当修补程序然后使用导出二进制函数时,它会导致elf 标头损坏。
有没有办法解决这个问题?
当修补程序然后使用导出二进制函数时,它会导致elf 标头损坏。
有没有办法解决这个问题?
初步发行说明将此列为 Ghidra 10 的一项功能,应在“2021 年 6 月中下旬”发布:
添加了将使用 PE 和 ELF 加载器导入的程序写回其原始文件布局的新导出器。用户在程序数据库中修改的任何文件支持的字节都将反映在写入的文件中。当前不处理作为导入过程一部分的字节,例如重定位或修改的内存映射。
一旦 Ghidra 10 发布,就可以使用该过程的详细信息编辑此答案,但很可能它与当前不生成有效二进制文件的“导出器”类似。
请注意,Binary 导出并没有被破坏,它只是被误解了。这个导出器只是以二进制形式转储 Ghidra 中定义的初始化内存块。这些块是按顺序附加的。它从未打算重新创建可加载/可执行的二进制文件。虽然这当然是一个理想的功能,但它在 Ghidra 中尚不存在。
https://github.com/NationalSecurityAgency/ghidra/issues/19#issuecomment-591596603 上的“官方”声明
Ghidra 本身目前(2020 年 4 月)不支持此功能,并且需要一些外部脚本/分叉并进行一些权衡,因为在最一般的意义上,您不能将地址空间转回可执行文件。但是对于修补指令的常见情况,有以下选项:
目前正在https://github.com/NationalSecurityAgency/ghidra/pull/1505上开发一个 PR ,旨在实现二进制补丁
如果构建自定义分支对于快速补丁来说太费力,另一个更简单的选择是使用像https://github.com/schlafwandler/ghidra_SavePatch这样的脚本