JANlittle's Blog

概要 这是目前已知的第一篇探究编译优化是如何具体影响反编译器控制流结构化并试图逆转这种优化的论文。 ASU（shellphish）的研究团队认为，反编译器的结果质量衡量最重要的不是降低复杂度或者消除goto，是尽可能接近原始源代码。而**产生不可控制流结构化的控制流图的根本原因，就是编译器优化以及反编译器和编译器之间的知识差距。**为此，反编译器必须是“编译器感知”的，能够知道当前没能正确匹配的控制流子图是由哪些编译优化引起的，又该如何“反优化”。 为了验证这一目标，作者探究了具体的编译优化选项会导致怎样的异常控制流图，同时在angr的反编译器上开发了第一个“编译器感知”的控制流结构化算法：SAILR。并且经过测试，发现SAILR的CFGED等指标可以与IDA Pro相接近，并且领先于先前的研究成果，如DREAM、revng等。 介绍 在恢复C控制流结构时，原始的控制流结构会被编译器优化所扭曲和破坏。这在反编译器的输出上表现为虚假的goto语句。 文中认为，产生不可结构化代码的根本原因是：编译器优化以及反编译器与编译器的知识差距。 反编译器常常使用图模式匹配来结构化控制流子图，但由于编 ...

抽空系统学下angr关于符号执行的一些api。通过angr_ctf来学，可以自己构建，不过solution目录下有已经构建好的程序、练习文件和参考答案，直接用就行了。目录下的SymbolicExecution.pptx还详细讲了一些符号执行的入门知识，可以看看。 00_angr_find 解常规逆向的基本框架，输入来自stdin。同时如果想默认从main函数开始执行，使用entry_state作为初始状态。 12345678910111213141516171819202122232425262728293031import angrimport sysdef main(argv): path_to_binary = './00_angr_find' # 起project，需要视情况加参数 project = angr.Project(path_to_binary) # 起始状态，entry_state表示main() initial_state = project.factory.entry_state( add_options = { ...

不知道从什么时候开始，有些老b登构建Rust程序时会把符号strip掉（尤其是在恶意软件和CTF中），大幅度降低了逆向体验😅。如果能恢复符号，哪怕是std库的那些函数符号的话，可读性都会提高很多。 恢复符号的话，一个方法是函数相似性匹配，往小了看有bindiff，往大了看有BinaryAI或者其它一些大数据AI，但前者你需要构建一个合适的程序进行diff，并且选择什么范围的similarity和confidence也是个比较玄学的问题；后者的话目前并没有什么大型的在线大数据匹配有存储大量的rust函数语料。 除此之外，另一个方法就是依靠像IDA和BN这样的反编译器为rust程序所用到的库做签名文件，例如FLIRT和sigkit。它们有着相似的思路：匹配函数硬编码字节与调用图等。其实这就有点像它自动化地做了bindiff的一些事情并顺便帮你做匹配了。这个方法最大的优势就是方便！ 对于本地进行符号恢复，无论是bindiff还是为特定反编译器构造签名文件，最重要的当然还是正确构造程序使用的库以进行匹配了。但就像匹配C库的函数你需要考虑编译器版本和库版本等因素一样，在rust中你同样需要考虑 ...

原博客文章链接：https://binary.ninja/2024/06/19/restructuring-the-decompiler.html 概述 Binary Ninja在4.1版本重构了反编译器，主要集中在其控制流结构化的策略上。这篇博文简单介绍了设计变化，同时这也是一篇挺好的介绍反编译器的主流控制流结构化策略的文章，值得记录一下。 所谓控制流结构化，就是识别控制流图模式，并将其转化/折叠为高级线性表示，例如C语言中的if...else...语句。 一般来说，在没有优化的情况下识别经典的C语言控制流语句生成的控制流图是非常容易的。但是在编译优化的影响下，函数控制流图的节点和边会被添加/删除/合并等，导致无法与经典控制流图模式相匹配。反编译器在面对控制流结构化时，最主要的挑战就是当控制流子图无法与现有模式匹配时，怎么做才能最大程度提高反编译结果的可读性和准确性？ 主流的几个策略 遇事不决添加goto 这个策略算是所有反编译器都会采用的手段，主打一个无脑。**当控制流图无法与已知模式匹配时，反编译器会为节点添加goto语句，并删除其出边来简化图结构，从而与已知模式相匹配。**当然 ...

前前前一阵子打了Codegate CTF 2024 Preliminary，有个逆向题(prism_messenger)是Rust+OLLVM平坦化，真的是天才组合啊😅！恶心到我了，同时直接把D810给干崩溃了，qiling的模拟执行也不好使了，事后不得不多瞅了它几眼。 特点 看起来这个Rust程序像是通过源代码级别的宏展开生成的平坦化代码，它有很多跟一般平坦化程序不一样的特点，大部分特点很像是先平坦化后再被编译器优化所得到的结果。以去平坦化的三个步骤来考察： 识别不同块的功能 在这里也就是说识别一个块是分配块、预分配块、虚假块、还是真实块的问题。 首先预分配块可以说是不存在的，或者说跟分配块所合并了，因为大部分真实块到最后会直接跳转到分配块，而不会经过预分配块的中转。也就是说，分配块的前继都是各个真实块，已经没有统一的预分配块了。 其次，真实块也不再是单独一块，而是被分割成好几个子块，有些子块被多次引用，很像是编译优化压缩函数大小导致的。这就为识别谁是真实块带来了很大的挑战。 识别真实块的后继块 真实块中的条件分支可能不再单纯只是根据条件不同修改状态变量实现真实块之间的条件跳转， ...

好久前弄的，补个档。 概述 R1mao👴在2022年为Pluto-Obfuscator加了个新的控制流平坦化算法，旨在对抗一般的静态/动态去混淆脚本。然而他的算法可以被”动态模拟执行+BFS探索真实块“所破解。 不过这个去混淆算法没什么实用价值，因为Pluto-Obfuscator已经长时间无人维护了，R1mao👴的这个算法也没人用力，顶多就CTF偶尔有人炒冷饭吧，破它就当图个乐。 修改后的qiling脚本可以在这里找到：https://github.com/JANlittle/qiling/tree/dev R1mao👴的算法干了啥？ 一般的OLLVM平坦化中的真实块会对状态变量直接赋新值来确定它的后继。那么一般的静态对抗手法就是定位真实块对状态变量的赋值，并查找这个状态变量对应的真实块，从而确定真实块后继；一般的动态对抗手法就是遍历并模拟执行每个真实块，探索它的后继块。 R1mao👴的算法改进如下： 每个真实块都会被分配一个key变量和访问标志位。 每个真实块第一次被访问时，都会修改其后继所有块（包括后继的后继的后继…）的key变量。 只有以正确顺序访问真实块，才能依次正 ...

变量 基本 不可变、可变、常量： 123let a = 0; // 不可变变量，但可以shadowinglet mut a = 0; // 可变变量const A: i32 = 0; // 常量，必须手动标注类型 变量解构 12345678910111213141516let (a, mut b): (bool,bool) = (true, false);struct Struct { e: i32}fn main() { let (a, b, c, d, e); (a, b) = (1, 2); // _ 代表匹配一个值，但是我们不关心具体的值是什么，因此没有使用一个变量名而是使用了 _ [c, .., d, _] = [1, 2, 3, 4, 5]; Struct { e, .. } = Struct { e: 5 }; assert_eq!([1, 2, 1, 4, 5], [a, b, c, d, e]);} 整数类型 u8~u128，i ...

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub. 也可以看傻瓜教程。 Quick Start Create a new post 1$ hexo new "My New Post" More info: Writing Run server 启动本地服务器，用于在部署前查看效果 1$ hexo server More info: Server Generate static files 1$ hexo generate More info: Generating Deploy to remote sites 123$ hexo deploy# 一键生成静态文件+部署$ hexo g -d More info: Deployment ...