0

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

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

    undefined4 local_17f;
...
    dest= &local_17f;
    for (i = 0xf; i != 0; i = i + -1) {
      *dest = 0;
      dest = dest + 1;
    }

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

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

4

1 回答 1

0

我想我找到了一些东西。在“列表”视图中，使用的局部变量布局显示为函数标题下的注释。似乎通过右键单击该注释中的相应 local-var 行，可以将“设置数据类型”应用于相应的局部变量。啊，然后是我一直在“功能/”编辑堆栈框架“下寻找的东西:-)

于 2022-01-14T15:54:32.233 回答