现在的做法
核心循环：“不断扩圈”
每一轮选择拥有足够上下文的函数，将其完整逆向分析还原为可编译的C代码。
目前的条件：如果一个函数所有的代码入边都来自已知函数，则认为他是可分析的函数。
问题：
- 完全没还原出来结构体
- 只有函数重命名，结构体0还原
- 重命名质量非常低
- 现象：没有统一性（也就是相同功能的函数只有一部分被正确重命名了）
- 原因：
- 对间接相关性的函数支持差
- 只有直接code xref想连的函数才正确分析了，通过data xref相连的完全没有分析
- 重命名没有数据段内容支撑
- 现象：比如引用对应函数的data地址，实际上周围提示了是XXXX服务，但是函数没有意识到
- 现象：比如虚表意识不到
- 重命名被干扰的现象很严重
- 比如大量的runtime_frame、runtime_object等垃圾名字
- 原因：single pass，并且sop缺乏引导
- 缺乏高层次自主理解&建模能力
- 现象：
- 无法意识到一系列函数实际上是std_string
- 无法意识到一系列函数是json object的相关方法
- 最基本的原型还原都做不到
- 现象：缺参数
- 原因：对ghidra的输出格式不熟悉，看不出来这种in_XX其实是没定义好的参数
undefined4 fn_040697D4_sabine_list_first_payload_or_zero(int param_1) { int iVar1; undefined4 uVar2; int *in_r5;