如何从 ghidra 的相应指令中破解 x64dbg？答案

【问题标题】：How to break in x64dbg from ghidra's corresponding instructions?如何从 ghidra 的相应指令中破解 x64dbg？
【发布时间】：2021-04-22 09:19:31
【问题描述】：

我通过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）。

显然说明是不一样的。（我相信我正确地做了变基）

我怎样才能使对应的 ghidra -> x64dbg 并在“相同的地方”（即相同的指令）中断 x64dbg？

【问题讨论】：

这个问题也可能更适合 RE 堆栈交换，但你已经知道了，所以我假设你是故意把它贴在这里的？
@FlorianMagin 是的，我知道。但是在这里调试与反转的选择是任意的，因此我选择使其更通用并选择调试，这在 SO 上更好。我认识到 ghidra 的使用可能会强烈建议反转或最终分析。
啊，很好的推理，并且更清楚地说明了您的问题的重点是什么。我同意如果重点放在一般调试方面，那么 SO 可能更适合。

标签： debugging assembly breakpoints ghidra x64dbg

【解决方案1】：

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。

【讨论】：

【解决方案2】：

你说你想去328b4，但你的第二个sn-p在...32B4，看起来你最终进入了指令的中间。我希望正确的地址是 0x00007FF8B2F81000 + 0x328b4 = 0x7ff8b2fb38b4。

我不知道ret-sync 支持设置断点，但您可以通过悬停获取相对偏移量来更轻松地进行地址转换

来源：https://twitter.com/dev747368/status/1347360276476293125

然后将00007FF8B2F81000 的x64dbg 偏移量添加到偏移量（屏幕截图中的2008h，在您的情况下为328b4h）

或者您可以通过在 shell 中运行 currentAddress.subtract(currentProgram.imageBase) 来编写此脚本以获取当前地址的相对偏移量（在您的示例中再次为 328b4h），然后添加 x64dbg 偏移量。所以完整的命令是：currentAddress.subtract(currentProgram.imageBase).add(0x00007FF8B2F81000) 在 Python REPL 中运行它，应该会得到当前地址的正确 x64dbg 地址。

【讨论】：

那么，ctrl+shift+g（转到文件偏移量）不是去我想要的地方的正确方法（自动变基）？这是为什么？我们在进程内存空间中没有程序的副本吗？
ctrl+shift+g in x64dbg?我实际上从未在 IDA 之外使用过 Windows 调试器，我主要使用 ghidra 进行静态 RE。如果x64dbg 可以自己进行pam_xauth.so + 2008h 翻译，那么它会变得更加容易，您可以以任何有意义的方式将0x2008 的偏移量传递给x64dbg
x64dbg 中有一个“命令”文本框，但它没有接受您的 python REPL 命令（我没有找到它）。因此剩下两个选项：“转到文件偏移量”和计算器，我将字符串偏移量+所需的偏移量放入 dll 中（取自 ghidra），然后询问“跟随反汇编程序”，这给出了我想要的结果。
啊，我的 Python REPL 命令用于 Ghidra Python REPL。 currentAddress 是一个神奇的变量，它将具有您当前位于 Ghidra 中的地址的值。因此，如果您在 Ghidra 中的一个有趣地址，您可以在 Ghidra 中运行此命令，并将在 x64dbg 中获得结果地址，或者如果您遗漏了最后一个 .add() 部分，则只是文件内的偏移量