我正在尝试使用 x64dbg 为 Windows 64 位可执行文件运行动态代码分析。我从https://github.com/x64dbg/ScyllaHide安装了 x64dbg 的反调试插件。我仍然发现调试器停止执行。有没有什么工具可以去掉反调试，做动态分析？此外，Ghidra 能够找到我需要专注于我的 RE 的文本字符串。但是，该地址根本不匹配 x64dbg 地址。
Ghidra 在 address 处找到了 8 个十六进制数字的文本字符串：
01A0FB74
x64dbg 所有地址都是 16 进制：
10009000ffbb9123
如何将 Ghidra 地址转换为 x64dbg 地址以便我可以查看说明？我是 RE 的新手。我需要一些指导。
我过去也用不同的工具经历过这种情况。我所做的是在两个工具中找到一些容易定位的东西，例如库的 DLL Main 或 PE 文件的入口点（或其他字符串）等。然后您可以计算两个工具之间的偏移量。根据程序，它可以随着调试器的每次运行而改变。X64dbg 正在做的是创建一个进程并使用 Windows 加载 PE 文件的偏移量。
例如，如果我的静态分析工具（即 Ghidra）说我的 PE 文件的入口点在0x1000并且 x64dbg 说入口点在0x400000那么我的偏移量是 0x3FF000，所以我在 Ghidra 中发现了一些有趣的东西然后我可以添加 0x3FF000 并且可能在 x64dbg 中找到它。这并不总是有效，因为 PE 文件可以指定某些部分在不同的地址加载。
PE 标头指定如何将某些内容映射到内存并包含由加载程序修复的重定位信息，以便所有内容都可以找到其他部分/函数/等。
一般来说，如果没有什么有趣的事情发生，比如打包/自解压，那么你只需要看看你在 Ghidra 中的哪个内存部分（左边的程序树中的东西，可能是 .data 或 .rdata）。在最上面，它会说“ram:01A00000 - 01A10000”之类的东西。
PE 允许部分说“我需要被加载到基地址 X”。如果本节这样做，这些数字可能是正确的。大多数部分不这样做，这很好。
您需要做的就是执行加载程序在修复重定位时所做的相同操作。您知道基地址是 01A00000，您在 01A0FB74 找到了您要查找的内容，因此对此的偏移量是 01A0FB74 - 01A00000 或 FB74。
所以现在查看 x64dbg 的内存映射部分。您将看到具有相同名称的相同部分。您实际上可能会看到多个 .data 或 .rdata 部分，每个加载的 PE 模块一个（EXE 是一个模块，DLL 也是一个模块）。您正在查看的模块部分旁边将是它在内存中的基址。将 FB74（或任何您的偏移量实际上是）添加到那里并去那里。那应该是你想去的地方。
x64dbg 允许您跳转到文件和 RVA 偏移量，例如，当我们调试暗黑破坏神的 GOG 版本时，它看起来像这样：
内存中的地址是加载可执行文件的 46BC30。如果您查看内存映射选项卡，您将看到可执行文件的基址是 400000，这也是可执行文件期望加载的位置，因此没有发生重定位。在这种情况下，地址将在 Ghidra 和 x64dbg 之间完美对齐。
如果我们查看屏幕底部，我们可以看到其他几个地址：
.text:46BC30 暗黑破坏神.exe:$6BC30 #6B030
$xxxxx 值是相对虚拟地址（RVA），你可以只做 ImageBase + 6BC30 来找到 Ghidra 将使用的地址，你也可以使用 6B030 在文件中找到这个偏移量。您还可以在 x64dbg 中搜索这些 #xxxxx 和 $xxxxx 地址以直接跳转到 RVA 和文件偏移量：
在 Ghidra 中搜索时，您仍然需要在文件中找到 ImageBase 以添加到 RVA，但随着时间的推移，您会变得更好。好消息是你会知道你是否猜对了，因为你会看到相同的反汇编。