昨天发现自己有点发烧，今天测一下果然阳了，大早上起来睡不着 。

请假以后正好闲着没事，完善一下之前文章 https://bbs.kanxue.com/thread-273759.htm 。

之前一直想写来着，但是一直没时间 。之前这篇文章介绍了。设备指纹基础对抗思路和原理 。很多都是基础部分 。这一篇将更详细的介绍一些常见的检测思路和方法，还有一些主流对抗手段 。

其中包括很多大厂头疼的一些事情，如何手机恢复出厂设置也能保证设备指纹不发生变化，保证稳定性 。这篇文章里面也都会详细介绍 。

如果没看过我之前的这篇文章，所以没看过的同学可以先看看这个文章 。之前有的这篇文章里面就不多二次介绍了 。

还有就是一个设备指纹大厂会使用多种方式去获取，那么我们应该如何进行对抗 ，我也会在文章里面说一下我自己的见解和方案，如何在一个“最佳”点去解决问题 ，当然如果你有更好的方案，也可以私聊我。

聊到设备指纹最经典的一个字段就是Android id，就我目前所知，他的获取方式不下5种 。分别介绍一下 。

最基础的Android id获取方式 ，这个不多说，直接Hook就行 。

第一种获取以后，系统会把Android id 保存起来，保存到一个HashMap里面，防止多次IPC初始化 ，所以为了验证第一种方法的准确性，可以二次获取cache ，

和上面的Android id进行对比 。9.0以上需要绕过Android id 的反射限制 。具体获取方法如下：

方法3也是很基础的Api ，主要通过ContentResolver 进行间接获取 。很多大厂也都在使用 。

通过query命令去查询，获取Android id ，这种方式底层走的也是ContentResolver

方法4的代码反射实现，我自己测试在高版本总是有问题 ，不是很稳定 ，所以这里面就不发了 。

在设备指纹里面，如果想回复出厂设置也能保证原有的设备信息 ，这个字段可以在服务端的相似度算法里面占比很重 ，可以以型号进行分类。，我之前测试过，回复出厂设置指纹也不发生变化的设备指纹核心的设备指纹就几个 。

比如硬盘大小，ipv6 ，还有一个就是MAC地址，这几个设备指纹也是很核心的设备指纹 。首先先介绍硬盘字节大小。 也是三种获取方法，但是方法底层都是一条系统调用。所以如果要进行对抗的话，只需要在SVC层进行处理即可 。获取三种方法如下 ，不建议分别进行处理，可能会导致有地方泄漏，特别是直接开启一条进程通过execve去执行，然后管道传过来，导致很容易Hook不全。

我之前也是参考的平头哥，Hook的Java方法，但是发现Native层并不能全量拦截 。后来弃用 。平头哥方法代码如下：

上面这种方式只适合Java获取，具体三种获取方法可以看下面 。

这三种方法底层走的都是statfs64 或者statfs函数，对抗的话也很简单，直接在statfs64 或者statfs 的after里面对参数2进行替换和复写即可 。

对抗如下，具体如何拦截svc代码可以参考proot ,可以参考我之前写的文章 https://bbs.kanxue.com/thread-273160.htm

这种方法的好处就是不管如何开进程，都可以在底层统一处理 。

这个没啥好说的，基础字段，Java层获取，netlink获取，命令行获取 。读文件获取，四种获取方法，和上面类似 ，直接在svc的 recvmsg ，recv，recvfrom的after进行数据包替换即可。netlink获取mac方法可以参考我之前的代码 。

https://bbs.kanxue.com/thread-271698.htm

如果判断是netlink的消息，并且是获取网卡类型直接对里面的数据包解析和替换即可 。

在读文件获取这块因为网卡信息已经在内存里面 ，所以直接IO重定向过去即可 。

常用的获取网卡信息的文件 ，以wlan0为例子 ,场景的获取目录如下：可以cat获取，也可以直接读文件 。

这个字段主要是监控群控的一些信息的，主要作用是获取当前wifi 附近的人MAC信息的 。

比如大厂一般检测群控的手段就是获取附近的网卡，如果有聚集性就可以认为是群控 。获取的方式也也跟上面一样 。五种获取方法 。

获取方法底层也是和MAC获取方法一样 ，底层都是netlink，比如可以直接执行 popen获取 ，

也可以直接直接读文件 ，路径如下：

还可以直接netlink获取 ，在收到消息以后判断消息类型是 hdr->nlmsg_type == RTM_NEWNEIGH 直接进行替换即可 。

直接在recv收到消息以后对数据里面的buff进行替换即可 。主要核心代码如下 。包括上面的mac地址替换 。

设个设备指纹也是很核心的设备指纹 ，这个玩意底层获取也是netlink，但是netlink获取，但是这块处理很不好处理 ，我暂时也没进行处理 。

常用的获取方式比如，Java获取 ，命令获取。如果需要进行替换的话 ，只需要处理命令行和Java的Hook即可 。

命令行可以在对方执行命令之前，将命令换成cat命令，去cat自己提前Mock好的文件，效果是一样的 。

当然，还有另一种思路，其实这个字段可以服务端获取，客户端二次上报，进行匹配 。

命令行获取如下，ip命令获取如下 。

打印的内容如下：

这玩意底层走的都是uname函数 ，直接对uname系统调用处理即可 。获取方法比如,也可以直接svc调用uname函数 ，也可以直接根据命令行 ，

修改的话也很简单，直接在uname的after里面直接对数据进行替换即可 。

这个是一个非常非常核心的字段，就是/data/app/随机Base64路径/base.apk

这个随机路径就是设备指纹，比如一些大厂会玩，读取你微信的随机路径，获取微信的包信息，然后获取里面的随机路径

比如微信，快手，京东，淘宝这种随机路径 ，作为核心的唯一设备指纹，只要你不卸载微信，或者其他大厂apk ，你得设备指纹永远不发生变化，无论你如何修改他自己Apk里面的信息，跟他都不产生任何影响 。

一般尝试比如小米之类的，登入了指定账号，可以得到一个账号的id信息 ，这个也需要处理一下 。最好的办法是不登入账号 。

检测环境大多数围绕Hunter的源码检测思路去复现 ，很多都是Hunter的源码 ，很多也都是行业内没有公开的一些检测思路 ，现在市面上检测已经很多没更新了 ，加速行业内卷，我辈刻不容缓 。 ：）

提到环境检测不得不说的就是Apk重打包检测 ，现在检测方法千奇百怪，我这边也是一一罗列一下，把一些可能存在的风险点，检测和绕过的原理详细叙述一下 。当然如果你有更好的思路也可以在文章下面留言。

想要绕过签名检测最好的办法或者说成本最低有效的办法就是修改完毕以后不签名配合核心破解直接安装。

核心破解是lsp的模块，lsp商店直接下载，Hook apk的系统签名解析方法，直接绕过签名检测流程 ，已实现不签名直接安装 。

首先先说一下大厂或者一些企业壳的检测点，Java层基础的获取签名的方法这块就不一一叙述了 。

这块以Hunter 源码开始介绍 。

核心就三部分 。

针对上面的检测对抗也很简单，对svc的openat拦截了以后，对readlinkat和stat函数进行处理即可 。很轻松即可绕过检测 。很多加壳基本都是检测ROOT检测LSP调用栈之类的 ，并不只是单一的去检测签名一个纬度 。比如发现了开启了seccomp就会闪退，发现Root就会闪退 。

这里先说一下Hunter的Java层检测签名的方法，这块相当于反射CREATOR 变量，这个变量是保存一些IPC通讯的东西 。

很多攻击者会用Lspatch进行打包 ，对变量进行替换，这时候我们去检测这个变量的Classloader是不是系统ClassLoader 。

防止被替换 。

对抗的方法主要下面三种：

现在大厂一般会直接通过IPC直接和PMS进行通讯 ，不过这种思路也很好过 ，我这边也是参考的Lspatch 。

这块有两个很核心的思路 ，就是拦截Binder IPC通讯的方法，和Hook 服务端的签名解析方法 。代码如下：

在系统进行签名解析的时候进行签名替换替换 。

这个思路也是抄的lspatch ，这种思路可以通过检测CREATOR 变量Classloader的方式检测出来 。

有很多大厂会自己伪造IPC和服务端进行通讯，用这种方法可以进行签名的修改和替换，实现思路主要就是Hook binder通讯解析的方法 。判断如果传输类型数据是获取签名的话就进行替换 。主要思路就是Hook传输数据的“水管”，对水管里面的内容进行替换 。

不知道为什么lspatch新版本把这段代码删除了 ，只采用了替换CREATOR 和Hook服务端解析签名的方法 。

代码如下：

还有很多很好思路的代码 ，比如ISO线程去读取apk签名信息，防止SVC被IO重定向掉 。

当然检测签名的方法肯定不止这些，如果有更好的，我没写的，也可以在文章下面留言 。

Java层基础的获取api架构啥的，这块就不一一叙述了 。

主要思路来自B哥 ，感谢B个 ，先安装seccomp架子 。

配合上面的代码 。启动调用getpid， 上面的架子会对getpid函数进行拦截 ，然后架构进行判断 。

这块思路主要来自非虫 ，在次感谢 。

这块思路还是很多的，不同的云手机检测的思路也不一样 。大部分云手机做的还是很好的，很多都可以过掉Hunter的检测 。

判断摄像头有个数 。

这块思路就是直接获取个数，少于10个可以直接认定为黑产 。 我目前没发现那个手机少于10个传感器 ，这块如果可能的话可以尝试调用一下传感器，保证传感器是否可用 ，防止云手机以假乱真 。

这块检测思路主要是检测传感器的名称，正常小米之类的手机他是不可能存在叫什么 AOSP的传感器的 。

这种AOSP基本都是自己编译的ROM ，所以这块也可以作为监测点 。可以上报传感器的一些名称信息，也是环境检测一个很重要的抓手 。

一般小白肯定不会说去改传感器名称 。

这块就是去遍历mounts 下面这几个文件，检测里面是否包含docker关键字 ，防止一些云手机搞虚拟化，通过使用docker进行挂载 。

这块也是很好的监测点 。

这块思路主要好多种 ，主要是为了防止一些自定义ROM ，通过修改机型的方法，绕过自定义ROM检测逃逸 。

可以直接执行getprop 把所有的环境信息都拿到手 ，如果是小米手机，里面环境信息里面，肯定是有MIUI关键字。

比如小米的手机，我会去检测是否包含这几个关键环境信息 。

这块可以采集以后服务端进行判断 。防止自定义ROM 机型伪造 。

这块还是执行 service list ，一般小米手机之类的，都会有小米的系统服务，这种东西很难去伪造，如果他伪造了假的 。你就尝试调用即可 。

这块还是建议上传到服务端，由服务端算法同学去根据相似度算法去推断 ，不要再本地进行判断 ，因为Hunter是非联网Apk，所以只是在客户端打了个样子 。

这块检测方法千奇百怪，首先最基本maps去检测frida或者根据调用栈检测lsp特征 ，基础的检测方案不说了 。因为我觉得并不是一个很好的方案 。改个名就绕过了 。

比如frida特征三件套 。检测思路主要

Hook检测，我们其实只需要检测内存没有被修改即可 。这块需要介绍一下基础原理。和实现的伪代码 。

正常我们知道一个SO加载到内存里，本质上是通过mmap把so分配到内存里面 ，比如A函数的指令是BBB，那么加载到内存里面应该也是BBB 。

记住上面这句话 ，我们就可以对内存里面的指令转换成一个int值，然后累加 。如果内存没有被修改 ，累加值文件里面和内存里面的值应该是一样的 。

因为现在Hook基本都是text段和plt端，一个inlinehook一个got表 。当然Frida可能会延迟启动 ，所以开启一条检测线程，进行轮训操作。

这块还有一个设计问题，很多开发者也都没注意到 ，就是我开启的这一条线程，被攻击者anti掉 应该怎么办呢？

因为想要anti掉一条检测线程，方法太多了，N种方法，比如监听全部线程的文件读写，看看那个线程在读取文件 ，只做这一件事，基本八九不离十 ，

也可以直接Hook开启线程的方法，对开启的线程进行anti 。当然这种思路 就没有好的对抗或者检测办法了么？

其实很简单 ，只需要把在你的检测代码里，对某个变量进行赋值 ，修改flag即可 。

然后第一次检测完毕以后将主进程的某个变量标志为true，可以使用__NR_process_vm_writev ，又因为是异步的关系，主线程可以延迟2秒对这个标识进行获取，判断是否为true ，

以确保检测线程成功开启 。

具体检测流程如下，以检测libc为例子，路径可以换成自己需要的路径 ：

首先获取本地So文件的累加值 ，返回execSection 结构体 。

然后和本地的指令去计算 。计算本地的指令方法就是对maps进行遍历，只遍历text和plt段 ，计算累加值和本地进行判断 。

当然这块就一定是比较完善的检测方案了么？其实有很多对抗思路 。比如把maps里面的内存进行隐藏，变成匿名内存，这样他在扫描maps的就找不到，对应的比如上面说的libc的item ，

这块可以参考riru里面的 map_hide ，代码路径如下 ：

030K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6d9K9h3E0C8j5f1q4H3M7s2y4Q4x3V1k6d9K9i4u0#2i4K6u0r3j5X3I4G2j5W2)9J5c8X3#2S2M7%4c8W2M7W2)9J5c8Y4u0A6M7Y4g2Q4x3V1k6K6M7X3y4Q4x3V1k6E0j5h3W2F1i4K6u0r3j5%4m8H3i4K6u0r3K9r3W2V1k6g2)9#2k6Y4g2@1K9h3I4K6i4K6u0W2j5%4m8H3

当然这种方式一定是安全的么？

其实，不是的，因为在他的这个代码里面我发现存在一个遗漏点，可以作为检测入手点 ，某个加固厂商，不仅仅会对maps item进行遍历 ，还会对里面的匿名内存进行遍历 ，检测匿名内存里面的 magic ，比如so 文件的magic是elf ，如果magic 匹配上一样当maps去解析 去遍历。

所以可以在原有的基础上改改，在将内存变成匿名内存以后，把elf的前四个字节抹掉，也就是magic的 内容，抹掉以后记得把权限修改成和之前的一样 。防止内存检测 。

这块检测核心逻辑全部放在ISO线程检测 。可以配置一个服务，然后服务里使用如下变量即可 。

这个服务非常恶心，一般沙箱对这个线程都会进行跳过 。

这块有人可能会问什么是iso线程？可以理解成一个独立的安全的线程，只能通过和外部IPC交互的方式进行通讯 。useAppZygote 相当于让这个进程运行在Zygote中 。这个时候时机特别早，早到什么程度呢？就连libart.so 都没加载，所以这个检测进程只能调用一些原始的libc方法，不能调用任何Art相关的函数 。

再多的我也不知道了 ，这块具体什么是ISO线程，让GTP回答一下吧，回答如下 ：

下面也是主要介绍一下hunter的检测思路 。

主要实现思路就是去检测proc下面是否有除了main进程以外的其他pid ,因为正常启动的话，肯定是只有一个main进程 。

但是沙箱的话会在启动之前去启动别的进程 ，所以这块可以进行bypass 。后面我会统一说这块应该如何对抗 ，包括如何绕过 。

这块先介绍检测思路 ，和检测原理 。这块里面有一个replaceSecInsns是我自己封装的一个函数，我担心 opendir 被Hook了，所以每次执行都去把指令替换成

本地文件的指令，而不是去执行内存里面的指令 。

这块想要绕过也很简单，opendir 底层其实就是 getdents64，getdents 如果遇到你想隐藏的文件直接对文件进行bypass就可以了，直接指向下一个指针 ，

代码来自proot

这块的思路就是检测是否存在其他进程 ，通过执行ps -ef命令 。

可以先伪造一个正常的文件，在执行到 ps -ef的时候把命令换成cat 你自己的文件 即可 。

这块的实现思路就是，检测内存里面的 Activity 或者 Application的个数 。正常我们的apk启动只会有我们自己的

Application，沙箱因为预启动的关系，会存在其他的Application ，这块也是一个很好的检测思路 。

因为在国内手机里基本Google和lineageos都是黑产的标配 ，大部分都是自己刷的ROM 。

这种手机理论上在国内 不应该出现，如果出现也会被打上标签，被认定为黑产 。可以直接Build.MODEL 获取厂商 。

另外这块还有一个细节点 ，就是lineageos一个特有文件/system/addon.d 。具体如下 。

当然这块有一个细节点：

直接获取 ro.build.display.id 可能会被Hook ，所以这块我的建议是直接去解析配置文件 。

核心解析（/dev/properties/u:object_r: ）文件方法如下 ：

这块检测方法太多了，我知道的就不下于10种，比如核心A和B方法里面加个时间搓，如果A执行到B大于5秒就可以认为被调试 。

检测调试状态也是很不错的选择，不过这块可以利用ISO线程去检测调试状态，防止被ptrace

也可以执行 "service list" 获取服务列表 ，判断是否包含frida关键字 。

如果你使用了这个帖子里面的代码，请备注出处 。感谢理解 ！

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！