MacOS AARCH64下Ghidra修改Rust二进制后进程被杀求助

核心问题定位 #

SIGKILL(9)是系统强制终止进程的信号，在ARM64架构的macOS/Linux环境下，针对你遇到的情况，最常见触发原因是代码签名验证失败或Rust默认安全机制（如栈保护、控制流完整性）触发，其次是Ghidra导出时破坏了二进制文件结构。

1. 代码签名与系统安全校验问题 #

Rust编译的二进制默认带有安全机制，部分系统（尤其是macOS）会对修改后的二进制做签名校验，发现篡改后直接终止进程。

• 解决步骤：
  • macOS环境：移除二进制签名

    codesign --remove-signature <你的修改后二进制文件>
    

  • Linux环境：临时关闭AppArmor/SELinux限制

    sudo aa-disable /path/to/your/binary
    # 或临时关闭SELinux
    sudo setenforce 0
    

2. Ghidra导出的二进制结构损坏 #

Ghidra导出功能可能破坏了ARM64二进制的页对齐或段表结构，导致系统加载失败。

• 解决方法：
  • 跳过Ghidra导出，直接用命令行工具修改原始二进制：先在Ghidra中定位到要修改的偏移地址，再用dd指令直接写入修改后的字节

    # 示例：假设修改偏移0x1234处的指令，原字节为0x35000010，修改为0x35000020
    printf '\x20\x00\x00\x35' | dd of=your_binary bs=1 seek=0x1234 conv=notrunc
    

  • 检查二进制段结构：用readelf -l your_binary（Linux）或otool -l your_binary（macOS）确认段的Align值符合ARM64要求（通常为4KB对齐）。

3. Rust控制流完整性（CFI）触发 #

Rust默认开启的CFI机制会校验控制流合法性，修改分支指令会破坏这种完整性，触发系统终止。

• 解决方法：
  • 重新编译Rust程序时关闭CFI和栈保护：

    RUSTFLAGS="-C control-flow-protection=none -C no-stack-protector" cargo build --release
    

  • 对已修改的二进制，用patchelf（Linux）移除CFI相关的动态链接依赖（如果存在）。

4. 未修改直接导出失败的特殊处理 #

如果未修改直接导出也被SIGKILL，说明Ghidra导出功能破坏了Mach-O/ELF文件头结构。

• 解决方法：
  • 直接复制原始二进制作为基准，再用dd手动修改指令，完全避开Ghidra导出环节
  • 对比原始二进制和导出二进制的哈希值，确认是否存在意外修改：

    sha256sum original_binary exported_binary
    

内容的提问来源于stack exchange，提问作者Milan Š.