APK直接拖入JEB，发现函数名混淆了，很长的标点什么的，还有就是字串加密了，看起来MainActivity有个文本框和一个按钮，点击按钮后，将文本作为参数调用utils.check，utils加载了一个so库，check为native函数。只不过so库名字加密了，不用管，因为看了下只有一个so库。

ida加载so文件，发现了check函数，发现好多花，JNI_Onload和check根本没法看。看了下字串，发现有几个可疑的字串，就研究了下，这几个字串都是通过unhex加异或解码的，大概如下：

前面是原始字串，后面为异或表，最后是解码的字串。 查看调用位置，发现几个类似反调试的函数，一个是通过ptrace反附加，一个是通过检查ida的远程调试端口反调试，一个是通过inotify监控maps文件反调试。我尝试进行了更改，前面为偏移，后面为更改情况：

在异或表前后还有很多类似的表，据此发现很多的unhex_xor的操作函数，数量很大。但是找不到调用的地方，反调试函数也没有找到调用的地方。陷入僵局。 无法继续看混淆，发现规律，形式单一，并且中间似乎没有和真实指令有关的东西，所以粗暴替换成NOP，加上前面的unhex_xor一起搞了：

搞完查看伪代码，发现似乎path有问题，看代码:

变量名不知怎么乱了。check_20020[count] == (unsigned __int8)v14[count]似乎就是最终的比较，24位，check_20020的赋值在此处和另一个函数sub_19FC中，分别写check_20020的奇数位和偶数位。似乎sub_19DA8为加密函数，最后来验证。

经过时间的研究与猜测，sub_1A31C()和check_20020取值手法一样，怀疑是密钥，sub_55E4像是密钥扩展什么的，里面开头有这么一段：

再加上后面及加密部分的难懂的代码，推理加密算法为RC4。 enbase_5AFC为base64编码，64个变换表太显眼了，还有个解码的函数，似乎没有地方调用。 分析加猜测，算法出来了，现在就是验证及校验码的拼接顺序，密钥的取值顺序，其值都是硬编码的明文，目前能得到校验码的可能相关值为Jyu3CJlVDSGQ和Pjpeyjk6mmH=，密钥的相关值为199310124853!，通过以上代码我没有弄出来准确值，代码解析还是有问题的。只好试着动态，在关键点下断找数据。

重新打开so文件，只patch反调试的地方，使用jar及jarsigner进行文件替换和签名，push到模拟器进行ida动态调试，意外出现了，在正常指令的地方如MOV R3,R3出现非法指令的异常，又费了很长时间，无法解决了似乎，另外arm虚拟机太慢了，坑死了。带着遗憾过了最后一晚上的攻击机会。最后听说没有反调试，可以直接调试，没时间试，不知道什么情况。

眼看情况快到了，一直在想参数的确定问题，24位base64比较值，两串相关字串就是24位，有可能是直接奇偶拼接，没有更换顺序。而key只有8位，现在是13位，又是怎么取的呢，难道和前面一样，按顺序取？ 最后找朋友帮忙动态确定猜想，果然。

懒得写py脚本了，用软件解了得到：madebyericky94528。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)