问题标签 [ghidra]

我有一个案例，其中某些函数在堆栈上分配/使用 404 字节的临时结构进行内部计算（该函数是自包含的，并在该数据结构中随机播放数据）。从概念上讲，各自的结构似乎由一些 32 位计数器组成，后跟一个 int[15] 和一个 byte[80] 数组，然后是一个可能会或可能不会实际使用的区域。表中生成的一些数据似乎代表了函数再次用于在临时结构中导航的偏移量。

不幸的是，Ghidra 的反编译器在试图理解该函数时弄得一团糟：特别是它创建了单独的“local_..”int-vars（然后使用指向该 var 的指针），因为它应该是指向函数原始的指针数据结构（例如指向其中一个数组）。

Ghidra 似乎不明白当时实际上正在使用基于数组的数据访问。然后 Ghirda 的反编译器还会生成一个本地 auStack316[316] 变量，不幸的是，该变量似乎只覆盖了原始 ASM 代码使用的相应本地数据结构的一部分（至少 Ghidra 实际上确实注意到使用了临时内存缓冲区）。结果，反编译的代码基本上使用了两个重叠（和损坏）的影子数据结构，它们应该正确地只是同一块内存。

有没有办法让 Ghidra 的反编译器使用函数分配的完整 404 字节块作为 auStack404 从而绕过 Ghidra 有缺陷的解释逻辑并实际保留 ASM 代码的原始功能？

我必须对还包含 LUA 字节码的 ELF 二进制文件进行逆向工程，提取 LUA 字节码以使用 luadec 或类似工具对其进行反编译的最佳方法是什么？

目前我在 Ghidra 中加载了二进制文件，主要了解功能以及如何加载 lua 代码，但我在这些事情上不是很有经验。二进制文件使用 luaL_readbuffer() 加载脚本，这些脚本似乎作为变量嵌入到二进制文件中。

谢谢！

在分析 Ghidra 中的装配清单时，我不清楚以下说明：

在 MOV 中，我假设寄存器 ECX 将获得指向寄存器 R13 + 8129 个位置（或 2048 个字节）的值。这个假设是当前的吗？

在 LEA 中，将 R13 + RSI 的值 + 8196 位置（2049 字节）的指针分配给 RDX。这是对的吗？

否则，我应该如何解释这些说明？

对于某些方法，Ghidra 的反编译器背景窗口是灰色的，我无法重命名函数或局部变量。为什么？

它适用于具有“白色背景”的方法。

例子：

匹配代码