HWS计划2021硬件安全冬令营线上选拔赛 Writeup
RE 部分转载来自安全客(2021DASCTF 一月赛 RE 部分)
RE
decryption-100
Try to decrypt me!
main 函数
发现代码还原的很好,可以可清楚地看到整个逻辑
其中第一个限制就是要求输入的字符长度为 32 位,否则就会直接退出,然后通过一个加密函数把输入的内容加密,加密之后通过 memcmp 进行比对,这也是一种非常常见的 RE 模型,也就是让你还原 encrypt 的过程
encrypt 函数
很清楚的可以发现一个特性,那么就是程序的加密过程都是单字节相关的,这意味着我们只需要逐字节的爆破比对就可以得到加密前的结果,由于这里伪代码是 C 的,所以我们考虑直接用 C++ 编写爆破代码。
导出比对内容
双击进入比对的内容,发现没有识别为字节数组,我们按下小键盘的*键
就可以转换为数组的形式显示
爆破程序
|
|
这里有一个坑点就是要注意一下在爆破比对的时候,比对的类型要一致,否则这道题就会有两个字节出不来结果。
obfu-200
小红电脑上的文件被黑客加密了,只留下了一个解密程序,但需要支付比特币购买序列号才能使用,你能帮助小红破解这个程序吗?
压缩包给出了两个文件
用 IDA 打开后,发现这道题的符号信息基本上都被清楚了,故尝试用字符串进行搜索
查找引用找到对应位置
发现程序逻辑相当的复杂,但是还是大概可以看出和上一题类似的一个模型,就是通过先加密,然后再比对来进行验证。
加密函数
观察代码可以发现输入的内容都被传入了 sub_401410 函数进行进一步的加密。并且第一个参数接受加密后的内容,第二个参数传入要加密的内容。
对我们已知的变量名称进行重命名,并且对已知的类型进行重新操作后,我们可以得到一份比较舒服的伪代码
第一部分
虽然不知道他的那个 while 是在干什么,但是通过动态调试可以发现,这一段其实就在把你输入的 16 进制字符串转换为内部储存的字节形式。
也就是从输入内容的 32 位字符串,变成了 16 位字节。
第二部分
这里其实是一个 for 循环,直到 idx == 16 的时候结束,不过 ida 的伪代码识别成 while 循环了
也就是一个加密的过程,所做的事情就是把 en1 加密后的内容进行第二部分的加密,但是我也不清楚他干了啥,但是简单的一看可以发现几个特征
1.首先就是当前字节的内容和前后两个字节的内容相关,虽然单字节爆破变成了双字节,但是这个爆破范围还是能够在接受范围内的
2.通过这个代码,我们有 16 个未知数和 16 个等式,其实我们可以直接通过 z3 约束来解出结果。
第三部分
不知道这里这一块在干什么,但是经过测试可以发现这一块的内容所生成的数据都是固定的(不会受到输入数据的影响),所以我们可以不进行分析
第四部分
可以发现最后生成的 key 是固定的,我们所需要分析的就是 sub_402B70 函数了,他传入了 en2,也就是我们之前加密的内容,并且传入了 key(名字是我分析之后修改的)
进入分析之后发现,虽然代码相当的复杂,分析也毫无头绪
我们可以注意到这样的函数
加密程序往里面传入了固定的 key 值和长度 16,我们非常有理由怀疑这里就是加密的主要逻辑
点进去分析就可以直接发现,其实这就是一个 rc4 加密
这里说一点识别的窍门,但主要还是见得多就知道了
rc4 加密最显著的特征就是他的循环次数是 256,在初始化的过程中会生成一个内容为 0-255 的数组(有些时候会直接赋值)
而这里的循环的次数和循环内所干的事情都符合,并且我们可以发现他对传入的 key 的信息进行处理,所以我们就可以大胆的猜测这里是 rc4
本来以为分析到这里应该也就差不多了,结果发现后面居然还有一层加密
加密后的内容传回到了 encode_data 中,并且又传递给了下一个函数。
这个函数我显然不是很脸熟,但是我通过 Findcrypt 插件找到了他的关键
可以发现在这个函数的内部实际上调用了
这部分的内容,所以我们大胆猜测这里其实就是 AES 加密,并且 key 的内容和 rc4 的 key 一致(正好两者要求也都是 16 位),v7 也就是 AES 加密的 iv。
到此加密函数就结束了
解密程序
我们需要完全的倒推内容
1.AES 加密
2.RC4 加密
3.可爆破的加密
最后得到的内容就是我们要输入的字节信息
程序中直接对第三步用 z3 约束进行求解(是真的好用)
其他的数据内容是通过动态调试提取得到的
|
|
babyre-200
IDA 打开之后
发现和一般的 re 题目不太一样,这道题目的加密函数似乎不是可以直接查看的,而是用了某种方式调用,但是最后的逻辑还是一样的,也就是通过比对加密后的内容最后判断是否正确
在各个函数中苦苦的寻找,最后终于找到一点可能是在加密的东西
反调试
他这里特意通过异或来动态解密,似乎就是再告诉我们这里在干一些见不得人的事情。
调试发现最后解密取出的地址是 ZwSetInformationThreadi 函数
百度搜索这个关键词发现这个似乎就是一种反调试操作
所以我们考虑把这里的调用函数操作给 nop 掉
从传参开始 nop,并且保存内容,之后就可以正常调试了。
动态解密
观察后面的内容发现这道题是动态解密出 Cipher.dll,不过我采用动态调试的方法,其实可以不用管解密的这部分内容
加密函数
我们就直接分析调用解密后代码的这一部分的内容即可
这部分就是重要的加密函数,这里把数据前十六字节和后十六字节分段进行加密
发现这一块内容因为是 SMC 生成的,所以 IDA 没有识别出来,我们按 P 手动转换成函数
接着不断的进入函数最后可以发现关键的内容
第一个循环
可以发现第一个循环动态生成了一个 data 数组,而这个数组的内容都是固定的,我们可以直接提取。
第二个循环
第二个循环的才是重要的加密内容,他通过一个循环进行不断的迭代,并且可以发现其中的
v5[0] - v5[3]的内容就是我们输入的前 16 个
而迭代的最后四位 v5[32]-v5[35]的内容就是最后加密得到的内容,我们暂且先不管 encode 函数内部实现如何。
可以发现,我们 encode 函数传入的参数完全是已知的的内容,我们只需要有 encode 函数正向的计算代码,就可以从后往前推出所有的内容
encode 函数
我们只需要正向的编写 encode 函数的代码即可,所以不需要复杂的分析,不过我这里还是说明一下吧,这个函数取出了参数的每一位 bytes,并且作为下标找到相应的 key 数组中的内容赋值给 data 数组,最后又通过函数把 data 数组的内容转换为 int,再用 get 函数异或一下。这个过程虽然很复杂,但是不要求逆向就无所谓了。
解密程序
|
|
总结
这道题赛后听说是 SM4 国密算法,可惜这个算法 findcrypt 不支持,我之前也没有接触过,所以一下子没有看出来,在比赛的时候手动撸了一份解密代码,也不知道为啥,感觉这个解密算法比我想象中要容易一些写出。
所以为了在以后不再犯这样的错误,我在 findcrypt3.rules 文件中加入了以下规则辅助识别。
|
|
Enigma-300
1940 年 9 月 6 日,英国情报部门军情六处截获了一封重要的德国电报,你能逆向分析德国使用的密码机 Enigma,帮助军情六处解密这封电报吗?注:得到的 flag 请以 MD5 格式提交
main 函数
也是老样子了,读入 inp 中的内容进行加密后输入到 enc 文件中,而这道题直接给出了 enc 文件,要让我们求出 inp 文件的内容,关键的加密内容就在 loc_4018F0 中
加密函数
这里显然是 IDA 无法正常的识别出代码的内容,而 0xC7 这个机器码也是没有对应的汇编的,这意味程序执行到这里的时候一定会报错,所以在这段代码的开头调用了 SetUnhandledExceptionFilter 来进行设置异常接管函数
这个函数我们这样似乎看不出什么,问题就在于它的参数类型识别错误。
我们对参数类型进行修改
接下来就可以看到很清楚的代码逻辑了
分析可以得知,
实际上 0xC7 0xFF 开头的代码是无法执行的,到了异常处理函数这里,会对产生异常的代码附近信息进行提取,并且后几个字节的内容都是作为参数来处理
比如这里的 4 就会进入 switch 语句中调用 case 4 的分支,并且传入参数 1 和 0。
我这里找了一个处理函数进行讲解(修正参数类型后就会得到比较舒服的伪代码)
可以发现处理函数实际上就是对寄存器进行操作,也就是通过了类似 opcode,和异常处理
,来达到了一个虚拟机的效果。
我这里不会 IDC,所以只能尝试通过反汇编引擎来逐个读取,如果读取到错误的内容,就当做 opcode 进行处理,最后把所有的汇编代码输出,然后我再手动还原。
我这里使用的是 od 的内部反汇编引擎,并且该引擎已经开源,我对其代码进行调用,使其可以在 VS 上调用,修改后的 github 地址:https://github.com/wjhwjhn/DisAsmVS,希望师傅们能给我点个 Star,嘿嘿
opcode 还原代码
|
|
还原之后,就可以直接查看
伪代码
|
|
直接用 z3 写正向代码约束求解。
解密程序
|
|
Childre-300
双进程保护
这道题就是典型的双进程保护(Debug Blocker)
双进程保护,实际上是程序本身作为一个进程或一个调试器,并且在调试模式下运行自身程序。所以这种保护通常就会存在两个进程。
这种程序的技术特点是
1.无法被调试,因为程序本身也是一个调试器。我们又知道一般情况下一个程序只能被一个调试器所调试,如果他的程序先抢占作为了调试器,那么就无法进行调试。所以解决办法只能是在他的调试器附加之前你先开始调试。
2.一般来说,为了防止你直接抢占调试来绕过,他还会加一个异常处理函数,程序中原本存在一些不合理的代码或者 INT3 断点,当他的调试器处理的时候会去做一些指定的流程,而你作为调试者,在调试过程中就无法处理那些代码。
不过好在他是一道题目,那么就一定是能做的,也就是一般来说这个异常处理函数不会很复杂,手动模拟也可以操作,或者编写简单的脚本也可以进行解密,比如有些题目就是会直接在异常处理函数里面对代码进行解密后再返回运行。
异常处理函数(调试器部分)
这道题我们尝试直接从 start 开始下断,并且找到他处理调试器异常的逻辑部分,然后再手动跳转来执行加密过程
不断单步可以发现,这里开始分配函数执行
不难发现这部分就是创建了互斥体,并且通过互斥体来判断当前进程是调试器还是被调试的函数,并且通过 dword_432350 来记录,然后创建进程。
接着跟踪就发现了调试器处理的代码,这部分内容如果看过《加密与解密》的师傅应该会很清楚,里面有对编写调试器的函数信息详细的解释。
接下来进入到 case 1 分支中的函数,就可以很清楚的看到处理逻辑
普通程序流程
我们目前知道了调试逻辑之后,接下来就是按照调试器的逻辑手动去执行代码。
我们手动创建一个进程,然后再次调试的时候,当前程序就会被认为是要被调试的程序,也就会去执行加密的流程了。
接下来就去 wmain 函数手动模拟,很快就遇到了第一个 int3 断点,我们模拟他的调试器逻辑,跳到下面去执行
紧接着又遇到第二个 int3
并且在这之前的 call 函数输出了
于是我们又手动修改 EIP,跳到下面去执行
紧接着发现程序停在了这里,要我们输入 flag 的信息
输入后继续执行
然后又到了一处 int3,并发现这里的数据 0xA8 在调试器处理函数中需要让 Eip + 9,我们计算后重新修改 EIP
加密函数
发现直接跳到下面的函数执行,我们查看伪代码发现伪代码非常的难看,没有识别出各个变量的信息
这里就要用到另一个技巧了,我们需要修补一下这里开头存栈的信息(实际上开头的信息是有的,但是被垃圾代码干扰了)
用 Keypatch 添加信息
|
|
虽然因为空间的原因覆盖了一行汇编代码,但是无所谓,我们这样修改只是为了伪代码能够识别出变量
接下来的伪代码就有变量信息了,接着我们修改一些能够直接看出来的变量类型,就可以得到一份比较舒服的伪代码了
我们接下来逐个分析
第一部分
把 Str 的信息都赋值给 input,其中 Str 就是我们输入的 flag 信息,然后通过循环把 input 的内容都转换为 int 数据储存给 input_Int,大家可以眼熟一下这个模块,所干的事情就是把字符四字节的储存。
第二部分
把之前处理的 input_int 传入到这个函数中进行加密,并且把加密后的结果又转回字符形式
这里就是另一个坑点了,可以发现这个函数中存在一个 int3 断点,而其对应的内容是 0xB2,按照之前所说的调试处理的逻辑,我们要替换 ESP 中的内容,并且让 EIP + 1,查看汇编不难发现,他替换的内容就正好是传入 push 的一个值 8E32CDAAh 并且把他替换成 0x73FF8CA6,这里我刚开始因为没有注意,死活解不出来。
这里因为 inc ebp 的原因导致 IDA 伪代码识别错误,而这行汇编是并不会执行的,所以我们把他 nop 掉之后再看伪代码。
我们这里要替换的就是 8E32CDAAh,否则加密后的结果和实际运行的不一致
第三部分
通过 gen 函数生成一些 int 的内容,具体啥过程并不重要,因为这些字符的内容都是固定的,并且把结果都放在 gen_data 中,然后又放到 gen_data_char 中
第四部分
最后加密一次后,与内部储存字符串比对,如果一致就输出 right.
这里不知道为啥,明明只要比对 32 字节,数组却开到了 36 字节,并且计算过程也是循环了五次。
_byteswap_ulong 函数实际上就是把 char 的内容转换成 int,感觉挺无语了,前面刚刚转成 char,现在又要转回 int。
接下来通过一个 for 循环来对内容加密 32 次,加密之后又储存回去,这里 gen_data 的数据都是固定的,所以我们可以直接当做常数来计算
通过分析,发现这个循环的内容是可以完全逆向的,我们只需要循环 32 次来反向推,就可以得到原文的内容
总感觉有点奇怪,感觉有点像是某种加密算法,但是我也没看出来,就只能硬推了。
而且感觉他这个几个 char 和 int 的变换,总觉得是为了套函数模块来写的。
解密程序
|
|
总结
这实际上是 TEA 加密,甚至都没有魔改过,这一点从 TEA 的常数可以看出来,而我在这之前接触 TEA 加密比较少,所以在这一题也没有看出来,手动写了个解密函数。希望下次能够看出可以加快做题的速度
PWN
emarm
这道题是一道预料之中的 arm pwn,在这次比赛之前就有稍微的了解过,并且搭建了基本的环境(qemu)
解题思路
这道题的逻辑还是比较清楚的
开头要求输入密码,我们直接用**\x00**就可以绕过,这种绕过方法适用于很多这样的题目,还有另一种绕过密码一般是通过覆盖最后的 0 字节,使得随机得到的密码被输出。
其次就会给一个 8 字节的任意写,我们这里可以考虑直接修改 got 表,这里了解到 arm 的 libc 地址在环境不改变(不重启)的情况下,多次运行的地址一致,也就是对于这道题来说,我们可以通过单次泄露就泄露出 libc 的地址,然后根据题目给出的 libc 来计算出对应服务器的 system 函数地址。
所以我们第一次攻击的时候,可以直接考虑修改 got 表上的 atoi 函数为 printf 函数,然后泄露出栈上的某个地址,然后计算出 system 的地址,第二次攻击修改修改为 system,最后就可以得到权限了!
EXP
|
|
总结
1.arm 程序的 libc 只要泄露一次即可当做确定的地址,而且 arm 的 libc 和 stack 地址开头都不是 0x7f 而是 0x40
2.arm 程序可以使用 IDA 进行调试,具体方法是
|
|
这样启动之后,可以在 IDA 直接连接,IP 是调试机器的,端口就是 1234。不过不能暂停,想要暂停需要提前下断点 3.使用 gdb 连接的时候,不能直接在 python 程序中连接,而是要重新开一个终端,并且需要以下的操作
|
|
4.使用 gdb 调试的时候,libc 文件需要用 file 命令进行指定,并且常见的 gdb 命令都不能使用,gdb 输出的地址也是不带 libc 偏移的
justcode
比较有意思的一道题目,考察的点也是我没有遇到过的。
首先开了沙箱,我们只能用 orw 的方法来做。
操作 1
接着程序读取了四个操作,可以选择 1 或者 2,其中 1 的代码是
这里存在一个栈溢出的漏洞,但是只能覆盖到 canary,没有什么操作价值,但是我们可以利用脏数据来带出 libc 地址和栈地址,还有就是要和 2 的操作相结合才能看到。
操作 2
这道题的最重要的漏洞就在这里
可以发现我们有一个 scanf 函数,他在写入内容的时候没有用取指针符,并且这个函数所写的位置我们是可控的(通过调试可知,他这里所写的位置是在操作 1 中可以控制的),但是这里有一个缺陷就是,我们 v1 的大小只是 unsigned int,也就是我们最多只能往四个字节的指针写内容。这样的话就无法直接操作 libc 和堆栈这样地址比较大的位置了,而这道题没有开 PIE,并且 got 表可写。
解题过程
如何重用代码?
因为程序内置的操作次数只有四次,这对于我们要写 ROP 来说是远远不够的,所以我们需要考虑如果重用代码。
第一个想到的方法就是修改 exit 的 got 表,直接修改到 main 函数的位置,这样的话,我们只要用三条命令,并且最后一个命令调用 exit,就可以实现无限重入的目的了。
如何执行 ROP?
根据前面所说,我们是无法修改栈上的数据的,这意味着我们无法直接写 ROP 来达到 orw 的目的。所以我刚开始在这道题卡了很久,我一直想办法把数据写到栈上,不过好在后来脑子开窍想到了一个方法,那就是直接通过 pop + ret,就可以返回到我们可控的 rop 的位置,而在操作 1 中,我们又可以触发**__stack_chk_fail**,所以只需要把他的 got 地址改为类似以下的 gadget 就可以了
|
|
其中第一行把 call 调用的 ret 地址弹出,再次 ret 就可以到我们可控的位置了。这其实也是利用了**__stack_chk_fail 函数的安全机制,在检查的过程中是优先于 leave**等操作的,这意味着当调用的时候的栈上地址正好就是我们可控的地址,只要通过 info 的输入就可以写 rop 了,大大节省了时间。
如何通过把字节数据转换成 int 类型的数据?
我们知道字节的数据如果要转换成无符号整数,我们直接用 u32 命令就可以了,但是对于这道题接受的格式是**%d**,我们就难免要考虑到一个格式转化的问题,我本来想找现成的轮子,都没找到转换的函数,所以只能自己写了一个,通过判定最高位来确定是否需要输出负号,具体内容见代码。
EXP
|
|
undlcv
这道题我猜我应该是非预期,这是一道堆题
题目没有给出 libc,没有 show 函数,edit 只能编辑四次,否则就会死循环卡死。
malloc 只能是 0xF8,但是给出了一次 0x18 的机会。
不过好在没有开 PIE
题目漏洞
在 edit 的时候存在 off by null,并且我们可以通过 0xF8 的 size 来触发
结合没有开 PIE,并且 libc 是 2.23 的版本,所以我们可以考虑直接使用 unlink 来劫持 heap_ptr,之后就有了任意写的权限,但是我们知道 edit 的次数只能有四次,所以我们只是单纯的劫持 heap_ptr 是不够用的。
解题过程
所以我这里非预期的做法就是通过修改 exit 的 got 表数据,来重入 main 函数,这样的话操作次数就又会被赋值为四次,这样我们就相当于无限次数的 edit。
并且这道题是 NO RELRO,我直接就想到了之前做过的一道题,NO RELRO 对于 ret2_dlresolve 是非常方便的,我们可以直接修改 strtab 的地址,指向我们可控的区域,并且修改对应的字符串,这样在下次 dlresolve 的时候就可以直接解析到我们修改的字符串内容。
不过会遇到一个问题,我们想要劫持 free 函数去执行 system,但是发现 free 函数在这之前必须调用过,那对于这种调用过的内容,我们就无法调用 dlresolve 了。解决方法就是直接修改 free 函数地址到 plt + 6 的位置,这样在下次使用的时候就会去调用 dlresolve 了。
总结
这道题刚开始的时候一直卡在如何 leak 上,所以导致我做了很久,其实这道题想要 leak 是比较麻烦的,因为没有 show 函数,估计正解应该是打 stdout 吧(不过这比赛官方 wp 都没没有,只要做出来就是正解)
做完后听说 cnitlrt 师傅居然通过 doube free 信息泄露出 libc 版本,找到对应的 libc,并且修改 got 表来执行 one_gadget 打通了(orz,太强了!!!看起来相对于这个方法,我这个又没那么不像是正解了)
这道题拿到权限之后还需要提权,用的是 CVE-2019-14287 sudo 权限提升漏洞,这种就只能靠积累了,感谢 cnitlrt 的帮助!
|
|
EXP
|
|
固件安全
easybios
分离文件
通过两次 binwalk 可以得到一堆 PE 文件
但是我们不知道哪个文件才是需要分析的文件
但是看到有个识别出 mcrypt 的特征,我决定重点分析它上面的文件 309E44,没想到就找到关键词了
那个 R 其实就是 Right,发现 sub_8325 对代码进行加密
解密程序
|
|
得到 FLAG
最后输入结果确认
STM
奇奇怪怪的固件
搜索 STM 相关的信息,找到了一篇安全客的文章 https://www.anquanke.com/post/id/229321,根据文章中的设置,发现在 IDA 中可以成功解析,找到关键代码发现就是一个异或解密,程序就是直接输出了 flag 信息
|
|
内核安全
easy_kernel
是谁在打电话?
这道题拿了一血,估计有很多人卡在异或那里
Windows 内核驱动,题目要求在 windows xp 下运行(毕竟其他系统安装驱动就可以劝退一群了),所以下载了一个虚拟机跑了一下。
驱动分析
在驱动函数中找到
发现是一个 DES 加密
r3 程序分析
在 ring3.exe 找到
看到 17 行的内容,实际上就是对驱动的调用,找到驱动中的这个函数,实际上参数是一一对应的
DES 加密的秘钥信息就是
这个字符串的前八位,sizeof(v6) = 8
但是这道题没有这么简单,通过调试可以发现
在图中的这个位置,实际上还对加密的结果进行了又一次加密,但是这里的内容只要我们单步进去就会蓝屏,我怀疑是进入了 r0 的区域,所以蓝屏了。如果要调试驱动要装 windbg,这有点麻烦,所以我就对这部分的内容进行了盲盒测试,发现最后一个字节始终不会改变,测试发现是一个异或加密,前一位异或后一位,这样最后一位就不会变化了。
解密程序
|
|