如何让 Ghidra 使用函数的完整/原始堆栈帧进行反编译代码答案

【问题标题】：how to make Ghidra use a function's complete/original stackframe for decompiled code如何让 Ghidra 使用函数的完整/原始堆栈帧进行反编译代码
【发布时间】：2022-01-15 01:33:19
【问题描述】：

我有一个例子，其中一些函数在堆栈上分配/使用一个 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 代码的原始功能？

【问题讨论】：

标签： reverse-engineering ghidra

【解决方案1】：

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

【讨论】：