bang加固简单分析
2022-7-31 18:1:31 Author: 看雪学苑(查看原文) 阅读量:17 收藏


本文为看雪论坛优秀文章

看雪论坛作者ID：falconnnn

一
dex
dex加固，可以使用frida-dexdump可以直接dump下来。
可以看到加载了SecShell进行脱壳调用，这个libSecShell.so是32位的。
二
libSecShell.so
export列表中看到了JNI_Onload，但是是加密的，分析不出来，修改代码的话一定会调用mprotect，在mprotect处交叉引用，找不到调用，于是猜测可能是svc调用，用脚本跑了一下，发现了mprotect，脚本是之前论坛上看到的。
system call : 7d 70addr : c0783Func Name : __NR_mprotect c0 70 a0 e3 00 00 00 ef
在这里交叉引用发现都在sub_C0C30里调用。

用frida去hook这个函数。
var mprotect_cnt = 0//frida -U --no-pause -f com.testlinker.ty -l hook.jsfunction sleep(delay) {    var start = (new Date()).getTime();    while ((new Date()).getTime() - start < delay) {      continue;    }}  function hook_svc_mprotect() {    let base_svc_mprotect = Module.findBaseAddress("libSecShell.so");    if (base_svc_mprotect != null) {        console.log("base_svc_mprotect : " + base_svc_mprotect)    }else{        return ;    }    let svc_mprotect = base_svc_mprotect.add(0xC0778);//32位    Interceptor.attach(svc_mprotect, {        onEnter: function(args) {            console.log("==========================================")                        console.log("svc_mprotect: start = " + args[0] + " , len = " + args[1] + " , ATTRIBUTES = " + args[2])            mprotect_cnt += 1            console.log(hexdump(base_svc_mprotect.add(0x281B4)))        },        onLeave: function(){            console.log("svc_mprotect leave")            console.log("==========================================")        }    })}function dis(address, number) {    for (var i = 0; i < number; i++) {        var ins = Instruction.parse(address);        console.log("address:" + address + "--dis:" + ins.toString());        address = ins.next;    }}//libc->strstr()  从linker里面找到call_function的地址function hook() {//call_function("DT_INIT", init_func_, get_realpath());    var linkermodule    if (Process.pointerSize == 4) {        linkermodule = Process.findModuleByName("linker");    }else if (Process.pointerSize == 8) {        linkermodule = Process.findModuleByName("linker64");    }    // var linkermodule = Process.getModuleByName("linker");    var call_function_addr = null;    var symbols = linkermodule.enumerateSymbols();    for (var i = 0; i < symbols.length; i++) {        var symbol = symbols[i];        //LogPrint(linkername + "->" + symbol.name + "---" + symbol.address);        if (symbol.name.indexOf("__dl__ZL13call_functionPKcPFviPPcS2_ES0_") != -1) {            call_function_addr = symbol.address;            //LogPrint("linker->" + symbol.name + "---" + symbol.address)        }    }    Interceptor.attach(call_function_addr, {        onEnter: function (args) {            var type = ptr(args[0]).readUtf8String();            var address = args[1];            var sopath = ptr(args[2]).readUtf8String();            console.log("loadso:" + sopath + "--addr:" + address + "--type:" + type);            if (sopath.indexOf("libSecShell.so") != -1) {                var libnativemodule = Process.getModuleByName("libSecShell.so");//call_function正在加载目标so，这时就拦截下来                var base = libnativemodule.base;                hook_svc_mprotect()            }        }    })}function main() {    hook();}setImmediate(main)
可以发现经过mprotect一次后，对应地址的值发生了变化。
[Pixel 3::com.example.cryptotest ]-> base_svc_mprotect : 0xcfaea000==========================================svc_mprotect: start = 0xcfaea000 , len = 0xa1000 , ATTRIBUTES = 0x7           0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  0123456789ABCDEFcfb121b4  9b 66 a6 75 82 ab ba fb 1a 80 e6 75 d7 0e 7f 1b  .f.u.......u....svc_mprotect leave====================================================================================svc_mprotect: start = 0xcfb8b000 , len = 0x1f000 , ATTRIBUTES = 0x3           0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  0123456789ABCDEFcfb121b4  2d e9 f0 4f ad f6 ac 4d df f8 44 4e df f8 44 3e  -..O...M..DN..D>svc_mprotect leave====================================================================================svc_mprotect: start = 0xcfaea000 , len = 0xa1000 , ATTRIBUTES = 0x7           0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  0123456789ABCDEFcfb121b4  2d e9 f0 4f ad f6 ac 4d df f8 44 4e df f8 44 3e  -..O...M..DN..D>svc_mprotect leave==========================================
用memdumper64（github上有，速度挺快） dump出so，用Sofixer修复so文件。
打开跳转到JNI_Onload（0x1E5DC），发现ida没有自动创建函数，按p会报错The function has undefined instruction/data at the specified address。
用idapython强制创建函数。
ida_funcs.add_func(0x281B4,0x2A5CC)
随便打开一个函数，发现是这样的：
‍
.data:00085E24 DD F9 97 E4 off_85E24 DCD 0xE497F9DD ; DATA XREF: sub_DF08+8↑r
cat /proc/18395/maps | grep e49看一下这个地址.
发现是libc.so，把这个libc.so拖出来放到ida分析。
计算一下0xE497F9DD-0xe494b000 = 0x349dd
看一下libc.so，所以这个函数就是strcpy。
感觉可以写一个idapython脚本去修复一下。
然后就写了一下，先从libc.so中提取函数地址和函数名。
from idautils import *from idaapi import *from idc import *f = open("./func.txt",'w')for func_addr in Functions(0,0x5B18BC):    func_name = get_func_name(func_addr)    print(func_addr , func_name)    f.write(str(func_addr) + "," + func_name + "\n")    # f.writelines()f.close()
效果：
然后从.data段中找到相应地址，相减得到libc.so中地址的偏移，然后对应起来，去修改函数名。
from idautils import *from idaapi import *from idc import *f = open(r"CryptoTest_32\CryptoTest\lib\func.txt",'r')func_info = {}while True:    info = f.readline().strip('\n')    if not info:        break    addr, func_name = info.split(',')    # print(addr + func_name)    func_info[int(addr,10)] = func_name# print(func_info)f.close()textStart = 0xA2984textEnd = 0xC2000# textStart = 0xA2DE0# textEnd = 0xA2E04libc_dump_base = 0xe494b000for i in range(textStart,textEnd,4):    dword_ = get_dword(i)    if dword_ > libc_dump_base:        libc_func = dword_ - libc_dump_base        # print(dword_,libc_func)        func_name = func_info.get(libc_func)        if not func_name:            func_name = func_info.get(libc_func-1)  #thumb        if not func_name:            continue        raw_name_off = get_name(i)        patch_name_off = func_name + "_ptr_" + raw_name_off        set_name(i,patch_name_off)        xrefaddrs = XrefsTo(i, flags=0)        for xrefaddr in xrefaddrs:            raw_name = get_func_name(xrefaddr.frm)          #拿到函数原名称            patch_fun_addr = get_name_ea_simple(raw_name)   #拿到函数地址            # print(get_func_name(xrefaddr.frm))            if raw_name and patch_fun_addr:                break        if raw_name and patch_fun_addr:            patch_name = func_name + "_" + raw_name            print("patch_name : ",patch_name)            set_name(patch_fun_addr,patch_name)        print(dword_,func_name)
效果如下：
这样就容易分析得多，其实不止libc.so，还有libdl.so等，不过这个函数少，就手动恢复了。
三
init_array
地址：0x11720
sub_13E48：打开libc.so，通过dlsym获取了mprotect、mmap、munmap、fopen、fclose、fgets、fwrite、fread、sprintf、pthread_create函数指针。
接着跟着frida的log，程序运行到了case 2。
流程是case 2 -> case 5 -> case 4（读cmdline） -> case 1 -> case 5 -> case 4循环读取。
这里主要是记录包名的长度，存在v8里。
最终执行到case 0，读包名，然后和/system/bin/dex2oat对比，这里我包名和/system/bin/dex2oat不匹配，不进入下面的步骤（这个过程看不懂它要干啥）。
然后进入到JNI_Onload。
四
JNI_Onload

字符串解密

刚看到JNI_Onload，发现用了sub_12B94函数大量解密字符串。
于是采用frida hook这个函数，打印出相应的信息（比如解密后的函数，返回地址），本来是只想解密字符串，但是字符串的解密顺序其实帮助了分析流程的过程，解密字符串的函数不止一个，具体的可以看看附件，写得很乱，需要注意的是这个hook的时机应该是在JNI_Onload解密之后，不然可能会出问题。
function hook_decode_str(){    let base_secShell = Module.findBaseAddress("libSecShell.so");    let decode_str = base_secShell.add(0x12B94+1);    Interceptor.attach(decode_str, {        onEnter: function(args) {            console.log("=======decode_str========="+ " size = " + args[1] + " op = " + args[2]," return addr = " + this.context.lr.sub(base_secShell))            this.args0 = args[0]            this.args1 = args[1]        },        onLeave: function(){            console.log(hexdump(this.args0,{length:this.args1.toInt32()}))            // console.log(hexdump(args[0],{length:0x10}))        }    })}  function hook_svc_mprotect() {    let base_secShell = Module.findBaseAddress("libSecShell.so");    if (base_secShell != null) {        console.log("base_secShell : " + base_secShell)    }else{        return ;    }    let svc_mprotect = base_secShell.add(0xC0778);//32位    // let svc_mprotect = base_secShell.add(0x1541A0);//64位    //private native void jniLoadScriptFromAssets(AssetManager assetManager, String assetURL, boolean loadSynchronously);    Interceptor.attach(svc_mprotect, {        onEnter: function(args) {            console.log("==========================================")                        console.log("svc_mprotect: start = " + args[0] + " , len = " + args[1] + " , ATTRIBUTES = " + args[2])            mprotect_cnt += 1            console.log(hexdump(base_secShell.add(0x281B4)))        },        onLeave: function(){            console.log("svc_mprotect leave")            console.log("==========================================")                        if(mprotect_cnt == 2){                hook_decode_str()                // hook_elf_hook()                // sleep(1000000)            }        }    })}

大概流程

先执行case 0：初始化JNIEnv，解密得到com/SecShell/SecShell/H字符串

然后case8（0x29e00）：

跳到sub_13E48，获取libc.so一些函数指针，从java类获取PKGNAME = "com.example.cryptotest"，

后面在case8里的case分支干了一些不知道在干啥，好像是在配置环境

然后是case9：

调用android/app/ActivityThread类的currentActivityThread方法

调用ActivityThread对象的getSystemContext方法

调用ContextImpl的getPackageManager方法

调用PackageManager的getPackageInfo方法

获取PackageInfo对象的applicationInfo字段

获取ApplicationInfo对象的sourceDir字段

获取ApplicationInfo对象的nativeLibraryDir字段

拼接出/proc/%d/fd/%d，遍历fd找到base.apk路径

然后是case2：对小米手机进行适配

然后是case3：创建了线程（没执行到），验证了签名

case1->case10

case10：打开/proc/self/maps，找到lib/libart.so，比较是否是r-xp权限，通过格式化字符串%lx-%lx读取地址

case11：把libart.so改为可读写，两个箭头前后对比

case13：拼接出各种字符串，比如/data/app/~~yqfNRTFBNC4L6gA2oycp-g==/com.example.cryptotest-VtwyTKkuWOlQLYKSpK7Z5Q==/oat/arm/base.odex

然后到case13里面的case10，打开这个base.odex

会打开打开classes.dve进行校验

然后会执行sub_260BC，这里会调用0x4D7DC（hook_libc_so_func）,对hook部分说的那些函数进行hook，然后读classes.jar写到内存里的时候就调用这些函数进行解密（dex加载）

case4：把libart.so权限改回去

case12：弄了好多inlinehook，但是好像也没有执行（不知道是不是我系统版本过高）

具体见附件给的idb吧

dex加载

sub_1DFB0调用了com/SecShell/SecShell/H的f方法加载/data/user/0/com.example.cryptotest/.cache/classes.jar

调用com/SecShell/SecShell/H的ff加载/data/user/0/com.example.cryptotest/.cache/v1filter.jar

通过dump maps来比较加载前和加载后的差异

可以直接把这个直接dump下来，发现解析不了，有点尴尬。
于是比较一下frida-dexdump dump下来的文件，发现后面多了几百个字节，删掉就可以解析了。

inlineHook

地址：0x53E30是inline hook函数
交叉引用可以看到很多hook的地方。
比如hook了libc.so的pread64、ftruncate64、write、read、munmap、msync、__open、__openat、__mmap2。
运行的时候发现其他的hook没有触发，之后用ida动态调试了一下确实是只hook了这些，其他地方不知道是不是有啥其他办法能让我断不下来。
这些没有执行的地方就不过多分析了。
函数p208CA25EFD02F087E334CA562B3F8423：

检测

地址0x60C5C：（似乎没有执行，发现这些check函数好像都没有执行）
xposed检测，fart检测等
check_usb：0x25508
check_root：0x17D9C

其他

函数地址：0x53E30，对华为和荣耀手机进行适配
is_miuiinstaller_process对小米手机进行适配
JNI_Onload里兼容性适配：
JNI函数注册：sub_16028（通过字符串解密log很容易发现）
用ida动态调试的时候，可能会遇到函数不会自动解析成函数，在下面框框输入这段脚本，然后用createFunction函数就可以创建函数了。
def createFunction(start,end):    len_func = end - start    begin = start    del_items(start,0,len_func)         #先undefine    while len_func:        cnt = idc.create_insn(begin)        if cnt == 0:            break       #遇到比如off_31F40 DCD __stack_chk_guard_ptr - 0x31D78这种就不解析了，一般是连续的，如果不连续需要跳过，继续解析        begin += cnt        len_func -= cnt        print(len_func)      #idc.create_insn(start)    return idc.add_func(start,end)
【参考文献】分析一下梆x加固：https://bbs.pediy.com/thread-266247.htm
好像超过上传大小了，两个文件，apk传不上去，所有文件放在百度网盘：
链接：https://pan.baidu.com/s/1Wdjp431IhhoCbcICQCJRAg
提取码：kxuc

看雪ID：falconnnn

https://bbs.pediy.com/user-home-803962.htm

*本文由看雪论坛 falconnnn 原创，转载请注明来自看雪社区

# 往期推荐

1.指令级工具Dobby源码阅读

2.AFL速通——流程及afl-fuzz.c源码简析

3.文件上传和文件包含的各种姿势

4.React Native Hermes 逆向实践

5.sql注入学习笔记

6.CVE-2016-3309提权漏洞学习笔记

球分享

球点赞

球在看

点击“阅读原文”，了解更多！


文章来源: http://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458459526&idx=1&sn=11ff8eeb0e81acb9f1c3f6c0b62027e7&chksm=b18e2d0c86f9a41a84ebd66daa909439b63ffbae824b6d105ae7be166d037f72ea1dde0baf6e#rd
如有侵权请联系:admin#unsafe.sh