作者：uiop

前言

偶然发现使用shamiko模块无法绕过某国外加固厂商的环境检测，那么就需要具体分析一下它检测了哪里。

第一部分：定位检测逻辑的通用思路

都深有感触的便是定位检测代码是个体力活；那么便先尝试用一些常用的定位思路来分析一波

1.通过linux“一切皆文件”思路定位

通过对底层系统库函数诸如openat、readlinkat、fstatat等进行hook监控，结果如下：

看到打开的都是sbin目录的特征文件然而此方式shamiko便能绕过，那么便还有其余的检测点。

2.分析现有检测软件猜测可能检测点

分析momo发现它是通过读取pts/2 下内容的方式发现su进程(此时su进程必须在运行状态下才能检测出来)，然而此时su必须是运行方式才能检测出来很明显与分析app检测方式不符合

3.通过正向开发思路定位

通过普遍cv的思想在github查找开源的代码块进行定位，下面代码在检测ld_prlaods符号存在于ro.data段，那么便可以使用gdb的awatch来观察ld_prlaods所在内存是否被读写。

最后发现Shimako对这片进行了隐藏。因此便需要针对app的特定特征进行分析了

4.通过activity及弹窗定位

此app有非常明显的窗口点击事件，通过hook点击事件来定位到是哪个activity进行的活动展示

通过对activity一步一步分析出一些整体流程

第二部分：检测结果展示整体流程

整体流程就粗略带过一下

1.Jni反射调用doDispath完成广播发送

2.NativeBridge接口完成数据交互

通过这些api接口完成java到native 层的数据交互，native层会根据这些信息拼接发送信息

3.Appdome注册registerAppDomeBroadCastReceiver接受广播

从以下代码便能看出接收器接受到检测到的各种事件

4.LoginActivity将接受事件进行活动展示

第三部分：native流程分析

重点来到native的检测流程

1.Native层如何分析？

通过Jnitrace后发现以下关键字符串，因为已经知道了整体流程最终都是通过dosidpatch来发送消息，那么对最终dodispatch地址打调用栈就可以分析出完整的检测流程

有了这些调用关系，接下来便是一路调试验证的体力活了

2.最终检测流程如下：

•0x3c2920 线程创建线程检测函数

•0x97568开启安全线程检查

•0x105704 magisk detect： 路径比较，动态链接库符号比较
函数体混淆之后非常庞大，因此只关注关键地方进行分析即可

通过对这些函数查看参数，就可以看到一些对magiks的一些传统检测




然而这里还没有跟开头发出的json字符串有关系，所以需要接着向下分析

•0x284638通过927c0和dbba0设置eventid

找到当前关键函数后向前打调用栈会发现有两个分支

•0x24c164：927c0分支读取/data/data/com.mobile.co.th/cached_prefs 的值判断是否设置eventid

这里发现cached_prefs没有任何的写入，删除便可绕过

•0x253a38：dbba0分支以malloc为标志计算0x7f2190偏移处的dladdr是否为0
这里的检测思路可以参考：c0aK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1j5#2k6h3x3I4j5$3k6X3i4K6u0r3L8i4W2Q4x3X3c8F1L8%4c8W2M7#2)9J5c8X3u0D9L8$3u0Q4x3V1k6E0j5i4y4@1k6i4u0Q4x3V1k6F1k6i4N6Q4x3X3c8A6k6r3g2S2i4K6u0V1k6r3g2@1k6h3y4@1i4K6u0V1P5Y4W2Y4K9i4y4C8i4K6u0W2L8h3c8Q4x3U0y4Q4x3U0g2q4y4W2)9J5y4e0V1#2i4K6t1#2b7U0m8Q4x3U0g2q4y4g2)9J5y4f1q4p5i4K6t1#2z5e0N6Q4x3U0g2q4y4q4)9J5y4f1t1^5i4K6t1#2b7f1c8Q4x3U0g2q4y4W2)9J5y4e0W2m8i4K6t1#2z5e0N6Q4x3U0g2q4z5q4)9J5y4e0V1%4i4K6t1#2z5p5k6Q4x3U0g2q4y4#2)9J5y4e0S2q4i4K6t1#2z5o6c8Q4x3U0g2q4y4W2)9J5y4e0W2o6i4K6t1#2b7V1p5`.

找到检测的关键点以后接下来的流程已经不重要了

•0x20c4f4处通过看参数和结果确定是在构造json字符串

•在0x203ac4的函数 通过eventid发送对应envent

•0x17e8e4反射调用doDispath发送广播

第四部分：绕过方案

有了以上分析之后那么接下来随便绕

1.不让app退出

分析退出流程是需要点击才能退出，于是可以通过lunch到想要的activity来进行绕过

2.使检查线程创建失败

既然是创建线程来检测， 那么就可以将检测线程创建失败进行绕过

3.粒度更小的绕过方式

使线程创建失败，粒度太大。也有许多对线程保护（如：将释放dex与检测放到一起，process_vm_write读取线程等）更多时候往往需要粒度更小的绕过方式，这时便可以对关键判断进行patch。

4.通用绕过方案

rom定制root方案
kernelsu方案
漏洞root方案

第五部分：后记

1.遇到的一些困难

分析时，检测到环境异常会退出严重干扰分析通过动态调试发现检测到环境异常后会执行非法指令进行退出。
使用gdb调试，追踪所有线程可以看到每个线程的行为

查看0x7b8段所属内存为匿名可执行段，将其dump下来可以查看syscall实现（以为在找到了7寸），分析这个可以对所有系统调用全部hook住。因为时机原因每次只hook到nano_sleep，然而真正退出并不是在这里，所以在这里倒推分析流程走了不少弯路。

2.还有很多检测（代码注入检测，adb检测，开发者选项开启检测等）暂时还没有分析

[培训]科锐逆向工程师培训第53期2025年7月8日开班！