最开始是有个群友群里咨询抓包的问题，好奇跟群友要了apk包，结果到手直接小黄鸟秒了

    一般这种情况，不是抓包证书问题就是手机问题（推荐使用谷歌原生手机做测试～bug相对来说少一些），所以我是建议群友正常抓一下百度的包试试看。果然，后来定位出来是手机证书问题导致的。

    简单抓了一个登录的请求包，参数加密了，来都来了，简单看下这个加解密吧

    本来打算直接拖来二营长的意大利炮，用算法自吐脚本秒了的，嘿，您猜怎么着？没秒掉

    那只能人工看了啊，搞了会感觉十分有九分的不对劲，我使用frida打印那些底层函数的调用情况，怎么在日志里面我输入的手机号18888888888毛都搜不到？

    这时候瞥了一眼这个app的包名，包名中带有“uni”的关键字，突然恍然大悟，原来是uniapp？验证的方式也很简单，把.apk后缀改成zip，然后解压，在./assets/apps/{包名}/www/这个目录下会存放着加载app使用到的前端资源文件

    正常情况下，代码的逻辑跟小程序类似基本都是写在app-service.js里面的，所以对于这uniapp的加解密逆向的话，最无脑的方法大多会采用静态代码分析app-service.js文件里面的代码逻辑。最开始我也是这样想的，不过看了半天，一点收获都没有，就随意点击了其他的js文件，忽然被一个乱码的文件给吸引住了，著名的五星上将-麦克阿瑟曾经说过“越是惧怕什么，人们就越努力把它藏进暗处”。直觉告诉我这个乱码内容就是加解密的核心代码。那么问题来了，怎么获取这个乱码的解码内容呢？

    其实只需要简单思索就会想到解决方案。众所周知，既然我们假定了它是加解密的核心代码，那么这个uniapp就一定会调用它，既然会调用它，那么内存里肯定会有明文缓存，既然会有明文缓存，我们直接在内存里捞一下不就好了嘛？很好，问题进入了下一个阶段，如何在内存里捞出来这个明文缓存呢？

    经常看我文章的师傅应该还有印象，之前介绍过一个邪修工具《看透“邪修”加解密逆向工具的灵魂：原理解析比教程更炸裂！》这个工具的本质其实就是从内存里面捞东西，幸运的是它恰巧也支持APP～使用之前，首先需要把一个dumpmm文件上传到/data/local/tmp目录下并赋777的权限

    然后点击真机，选择app的包名，点击加载模型，等个大概10分钟左右，就会出现模型加载成功的字样

    随后选择明文搜索，输入乱码文件的文件名，点击开始推理

    静静等待推理结束，随机便可以在结果中发现这个文件在内存缓存中的明文状态（搜索出来的结果可能会有点多，需要简单筛别一下）

    成功发现里面赫然记录着加密方式，key，iv等信息，验证一下，没有问题～

    当然，搜乱码文件的文件名，还是中规中矩了一些，因为如果其他js文件中引用了app-confusion文件，也会从内存中扒出来很多的结果，筛选起啦还是有点太麻烦了，邪修直接从内存里扒关键字“.enc.Utf8.parse”，背后的经验逻辑是：凡是用字符串字面量（固定字符串）作为加密密钥或 IV 的 CryptoJS 代码，几乎都会调用 .enc.Utf8.parse() 来转为字节格式。因此如果一个uniapp，看起来不是很恶心的情况下，你可以大胆猜测它就是固定的key和iv进行加密的，直接内存扒关键字“.enc.Utf8.parse”就完事儿了。顺便说一句，之前其实也就是因为，全局搜索文件夹下的所有文件，都搜不到这个关键字，才猜测那个乱码文件的内容就是加解密的核心代码。

    当然，如果你觉得使用上文提到的推理助手工具，推理过程太过花费时间，而恰巧你又会点frida，那么同样也推荐你使用frida去hook uniapp加载的js资源，直接就是一手“frida -U -f 包名 -l hook.js -o res.txt”将加载的js资源保存到res.txt中也能达到同样的效果，发现这个乱码文件的明文内容

    过程虽稍长，但目的是记录完整的思考路径：按需求自顶向下倒推并拆解问题，直到得到可执行的子任务再去处理。这样的拆解方法具有通用性，处理问题的能力比处理问题更重要！