Android逆向-实战so分析-某洲_v3.5.8_unidbg学习
作者：互联网
文章目录
1.unidbg的介绍
unidbg是一款基于unicorn的用来模拟执行二进制程序的逆向工具，可以让安全研究人员直接在PC上运行android或ios的动态库文件并调用其中的方法，来看下该工具支持的功能。
支持功能如下：
- 支持模拟执行JNI调用API，以便可以调用JNI_OnLoad
- 支持JavaVM，JNIEnv
- 支持模拟syscalls调用
- 支持ARM32和ARM64
- 基于HookZz实现的inline hook
- 基于xHook实现的import hook
- 支持iOS fishhook、substrate、whale hook
- 支持简单的控制台调试器、gdb、IDA、android调试器服务器、指令跟踪、内存读/写跟踪。
- 支持iOS objc和Swift运行
2.unidbg的安装
2.1.下载unidbg工具
下载地址：unidbg
2.2.导入IDEA
打开IDEA，点击Import Project按钮。
这里需要说明一下，可能有些小伙伴一打开IDEA不是下图页面而是以往的项目页面，这种情况则直接在IDEA工具的File->New下面点击Project from Existing Sources…按钮一样可以进入到下一步的页面。
进入这个页面后将前面下载好的unidbg源码路径填入之后点击OK按钮。
然后会弹出下面这个页面，让我们选择项目类型，选择Maven项目，点击Finish按钮后IDEA就会开始导入工作。
这时候可能需要稍微等待一会，IDEA在导入项目的时候会下载一些依赖，记得保持网络通畅，之后等就完事儿了。
2.3.验证导入是否成功
等IDEA将整个项目导入完成后可以看到和下图类似的页面，主要看下左边红框中的内容，这是整个项目的视图，可以看到整个unidbg项目包含了unidbg-android、unidbg-api、unidbg-ios共三个子项目。
我们在unidbg-android子项目中找到作者给我们提供的测试类"com.bytedance.frameworks.core.encrypt"，然后点击运行TTEncrypt.main方法。
如果运行结果如下，则表示整个项目导入成功。
之后开始我们正式的分析工作。
3.unidbg的使用
3.1.目标方法静态分析
成功测试完作者给出的例子后，我们可以找一些例子来简单学习下unidbg的使用，这里直接使用白龙大佬博客中的例子(liboasiscore.so)。
首先看下本次需要调用的目标方法，目标方法在target.dex文件中，这个文件是白龙大佬脱壳出来的，对脱壳感兴趣的小伙伴可以试下脱壳。之前也有说过常用脱壳方法"实战sign分析-某某合伙人_v4.0.9"
样本APK：绿洲_v3.5.8
这里我们直接将target.dex丢到JEB工具中并定位到com.weibo.xvideo.NativeApi类，这是个全是Native方法的类，本次要模拟执行的方法是名为s的native方法，包含两个参数，参数1是个byte型数组，参数2是个boolean型变量。
现在有了目标方法，但我们并不知道这个方法是在哪里实现的，所以还需要找到这个方法的实现地址，这样我们才能使用unidbg进行模拟执行。
根据NativeApi构造函数中的System.loadLibrary可知这些native方法都在liboasiscore.so中实现的，使用解压软件可在原apk中的以下目录找到这个so文件。
这里需要注意你自己的测试机是多少位的系统，我这里是64位的，所以选用的是arm64-v8a目录下的so。
找到目标方法所在的so之后，可以使用IDA工具对这个so进行静态分析，以此来拿到目标方法的地址。
但本次目标方法的地址单纯的使用IDA静态分析并不能直接获取，一般如果native方法使用静态绑定可通过在IDA的函数窗口搜索java等关键字即可定位到目标方法，这里主要得益于静态绑定的方法命名需要按照固定的格式的原因，而本次目标方法采用的是动态绑定的方法，动态绑定就没有必须按照固定格式命名这么个限制，所以需要先找到so中动态绑定目标方法的位置，才能定位到目标方法代码实现的位置。
一般so对native方法动态绑定的实现都放在JNI_OnLoad方法中，首先定位到JNI_OnLoad方法，再去找动态绑定的实现。
找到JNI_OnLoad方法后又发现这个方法实际上被OLLVM混淆过，这样看来想通过静态分析找到目标方法的位置就不太现实了，到此我们的静态分析结束，下面开始我们的动态分析过程。
之前的动态分析都是采用Frida框架对应用中的一些关键方法进行hook的方式来分析的，这次采用另一种方式来实现动态分析—模拟执行。
3.2.模拟执行目标方法
打开前面配置好的unidbg工程，在工程的unidbg-android子项目的src/test/java/目录下创建一个com.sina.oasis.Oasis类并继承自AbstractJni类，主要用来编写我们的模拟执行so的代码，并将目标so文件liboasiscore.so和原apk也放到该目录下。
整个框架准备完毕后开始在com.sina.oasis.Oasis类中编写模拟执行的代码。
因为目标方法s是在JNI_OnLoad方法中实现的动态绑定，所以需要先实现对JNI_OnLoad方法的模拟执行。
JNI_OnLoad方法模拟执行如下：
package com.sina.oasis;
import com.github.unidbg.AndroidEmulator;
import com.github.unidbg.Module;
import com.github.unidbg.linux.android.AndroidEmulatorBuilder;
import com.github.unidbg.linux.android.AndroidResolver;
import com.github.unidbg.linux.android.dvm.AbstractJni;
import com.github.unidbg.linux.android.dvm.DalvikModule;
import com.github.unidbg.linux.android.dvm.DalvikVM;
import com.github.unidbg.linux.android.dvm.VM;
import com.github.unidbg.linux.android.dvm.array.ByteArray;
import com.github.unidbg.memory.Memory;
import java.io.File;
import java.nio.charset.StandardCharsets;
import java.util.ArrayList;
import java.util.List;
public class Oasis extends AbstractJni {
private final AndroidEmulator emulator;
private final VM vm;
private final Module module;
Oasis(){
// 创建一个模拟器实例,进程名建议依照实际的进程名填写，可以规避一些so中针对进程名校验
emulator = AndroidEmulatorBuilder.for64Bit().setProcessName("com.sina.oasis").build();
// 设置模拟器的内存操作接口
final Memory memory = emulator.getMemory();
// 设置系统类库解析
memory.setLibraryResolver(new AndroidResolver(23));
// 创建Android虚拟机,传入APK,Unidbg可以替我们做部分签名校验的工作
vm = emulator.createDalvikVM(new File("unidbg-android/src/test/java/com/sina/oasis/lvzhou.apk"));
// 加载so到虚拟内存,第二个参数的意思表示是否执行动态库的初始化代码
DalvikModule dm = vm.loadLibrary(new File("unidbg-android/src/test/java/com/sina/oasis/liboasiscore.so"),true);
// 获取so模块的句柄
module = dm.getModule();
// 设置JNI
vm.setJni(this);
// 打印日志
vm.setVerbose(true);
// 调用JNI方法
dm.callJNI_OnLoad(emulator);; // 调用JNI_OnLoad
}
public static void main(String[] args){
Oasis oasis = new Oasis();
}
}
以上代码实现了在PC上模拟执行目标so并调用JNI_OnLoad方法的功能。
通过输出日志可以看到JNI_OnLoad方法在执行的过程中调用的各种方法，同时还可以看到我们的目标方法被动态绑定时所在内存的地址，unidbg还友好的帮我们输出了该方法在so文件中的地址0x116CC。
有了这个地址就能在IDA中很方便的定位到目标方法的位置。
使用IDA快捷键G能够快速跳转到目标地址。
有了目标方法的地址后下面开始对目标方法进行模拟执行。
目标方法s的模拟执行如下：
package com.sina.oasis;
import com.github.unidbg.AndroidEmulator;
import com.github.unidbg.Module;
import com.github.unidbg.linux.android.AndroidEmulatorBuilder;
import com.github.unidbg.linux.android.AndroidResolver;
import com.github.unidbg.linux.android.dvm.AbstractJni;
import com.github.unidbg.linux.android.dvm.DalvikModule;
import com.github.unidbg.linux.android.dvm.DalvikVM;
import com.github.unidbg.linux.android.dvm.VM;
import com.github.unidbg.linux.android.dvm.array.ByteArray;
import com.github.unidbg.memory.Memory;
import java.io.File;
import java.nio.charset.StandardCharsets;
import java.util.ArrayList;
import java.util.List;
public class Oasis extends AbstractJni {
private final AndroidEmulator emulator;
private final VM vm;
private final Module module;
Oasis(){
// 创建一个模拟器实例,进程名建议依照实际的进程名填写，可以规避一些so中针对进程名校验
emulator = AndroidEmulatorBuilder.for64Bit().setProcessName("com.sina.oasis").build();
// 设置模拟器的内存操作接口
final Memory memory = emulator.getMemory();
// 设置系统类库解析
memory.setLibraryResolver(new AndroidResolver(23));
// 创建Android虚拟机,传入APK,Unidbg可以替我们做部分签名校验的工作
vm = emulator.createDalvikVM(new File("unidbg-android/src/test/java/com/sina/oasis/lvzhou.apk"));
// 加载so到虚拟内存,第二个参数的意思表示是否执行动态库的初始化代码
DalvikModule dm = vm.loadLibrary(new File("unidbg-android/src/test/java/com/sina/oasis/liboasiscore.so"),true);
// 获取so模块的句柄
module = dm.getModule();
// 设置JNI
vm.setJni(this);
// 打印日志
vm.setVerbose(true);
}
public String call_native_s(){
// 构造jni方法的参数
List<Object> arg_list = new ArrayList<>(10);
// 参数1：JNIEnv *env
arg_list.add(vm.getJNIEnv());
// 参数2：jobject或jclass 一般用不到,直接填0即可
arg_list.add(0);
// 参数3：bytes
String input = "aid=01A-khBWIm48A079Pz_DMW6PyZR8" +
"uyTumcCNm4e8awxyC2ANU.&cfrom=28B529501" +
"0&cuid=5999578300&noncestr=46274W9279Hr1" +
"X49A5X058z7ZVz024&platform=ANDROID×tamp" +
"=1621437643609&ua=Xiaomi-MIX2S__oasis__3.5.8_" +
"_Android__Android10&version=3.5.8&vid=10190135" +
"94003&wm=20004_90024";
byte[] input_bytes = input.getBytes(StandardCharsets.UTF_8);
ByteArray input_byte_array = new ByteArray(vm,input_bytes);
arg_list.add(vm.addLocalObject(input_byte_array));
// 参数4：boolean false 填入0
arg_list.add(0);
// 参数准备完毕 调用目标方法
Number number = module.callFunction(emulator,0x116CC,arg_list.toArray())[0];
return vm.getObject(number.intValue()).getValue().toString();
}
public static void main(String[] args){
Oasis oasis = new Oasis();
System.out.println("Native方法返回值：" + oasis.call_native_s());
}
}
运行后的输出日志。
可以看到目标方法执行完之后返回的结果是个32位的字符串，一般32位可能是Hash算法，下面来分析下目标方法s使用的算法。
3.3.算法分析
首先使用findhash工具对目标so中可能用到的常见Hash算法进行检测。
使用方法
- 下载findhash
- 将findhash.xml和findhash.py放到IDA的plugins目录下
- 使用IDA7.5加载完so后，在IDA工具栏依次点击edit->plugin->findhash即可运行
findhash工具的检测结果如下：
提示共发现3处疑似哈希函数的代码，同时还友好的帮我们生成了基于frida的hook代码，我们使用生成的代码来验证下算法。
λ frida -U -f com.sina.oasis -l liboasiscore_findhash_1626530188.js --no-pause
____
/ _ | Frida 14.2.2 - A world-class dynamic instrumentation toolkit
| (_| |
> _ | Commands:
/_/ |_| help -> Displays the help system
. . . . object? -> Display information about 'object'
. . . . exit/quit -> Exit
. . . .
. . . . More info at https://www.frida.re/docs/home/
Spawned `com.sina.oasis`. Resuming main thread!
TypeError: cannot read property 'add' of null
at hook_suspected_function (/liboasiscore_findhash_1626530188.js:26)
at main (/liboasiscore_findhash_1626530188.js:52)
at apply (native)
at <anonymous> (frida/runtime/core.js:45)
第一次尝试直接报错，分析发现是因为hook的时机不对，因为我们是在程序启动时开始hook的，而此时目标so还没有加载到内存中，所以会报错。
修改代码：
将js代码中自动生成的setImmediate(main);改为setTimeout(main,5000);使之前的立即调用main方法变成5秒后调用main方法，这样就能在目标so加载完成后进行hook，也就不会再报前面的错误了。
λ frida -U -f com.sina.oasis -l liboasiscore_findhash_1626530188.js --no-pause
____
/ _ | Frida 14.2.2 - A world-class dynamic instrumentation toolkit
| (_| |
> _ | Commands:
/_/ |_| help -> Displays the help system
. . . . object? -> Display information about 'object'
. . . . exit/quit -> Exit
. . . .
. . . . More info at https://www.frida.re/docs/home/
Spawned `com.sina.oasis`. Resuming main thread!
[Nexus 5X::com.sina.oasis]->
发现，虽然没有报错了，但应用启动后随意操作几下发现却并没命中我们的hook代码，直接使用findhash的脚本还是存在一些问题，作者也说了对arm64适配还有些问题，看来我们只有手动分析了。
3.3.1.OLLVM去混淆
根据前面的分析我们知道该应用对so中的方法都加了OLLVM混淆，手动分析的话那么第一步就是去混淆，这样分析起来才不至于迷失在代码的海洋。
本次使用的思路如下：
1.首先使用unidbg对目标方法进行指令级trace，拿到目标方法所有会被执行的指令地址；
trace代码：主要在原call_native_s()方法中添加了对一定范围内指令执行的监控回调。这里我们使用IDA快捷键"ctrl+s"查看目标so的代码段，将整个代码段的起始地址(0x8C50)和结束地址(0x42ED4)作为监控范围。记得加上so基址；
public String call_native_s(){
// 添加一个指令集hook回调,并输出当前执行指令在so文件中的偏移地址
emulator.getBackend().hook_add_new(new CodeHook() {
@Override
public void onAttach(Unicorn.UnHook unHook) { }
@Override
public void detach() { }
@Override
public void hook(Backend backend, long address, int size, Object user) {
// 打印当前指令地址,注意需要将实际地址减去so基地址得到代码在文件中的偏移
System.out.println(String.format("0x%x",address-module.base));
}
},module.base+0x8C50,module.base+0x42ED4,null); // 指定监控起始地址与结束地址,记得加上so基址
// 构造jni方法的参数
List<Object> arg_list = new ArrayList<>(10);
// 参数1：JNIEnv *env
arg_list.add(vm.getJNIEnv());
// 参数2：jobject或jclass 一般用不到,直接填0即可
arg_list.add(0);
// 参数3：bytes
String input = "aid=01A1heTbypm4P4ovynAZcytJ3Af1fHFAV90gv3_mMmB6Ch9gQ.&cfrom=28B5295010&cuid=5226994080&filter_quick_replay=0&filter_rainbow=0&noncestr=H022wq318Kk508356jZXXl1317G8RS&platform=ANDROID×tamp=1626584839282&ua=LGE-Nexus5X__oasis__3.5.8__Android__Android8.1.0&version=3.5.8&vid=2003855943799&wm=20004_90024";
byte[] input_bytes = input.getBytes(StandardCharsets.UTF_8);
ByteArray input_byte_array = new ByteArray(vm,input_bytes);
arg_list.add(vm.addLocalObject(input_byte_array));
// 参数4：boolean false 填入0
arg_list.add(0);
// 参数准备完毕 调用目标方法
Number number = module.callFunction(emulator,0x116CC,arg_list.toArray())[0];
return vm.getObject(number.intValue()).getValue().toString();
}
模拟执行结果：
之后手动将这些地址保存成一个unidbgTrace.log文件。
2.使用IDAPython在IDA中将前面收集到的地址进行标记；
有了目标方法执行的实际指令地址后使用IDAPython脚本在IDA中对这些地址进行标记，表示有效指令。
# -*- coding: utf-8 -*-
import sark
import sys
def do_ollvm_bcf():
'''
ollvm虚假控制流处理
'''
log_file = "unidbgTrace.log"
trace_addrs = []
# 将trace指令的地址读取到trace_addrs列表中
with open(log_file, "r") as f:
lines = f.readlines()
for line in lines:
trace_addrs.append(int(line.replace("\n", ""), 16))
for addr in trace_addrs:
line = sark.line.Line(addr)
line.color = 0xEE82EE # 将执行过的指令通过修改颜色来标记出来。
if __name__ == "__main__":
do_ollvm_bcf()
IDA加载IDAPython脚本：IDA工具栏依次点击file->script file…之后在弹出来的文件选择框中选择写好的Python脚本文件加载即可。
执行完后跳转到目标地址方法0x116CC处看下，效果如下：
处理后的目标方法的流程图，其中标记为紫色的表示有效会被执行的代码；
不过还有个问题，根据上图可以看出整个方法还是有许多无效的代码块，主要是因为IDA将目标方法解析成了JNI_OnLoad方法的一个分析，所以这里看到的图实际上是包括JNI_OnLoad方法和一些别的方法的代码的。
对于这种情况，在JNI_OnLoad方法开始（0x10CEC）处使用快捷键"u"将整个方法取消定义，之后再跳到目标方法开始（0x116CC）处使用快捷键"p"从当前地址开始解析成方法，处理完成后效果如下：
然后你会发现，好像，，，，这个方法并没有什么虚假控制流。-_-||
问题不大，反正也是学习，说一下，如果有时候发现存在大量的虚假控制流，那么还可以根据有效指令将不会被执行到的指令patch为nop，这样IDA在反编译伪C代码的时候就不会对无效指令进行解析，减少伪C中无效指令的干扰。
使用IDAPython对方法中未执行的指令全部patch成nop指令(0x1f, 0x20, 0x03, 0xd5)；
如何知道nop指令的opcode？
使用IDA插件Patcher：IDA工具栏依次点击edit->plugin->keypatch patcher
IDA快捷键：
- u：取消函数、代码、数据的定义
- p：从当前地址处开始解析成方法
完整代码如下：
# -*- coding: utf-8 -*-
import sark
import idc
import sys
def patch_nop(addr):
'''
将指定地址的字节修改成nop
'''
nop_code = [0x1f, 0x20, 0x03, 0xd5]
for i in range(len(nop_code)):
idc.patch_byte(addr+i, nop_code[i])
def patch_code():
# 设置需要处理代码的起始地址和终止地址，并获取范围内所有汇编指令的地址
s = 0x10CEC # 目标方法起始地址
e = 0x10CEC+0xFEC # 目标方法结束地址
funcLines = sark.lines(s, e)
for line in funcLines:
# 判断如果该行代码的颜色是我们标记的颜色,则进入patch逻辑,将代码patch为nop指令。
if line.type == "code":
if line.color != 0xEE82EE:
patch_nop(line.ea)
def do_ollvm_bcf():
'''
ollvm虚假控制流处理
'''
log_file = "unidbgTrace.log"
trace_addrs = []
# 将trace指令的地址读取到trace_addrs列表中
with open(log_file, "r") as f:
lines = f.readlines()
for line in lines:
trace_addrs.append(int(line.replace("\n", ""), 16))
for addr in trace_addrs:
line = sark.line.Line(addr)
line.color = 0xEE82EE # 将执行过的指令通过修改颜色来标记出来。
if __name__ == "__main__":
do_ollvm_bcf()
# patch_code()
虽然处理完后还存在一些控制流平坦化的问题，但这并不妨碍我们fuck这操蛋的代码。
F5看下伪C代码，分析前先对目标方法的入参类型进行修复，鼠标选中参数1，IDA快捷键"y"修改变量类型，将参数1恢复成JNIEnv *a1，这样方法中调用的JNI方法就会被自动识别出来。
__int64 __fastcall sub_116CC(JNIEnv *a1, __int64 a2, __int64 a3, char a4)
{
// ...
v35 = *(_QWORD *)(_ReadStatusReg(ARM64_SYSREG(3, 3, 13, 0, 2)) + 40);
v6 = 0xFD500367;
v7 = (*a1)->GetByteArrayElements(a1, a3, 0LL);
v8 = (*a1)->GetArrayLength(a1, (jarray)a3);
v9 = v8;
v10 = v8 == -1;
if ( v8 < -1 )
v11 = -1LL;
else
v11 = v8 + 1;
v12 = !v10;
v13 = (char *)operator new[](v11);
v14 = &v13[v9];
memset(&v13[v9], 0, v12);
v15 = v9;
v16 = a1;
memcpy(v13, v7, v15);
*v14 = 0;
(*a1)->ReleaseByteArrayElements(a1, (jbyteArray)a3, v7, 0LL);
v17 = (const char **)&off_5D0A8;
if ( a4 )
v17 = (const char **)&off_5D0A0;
v18 = *v17;
v32[0] = 0LL;
v32[1] = 0LL;
v33 = 0LL;
v19 = strlen(v18);
sub_12C90((int)v32, (int)v18, v19);
v20 = strlen(&byte_5D230);
sub_12FDC((int)v32, (int)&byte_5D230, v20);
v21 = strlen(v13);
sub_12FDC((int)v32, (int)v13, v21);
free(v13);
sub_C688(v34, v32);
sub_F6DC(v34);
if ( ((v29 ^ 0xFE) & v29) != 0 )
v23 = 0xC984BF68;
else
v23 = 0xA4F8DF4D;
for ( i = 0x9C2D2380; ; i = 0x4D9896E ){
while ( i <= (int)0xC984BF67 ){
if ( i == 0x9C2D2380 ){
i = v23;
}else{
i = 0x4D9896E;
v22 = v30;
}
}
if ( i != 0xC984BF68 )
break;
v22 = (char *)v31;
}
v25 = (__int64)(*v16)->NewStringUTF(v16, v22);
v26 = 0xFD500367;
while ( v26 != 0xF409034D ){
// ...
}
while ( v6 != 0xF409034D ){
// ...
}
return v25;
}
捋一下方法的大概逻辑，代码比较少，首先通过v7 = (*a1)->GetByteArrayElements(a1, a3, 0LL);方法拿到Java层传入的待加密字符串，之后申请一块新内存将Java层传入的待加密字符串拷贝进去。
之后分别通过方法sub_12C90()，sub_12FDC()，将两个内置的字符串(“YP1Vty&$Xm*kJkoR,Opk"和”&")与Java层传入的待加密字符串进行拼接，结果存放在变量v32(0x78b5752338)指向的内存中，之后调用free将前面申请的内存进行释放。
方法sub_C688，sub_F6DC则主要是对拼接后的字符串进行处理，应该是主要加密逻辑，但简单分析后发现与这两个方法相关的两个变量v34与v32在之后的代码中并没有被引用，导致无法进一步分析，所以换个方向，试一下根据目标方法的返回值进行反向分析。
思路如下：
- 1.找到返回值来源
- 2.监控返回值来源内存的变化
目标方法的返回值来源：返回值等于v25，v25的数据来源于"(*v16)->NewStringUTF(v16, v22)"，所以数据来源于v22，而代码中v22有两处赋值，根据我们打的有效标记可知v22的实际来源是v31，到这里后发现数据流又断掉了，淦，直接看汇编吧。
伪C代码"v22 = (char *)v31;“对应汇编"MOV X1, X12”，再看看X12的来源等于"LDR X12, [SP,#0x110+var_E8]"。
到此分析了整个返回值的数据来源，下面使用Frida的指令级Hook确定一下。
3.3.2.指令级Hook辅助分析
"LDR X12, [SP,#0x110+var_E8]"指令所在地址是0x11870，但是hook时需要下条指令的地址0x11874，这样X12寄存器中的值才是正确的；
代码如下：
// 指令Hook
let arm_11874 = targetSo.add(0x11874);
Interceptor.attach(ptr(arm_11874),{
onEnter:function () {
// console.log(args[0]);
var sp = new NativePointer(Number(this.context.sp) + Number(272 - 232));
console.log("arm_11874_onLeave [ARM:SP+0X110-0XE8]:"+JSON.stringify(sp));
console.log(hexdump(sp,{length:100}));
console.log("arm_11874_onLeave [ARM:X12]:"+JSON.stringify(this.context.x12));
var x12 = this.context.x12;
console.log(hexdump(x12,{length:100}));
},onLeave:function (retval){
console.log("");
}
})
分别得到"SP+0X110-0XE8"与X12寄存器的值；
接下来再对"SP,#0x110+var_E8"指向的内存进行监控，看下是在哪出被修改的。
调试可见存放结果的目标内存是在sub_F6DC函数执行前后不一样，所以应该是在这里面被修改的。
3.3.3.unidbg寄存器trace分析
----------------------- 以上全错
以上的方法都太麻烦了，还有更简单更暴力的方法；
通用思路：利用trace功能，将每条汇编指令以及寄存器值的变化全部记录下来，然后分析寄存器中的值是否有标准算法的关键数据。
如下：这里使用unidbg trace功能识别标准MD5算法的魔术IV值，定位到这些数据后离算法的运算逻辑就不远了。这实际上是个标准的MD5加密。
或者也可以一个个尝试标准Hash算法。((:
比较全的一个加解密在线工具CyberChef
4.补充知识
4.1.JNIEnv、jobject、jclass
一般在JNI编程中，javah生成的Native方法的第一个参数永远都是JNIEnv指针，而第二个参数一般都是jobject或jclass中的一个。
4.1.2.JNIEnv指针是什么东西？
JNIEnv顾名思义，指代了Java本地接口环境（Java Native Interface Environment），是一个JNI接口指针，指向了本地方法的一个函数表，该函数表中的每个成员都指向一个JNI函数，本地方法通过JNI函数来访问JVM中的数据结构。
可以看到，JNIEnv中包含了诸多的JNI函数结构体。
4.1.3.jobject和jclass又有什么区别？
jobject与jclass通常作为JNI函数的第二个参数出现，当声明的Native方法为静态方法时，对应的参数就是jclass，因为静态方法不依赖对象实例，而依赖于类，所以参数中传递的是一个jclass类。相反，如果声明的Native方法是非静态方法，则对应的参数是jobject。所以为了能够在Native层访问java中的类和对象，jobject和jclass分别表示对象和类，进而实现成员方法和成员变量的访问。
标签：v3.5,com,so,unidbg,import,JNI,方法 来源： https://blog.csdn.net/weixin_46734340/article/details/118857038