技术宅的结界

 找回密码
 立即注册→加入我们

QQ登录

只需一步,快速开始

搜索
热搜: 下载 VB C 实现 编写
查看: 85|回复: 1
收起左侧

Android新攻防技术研究与应用

[复制链接]

271

主题

445

帖子

4725

积分

用户组: 真·技术宅

UID
2
精华
61
威望
148 点
宅币
3553 个
贡献
126 次
宅之契约
0 份
在线时间
614 小时
注册时间
2014-1-25
发表于 2018-12-12 13:22:15 | 显示全部楼层 |阅读模式

欢迎访问技术宅的结界,请注册或者登录吧。

您需要 登录 才可以下载或查看,没有帐号?立即注册→加入我们

x
本帖最后由 元始天尊 于 2018-12-12 15:53 编辑

一年前写的了哈,原帖:https://www.jianshu.com/p/9289dd2e034c,要是我们这里支持markdown就更好了
底下编辑按钮没了,很苦恼,放在这里 编辑

通用软件保护手段

  • 源码层级保护:在编码过程中实现的攻防手段
    • ① 增加分析复杂度:多线程、虚函数、模板、静态STL库、回调等
    • ② 常规攻防能力:AntiHook/AntiDebug/AntiInject/RootDetect/EmulatorDetect/...
    • 混淆技术:
      • ③ 代码混淆:如OLLVM
      • ④ 常量混淆:主要是字符串混淆
  • ⑤ 二进制层级保护:在生成软件后,对二进制进行处理进行加固的手段

本文着重介绍①和③,其他方式网上资料较多这里不再赘述。对于②提供如下参考资料:
https://github.com/obfuscator-llvm/obfuscator
Android常规攻防能力表:

调试检测(Debug) 反调试(AntiDebug) 注入检测(Inject) 反注入(AntiInject) Hook检测(Hook)) 反Hook(AntiHook) Root检测(RootDetect) 模拟器检测(EmulatorDetect)
进程名检测
默认调试端口检测
进程调试状态检测
内存断点检测
内存读写检测
<font color=#FF0000 bgcolor=orange>调试协议测试</font>
进程文件二进制匹配
ptrace保护
<font color=#FF0000 bgcolor=orange>JDWP握手信号拦截</font>
<font color=#FF0000 bgcolor=orange>JDWP调试模型破坏</font>
Jni层反调试
常见注入工具检测
环境变量检测
加载模块检测
注入端口检测
检测加载模块 常见Hook框架检测
系统文件修改检测
进程模块检测
<font color=#FF0000 bgcolor=orange>Java native hook检测</font>
内存模块恢复 常见su文件检测
系统目录权限检测
Root工具检测
系统属性检测
特殊文件检测
手机号、硬件ID检测
……

注:加红为我们自己新增的高级功能

C++模板元常量字符串混淆

  模板元是C++ 11引入的新概念,用于将一些简单函数执行流程(分支/循环)放在编译期完成,以提高运行期性能甚至完成一些特殊功能。在展示一个完整的模板元编程实现字符串加密函数前,这里先提供一些准备知识:

  • C++ 11提供constexpr关键字用于定义编译期常量
  • inline关键字是向编译器请求内联;force_inline关键字是强制编译器内联
  • TIME用于在编译期获取时间
line01 #define force_inline __attribute__((always_inline))
line02 #define naked __attribute__ ((naked))
line03
line04 #ifndef vxSEED
line05 // If you don't specify the seed for algorithms, the time when compilation
line06 // started will be used, seed actually changes the results of algorithms...
line07 #define vxSEED ((__TIME__[7] - '0') * 1  + (__TIME__[6] - '0') * 10  + \
line08                            (__TIME__[4] - '0') * 60   + (__TIME__[3] - '0') * 600 + \
line09                            (__TIME__[1] - '0') * 3600 + (__TIME__[0] - '0') * 36000)
line0A #endif
line0B // The constantify template is used to make sure that the result of constexpr
line0C // function will be computed at compile-time instead of run-time
line0D template<uint32_t Const>
line0E struct vxConstantify {
line0F     enum {
line10         VALUE = Const
line11     };
line12 };
line13
line14 // Compile-time mod of a linear congruential pseudorandom number generator,
line15 // the actual algorithm was taken from "Numerical Recipes" book
line16 constexpr uint32_t vxRandom(uint32_t Id) {
line17     return (1013904223 + 1664525 * ((Id > 0) ? (vxRandom(Id - 1)) : (vxSEED))) &
line18            0xFFFFFFFF;
line19 }
line1A
line1B // Compile-time random macros, can be used to randomize execution
line1C // path for separate builds, or compile-time trash code generation
line1D #define vxRANDOM(Min, Max) (Min + (vxRAND() % (Max - Min + 1)))
line1E #define vxRAND()           (vxConstantify<vxRandom(__COUNTER__ + 1)>::VALUE)
line1F
line20 // Compile-time recursive mod of string hashing algorithm,
line21 // the actual algorithm was taken from Qt library (this
line22 // function isn't case sensitive due to vxTolower)
line23 constexpr char vxTolower(char Ch) {
line24     return (Ch >= 'A' && Ch <= 'Z') ? (Ch - 'A' + 'a') : (Ch);
line25 }
line26
line27 constexpr uint32_t vxHashPart3(char Ch, uint32_t Hash) {
line28     return ((Hash << 4) + vxTolower(Ch));
line29 }
line2A
line2B constexpr uint32_t vxHashPart2(char Ch, uint32_t Hash) {
line2C     return (vxHashPart3(Ch, Hash) ^ ((vxHashPart3(Ch, Hash) & 0xF0000000) >> 23));
line2D }
line2E
line2F constexpr uint32_t vxHashPart1(char Ch, uint32_t Hash) {
line30     return (vxHashPart2(Ch, Hash) & 0x0FFFFFFF);
line31 }
line32
line33 constexpr uint32_t vxHash(const char *Str) {
line34     return (*Str) ? (vxHashPart1(*Str, vxHash(Str + 1))) : (0);
line35 }
line36
line37 // Compile-time generator for list of indexes (0, 1, 2, ...)
line38 template<uint32_t...>
line39 struct vxIndexList {
line3A };
line3B template<typename IndexList, uint32_t Right>
line3C struct vxAppend;
line3D template<uint32_t... Left, uint32_t Right>
line3E struct vxAppend<vxIndexList<Left...>, Right> {
line3F     typedef vxIndexList<Left..., Right> Result;
line40 };
line41 template<uint32_t N>
line42 struct vxIndexes {
line43     typedef typename vxAppend<typename vxIndexes<N - 1>::Result, N - 1>::Result Result;
line44 };
line45 template<>
line46 struct vxIndexes<0> {
line47     typedef vxIndexList<> Result;
line48 };
line49
line4A template<uint8_t XorKey, uint8_t BitShiftKey, typename IndexList>
line4B struct vxEncStr;
line4C
line4D template<uint8_t XorKey, uint8_t BitShiftKey, uint32_t... Idx>
line4E struct vxEncStr<XorKey, BitShiftKey, vxIndexList<Idx...> > {
line4F     uint8_t Value[sizeof...(Idx) + 1]; // Buffer for a string
line50     // 这里若不设置alinline则最大加密50字节
line51
line52     constexpr force_inline uint8_t vxEncCh(const char Ch, uint32_t Idx_) const {
line53         // do XOR
line54         return (uint8_t)((((Ch & 0xFF) ^ ((XorKey + Idx_) & 0xFF)) >> BitShiftKey) |
line55                (((Ch & 0xFF) ^ ((XorKey + Idx_) & 0xFF)) << (CHAR_BIT - BitShiftKey)));
line56     }
line57
line58
line59     // Compile-time constructor  有的编译器数组初始化使用'{',有的使用'('
line5A     constexpr force_inline vxEncStr(const char *const Str) : Value{vxEncCh(Str[Idx], Idx)...} {
line5B         static_assert(BitShiftKey < 8 && BitShiftKey >= 0, "Invalild BitShiftKey");
line5C         static_assert(XorKey < 0x100 && XorKey >= 0, "Invalild XorKey");
line5D     }
line5E
line5F     // Run-time decryption
line60     char *decrypt() {
line61         for (uint32_t Idx_ = 0; Idx_ < sizeof...(Idx); Idx_++) {
line62             // do XoR         XorKey + Idx_ may exceed 255
line63             Value[Idx_] = (uint8_t)((((Value[Idx_] & 0xFF) << BitShiftKey) |
line64                 ((Value[Idx_] & 0xFF) >> (CHAR_BIT - BitShiftKey))) ^ ((XorKey + Idx_) & 0xFF));
line65         }
line66         Value[sizeof...(Idx)] = '\0';
line67         return (char*)Value;
line68     }
line69 };
line6A
line6B // Compile-time hashing macro, hash values changes using the first pseudorandom number in sequence
line6C #define vxHASH(Str) (uint32_t)(vxConstantify<vxHash(Str)>::VALUE ^ vxConstantify<vxRandom(1)>::VALUE)
line6D // Compile-time string encryption macro
line6E #define vxStrEnc_(Size, Str) (vxEncStr<vxRANDOM(0, 0xFF), vxRANDOM(0, CHAR_BIT - 1), \
line6F     vxIndexes<Size - 1>::Result>(Str).decrypt())
line70 #define vxStrEnc(Str) vxStrEnc_(sizeof(Str), Str)
line71 #define vxStrEncDbl(Str) vxStrEnc_(sizeof(Str), vxStrEnc_(sizeof(Str), Str))
line72 #define vxStrEncTri(Str) vxStrEnc_(sizeof(Str), vxStrEnc_(sizeof(Str), vxStrEnc_(sizeof(Str), Str)))

说明如下:

  • vxRandom为模板元函数,用于在编译期生成随机数,(模拟rand实现),每次调用该函数以获取不同随机数
  • vxHASH为模板元函数,用于在编译期对静态字符串生成散列值
  • vxStrEnc为模板元函数,用于在编译期对静态字符串实施加密,这样在编译生成的二进制中只会存在经过加密的16进制序列,该序列在运行期在vxStrEnc调用点使用decrypt解密。注意decrypt需要在运行期执行因此不能是模板元函数
  • vxStrEncDbl和vxStrEncTri是进行多次加密,增强复杂度
  • 模板元函数对于静态字符串或静态数组的处理,是通过模板迭代成单个元素,这一过程较为复杂,上述代码借助vxIndexList生成一个静态索引数组来实现迭代字符串元素
      综上,模板元编程是将运行时的某些操作放到编译期来做,提高了程序运行效率,也会略微增加生成二进制大小;而上述代码的加密极大增强了分析复杂度,结合OLLVM效果更好

调试检测

常用调试器进程名检测/二进制匹配

  • 对于C调试器采用进程检测
      如果当前进程被调试则必然存在调试器进程,因此可以通过进程名方式检测,存在下面是常见调试器对应的进程名及二进制中特征字符串
IDA  -> android_server / android_server_pie -> “IDA Android 32-bit remote”
GDB  -> gdb / gdbserver -> “GNU gdbserver”
LLDB -> lldbserver
  • Adbwifi类APP进程检测
      adbwifi是在Root权限下,使用wifi进行Java/C层调试的工具,因此若存在这种进程有可能设备已经Root或正在进行调试,我收集了一些常用包名用于检测这类调试器:
com.gikir.gikdbg      com.soynerdito.adbnetworkenabler   
adb.wifi.woaiwhz.wifiadbandroid  com.twiceyuan.devmode      
chendx.wifiadb.main     com.vn.tooa.adbwireless      
cn.com.wxtech.adbwireless   com.wmendez.adbovertcp      
com.adam.adbWifi     com.youzi.adbwifi       
com.adb       com.zhoupeng.adbwireless     
com.androidfree.adbwifi    fr.ydelouis.yrelessadb      
com.eboy.adbwireless     hcursor.adbcontrol       
com.fly.wifiadb      info.nakajimadevnakajima.adboverlanswitcher
com.ilovn.app.wifi_adb    jps.android.adbtcp        
com.liam_w.networkadb    me.meowo.adb        
com.palmcrust.yawadb    moe.haruue.wadb        
com.rair.adbwifi      net.wiagames.adbon       
com.rockolabs.adbkonnect    rfo.mougino.waf        
com.ryosoftware.adbw          ru.bartwell.easyremoteadb
com.scopionstudio.adbwifi            vn.android.adbwireless
                                  za.co.henry.hsu.adbwirelessbyhenry

二进制匹配和进程名检测技术总结:
优点:二进制文件比对这种检测方式可以弥补进程名检测的不足。
缺点:始终是最简单的调试检测方式,也最容易被绕过

常用调试器端口检测

  移动端采用远程调试器的调试方式很常见,其结构是远程调试服务器+本地调试器,通过调试协议进行通信,其中远程调试器server端安装在移动设备上,完成如下断点等所有实际操作,而本地调试器位于主机上,接受用户指令转化成调试协议数据发送给服务端。作为服务器就要在设备端绑定端口,因此可以检测某些默认端口号来检测调试器的存在,如:IDA默认调试端=23946。(同理还有注入服务器、Hook服务器)
  本地端口开放状态可以通过读取/proc/net/tcp和/proc/net/udp解析。Android基于linux系统,存在特殊的unix文件句柄用于socket通信,Android Studio使用lldb调试采用这种方式调试,可以在/proc/net/unix发现踪迹。
  由于采用默认端口的服务端很少,因此对处于ESTABLISHED状态的服务端,这里提供协议测试方式分辨调试服务器(对于已连接状态的服务端无法检测)(该方式由于与服务器进行通信,有一定可能使本地服务器崩溃),目的如下:

  • 检测调试器
      在本地调试器连接到该远程调试服务器之前,通过发送特定bit请求,观察服务器响应,如果响应匹配调试器的响应bit,则判定为调试器
  • 反调试
      若判定为调试器,则不进行释放socket句柄操作,这样对于只接受单连接的服务器,本地调试器无法再连接该服务器,也就无法继续调试,如GDB的gdbserver、IDA的android_server。某些特殊调试器甚至存在允许关闭自身的指令,因此可以通过发送特定bit请求使服务器关闭。这种方式对于接受多链接的服务器无效。

一次典型的gdb协议通信如下:

Send               Rreceive
+               => qSupported:multiprocess+;swbreak+;hwbreak+;
QStartNoAckMode => +$OK

调试器端口检测技术总结:
优点:端口协议测试这种检测方式,对于尚未发起调试攻击过程有一定阻碍作用
缺点:无法对已经建立的调试过程产生影响

硬件可调试性检测

  这部分是对设备是否开启调试功能及APP自身是否开启调试功能的这类环境变量进行检测,包括如下字段:

init.svc.adbd      adbd是否运行
persis.sys.usb.config    usb是否连接
sys.usb.config      。。。。
sys.usb.state      。。。。
ro.debuggable      设备是否可调试
development_settings_enabled   是否开启开发者模式
FLAG_DEBUGGABLE    app是否可调试
isDebuggerConnected    JDWP调试器是否连接(dalvik/art)

  其中ro.debuggable需要设备拥有Root权限才可修改,开启后所有App均处于可调试状态,无论App本身的设置,FLAG_DEBUGGABLE则是App自身对Java层可调试性的配置,Release版会自动设为False

进程调试状态检测

  C层调试器在连接后,调用到系统调用ptrace,这个过程会留下一些痕迹,最明显的是/proc/pid/status中的TracerPid字段,该处存放调试器的进程ID。该标记可由本进程、父进程、子进程读取。同理/proc/pid/stat第二个字段会在本进程在调试器中暂停时被系统置为T/t,但由于本进程已经暂停,该标记只能由父进程或子进程读取。类似的还有/proc/pid/wchan的ptrace_stop标志。
  上面这些仅仅是针对子进程,然而linux支持只对某个线程做调试,这样就可以绕过上面的检测,因此这里需要遍历所有子进程并检测标志位,由于调试器附加进程后会写进程和所有子线程的标志位,因此无需对/proc/pid/做单独检测,目前计划采用fork子进程方式监测如下位置

/proc/[pid]/task/[tid]/status TracerPid: [pid]
/proc/[pid]/task/[tid]/stat T/t
/proc/[pid]/task/[tid]/wchan ptrace_stop

  另一个检测点是ptrace的PTRACE_TRACEME,对于App进程该语句会让zygote附加调试自身,由于只能被一个调试器调试,因此其他调试器无法继续调试本进程。而如果该语句执行失败说明有调试器优先zygote附加本进程。
作为辅助检测点,检测isDebuggerConnected及 jni层的dalvik/art实现dvmDbgIsDebuggerConnected/Dbg::IsDebuggerActive

断点检测

  在进行调试时攻击者经常下断点以便拦截到代码执行或数据抓取,因此对通过断点检测到调试器存在,断点类型如下

  • C层软件断点
      软件断点是通过修改特定指令所在的内存数据为特殊指令,使进程在执行到该处时因为断点指令或异常而中断在调试器中。因此可以通过比对代码与文件的数据比较检测到断点的存在(也可能是hook或其他情况)。为了提高速度,先暂存文件数据的哈希值,每次检测将该哈希与内存哈希进行比较,若不同再检测是否存在断点。下面是常见的软件断点机器码模式(参照GDB/LLDB/IDA等调试器的实现)
ARCH  SWBP(little-endian)
Arm   01 00 9f ef
arm-eabi  f0 01 f0 e7
thumb  01 de
thumb2  f0 f7 00 a0
mips   0d 00 05 00
arm64  00 00 20 d4        (aarch64)
x86/x64  cc

  这里特殊的一点是软件断点可以通过异常实现,因此理论上写入无效指令触发异常即可,无需一定匹配上述模式

  • C层硬件(观察)断点
      硬件断点是处理器提供的用于调试的一组寄存器功能,通过设置寄存器实现在内存处读、写、执行时中断到调试器。因此通过检测特定寄存器的数据,可以检测是否被调试。(暂不实现)

文件系统监控检测

  调试器在附加进程后会读取该进程/proc/pid下的一些数据,其中一些行为可明显区分出调试器行为

Gdbserver  读取/proc/pid/mem 读写内存
Android_server 读取/proc/pid/maps 获取模块信息

反调试

Java虚拟机反调试

  原理:Android Java层调试采用JDWP调试协议,而该协议实现于libart.so/libdvm.so中,远程调试过程是一个网络通信过程,从源码分析可以发现JdwpState是一个函数指针数组,部分结构如下:

    void *accept;   // 服务端接收远端调试连接
    void *establish;  // 建立调试器服务端
    void *shutdown;  // 结束进程
    void *processIncoming; // 处理远端发来的调试消息

  调试过程:establish->accept->processIncoming->processIncoming->…->shutdown;每当用户下断点时,主机上客户端(jdb)会将该请求发到移动端的调试器服务端(libdvm),调用processIncoming处理该消息。因此只要将processIncoming指向自定义回调即可检测到JDWP调试过程,而使其指向shutdown则会在下次调试事件时退出进程。JDWP调试分为adb和socket两种方式,因此有2套JdwpState对象,分别处理通过socket直接进行JDWP调试和通过adb桥进行JDWP调试的通信逻辑
  实现:dalvik虚拟机实现在libdvm.so中,而art虚拟机实现在libart.so中;libdvm.so导出dvmJdwpAndroidAdbTransport/dvmJdwpAndroidSocketTransport函数,可得到getState函数指针,通过调用getState()得到JdwpState结构;libart.so则导出art::JDWP::JdwpAdbState/art::JDWP::JdwpSocketState虚表指针,也是JdwpState类似结构。利用该方式实现Java调试检测:

  • 将processIncoming设置为自定义回调,可以检测到启动以后adbd尝试连接app jdwp端口的行为,adbd只有打开开发者模式以后才会存在。调试器一旦连接则会经过processIncoming,但经过processIncoming的连接不一定是调试器行为,也可能是adbd的通信
  • 由于Android7.0增加了系统保护机制,使得dlopen对某些敏感动态库操作失败,因此采用Hook read函数,检测jdwp协议握手字段JDWP-Handshake。若sosafe模块加载晚于jdwp调试过程建立,该法无效
    Java虚拟机反调试技术总结:
    优点:利用Android虚拟机自身原理进行反调试,隐蔽性和实用性较强,使调试器拒绝服务
    缺点:Android7.0开启了系统动态库保护机制,无法使用获取到私有函数,无法利用这种方式

JNI层反调试

  由于JNI调试器(gdbserver/android_server/…)最终通过内核ptrace与应用程序交互,在检测到调试器直接退出进程是明智的选择,这里检测到调试器后的执行延时退出,使用内联汇编的exit函数或异常机制实现退出,避免被很容易的检测到。后期加入擦除回溯栈之类的保护措施,防止被调试器跟踪到关键代码

挂钩检测

常用HOOK工具包名检测

  一般挂钩是通过注入和Hook框架工具,取得目标进程控制权,然后通过inline hook/got hook等方式进行挂钩。因此收集Xposed/Substrate等工具安装信息作为最简单的检测方式,包名分别为de.robv.android.xposed.installer com.saurik.substrate。这里先通过java层获取package那么,如果失败则通过执行pm list package命令从native层直接获取所有安装包名,避免被拦截到

系统文件改动检测

  Xposed/Substrate这类工具通过修改系统文件的方式,尽可能将自身在最早的时机加载:

  • Substrate通过替换liblog.so,将自身加载时机提前到app_process运行前,liblog.so加载前的时机
  • Xposed通过替换app_process,将自身加载时机提前到app_process执行时
      通过检测替换后文件特征,确定系统文件是否被修改过,即可得知系统是否安装Hook框架;由于app_process可能有/system/bin/app_process /system/bin/app_process32 /system/bin/app_process64共存的情况,所以取当前进程/proc/self/exe指向的app_process文件为准

进程模块检测

  Xposed/Frida这类工具通过在zygote中加载模块实现某些功能,由于zygote是所有App进程的孵化器,因此zygote注入的模块自然的被App进程继承。通过检测zygote进程和App进程的加载模块(/proc/self/maps),可以检测是否被挂钩和注入,已知Android平台挂钩/注入工具模块名如下

 ProbeDroid  libProbeDroid.so
 Frida   frida-agent.so frida-gadget.so
 Cydia Substrate libsubstrate.so libDalvikLoader.so libAndroidCydia.so libAndroidLoader.so *.cy.so
 Xposed   XposedBridge.jar
 Dynamorio  libdynamorio.so

  由于某些是开源项目,模块名可以人为修改,因此在模块名检测的基础上增加对二进制模块文件的匹配,其中.cy.so是用于substrate的自定义注入模块

Java层调用栈检测

  在Hook框架生效时,如果当前线程恰好在Hook框架调用范围内,会在线程回溯栈产生Hook框架自身的函数和类名:

 Xposed   de.robv.android.xposed.XposedBridge
 Cydia Substarte com.saurik.substrate.MS$2.invoked

  经过分析,这种方式并不可取,因为要求当前线程已经处于被hook框架调用的代码中,检测率极低且结果也不可靠

Java类成员函数属性校验

  由于常见的对于Java函数的挂钩方式是修改Java函数为native函数实现,因此通过检测各个Java类成员函数是否为Native属性判断是否存在Java层挂钩。在检测前提前下发一个包含所有非native函数(包括所有系统和app的类成员函数)的数据表,在检测时刻比对当前所有已加载类的native函数存在该表中的情况,即为存在挂钩。(由于App可随时加载dex,且每次检测只能获取到当前已load的class,因此下发非native表比native函数表可靠)。这种方式目前只实现了Dalvik部分,Art由于各版本私有函数存在差异,比较复杂。
  这种方式利用的是JDWP通信接口,以Dalvik为例,dvmDbgGetClassList函数可以获取当前所有已加载类,dvmDbgOutputAllMethods函数可以获取到所有类成员函数信息,通过这两个函数就可以遍历所有已加载类成员函数。

加载模块内存校验

  由于sosafe模块加载时机可能晚于挂钩时机,因此需要比对文件和内存模块的区别,判断是否存在Jni层挂钩。通常hook框架使用inline hook/got hook,因此会修改elf代码段和got表,这样就会产生和文件不一致的情况。通过检测文件和内存哈希监测是否存在Jni层hook,即使是Java层Hook,仍然会在Native层有Hook行为,因此这种方式可以检测Java/Jni层Hook。具体操作如下:

  1. 启动时初始化模块表,记录elf文件的.text段哈希
  2. 在Hook检测时,获取内存elf的.text段哈希,若不同则判断是否为几种情况之一:软件断点 /Inline Hook/文件修改,若发现inline hook需要判断跳转点是否位于厂商模块/系统自带模块/百度安全组件,不是则记录
  3. 在Hook检测时,枚举所有got表元素,检查指针所属模块,不是厂商模块/系统自带模块/百度安全组件则记录

注入检测

常用注入工具进程名检测/二进制匹配

检测常见注入工具的服务器进程,如Frida-server adbiserver

检测环境变量注入

检测LD_LIBRARY_PATH LD_PRELOAD是否存在不合法路径

加载模块名检测/二进制匹配

与挂钩检测相同

常用注入工具端口检测

Frida-server常用27042端口通信

ROOT检测

常用ROOT工具路径包名检测

  • Root工具:利用漏洞下载su到本地,如360一键root
  • 刷机工具:通过刷入Root过的系统镜像实现Root,如刷机大师
  • 权限管理工具:在已获得Root权限的机器上管理Root权限
  • 其他工具:需要Root权限执行的app,如hook框架

常见su文件路径检测

  设备Root后,一定在本地存在su文件以便提权,因此可以通过检测su存在判断设备是否root。Su文件路径选择常见路径+环境变量$PATH,su文件名选择收集到的su文件名。后期可能加入检测su文件是否可执行的逻辑,而由于是否成功获取root权限取决于权限管理器,因此可能给用户弹窗或获取失败的情况

常见路径        常见su
/sbin/                      su          
/vendor/bin/                us          
/system/sbin/               .su          
/system/bin/                .suv          
/system/xbin/               .suo          
/system/usr/                .uv          
/system/bin/.ext/            au          
/system/bin/failsafe/        k.sud          
/system/sd/sbin/            ku.sud          
/system/sd/xbin/            .rgs          
/system/sd/bin/             .tmpsu          
/system/usr/we-need-root/   daemonsu          
/system/sd/                 kinguser_su"          
/system/                    cm_su          
/data/local/                          
/data/local/bin/                      
/data/local/xbin/                     
/data/local/sbin/   

常见系统目录权限修改检测

  未Root的手机某些文件夹是拥有r--或---权限的,如默认情况/data文件夹不可读,而在root后这些文件夹属性会发生变化,利用这个特性可检测是否root,默认只读目录:

/data             /vendor/bin   /system/bin       /etc       
/                 /sys          /system/xbin      /proc      
/system           /sbin         /system/sbin      /dev       

虚拟机检测

检测设备特征

某些模拟器会在以下系统属性中存在特征,比如nox,goldfish, ttVM….

ro.build.description
ro.hardware
ro.product.brand
ro.product.device
ro.product.manufacturer
...

有些模拟器采用默认手机号:

15555215554
15555215556
15555215558
...

有些模拟器采用固定hardwareid

000000000000000
e21833235b6eef10
012345678912345
...

有些模拟器是基于qemu/virtualBox,因此系统目录存在特殊文件:

/dev/socket/genyd
/dev/socket/baseband_genyd
/dev/socket/qemud
/dev/qemu_pipe      
...

1

主题

19

帖子

95

积分

用户组: 小·技术宅

UID
2054
精华
0
威望
2 点
宅币
72 个
贡献
0 次
宅之契约
0 份
在线时间
9 小时
注册时间
2016-11-10
发表于 3 天前 | 显示全部楼层
干货,码住
最近刚好有看了点安卓的东西

本版积分规则

QQ|申请友链|Archiver|手机版|小黑屋|技术宅的结界 ( 滇ICP备16008837号|网站地图

GMT+8, 2019-1-19 06:02 , Processed in 0.100439 second(s), 34 queries , Gzip On.

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表