记录一次so逆向思路

神女软件定制

请求参数加密了，疑似是rsa
用推理工具(https://125.confly.eu.org/forum.php?mod=viewthread&tid=14845762)推出来的公钥太多了，于是就上手逆向

跟踪发现最终加密在so里面，去so里面扫描了一下，也没有发现rsa公钥，最后发现是登录就返回了公钥(没注意看)。我就在想，那你这个so，不是白弄了嘛。

结果又遇到个问题，登录包下发公钥之后，每个请求的数据都是用rsa加密了，一两个还好，可以用一个手动技巧，找出原文，该替换的替换，但是每个请求都是rsa，原文内容都不一样。rsa知道公钥，也没办法通过抓包得到的密文还原原文。

脑子灵光一闪，你这个公钥加密的我没法解密，我自己弄个公钥我就可以解密了，于是，就用sunny写了一个临时抓包工具。
登录成功，返回的时候，记录下返回内容里的原始公钥，然后替换成自己生成的一个公钥(当然我也有配对的私钥)返回给客服端。
然后每抓到一个后续的包，就用配对的私钥给他解密出来原文，然后再用原始的公钥给他加密替换回去提交给服务器。把解密的内容显示在临时抓包工具上，就可以知道每个请求的原文内容了。
深刻理解了中间人攻击

于是信心慢慢的测试，结果诡异的现象就是解密不了前面的128字节，128字节后面的都能成功解密出原文。（rsa加密长度，超过了密钥长度，就会分多个块加密）

我一度怀疑是不同库的标准啊，rsa加密的一些另类模式啊之类的导致。
用js，c++，python都写了代码解密，结果都是第一个块解密不了，后续都能成功解密。就这个卡了我一整天。

都放弃了，又不死心，最后想了下，还是感觉有可能单独处理过前面128字节，并且应该是在rsa加密之后处理的(理论上，rsa分块加密，每个块都是一样的过程，如果他在之前处理，也能解密出处理之后的内容)
还是又从so下手分析。

中间蓝色的部分，看起来都能理解，上面都有函数名称
红框部分看起来就有点格格不入了。
慢慢查了下，给可疑指令都加上了备注。（顺便总结个经验：只要出现 and，or，shr，shl这种之类的指令，以及一些奇怪的常数，比如截图中的0xFFFFFF80，可能就是你要找的）
然后整体看，前半部分就是计算一个数字，后面部分在一个buff中交换了，0和那个数字，两个位置的字节。

有样学样的跟着交换，也算是搞定了……

a657938016

牛逼啊，大佬