Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

An Observational Investigation of Reverse Engineers’ Processes

作者:Daniel Votipka, Seth M. Rabin, Kristopher Micinski1, Jeffrey S. Foster2, Michelle M. Mazurek

单位:University of Maryland; 1Syracuse University; 2Tufts University

会议:29th USENIX Security Symposium (USENIX Security 20)

原文:An Observational Investigation of Reverse Engineers’ Processes

本文通过访问调查的方式,对逆向工程(RE)的工作流程进行了研究。经过调查,本文定义了RE的三阶段模型,并明确了三阶段中经验的作用,罗列了RE中用到的方法、工具、和特征模式(beacon)。本文最终提出了对RE工具设计的5条指南。

研究现状

自然决策过程NDM

即对领域专家的决策过程的研究与建模。一种典型的决策方式为识别驱动决策RPDM,在这种方式中专家先对所处的状况进行元素分解,然后从中识别出和以往的经历中类似的场景,最终运用经验来解决问题。这种决策方法见于消防员、软件工程师等很多专业人士,因此可能也对RE过程适用。

在对决策过程的研究中,一种典型的研究方式是关键决策法CDM。这种方法要求被试复述一次最近的专业过程,由研究者对其中的兴趣点进行深入的提问。

程序理解 Program Comprehension

程序理解主要研究开发者在阅读代码时如何思考。一般当开发者面对一份陌生的代码时,遵循作出假设/验证假设的模式。开发者根据特征模式(beacon)来做出假设,然后通过抽象解释、样例测试、反例证明等方法来验证自己的假设,如此循环,不断加深自己对代码的理解。

RE中很可能也存在着这样的思维过程。然而值得注意的时,RE过程中没有源码、没有文档,而且往往存在着一些反调试措施。另外,正向分析和逆向分析在目的上也有所不同,正向分析最终要实现的多是代码调试、更新,而逆向分析则多为寻找漏洞或恶意行为发现。因此RE中的思维方式可能和正向的PC有所差别。

其他研究基础

作者调查了一些RE工具的改进工作,但是认为这些工作在设计上很主观,立足于一个观察展开,并没有一个很系统的指导理论。作者认为RE的工具的改进最终应当追求“让计算机消失”。

另外还调研了对漏洞挖掘过程的研究,包括一篇本文一作的前作,但是这个过程包括了很多RE以外的内容,包括生态建设等。作者在本文中聚焦于RE过程。

研究问题

作者决定本文主要讨论3个问题。

  1. RE过程包含哪些主要过程?
  2. RE过程中常用到哪些技术手段/典型行为?
  3. RE过程中的工作流程与传统的程序理解流程有何不同?

调查设置

本文包括了16名逆向工程师的访谈结果。对于每次访谈,都至少进行了70分钟,由有多年逆向经验的一作进行提问,全程录像。对于每位受访者,提供了40刀的礼品卡以示感谢。在正式的访谈之前,进行过两次领航员测试,并调整了设问。

调查的进行方式参考前述的CDM方法,由被试重现最近一次逆向的过程,研究者在观察中提问。选择一个被试没有分析过的程序更能反映他们的操作流程,但是可能导致调查时间不收敛,因此最终选择分析过的程序。

调查分为两部分:

  • 程序背景。由被试介绍自己所选择程序,其功能和规模,分析中用到了什么工具,是否有与他人进行合作。
  • RE过程。首先由被试介绍自己逆向分析的目标,然后被试演示逆向过程,屏幕全程分享,研究者可以从中捕捉工程师下意识地、没有描述的行为,并进行提问。

提问主要从以下要点出发:

  • 决策过程。RE中需要选择对哪段代码进行分析、用什么方法进行分析。研究者会要求被试说明决策的依据。
  • 问题与假设。根据PC方面的研究,这是程序理解过程中的核心概念。研究者会要求被试说明为什么假设可能成立,以及要怎么样验证假设。
  • 方法与技术手段。研究者关心被试是否使用了工具,并会收集工具的信息以及被试对工具的评价。研究者也关注被试使用的方法,会就方法的使用频率、输入输出、以及什么时候更换方法进行提问。
  • 特征模式。哪些东西是逆向工程师关注的特征,它们是如何被注意到的。
  • 文档和其他网络资源。研究者关心其使用频率以及对资源的选择依据。

调查过程显示出了一些本研究的固有限制,包括:

  • 有的被试可能不记得自己当时是如何解决一个问题的,但作者认为CDM可以帮助他们进行补充。
  • 因为保密的规定,有的被试对他们工作的一些细节表示无可奉告。大部分人不能演示的包括自己所使用的关键字表等一些操作性细节,但也有几位被试因为工作关系只能选择CTF题目进行演示。
  • 本文的调查是面向专家的,不考虑新手的学习过程。

本文的被试招募自技术论坛、与漏洞挖掘团队进行接触、在RE相关会议现场进行的招募。为了保证研究是面向专家的,作者要求被试具有至少3年的逆向经验,且在技能的5级自评中至少具有3级的熟练度。总共有68人应聘,42人合规。作者对被试进行了随机抽取,调查到16人时观察到结果收敛(新的被试没有带来新的结果),此时停止实验。16名被试的情况如下表所示。

image-20200409152535565

结果:三阶段过程模型

image-20200409152631169

作者发现所有被试的工作流程都可以概括成三个阶段,overview、sub-component scanning、focused experimentation,其中后两个阶段构成循环,这也与程序理解的过程类似。面向恶意软件和面向漏洞挖掘的逆向分析的过程都符合这三阶段,只是所选取的beacon有所差异。

Overview

这个阶段的目的是找到初步的兴趣点。典型行为包括:

  • 列出API和字符串。这些信息提示了程序的特征行为。
  • 尝试运行程序:可以了解程序的功能,找到兴趣点,能根据UI定位到执行流程。
  • 查看元数据:如ASLR、DEP是否启用等。
  • 对于恶意软件分析,一个特有的步骤是脱壳。

与程序理解相比,overview是逆向分析所特有的一个步骤。这被解释为正向的开发者对程序有一定的先验知识,不需要这个过程就能了解到这些信息。

Sub-component Scanning

这个阶段的目的是扫视代码,做出假设。典型的行为包括:

  • 在代码中扫视beacon。这有助于推断代码的意图和作用,如一串特定的API调用序列和字符串可以说明一段代码是在做HTTP测试,进而可以推断出其意图是测试网络连接性。
  • 追踪控制流/数据流。可以借此判断输入输出的关联性,判断是否存在导致某种特定行为的路径(特定调用序列、内存错误等)。

与程序理解相比,这个阶段所使用的beacon明显不同。正向的开发者有变量名、注释等语义信息,丧失了这些信息的逆向工程师需要通过很多其他的信标来弥补。

Focused Experimentation

这个阶段主要是要验证前一个阶段所作的假设,加深对代码行为的理解,准备下一轮分析。典型行为包括:

  • 执行程序。会使用调试器或者是IO监视器。可能会用到对寄存器或二进制的修改,以快速进入待测试的部分。可能会用到fuzzing,但基本上是手工的。
  • 与样例程序对比,包括代码的数据流控制流的比对和输入输出对拍。例如加密算法,对比程序和输出可以确定算法的类型、参数上有无修改。
  • 细读代码。不常用的方法,一般只在代码很短或一些重要的代码段上用。有时是不得不,如一些嵌入式固件,要运行起来需要搭建模拟器,可能会很花时间。会用到符号执行,但是是手工分析为主,如果程序比较复杂会写Z3帮助计算。
  • beacon在这一阶段仍然可以作为捷径使用。

这个阶段的行为基本与程序理解类似,除了样例程序对比。

结果:各阶段显示出的倾向

image-20200409155118699

作者概括了调查中除了三阶段模型以外的发现,包括:

  • 前两个阶段多用静态分析,但第三个阶段多用动态分析。然而前面提到了,2、3两个阶段往往是交替循环的,因此工程师需要在静态分析工具和动态分析工具之间来回切换,而现有的工具往往并不支持这样的同步。很多工程师把两种的工具的窗口并排。
  • 经验在三个阶段中都有作用。对前两个阶段,经验可以帮助选择要关注的代码段;对于第二个阶段,经验可以帮助工程师识别代码的行为和潜在的问题;在所有的阶段中,经验都可以帮助工程师选定分析方法、有效地解读结果。
  • 大家都喜欢能把输出关联到代码上的工具。
  • 大家经常会想办法改善代码的可读性,如对变量重命名、记笔记等。
  • 大家经常在网上查指令和API的文档;对于一些没有太多文档的部分,大家会选择搜索博客或者是Stack Overflow。另外大家经常通过谷歌搜索一些魔法数,来确定算法。

交互设计指南

image-20200409155203715

作者根据以上的发现,归纳出了5条RE工具的交互设计指南。

  1. 工具的设计要与三阶段模型相符;即工具能提供总览、特征摘要、详细信息等不同的视图。样例程序包括IDA和R2,这些程序被认为有良好的扩展性,可以提供各种不同的界面,但是没有成形的工作流导航。
  2. 输入和输出都应该与代码相关联,如一位被试提到,希望能在代码上直接设置污点源、查看污点扩散的结果。样例的Lighthouse能够在基本块上通过高亮显示覆盖情况,但输入仍然不能直接在代码上进行。
  3. 静态分析、动态分析的数据互通。没有现有工具可以做到这一点。难点在于信息的展示设计,而且可能需要增量话的分析方法来控制性能开销。
  4. 给用户选择权,来选择分析的方法和精度。如Hex-rays的工具,可以选择反编译的选项来平衡准确性和性能(?),而且还可以和反汇编器一起工作。但作者提到有时大家会有混合精度分析的需求,而目前这样的混合分析还很难做。
  5. 支持对可读性的改进。工具可以尽量推断出有意义的名称,另外一定要允许用户更改分析的结果。