Heaven's Gate
原理及POC
通过在32位WoW进程中执行64位代码,实现静态反编译以及干扰对Win32Api的检测实现免杀。
详见[原创]天堂之门 (Heaven's Gate) C语言实现-软件逆向-看雪-安全社区|安全招聘|kanxue.com
常见的打开天堂之门的代码块
// convert x86 to x64
6A 33 push 0x33 ; cs寄存器的新值
E8 00 00 00 00 call $+5 ;push 下一条指令的地址入栈,并继续执行下一条指令
83 04 24 05 add dword [esp], 5 ;栈顶的返回地址加5,指向retf的下一条指令
CB retf ; 通过retf,程序返回到下一条指令继续执行,但cs 寄存器已经被修改为0x33, 执行的代码是64位
// convert x64 to x86
E8 00 00 00 00 call $+5
C7 44 24 04 23 00 00 00 mov dword [rsp + 4], 0x23
83 04 24 0D add dword [rsp], 0xD
CB retf
前置知识
32位程序中调用64位程序的逆向方法
参考CTF中32位程序调用64位代码的逆向方法-安全客 - 安全资讯平台 (anquanke.com)深度好文,解答了在复现OddCode时遇到的种种odd问题的疑惑!
识别
retf是切换32位和64位的关键指令。
retf前有push 0x33(33h)类似的指令。
push 33h
add dword ptr [esp], 5
retf
或者
mov dword ptr [eax], 33h
leave
retf
retf后CS寄存器从0x23变为0x33。
程序中可能有进行支持64位的检查,如GWoC。
当一块可执行的内存,调试时无法识别汇编或者几步一跳时,有可能在是执行64位的代码。
32位代码调用函数的方式和64位代码有差异,32位程序大多通过入栈方式传参,64位程序一般用寄存器传参。
32位和64位的syscall的含义和参数有所不同。
静态
dump出64位代码后拖进ida64分析,在ida64中注意设置基址和源程序中相同便于分析。
动态
用ida64调试时,在进入64位代码所在区域前,在Edit->Segments->Edit segment处设置64位代码所在段为64位模式,可读可写可运行
天堂之门解题trick
根据call far、jmp far定位是天堂之门,找到切换64位模式的代码,然后对64位部分代码进行静态or动态分析。静态的话就是dump出64位部分代码,然后设置基址和段属性。动态就是windows下ida+windbg。
题目
OddCode
本题参考
2021年羊城杯官方Writeup公布(Reverse) (qq.com)
羊城杯_2021 OddCode 天堂之门 + unicorn反混淆 - TLSN - 博客园 (cnblogs.com)
[原创]羊城杯OddCode题解(unicorn模拟调试+求解)-CTF对抗-看雪-安全社区|安全招聘|kanxue.com
这题看起来好炫,跟着wp做做,然后就做了好久好久。用ida打开后发现有很多花指令干扰,但是略向下翻可发现此处远跳转,配合上下面的call指令序列可知此题属于heaven's gate,远跳转和call $+5指令序列分别是32位转64位和64位转32位的代码。ida对远跳转支持不好,可参考汇编中的jmp转移指令:jmp short、jmp near ptr、jmp far ptr-CSDN博客。在这里可看远跳转的机器码,小端序0033:00405313,即设置cs为0x33,地址为0x405310,也就是他下面一行call sub_401010指令。
可以从x32dbg的调试中看出远跳转是在设置cs为0x33
可以看出,程序切换到64位模式后跳转下一行,执行的是call sub_401010
执行完后经下列指令切换回32位模式。
最后根据sub401010的返回值判断flag正误,可知关键函数即sub401010
同时观察可知,跳转前将input放入esi,将一个可能是key的数组放入edi
下面就是要分析64位部分的代码,可以dump后静态分析,也可以动态分析。这个题dump出来后简单观察下就可以发现充满花指令混淆,实在是难以分析,只能动态调试下看看。
思路一:用unicorn来调试代码块,但是我一直搞不懂切换64位前寄存器的状态是怎么获得的,我的EIP指向0x2e1010时寄存器的值和搜到的这个思路的wp都不太一样,不知道是不是因为64/32位切换我没弄好。
from unicorn import *
from unicorn.x86_const import *
ADDRESS = 0x2E1000 # 程序加载的地址,可通过ida,exeinfoPe,x32dbg调试等获得
INPUT_ADDRESS = 0x2E701D # 输入的地址
KEY_ADDRESS = 0x2E705C # 16字节key的地址
with open('OddCode.exe', 'rb') as file:
file.seek(0x400)#PE文件结构代码开始部分
X64_CODE = file.read(0x4269) # 读取代码,除去32位程序剩下的所有代码
class Unidbg:
def __init__(self, flag):
mu = Uc(UC_ARCH_X86, UC_MODE_64) # 基址为0x2E1000,分配16MB内存
mu.mem_map(ADDRESS, 0x1000000)
mu.mem_write(ADDRESS, X64_CODE)
mu.mem_write(INPUT_ADDRESS, flag) # 随便写入一个flag
mu.mem_write(KEY_ADDRESS, b'\x90\xF0\x70\x7C\x52\x05\x91\x90\xAA\xDA\x8F\xFA\x7B\xBC\x79\x4D')
#跳转前存入的key
# 初始化寄存器,寄存器的状态就是切换到64位模式之前的状态,可以通过动调得到
mu.reg_write(UC_X86_REG_RAX, 1)
mu.reg_write(UC_X86_REG_RBX, 0x51902D)
mu.reg_write(UC_X86_REG_RCX, 0xD86649D8)
mu.reg_write(UC_X86_REG_RDX, 0x2E701C)
mu.reg_write(UC_X86_REG_RSI, INPUT_ADDRESS) # input参数
mu.reg_write(UC_X86_REG_RDI, KEY_ADDRESS) # key参数
mu.reg_write(UC_X86_REG_RBP, 0x6FFBBC)
mu.reg_write(UC_X86_REG_RSP, 0x6FFBAC)
mu.reg_write(UC_X86_REG_RIP, 0x2E1010)
mu.hook_add(UC_HOOK_CODE, self.trace) # hook代码执行,保存代码块执行轨迹
self.mu = mu
self.except_addr = 0
self.traces = [] # 用来保存代码块执行轨迹
def trace(self, mu, address, size, data):
if address != self.except_addr:
self.traces.append(address)
self.except_addr = address + size
def start(self):
try:
self.mu.emu_start(0x2E1010, -1)
except:
pass print([hex(addr)for addr in self.traces]) Unidbg(b'SangFor{00000000000000000000000000000000}').start()
下面就可以用unicorn去hook访问input和key的代码块,同时借助unicorn还可以鉴别花指令和正常执行的指令,详见地球人的博客。后续观察出来了判断的逻辑直接爆破。
另外值得注意,在windows下调试时windbg对32/64位切换的支持较好,其他如ida、x32dbg等调试器在retf语句后都无法调试。
因为这点耽误了很多时间,比如ida虽可以通过断点进入64位部分,但是会一直报错不能调试。稍等研究下ida和windbg结合使用再更下。
思路二:官方wp里把64位部分dump出来重新编译成exe然后运行调试。通过观察寄存器的值发现的变换逻辑。但是这里不太了解dump出来之后那个masm格式怎么写的,再学下之后补上。
西湖论剑2023 Dual personality
挖坑尽快填上。这个题就是直接识别出64位的部分dump出来然后直接分析代码逻辑就好。
标签:逆向,Heaven,32,代码,mu,write,64,Gate,self From: https://www.cnblogs.com/y0hv2y/p/17872410.html