逆向sgavmp篇

逆向sgavmp篇

sgavmp篇

觉着降生

也许在业界中sgavmp算是一个比较高的点了；它让很多人望而生畏，特别是对于我这种菜鸡来说，它简直是一个无法跨越的屏障。和猫一样人也对一些事物充满好奇，但往往催生你欲望的不是好奇而是外界事物。前不久有一个阿里安全部的面试邀请，记得最后一面的时候面试官几次问到了我他们avmp的实现原理，在当时我几乎除了听过其名字外对此一无所知，这便燃起了我的好奇心。

聊到sgavmp就不得不聊聊liteVM，不过我并不想在这里过多的描述它，我会单独在写一篇liteVM的文章。在逆sgavmp早期litevm并没有引起我的过多注意，从sdk中我知道有它的存在，但是它是怎样的存在就不得而知了；然而你想逆sgavmp你就不得不过litevm这一关，它出现的机率不亚于sgavmp；早期的时候它经常会乱入，随着我们把坑慢慢填满，才终于发现原来litevm是这样的一个存在，它作为一个附属大礼包免费送给你了。

逆向sgavmp过程是极其煎熬和富有挑战的，因为它确实有难度；做逆向的人应该最喜欢流水式的程序，你不用思考，很多时候静态分析就解决了大半工作，剩下的部分只需看着伪代码在模糊点调试一下即可。困难和恐惧来自未知，当程序打破流水式的时候，你会发现即使有伪代码你仍看不懂，程序不在有连续性，它的走向是未知的；在未知中给你添加几个小黑盒，黑盒隐藏了大部分逻辑，当你兴高采烈的弄明白黑盒子时，你发现原来它只是个盒子，盒子里面的东西才是你想要的；当你再次高兴的把里面看清楚时，你发现原来你想要的东西还是在外面，你永远不会知道下一步等待你的是什么。代码风格好的程序也是逆向者的最爱，因为数据结构清晰，我们几乎不用动脑就能轻松的还原；如果编程者刻意隐藏结构之间的关系，让本来存在直接关系的结构变成间接关系，那想必会增加逆向难度。一个巨大的数据结构也会增加逆向的难度，想想如果你去逆向linux内核（假设没有源码），想还原task_struct结构你需要花特别多的力气，一个是它自身大，另外是和它存在关系的结构也非常巨大，想正确的还原每个结构的每个属性还是比较难的。

追寻正法

       对于sdk类或者插件类程序，我并不喜欢直接调试或者逆向它的宿主程序，原因有三；一、sdk或者插件本身就已经很复杂，和宿主融合到一起后会更加复杂，无疑增加逆向程成本，二、需要找到sdk或者插件的调用入口点，三、需要绕过宿主的对抗。当一个宿主程序包罗万象大的夸张的时候，你千万别高估自己的定位能力，也千万别高估自己的耐心。

       对抗sdk或者插件我的思路是从最小化集成到完全集成，通俗讲就是你来作为它的宿主，你负责它生命周期管理，需要什么集成什么，我也确是这么做的。

       你的宿主可以很轻量化，并且能随时定制，仅提供你所需要的功能即可。

下图是我定制的宿主的view，它提供了我所需要的功能。

多道

sgmain、sgavmp、sgsecuritybody等前身是百川sdk下的无线保镖，最早由聚安全开发，同时对外对内都提供安全能力，对外提供低版本的5.x，对内提供更具安全能力的6.x版本；5.x版本不具备avmp、litevm功能，也不具备其他插件的能力。

如某内部app集成了无线保镖，它将拥有如下图所示部分（具体看实即集成）：

就sgavmp来说，libsgavmp.so是一个压缩包，是一个完整的apk，而带版本号的so才是真正的so文件。

这些插件中，sgmain是主插件，其他插件强依赖这个插件，sgmain对其他插件可能存在弱依赖关系，也就是说sgmain可以独立运行，但其他插件不可以，sgmain插件的某些功能被单独拿出实现成了其他插件，因此对其他插件可能存在弱依赖。

sgmain插件：