-
-
[原创]360无线攻防第三题详细分析
-
发表于: 2014-6-7 18:29
-
来看雪混了快一年了，由一年前的“不会汇编，不会android”的超级新手，慢慢变成了新手，这不得不感谢看雪各位大牛的无私分享！前几天偶然见到“风随雨行”大大的360无线攻防第三题粗解，很是手痒，就断断续续花了6天的时间进行了详细分析。处女贴，有什么不对的地方望大家指正！
分析文档，代码和apk均在附件中。
360crackme分析
1 概述
该crackme的核心验证程序在libqihoo.so中。这个动态库经过了加密、清除elf文件的节区信息、花指令等处理，无法直接使用IDA进行静态分析。所以需要使用动态调试。不过如果仅仅使用动态跟踪的话，是很难分析出最后结果的。所以应当想法获得正确的libqihoo.so文件，然后结合动态调试、静态分析，最终分析出验证机制。
2 破解方法
2.1 获取较为正确的libqihoo.so文件
这里之所以使用较为正确，是因为我从内存dump出来的libqihoo.so文件并不完全正确，不过核心代码均有了，只是IDA没能自动识别出export函数(malloc,memset等)，需要我们分析的时候自己加以判断，只要熟悉这些函数就很容易判断出来。
获取so文件的方法很简单：使用动态调试附加上crackme之后，运行几次确保so已经加载到内存，然后ctrl+s查看so在内存中的起始位置，再到hex-view窗口中dump出这段内存，另存为libqihoo.so，然后另起一个IDA静态分析即可。IDA分析后的可以发现在Function widows有了我们关心的JNI_OnLoad和verify函数：
如图所示：
2 开始分析
通过分析发现JNI_OnLoad函数将JAVA层的verify函数同so中的verify函数进行了关联。所以我们直接开始分析verify函数即可。Ps:方便大家查看，我将我分析过程中提取的关键代码也放出来，在360crackmeARMcode.c中，大家可以参照着看，那里面有详细注释。其中逻辑简单的我保留了汇编代码，逻辑复杂的就手工转换成了c代码。
2.1 JAVA层传递的参数
JAVA层传递三个参数username, emailaddr, serialNum。这三个参数均为String类型。
2.2 so文件的花指令模式
Libqihoo.so中加入了大量的花指令，这无疑增加了逆向分析的工作量。不过只要理清了它的花指令模式，我们完全可以一劳永逸地解决这个麻烦。它的花指令模式如下：
typedef struct inputInfo{
char *username;
char *emailaddr;
char *serialNum;
}inputInfo;
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
看楼主这么卖力的，俺凑个热闹
 先上个修复图，不明白的看下elf文件结构。  其实这个修不修复没啥影响。就未修复的来说，ida 静态加载虽然会弹错，但导出函数能正确识别，只是不能区分有些section。看jni_onload, verify就知道是被加密了，那前面肯定有个解密函数。翻翻ida能识别的代码，大概齐__gnu_armfini_26就是你想要的解密。 当然修复了更直观，直接可以看到 __gnu_armfini_26x 在.init_array section。 再说下另外一个问题，动态加载的时候根本木有还原。section header table没被破坏，所以加载器能够正确识别。 |
|
|
感谢指点。我先消化消化~
|
|
|
|
|
|
|
|
|
额，我静态分析搞定部分了 ~~就是有点费时费力
 ~ 不过还是跪求下断点方法~
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
