TL;DR魔改版下载UI配置UI配置&魔改：越像IDA越好简单UI配置快捷键配置（KeyBinding）整合已有的快捷键Meta键兼容层Ghidra功能魔改修复：魔改Inline逻辑（202302）修复：MachO Loader PTR_64 Chained Fixup（202302）修复：快捷键弹Multi Action（202302）修复：Windows下按空格无法打开Function Graph（202303）修复：Esc无法关闭很多窗口（202303）新功能：Xref框改为模态对话框（202303）修复：快捷键弹Multi Action（202303）Ghidra编译基础设施基础设施：CI加速CIScoop支持基础设施：自动Merge上游
TL;DR
魔改版下载
ghidra_mod
NyaMisty • Updated Apr 17, 2023
可以直接使用CI自动编译出来的包（全平台）
ghidra_mod-ci
NyaMisty • Updated Apr 29, 2023
UI配置
- （配置好了快捷键、UI布局、基本设置）
（旧，现已集成到Ghidra中）RemapCtrl脚本： https://gist.github.com/NyaMisty/dfd8fd9271f70122fb2f83a698baf59d
用于解决Meta键的兼容问题
UI配置&魔改：越像IDA越好
简单UI配置
- 自动高亮
- 调整Listing中Field的大小
快捷键配置（KeyBinding）
整合已有的快捷键
- Ghidra的Keybinding导出后格式为kbxml，在GitHub上面搜索可以找到4个kbxml
- 编写工具整合这些kbxml：https://github.com/NyaMisty/ghidraKb
Meta键兼容层
需要处理Meta键的兼容，否则同一份快捷键KeyBinding在Windows和Mac上操作体验会差很多：
- 把所有的Ctrl键KeyBinding转成Meta
- 把Meta键映射到对应的Ctrl或CommandKey上
旧方案：通过Ghidra Jython Script
新方案：直接整合到GhidraMod中
Ghidra功能魔改
修复：魔改Inline逻辑（202302）
- 整合@homes410的 inline patch (ezclone)
- 通过git am来apply 他的patch
git am -3 << XXX来解决冲突- 最后一个commit
git am -3也解决不了，在git am后使用patch -p1 --merge好后git am --continue
修复：MachO Loader PTR_64 Chained Fixup（202302）
Temp fix for PTR_64 DYLD Chained Fixup
- PTR_64重定位不应该加上imageBase，加了个判断
- 上游已提交issue，但官方速度慢
修复：快捷键弹Multi Action（202302）
- 修正反编译中按Y：限制在decompiler里，只有对着function identifier时候才能edit signature
Change "Edit Function Signature" enable case in decompiler
- 修正Listing中按N：原来判断是在Function上按N的时候不触发Edit Label，现在限制在全局变量上面按N的时候也不触发Edit Label
修复：Windows下按空格无法打开Function Graph（202303）
- 原因：快捷键SPACE同时被其他Action占用
修复：Esc无法关闭很多窗口（202303）
- 对DetachedWindowNode增加ESCAPE的响应callback
新功能：Xref框改为模态对话框（202303）
- 和IDA功能相同
- 困难：需要处理LocationReferencesProvider自动复用的问题（他自己手搓了个pool）
修复：快捷键弹Multi Action（202303）
- 修复Listing按H：Convert to Decimal/Hex共用
- 限制仅当当前data type和目标状态不同时启用
Ghidra编译基础设施
基础设施：CI
加速CI
- 基于roblala的ghidra-ci魔改
- 原版速度慢，需要buildNative、再build java层、再sleighCompile，最后打包
- 修改后，同时buildNative、编译Java、编译JavaDoc、编译Sleigh，最后打包
Scoop支持
重新针对于我的ghidra魔改版本增加了scoop repo
基础设施：自动Merge上游
- 上游的修改很频繁（一天很多次），不可能手动同步
- 原来在其他repo尝试过rebase、merge
- rebase：
- 优点：保持upstream的commit id
- 缺点：如果我魔改的commit比较多，那么每次就会有巨多的commit rebase
- 反着rebase：
- 优点：保持我魔改的commit id
- 缺点：完全无法track上游
- merge：
- 优点：保持upstream的commit id
- 缺点：会带来mergecommit，导致log里出现很多个自动merge的commit，不好rebase
- 考虑之后决定还是用merge，但是避免出现多个AutoMerge commit
- 加入检查，如果上一个commit就是automerge，那么就drop掉重新automerge一次