某手游il2cpp逆向分析libtprt保护

function print_arg(){    var libtprtaddr = Module.findBaseAddress("libtprt.so");    console.log("libtprt基址: ",libtprtaddr);    console.log("libil2cpp基址: ",Module.findBaseAddress("libil2cpp.so"));    var function_addr = libtprtaddr.add(0x1BCE3C);    Interceptor.attach(function_addr,{        onEnter:function (args) {            console.log("0x277DA0: ",Memory.readPointer(libtprtaddr.add(0x277DA0)));        },        onLeave:function (returnValue) {        }    })}var isCalled = false;function hookdlopen() {    var dlopen = Module.findExportByName(null, "dlopen");    Interceptor.attach(dlopen, {        onEnter: function (args) {            var path = args[0].readCString();            if (path && path.indexOf('libil2cpp.so') !== -1) {                this.path = path;            }        },        onLeave: function (retval) {            if (this.path && this.path.indexOf('libil2cpp.so') !== -1 && !isCalled) {                print_arg();                isCalled = true;            }        }    });}hookdlopen();

运行后查看打印情况

可以明显看到，0x277DA0处的函数指针并不是libtprt内的函数，而是libil2cpp中的，将得到的地址减去libil2cpp的基址，得到0x7281F04，去ida中查看数据并没有解析出来，我们按"C"键来将其主动转化成汇编可以看到他跳转了一个函数，进去跟进去吧可以看到有一个明显的Metadata字符串，这和源码中的LoadMetadataFile函数很类似继续往下看，发现还有类似的字符串，如"ERROR: Could not open %s"那看来函数应该是找对了，继续对照着看，发现sub_165588C和os::File::Open很类似，都是6个参数，而且v42也和error很像，那么v32就可以认为是源码中的handle了。继续对照源码，源码中只有两个地方调用了handle，分别是utils::MemoryMappedFile::Map和os::File::Close，而ida中的伪c代码也只有两处，分别是sub_16DC91C和sub_1655C7C，故而直接推论，sub_16DC91C就是utils::MemoryMappedFile::Map，那么直接跟进去看看实现跟进去看看如图所示，整个sub_16DCB14只调用了三个函数，我们分别对着三个函数进行分析很明显，sub_16EC43C只是一个计算长度的，直接跳过同样的，通过sub_165A548的返回值也能看出来并不是主要函数那就只能是sub_165A6FC了，跟进去看看F5分析的有问题，直接看汇编吧果然有问题，BL指令调用完全后是会执行后续指令的，这是带LR寄存器的跳转，所以后续的那个函数也应该包含在sub_165A6FC函数里面，直接去看0x165A740+4，也就是0x165A744处的函数实现提示栈有问题，不用管，能分析出来就行，查看逻辑，发现返回的result只与sub_F1E0B0有关，那行，跟进去看看继续跟又看到了熟悉的g_tprt_pfn_array_ptr_0，继续去libtprt里面去找吧，不过这次的偏移量是0xA0跟进去，是个B跳转，继续跟，看到了一个函数我们注意到函数内有几个判断值的if语句：  if ( buf[0] != 0x94 )    return mmap(addr, len, prot, flags, fd, offset);  if ( buf[1] != 0x43 )    return mmap(addr, len, prot, flags, fd, offset);  if ( buf[2] != 0x72 )    return mmap(addr, len, prot, flags, fd, offset);  if ( buf[3] != 0x12 )    return mmap(addr, len, prot, flags, fd, offset);这与我们开头看到的安装包内的global-metadata.dat的头一模一样，所以基本可以判定，这个就是解密的函数，我们直接hook这个函数的返回值看看：

function print_arg(){    var libtprtaddr = Module.findBaseAddress("libtprt.so");    var libil2cppaddr = Module.findBaseAddress("libil2cpp.so");    console.log("n");    console.log("libtprt基址:",libtprtaddr);    console.log("libil2cpp基址:",libil2cppaddr);    var function_addr = libtprtaddr.add(0x1BCA50);    var hooked = false;    Interceptor.attach(function_addr,{        onEnter:function (args) {            this.len = parseInt(this.context.x1);        },        onLeave:function (returnValue) {            if(!hooked){                hooked = true;                var currentApplication = Java.use("android.app.ActivityThread").currentApplication();                var dir = currentApplication.getApplicationContext().getFilesDir().getPath();                var file_path = dir + "/global-metadata.dat";                var file_handle = new File(file_path, "wb");                if (file_handle && file_handle != null) {                    var buffer = ptr(this.context.x0).readByteArray(this.len);                    file_handle.write(buffer);                    file_handle.flush();                    file_handle.close();                    console.log("[dump]:", file_path);                }            }        }    })}var isCalled = false;function hookdlopen() {    var dlopen = Module.findExportByName(null, "dlopen");    Interceptor.attach(dlopen, {        onEnter: function (args) {            var path = args[0].readCString();            if (path && path.indexOf('libil2cpp.so') !== -1) {                this.path = path;            }        },        onLeave: function (retval) {            if (this.path && this.path.indexOf('libil2cpp.so') !== -1 && !isCalled) {                print_arg();                isCalled = true;            }        }    });}hookdlopen();

这里需要注意，我是测试过这个函数是第一个加载global-metadata的，所以添加了个hooked变量去控制，如果不清楚是什么时候加载global-metadata的话，可以打印this.len看看，一般来说和安装包内的大小差不多，可能会有些许差距

看看内存dump出来的global-metadta吧可以看到，文件头是被抹除了的，但是基本上的内容都还在，我们用UnityMetadata.bt模板跑一遍看看是报错了的，看来内存dump出来的还是有问题，然后我hook了最开始的sub_1684EF0函数，看看会不会在中途继续解密，结果是没有，最后返回的内容还是和之前hook的一样的继续分析吧，我们看看Il2CppGlobalMetadataHeader是什么样子可以看到，除了文件头的四个魔数被抹除了之外，其余的信息是全的，那么问题出在哪里呢，通过Il2CppGlobalMetadataHeader的内容我们可以看到，stringLiteralOffset的值为256，即0x100，那么表示文件内容是从0x100开始的，我们查看0x100处的内容，通过与正常的global-metadata.dat文件进行对比，可以确认这里肯定存在加密（因为正常的global-metadata.dat 0x104处的值必须为0）那怎么办呢？我想到了查看源码，看看源码中有没有调用stringLiteralOffset的地方，通过源码来实现逆向分析。找完整个源码，发现只有一处调用了stringLiteralOffset如何快速定位到这个地址呢？这个函数并没有什么字符串特征，所以并不好通过字符串实现快速定位这里参考了这位大佬的分析思路，通过il2cpp::vm::String::NewLen来找到对应的函数https://notion-blog-wine-gamma.vercel.app/article/genshin_analyze_1查一下他的交叉引用一个个对比，最终定位到sub_16852F0很好，它在调用stringLiteralOffset的时候肯定是进行解密了的，所以我们直接hook这个情况下的GlobalMetadataHeader。我尝试hook加载后的地址，遗憾的是，它并没有走这条路径，也就是说它自实现了一些解密和加载的函数，并没有选择调用原生函数，所以只能另寻出路了这个时候其实已经很难分析了，因为它魔改了的话，对比源码已经没太大效果了。后面我突然想到，他如果进行解密的话，肯定会访问GlobalMetadataHeader的地址，为什么不用监听内存试试呢？说干就干，我首先尝试使用frida的MemoryAccessMonitor来进行监听内存，发现还是hook不到，因为MemoryAccessMonitor原理是使用mprotect来禁止读写执行，进而触发异常被frida监听到，但是mprotect只能针对一整页的内存（大小为0x1000），数据量太大了，并不会有什么效果，所以又要换一种思路，想要单独监听一个内存地址，就只能使用调试器之类的软件了，例如GDB和LLDB，因为我之前并没有使用过这两个调试器，所以选择了我比较熟悉的pwatch，写了个frida脚本来配合pwatch

function stop(){    var libtprtaddr = Module.findBaseAddress("libtprt.so");    var libil2cppaddr = Module.findBaseAddress("libil2cpp.so");    console.log("n");    console.log("libtprt基址:",libtprtaddr);    console.log("libil2cpp基址:",libil2cppaddr);    var function_addr = libil2cppaddr.add(0x1684F68);    Interceptor.attach(function_addr,{        onEnter:function (args) {            console.log(`./arm_64 -t -b ${Process.getCurrentThreadId()} rw8 ${this.context.x0.add(0x100)}`)            console.log("开始暂停");            // 暂停当前线程 10 秒            const startTime = Date.now();            while (Date.now() - startTime < 10000) {            }            console.log("恢复线程");        },        onLeave:function (returnValue) {        }    })}

为什么hook 0x1684F68呢，因为这是在前面sub_1685100函数运行成功后的下一个地址，在刚加载完就进行hook，可以有效避免其他情况影响

frida打印为：pwatch打印为：距离tprt和il2cpp最近的地址是0x7e906848e8，减去libtprt的基址0x7e904c3000，得到0x1C18E8，直接去tprt里面看看查看一下当前地址所在的函数sub_1C1884吧因为堆栈中显示的是lr寄存器，也就是调用的地址+4，所以可知读取stringLiteral的函数是sub_1BDB94，这样其实看伪c已经能看出来很多东西了，因为v5 + v7 + 8LL * a2这个结构，很类似于((const char*)s_GlobalMetadata + s_GlobalMetadataHeader->stringLiteralOffset) + index，进去sub_1BDB94里面看看直接看跟返回值唯一有关的函数sub_1C1C48终于找到解密点了，查看该函数，容易分析出参数1是加密的内容，参数2是长度，参数3是加密值，打印一下看看看来分析的没错，长度应该固定为8，前面解释过了，加密值怎么获取的呢？往上层分析，在sub_1BDB94中可以看到，加密值为v9 ^ a4，v9 = sub_9241C(v8, 0LL)，a4则为sub_1BDB94的参数先打印看看这两个是不是固定值，hook后发现v9为固定值，a4则为当前的偏移量，最后根据sub_1C1C20写一个相同的脚本就行了，解密出来后发现都恢复了注意到sub_1C1884中，通过sub_1BDB94获取到v8后，在下面还进行了一处调用，通过对比源码，可以猜测下面的函数中包括stringLiteralData的解密函数，跟进去看了确实如此，同样写一个解密脚本进行还原即可后记这篇文章年前就准备写了，只是一直偷懒导致拖了许久。文章中写的都是我最开始尝试时用到的方法，其实还有很多地方可以进行优化，比如在定位解密函数时，是可以hook il2cpp_string_new_len这个导出函数通过打印堆栈来定位到的，当然，这个都是后话了，hook il2cpp_string_new_len并不如我原文中写的方法具体代表性，因为它完全可以自实现这个函数，只不过并没有罢了。文章写到这里其实是并没有完结的，此时使用il2cppdumper还是会报错，metadata里的数据并没有高熵了，那么有问题的地方应该就是il2cpp.so了，但是在写完这篇文章前，我已经没有在玩那个游戏了，耗费这个精力对我来说并不值得。如果评论区有知道的朋友，望不吝赐教