当前位置：首页 > news >正文

对一手游的自定义 luajit 字节码的研究

news 文章来源：https://blog.csdn.net/jmm18363027827/article/details/135680025 2025/5/19 5:01:55

对一手游的自定义 luajit 字节码的研究

前言

最近闲下来之后无聊研究起了一个unity手游大量使用了 lua （或者说就是 lua 写的）看到网上已有的一些针对方案都觉得太不方便于是深入研究了一下他自定义的 luajit

情况研究

首先这是一个 unity的传统手游这里就跳过较为前期的部分

像是 libtersafe . libbugly . libcri_ware 这些都是老熟人了都跳过

unity 的 lua 通信方案

对于 unity游戏来说特别是商业手游热更新几乎是必须的

由此诞生很多方案这里简单介绍几个重点

hybridclr

- c# 原生热更新
xlua
- 代表新兴 lua 框架
- 有详细的文档！
tolua
- 代表老一代 lua 框架

luac 与 luajit 的关系

以下来自 gpt

LuaC 和 LuaJIT 都是与 Lua 编程语言相关的工具，但它们的用途和性能特点有所不同。

LuaC:

LuaC 是 Lua 的标准字节码编译器。它是 Lua 解释器的一部分，用于将 Lua 源代码编译成字节码。这个过程通常是为了提高代码的加载速度和执行效率。
LuaC 生成的字节码可以在任何 Lua 虚拟机上运行，确保了跨平台的兼容性。
它是 Lua 发行版的标准组成部分，通常用于开发环境或当脚本需要预编译以隐藏源代码时。

LuaJIT:

LuaJIT 是一个独立的 Lua 编译器，它使用即时编译（JIT）技术来提高 Lua 代码的执行速度。LuaJIT 能够在运行时将 Lua 字节码转换成机器码，这通常可以显著提高性能。
LuaJIT 与 Lua 5.1 版本高度兼容，但也引入了一些自己的扩展和优化。
它特别适合于性能敏感的应用，如高性能服务器、游戏、或实时系统。
LuaJIT 的性能通常远超标准 Lua 解释器，尤其是在复杂或计算密集型任务中。

总的来说，LuaC 更多地关注于代码的移植性和标准化，而 LuaJIT 更专注于提高执行效率和性能。用户可以根据自己的需要选择使用 LuaC 还是 LuaJIT。

luac 和luajit的字节码一致吗 api呢

LuaC 和 LuaJIT 在字节码和 API 方面存在一些差异：

字节码兼容性:

LuaC 和 LuaJIT 生成的字节码不完全一致。LuaC 遵循 Lua 官方的标准，为特定版本的 Lua（如 Lua 5.1, Lua 5.2 等）生成相应的字节码。LuaJIT 也能够编译为字节码，但它的字节码格式是为 JIT 编译器优化的。
由于 LuaJIT 主要与 Lua 5.1 兼容，它的字节码在某种程度上与 Lua 5.1 的字节码相似。然而，由于 JIT 优化的原因，LuaJIT 生成的字节码可能在某些情况下与标准 Lua 字节码不兼容。
这意味着用 LuaC 编译的字节码可能无法在 LuaJIT 上正确运行，反之亦然。
API 兼容性:

在 API 层面，LuaJIT 与 Lua 5.1 高度兼容。它支持 Lua 5.1 的全部标准 API，并且引入了一些自己的扩展。这些扩展主要是为了提高性能和扩展功能。
如果你的 Lua 代码是针对 Lua 5.1 API 编写的，那么它在 LuaJIT 上应该可以无缝运行。但如果你使用了 LuaJIT 的特定扩展，那么这部分代码可能无法在标准 Lua 解释器上运行。
综上所述，虽然 LuaC 和 LuaJIT 在很多方面是兼容的，但在字节码和特定 API 的使用上存在一些差异。如果你的项目需要在不同环境中移植，需要特别注意这些差异。对于大多数应用来说，这些差异并不会造成显著问题，但在高性能或特定的应用场景下，选择合适的工具是非常重要的。

准备环境

分析之前我们现确定一下目标

让使用 luajit 的应用能执行我们提供的 lua 代码

luajit 源码
库源码

xlua , tolua 等等都是开源的而且区别主要在和 c#对接的部分对于我们需要研究的部分差别不大

vs （用于分析 c 源码和 c# 源码）
vsc （用于分析编写 lua 和 js / ts ）
python ( 自动化工作流， frida )
node ( 编译 ts )
010editor （分析二进制 lua bc）
ida ( 分析修改后的luajit )

最好吧 unity 也带上方便需要问题可以用 unity 实际测试一下

手游分析

app 分析

在 app 中我们可以直接看到 libxlua.so , libil2cpp.so

frida / frida-il2cpp

直接用 frida 为了方便使用 frida-il2cpp 我们创建一个 node 项目

添加库并配置 ts 环境

@types/node

@types/frida-gum

frida-compile

frida-java-bridge

frida-il2cpp-bridge

添加命令

frida-compile src/index.ts -o dist/_agent.js -c
frida -Uf xxx -l dist/_agent.js

（ frida js 运行在手机上运行麻烦使用 ts 可以避免语法错误并享受 js 生态）

在 index.ts 中开始 hook

我们先使用Il2Cpp.perform(()=>{console.log("OK")}) 确认il2cpp 能够被正常 hook

然后我们就可以使用 il2cpp 获取由元数据的来的c#代码函数签名信息

            const destination = 		`${Il2Cpp.applicationDataPath}/${dirName}`;for (const assembly of Il2Cpp.Domain.assemblies) {const path = `${destination}/${assembly.name}.cs`const file = new File(path, "w");for (const klass of assembly.image.classes) {file.write(`${klass}\n\n`);}file.flush();file.close();}

这一步其实和文章主题关系不大这里的手游 c# 层也没有特别的内容

说明在 c#层没有修改内容

接着我们看向 luaEnv 类这里就有由 lua 框架映射而来的多数 lua基础 api

（在 so 库中也能看到接口）

这里我们直接尝试使用 DoString 方法来执行我们提供的 lua 代码

this.AssemblyCSharp = Il2Cpp.Domain.assembly('Assembly-CSharp').image;
this.AssemblyCSharp.class("LuaEnv").method("DoString").implementation = function (bytes: Il2Cpp.Array<Il2Cpp.Object>, name: Il2Cpp.String) {
if(name !== undefined && name?.content=="@main.lua"){this.method("DoString").Invoke(Il2Cpp.String.from(`print("我的 lua 代码。。。")`),Il2Cpp.String.from(`@test.lua`))
}
}

faq 我怎么知道是 main.lua 你可以先打印他们的名字啊

faq 为什么要在执行 main.lua 之后执行因为这样才能获取到他代码注册的内容

题外话记得去把 log hook 了才能看到输出

frida-il2cpp 提供了 log Il2Cpp.installExceptionListener("all");

lua 框架大概率也有logger 可以 hook lua框架的 logger 将输出复一份到 frida上面来

然而很神奇的事情发生了程序直接崩溃了

在反复排除了各种东西之后不得不打开 ida 分析 so 库

好在lua 框架是讲他自己的代码链接到 luajit 上的也就是说我们可以对照 luajit 的源码

题外话 win 上可以使用 msvc 编译 luajit 参考 luajit 官网教程记得把 -O2 改成 -Od 开启 debug 模式

直接定位到核心的 lua 代码加载函数 lua_loadx -> cpparser

手游的 so 库里面的

*(a1[10] + 196LL) = -1;

v5 = (loc_43480)();

if ( !*(a3 + 136) )

{

if ( v5 )

goto LABEL_4;

return 0LL;

}

if ( v5 )

{

if ( strchr(*(a3 + 136), 'b') )

{

LABEL_4:

v6 = sub_45740(a3);

v7 = sub_351F0(a1, v6, a1[9]);

v8 = a1[5];

a1[5] = v8 + 1;

*v8 = v7 | 0xFFFB800000000000LL;

return 0LL;

}

goto LABEL_8;

}

if ( strchr(*(a3 + 136), 't') )

return 0LL;

LABEL_8:

v10 = a1[5];

a1[5] = v10 + 1;

*v10 = sub_3142C(a1, 2100LL) | 0xFFFD800000000000LL;

v11 = sub_3123C(a1, 3LL);

return lua_loadx(v11, v12, v13, v14, v15);

}

编译的 so 库里面的

*(a1[10] + 196LL) = -1;

v5 = (loc_426F8)();

if ( !*(a3 + 136) )

{

if ( v5 )

goto LABEL_4;

goto LABEL_6;

}

if ( !v5 )

{

if ( !strchr(*(a3 + 136), 't') )

goto LABEL_9;

LABEL_6:

v6 = sub_49D8C(a3);

goto LABEL_7;

}

if ( strchr(*(a3 + 136), 'b') )

{

LABEL_4:

v6 = (loc_4A8A8)(a3);

LABEL_7:

v7 = sub_349F0(a1, v6, a1[9]);

v8 = a1[5];

a1[5] = v8 + 1;

*v8 = v7 | 0xFFFB800000000000LL;

return 0LL;

}

LABEL_9:

v10 = a1[5];

a1[5] = v10 + 1;

*v10 = sub_30C08(a1, 2100LL) | 0xFFFD800000000000LL;

sub_30A10(a1, 3LL);

v12 = v11;

v15 = v13;

if ( !feof(*v13) && (v14 = fread(v15 + 1, 1uLL, 0x400uLL, *v15), (*v12 = v14) != 0) )

result = v15 + 1;

else

result = 0LL;

return result;

}

源码

// lj_load.c

LUA_API int lua_loadx(lua_State *L, lua_Reader reader, void *data,

const char *chunkname, const char *mode)

{

LexState ls;

int status;

ls.rfunc = reader;

ls.rdata = data;

ls.chunkarg = chunkname ? chunkname : "?";

ls.mode = mode;

lj_buf_init(L, &ls.sb);

status = lj_vm_cpcall(L, NULL, &ls, cpparser);

lj_lex_cleanup(L, &ls);

lj_gc_check(L);

return status;

}

static TValue *cpparser(lua_State *L, lua_CFunction dummy, void *ud)

{

LexState *ls = (LexState *)ud;

GCproto *pt;

GCfunc *fn;

int bc;

UNUSED(dummy);

cframe_errfunc(L->cframe) = -1; /* Inherit error function. */

bc = lj_lex_setup(L, ls);

if (ls->mode && !strchr(ls->mode, bc ? 'b' : 't')) {

setstrV(L, L->top++, lj_err_str(L, LJ_ERR_XMODE));

lj_err_throw(L, LUA_ERRSYNTAX);

}

pt = bc ? lj_bcread(ls) : lj_parse(ls);

fn = lj_func_newL_empty(L, pt, tabref(L->env));

/* Don't combine above/below into one statement. */

setfuncV(L, L->top++, fn);

return NULL;

}

题外话手游的 so 库开了优化一些没有注明要内联的函数也被内联了看着会有些不一样

不难发现他直接少了 t 选项查阅 lua 官网可知

lua加载代码分为 b (从字节码加载) t (从文本加载 )

而进一步的分析发现这个手游直接把 t 模式整个删了（没绷住）

随后进一步的对比分析发现不仅仅是加载字节码的模式而是真个字节码都被加密了下面的章节会详细介绍

已有的破解分析

在网上搜索时发现了另一种思路

即通过 lua 暴露的 c api 来控制 lua

lua_gettop

lua_pop

lua_pushvalue

lua_pcall

lua_pushstring

这样也可变相的实现控制逻辑而且由于这些暴露的接口对于框架交互来说是必须的也不用太担心这里会被做手脚但是这个方案只能进行简单的更改对于外挂之类的来说可能比较有用

不过这里也提供另类的思路

由于 lua 的特殊性 lua 运行时本身是无状态的理论上我们可以将 lua_state 直接交给另一个 lua 虚拟机来执行

不过这个方案并不能运用在这里这里由于是游戏有大量的网络请求涉及到协程 lua 会将协程信息放在 lua 共有的 global 段中这样的话就不是无状态了

另一种思路是修改一个 lua 虚拟机将其最终执行的命令记录并转发给我们这里的 lua 虚拟机得益于 lua 本身的简单这并非不可能像 fengari 库直接在原始 js 中实现了 lua vm ，如果对他进行一下修改后集成在 frida 中也许可以实现

原始 luajit bytecode 分析

最后我们还是老老实实的分析他加密后的 bytecode 不过在分析加密的之前我们得先搞清楚原始的

题外话大佬提供的 010 的 bt 模板在我这里似乎有版本兼容问题

没有函数 parentof() 即获取节点的父节点

不过这个可以直接在父节点处

把父节点自己作为参数传给子节点来绕过这个函数

自定义 bytecode 分析与对应实现

为了更好的分析游戏的 lua bytecode 这里我们需要找一个游戏中有的（加密过后的文件）同时我们也有源码的 lua 文件（加密前的文件）

这样的文件我们可以去找框架的 lua 代码让后使用 frida hook loadbuffer 函数并判断名称然后 dump 下来

顺带我们打开一个 python 并编写

这里我们进行超级多开

ida - 目标游戏的 so 库
ida - 自编译的 so 库
vs - luajit 源码
vsc - python 代码（编写加解密脚本）
010 - 游戏的lua字节码
010 - 原始的 lua字节码

我们可知原始 luajit 字节码的结构

GlobalHeader 头部
多个 Proto 函数体
- header 头部
  - size
  - flags
  - arg_count
  - framesize
  - upvalue_count
  - complex_constants_count
  - numeric_constants_count
  - instructions_count
- insts 指令
  - 4 个字节一组详见上一张大佬的文章
- constants 常量
  - upvalue
  - complex
    - CHILD = 0
      
      TAB = 1
      - tab 还会进一步细分为键和值或仅值（lua特色）
      I64 = 2
      
      U64 = 3
      
      COMPLEX = 4
      
      STR = 5 大于 5 的都是字符串字符串长度为值-5
  - numberic
最后以一个 size 为 0 的 proto 结束

而 luajit 解析这是

GCproto *lj_bcread(LexState *ls)

{

lua_State *L = ls->L;

lj_assertLS(ls->c == BCDUMP_HEAD1, "bad bytecode header");

bcread_savetop(L, ls, L->top);

lj_buf_reset(&ls->sb);

/* Check for a valid bytecode dump header. */

if (!bcread_header(ls))

bcread_error(ls, LJ_ERR_BCFMT);

for (;;) { /* Process all prototypes in the bytecode dump. */

GCproto *pt;

MSize len;

const char *startp;

/* Read length. */

if (ls->p < ls->pe && ls->p[0] == 0) { /* Shortcut EOF. */

ls->p++;

break;

}

bcread_want(ls, 5);

len = bcread_uleb128(ls);

if (!len) break; /* EOF */

bcread_need(ls, len);

startp = ls->p;

pt = lj_bcread_proto(ls);

if (ls->p != startp + len)

bcread_error(ls, LJ_ERR_BCBAD);

setprotoV(L, L->top, pt);

incr_top(L);

}

if ((ls->pe != ls->p && !ls->endmark) || L->top-1 != bcread_oldtop(L, ls))

bcread_error(ls, LJ_ERR_BCBAD);

/* Pop off last prototype. */

L->top--;

return protoV(L->top);

}

其中 bc 开头的函数都是读取对应部分的函数重点在于lj_bcread_proto 这个函数

包含了分析 proto 这个重要结构的代码

由于编译器将很多子函数的代码内联了进来导致这个函数很大不过不要怕我们有原程序进行对比这里就不完整将函数代码贴上来了

第一部分读取 proto 头部

ls_p = *(ls + 32);

*(ls + 32) = ls_p + 1;

ph_b1_framesize = *ls_p;

*(ls + 32) = ls_p + 2;

ph_b2 = ls_p[1];

*(ls + 32) = ls_p + 3;

flags = ph_b2 ^ ph_b1_framesize;

ph_b3 = ls_p[2];

*(ls + 32) = ls_p + 4;

v6 = (ls + 32);

numparams = ph_b3 ^ ph_b2 ^ ph_b1_framesize;

ph_b4 = ls_p[3];

sizekn = bcread_uleb128((ls + 32));

sizeuv = ph_b4 ^ numparams;

sizekgc = bcread_uleb128(v6);

sizebc_1 = bcread_uleb128(v6);

sizebc = sizebc_1 + 1;

不难发现他进行了异或将函数头的参数互相异或了并修改了部分参数的位置

这里我们直接让 gpt 给出逆函数

当然，让我总结一下我们找到 (fl) 函数反函数的过程：

问题描述: 您提供了一个名为 (fl) 的函数，它对一个四元素的元组 (t)（具体为 (0, 1, 2, 3)）进行一系列异或（XOR）操作，生成一个新的四元素元组。您询问如何找到 (fl) 函数的反函数，即如何从 (fl) 函数的输出恢复出原始输入。

(fl) 函数的分析: (fl) 函数通过以下方式操作：

(o1 = t[0])
(o2 = t[1] \oplus o1)
(o3 = t[2] \oplus o2)
(o4 = t[3] \oplus o3)

逆函数的构建: 我们尝试了几种不同的方法来构建这个逆函数，关键在于理解 XOR 操作的自反性和如何正确地逆向每一步操作。

最终解决方案: 经过一系列尝试和错误，我们找到了正确的逆函数。这个逆函数通过以下方式恢复原始 (t) 值：

从 (o4) 开始，因为 (o4 = t[3] \oplus o3)，所以 (t3 = o4 \oplus o3)。
依此类推，我们逆向每一步操作，最终恢复出 (t0, t1, t2, t3)。

验证和结果: 逆函数成功地验证了，它能够准确地从 (fl) 函数的输出恢复出原始输入 (0, 1, 2, 3)。

1

2

3

4

5

6

7

8

9

10

11

12

13

def fl(t):

    o1 = t[0]

    o2 = t[1] ^ o1

    o3 = t[2] ^ o2

    o4 = t[3] ^ o3

    return o1 , o2 , o3 , o4

def fl_inverse(t):

    t3 = t[3] ^ t[2]

    t2 = t[2] ^ t[1]

    t1 = t[1] ^ t[0]

    t0 = t[0]

    return t0, t1, t2, t3

这样我们可以先编写proto 的 python

t = (self.framesize[0],self.flags[0],self.argcount[0],self.upvc[0])

a1 , a2 , a3 , a4 = fl_inverse(t)

assert t==fl((a1 , a2 , a3 , a4))

WriterUtil.write_byte(stream,a1)

WriterUtil.write_byte(stream,a2)

WriterUtil.write_byte(stream,a3)

WriterUtil.write_byte(stream,a4)

WriterUtil.ULeb128Write(stream,self.ncc)

WriterUtil.ULeb128Write(stream,self.ccc)

WriterUtil.ULeb128Write(stream, self.instc)

而对于指令

do

{

v21 = *(v18++ + 3);

v22 = v20++ ^ v21;

v23 = *(v18 - 3);

*(v18 - 1) = v22;

*(v18 - 3) = ~v23;

}

while ( v20 != sizebc_1 );

结合 010 我们可以发现对于指令的 4 个数 op , a1 ,a2, a3

首先他 opcode 都更改了但是是一一对应的
其次根据代码不难发现
- a1 为 ~a1&0xff
- a2 不变
- a3 为 a3^idx&0xff 其中 idx 为指令个数

对于指令好在他虽然打乱顺序了但是没有完全打乱

他只是按照 lj_bc.h 中指令的大块打乱了相邻的指令依然是连续的

结合之后获取的更多的 lua 样本和其他模板的解密指令基本能够恢复

（就算不能完全恢复常用指令也能够恢复对于达成目标并不影响）

class LuaJitInstruction:

def __init__(self,stream,idx) -> None:

self.idx = idx

self.op = ReaderUtil.read_byte(stream)

self.a1 = ReaderUtil.read_byte(stream)

self.a2 = ReaderUtil.read_byte(stream)

self.a3 = ReaderUtil.read_byte(stream)

def dump(self,stream):

if not NEED_OBUF:

WriterUtil.write_byte(stream,self.op)

WriterUtil.write_byte(stream,self.a1)

WriterUtil.write_byte(stream,self.a2)

WriterUtil.write_byte(stream,self.a3)

else:

WriterUtil.write_byte(stream,OP().OPtoOBOP(self.op[0]))

WriterUtil.write_byte(stream,~self.a1[0]&0xff)

WriterUtil.write_byte(stream,self.a2)

WriterUtil.write_byte(stream,(self.a3[0]^self.idx)&0xff)

接下来对于字符串我们能在 ida 中看到一串很恐怖的大量代码

if ( _loop_next_len - 6 <= 14 )

{

v40 = 0;

LABEL_28:

ls_p_1[v40 / 0x10].n128_u8[0] = ~ls_p_1[v40 / 0x10].n128_u8[0] ^ v40;

if ( loop_len > v40 + 1 )

{

ls_p_1[v40 / 0x10].n128_u8[1] = ~ls_p_1[v40 / 0x10].n128_u8[1] ^ (v40 + 1);

if ( loop_len > v40 + 2 )

{

ls_p_1[v40 / 0x10].n128_u8[2] = ~ls_p_1[v40 / 0x10].n128_u8[2] ^ (v40 + 2);

if ( v40 + 3 < loop_len )

{

ls_p_1[v40 / 0x10].n128_u8[3] = ~ls_p_1[v40 / 0x10].n128_u8[3] ^ (v40 + 3);

if ( v40 + 4 < loop_len )

{

ls_p_1[v40 / 0x10].n128_u8[4] = ~ls_p_1[v40 / 0x10].n128_u8[4] ^ (v40 + 4);

if ( loop_len > v40 + 5 )

{

ls_p_1[v40 / 0x10].n128_u8[5] = ~ls_p_1[v40 / 0x10].n128_u8[5] ^ (v40 + 5);

if ( loop_len > v40 + 6 )

{

ls_p_1[v40 / 0x10].n128_u8[6] = ~ls_p_1[v40 / 0x10].n128_u8[6] ^ (v40 + 6);

if ( loop_len > v40 + 7 )

{

ls_p_1[v40 / 0x10].n128_u8[7] = ~ls_p_1[v40 / 0x10].n128_u8[7] ^ (v40 + 7);

if ( loop_len > v40 + 8 )

{

ls_p_1[v40 / 0x10].n128_u8[8] = ~ls_p_1[v40 / 0x10].n128_u8[8] ^ (v40 + 8);

if ( loop_len > v40 + 9 )

{

ls_p_1[v40 / 0x10].n128_u8[9] = ~ls_p_1[v40 / 0x10].n128_u8[9] ^ (v40 + 9);

if ( loop_len > v40 + 10 )

{

ls_p_1[v40 / 0x10].n128_u8[10] = ~ls_p_1[v40 / 0x10].n128_u8[10] ^ (v40 + 10);

if ( loop_len > v40 + 11 )

{

ls_p_1[v40 / 0x10].n128_u8[11] = ~ls_p_1[v40 / 0x10].n128_u8[11] ^ (v40 + 11);

if ( loop_len > v40 + 12 )

{

v50 = v40 + 13;

ls_p_1[v40 / 0x10].n128_u8[12] = ~ls_p_1[v40 / 0x10].n128_u8[12] ^ (v40 + 12);

if ( loop_len > v40 + 13 )

{

v51 = v40 + 14;

ls_p_1->n128_u8[v50] = ~ls_p_1->n128_u8[v50] ^ v50;

if ( loop_len > v51 )

ls_p_1->n128_u8[v51] = ~ls_p_1->n128_u8[v51] ^ v51;

}

else

{

v41 = ls_p_1;

v42 = 0;

v43 = xmmword_45730;

do

{

v44.n128_u64[0] = 0x400000004LL;

v44.n128_u64[1] = 0x400000004LL;

v45.n128_u64[0] = 0xC0000000CLL;

v45.n128_u64[1] = 0xC0000000CLL;

++v42;

v46 = vaddq_s32(v43, v44);

v44.n128_u64[0] = 0x800000008LL;

v44.n128_u64[1] = 0x800000008LL;

v47 = vaddq_s32(v43, v45);

v48 = vmovn_hight_s32(vmovn_s32(v43), v46);

v45.n128_u64[0] = 0x1000000010LL;

v45.n128_u64[1] = 0x1000000010LL;

v49 = vaddq_s32(v43, v44);

v43 = vaddq_s32(v43, v45);

*v41 = veorq_s8(vmovn_hight_s16(vmovn_s16(v48), vmovn_hight_s32(vmovn_s32(v49), v47)), vmvnq_s8(*v41));

++v41;

}

这一大串看着多其实很简单大部分内容都是由于编译器为了加快异或而生成的代码下面xmmword这些其实是 SIMD 指令集

整段代码其实就是

1 2	`def` `stringOBUF(s: bytes)` `-> bytes:` `return` `bytes([( (~e &` `0xff) ^ i)` `for` `i, e` `in` `enumerate(s)])`

将字符串按位求反异或而这个操作的逆函数就是他自身

还有一些其他大大小小的更改如更换位置等

这里就不贴上来了

最后写一个自动编译生成的工作流结合之前的 ts 代码

LUAJIT_PATH = os.path.join("LuaJIT", "luajit64.exe")

LUA_PATH = os.path.join("HookScript", "LuaCode", "main.lua")

LUA_BC_PATH = os.path.join("HookScript", "dist", "_agent.lua.bc")

OUTDATA_PATH = os.path.join("HookScript", "src", "hooks", "luadata.ts")

subprocess.run([LUAJIT_PATH, "-b",os.path.join("..",LUA_PATH),os.path.join("..",LUA_BC_PATH)], cwd='LuaJIT') # f"{LUAJIT_PATH} -b {LUA_PATH} {LUA_BC_PATH}"

with open(LUA_BC_PATH,'rb') as f:

data = LuaJitBC(f.read()).dump()

luats = ["""export const luadata = [\n"""]

luats.append(",".join([hex(i) for i in data])+"\n")

luats.append("]\n")

with open(OUTDATA_PATH,'w') as f:

f.writelines(luats)

subprocess.run(["pnpm","i"],cwd="./HookScript",shell=True)

subprocess.run(["pnpm","run","phone"],cwd="./HookScript",shell=True)

在 frida 中我们直接 hook dll 的对应函数使用 frida 创建调用

这里核心就 lua_loadbuffer 一个函数其他都是为了不让我们插入的代码破坏 lua 的原始堆栈引发程序崩溃的保护措施

public LuaLoad(data:Array<number>,chunkName:string){this.lua_pushtraceback(this.lua_state)const oldTop = this.lua_gettop(this.lua_state)const prtbuffer = Memory.alloc(data.length+1)prtbuffer.writeByteArray(data)const ckn = Memory.allocUtf8String(chunkName)console.log(`allocing ${data.length} mem`)console.log(`[lua] LuaLoad execing as oldTop:${oldTop} and buffer at ${prtbuffer.toString(16)}`)if(this.lua_loadbuffer(this.lua_state,prtbuffer,data.length,ckn)==0){if(this.lua_pcall(this.lua_state,0,-1,0)==0){this.lua_settop(this.lua_state,oldTop-1);console.log("[lua] LuaLoad exec finished!")return;}}const errlen = new NativePointer(0)const errptr = this.lua_tolstring(this.lua_state,-1,errlen)let errmsg:stringtry{if(errlen.isNull()){errmsg = errptr.readUtf8String() || ""}else{errmsg = errptr.readUtf8String(errlen.toInt32()) || ""}console.error(errmsg)console.error("[lua] failed to exec")}catch(e){console.error(e)console.log("[lua] failed to load errmsg")}this.lua_settop(this.lua_state,oldTop-1);return}

尾声

在成功植入 lua 代码之后参考 unlua 写了反编译我们就可以直接使用 lua 代码来 hook 并插入内容了

local org_func = target_class.target_func
target_class.target_func = function (self, args)-- doxxx beforeorg_func(self,args)-- doxxx after
end

文章没有写的很详细考虑到文章核心是介绍 lua bc 其他部分就都简化了

有什么问题欢迎在文章下提问