标签：android style blog http color 使用 strong 文件
By Bob Pan
国内的apk加固技术都使用了将原有的dex隐藏, 在运行时解压, 并且通过修改app的类加载器的方式实现加固. 参考: AndoridAPK反逆向解决方案：bb加固原理探寻
然而, 不管如何隐藏dex, 最终在运行时都必须释放到内存, 所以本文的思路是从内存中找到解密后的dex文件, 进而得到加固前的apk.
注意: 这个方法截止2014-07-29有效, 后续版本未测试. 由于dalvik的执行机制要求dex在内存中是连续的, 所以想办法拿到内存的coredump总是不错的选择.
更新: 某公司会对名字为gdb的程序进行检测, 请将gdb重命名, 比如hello.
注意: 如果gdb连不上对应的pid, 请尝试连接/proc/[pid]/task/目录下的tid
某公司加固的app并没有做反调试的保护. 打开app之后直接使用gdb连接, 然后用gcore, 产生core dump.
使用ps查看pid
使用gdb连接pid
使用gcore产生core dump
将产生的core.1033复制回电脑, 并使用编辑器打开, 通过类名找到dex中string-data段, 然后通过查找’dex.035’可以找到多离string-data最近的个dex头. dex文件头偏移32的整形值就是dex的文件长度. 使用dd命令可以从内存中抠出dex.
更新: 拿到的事实上是一个odex文件, 里面会包含odex的指令. 通过一个修改过的baksmali处理后可以恢复原始的dex.
更新: 修复odex的方法,
1. 将系统的/system/framework目录复制到本地的framework目录
2. 运行baksmali -x -d framework abc.odex //将输出smali文件到out目录, 请尽量使用linux
3. 运行smali out -o classes.dex //重新制作dex
通过类名找string-data段
找到最近的dex文件头(0x4f87a08)和dex文件大小0x07c0
使用dd抠出dex
这个文件是个完整的dex文件, 并且可以被dexdump直接打印
[注意: 部分内容已丢失]
通过隐藏dex确实可以让大部分静态分析工具找不到执行代码, 但是在动态运行的时候无可避免的需要将dex在内存中还原. 通过本文的方法分析其内存然后恢复dex, 更进一步可以完全恢复原始apk.
标签：android style blog http color 使用 strong 文件
原文地址：http://www.cnblogs.com/xunbu7/p/3912450.html
