问题描述
我通过 ret-sync 同步了 x64dbg 和 ghidra。我在 ghidra 中发现了一个有趣的点:
1800382b1 4d 8b e0 MOV R12,rebitData
1800382b4 48 63 f2 MOVSXD packetSize_,packetSize
在列表视图中;文件 my.dll 从 180000000 开始。 所以,然后在 x64dbg 中,我为 my.dll 添加了一个 dll 中断,当我进入时,我使用 ctrl+shift+g 转到文件偏移量并输入 328b4,但我最终在(第一行):>
00007FF8B2FB32B4 | 06 | ???
00007FF8B2FB32B5 | E9 80000000 | jmp my.7FF8B2FB333A
00007FF8B2FB32BA | 45:8BC6 | mov r8d,r14d
00007FF8B2FB32BD | EB 7B | jmp my.7FF8B2FB333A
00007FF8B2FB32BF | 3BFB | cmp edi,ebx
00007FF8B2FB32C1 | 73 22 | jae my.7FF8B2FB32E5
00007FF8B2FB32C3 | 41:3BDB | cmp ebx,r11d
00007FF8B2FB32C6 | 76 18 | jbe my.7FF8B2FB32E0
在 x64dbg 中,文件起始于:00007FF8B2F81000
(cpu 选项卡,模块 my.dll,主线程 X,PID Y)。
显然说明不一样。 (我相信我正确地做了 rebase)
我怎样才能使对应的 ghidra -> x64dbg 并在 x64dbg 的“同一个地方”即相同的指令中断?
解决方法
- ret-sync 允许使用 F2 直接从 ghidra(到 x64dbg)添加断点: https://github.com/bootleg/ret-sync#ghidra-usage
然而,这不适用于 ret-sync 在发行版中内置,仅在调试版本中。 This is a bug。
-
对于手动rebase+jump,从x64dbg可以在x64dbg计算器的
expression
中输入偏移量(当前偏移量-基础偏移量),并要求follow in disassembler
直接跳转到抵消。可以计算一个执行变基或更复杂函数的表达式(例如,offset + sizeof X * Ntimes)。 -
如果最终偏移量已知,另一种跳转到 x64dbg 中所需偏移量的方法是
ctrl+shift+g
(go to file offset
),如果所需模块在 CPU 反汇编中。如果不是,则需要转到符号,然后按照 CPU 反汇编中感兴趣的模块然后go to file offset
。
你说你想去328b4
,但你的第二个片段是在...32B4
,看起来你最终进入了指令的中间。我希望正确的地址是 0x00007FF8B2F81000 + 0x328b4 = 0x7ff8b2fb38b4。
我不知道 ret-sync
支持设置断点,但是您可以通过悬停 来获取相对偏移量来更轻松地进行地址转换
来源:https://twitter.com/dev747368/status/1347360276476293125
然后将 x64dbg
的 00007FF8B2F81000
偏移量添加到偏移量(屏幕截图中的 2008h
,在您的情况下为 328b4h
)
或者您可以通过在 shell 中运行 currentAddress.subtract(currentProgram.imageBase)
来获取当前地址的相对偏移量(在您的示例中再次使用 328b4h
)然后添加 x64dbg
偏移量来编写脚本。所以完整的命令是:currentAddress.subtract(currentProgram.imageBase).add(0x00007FF8B2F81000)
在 Python REPL 中运行它,应该会得到当前地址的正确 x64dbg
地址。