C/C++编译产物源码恢复

解决什么问题

二进制发布、甲方交付或事故应急时，常见的一种困境是：手上只有可执行文件，没有源码。一个典型场景是项目使用 CMake 构建，最终只交付 /usr/local/bin/worker，把 src/ 和 include/ 留在了上一任手里。代码重构、安全审计、跨平台移植都可能因此卡住。手工看 objdump -d 输出很容易在几百行汇编里迷路——你需要一个从二进制到工程化源码的系统化恢复流程。

技能如何工作

• 编译器指纹：用 file 与 eu-readelf 判断架构、位数、端序，识别 GCC/Clang/MSVC 特征，并推断 -O0～-O3 优化级别与 stripped 状态。
• 反编译主链：Ghidra/IDA 自动分析生成伪 C；带 -g 的二进制优先用 objdump/gdb 提取符号和类型。
• 类型重建：从 vtable/RTTI 还原 C++ 类布局，标注 this、虚函数表与模板实例化痕迹；stripped 二进制用 Ghidra 类型推断与 FLARE 辅助。
• 工程化输出：按模块切分到 src/、声明还原到 include/*.h、生成 CMakeLists.txt 骨架，并通过编译验证比对行为一致性。

适用边界

• 合法性：仅用于自有产物、授权恢复或备份找回，不要用于未授权目标。
• 非 1:1 还原：变量名、宏、注释通常丢失，得到的是语义等价的伪 C，而非原始源码。
• C++ 更难：模板、虚函数、RTTI 的重建需要人工辅助，恢复率低于 C。
• 优化干扰：-O2/-O3 会打乱控制流，建议启用 Ghidra 的类型传播；外部库调用以 stub 声明保留，避免无限展开。