// 反编译 tt.apk
java -jar apktool_2.5.0.jar d tt.apk -o test -f
// 回编译 apk
java -jar apktool_2.5.0.jar b test -o unsign.apk
// 对回编译的apk进行签名
java -jar ../Autosign/Auto-Sign/signapk.jar ../Autosign/Auto-Sign/testkey.x509.pem ../Autosign/Auto-Sign/testkey.pk8 unsign.apk signed.apk
这个时候打开apk 发现白屏, 屏幕一直都是白屏. apk没有挂．
adb shell 然后 logcat | grep com.tt.ttt 查看应用信息, 发现
?
?发现都是died fore top 这种提示信息, 于是搜索了一下?died fore top, 发现是内存泄露，一般是jni问题, 于是在jadx中全局搜索了一下 loadlibrary, 结果如下
?stringFog是这个app通用的字符串加密, 可以通过 frida hook 自调用查看so库名称,
不过在这个类下发现了一系列可疑的native函数,? 其中 validitySign 格外养眼
查看谁调用了这个函数
只有这一处, 不搞so, 尝试着smali中 删除这部分代码， 回编, apk正常运行．
上述方法一:? 修改smali把签名验证逻辑删除，搞定收工.
不过本着学习的态度， 可以继续看看so, validitySign这个函数是静态注册, 实现如下
进入这个验证函数内部看看
发现有一个比较操作, 当计算所得的签名与固定字符串比对相同时,则验证成功．
我们可以修改逻辑，把逻辑改成 =>? 当签名与固定字符串比对不同时,则验证成功
CBZ ? R0, loc_83BE
CBZ 指令是 compare branch zero ， 当R0为0时，则跳转, R0存放的?c函数strcmp的结果
所以一种改法是将?CBZ 改为?CBNZ
推荐一个在线的arm <=> hex 转换站点??https://armconverter.com/
?CBZ ? R0, loc_83BE? 这条指令对应的hex 是00B3,?loc_83BE是函数相对于本条指令的偏移
? ?
?可以看到偏移是0x44, 然后紧接着arm to hex 试试， 发现是可以来回转换的?
然后将 cbz 改为 cbnz?
cbnz这条指令对应的机器码用16进制表示是 00BB
然后打开二进制修改工具, 找到对应的位置
将 837A 处的00B3?修改为 00BB， 然后回编， 发现程序正常运行.
?
上述方法二:? 修改so层代码逻辑，搞定收工, 回家收衣服.
仅限于学习交流， 侵删！！！！