题目给出一个镜像文件
观察镜像中的文件判断为DOS系统盘
使用DOSBox挂载镜像文件,编辑dosbox.conf
运行DOSBox,尝试输入密码,回显密码是否正确
解压镜像文件可以发现DOS启动后运行AUTOEXEC.BAT,然后执行infohelp.exe
对infohelp.exe进行逆向分析,可以发现程序是由Watcom编译的16位程序
16位程序直接无法使用F5插件,掏出王爽老师的书籍温习16位x86汇编,分析时要注意区分CS、DS、ES段
知道了infohelp.exe使用的编译器,制作Watcom标准库的FLIRT signature的签名,IDA自动标记了Watcom的库函数,大大简化了逆向工作量
(参考https://blog.csdn.net/hgy413/article/details/50612296)
infohelp.exe程序由sub_10000作为入口,主要流程可以按如下表示:
在infohelp.exe中并没有检查密码,而是在输入密码后,直接输出了message.dat的文件内容
此外我们还注意到了程序并没有回显Welcome to FLARE spy...的信息,这和DOSBox运行的情况不符
为了验证这个情况,把镜像中的文件解压挂载到用户盘,启动DOSBox自带的DOS系统运行infohelp.exe
解压镜像到DOSBox\floppy,编辑dosbox.conf并再次运行DOSBox
实验现象和预期的一样,程序在输入密码后直接输出了Message
将镜像文件和原版的DOS系统镜像进行比对
可以发现镜像文件的头部,MBR有一段已经被修改了
使用VM+IDA5.5对这个MBR进行调试(16位程序,下面的内存地址按段:偏移表示)
(参考https://www.cnblogs.com/alwaysking/p/8511280.html)
MBR一开始将镜像中的tmp.dat拷贝0x6000字节到0:0x800并跳转到该区域执行
在执行这段shellcode时,MBR继续加载tmp.dat的一部分数据到数据内存中,然后修改了0:0x4c的数据,然后跳转到解码出的微软原版MBR继续运行
其中0:0x4c地址是int 13h中断服务函数的地址,运行后13h中断服务地址被改为0x97400012
这是一种Bootkit,Bootkit通过感染磁盘主引导记录(MBR)方式,在启动时对系统服务进行hook,由于预先于操作系统、应用程序加载所以很难被查杀
对hook后的中断服务13h继续跟进
伪造的int 13h函数会先记录int 13h所有的参数并调用原版系统服务,原版系统服务执行完后,根据系统服务的参数进入不同的handler
以0x9740:0x105为例,当中断服务13h的参数cx == 0x2111 && dh == 1 && al == 1时,会调用0x9740:0x17e的handler,根据镜像中的信息该镜像的线性地址LBA = 0x200 * [(磁盘柱面 * 36) + (磁头 * 18) + (扇区号 – 1)],此时LBA正好对应message.dat
也就是说当读取message.dat会调用0x9740:0x17e地址的函数
其他的handler和这个例子类似,其中和密码相关的一个就是在打开message.dat文件时会被hook执行tmp.dat中的函数,另一个就是写key.dat时会将写入的内容复制到指定的内存区域
也就是说通过Infohelp.exe作为触发器,infohelp.ex在输入密码后将密码写入key.dat,此时输入的密码会被复制到指定的内存位置,下一步在打开message.dat时,被hook到真正的密码验证程序
恢复0x9740:0x17e这个handler,大致流程如下
查阅wiki资料,这是One-instruction set computer (OISC)中的subleq的模拟器
只支持一种指令的处理器却可以执行任意的逻辑,可以降低芯片成本,同时给逆向增加难度
(参考: https://en.wikipedia.org/wiki/One_instruction_set_computer)
在python中重构了subleq的simulator,并执行dump的subleq程序
参考Flare-on4的11题,也是解subleq密码,读了网上去年的WP,一般使用到了进行侧信道攻击,通过不同密码输入的CPU Titk、程序指针图等手段来测试密码
但是我按去年的方法进行尝试,除了发现密码中输入了’@’会大大增加CPU Tick外并没有总结明显的规律
然后进行数据流分析,追踪密码的流向,对读写密码的敏感位置进行标记,也没有明显发现
[招生]科锐逆向工程师培训(2024年11月15日实地,远程教学同时开班, 第51期)
最后于 2018-10-9 11:53
被chenzhuoru编辑
,原因: