自己的一个demo随手就上传加固了一下，然后开始分析,是免费版的，应该不少人已经分析过了

dex加固，可以使用frida-dexdump可以直接dump下来

可以看到加载了SecShell进行脱壳调用，这个libSecShell.so是32位的

export列表中看到了JNI_Onload，但是是加密的，分析不出来，修改代码的话一定会调用mprotect，在mprotect处交叉引用，找不到调用，于是猜测可能是svc调用，用脚本跑了一下，发现了mprotect，脚本是之前论坛上看到的

在这里交叉引用发现都在sub_C0C30里调用
用frida去hook这个函数

可以发现经过mprotect一次后，对应地址的值发生了变化

用memdumper64（github上有，速度挺快） dump出so，用Sofixer修复so文件

打开跳转到JNI_Onload（0x1E5DC）

发现ida没有自动创建函数，按p会报错The function has undefined instruction/data at the specified address

用idapython强制创建函数

随便打开一个函数，发现是这样的

cat /proc/18395/maps | grep e49看一下这个地址

发现是libc.so，把这个libc.so拖出来放到ida分析
计算一下0xE497F9DD-0xe494b000 = 0x349dd
看一下libc.so，所以这个函数就是strcpy

感觉可以写一个idapython脚本去修复一下
然后就写了一下，先从libc.so中提取函数地址和函数名

效果：

然后从.data段中找到相应地址，相减得到libc.so中地址的偏移，然后对应起来，去修改函数名

效果如下：

这样就容易分析得多，其实不止libc.so，还有libdl.so等，不过这个函数少，就手动恢复了

地址：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，发现用了sub_12B94函数大量解密字符串，

于是采用frida hook这个函数，打印出相应的信息（比如解密后的函数，返回地址），本来是只想解密字符串，但是字符串的解密顺序其实帮助了分析流程的过程，解密字符串的函数不止一个，具体的可以看看附件，写得很乱，需要注意的是这个hook的时机应该是在JNI_Onload解密之后，不然可能会出问题

先执行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：创建了线程（没执行到），验证了签名

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！