对某茅台MK-V参数的逆向过程的补充

在之前的帖子里记录下逆向某茅台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二进制文件来反编译查看，或许比我和汇编死磕来得强。