《星球大战》衍生剧《曼达洛人》里面有一句经典台词——“This is the way”，关于这个way（可以翻译为“道”？）在软件调试中，也有很多不同的“道”，今天为大家推荐的这篇论文Debugging the OmniTable Way就介绍了一种新型的调试（debug）之道从学习写代码开始，我们就知道bug是很难避免的，debug往往是程序开发中重要的一环，但是debug的方法也有高下之分，例如很多初学者通常都只会用经典的printf大法来进行调试，而高阶一点的分析可能会使用诸如ollydbg或者gdb这样功能强大的调试器，更为复杂的debug甚至会用到代码插桩技术。不管怎么样，debug的核心在于观察程序执行不同瞬间的状态。为了实现这一目标，分析者往往需要记录软件的运行状态，并将其输出以供理解。然而我们知道，（基于中断的）debug方法往往对软件的运行产生非常严重的干扰，特别是极大拖慢了软件运行的速度。另一方面，观察软件运行时的各种状态，往往需要记录海量的信息，这个也是诸如使用朴素的printf大法无法有效做到的。本文作者大概是受到web开发的影响比较深，提出了一种名为OmniTable的调试编程范式。这种范式的核心思想是把程序运行状态记录下来，并存储在一个关系型数据库中，然后用类似SQL查询的方式，方便后续的分析。作者认为，通过类似于SQL查询这样的方法来进行调试分析，观察程序状态，可以更为抽象地查看程序的执行情况，从而降低了调试的难度（呃……这个结论，逆向分析师要不要出来表个态）。无论如何，作者的这个设想还是为debug引入了一种新的风格，我们来看看所谓的“OmniTable之道”具体是什么样的。作者设计了一套程序运行状态的记录机制，如上图中Figure 2所示，代码运行过程中，在特定时间和eip下，分析者关心的变量（used、entry）的值都被记录下来了。如果分析者需要更简略的信息，也可以关注Figure 3这种以函数为粒度的插桩记录（只关心函数的参数和返回值）。实际上，作者研发了一套名为SteamDrill的系统，能够对下面的一些信息进行记录。考虑到记录程序完整的运行状态产生的巨大（性能和存储）开销，作者自然会使用经典的deterministic record and replay记录方式，如果读者尚不熟悉这种方式，那么赶紧去补补课！在完成了记录之后，SteamDrill支持使用SQL查询来提取程序运行时的状态：同时，作者还为其他调试器引入了接口，例如可以为gdb的python binding提供查询能力作者使用了Apache、Memcached、Redis和SQLite作为评估对象，分析了对这些程序进行特定的调试任务所需要编写的查询语句的复杂度：当然，性能方面的开销评估也少不了。作者对SteamDrill和gdb进行了性能对比（怎么好意思去对比gdb……）最近今年将程序分析和数据库结合的设计是越来越多了，我们也对OmniTable这个范式是否能流行如CodeQL之类的分析拭目以待！论文PDF：https://www.usenix.org/system/files/osdi22-quinn.pdf
还没有评论，来说两句吧...