这篇帖子起因是前段时间想挂个协和的号,随便拿了个测试机下载好APP后打开卡在启动界面,以为是测试机root之类的东西被检测到后拒绝启动了。
于是准备看看怎么回事,发现这玩意儿使用了**加固,正准备分析分析,突然发现测试机WiFi没连上,连上网之后就正常了,于是就把它丢在一边没管了。
然后过年在家闲着没事,想起还有这么个东西,正好**加固以前没有遇到过,于是又在垃圾桶里把它翻出来了。
分析完后,实在是忍不住想吐槽一下,,不知道是不是外包公司没给钱,这加固做得就跟期末大作业水平差不多,全程就像读源码一样,,和前一篇帖子分析的乐固差远了。。
老规矩,先把apk用jadx反编译,从AndroidManifest.xml找到application的类com.***ivm.security.StubApplication,
发现这个类的attachBaseContext和onCreate方法都是native方法,然后有个静态代码块。
在SDK大于等于29(android9)的时候,先解除对隐藏api的反射限制。
然后init方法判断cpu架构,从apk的assets目录释放对应的so进行加载。
选择分析arm32的文件kadp_armeabi。
用ida加载kadp_armeabi,发现没有.init_array段,于是直接看JNI_OnLoad函数,代码很简单,只调用了init函数
init函数的代码也很简单,判断了下sdk版本和vm版本,然后注册了两个native方法
看下off_2C124的数据,注册了attachBaseContext和onCreate这两个方法
接着看native_attachBaseContext,首先调用了init_class
init_class函数中获取了一些字段和方法的id进行缓存
回到native_attachBaseContext,获取dalvik.system.DexFile的构造方法缓存起来,然后调用函数extractDexToMemMap_zlib从apk获取dex文件,接着调用函数cfile_init对dex进行解析
函数extractDexToMemMap_zlib通过zlib库遍历apk中的文件,获取classes.dex文件并mmap
函数cfile_init先判断文件类型,找到dex的基址,计算dex所属内存页,修改属性,用于后面解密直接修改
然后解析一些用于解密dex的字段
dex中用于解密的数据从dex的data数据之后开始,即起始位置的偏移为 dex_header.data_size+dex_header.data_off
结构如下:
magic字段内容如下,不匹配则解析失败
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入!
最后于 2022-2-17 20:10
被kanxue编辑
,原因: