昨日,让我很寒心的事情出现了。因为A问我:“大蒜是什么?”而我居然无法解答。
大蒜,英文名IFFA(Interactive File Format Analysis) 交互式文件格式识别系统。
其实这个词语也不能完全表达这款软件。
前几日B问我,文件格式用010editor他不香吗?
所以丢了一个词语:未知。 应该是交互式未知格式识别系统。虽然我的所有例子都是用BMP PNG已知格式去做文章,但是他确实按照未知格式来识别的。退一步讲已知格式的识别有什么技术含量?有什么含金量?我怎么能做出那种低端货?
这样描述就准确了吗?不。因为接着又有C问我,AFL不牛逼吗?为啥还要用大蒜?
这里要再强调两个词。一个是非动态,既非环境依赖。一个是非代码依赖。
而AFL是依赖程序代码的,无论的源码还是二进制,说白了都是代码。
AFL是动态的,需要动态调试的。这就依赖环境了。
AFL运行还引用了其他乱七八糟的一大堆库,配置过AFL的就都知道了。如AFL依赖于动态插装的类库DynamoRIO。
而大蒜完全基于win sdk开发。程序不依赖于任何第三方库。完整知识产权。
AFL的工具有很多,而大蒜这种功能的产品,至少我没有见过类似的产品。因此又多一个词:唯一。
所以,准确的命名应该是第完整知识产权 唯一 纯静态 非环境依赖 非代码依赖 的交互式 未知文件格式/协议识别系统。
我的官网介绍是:
不去逆向.不调试.不分析代码.
智能化对大量样本分析,推出格式信息
也可自动化输出以往需要手动编写的脚本(如peach的pit脚本)
可有有些人就是读不懂。那么我这里只个链接看里面的图片了。
http://www.asm64.com/IFFA/index.html
如果上面你还听不懂,那么我们就从最简单的聊起。
Fuzzing是漏洞挖掘的一种有效方法,这种方法是如何发展的?
如EasyFuzzer就是经典的第一代Fuzzer。www.asm64.com。
如上图BMP格式。你强行把文件结构改大(DNA=16) 但是你不知道他控制BMP长和宽是哪里[DNA=7 DNA=8],所以是没用的。而当你强行修改了长和宽,其下面的文件结构大小又匹配不上。再者ZIP RAR结构,各种CRC校验,你强行修改了他很难深入解析。因此随着软件的健全,第一代的fuzzer效果越来越差了。
这一代Fuzzer最典型的就是老外的Peachfuzzer了。
对于已知文件结构,还是从BMP结构。用户可以看官方文档,然后去编写相应的Peach 脚本。这个事情只需要花时间就可以完成了。
但是对于未知的文件结构或者协议。那么只能通过逆向了,看汇编代码去分析逻辑信息,然后继续写pit脚本。
对于未知并且拿不到源码的情况下(如软件拿不到,软件被VMP等加壳),那看领导是否强势了。不强势被骂一顿,强势就等着离职继续找工作吧。
其实还好,对于大部分软件,投入人,投入时间,其实就可以搞定的。
随着节奏发展越来越快,大家不愿意再用peachfuzzer。
为了一个漏洞逆向几周甚至几个月,最后还可能没有任何结果。于是谷歌大神开发的AFL出现了。只需要给程序一个地址,然后给几个样本,然后他完全就可以自动的去跑了,你等着去收poc就行了。
AFL最牛逼的时候,可能就是现在了。据统计,安全圈超过80%的安全研究员,都在用AFL去挖掘漏洞,可见AFL是有多么的牛逼。那么缺点也是有的,因为这条路对于大部分人来说是直线的,没有什么分支。就是说谁先搞就是谁的漏洞。用他挖掘出东西,除了证明afl软件牛逼,还能说明什么呢?
总结如下:
刚才说完第二代fuzz,peachfuzzer。难点就在于需要逆向,需要写源码。如果这些工作交给软件自动去完成。或者是不依赖于代码,不依赖于动态环境去完成,那岂不乐哉?
而交互式,让你的智慧和大蒜的智慧发生碰撞,最终生成你爱的那个宝贝儿。
没做,这,就是大蒜。
下图为大蒜自动生成的peachfuzzer用的脚本。
总结如下:
Fuzzer发展 | 代表作 | 优点 | 缺点 |
第一代 | EasyFuzzer等 | 速度快 | 效率低 |
第二代 | Peachfuzzer等 | 速度慢 | 效率高 |
第三代 | AFL 等 | 速度快 | 外界依赖性高,Windows下需要逆向能力。 |
第四代 | 大蒜 | 速度快 效率高 依赖性低 无竞争对手 | 丑 |
或许在未来,“静态未知文件格式识别”方向,大蒜做不到最好的那个,但是大蒜已经做到了第一个。