国外加固Appdome环境检测与绕过

2023-12-26 00:10:10

文章目录

前言

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

博主可以帮忙过AppDome的签名校验,各种签名校验,算法还原,滑块,风控的突破. 需要可以联系博主. v: cjh-18888
类 HH Poker, gcash 应用

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

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

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地址打调用栈就可以分析出完整的检测流程。
在这里插入图片描述

有了这些调用关系，接下来便是一路调试验证的体力活了，最终检测流程如下：
0x3c2920线程创建线程检测函数

在这里插入图片描述

0x97568开启安全线程检查
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

0x105704magisk 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
这里的检测思路可以参考：
https://github.com/5ec1cff/my-notes/blob/master/new-idea-detect-zygisk.md#%E6%95%B0%E5%AD%97%E4%B8%AD%E6%9A%97%E8%97%8F%E7%8E%84%E6%9C%BA
在这里插入图片描述

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

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，然而真正退出并不是在这里，所以在这里倒推分析流程走了不少弯路。

文章来源:https://blog.csdn.net/Qiled/article/details/135210394
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。