-
-
[原创]360加固保分析
-
发表于: 2020-6-11 20:08
-
背景:
调试手机是Android 6.0的32位的手机。样本是自己写的一个经过360加固的小程序。加固时间为今年的5月份左右。
步骤：
总体来说就是分为两大步，首先是分析libjiagu.so，从中dump出第二个so，也就是解释器so，第二步就是修复分析解释器so，找到指令映射的对应关系，得出指令映射表。
第一步：
首先看一下.init_array做了什么事
可以看到这里只有一个函数，经过我的分析这里并没有做什么重要的事。
然后继续看JNI_OnLoad区域。
发现是这样子的，然后我们的静态分析就变得困难了，只能开始我们的动态调试之旅了。
通过动态调试我从JNI_OnLoad一路跟到这个重要的函数，_Z10__fun_a_18Pcj。
可以看到这个函数被混淆的非常严重。但是经过我的分析有用的分支基本只有case31和case35两个分支。这里可以说一下case31是一个反调试的分支，case35是进入第二个so的入口，别的分支有的也做了一些事，但是对于我们来说用处不大。
反调试：
我们可以在这里下断，然后跟随R0寄存器。如图
这个版本的一共有三个反调试的点，一个是符号，一个是端口，一个是时间。
此处为第一个反调试了。
我们可以在内存窗口修改指令，改成无用指令。
第一个反调试之后，两次f9就是第二个反调试的点了，也就是时间反调试。
从这个跳转进入，即为时间调试。
在这里我们只需把R0寄存器置0就可以。
还有一个是端口检测，我们只需更改ida的默认调试端口就可以了。
到此，反调试告一段落。
接下来我们继续分析，sub_5CE8为第二个so加载的关键地方。
如图，这个是ida f5的结果。
但是我们会发现一个有趣的地方。
有没有觉得这个地方与Android源码中加载so的函数有点相似。
在这个函数断下就可以dump第二个so。
但是可惜的是它并没有走这个分支，而是这个分支
sub_540C这个函数一共要解密四个部分，分别为程序头表、JMPREL、RELA、DYNAMIC。
一个循环即为一部分。我们把这四部分dump出来。
R7寄存器地址即为整个第二个so的开始地址，我们可以把整个malloc的区域全dump下来。
需要注意的是
一定要在这个循环执行完之后dump，即解密完。
在这里说一下如何修复，因为这个so没有elf_header，所以需要我们自己修复，并且把其他三部分放到原来的地方。在这里特别说一下，R7寄存器为so的开始地址，R1寄存器为此部分在so的偏移，R0为要解密的数据大小。如此，我们可以修复解释器so。
总结一下，我们把dump出来的四部分按照偏移直接覆盖到dump出来的so中就可以，因为我们dump出来的so的那四部分并未解密。但是需要注意先修复elf_header。
第二步：
按惯例来分析init_array区域，经过分析init_array区域并没有做什么重要的事情。
然后分析JNI_OnLoad，这个函数做了很多事情，最重要的就是注册stub方法和dex的加载。
Dex的加载在这里完成
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
|
|
|---|---|
|
|
感谢分享
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
暂时还没有找到好的对抗方法 |
|
|
楼主jumpout咋处理的 |
|
|
可以patch处理 但是对于参数的识别不是太友好 |
|
|
|
|
|
把整个malloc区域全dump下来就可以，然后进行so修复 |
|
|
是把四次malloc的区域dump下来吗~ 
|
|
|
那四个区域肯定要dump的，这四个区域是so文件中加密的四部分 等它解密完后dump下来 用来修复so文件 除此之外还要dump整个so文件，就是截图中这部分 AEEC0000 AEFC0000 这是完整的so文件，只不过里面其中的四部分加密了，当然，除了这四部分之外，还有别的很多部分。 |
|
|
|
|
|
|
|
|
感谢大佬~我分析的可能版本不太一样 有差别 
|
|
|
|
|
|
|
|
|
可能是dump错了地方 也可能是没有dump下来的原因 |
|
|
|
|
|
|
|
|
上面提到过，从case35可以进入第二个so |
|
|
|
|
|
|
