[PAPER] Challenges in Firmware Re-Hosting, Emulation, and Analysis

PAPER

https://engineering.purdue.edu/dcsl/publications/papers/2020/firmware-analysis_csur_2020.pdf

 

ABSTRACT

펌웨어 리호스팅 과정에서의 어려움을 정리하고,이러한 어려움을 해결하는 과정과 사용된 툴을 조사했다. emulator 종류, 시스템 타입, 충실도, emulator 목적, 제어의 5가지 측면으로 분류 기술을 설명한다. 이 분류와 비교 기준은 emulation에 대한 적절한 툴을 사용할 수 있도록 한다. 분류를 필드에서의 유명한 작업을 분류하는데 사용하고, 펌웨어를 가져오는 것부터 emulation 분석을 할 때의 생성, 에뮬레이팅, 분석 시 직면한 28개의 문제를 제시한다.

 

1. INTRODUCTION

Embedded system emulation

• 하드웨어 없이 임베디드 소프트웨어 테스트를 가능하게 하고, 임베디드 시스템 펌웨어 내 취약점을 찾고 예방하는데 돕는 기술이다.

 

Purpose

• 펌웨어 emulation을 위한 툴을 익히는데 어려움이 있으므로, 펌웨어 리호스팅에 대한 가이드를 제공한다.

 

Emulation tool/technique evaluation & classification

• emulation 툴과 기술을 분류하고 평가한다.
• 각 문제마다 해결 가능한 툴이 적힌 테이블을 제공하여 툴 사용할 때 직면한 문제를 해결할 방법을 제안한다.

 

Overview

• Section 2: emulation에 대한 역사와 배경지식 설명
• Section 3: survey work 소개
• Section 4: 서로 다른 emulation 기술 소개 및 비교
• Section 5: emulation에 대한 survey 연구 비교
• Section 6: 펌웨어 리호스팅 시 필요한 조건과 직면한 문제 설명
• Section 7: Pre-Emulation, Emulation, Post-Emulation으로 과정을 카테고리화. Pre-Emulation 과정에서 직면한 문제를 해결할 방법 제안
• Section 8: Emulation 분류에서 직면한 문제 해결할 방법 제안
• Section 9: Post-Emulation 과정에서 직면한 문제 해결 방법 제안
• Section 10: 펌웨어 리호스팅 툴 선택 시 고려사항
• Section 11: Summary

 

 

2. EMULATION BACKGROUND

2.1 Evolution of Emulation

초기 emulation 사용

하드웨어 사용을 넓히고 시뮬레이션 속도를 높이기 위한 기술로 사용되었다. 예를 들면, 대부분 프린트 소프트웨어가 HP 프린터를 위해 설계되었어서, HP가 아닌 프린터는 HP를 위해 설계된 소프트웨어를 리호스팅하기 위해 emulator를 사용했다. HP를 위한 프린트 소프트웨어를 사용함으로써 새로운 소프트웨어 설계 노력과 개발 시간을 줄일 수 있었다.

Emulation 이론

• IBM System/360 시리즈 mainframe 컴퓨터를 위한 7070 emulator로 emulation 이론이 1960년대 처음 개발되었다. 7070 emulator는 하드웨어가 업그레이드 되어도 기존 IBM 애플리케이션을 사용할 수 있도록 했다.
• 대부분 초기 emulation은 제한된 사용 가능한 소프트웨어에 대한 노후화를 피하고 하드웨어 호환성을 높이기 위해 사용되었다.
• 현재 emulator는 보안 분석과 디버깅에 잘 사용되는 툴이다.

Simulation vs. Emulation

• 컴퓨터 과학 맥락에서 보면, simulation은 내부 구현으로 시스템을 모델링하는 기술이고, emulation은 시스템 내부의 일부를 교체함으로써 모델링하는 기술이다.
• simulation은 소프트웨어로 대체되는 시스템을 말하기도 하는데, 이 논문에서 조사한 툴들은 이러한 기술을 emulation이라고 한다.

초기 emulation의 성공

• 90년대에 Bochs가 emulation에 성공했다. PC OS 개발에 필요한 하드웨어를 emulate하는 emulator로, 하드웨어로부터 OS를 독립시키는 것이 가능했다.

execution and memory fidelity

• 여러 emulator가 등장하면서, 얼마나 에뮬레이트된 시스템이 실제 시스템과 비슷한지에 대한 실행과 메모리에서의 충실도(fidelity, 정확도라고도 일컫는다.)가 높음(cycle과 레지스터 정확)부터 낮음(module과 black box 정확도)까지 다양하다.
• 충실도와 emulator 속도는 서로 다른 emulator를 구분하는 가장 큰 요소이다.

 

2.2 Emulation Bases

Simics

• 2000년대 초기에 Alpha, x86-64, IA-64, ARM, MIPS, MSP430, PowerPC, SPARC-V8, V9, x86 ISA를 포함하는 여러 아키텍처들을 에뮬레이트하기 위해 생성되었다.
• fidelity: instruction level
• configuration 관리, scripting, 자동화된 디버깅 기능 제공하고, 다른 정적/동적 분석 툴을 사용해서 emulate 시스템을 구성할 수 있다.
• DARPA Cyber Grand Challenge에서 제출된 바이너리가 대회 인프라를 준수하는지 자동으로 확인하기 위해 사용되었다.

QEMU

• emulation 속도를 개선하기 위해 정확도를 조금 포기했다.
• simulator의 sub-instruction으로 작동하는 대신, QEMU는 모든 instruction 블록을 host 시스템의 instruction set으로 해석하고 해석된 instruction을 실행하여 block level(순차적, non-control flow instruction)에서 실행하고 emulation한다.
• 각 instruction에서의 interrupt를 체크하지 않고 block을 캐싱해서 해석에서의 오버헤드를 줄여서 QEMU가 빠르게 작동할 수 있다. ⇒ fidelity: block level fidelity
• 지원하는 아키텍처: IA-32, x86, MIPS, SPARC, ARM, SH4, PowerPC, ETRAX CRIS, MicroBlaze, and RISC-V
• 여러 시스템의 peripheral 지원한다.
• 오픈소스

Ghidra Emulator

• Ghidra는 오픈소스 리버스 엔지니어링 툴이다.
• 2019년에 출시한 Ghidra에는 emulation 툴을 포함한다.
• Ghidra는 Sleigh라는 자체 processor modeling 언어와 register 전송 언어인 P-code를 사용한다.
  • 각 machine instruction는 30 P-code instruction으로 해석할 수 있다.
• Ghidra emulator는 sub-instruction level (여러 emulator instruction이 각 기계어마다 수행된다.)에서 작동
• 지원하는 아키텍처: X86 16/32/64, ARM/AARCH64, PowerPC 32/64, VLE, MIPS, MSP430, Z80, AVR 등
• 제공 기능: 로더, 디스어셈블러, 디컴파일러, 분석툴

 

2.3 Related Vulnerability Discovery Techniques

Symbolic Execution

• Symbolic execution은 프로그램 입력으로 임의 값인 심볼을 줘서 프로그램을 분석하는 방식
• 목적: 어떤 입력이 프로그램의 다른 부분을 실행할 수 있을지 분석
• symbolic execution 엔진은 심볼에 제약을 주면서 가능한 모든 프로그램 실행 경로를 찾는다.

Concolic Execution

• Concrete+ Symbolic = Concolic 으로, concrete execution과 symbolic execution 장점을 이용한 실행 방식
  • concrete execution: 구체적인 값으로 프로그램 실행해서 분석하는 방식
• emulation이나 실행 중에 symbolic symbol과 concrete symbol 사용을 바꿔가면서 프로그램을 실행하는 것

펌웨어 리버스 엔지니어링 시, 어떤 조건에서 프로그램이 특정 코드 부분을 실행할지 결정하는데 symbolic execution과 concolic execution을 사용한다.

Fuzzing

• 랜덤 입력을 줘서 취약점 및 버그를 자동화하여 찾고 시스템의 의도하지 않은 행동 (크래시 같은)을 찾는 기술이다.
• emulation 맥락에서 퍼저는 바이너리 실행에 대한 가시성과 제어를 사용해서 바이너리 탐색성능을 향상시키기 위해 랜덤 입력값을 최적화한다.

 

 

3. SURVEYED WORKS

Simics, QEMU, Ghidra emulator는 base emulator로 사용된다.

base emulator는 user 모드 emulation으로 실행 가능하거나 full system emulation(processor, 하드웨어 peripheral emulation 가능)이 가능하다. base emulator에서 가능한 emulate된 peripheral 수가 적기 때문에 많은 펌웨어 emulation 연구에서는 이 emulate된 주변장치 부족을 해결하기 위해 목적을 두고 있다.

Avatar2

• dynamic multi-target orchestration and instrumentation framework
• 펌웨어 분석에 초점을 맞춘 프레임워크
• angr, QEMU, gdb 등 다양한 툴과 통신하고 데이터 주고받을 수 있다.
• 물리적 하드웨어에서 실행이나 메모리 접근하는 부분인 loop emulation에서 하드웨어 사용 가능하다.

angr

• symbolic execution engine
• 정적/동적 분석을 위한 binary 분석 프레임워크
• 제공하는 기능: 아키텍처 라이브러리, 실행 가능한/라이브러리 로더, symbolic execution engine, built-in 분석, python wrapper

HALucinator

• base emulator에서 구현되어있지 않은 peripheral 제공의 어려움에 대해, HAL(Hardware Abstraction Layer)로 peripheral과의 통신 기능을 제공한다.
• Avatar2, QEMU를 base emulator로 사용해서 HAL 호출을 가로채고 대체한다. 리호스팅 과정에서 HAL 함수에 대한 대체할 것을 제공한다.
• library matching 툴 사용해서 펌웨어 내 HAL 함수를 식별한다.

PANDA

• QEMU 위에서 만들어진 동적 분석을 위한 오픈소스 플랫폼
• system record & replay 기능: PANDA 장점. 깊이있는 시스템 분석이 가능하다.

Muench2018

• PANDA와 $Avatar^2$를 결합하여 segment 추적, 포맷 지정자 추적, heap 객체 추적, call stack 추적, call frame 추적, stack 객체 추적 기능을 제공한다.

CostinFA, Firmadyne

• QEMU를 base emulator로 사용
• CostinFA (Costin Firmware Analysis)
  • 펌웨어에서 파일시스템을 추출하고 커널에서 파일시스템을 리호스팅한다.
  • system emulation - 소프트웨어만 사용
  • 리호스팅된 펌웨어에서 정적/동적 분석 가능
• ARMX
  • CostinFA, Firmadyne와 동일한 접근 방법 사용
  • ARM 아키텍처 기기만 지원하고, 펌웨어에서 NVRAM 추출한다.

PROSPECT, SURROGATES

• 실제 기기에 하드웨어와 peripheral 접근을 보내서 emulation을 하는 기술이다.
• HIL (hardware in the loop)
• PROSPECT는 기기로의 버스 연결을 통해 주변장치와 하드웨어에 상호작용을 전송하지만, 분석과 구현 시 시스템에 연결된 주변기기나 외부 하드웨어에 대한 지식은 필요하지 않다.
• SURROGATES의 경우, 호스트 PCI Express 버스와 시스템 사이 저지연 FPGA bridge를 사용해서 원래 Avatar 시스템보다 시스템 주변기기로나 시스템 주변기기로부터 상태 전달이 빠르다.

P2IM

• base emulator: QEMU
• drop-in fuzzer(AFL) 사용: QEMU(base emulator)에 피드백을 주기 위해 fuzzer를 사용한다.
• 주변장치와 하드웨어 IO를 추상화한다.
• fuzzer가 상호작용을 하기 때문에 주변장치에 대한 상세한 지식이 필요없고 하드웨어를 사용하지 않는다.

Pretender

• 머신러닝 사용 - 하드웨어 상호작용에 대한 모델 제공하기 위해 펌웨어 리호스팅에 머신러닝 사용
• 실행 시 발생하는 interrupt와 하드웨어 상호작용 및 메모리에 매핑된 입출력 영역을 기록한다.
• 주변장치를 클러스터링하고 각 주변장치에 대한 레코드을 서브 레코드으로 나눈다.
• 메모리 모델을 학습하고, 각 주변장치에 대한 모델을 고르고 학습한다.

 

 

4. EMULATION COMPARISON AXES

서로 다른 emulator를 비교하는 척도에 대해 설명한다.

 

4.1 Emulation Techniques

emulation of peripheral

• 에뮬레이트가 필요한 하드웨어 주변장치
• 평가 척도 중 하나는 emulator가 주변장치를 지원하는지이다.

emulate 가능한 하드웨어 복잡도

• emulator 비교 척도

peripheral interaction techniques

• 하드웨어 주변장치 제공하는 기술
• hardware in the loop (HITL)
  • instruction 실행하기 위해 emulator 사용
  • 하드웨어 주변장치에 접근이 필요하면 실제 하드웨어에 요청한다.
  • SURROGATES, $Avatar^2$
• learning
  • 하드웨어 상호작용 위해 machine learning 사용하는 기술
  • Pretender
• fuzzing
  • 시뮬레이트된 하드웨어 상호작용 위해 랜덤 생성 사용하는 기술
  • P2IM
• abstraction replacement
  • 펌웨어에서 소프트웨어 추상화 부분을 식별하고 자체 구현을 통해 추상화 부분 실행을 교체하여 주변장치 기능을 제공한다.
  • Firmadyne, CostinFA, HALucinator

 

4.2 Types of Systems

emulator가 어떤 시스템을 지원하는지 고려해야 한다.

시스템이 실행하는 펌웨어 종류에 따라 3가지 클래스로 나눈다.

 

General Purpose Embeddedd Systems (GPES)

• Type 1 embedded system
• 서버와 데스크탑 시스템에서 사용되는 범용 목적 운영체제를 사용한다.
• OS는 embedded 공간을 위해 개조되었지만 desktop level 기능은 남아있다. 컴포넌트는 분리되어있어 busybox, uClibc 등 유저 스페이스 환경과 조합된다.
• Firmadyne, CostinFA는 Linux 기반 시스템에서만 작동한다.
• 이러한 시스템을 emulate하면 데스크탑 소프트웨어와 OS을 emulate하는 것으로 큰 이득이 있다.
• 예) linux, embedded Windows, Raspberry Pi

 

Special Purpose Embedded System (SPES)

• embedded system을 위해 개발된 운영체제를 사용한다.
• OS와 애플리케이션이 따로 컴파일될 수 있고 시스템은 데스크탑 OS에서 파생되지 않는다.
• 이 시스템을 리호스팅하려면 커널 공간과 유저 공간 모두 리호스팅 해야 한다.
• 예) , µClinux, ZephyrOS, VxWorks

 

Bare-metal Embedded Systems (BMES)

• OS가 없거나 가벼운 OS-Library만 포함한다.
• 애플리케이션은 하드웨어와 OS에 바로 접근하고 하나의 바이너리에 정적으로 링크된다.
• 예) Arduino system

 

4.3 Fidelity

fidelity는 펌웨어 관점에서 emulation이 얼마나 실제 하드웨어와 비슷하게 작동하는지에 대한 것이다.

 

fidelity 분류

• execution fidelity와 data / memory fidelity로 분류하였다.
• 이 분류는 앞서 설명한 GPES, SPES, BMES 시스템 분류에 적합한 분류이다.

 

Execution fidelity

• emulator에서의 실행이 얼마나 물리적 시스템에서와 일치할 수 있는지에 대한 것이다.

BlackBox fidelity

• 외부는 실제 시스템과 동일하게 작동하지만, 내부는 실제 시스템이 실행하는 instruction과 동일하거나 동일하지 않을 수 있다.

Module fidelity

• module level의 fidelity 제공
• 예) Firmadyne - 펌웨어 리호스팅 사용 가능한걸로 원래 펌웨어의 커널을 교체한다. 어떤 모듈은 동일하게 사용하고, 어떤 모듈은 교체되기 때문에 module level fidelity이다.

function fidelity

• function level에서 시스템을 모델링하는 것이다.
• 예) HALucinator - emulation을 하는데 모든 함수를 교체한다.

Basic Block fidelity

• basic block level layer에서 에뮬레이트하는 것

instruction fidelity

• instruction level layer에서 에뮬레이트하는 것

cycle fidelity

• cpu instruction cycle에 충실하게 에뮬레이트하는 cycle level
• 예) gem5 simulator

perfect fidelity

• 실제 하드웨어에서와 동일하게 에뮬레이트하는 것
• 아직까지는 어떤 emulator도 이 perfect fidelity는 갖지 않는다.

 

data/memory fidelity

BlackBox fidelity

• 외적으로 시스템이나 외장 메모리(HDD, SDD)에 보이는 데이터가 동일한 것
• 예) 동일한 입력으로 동일한 출력을 얻는 것

Internal Memory

• 내장 메모리가 특정 실행 시점에서 하드웨어에 일관성이 있는 것

Register level fidelity

• 주어진 execution fidelity에서 내장 메모리와 레지스터가 동일한 것

Perfect

• 시스템의 execution fidelity에서 필요한 모든 메모리의 구성 요소가 동일한 것

 

각 펌웨어 emulation 기술을 앞서 설명한 fidelity로 분류한 표이다.

 

4.4 Purpose of emulator

펌웨어 리호스팅 연구에서는 [emulator 생성, 동적 분석, 정적 분석, 퍼징]을 중점으로 연구한다.

emulator의 목적

• 취약점 탐지
• legacy code 실행 가능하게 하는 것
• 하드웨어 대체
• 개발 보조
• 시스템 행위 분석

 

4.5 Level of Control

• 펌웨어 탐색 제어 기능
• 어떤 tool이나 emulator는 controlled exploration을 허용하지 않는다.

 

 

5. CLASSIFICATION OF SURVEYED WORKS

Figure 1은 fidelity 분류를 보여준다.

x축은 Execution fidelity, y축은 data/memory fidelity에 해당한다.

색은 진할 수록 툴 설정에 user interaction이 적고 automation이 높으며, 색이 엷을수록 툴 설정에 user interaction이 많이 필요하다.

 

5.1 Hardware in the loop

• fidelity 개선 시 성능이나 복잡도에 대한 trade off가 있다.
• SURROGATES
  • QEMU를 base emulator로 사용하면서, 실제 하드웨어와 빠른 통신 위해 하드웨어를 추가했다.
  • 하드웨어 추가로 peripheral 접근이 좋아지면서 execution fidelity가 높다.
• PROSPECT
  • HITL으로 data fidelity를 높인다.
• 추가 하드웨어나 HITL은 확장성은 낮추면서 emulation의 복잡도나 수행 비용을 높이기 때문에 각 emulation을 위한 전용 하드웨어가 필요하다.

 

5.2 Instruction Level Execution Fidelity

• Simics, Ghidra emulator
  • register level fidelity도 갖는다. (sub-instruction execution)
  • 조사한 emulator 중 가장 less automation - emulator를 즉시 사용할 수 있어서 interaction은 적은 편이지만

 

5.3 Basic Block Level Execution Fidelity

• QEMU, Muench2018, angr, Panda, HALucinator, $P^2IM$, Pretender
• QEMU는 execution fidelity 측면에서는 basic block execution fidelity data fidelity 측면에서는 Internal Memory fidelity (RAM fidelity)이다.
• Muench2018, angr, Panda, HALucinator는 HITL 대신 QEMU를 base emulator로 사용하기 때문에 동일하게 basic block execution fidelity와 RAM fidelity를 갖는다.
• P^2IM의 경우 random fuzzing을 하기 때문에 data 측면에서는 blackbox fidelity도 안 된다.
• Pretender의 경우, machine learning을 사용해서 peripheral 소프트웨어 대체 모듈을 제공하기 때문에 data fidelity는 낮지만 internal memory fidelity 정확도가 있다.
• Muench2018, PANDA의 경우, tracking/recording 기능 제공하는데 QEMU base emulator를 사용하기 때문에 basic block fidelity와 Internal memory/register fidelity를 갖는다.
• angr의 경우 QEMU를 concolic과 concrete execution에 사용하기 때문에 QEMU base와 동일한 fidelity를 갖는다.
• Avatar2의 경우 분석가가 어떤걸 프로그램 하느냐에 따라 다르지만, default 툴(QEMU, angr, PANDA, HALucinator)를 Avatar2 프레임워크에서 실행하기 쉽기 때문에 default 툴과 묶어서 fidelity를 나타냈다.

 

5.4 Module Level Execution Fidelity

• Firmadyne, CostinFA
  • 둘다 QEMU를 base emulator로 쓰지만, 펌웨어에서 파일시스템만 추출하고 자체 커널에서 코드를 돌리기 때문에 execution fidelity와 data fidelity가 낮다.
  • high automation

 

 

6. QUESTIONS AND CHALLENGES

펌웨어 리호스팅 시 직면할 수 있는 문제들과, 문제를 해결하기 위해 사용할 수 있는 기술 및 툴을 설명한다.

 

6.1 Questions of Purpose and Value

각 emulator는 펌웨어 리호스팅 전 필요한 준비물이 있다. precondition의 경우 섹션 7에서 다룬다.

펌웨어 리호스팅 전, 분석가는 왜 시스템을 에뮬레이트하는가에 대해 생각해야 한다. 취약점을 찾기 위한다면 fidelity level에 따라 찾을 수 있는 취약점이 다르다.

따라서 시스템 리호스팅 전, emulation 수행 시 비용과 돈을 추정해야 한다.

 

6.2 Key Research Questions

연구에서 핵심을 이해하기 위해서는 emulation으로 어떤걸 해결하고 싶은지 알아야 한다.

emulation의 속도를 높이는 것에 대한 핵심 연구는 모든 종류의 임베디드 시스템(GPES, SPES, BMES)에 해당하고 섹션 7,8,9에서 소개하는 문제를 해결할 방법을 포함한다.

 

6.3 Challenges

survey 연구에서 펌웨어 리호스팅 시 직면한 문제들을 3가지로 분류하여 설명한다.

문제 분류

1. Pre-Emulation
   • emulation 실행을 위한 pre-requisites 문제와 emulator 실행 가능하게 하기 위한 해결 방법
   • 문제: 펌웨어 획득, 펌웨어 unpack, configure emulator 등
2. Emulation
   • Emulation 설치
   • emulator 실행
3. Post Emulation
   • 실행 분석
   • 실행 유효성 확인

테이블 내 표시

• check mark - 해당 문제가 있음
• dash - emulator 내 자체 기술로 문제 우회 가능
• empty - 문제 없음

 

 

7. PRE-EMULATION

emulation을 하기 위해 필요한 정보는 emulation 기술에 따라 다양할 수 있는데, 일반적으로 펌웨어 획득, memory layout, ISA(instruction set architecture), processor 정보, 바이너리 분석, 펌웨어 디스어셈블리, 펌웨어 분석는 포함한다.

Pre-emulation은 Table 1에 정리되어있다.

binwalk

• Pre-emulation에 필요한 정보를 얻는데 사용하는 툴
• 펌웨어 이미지에서 내용을 추출하는데 가장 많이 사용된다.
• 제공 기능: ISA 확인, blob에서 파일 추출, string 탐색, signature(ex. 암호화 포맷), capstone을 사용한 디스어셈블, entropy 계산, binary diffing

 

7.1 Obtaining Firmware

펌웨어 획득방법

• vendor 웹사이트
• 3rd party 사이트(Github 등)
• 개발 보드 내 예시 펌웨어

 

펌웨어 획득 시 어려움

• 펌웨어 다운로드가 항상 가능한 것은 아니다.
• 펌웨어 다운로드 해도 추출이 힘든 embedded proprietary file 포맷(특정 회사 등에서만 쓸 수 있는 파일 포맷)일 수도 있다.
  • 파일이 압축되거나 펌웨어 저장 시 여러 아키텍처 파일을 가지고 있어서 boot load 과정에서 하드웨어 단에서 펌웨어 컴파일이 이루어져야 할 수 있다. → 이 embedded unpacking 문제의 경우, network capture 도구를 실제 하드웨어에 연결한 후, 펌웨어 업데이트 시 network traffic을 포착해서 해결할 수도 있다. 펌웨어는 캡처된 packet 페이로드에서 추출 가능하다.
• BMES나 SPES 같은 시스템에서는 펌웨어가 OS와 결합되어있을 수 있다.
• GPES 같은 경우 펌웨어가 유저 레벨에서만 다운로드 가능한데 full emulation을 위해 OS kernel을 얻으려면 별도로 얻어야 한다.

 

하드웨어에서 펌웨어 추출

• UART 인터페이스, UART 포트, debug 포트(JTAG), USB 포트를 사용해서 펌웨어 덤프를 한다.
• bootloader에서 firmware update protocol을 리버싱한 후 flash memory의 read 명령어 사용해서 획득한다.
• 포트가 lock 또는 secured이면, 메모리를 회로 보드에서 제거하고 다른 시스템에 연결해서 펌웨어를 덤프 뜬다. (메모리 제거 시 하드웨어 손상이 있을 수 있다.)

 

survey 도구 펌웨어 획득

• Firmadyne, CostinFA: vendor 사이트 (획득 O)
• P2IM, angr, Pretender: Github (3rd party 사이트) (획득 O)
• HALucinator, Pretender: 실제 임베디드 보드의 개발 예제 펌웨어 사용 (획득 O)
• Simics, QEMU, Ghidra: base emulator이고 학술 논문이 아니라 어떻게 펌웨어 획득하는지 명시 X (획득 X)
• Panda, Muench2018, SURROGATES, PROSPECT: 어떻게 펌웨어 획득하는지 명시 X (획득 X)

 

7.2 Instruction Set Architecture

• emulator가 펌웨어를 disassemble하기 위해 Instruction Set Architecture를 알아야 한다.

ISA 확인 방법

1) datasheet

• ISA는 에뮬레이트하는 프로세서의 datasheet에서 정보를 얻을 수 있다.

2) static analysis

• datasheet 없거나 하드웨어 정보 없을 경우
• 어떤 파일 포맷인지, 펌웨어 내 시그니처 정보(암호화, 압축 등), 바이너리 내 문자열 분석(ISA 유추 위해)

3) binwalk 사용

• capstone disassembler 사용하여 바이너리가 어떤 ISA인지 판별한다.

4) machine learning

• ISA와 endianness를 분류하는데 머신러닝을 사용하는 기술이 있다.
• binary similarity detection 사용
• 하지만 정확도를 높이려면 학습하는데 큰 dataset이 필요하고 training data에서만 정확도가 높다.

5) 펌웨어 내 시그니처, 문자열 정보 확인

• 펌웨어 내 시그니처를 확인하거나 문자열(압축, 시그니처, copyrights 등)

6) brute force decompilation

• 모든 아키텍처 대상으로 디컴파일 해보고 일일이 확인하는 것

 

survey 도구의 ISA 확인

• Firmadyne, CostinFA: binwalk와 추출 도구 사용하여 ISA 확인하고 파일시스템 추출
• Ghidra: ISA 확인 가능한 script 사용
• angr: boyscout 도구 사용해서 아키텍처와 펌웨어 endian 확인
• 다른 도구들도 ISA 확인됨

 

7.3 Determine Base Address

펌웨어를 emulator에서 실행하기 위해서는 주소를 로드해야 한다.

 

base address 획득 방법

1) 하드웨어 datasheet

2) linker script

• 소스나 컴파일 툴 가능한 경우

3) base address 찾기 위한 바이너리 분석 기술 사용

• 문자열과 LDR instruction 사용해서 이미지 기반의 펌웨어에서 offset을 비교 및 매칭해본다.
• 파일 내 문자열 리스트와 dword 리스트를 리스팅해서 가능한 가장 큰 차이를 구한다. 구한 offset을 빼서 image base address를 구한다.

4) binary jump table 활용

• jump table 활용해서 jump table 위치와 indirect jump 명령어의 메모리 접근 패턴을 분석한다.
• jump table에는 완전한 코드 주소가 있어서 유용
• jump table을 찾고, jump table에서 jump target을 읽는 메모리 위치나 디스어셈블리 구문에서 모든 indirect jump를 분석한다.

5) brute force guessing

 

survey 도구의 base address 획득

• angr: girlscout (analysis script) 사용 - 함수나 통계적 분석으로 가장 base address 가능성이 있는 주소를 찾는다.
• Firmadyne, CostinFA: ISA 확인 후 펌웨어에서 파일시스템 추출하고 나면, 파일시스템은 QEMU의 custom kernel로 사용된다. 자체 kernel을 사용하기 때문에 base address를 구하지 않아도 되지만, execution fidelity를 낮춘다. (원래 kernel을 사용하지 않기 때문)
• 다른 도구들: 다른 분석가들이 구한 base address 사용

 

7.4 Finding Entry Point

어디에서 실행을 시작해야 하는지 알수 있는 entry point 정보가 있어야 한다.

entry point 정보 얻는 방법

1) function call graph 기술

• angr, Ghidra, IDA: script 사용
• binary를 스캔해서 function prologue, function return 찾는다. 함수 정보에서 function call graph를 생성하고 분석한다.
• call graph에서 약하게 연결된 root node가 잠재적인 entry point로 생각할 수 있다.
• function call graph 생성과 분석에는 ISA가 필요하다.
• call graph 기술에서 여러 entry point가 리턴될 수 있다.
• 펌웨어는 여러 유효한 entry point를 가질 수 있다.

2) 하드웨어 정보 이용한 기술

• HALucinator: ARM Cortex-M 기기를 지원하는데, Cortex-M 아키텍처는 reset 시 Program counter 초기값을 0x4 주소에 저장한다. 이것으로 0x4 주소를 보는 것으로 HALucinator는 entry point를 찾는다.

3) 하드웨어 datasheet

• 하드웨어를 알고 있으면, datasheet에서 시스템이 실행을 시작하는 정보를 제공하기도 해서 datasheet을 참고하면 좋다.

4) function matching 기술

• OS나 compilter toolchain 알고있으면 entry point 함수((_start, _init 등)가 명시되어있어서 function matching 기술을 통해 entry point를 찾을 수 있다.
• VxHunter - VxWorks OS와 compiler toolchain 사용하는 펌웨어에서 사용 가능

kernel을 교체하는 CostinFA, Firmadyne은 entry point 찾는 과정을 생략할 수 있다. (자체 kernel을 사용해서 entry point를 알 수 있다.)

 

7.5 Determine Memory Layout

processor 내 RAM, Flash, MMIO 주소를 설정한다.

memory layout 확인 방법

1) datasheet

• 일반적으로 datasheet에서 알 수 있다.

2) ARM 시스템 CMSIS-SVD 파일

• memory layout 알 수 있다.
• Ghidra, IDA(리버싱 도구)나 자동화 분석에서 memory layout 업데이트하는데 사용된다.

3) EDC 파일

4) hwconf 파일

5) 기기의 물리적 요소 검토

• 마킹이나 제조사 출력 부분으로 datasheet 식별할 부분 있을 수 있다.

6) trial and error

 

7.6 Identify Processor and/or Board Support Package (BSP)

• processor 알아내는게 필요없는 경우도 있다.
  • QEMU: ISA level 기능만으로 동작한다.
  • cycle level emulation: gen5 - 프로세서마다 동일한 ISA instruction도 다르게 구현되어있다.

 

processor 확인 방법

1) 하드웨어 아는 경우

• 프로세스에 라벨이 붙어있어서 그걸로 확인 가능하다.

2) 메모리와 instruction이 교류하는 방법 분석

• 하드웨어를 알 수 없는 경우, 메모리와 instruction의 상호작용 분석해서 processor 후보에서 찾아낸다.

3) vendor를 아는 경우

• 다른 리버스 펌웨어에서 기존 정보를 활용하는 프로젝트 사용

4) brute force

• brute force script 사용해서 모든 가능한 processor를 base emulator에 테스트해본다.

QEMU를 base emulator로 사용하는 도구의 경우 processor를 알아내지 않아도 된다.

 

7.7 Disassembly, Initial Analysis, and CFG Recovery

Pre-emulation에서 진행하는 이유

디스어셈블, 초기 분석, CFG 복원은 Pre-emulation 시에만 해결해야 할 문제는 아니지만, 해당 문제들을 pre-emulation 과정에서 올바른지 입증하면 emulation 단계에서 시간을 줄이고 더 편할 수 있다. 예를 들면, 여러 entry point가 있다면 사전에 검증하고 입증하는 것이 bootloader 리호스팅 시 시간을 절약할 수 있다.

 

CFG(Control Flow Graph) 복원

하드웨어가 알려진 것과 같은 펌웨어가 뭘 하는지 아는 경우, GFG 분석으로 (이전 과정에서 구한) base address, ISA, entry point가 올바른지 알 수 있다. CFG가 복원되면, 디스어셈블러와 디컴파일러 성능도 얼마나 좋은지 알 수 있다. 이는 얼마나 emulation 실행이 잘 될지 또는 emulation fidelity가 어떻게 될지 생각해볼 수 있다.

emulation 도구들의 디스어셈블리 구현

angr: capstone을 디스어셈블러로 사용

QEMU, Ghidra: C/C++을 디스어셈블리 구현에 사용

다른 emulation 도구들: base emulator를 사용하기 때문에 이 base emulator의 디스어셈블리 구현을 사용

CFG 복원의 어려움

제어 흐름이 메인 프로세서를 벗어나 GPU나 DSP 같은 co-프로세서 칩으로 간다면, co-프로세서에서는 CFG 복원이 거의 불가능하다. 제어 흐름이 에뮬레이트되는 프로세서를 벗어나면 emulation의 fidelity는 리호스팅 부분으로 제한되지만, 대부분의 경우 emulation에서 제한하는 요소가 아니다.

disassembly, analysis

펌웨어의 제어 로직을 알 수 없는 경우 사용할 수 있는 방법이다.

디스어셈블은 ISA와 프로세서 유효성을 아는데 도움이 된다. 디스어셈블을 하고 결과를 반복해서 분석하면, 분석 결과에 따라 디스어셈블에 대한 입력과 파라미터를 변경하면서 진행할 수 있다. 여러 펌웨어를 동일한 시스템에서 동시에 분석하고 분석 결과를 종합하여 결과를 굳힐 수 있다.

 

 

8. EMULATION

펌웨어의 프로세서, memory layout, entry point, base address 정보를 알아낸 후, base emulator에서 지원 여부를 확인해야 한다. base emulator에서 펌웨어가 사용하는 프로세서를 지원하지 않으면, base emulator에 새로운 사양을 추가해야 한다. QEMU, Ghidra는 새로운 프로세서를 추가하는 가이드를 제공한다. 이 과정이 해결되어야 base emulator를 사용할 수 있다.

pre-emulation에서의 문제 해결이 선행되어야 펌웨어를 emulator에 로드하고 실행할 수 있다. 실행에서 추가로 해결해야 할 문제들을 setup과 실행 단계로 나눴다. setup 단계는 emulator가 멈추거나 중단될 때 정적으로 해결되는 것이고, 실행 문제는 emulator가 실행 중일 때에 해당한다.

 

8.1 Emulation Setup

emulation 범위(칩인지, microcontroller인지 등)에 따라 emulation 시 직면하는 문제가 다를 수 있다.

8.1.1 Peripherals, External Hardware, and Modeling

주변장치 처리

주변장치와 vendor가 다양하기 때문에 base emulator에서 구현되어있지 않는 주변장치가 있을 수 있다.

memory map을 알고 있으면 주변장치가 어디에 위치하는지 알 수 있다. 동적 분석이나 실행으로 어떤 주변장치가 사용되는지에 대한 정보를 얻을 수 있다.

동적 실행 중, emulator에서 매핑되지 않은 주변장치 접근으로 exception이나 crash가 발생하면 대부분 alias 문제이다. 대부분 alias 문제의 경우 동적 실행 시 주소들을 트래킹 하면서 emulator에 대한 주변장치 모델 정보를 업데이트 해줘야 한다.

HITL emulation

실제 하드웨어를 이용해서 외부 장치를 에뮬레이트 하는 방식으로 주변장치를 처리할 수도 있고(HITL), 펌웨어에서 주변장치에 대한 통신을 우회하도록 구현할 수 있다. HITL emulation의 경우 실행과 메모리에 가장 높은 fidelity를 갖는다. 그러나 emulation 병행 처리가 불가능하고 하드웨어와 emulator 사이 상태 동기화가 어렵다.

abstraction 접근 방식

• 장점: 높은 fidelity를 제공한다.
• 단점: abstraction을 제공하려면 주변장치에 대한 이해가 필요하고 manual 노력이 필요
• 관련 emulator: QEMU, HALucinator, PANDA, Muench2018

fuzzer 방식

• 장점: 기기에 대한 지식 필요 없다. 취약점이나 버그 찾는데 유용
• 단점: fidelity가 좋지 않다.
• 관련 emulator: P2IM → fuzzer 사용, 취약점들 찾은 사례 있음

machine learning 방식

• 장점: 버그 찾는 등 유용한 통찰력을 준다.
• 단점: 오늘날 machine learning 접근 방식을 사용한 도구들은 단순한 주변장치(serial/UART port)에 대한 검증만 보여준다. 그 외의 하드웨어 주변장치에 대해서도 동작할지는 불명확하다.
• 관련 emulator: Pretender

기타 도구

• Firmadyne, CostinFA: 주변장치가 kernel의 일부분이어야 하고, 그렇지 않으면 emulator에서 크래시 발생
• SURROGATES, PROSPECT: 실제 하드웨어로 주변장치 접근, emulation의 상태 동기화와 딜레이 문제 존재

 

8.1.2 Memory Interactions and Setup

대부분 emulator에서 데이터, 코드, 주변장치가 어디에 위치하는지 명시할 수 있다. 이렇게 emulation에 제한을 두면 올바르지 않은 코드 실행에 대해 크래시를 내거나 알려줄 수 있다. 이 emulation 세팅은 emulator config에 사용할 수 있다. 세팅 시 base address entry point, memory layout, memory 크기와 같은 정보가 필요하다. (pre-emulation 단계에서 설명함)

도구에 메모리 지원이 없으면, base emulator의 기능을 사용하거나 다른 소프트웨어를 사용할 수 있다.

survey 도구

• SURROGATES, PROSPECT의 경우 실제 하드웨어를 사용한다.
• HALucinator, Ghidra, PANDA, PROSPECT, Muench2018는 built-in memory handler를 사용하거나 모듈을 제공한다.
• Firmadyne, CostinFA: 메모리 처리는 바로 kernel로 가서 에러 발생 시 펌웨어 버그가 아닌 kernel에서 해결해야 할 문제이다.

 

8.1.3 Configuring Hardware

HITL

HITL(Hardware In The Loop) 방법을 사용한 emulation에서 하드웨어를 세팅하는 일은 어렵다. 사용할 수 있도록 초기화를 해야 하고 loop에 가져와야 한다. 이를 위해서 사용자는 어떻게 하드웨어와 통신할지 emulator에 명시해야 한다. 딜레이가 있거나 속도를 높이려면 특화된 하드웨어를 추가로 사용해야 한다.

Aveksha는 임베디드 무선 노드에 적합함. 실행 추적

Avatar2

하드웨어 config에 유용한 도구로 HITL 방식으로 emulation 시 사용 가능

 

8.1.4 Missing Code

CFG 복원 시 누락된 코드가 있을 수 있다.

누락된 코드 발생 원인

• 잘못된 entry point를 명시
• 기능이 패치되어 코드에 쓰여졌을 수 있음 (bootloader 같은)
• 펌웨어가 완전하지 않음 (펌웨어 업데이트되었거나 언패킹이 완전히 되지 않음)
• ROM chip에 코드가 있는 경우
• 펌웨어가 실제 하드웨어 기기에서 벗어난 경우

누락된 코드가 있는 경우 문제점

emulator가 누락된 코드를 실행하려고 하면, 시스템은 exception이나 크래시를 낸다.

누락된 코드 해결 방법

• 코드를 대체하거나 해당 코드를 스킵하도록 한다.
• HALucinator
  • 함수를 가로채는 기술을 사용해서 코드를 교체해서 직접 쓴 모델에서 함수의 기능을 하도록 한다.
• 다른 survey 도구
  • 직접 해결해야 함

 

8.1.5 Function Identification and Labeling

• emulation fidelity가 module이나 function level인 경우 필요 (필요하지 않는 경우도 있음)
• HAL(Hardware Abstraction Library) 호출 같은 특정 함수를 알아내서 해당 함수에 대한 abstraction을 제공하려고 할 때 필요

angr, Ghidra, HALucinator

• library matching 기술 사용 -> 함수 식별에 IDA FLIRT signature를 사용해서 매칭하려는 라이브러리를 로딩하고 HAL을 컴파일해서
• 다른 survey 도구 – 함수 식별이 필요 없거나 이 과정에서 문제가 없음

 

8.2 Emulation Execution

emulation execution의 어려움

• 서로 다른 fidelity에 따라 서로 다른 emulation 기술이 필요하다.

survey 도구들의 execution 위한 방법

• gem5: 명령어를 에뮬레이트할 때 프로세서에 따라 명령어를 디코드하고 CPU pipeline과 동일한 깊이를 사용
• Simics: instruction level fidelity, 명령어 디코드하고 각 명령어 실행마다 상태 업데이트
• QEMU: basic block fidelity, 호스트 명령어 실행 위해 QEMU의 Tiny Code Generator(TCG)를 사용하여 호스트 아키텍처의 basic block 명령어를 해석
• Ghidra Emulator: 명령어를 P-code로 변환 각 기계어를 최대 30 P-code 명령어로 해석한다.
• angr: VEX로 해석

base emulator가 있는 survey 도구들

• QEMU를 base emulator로 사용: angr, Avatar2, CostinFA, Firmadyne, HALucinator, P2IM, PANDA, Pretender, PROSPECT, SURROGATES, Muench2018
• angr - CLE 로더 사용해서 Avatar2 대상이 symbolic execution과 concrete execution을 결합한 angr_symbion을 통해 프레임워크에서 구체적으로 실행이 가능하게 한다.
• base emulator인 QEMU, Simics, Ghidra Emulator에서 문제를 어떻게 해결하는지 설명한다.

 

8.2.1 Register Allocation

• 각 아키텍처마다 서로 다른 레지스터와 컨벤션을 가진다.
  • Program counter (PC) - 아키텍처가 다른 PC는 레지스터가 다르다. ARM에서는 R15, x86/x86_64/PowerPC는 PC, T1-MSP430은 R0이다.
• 고정된 호스트 메모리에 레지스터를 매핑하는건 QEMU, Simics, Ghidra emulator에서 할 수 있다.

 

8.2.2 Direct Block Chaining

• Block Chaining은 QEMU 관련
• QEMU는 전체 basic block을 해석하고 다음으로 실행할 코드 블록을 찾는데 시뮬레이트된 program counter를 사용한다. 실행 속도를 높이기 위해 블록들은 메모리에 캐싱되어 hash table에서 블록을 찾아 사용한다.
• 어떤 emulator는 다음 실행할 블록의 명령어를 바로 연결하기 위해 블록 끝에 명령어를 추가한다.

 

8.2.3 Self-modifying code and translated code invalidation

• 스스로 변형하는 코드를 해석된 코드와 읽기 전용으로 대응하는 호스트 페이지 추적을 보유해서 처리하기도 한다. 코드에 쓰기가 수행되면, 해석한 코드를 무효화해서 코드에 다시 쓸 수 있도록 한다.
• MMU 소프트웨어 사용: 데이터만 변경될 경우 코드를 무효화하지 않는다.
• Ghidra Emulator: 쓰기에 권한이 필요하고 코드는 읽기 전용으로, 코드에 쓰기가 발생하면 emulator는 에러 처리하고 종료한다.
• Simics: self-modifying 코드 지원 여부나 처리 여부가 분명하지 않다.

 

8.2.4 Non-Volatile Memory (NVM)

• NVM은 나온지 얼마 되지 않아서 대부분 emulator에서 지원이 적다.
• 어떤 벤더는 실제 하드웨어 없이 PMEM 애플리케이션을 빌드해서 에뮬레이트된 환경을 구성하는 방법을 제공하기도 한다.
• NVM, PMEM 문제를 해결하기 위해 메모리가 어떻게 핸들러를 제공하는지 알아야 한다.
• 서로 다른 PMEM 하드웨어 벤더에서 제공하는 명령어는 구현에 어려움이 있다.
• QEMU, Simics, Ghidra Emulator: 호스트 시스템에서 메모리를 할당하고 사용자가 하드웨어와 통신하기 위해 모델링한 것으로 NVM을 처리한다.
• QEMU는 NVRAM 도구 제공

 

8.2.5 Direct Memory Accesses (DMA)

co-processor 중에서 DMA를 초기화나 주변장치가 메모리에 바로 쓰는데 사용할 수 있다.

DMA 처리 방법

• HITL emulation을 사용해서 co-processor를 에뮬레이트한다.
• DMA 관련 함수 호출에서 함수를 가로채거나 함수 기능을 대체한다.

survey 도구에서 DMA 처리 방법

• QEMU: Avatar2 확장
• SURROGATES: 하드웨어 사용해서 주변기기가 실제 하드웨어에 접근하도록 처리
• Simics: HITL 방식 사용
• HALucinator: HAL 호출을 가로채서 DMA 기능을 수행하도록 한다.

 

8.2.6 Handling Interrupts

emulator에서 interrupt 처리 방법

• interrupt에 대한 각 명령어나 해석된 블록 체크
• user trigger interrupt, interrupt 핸들러 호출, 자동 호출 패치

survey 도구에서 interrupt 처리 방법

• QEMU: 해석된 블록을 체크하지 않고 유저가 비동기적으로 특정 함수를 호출해서 어떤 인터럽트인지 명시한다. 그 시점에서 함수는 현재 실행 중인 블록의 체인을 리셋하고 CPU emulation의 메인 루프로 가서 하드웨어 인터럽트가 있는지 확인한다. 유저 비동기적 인터럽트를 사용하기 때문에 emulator는 훨씬 빨라지고 오버헤드가 적다.
• Simics: 각 명령어 사이에서 인터럽트를 허용하는 반면 속도 비용 측면에서 더 높은 실행 fidelity를 허용한다.
• Ghidra Emulator: sub-instruction 레벨에서 서로 다른 P-code 실행 사이 인터럽트를 허용

 

8.2.7 Multi-Threading

멀티 스레드 지원 방법

• 멀티 스레드를 사용하는 애플리케이션은 잠금이나 세마포어를 사용할 수 있는데, 이는 emulator가 멀티 스레드가 동시에 실행되도록 해야 한다.
• 여러 애플리케이션이 실행되는걸 허용한다면, 스케줄러가 있거나 선점형 스케줄링 또는 협조적 스케줄링을 사용해야 한다.
  • 협조적 스케줄링(co-operative scheduling) - emulator가 멀티 스레드가 실행되는걸 허용하면 되고 스레드는 스스로를 관리한다.
  • 선점 스케줄링(pre-emptive scheduling) - 인터럽트를 트리거해서 스케줄러가 스레드 간 문맥 교환이 이루어지도록 해야 한다.

survey 도구에서 멀티 스레드 지원 방법

• Simics: instruction level fidelity를 가지기 때문에 멀티 스레드 펌웨어나 시스템을 디버깅 시 유용하다. insturction 사이에서 스레드 상호작용 가능
• QEMU: 멀티 스레드 사용하는 시스템을 지원하는데 스레드가 basic block의 끝에서만 상호작용할 수 있어 잘못된 정확성을 가져올 수 있다. 이 한계를 각 명령어마다 breakpoint를 설정하는걸로 해결하지만 시스템이 느려져서 이 emulation은 유용하지 않게 된다.
• Ghidra Emulator: basic block 중간에서도 instruction 간 스레드 상호작용 가능

 

8.2.8 Debugging

디버깅 필요성

• emulation 중 에러가 발생할 때 실제 펌웨어나 시스템에서 발생한 에러인지, emulator에서의 에러나 버그인지 알 수 없을 때 디버깅을 사용할 수 있다.

디버깅 기능

• GNU GDB: Avatar2, angr, Ghidra, QEMU 등
• serial port emulating
• “print” 하는 방식: 메시지를 출력하도록 함

survey 도구에서 debugging

• QEMU: 로깅, breakpoint 등 디버깅 기능을 GDB에서 사용하는 것처럼 제공
• Ghidra Emulator: GDB bridge를 연결해서 디버깅 가능
• Simics: forward와 reverse 방향의 디버깅 지원

 

8.2.9 Timing Constraints

• SURROGATES: 메모리나 주변장치가 실제 기기에 접근하도록 하는 특별한 하드웨어를 사용하는데, emulation을 병렬화 해야 하면 HITL 방식은 불가능하다.
• HITL 환경에서는 사용자가 스스로 timing을 구현해야 한다.
• Simics: emulation에 필요한 cycle 수를 제공
• QEMU: Simics보다 더 빠르지만 실행 시간을 알 수 없어서 timing 기능 사용 시 부적합할 수 있다.

 

 

9. POST EMULATION

9.1 Finding Vulnerabilities

취약점 찾는 기술들

• fuzzing
• data flow analysis
• taint analysis
• control flow analysis
• record and replay execution analysis
• dynamic and symbolic execution
• machine learning → ML으로 펌웨어 취약점을 찾고 취약한 기기를 찾기 위해 펌웨어를 분류

 

9.2 Verification

emulator가 의도한 대로 동작하는지 검증이 필요하다.

SoC 칩 기능 검증은 연구가 많이 이루어졌지만 에뮬레이트된 시스템이나 리호스팅된 펌웨어 검증에 대한 연구 자료는 부족하다. 현재 리호스팅된 펌웨어를 검증하는 도구는 존재하지 않고, emulator를 테스트할 표준 벤치마크나 검증 기술이 없다.

 

9.3 Analysis

emulation 중에 펌웨어는 버그를 위해 분석하거나 테스트되어야 한다. emulator는 실제 하드웨어의 펌웨어나 바이너리 강화에 더 도움이 되도록 분석할 수 있다.

 

 

10. CONSIDERATIONS

각 도구를 base emulator로 사용하거나 기술들을 사용하려고 선택 시 도구마다 장단점이 있다. 도구 선택 시 하드웨어 지원, fidelity, 성능, 디버깅 지원 및 가능 여부, 사용성 면에서 고려해야 한다.

Hardware support

새로운 하드웨어나 프로세서를 간단하고 쉽게 추가하려면 가장 먼저 고려할 점은 에뮬레이트하고 싶은 하드웨어 자체를 도구에서 사용할 수 있도록 하는 것이다.

Emulator fidelity

만약 symbolic execution이 필요하면 angr를 사용하는게 가장 좋은데 symbolic execution이 안 되면 사용자는 Figure 1을 참고하여 필요한 fidelity에 따라 도구를 선택할 수 있다.

performance

• 이전에 emulation이 잘 사용되지 않았던 이유는 오버헤드와 느린 성능 때문이었는데, 소프트웨어와 하드웨어가 더 발전하면서 성능 문제를 극복할 수 있게 되었다.
• 에뮬레이터 사용 시 성능이 문제가 되면 부분적으로 에뮬레이트하거나 추가 하드웨어를 사용하는 대안이 있다.
• Ghidra Emulator: 사용자가 특정 입력을 줘서 특정 함수에서 emulation이 실행되도록 하여 부분 emulation 지원
• SURROGATES: 메모리와 통신 가능한 특별한 하드웨어 지원한다.
• HALucinator: YAML 파일에서 특정 주소에 breakpoint를 설정 가능

debugging support

사용자가 펌웨어에 대한 지식이 적은채로 펌웨어 리호스팅을 하면, 디버깅 지원이 더 필요하게 된다.

emulation의 장점은 펌웨어 리호스팅 시 각 지점에 대한 메모리를 알 수 있다는 것이다. 메모리를 알기 위해서는 디버깅 도구나 로깅을 사용해야 한다.

• QEMU, Ghidra: GDB 사용해서 emulation 시 breakpoint 사용
• Simics: 빌트인 디버깅은 breakpoint 지원

디버깅 시 많은 breakpoint나 추적은 emulator를 느리게 해서 성능에 영향을 미친다.

성능과 디버깅 지원 모두 활발히 연구가 이루어지고 있다.

Usability

탐사 및 제어나 도구 자동화 같은 사용성을 의미한다. GDB를 사용하는 도구는 더 확장된 제어를 할 수 있을 것이고, 퍼징이나 랜덤화를 사용하는 도구는 제어를 적게 할 수 있지만 어떤 사용자에게는 유용하지 않을 수 있다.

조사한 모든 도구의 경우, base emulator에서 디버깅은 빌트인이거나 플러그인으로 제공하고 있다.

 

 

11. SUMMARY AND CONCLUSION

emulation 기술들을 비교하고 고려사항을 제안했다. emulation 도구가 제공하는 기술, 어떤 시스템에서 도구가 동작하는지, exploration, 도구의 목적, 분류 기술, fidelity를 기준으로 도구들을 비교하였다.

기술을 비교하며 angr, Avatar2, CostinFA, Firmadyne, Ghidra, HALucinator, P2IM, PANDA, Pretender, PROSPECT, QEMU, Simics, SURROGATES, Meunch2018를 포함한 조사한 도구를 분류하였다. emulation이나 펌웨어 리호스팅 시 직면한 문제들이 다른 것으로 도구의 기술이나 도구 간 차이를 설명했다.

새롭게 펌웨어 리호스팅이나 emulation 연구를 진행하는 연구자들에게 아웃라인을 제공했다. 이 논문에서는 pre-emulation, emulation, post-emulation 시 문제들을 해결하기 위한 연구들과 도구가 필요함을 강조했다. 또한 도구를 평가하는 분류와 기준을 제공했다.

 

---

Review

• 펌웨어 리호스팅 시 어떤게 필요한지, 필요한 것을 해결할 수 없다면 대안이 무엇인지 Pre-emulation, emulation, post-emulation 단계에서 구체적인 정보를 제공하여 펌웨어 리호스팅을 처음 해보는 연구자들에게 유용할 것이다.
• 각 조사한 도구 별로 어떻게 base address, ISA 등을 얻는지, 펌웨어를 어떻게 획득하는지 등을 알 수 있어서 사용하는 펌웨어 리호스팅 도구 사용 시 유용하게 참고할 수 있을 것 같다.
• 도구 별로 fidelity를 정리하여 연구자가 어떤 취약점을 찾고자 하는지, 어떤 분석을 진행하는지에 따라 참고하여 펌웨어 리호스팅 도구를 선택할 수 있을 것이다.