-
-
某app deviceinfo分析
-
发表于: 2022-10-15 21:32
-
可以看到输入是protobuf，输出是byte array。并且输入和输出相隔了40多w条指令。
在trace文件中搜索0x2a
对应的c语言代码
经分析，该函数功能是对输入的byte arr进行字节转换。再往下
这是具体的加密函数，对输入的数据16位一组就是加密，末尾补pad个pad
使用python还原一下
为减少干扰，删除已还原数据，搜索目标数据
经过分析，该函数为计算hash, 调用了两次，计算的hash值为
第二次计算的hash为结果串的前8个字节中的后四位。输入为:002a7b0a-7ae6-4000-93af-60c2d63176fe
继续搜索, 可以发现在0x13714位置，对数据进行了eor运算，eor结果即为输出的数据。
从0x20起，即为eor第一步中加密算法的结果。
前32位数据为:
未加注释的地方，由于trace工具对内存读写这方面的支持还不是很好，就鸽了，感兴趣的可以自己分析，基本上在这儿。
, 前面说到后四位是由第二次计算结果的值获得。那么前4位呢？
前两位固定，后两位是由一个数 ^ CDEF 而来
由于trace工具对内存读写还不太完善，具体没追这个值，不过大胆猜测这是该加密函数的调用次数，可以用frida验证下结果。
0x35 0x79.......0x32 是0x10长度的salt，多次对app进行清空等操作，发现只有两组salt，分别为
5yPDTSC3rzXfpwN2 和 fGqSL6alaNcUyV9W，同样由于trace工具对内存读写访问的问题，不太容易跟踪，在此不得不感慨，unidbg的内存访问断点是真的好用。 哎有时间根据加密算法，还原下解密吧。
com.***.***.***.***.***.JNICLibrary#doCommandNative方法，其中当序号为10400时为加密算法。
com.***.***.***.***.***.JNICLibrary#doCommandNative方法，其中当序号为10400时为加密算法。
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
最后于 2022-10-15 21:57
被我只是没人要编辑
，原因：
|
|
|---|---|
|
|
|
|
|
|
|
|
|
