一：基本情况

apk运行过程中会多次触发 libdidiwsg.so (arm64)注册的 nativeCollect 函数

当参数为下面字符串时会返回加密后的数据

"epassport.diditaxi.com.cn/passport/login/v5/codeMT"

以学习为目的来尝试解密这些数据， libdidiwsg.so 的代码存在混淆看不了，只能trace

二：IDA trace 

IDA 可以附加进程进行trace，但原始APK会多次触发nativeCollect 函数，还有其它干扰，思路是新创建一个新的android 工程p9，用来单独加载这个so，专门调用这个函数。

为了保证 init_array表中的函数、Jni_Onload 函数、以及so通过 CallxxxMethonID系列函数调用 java层函数能够成功执行，需要在p9工程中补全 FindClass查找的各个包和类和类中对应的各个函数。

nativeCollect 接口调用成功后就可以使用IDA附加trace，IDA附加进程后需要挂起其它线程

def suspend_other_thread():
    current_thread = idc.get_current_thread()
    thread_count = idc.get_thread_qty()
    for i in range(0, thread_count):
        other_thread = idc.getn_thread(i)
        if other_thread != current_thread:
            idc.suspend_thread(other_thread)

IDA 可以正常的 trace ，但速度太慢，只能使用其它 trace 工具

三：unidbg trace

3.1：修改trace格式

需要修改 unidbg trace 的格式，把一些字符串打印出来，比如 strlen 、strstr、strcpy 这个字符串操作函数。

so是arm64，修改对应的  unidbg-master\unidbg-api\src\main\java\com\github\unidbg\arm\ARM.java 文件：

其中的0x3330E0 是对应函数的.plt 地址

3.2：base64 table 定位

trace后共有 430多万行，其中有一个 strlen 函数的参数应该就是获取到的所有信息，后续应该就是对这个信息进行加密

最后一个 strlen 函数就是输出的结果

此时保存结果的内存值为 x0=0x12b3c000，向上查找它的写入来源，发现偏移 0x1d50a0存在可疑访问 ：搜索这个偏移，发现这个地址执行了124次，每次的地址都是加4，编码后的数据正好是 124*4=496

 而且base64编码每次都是处理4字节，所以可以猜测这里可能就是在进行base64编码

调试后发现每次都是写入4字节数据：

那么，应该可以在相邻执行到偏移 0x1d50a0之间的代码找到base64的table ，两次执行之间的指令共有 73行，直接搜索上面的 0x65、0x56、0x36、0x30 (eV60)，很容易定位到偏移 0x1d50c8处的 x17 保存的就是table

3.3：待续