转:http://blog.youkuaiyun.com/eewolf/article/details/44425569
eewolf原创,转载请注明
360对dex的保护是比较好的,直接去dump内存会发现activity类都是有问题的,从dex格式而言,其DexClassDef结构体是有问题的,除了ClassId的所有成员均为0。
那应该怎么脱呢,当然360对so有加壳,我们可以对其进行脱壳后进行分析;另外,当然也可以修改libdvm来进行脱壳。
但对于一名coder而言,能否从实现角度出发呢?如果我们来实现这个功能,要如何做。
我们知道,通常加壳方案中,需要替换classloader来加载系统组件类(当然也可以用替换mCookie的方法),activity当然也是一种系统组件。那么,可以大胆猜测,360的加壳方案中,在ClassLoader的loadClass函数上是动了手脚的,来达到先修正activity类,再修错的目的。
有了这个猜测后,实现就很简单了,可以hook loadClass,在这个时机点,去dump内存,就可以得到正确的dex。
当然,如果在dvm中实现,应该可以在defineClass函数中进行实现。
eewolf原创,转载请注明
本文探讨了360对DEX文件的保护机制,并提出了一种通过Hook ClassLoader的loadClass方法来获取未被篡改的DEX文件的方法。此外还讨论了在Libdvm中的defineClass函数处进行修改的可能性。
4708

被折叠的 条评论
为什么被折叠?



