// 反编译 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层代码逻辑，搞定收工, 回家收衣服.
仅限于学习交流， 侵删！！！！