360加固保关键技术浅析

逆向破解hacker2017-11-22 19:54:5910312A⁺A^-

"0 写在前边

阅读文章文中必须您有ELF和DEX文档构造等有关背景图专业知识。为防止汉语翻译习惯性不一样产生模棱两可，某些专业术语会使用英文叙述。文中常用的APK样版详细地址点我免费下载，版本号：32.1，文件大小：9,770,467字节数。

图 1

图1叙述的是电脑管家结构加固保技术规范平面图，编号表达其实行的依次顺序。除原DEX外，剩下的部件均为电脑管家结构加固保所加上。更精确点，原DEX和AndroidManifest.xml里也被加上了编码。壳ELF来自单独的so文档。图中华DEX和輔助DEX中间也有每段统计数据。

1 城门洞开迎司马

一般说来，结构加固后的APK都是添加某些干挠信息内容，毁坏反编译工具的一切正常运作。最新版的电脑管家结构加固保是个列外，壳DEX和壳ELF能够静态数据反编译。

其缘故将会有二：最先，反编译工具的逐步完善，能轻轻松松绕开至少的干挠信息内容；次之，真实有效的统计数据早已被数据加密。两者之间花活力结构没用的反编译圈套，比不上集中力量维护好关键统计数据。

各种各样APK加固方案在技术性挑选上将会各有不同，但他们常有1个相互的基础理论基本——被数据加密的总体目标统计数据任何安全性。安全性到静态数据反编译没法获取详细的总体目标统计数据。要是该基本被攻克，那麼全部加固方案都将如流沙上的摩天大楼轰然坍塌。

即然电脑管家结构加固保大门口不设防，纵然里边沒有过多能用信息内容，人们還是进到略探其到底。

1.2 DEX文档静态数据剖析

图 2

分析壳DEX文档，如图所示2。至少map item数量是18，简易测算可得到壳DEX文件大小为0x3b18，低于当今文件大小0x1d34d4。

图 3

图3如图所示壳DEX文档被添加的附加统计数据。见到反复出現的68，非常容易令人lenovo它是用0×68异或简易数据加密后的统计数据。

反编译壳DEX文档后能够得到两根信息内容。

最先在AndroidManifest.xml设定application为Com.stub.StubApp，以保证app软件启动结构加固编码最先得到实行机遇；

次之，StubApp依据显卡构架载入相对的so文档，把执行权迁移至更加安全性的native编码。在StubApp类中申明了上一百多个native涵数，只有只能好多个有效，这也算作初次释放出来烟雾弹，来个下马威。

1.3 ELF文档静态数据剖析

电脑管家结构加固保的壳ELF以单独so文档存有，文件夹名称为libjiagu.so（不一样显卡构架相匹配不一样的so文档）。壳ELF较为老实巴交，各种各样元数据都维持详细，能够轻轻松松反汇编。图4是该文档的一部分section headers统计数据。

图 4

图4如图所示的.init_arraysection在壳ELF文档偏位0x030bec储存2个函数指针，数值0x5f41和0x5f85（见图5）。显而易见两者全是Thumb命令涵数通道，但objdump.exe把他们作为ARM命令反汇编了（见图6）。只有也怪不得错误，壳ELF确实包括了二种命令，这会给动态性调节提升难度系数。主ELF则只应用Thumb命令。

图 5

图 6

再细心查询图4，还会发觉，.bmp和.mips这2个姓名和编译/连接器办理备案的section姓名有点儿区别。.compiler看上去很正统，但实际上他们3个section全是同伙的，主ELF就撒落在此地。

系统软件载入ELF文档时只不过sectionheaders信息内容，但为什么libjiagu.so还保存着？难题先搁一面，下文再表述。

2 改门换庭变新颜

依据iOSapp软件起动步骤，派生在application的Com.stub.StubApp最开始得到实行。稍稍分辨显卡构架，便刚开始载入壳ELF（见图7）。

图 7

上文上述，即然.init_array不以空，那麼其对准的涵数将最开始被执行，比JNI_OnLoad也要早一歩。

.init_array最少进行下述实际操作：

① 复位某些字符串；

② Dynamic section归零；

③ 把.bmp、.compiler和.mips三责险统计数据总体向后（高详细地址）移0×1500。那样，说来修复了每个section初始外貌；两者顺便用“任意统计数据”遮盖后边的.comment至.shstrtab每个section，大自然文档最终的section headers未能幸免。