0


Android hook、检测及对抗相关

frida——hook 内存访问断点

    环境:app:arm64      python 3.10   frida 15.2.2   

    简单的内存访问断点代码,可能还有些bug,根据apk需要自己改,下文为在apk中指定的地址调用函数时内存断点才被激活,以下需要改动:

            var str_name_so = "********";                           // 需要hook的so名
             var n_addr_func_offset = ********;                   // 需要hook的函数的偏移
             var ret_addr = *******;                                     //hook函数的返回地址

            process = frida.get_remote_device().attach('*****')  # 进程名

    frida hook原理:通过python代码将jscode插入到指定函数的起始位置,通过b x16跳转到插入代码,首先执行Interceptor.attach,离开被hook函数时执行onLeave:function,app执行过程中触发异常时进入Process.setExceptionHandler,剩余根据自己使用情况可精简。

    details.address(出现异常的地址)

    details.memory.address(访问了哪里触发异常)
import frida, sys

jscode = """
Java.perform(function(){
    var str_name_so = "libVuforia.so";                   // 需要hook的so名
    var n_addr_func_offset = ********;                   // 需要hook的函数的偏移
    var n_addr_so = Module.findBaseAddress(str_name_so); // 获取so模块基址
    var ret_addr = *******;                             //hook函数的返回地址
    
    send('n_addr_so:' + n_addr_so.toString(16));
    var addr = 0;             // 内存断点地址地址
    var size = 0x8c;          // 内存断点大小
    var bpt_addr = 0;         // 需要下断点的地址
    var o_code = 0;           // 原机器码
    var tmp = 0;
    
    //输出bpt_addr处的硬编码
    //console.log(hexdump(bpt_addr, {offset: 0,length: 48,header: true,ansi: false}));
    
    // 需要hook 的地址 = 模块基址 + 函数偏移
    var n_addr_func = parseInt(n_addr_so, 16) + n_addr_func_offset; 
    // 创建NativePointer对象
    var ptr_func = new NativePointer(n_addr_func);

    // 处理异常回调函数
    Process.setExceptionHandler(function(details){
        // 输出异常信息
        send("!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");
        send("触发异常偏移地址:" + (details.address - n_addr_so).toString(16));
        send("常规断点偏移地址:" + (bpt_addr - n_addr_so).toString(16));
        send("异常类型:" + details.type.toString(16));

        // 判断异常是否由正常断点(0xcc)触发
        if(details.type == 'illegal-instruction'){
            send("常规断点触发");
            
            
            // 修改为可写权限
            var ret1 = Memory.protect(ptr(bpt_addr), size, '-w-');
            if (ret1 == false){
                send("设置软件断点后内存断点权限 修改 失败");
                return false;
            };
            // 写回原机器码
            bpt_addr.writeU64(o_code);
            
            
            // 权限改回
            var ret2 = Memory.protect(ptr(bpt_addr), size, 'r-x');
            if (ret2 == false){
                send("设置软件断点后内存断点权限 改回 失败");
                return false;
            };
 
            send("常规断点取消");
            bpt_addr = 0;
            
            // 再次修改内存断点区域权限
            var ret3 = Memory.protect(ptr(addr), size, '--x');
            // 权限修改失败则输出提示
            if(ret3 == false){send(addr.toString(16) + "处权限修改失败:" + ret3.toString(16))}
            else(send(addr.toString(16) + "处内存断点再次激活:" + ret3.toString(16)));
            return true;            
        };
        
        
        
        
        
        
        // 判断异常类型是否是访问异常
        if(details.type == 'access-violation'){
            send("异常操作类型:" + details.memory.operation.toString(16));        
            send("异常访问的地址:" + details.memory.address.toString(16));
            
            
            //  访问  的位置是否在范围内
            if(details.memory.address - addr <= size && details.memory.address - addr >= 0)
            {
                //  当前指令是否在文件的代码段
                if(details.address - n_addr_so > 0 && details.address - n_addr_so < 14276064)
                {
                    send(details.address - n_addr_so);
                    send("目标地址已找到:" + (details.address - n_addr_so).toString(16));
                    send("触发异常的地址:" + details.address);
                    send("异常访问的地址:" + details.memory.address);
                    send("内存访问断点地址:" + addr);
                    send("基质:" + n_addr_so);
                    return false;
               }
               else
               {
                    send("########超出文件的访问地址##########");
                    console.log(hexdump(details.address, {offset: 0,length: 48,header: true,ansi: false}));
                    return false;
               }
               
            }  
            
            if(details.memory.address - addr > size || details.memory.address - addr < 0 )
            {
                
                // 计算需要在哪里下软件断点
                bpt_addr = ptr(parseInt(details.address, 16) + 4 );
                
                // 保存原机器码
                o_code = bpt_addr.readU64();
                
                
                // 修改为可写权限
                var ret4 = Memory.protect(ptr(bpt_addr), size, '-w-');
                if(ret4 == false){
                    send("常规断点设置失败:写入异常失败!");
                    return false;
                };
                
                // 写入异常
                bpt_addr.writeS64(0xcccccccc);
                
                // 权限改回
                var ret5 = Memory.protect(ptr(bpt_addr ), size, 'r-x');
                if(ret5 == false){
                    send("常规断点设置失败:还原权限失败!");
                    send(bpt_addr);
                    send("发生异常的地址:" + (details.address - n_addr_so));
                    
                    return false;
                };
                
                send("设置常规断点");
                // 将内存断点处的权限改回来
                if(details.memory.operation == 'read'){
                    var ret6 = Memory.protect(ptr(addr), size, 'r--');
                    if (ret6 == false){
                        send("设置软件断点后内存断点权限修改失败");
                        return false;
                    };
                }
                else if(details.memory.operation == 'write'){
                    var ret7 = Memory.protect(ptr(addr), size, '-w-');
                    if (ret7 == false){
                        send("设置软件断点后内存断点权限修改失败");
                        return false;
                    };
                }
                else{
                        send("不应该出现执行的情况" + details.memory.operation);
                        return false;
                }
                send("内存断点暂时失效");
                return true;
            };          
        };        
        
        send("未知错误");
    });
        
        
    // 截获对函数的调用
    Interceptor.attach(ptr_func,{ 
       
        // onEnter 回调函数:该函数在被hook函数之前执行,其参数args可用于读取或修改目标函数的参数
        onEnter: function(args) {
        
            //判断函数调用 被hook函数执行后ret的地址
            tmp = this.context.lr - n_addr_so;
            if(tmp != ret_addr) return true;
            send("目标调用");
            
            // 从寄存器中取出要下内存断点的地址
            addr = parseInt(args[7], 16) + 376;
            
        }, onLeave: function(retval){
            if(0 == addr ) return true;
            
            send("--------------");
            // 修改目标地址的权限
            var ret = Memory.protect(ptr(addr), size, 'x');
            // 权限修改失败则输出提示
            if(ret == false){send(addr.toString(16) + "处权限修改失败:" + ret.toString(16))}
            else(send(addr.toString(16) + "处权限修改成功:" + ret.toString(16)));
            
        }
    });
});
"""
def printMessage(message, data):        # js中执行send函数后要回调的函数
    if message['type'] == 'send':
        print('[*] {0}'.format(message['payload']))
    else:
        print(message)

process = frida.get_remote_device().attach('*****')  # 进程名
script = process.create_script(jscode)  # 创建脚本
script.on('message', printMessage)      # 加载回调函数,也就是js中执行send函数规定要执行的python函数
script.load()                           # 加载脚本
sys.stdin.read()

**Inline-Hook和SandHook **

    都是基于inline-hook基础,通过修改函数的跳转地址实现hook,br  mycode_addr;据说inline主要用于32位hook,sandhook主要用于64位hook。

PLT/GOT hook

    全局偏移表(GOT)和动态链接表(PLT),主要通过解析so文件,将导出表函数地址替换为自己的native函数地址实现hook,导入表hook本质上和导出表hook原理相同,只不过hook的是系统so或者其他so的导出表,优点是相比于Inline-hook稳定性更好,缺点是只能hook导入导出表

Unicorn hook(没太看懂,貌似很牛逼)

    跨平台的模拟框架,通过模拟不同平台的cpu实现,内部并没有函数的概念,只是一个单纯执行指令的cpu,可以实现指令级hook

** Xposed hook**

** **原理:Java函数执行时会调用到dvmCallMethodV判断是Java层还是native层函数,xposed通过修改dvmCallMethod的accessFlags值来欺骗虚拟机为调用native层函数,再将nativeFunc指针指向自己实现的native方法();

            Android版本高于5.0时,使用xposed需要刷入框架,替换系统的

    1.重写系统的Zygote,加入一段代码,所有从zygote fork出的进程都注入XposedBridge.jar ,使用XposedHelpers.findAndHookMethod 方法hook系统函数。

    2.通过反射机制找到Method,判断安卓版本,初始化参数与返回值类型。

    3.修改函数指针。

万物皆可 Hook,探究 Xposed 框架 Hook 原理 - 知乎 (zhihu.com) (hook代码及xposed检测)

Frida hook

** **原理:和Xopsed类似,也是欺骗虚拟机执行自己的native函数,修改accessflags,函数指针,函数执行模式。

    1.函数是否 为AOT 编译的热点函数,是则直接执行。

    2.Java层函数调用,未经过AOT编译,ARTMethod 的值为artQuickToInterpreterBridge(快速编译代码的入口点),从二进制执行模式(AOT)切换到边解释边执行(JIT)模式

    3.Native层函数调用,未经过AOT编译,ARTMethod的值为artQuickGenericJniTrampoline 

    所以Frida会更改ARTmethod结构中的:
        access_flags_(执行的是Java层还是Native层)
        entry_point_from_jni_
        art_quick_generic_jni_trampoline
        artInterpreterToCompiledCodeBridge
    检测:frida开启的端口、被注入进程中是否存在frida-agent-32.so模块、检测进程是否有frida-server、探测端口通信D-bus协议。

Xposed 与 frida 的区别:

    Xposed是通过修改字节码实现hook,因此只能搞Java层函数,且安装需要root权限,稳定性较好。

    frida是通过向程序注入JavaScript脚本,动态二进制插桩实现,所以native层函数也可以搞,不用root,上去就是干,但是稳定性较差,没事就崩给你看。

APK简单对抗

1.Java层混淆:jadx -> 工具 -> 反混淆

2.资源加密:特点 直接用Android killer打开,反编译失败,资源文件报错;在手机MT管理器中更改代码。

3.签名校验:

     java层:关键API getPackageManager(获取包管理器)  getPackageInfo(获取包信息)  packageInfo.signatures(包签名信息)   

    so层:先找到执行签名校验的so文件,拖入IDA,查看导出表,check_sign jni_onload(动态注册) java_(静态注册)等关键函数,分析校验逻辑更改so或者java层文件。 

通过Java反射机制调用签名校验Java反射机制详解_杨 戬的博客-CSDN博客。

PackageInfo packageInfo = getPackageManager().getPackageInfo(

            getPackageName(),

            PackageManager.GET_SIGNATURES);

Signature[] signs = packageInfo.signatures;

4.模拟器检测:检测蓝牙,电话信息权限,已安装的APK,CPU框架等。

5.类抽取:将dex文件中的函数指令转为NOP,程序跑起来时在so层填充该函数指令。

正向还原:第一种是通过读取

/proc/<pid>/maps

文件获取加载的DEX文件地址,然后对DEX文件进行解析,找到NOP指令进行还原;第二种方法就是通过Hook系统函数(最简单的就是

dexFindClass

函数)然后进行指令还原。

逆向还原:最终解密出的Java函数还是要在内存中的,使用IDA动态调试拿到原本的函数字节码,填充回dex,或者同样hook系统函数,等程序填充后在dump dex。

dex方法还原:

    使用 010Editor 找到该方法的类(在class区段中找)

     选中并打开类数据标签(2),打开方法列表(3,下图中有两个列表),在列表中找到参数类型与返回值类型与咱们的目标函数相同的方法,此次实验目标为public void org.a.a.m.c.a(char[], int, int)方法。![](https://img-blog.csdnimg.cn/c3c16debb3bc4e89ae68c9540fc0c79f.png)

     按照下图打开选项卡,找到方法对应的16进制数据,进行填充或者删除,最后还需要更改dex文件头中的SHA1(或者其他的?)校验信息。![](https://img-blog.csdnimg.cn/4feb2bc82dc44316b49b3ee853c736f8.png)

6.第四代VMP壳:程序启动时,将加密后的dex文件解密,加载到内存;在内存中创建一个虚拟机,将dex转换为vmp虚拟指令集;再将指令集转换为Dalvik字节码执行(用到那个dex中的方法就解密哪个,不是一次性将dex转为Dalvik字节码)

7.函数级加密:

** **在应用程序运行时,解密函数会被调用来解密每个被加密的函数,然后将其加载到内存中,并在执行时动态解密。

    静态函数级加密:每个函数加密方式**相**同,拿到解密函数还原。

     动态函数级加密:每个函数加密方式**不**同;动态函数级加密中,每个函数使用不同的密钥进行加密,获取每个函数对应的密钥;找出解密函数,解密函数使用密钥对每个函数进行解密。

8.不落地加载壳:

** **先执行壳程序,在内存中解密程序本身的dex,在so层调用系统 libdvm.so 中的 openDexFile 函数加载内存中的dex,该函数的返回类型为int类型的cookie。

9.so加壳:

    通过加壳器对原始so文件进行混淆与加密,运行时在解密,详见 Android杂项 中的自定义linker

10.ollvm混淆:

    控制流平坦化:听起来好像很难懂,其实就是把原本直接的函数调用,前面加上各种 if 、for、switch、while等分支判断的逻辑,加大逆向分析的时间开销,函数逻辑变得混乱。
  • (1)函数的开始地址为序言的地址;
  • (2)序言的后继块为主分发器;
  • (3)后继为主分发器的块为预处理器;
  • (4)后继为预处理器的块为真实块;
  • (5)无后继的块为retn块;
  • (6)剩下的为无用块。

下图为经过ollvm控制流平坦化处理的函数

     去混淆的思路就是去除无用块及确定真实块执行的先后顺序。

    指令替换:将程序原本简单的二元运算(加 减 乘 除 异或 与 等等),替换为更加复杂的运算,但结果和原本一样(PS:纯纯有病,技术不行,cpu来凑?)

    控制流伪造:和平坦化差不多,就是 if 、for、switch、while 循环的替换,加大分析难度,让cpu更容易冒烟。

Android反调试

1.关键文件检测:改文件名。

2.调试端口检测:更改ida,frida等默认连接端口;

3.进程名检测:android_server gdbserver gdb等进程名检测;父进程名检测,桌面启动的父进程名应为zygote,hook 或修改smali

4.Java层反调试:android.os.Debug.isDebuggerConnected(),killer中搜索函数更改;xml中applicationInfo属性中添加android:debuggable=“true”。hook该函数让其返回1;

5.ptrace检测(相当于Windows中的attch):手动跟踪到ptrace函数修改返回值;编写新的ptrace函数so文件放到app的lib下并设置环境变量;hook大法,

6.TracerPid 检测:基本同上,检测/proc/self/status的TracerPid 值。不为0就是被调试了,通过修改内核文件/dev/block/mmcblk0/boot中TracerPid函数硬编码实现;程序建立子线程附加自己,如果TracerPid值为0则退出;。

7.断点检测:rtld_db_dlactivity函数:这个函数默认情况下为空函数,这里的值应该为0,而当有调试器时,这里会被改为断点指令;获取该函数地址,将其nop。

8.时间检测,单步调试陷阱:app主动设置断点,并在代码中注册断点信号处理函数,未被调试(执行断点发出信号—进入处理信号函数—NOP替换断点—退回PC),被调试,执行调试程序的处理函数,他会恢复目标处指令失败,然后回退PC,进入死循环。

9.利用ida先截获信号的特性:将关键函数放在信号处理函数中,未被执行则被调试。

10.双进程守护:主进程a,fork子进程b,b进程ptrace a的所有线程;修改安卓源码;

Java层的双进程通过xposed hook应该可以解决(xposed是通过重写zygote进程实现hook,理论上可以拦截所有Java层的操作);so层的可以在该so刚加载时就附加,然后修改fork操作(未实践)。或者编写一个so库,里面重写ptrace和dlopen函数,重写的函数里面最后在调用真正的系统函数,加载该库。

Android风控

    风险控制,为了解决和预防将要发生,或者可能发生的一些危险情况,从而减轻损失。

    注:并不完全是新内容,选读,因为近期面试遇到过不少,所以自己学学之后打算写个笔记加深一下印象。

蜜罐数据:当发现作弊以后返回的数据是非正常的数据,可能存在埋点等信息,比如在视频的随机帧中添加标识,水印等,返回错误,重复的数据。

IP限制:当一个IP请求过量或过于频繁时,返回错误数据或者蜜罐数据。

设备指纹:设备指纹的核心是使用设备的唯一识别码,就像每个人的身份证号码一样。

java函数获取:Settings. Secure / Global .getString(context.getContentResolver(),Settings.Secure.ANDROID_ID)

黑灰产通过协议逆向,实现批量注册等“薅羊毛”行为,可通过网络数据包中的设备指纹判断,是否为同一设备,短时间内大量注册账号,从而判定是否遭到黑产攻击。

App环境信息:可以通过该设备运行环境的信息,将用户划分为 可疑设备 与 黑产设备。

1.root检测:su权限,文件检测;扫描 magisk 关键字;maps检测等。

2.Hook检测:主流hook框架Frida与xposed检测上报。

3.沙箱检测:判断APK的私有路径是否为 /data/data/包名;

4.自定义rom检测:需要有手机的驱动源码才能自定义rom,通过对比md5值等检测是否存在自定义rom。

5.查杀分离:当当前设备被服务器判定为黑产时,不会立即封杀,而是延时几小时或者几天在封杀,防止黑产一次一步步摸清风控判断依据。

6.心跳包&用户行为检测:在app刚跑来就与服务器建立socket连接,每隔一段时间发送一个心跳包,如果通过单纯的逆向网络协议实现算法接口,再通过PC发送数据的话,服务端在长时间没有收到用户的心跳包后,就可以将此设备判定为黑产设备。用户通过逆向字节写的点击框架,可能没有一点多余的操作,如正常用户的滑动屏幕,点击时间间隔,屏幕点击坐标等,也可以以此作为风控判定标准。

7.异常&行为埋点:正常用户点击登入接口时,在之前肯定会打开app的登入页面,可以在登入页面设置埋点,发送特定的数据包给服务器,如果用户只发送了登入的数据包,或者发送的埋点数据不足时,可以此判定该设备为黑产设备。

Android 进程注入

动态注入

    由于Linux的进程机制,每个进程在安装后都会分配一个独享的UID,所以要想达到进程注入,需要拿到系统的root权限,之后总体流程和PC端大同小异;

获取进程pid

附加进程 :Attch(pid)

保存目标进程寄存器 :GetRegs(pid,&SaveRegister)

目标进程内申请空间 :通过mmap映射申请,与binder差不太多

写入shell :

修改PC寄存器,

执行shell。

静态注入

    通过修改ELF文件实现,

本文转载自: https://blog.csdn.net/jinganggiao/article/details/126932091
版权归原作者 Baga_Boy 所有, 如有侵权,请联系我们删除。

“Android hook、检测及对抗相关”的评论:

还没有评论