-
-
[分享]对某茅台MK-V参数的逆向过程的补充
-
2024-3-22 11:41
20345
-
在之前的帖子里记录下逆向某茅台MK-V参数的过程并提出了3个疑问:
1、so使用了什么反调试手段?
2、可以从哪些切入点去分析这些反调试?
3、除了动态调试是否有办法对so静态反编译?
于是又去逆向了so的加载过程,在看完三万条汇编代码后(大多是无意义的垃圾代码),自己来回答自己的疑问。代码我就不贴了,实在太长。
1、so首先通过调用__NR_mprotect系统调用改写了自身某段内存属性为可读可写可执行,以备后用。又拷贝了自身两处数据组成长度0x241c的数据,将0x241c长度的数据解压,长度变为0x3ed8,然后通过一定操作映射到长度为0x6000的新地址,并进行了一定的初始化操作。然后调用析构函数,释放共享内存,对一些痕迹进行清理。
2、我是从so加载的角度去分析,通过查看aosp源码,根据Runtime_nativeLoad -> JVM_NativeLoad -> LoadNativeLibrary -> OpenNativeLibrary -> android_dlopen_ext -> __loader_android_dlopen_ext -> dlopen_ext -> do_dlopen -> call_constructors这个调用链一直跟踪,最终定位到这个so的call_constructors,通过hook这个地址获取了init和init_array的代码位置。
如果各位有更好的方法请不吝赐教!
在此又产生了一个新的疑问:如果so使用了自实现的linker去加载so,应该从什么地方着手跟踪?
3、在明白了so的运行原理后,静态反编译so变得无足轻重了,提出这条疑问的初衷是为了方便逆向分析,逆向后发现so中充斥着大量无用代码,即使反编译出来也难以查看。逆向过程中发现了通过mmap64映射后的地址,在得到此地址后dump二进制文件来反编译查看,或许比我和汇编死磕来得强。
[竞赛]2024 KCTF 大赛征题截止日期08月10日!