L3HCTF 2021 MISC bootflag

发表于 | 分类于 |

破解新版本AMI的BIOS密码，其实就是存储在flash的nvram区中的一个SHA256。

  • 给了一个视频和一个flashdump的固件
  • W25Q256JVFIQ.bin 这个flashdump就是bios的存储实体
  • 视频是在bios里设置两个密码，flag就是这两个密码，视频关键截图如下

image

BIOS介绍

从截图中可看出，这是一个能管理BIOS的Web界面，显然在BIOS阶段，主系统并不能工作，那这个东西是如何实现的呢？这个左上角的KVM又是啥呢？

至于破解BIOS密码这个事，其实小的时候他听说也只是听说拔电池：

看起来现在的电脑仍然有CMOS作为介质来存储一些配置，可能是历史遗留问题吧。不过看题目只给出了flashdump，这是否意味着当下的密码已经存储到flash，而并非CMOS中呢？

基本方法

根据视频可以发现这个bios的名字叫：aptio setup utility，但是搜这玩意搜不到啥，根据其厂商American Megatrends Incorporated 搜索AMI bios就有一些文章了：

使用MMTOOL直接打开这个固件，可以看到一个L3HSecDxe，也可以提取出PE文件，解压出来是个去掉开头0x44字节是个PE，但其路径是bootflag2，所以看起来跟第一关关系不大，然后搜到：

但是不会用，不知道姿势，感觉这些工具好像都是在破本机的bios。不过结合这些文章可以看出，MMTOOL这种工具是可以直接分析flashdump的固件的，并且可以分析出其中的模块，不过是windows的软件，找到了主流分析BIOS固件的软件：

  • UEFItool：有三大平台的图形化界面，如同MMTOOL一样，可直接扔进去一个BIOS固件

另外其实这个flashdump还可以用IDA直接打开，IDA可以识别其为BIOS固件，并按相关地址加载分析。但根据MMTOOL之前的结果可以发现，现在的BIOS也足够复杂，里面还有PE文件，显然IDA不能做到分析出每个模块的内容，所以直接用IDA分析整个BIOS并不是明智之举。

模拟运行

如果能直接运行起来的话，4位密码爆破也是个可行的办法，很明显，QEMU可以通过 -bios 参数运行调试BIOS：

但是此文件是spi flash 的 dump，搜索发现，qemu也是可以直接给flash的：

但发现目标bios的大小超过了QEMU的限制：

➜  qemu-system-x86_64 -pflash ./W25Q256JVFIQ.bin
WARNING: Image format was not specified for './W25Q256JVFIQ.bin' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
qemu-system-x86_64: combined size of system firmware exceeds 8388608 bytes

此dump是32M，qemu最大限制是8M，尝试对QEMU做如下patch：

hw/i386/pc_sysfw.c

-#define FLASH_SIZE_LIMIT (8 * MiB)
+#define FLASH_SIZE_LIMIT (64 * MiB)

patch后发现执行没有显示界面，但gdb挂上发现的确运行了，所以他可能是个真机的bios，qemu不支持其硬件设备，无法模拟。（后跟出题人交流，这就是真机的BIOS，通过编程器读取服务器的flash芯片这种物理方式出的题）

继续逆向

故使用UEFITool进行头大的逆向，搜索“Confirm New”找到目标模块：AMITSE，对这个PE逆向，没啥结果：

image

柳暗花明

突然想明白，对上面这个代码逆向没有直接的意义，因为密码是要存在数据区的，平时ELF是在内存，配置可能落地为文件系统中的文件，对于BIOS固件，用户写入的数据在呢？在CMOS中么？UEFItool发现这玩意有nvram区，之前l1n3师傅教过我，nvram就是划分的一段flash存储，用于持久化存储用户配置，故搜索AMI、nvram、password等关键字，可以搜到：

密码在果然在nvram区，并且其uuid是固定的：C811FA38-42C8-4579-A9BB-60E94EDDFB34 (AMITSESetup)

image

但数据显然与此文不同，异或无效，开始还以为魔改了异或的魔数，后来在提出的PE里找异或指令都没找到，感觉不对：

55850E9EEF1708206617B07FA1C3D5D0
C44C3EF74D7AB02EB22FC64A18E90BE9
0000000000000000873EEAC1D84A1734
53A2486CC556764F12D4B2A85885E819
325239B3AE3EF0770000000000000000
01

翻评论说升级hash了，一顿搜索，找到twitter：https://twitter.com/dev_console/status/1345851717389266944，其中说明：

to crack a new-style SHA256-hashed AMI BIOS password, located in the AMITSESetup EFI variable:

`hashcat -m 1430 -a 3 -w 3 -O -1 <charset> --hex-salt hash.txt <pattern>`

hash.txt containing:
`<hash>:<0000 repeated (max password size (usually 20) - search length) times>`

the password is processed as:
sha256(password.null_pad_to(max_password_size).encode('utf-16le'))

this abuses hashcat's salting mechanism to pad the attempted password with null bytes, very useful that it has a SHA256(password.encode('utf-16le')) algorithm (1430)

原来就是sha256，不过要注意padding和utf-16le编码：

➜  hashcat -m 1430 -a 3 -w 3 -O --hex-salt 55850E9EEF1708206617B07FA1C3D5D0C44C3EF74D7AB02EB22FC64A18E90BE9:0000000000000000000000000000000000000000000000000000000000000000 "?a?a?a?a" --show
55850e9eef1708206617b07fa1c3d5d0c44c3ef74d7ab02eb22fc64a18e90be9:0000000000000000000000000000000000000000000000000000000000000000:7K62
➜  hashcat -m 1430 -a 3 -w 3 -O --hex-salt 873EEAC1D84A173453A2486CC556764F12D4B2A85885E819325239B3AE3EF077:0000000000000000000000000000000000000000000000000000000000000000 "?a?a?a?a" --show
873eeac1d84a173453a2486cc556764f12d4b2a85885e819325239b3ae3ef077:0000000000000000000000000000000000000000000000000000000000000000:7D12

//L3HCTF{7D127k62} 官方WP中声明，此BIOS对密码的大小写不敏感，统统为大写，一大一小这么写是flag的要求

其他队伍和官方WP都是说要找到泄露的源码：（我当时是没找到…

其他WP