CTF对抗-[推荐]hack.lu 2024 Getting into Shape wp

题目附件给了一个tff(TrueTypeFont)文件,在该文件中嵌入一个wasm, 该wasm文件的源码通过rust编写，该代码写了flag的checker部分，checker部分算法使用chacha20加密,通过字体的控制完成映射，并显示，显示结果：

flag错时：

flag对时：

首先将ttf文件放到010 editor中观察

在ttf最后一个成员gasp 后往下的一部分 出现asm（wasm的magic number）

推测这里是嵌入了wasm文件（实际就是harfbuzz中可选的wasm shaper）

使用python脚本提取：

end的选取 在使用wasm2wat等工具时会报错，根据报错逐渐调整end

可以看到结尾的‘字符串’是/+.\S*$/的格式, 按照这个规律challenge的wasm的end应在这里：

当然也可以自己编译一个wasm比较一下，下面是我自己编译的demo.wasm(wasm-pack 构建rust项目)[[how to Compile a WebAssembly module from rust](https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_Wasm)]

对于wasm的文件处理可以使用wasm2c或者wasm2js

这里使用wasm2c 对wasm文件进行处理

实际不管使用wasm2c 还是 wasm2js, 代码形式和汇编差不多，并没有多少简化

wasm2c反编译出来的数据是16进制显示，wasm2js是base64编码，这对于我们分析字符串都不方便，这里使用wasm2wat查看dcmp文件中的字符串：

可以看到有关于flag的正则表达式：flag{([^{}]*)

关键的.rs,如arfbuzz-wasm-examples/harfbuzz-wasm/src/lib.rs， google一下就会知道，这是github项目，在该仓库中我可以找到在m1上可以使用harfbuzz的工具：https://github.com/harfbuzz/harfbuzz-wasm-examples/tree/main/fontgoggles-wasm-m1

正是前面提到的查看flag checker运行结果的程序

这里查看wasm2c反编译出来的c语言，太长，太多，总共有41万行，找个函数引用vscode都会卡住

人工分析显然是不太可能，这是我编写了一个对“flag{([^{}]*)”所在缓冲区的引用搜集

在wasm2c该缓冲区为：

加载位置：

下面使用python脚本对1048576-101048576+1061处所有的引用进行提取

运行结果：

这里为两个checker的结果输出字符串的引用

“expand 32-byte”为slasa20流密码家族中magic number

因为wasm程序不管怎么转化，始终都是‘汇编’的形式，又臭又长，所以我们的逆向还是要回归到这些汇编细节上，所以我们必须要了解这些算法在汇编层次上的不同

根据‘expand 32-byte k’我们知道了程序使用了salsa20家族中的某一个流密码算法

salsa20 流密码家族包括：

Xsalsa20 是Salsa20的改进，chacha20是Salsa20的变种，同理Xchacha20是在chacha20基础上的改进

初始矩阵为64字节的4*4的32bits数组，分为4个部分：

并且具体的分布也不同：

salsa20 与 chacha20都基于ARX，包括32 bit 的加法，异或，旋转

在代码上体现为QR()函数:

salsa20与chacha20都会进行20轮QR(),其中10轮偶数轮，10奇数轮

其中具体参与运算的块也不尽相同，具体如下：

salsa20:

chacha20:

最后体现在代码上（C语言）：

具体参考了这篇论文：https://cr.yp.to/snuffle/xsalsa-20110204.pdf

初始状态矩阵不同：

初始状态矩阵x：

Xslasa20在slasa20的基础上使用192bit的nonce，其中x6,x7,x8,x9为nonce，其他与slasa20相同

你可能注意到counter部分消失了，流密码没有counter怎么能行，其实这部分在Hslasa20实现了：

HSlasa20是XSalsa20独有的部分，并在Xsalsa20中首先运行，来产生额外的64bits nonce和64bits counter

Hslasa20根据Xslasa20的初始矩阵，产生256 bits的数据(z0,z1,...,z15)

为什么是256bits

因为根据安全考虑，hslasa20会任意的丢弃一般的256bits，相关细节请参考上面的论文。

如在论文的例子里丢弃了(z0,z5,z10,z15,z6,z7,z8,z9).

Xslasa20随后根据(z0,z1,...,z15) 补充额外的64bits nonce和64bits counter（摘抄自论文）：

随后便是和slasa20一样的流程。

看slasa20与chacha20，就看初始矩阵‘expend 32-byte k’是对角线填充还是一行填充

看slasa20与Xslasa20，chacha20与Xchacha20，就看初始矩阵nonce的填充长度

定位constants填充的位置：

前8字节

后8字节

计算前后8字节的位置的距离：296-288 = 8。可以发现地址是连续的8字节，这说明是按行填充，那么使用的算法是chacha20.

当然在wasm2wat转化的dcmp文件中也可以找到chacha20.rs的信息，但是藏在巨量的字符串里，只能尝试搜索试一试，或者做一个验证也可

如法炮仗，找到key填充的部分，按照8字节填充规律，key为32字节，需填充四次，地址应为304，

312，320，328。果然找到了key的填充部分：

hex(1374463283923456787) = ‘0x13’ * 8 key即为‘0x13’ * 32

如法炮制 找到nonce的位置

nonce 为 ‘0x37’ * 12

密文定位：

该引用十分可疑 起出现在yasss!!!和nah前面 密文的可能性很高

尝试解密：

放入前面提到的程序中，验证成功，此题得解！

先说题目，这是一道创新性极高，难度极高，同时趣味性极高的题目。首先是ttf文件，里面竟然可以暗藏wasm，通过调研这是harfbuzz的wasm shaper，在harfbuzz-wasm-examples学习到tff文件也可以变着花样甚至可以实现一个计算器，在本题中除了是一个正常的字体以外，竟然还是一个flag checker，对所有符合flag{}正则的字符串，输出正误结果，真是太妙了。

再说我的做题过程，大部分时间花在了如何想法让wasm好分析，最后折腾下来还是老老实实的分析又臭又长的跟汇编没区别的c语言，但是在这个过程，我总结出逆向wasm的一个方法：

寻找对关键关键缓冲区的引用，来寻找关键逻辑的蛛丝马迹。因为通过其他语言编译成wasm，表现在wasm中总是在关键逻辑上加上大量的看似无关的代码，人工分析工作量太大

什么是关键是关键缓冲区？

我理解为和程序逻辑相关的缓冲区，这里一般为通过wasm2*出来文件中的第一个缓冲区（经验）。通过我自己实验，通过wasm-pack把rust编译成wasm，事实也是如此。

关键函数

在解这道题的时候我也试着自己写一个rust程序编译成wasm，然后反编译出来找找异同点，来给这道题找思路

我的核心lib.rs:

可以看到这里我和官方教程所不同的是 我对greet函数的实现了#[wasm_bindgen(start)]而不是

#[wasm_bindgen] 。加了start可以起到什么作用？

在生成的wasm文件中可以看到__wbindgen_start()中除了默认的call __wbindgen_init_externref_table() , 还增加了 call greet()

编写html调用它：

python起一个http，浏览器访问：

发现直接就调用了greet()

跟进init()发现调用了 __wbg_init()

__wbg_init()在最后调用了_wbg_finalize_init()

可以发现__wbg_finalize_init()调用了__wbindgen_start(),而__wbindgen_start()将调用到我们greet(),最后返回完成初始化。这就跟c语言中的init_array一样。

那么在这里我们可以通过这个功能实现一些hook,反调试，加密，解密，混淆等等，哈哈哈。

就写到这里，感谢你的耐心阅读，我们下次再见