md，因为要准备期末考试再加上买了新主机以后一直都在玩泰拉瑞亚，所以到现在才有题解。
以往 CTF 的 Windows RE 至少调试没啥问题，就算再怎么恶心上调试器就可以做出来了，结果这次 这个天堂之门直接不给你用常规的调试工具调试的。导致这次被卡了很久。
而且因为天堂之门 x86 和 x64 代码混杂，导致 IDA F5 是直接无法工作的。所以这次只能全程看汇编力。 还好出题人够仁慈没有在全程汇编的情况下塞个 AES RC4 啥复杂的算法。
而且我的 Mac 还是 Arm 的，以前 Windows Arm 可以直接运行 RE 题目程序，但是这次因为用了天堂之门 这个邪门的调试技术，导致我虚拟机直接废了，就算用 UTM 虚拟机直接硬装了个 X86 Windows 7 好像也运行不了， 真的吐了。
而且这次还有一个非常让人没想到的检测调试器的手段，导致我就算这几天做了很久也一直被卡。
天堂之门技术就是一个在 Windows 程序执行的时候通过类似 jmp 0x33:0x4012d0 这样的指令，让 CS 寄存器直接切换到 0x33，这样 Windows 就会让程序直接运行在 64 位环境。因为这个原因 x64dbg 这样的 普通调试工具直接就 GG 了。
后面我找到 flare on 5 有一个题目 Wow，一样也是天堂之门程序的逆向。
https://blog.attify.com/flare-on-5-writeup-part5/?utm_source=pocket_saves
在这个文章里面，作者是直接使用 windbg 64 位调试的。然后我尝试了一下，发现还真的可以，而且虽然 windbg 是 64 位的调试工具，但是似乎在程序刚开始在 32 位模式下工作的时候，也能正确识别汇编和下断点。
windbg 教程有不少，网上找找罢。我这里就列举几个比较常用的命令
bp 0x1234 在 0x1234 处下断点bl 列出所有断点lm 列出所有模块的内存地址g 运行到断点在经过调试以后，我们可以知道 0x4011D0 ~ 0x4012E5 这个地址范围内的代码都是 64 位的 IDA 无法正常反汇编。
所以我们使用 capstone 这个 python 库来进行反汇编
from capstone import Cs
from capstone import CS_ARCH_X86
from capstone import CS_MODE_32
from capstone import CS_MODE_64
uc32 = Cs(CS_ARCH_X86, CS_MODE_32)
uc64 = Cs(CS_ARCH_X86, CS_MODE_64)
f = open('./prog.exe', 'rb')
file = f.read()
f.close()
text_offset = 0x400 # offset of text segement
base_addr = 0x400000 # base addr of prog
text_addr = 0x401000 # address of text enter point
start_addr = 0x4011D0
end_addr = 0x4012E5
code64 = file[text_offset + start_addr -
text_addr: text_offset + end_addr - text_addr]
code64_insn = list(uc64.disasm(code64, start_addr))
for i in code64_insn:
print("addr:{:7}|size:{:2}|{:12}{}".format(
hex(i.address), i.size, i.mnemonic, i.op_str))