爱盘 爱盘，在线破解工具包，实时提供最新逆向资源！ 帮助 吾爱破解论坛常见问题解答中心 本文是对于了 版本7.26.1，以及版本7.76.0 的frida检测进行的分析研究以及绕过 bilibili 7.26.1 bilibili的旧版本frida检测 image-20250304173059677.png (323.94 KB, 下载次数: 3) 下载附件 2025-3-6 16:00 上传 image-20250304173059677.png (323.94 KB, 下载次数: 3) 2025-3-6 16:00 上传 可以看到按照Spawn的方式启动的时候，直接frida就被检测了。我们按照 hook dlopen去查看可能出现的对应frida检测的so文件。 image-20250304173504546.png (439.55 KB, 下载次数: 4) 下载附件 2025-3-6 16:00 上传 image-20250304173504546.png (439.55 KB, 下载次数: 4) 2025-3-6 16:00 上传 可以看到的是libmsaoaidsec.so文件，在dlopen了之后，frida就被检测到了，所以大概率的可能是在libmsaoaidsec.so进行的frida检测。在这里之前，我们需要知道是在哪进行HOOK是最为有用的 这里我们可以通过在dlopen结束之后，去HOOK JNI_Onload函数，去判断检测函数在JNI_Onload之前还是之后，我们通过IDA可以去查看JNI_Onload的地址。这里是在JNI_Onload之前出现的frida检测。 image-20250304174423941.png (109.82 KB, 下载次数: 2) 下载附件 2025-3-6 16:01 上传 image-20250304174423941.png (109.82 KB, 下载次数: 2) 2025-3-6 16:01 上传 我们通过HOOK 进程创建，来看看对于frida检测的线程是在哪里启动的。在复现过程中，原作者使用了hook _system_property_get函数，这里是 init_proc函数较早的位置，这里涉及到了安卓源码中dlopen和.init_xx函数的执行流程比较，在我的so文件执行流程的过程中有细节分析。 image-20250304175152829.png (118.6 KB, 下载次数: 3) 下载附件 2025-3-6 16:01 上传 image-20250304175152829.png (118.6 KB, 下载次数: 3) 2025-3-6 16:01 上传 image-20250304175126362.png (19.96 KB, 下载次数: 2) 下载附件 2025-3-6 16:01 上传 image-20250304175126362.png (19.96 KB, 下载次数: 2) 2025-3-6 16:01 上传 由于我们知道，frida检测的是在JNI_Onload函数之前，那么我们就要在init_proc的越早的地方可以进行HOOK，我们HOOK的地方就是线程创建的位置pthread_create。 在这里我们通过去HOOK dlopen的位置，通过dlopen的位置去HOOK system_property_get 当参数是ro.build.version.sdk然后去hook pthread_create dlopen ———>system_property_get————>pthread_create image-20250305101304937.png (1005.51 KB, 下载次数: 4) 下载附件 2025-3-6 16:01 上传 image-20250305101304937.png (1005.51 KB, 下载次数: 4) 2025-3-6 16:01 上传 这里去比较了对应所以由pthread_create 创建的线程，当对应的线程的地址在libmsaoaidsec.so的地址区域内的时候，打印对应的地址以及偏移。可以看到这里有两个线程出现了 我们可以去通过IDA看看 image-20250305101938410.png (91.55 KB, 下载次数: 3) 下载附件 2025-3-6 16:01 上传 image-20250305102030763.png (25.16 KB, 下载次数: 2) 下载附件 2025-3-6 16:01 上传 image-20250305102554308.png (41.49 KB, 下载次数: 3) 下载附件 2025-3-6 16:01 上传 image-20250305101938410.png (91.55 KB, 下载次数: 3) 2025-3-6 16:01 上传 image-20250305102030763.png (25.16 KB, 下载次数: 2) 2025-3-6 16:01 上传 image-20250305102554308.png (41.49 KB, 下载次数: 3) 2025-3-6 16:01 上传 这些位置的像出现的 strcmp openat strstr.......很多的frida的检测，我们交叉引用一下看看pthread_create，然后直接实现NOP就可以了 image-20250305102842641.png (103.62 KB, 下载次数: 3) 下载附件 2025-3-6 16:01 上传 image-20250305103007170.png (119.26 KB, 下载次数: 2) 下载附件 2025-3-6 16:01 上传 image-20250305102842641.png (103.62 KB, 下载次数: 3) 2025-3-6 16:01 上传 image-20250305103007170.png (119.26 KB, 下载次数: 2) 2025-3-6 16:01 上传 image-20250305103610008.png (2.07 MB, 下载次数: 2) 下载附件 2025-3-6 16:01 上传 image-20250305103610008.png (2.07 MB, 下载次数: 2) 2025-3-6 16:01 上传 这里就绕过frida了，或者通过直接在IDA中去patch掉上面两个位置的pthread_create，然后把补丁之后的so再放到APK中也可以。 参考文章： [原创]绕过bilibili frida反调试-Android安全-看雪-安全社区|安全招聘|kanxue.com 7.26.1: image-20250305141556864.png (45.56 KB, 下载次数: 3) 下载附件 2025-3-6 16:01 上传 image-20250305141556864.png (45.56 KB, 下载次数: 3) 2025-3-6 16:01 上传 在高一点的版本上面，pthread_create函数是被隐藏了的 image-20250305141808889.png (81.61 KB, 下载次数: 3) 下载附件 2025-3-6 16:01 上传

image-20250305141808889.png (81.61 KB, 下载次数: 3) 2025-3-6 16:01 上传 但是其实我们通过之前的方法也能看到对应的pthead_create创建线程的位置 image-20250305144616783.png (860.96 KB, 下载次数: 3) 下载附件 2025-3-6 16:01 上传 image-20250305144616783.png (860.96 KB, 下载次数: 3) 2025-3-6 16:01 上传 这里可以看到在libmsaoaidsec.so中创建了三个新的线程，这里多半也就是进行frida检测的位置的了 同时这里我们进行HOOK的检测frida线程在哪的时候，也是在system_property_get的函数的位置进行HOOK的，但是实际上这里的位置也已经被混淆了，但是这个函数没有被混淆，可以直接在导入表里面找到的，那么我们就去交叉引用看看在哪引用的 image-20250305144950838.png (44.54 KB, 下载次数: 3) 下载附件 2025-3-6 16:01 上传 image-20250305145028014.png (72.21 KB, 下载次数: 3) 下载附件 2025-3-6 16:01 上传 其实是能够发现还是在init_proc的sub_123F0函数的位置的 image-20250305145110772.png (38.4 KB, 下载次数: 2) 下载附件 2025-3-6 16:01 上传 image-20250305144950838.png (44.54 KB, 下载次数: 3) 2025-3-6 16:01 上传 image-20250305145028014.png (72.21 KB, 下载次数: 3) 2025-3-6 16:01 上传 image-20250305145110772.png (38.4 KB, 下载次数: 2) 2025-3-6 16:01 上传 但是这里去判断参数的为"ro.build.version.sdk"已经被混淆了，但是我们既然能通过这个代码找到对应的线程，说明实际上还是去执行了 _system_property_get（"ro.build.version.sdk"） 这个函数的，而且既然代码可以直接检测得到frida检测的线程的地址，那么说明检测点还是再_system_property_get（"ro.build.version.sdk"）之前的。 我们同样按照交叉引用看看pthread_create 被混淆成了什么 image-20250305150332542.png (17.96 KB, 下载次数: 3) 下载附件 2025-3-6 16:01 上传 image-20250305150358745.png (14.73 KB, 下载次数: 3) 下载附件 2025-3-6 16:02 上传 image-20250305150437030.png (19.08 KB, 下载次数: 3) 下载附件 2025-3-6 16:02 上传 其实通过参数的形式，我们就可以判断大概率就是被混淆了的pthead_create函数 image-20250305150332542.png (17.96 KB, 下载次数: 3) 2025-3-6 16:01 上传 image-20250305150358745.png (14.73 KB, 下载次数: 3) 2025-3-6 16:02 上传 image-20250305150437030.png (19.08 KB, 下载次数: 3) 2025-3-6 16:02 上传 按照之前旧版本的frida检测，我们的反检测是通过NOP掉对应的frida检测线程，在7.26.1中frida检测是有两个线程的，而在7.76.0中，这里的frida检测有了三个线程，那么我们也可以对于这里的三个线程进行NOP 这里按照最原始的方法，不去NOP掉 pthead_create函数 ，而是去patch掉对应的frida函数。以及其中的NOP的实际，我选择的位置是在判断到进入libmsaoaidsec.so的时候，并且开始进行frida检测线程创建的pthead_create函数时期 image-20250306152208226.png (1.89 MB, 下载次数: 3) 下载附件 2025-3-6 16:02 上传 image-20250306152208226.png (1.89 MB, 下载次数: 3) 2025-3-6 16:02 上传 可以看到是直接绕过了frida检测的位置的。并且我写的一个frida打印函数也是成功执行了 绕过最新版bilibili app反frida机制-Android安全-看雪-安全社区|安全招聘|kanxue.com 在这一篇文章中，作者并没有去实现正面对抗，而且取巧绕过了，通过的方式就是在HOOK dlsym函数，在进入libmsaoaidsec.so之后去HOOK dlsym 判断调用pthead_create函数的次数，在前两次进行调用pthead_create函数时，去调用fake_pthead_create函数，从而实现frida线程不启动，达成绕过。 以下是取巧绕过的代码(复制于上面的网址)： image-20250306153129200.png (2.25 MB, 下载次数: 4) 下载附件 2025-3-6 16:02 上传 image-20250306153129200.png (2.25 MB, 下载次数: 4) 2025-3-6 16:02 上传 同样也可以实现绕过，不过，我们其实能知道，最开始的时候，其实是发现在libmsaoaidsec.so一共是开启了三个线程的，其实我觉得这里可以把count设置到三 [md]# XHS 8.32.0 在XHS的8.32.0中这里的代码仍然是可以使用的，我这里也是测试过的，不过对于代码里面新的修改 这里是可以绕过XHS的frida检测的，也是这三个线程的frida检测 image-20250310191525553.png (1.19 MB, 下载次数: 2) 2025-3-10 19:15 上传 发帖前要善用 【 论坛搜索 】 功能，那里可能会有你要找的答案或者已经有人发布过相同内容了，请勿重复发帖。 PixPin_2025-04-11_21-36-30.jpg (99.84 KB, 下载次数: 3) 2025-4-11 21:37 上传 免责声明： 吾爱破解所发布的一切破解补丁、注册机和注册信息及软件的解密分析文章仅限用于学习和研究目的；不得将上述内容用于商业或者非法用途，否则，一切后果请用户自负。本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑中彻底删除上述内容。如果您喜欢该程序，请支持正版软件，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。 Mail To:Service@52pojie.cn 关注微信 微信签到每天都送论坛币！ RSS订阅 | 小黑屋 | 处罚记录 | 联系我们 | 吾爱破解 - 52pojie.cn ( 京ICP备16042023号 | 京公网安备 11010502030087号 ) GMT+8, 2026-10-19 23:57 Powered by Discuz! Copyright © 2001-2020, Tencent Cloud.