接触 ctf 之后好好打的第一个正式的比赛,难哭了
只写出来两道逆向,但狗运还行(校内大佬基本都组一起了),拿了校内第三
# ezDOS
查⼀下,16 位 dos 程序,win11 打不开,但 ida 可以分析
怼着汇编看了半天,这⾥有个很典型的花指令(看到这个 call 有点莫名其妙,感觉是花指令,nop ⼀下发现猜想是对的)

还有⼏处这样的,全 nop 掉后再分析
是⼀个输⼊ -> 加密 -> 校验的过程,加密后的密⽂硬编码在 142h 到 167h 之间
但这⾥⾯对密钥好像做了⼀些加密(deepseek 说是魔改的 rc4)
汇编水平太差。。。有点看不明白这个逻辑
但 RC4 最后就是将密钥流和原文逐字节异或,那我直接提取出来密钥流不就⾏了吗?

也就是找到上图这个时候的 al 的值
可以用 dosbox 调试 16 位程序
先导入程序进 dosbox

debug 调试即可
需要注意,原程序里面有花指令,dos 中一步步执行时会遇到这些花指令,不能让 dos 运行这些错误的汇编指令,这里要修改为正确的汇编指令,否则动态调试得出来的 al 的值会错
我先在 ida ⾥⾯看我修改花指令之后对应区域的机器码,然后在 dosbox ⾥⾯⽤ - e 命令⼀个个修改(懒得截图了)
这里还有个坑就是,当提示输入的时候,输入的字符串长度必须要等于 flag 的长度,否则验证逻辑走不完,没法完全提取出 al 的值(我就错了一次,又得重头再调一遍,极其痛苦)
做题的时候我真的循环执行了几十遍⼀个个提取 al 的值,现在不想再搞⼀次了()
1 | a=[0x32,0x7d,0x59,0x7a,0xf3,0x0d,0xb3,0x7b,0x64,0x8c,0xeb,0x28,0xc4,0xa4,0x50,0x30,0xa0,0xed,0x27,0x6a,0xe3,0x76,0x69,0xc,0xda,0x28,0xf8,0x8,0xba,0xa6,0x17,0x3e,0x12,0x59,0x45,0x6,0x4e,0xf1] |
# SafeProgram
64 位无壳,直接 ida 分析
和上题一样的输入 -> 加密 -> 验证逻辑,密文也直接硬编码在内存里

sub_1400019D0 函数这一大串加密是个 SM4,每次传入 16 个字符原文,分两次加密 flag 前后 16 个字符
密钥也在程序里面

做题的时候感觉应该没这么简单,cyberchef 了一下,答案果然是错的
那就动态调试试试
但是在 main 函数开头下断点,会报错并无法继续调试

应该是某种反调试,那就在__scrt_common_main_seh 开头下断点看看
这里还有个问题,即使在__scrt_common_main_seh 开头下了断点,main 函数内也不能有断点,否则还是会出现上述 warning(试了几次都这样)
那就只在__scrt_common_main_seh 开头下断点,继续调试
这个时候可以正常进入 main 函数,没有出现 warning
按要求输入一个长度为 38 的字符串,进入到加密逻辑

这里我试过很多次,用汇编窗口分析更好一点

这里有个除 0 异常,做题的时候我其实误打误撞的,没怎么在乎,但赛后看到其它大佬的 wp,这里应该调用了这个函数:

把上面的密钥更改了

同时更改了 SM4 加密的 S 盒

自己在比赛的时候其实还不是太熟悉 SM4,这里调了一段时间,重试了很多次,最后误打误撞才发现这两处地方似乎被修改了,然后去了解了一下 SM4,才知道这个情况
知道这些信息,从网上抄了一份原生的 SM4 加密,再手动修改 S 盒以及密钥,分两次解密密文的前后 16 个字符即可
1 | from pydoc import plaintext |
输出的十六进制手动转一下就好了
NCTF
# gogo(复现)
极其逆天
go + 虚拟机逆向 + 多线程,给萌新难傻了,比赛第二天做了 8 个多小时,只发现了虚拟机的 opcode,实在没精力再去研究怎么还原出汇编代码,就放弃了
用 ida 打开,go 语言逆向会损失函数的符号而找不到 main 函数,这里我找到了一个插件可以一键恢复符号
0xjiayu/go_parser: Yet Another Golang binary parser for IDAPro
恢复后就可以找到 main 函数 main_main 了

没怎么接触过 go,查了半天资料了解了一下,它里面的很多字符串的特性以及函数的调用都和其它语言有挺大差距的,一些常见的像 print 这样的函数长得比较奇怪,不过 ida 整体反汇编出来的代码和 c 其实相差不大,看不懂可以动态调试

这个区域开始就是加密的主要逻辑
这道题的程序是多线程,动态调试的时候会在两个线程之间来回跳转,但这里不能被这些东西吓到

经过一阵折腾找到了这个函数,其实这个加密逻辑就是把 40 个字符的 flag 按前后分成 20 个字符,分两个线程并发地加密(这里我的代码对某些有意义的值重命名过)
具体加密逻辑就是执行虚拟机指令的过程
而虚拟机操作码的获取可以结合动态调试,会跟踪到 main_map_init_0 和 main_map_init_1 两个函数,这里就分别是对 flag 前后 20 个字符的加密的操作码(两个线程的虚拟机的指令对应的操作码不一样)
比较搞笑的是这里我在做题的时候居然提取错了..... 我的提取是这样的:
对于前 20 个字符:
LDR:0x12
LDRI:0x15
STR:0x16
STRI:0x2A
MOV:0x41
ADD:0x42
SUB:0x47
MUL:0x71
LSL:0x73
LSR:0x7A
XOR:0x7B
AND:0xFE
RET:0xFF
对于后 20 个字符:
LDR:0x14
LDRI:0x17
STR:0x18
STRI:0x2B
MOV:0x91
ADD:0x92
SUB:0x97
MUL:0xC1
LSL:0xC3
LSR:0xCA
XOR:0xCB
AND:0xFE
RET:0xFF
正确的是(官方的 wp):
var instructionSetA = map[byte]handler{
0x11: LDR,
0x12: LDRI,
0x15: STR,
0x16: STRI,
0x2A: MOV,
0x41: ADD,
0x42: SUB,
0x47: MUL,
0x71: LSL,
0x73: LSR,
0x7A: XOR,
0x7B: AND,
0xFE: RET,
0xFF: HLT,
}
var instructionSetB = map[byte]handler{
0x13: LDR,
0x14: LDRI,
0x17: STR,
0x18: STRI,
0x2B: MOV,
0x91: ADD,
0x92: SUB,
0x97: MUL,
0xC1: LSL,
0xC3: LSR,
0xCA: XOR,
0xCB: AND,
0xFE: RET,
0xFF: HLT,
}
那么现在的问题就变得很简单(?),就是根据 opcode 对应的操作码映射为汇编代码,这样就可以分析了,由于是两个线程并发进行且它们共用一个 opcode,因此可以分开讨论,把两个线程分开解析,这样不容易搞混
我做题的时候就卡在这一步了,因为正常的 opcode 应该是这样的(hgame2023 vm):

也就是说,opcode 里面的每一个字节,对应着一个指令或不进行操作,并且可以很方便地创建结构体,以便于看出汇编指令所操作的各寄存器
[原创] VM 逆向,一篇就够了(上)-CTF 对抗 - 看雪 - 安全社区安全招聘 kanxue.com
但这道题我真的无从下手,不知道怎么创建结构体。同时,opcode 是四个字节为一个单位进行操作而且 19444 字节的 opcode 体量庞大, 确实把我吓到了,不知如何解析,到这里我已经看这道题近 8 个小时了(于是我就放弃这道题然后出去打舞萌了 233)
赛后看了官方的 wp,其实很容易理解,这个 opcode 以四个字节为单位执行一个汇编语言,那么根据这些汇编语言的语法,四个字节都可以很容易地找到它们的含义是什么

以第一块为例,‘2A’对应 init_0 的 mov 指令,‘0’对应寄存器(这里分析了一下,发现有好几个寄存器,分别以 0,1,2,3..... 来表示,这里是 R0),后面的‘37’、‘9e’对应的就是操作数,于是这段指令就可以翻译为:
mov,R0,9e37
对于某些指令(如 ADD、LSL 等)后三个字节都是寄存器,推测应该是前两个寄存器当成了一个来用
那么就可以分析了:
注意到 0x9e3779b9 是 tea 算法的典型数据,可以猜测是 tea 或 xxtea 等变种(没猜测到也不要紧,可以看导出来的汇编),手搓一下代码先
对于 init_0:
1 | #include<stdio.h> |
init_1 和上面一样,改一下操作码即可
这里我没有写 STR,LSR 等指令,因为全写出来也看不太明白,而且这些指令对加密逻辑的判断用处不大
跑出来可以看到,init_0 就是很标准的 XXTEA,没有魔改,但 init_1 稍微修改了一下,把代码中的 “左移” 和 “右移” 互换了(表达不太清晰,下面放代码)
密钥也在代码执行后得到的汇编指令里面,找出来就行
有关密钥提取,这里有一个需要注意的地方(笨比自己看半天没明白,问了一下出题的学长才知道)
以 init_0 生成的汇编指令为例,可以看到生成的大致是这样的指令:
1 | mov,R0,9e37 |
这里可以看到密钥出现的先后顺序是 0xa78c0b4f,0x6e637466,0x062ef0ed,0x32303234
但密钥的实际顺序是 0x6e637466, 0x062ef0ed,0xa78c0b4f, 0x32303234
这里的原因是,汇编指令中出现的先后顺序是密钥的调用顺序,而不是它原本的顺序
具体来说,在进行加密的时候,对 key 的索引为:(p&3) e,而在加密的第一轮中,p=0,e=(0x9e3779b9>>2)&3=2,因此 pe=2
得出第一个调用数据实际上是 key [2]
以此类推得出 key 的原本顺序
结合下面的代码来想会好理解一点
这是前 20 个字节的解密流程(未魔改 xxtea):
1 | #include <stdio.h> |
这是后 20 个字节的解密流程(魔改的 xxtea):
1 | #include <stdio.h> |
得到的数据转成字符即可
1 | a=[0x4654434e,0x7234487b,0x4d565f64,0x7469775f,0x6f475f68,0x74753072,0x5f336e31,0x34636635,0x65623062,0x7d646137] |
NCTF
# x1Login(复现)
对安卓逆向不太熟悉,看到这道题还有反调试更是被吓晕,以为要动态调试,直接不写了
赛后复现发现其实就是因为我不熟悉安卓逆向,题目本身难度并不大
先说这个把我吓跑的反调试和反 root

这里官方题解写到 “apktool 解包修改 smali 代码,再重新签名打包。”(常规解法)
其实这个东西不管它也行,反正用不上动态调试,把模拟器 root 关了先进去看看

就是输入 -> 加密 -> 校验的逻辑,找到 username 和 password 即可
看 mainactivity,这里有挺多很像 base64 的加密字符串

但是直接拿去解密不对,那就看看这个 get 方法干了什么

这就很像 windows 系统上面的 DLL 文件,是动态载入的,只不过在安卓系统上是 so 文件
将 apk 文件解压,在 lib 文件夹里找到 libsimple.so 文件,这个是 ELF 文件头,可以直接用 ida 分析
在导出表可以找到 get 方法并找出加密逻辑
就是先进行换表 base64,再将得到的明文异或于它的长度
把上面那个解密,得到

这显然是一个方法名,但是在 jadx 里面找不到,而且目前也没有看到我们在程序中输入错误用户名和密码时的错误输出:“Login Failed”,推测应该还有一个 so 文件被动态载入了
在 onCreate 方法里面继续往下看(感觉这个有点像一般 windows 逆向的 main 函数),找到 getclass 方法
这个方法调用了 Secure 类,在反调试和反 root 里面也调用了这个,看一下这个类里面有什么东西

这里的密文解密出来是 native,lib 里面还有另一个 so 文件就是 native,是在执行
InMemoryDexClassLoader(ByteBuffer.wrap(Secure.loadDex(getApplicationContext(), DecStr.get("ygvUF2vHFgbPiN9J"))), getClassLoader()).loadClass(classname)
这条命令时动态加载的这个库,把这里的密文解密可以发现,这里又加载了一遍 libsimple.so 库,这有什么意义吗?
显然没有意义,因此可以合理推测,是否存在同名的 libsimple.so 库?
可以在 asset 文件夹里面发现一个同名的 libsimple.so 库(实际上反编译 native 文件,里面有指向这个库在 asset 文件夹的信息,但是有点难发现,感觉只能乱翻了)
这个库还埋了一个坑,它实际上不是 so 文件,是 dex 文件(丢到 ida 里面啥也没有),用十六进制编辑器打开可以发现有 dex 文件头
将 dex 头前面的字节全部删掉,再修改后缀为 dex,丢入 jadx 分析

有前面出现的 check 方法和一些提示信息,这里就是程序以及加密执行的主要逻辑
用户名可以直接由 uZPOs29goMu6l38 = 解密得出:X1c@dM1n1$t
将解密得到的用户名 md5 加密作为密钥,和密码原文一起放入 docheck 函数,这个函数位于 secure 类下
可以在反编译的 native 库中找到这个函数的实现,就是一个 3DES 加密,没有魔改(出题人还没这么坏)
加密后的密码也硬编码在内存里了

直接 cyberchef 解密就行

↑这个图是错的,笨比后来才发现,这里需要注意一个坑,原程序的 3DES 使用的是分三次 DES 算法,即加密 -> 解密 -> 加密的过程(两次加密密钥相同),因此所用的密钥和生成的密文严格遵守小端序
NCTF{X1c@dM1n1\x?YM+5U05Gm6=}