题目给了一个 exe 文件和一个 out 文件，猜测是使用 exe 去加载 out 的脚本。out 似乎被加密过了，看不出来是什么文件格式。

ida7.6 打开，exe 是 golang 写的，函数名都被混淆了。

因为 gopclntab 的 magic 是 0xFFFFFFFA ,所以肯定是 go 1.16 版本以上。这里和 go 1.17 的 bindiff 结果最接近，导入 Matched Functions ，恢复大部分 go 函数，找到 main_main。

题目直接运行提示 usage: new_lang binfile ，后面加上给的 out 文件的路径以后正常运行，所以下断 ReadFile。

回溯，runtime_asmstdcall 这类 go 内置函数直接略过，第一个混淆名字的函数 dazZVaWekDxmHOBm

经典 syscall_ptr_LazyProcFind ，还是处于 go 的函数中，继续往上，直到 hDwRGqXZOHitsyulULeUIiCTqaedCidWS。

解密以后就看出来是 lua ，但是文件的 magic 和版本信息好像不太对

函数 ZjulCvXVFufJHreFwkLSR

这里确认是 lua，因为 size_t size 是 8，所以要编译 64 位的 luadec ，但是反编译不出来，怀疑替换了 opcode_table。

程序里有 luago 的字符串， github 搜了一下，找到了源码，https://github.com/zxh0/lua.go 。 git 上有很多 luago 的版本，可是都没实现 stdlib 的 string.dump 函数，而 exe 可以用这个函数，用这个判断。

LnNZNVGrFxUawfmfFtLuzZZpawrA 就是项目中 api_call.go 的 Load 函数。

尝试三种方法找到 opcode_table 的位置：

搜索字符串 MOVE 等，失败（因为出题人把 opcode 的名称都改成了 NONNAME）

根据函数调用关系找到 Execute，得到 opcodes

在 LnNZNVGrFxUawfmfFtLuzZZpawrA （Load）函数返回后，对于每一个 call ，都 F8 ，如果跑飞了，那说明 Execute 在这个 call 里，重复这个过程缩小范围（感觉有时间可以写个小工具，还是挺实用的方法）

off_51FD90 即为 opcode_table 的指针。

红框里的为一组 opcode 的结构，大小 0x20，opcode 的名称被出题人都改成一样的了。这里没法从这判断顺序。尝试两种方法：

特别感谢这位老哥，思路非常牛逼，让相同的代码在题目和我们自己编译的 lua.go 中跑，dump 出两个代码，进行对比，得到 opcode 的顺序。

我修改了一下，帮他补上了 lua 5.3 版本新增的 opcode

check_opcode.lua 要小改一下，主要把 5.1 的 opcode 换成 5.3 的

也要注意这句，因为我们的文件头和版本和原来肯定是不一样的，不要把他们也算在 opcode 的变化里了

写了个小脚本用来试 opcode（毕竟一次很难补全）

这里有几个 -1 （opcode 没有使用或者和原来一样），我们手动处理一下，首先 OP_LOADKX 和 OP_EXTRAARG 直接跟原来的值一样即可，因为根本不会用到，中间的 BXOR 是因为跟原来一样。

然后修改 luadec 中的 lopcodes.h

编译 luadec ，把 new_lang_script.out 的文件头改一下 LuaS，反编译。

逻辑很清楚，但是第 9 位到第 17 位这 9 位 flag 的验证缺失，是在 local flag1 = _(flag) 验证的，应该是个 native 函数。

找到 Execute，对运行指令的位置下断点，一直 F9，直到 flag 读入，对第 9 位下断点，断两次以后来到关键函数。

就是个异或，然后把 flag 拼起来就行了。

总结：学到了很多，下次出题把 lua 明文执行的接口删掉

[招生]系统0day安全班，企业级设备固件漏洞挖掘，Linux平台漏洞挖掘！