世上有两类论文,被人诟病的(然后改进的)和那些没人读的。-- 白岩松
最近突然发现G.O.S.S.I.P之前的一篇研究论文(K-Hunt @ CCS 2018)被人吐槽且改进了,而且人家还非常有心——论文的标题继承了我们之前的研究工作。除了作者之外,可能我们是全世界最有资格推荐这篇论文的,那今天必须要来介绍一下:
这篇论文是对我们的CCS 2018论文提出的自动化密钥分析系统的改进(关于之前的工作,可以参考 https://www.inforsec.org/wp/?p=2961 的相关中文分享)。首先人家上来就吐槽说K-Hunt在GitHub上的开源项目(基于Intel PIN开发的一套分析组件)不够完整,当然这个里面确实有一些配置文件是需要手工去设置的(比如要记录的地址范围,要分析的特定指令以及相关数据),而且由于后续该项目也进入了和企业合作的范围,因此就没有精力去特别维护开源项目了,只有在交通大学来修IS308《计算机系统安全》课程的同学能够享受到指导哦(硬广,欢迎大家选课)。
接受批评,然后我们来看看作者对我们的工作进行了什么改进:作者指出,K-Hunt的一些启发式的检测特征(例如关注memory buffer的长度)可能会导致检测失效(这个我们后面会说,论文的观点不太对);对于某些会把key和data都当成数据、用同一个函数进行处理的情况也会失效。所以作者提出了一套更为复杂的流程(如下图),也就是K-Hunt++的工作流程
从这个流程可以看到,K-Hunt++ 一开始还是沿用了K-Hunt的思路,即先要在二进制代码中定位所谓的“crypto block”,也就是那些负责密码算法操作的代码基本块;然后,K-Hunt++ 提出了更为复杂的定位“key loading block”这一设计;在接下来识别那些和crypto key相关的操作指令时,K-Hunt++ 增加了4类新的特征;最后K-Hunt++还增加了一个调试步骤来输出key(感觉有点画蛇添足,直接在代码插桩分析的时候输出也行吧)。下面我们来具体点评下这些步骤。
首先,第一个步骤没什么好说的,和K-Hunt的思路是一致的。到了第二个步骤,K-Hunt++ 在实现细节上写得有点草率,大概的意思是不光要关注所有crypto block,还要扩展地关注涉及到crypto key加载的代码基本块——key loading block,所以要执行一个数据依赖性分析;这部分在K-Hunt里面是没有考虑的,K-Hunt只关注数据是怎么从用户(或者外部)的输入传播到最后的使用,至于为什么要考虑这个,是因为K-Hunt++在第三个阶段(识别key)的时候,把K-Hunt那个比较粗糙的function-level的数据传播分析改成了一个细粒度的数据污点分析,但是这个其实就引发了一个问题,也是我们前面说的作者吐槽得不太对的地方。
在K-Hunt原来的设计中,正是因为使用了function-level的数据传播分析,只关注一个函数的输入和输出,所以不会被函数内部的一些局部的buffer干扰,而K-Hunt++ 虽然使用了细粒度的数据污点分析,就不可避免地要去处理各种函数内部的临时buffer,这可能也是K-Hunt++ 为什么要在第三步加入了更多的启发式分析来帮助判断到底哪个buffer才是key的原因?总之,到底是K-Hunt++ 这个设计更好还是K-Hunt原来的策略更优,要留给读者去思考啦~
补充一下,这篇论文是它所发表的会议(CheckMate Workshop https://checkmate-workshop.github.io/ 一个关注软件调试分析,特别是通过这类手段恢复软件中的秘密信息的小会)上的另一篇论文Tools and Models for Software Reverse Engineering Research的姐妹篇,作者在另一篇论文中介绍了TREX
逆向工具箱,可以帮助进行内存搜索、密钥恢复等任务,K-Hunt++也是它的其中一个插件,大家可以去访问一下(见文末“代码”链接)。
无独有偶,在刚刚进行的r2con 2024会议(https://rada.re/con/2024/, 参见我们的公众号好友“非尝咸鱼贩”的介绍【r2con 2024 将在油管同步直播】)上,也有一个相关的议题,大家可以配合服用,效果更佳!
最后,感谢远在万里之外有人关注我们的研究(想到研究成果真的会被人仔细挑刺,觉得还蛮酷的)~
论文:https://thomasfaingnaert.be/publications/Faingnaert_2024_KHuntPP.pdf
代码:https://github.com/csl-ugent/TREX