Processor-Peripheral Interface Modeling

P2IM

• Scalable and Hardware-independent Firmware Testing via Automatic Peripheral Interface Modeling(Usenix 2020)
• Processor-Peripheral Interface Modeling
• 펌웨어를 MCU의 펌웨어로 국한
  
  
  

 

 

 

 

[Open Challenges]

1. Hardware Dependence

하드웨어 의존은 퍼징하는데 delay를 만들고, 병렬처리를 하는데 한계가 존재.
즉, 병렬 퍼징이 힘들다.

2. Wide Range of Peripherals

최근에는 펌웨어의 에뮬레이션 기반 퍼징만 제안이 있어왔음.
그러나 에뮬레이팅된 MCU를 생성하는것은 비 실용적이고, 존재하는 에뮬레이터는 MCU를 지원하지 않음.
때문에 보통 퍼징이나 테스팅을 위해 에뮬레이터를 커스터마이징함.
이른 에러도 많고, MCU의 종류가 많아 현실적으로 힘든 부분이 존재.

3. Diverse OS & System Design

기존의 퍼저들을 펌웨어 퍼징에 적용하기 어렵다.
MCU는 일반적인 OS(Linux)가 아닌 MCU를 위해 설계된 OS를 사용.

4. Incompatible Fuzzing Interface

펌웨어의 모든 인풋은 다양한 종류의, 자신만의 convention을 가진 peripheral을 통해 들어옴.
그래서 일반 퍼저들의 인풋 인터페이스는 MCU 펌웨어에 부적절.

 

[Processor-Peripheral Interfaces]

• 펌웨어는 직접 off-chip에 접근할 수 없기 때문에 On-chip peripheral만 다룸.
• 레지스터와 인터럽트를 통한 peripheral I/O 인터페이스를 다룸.
• DMA를 통한 peripheral I/O 인터페이스는 제외.
  
  

[P2IM]

1. Abstract Model

- P2IM에 접근할때 펌웨어가 따르는 컨벤션이나 패턴들을 MCU Device 데이터 시트 또는 프로세서 Doc를 통해 수집.
- 이 단계는 전문가들에 의해 이루어지는 오프라인 수작업 단계(only manual step in P2IM).
- 일단 ARM Cortex-M 프로세서만 available.
- 다른 아키텍쳐를 위한 abstract model을 정의하는건 미리 정의된 템플릿이 있기때문에 많은 노력없이도 가능.
- 이 단계는 MCU 아키텍쳐별로 한번만 이루어지는 과정이고, 대부분의 MCU는 동일한 아키텍쳐(ARM Cortex-M)를 사용.
- first, peripheral 레지스터를 4개로 분류후, 각 레지스터별 엑세스 패턴과 엑세스 핸들링 방법을 제공.
    * Control Register(CR)
    * Status Register(SR)
    * Data Register(DR)
    * Control-Status Register(C&SR)
- second, peripheral을 대신해 에뮬레이터가 인터럽트할 방법을 정의.
    * ex) 인터럽트가 인풋이 준비되었다는 신호를 펌웨어에 보내면, ISR(Interrupt service routine)이 동작하고, 데이터 레지스터에 있는 인풋을 읽음
    * 인터럽트 전략은 간단한 방식인 Round-Robin.

2. Model Instantiation

- abstract model을 인스턴스화 하여 분석할 펌웨어를 완전한 모델로 생성하는 단계.
- firmware-specific한 정보를 자동으로 추론.
- deterministic하고 repeatable한 작업.
- 인스턴스화 된 모델은 펌웨어 특화된 정보를 포함.
    1. 식별된 memory mapped 레지스터, 메모리 위치, 타입
    2. 레지스터 타입별 엑세스 핸들링 전략.
    3. enabled 인터럽트 전략.
- peripheral config 관련정보는 불포함.

- peripheral을 에뮬리이팅 하지않은 에뮬레이터에서 펌웨어를 실행.
- 펌웨어가 Processor Peripheral Interface에 접근할때 계속적으로 모델을 인스턴스화 함.

 

[Implementation]

• QEMU + AFL
• AFL은 유저모드 에뮬레이션만 지원하는데, AFL을 QEMU의 full system 에뮬레이션 모드에 연결되도록 브릿지 해야함.
• TriforceAFL은 full system 에뮬레이션을 지원하기 때문에, TriforceAFL의 코드를 통해 AFL을 QEMU에 연결.
• 퍼저에 의해 생성된 인풋은 DR(Data Register)를 통해 펌웨어에 전달.
• QEMU를 통해 코드커버리지 정보를 수집후 퍼저에 전달.
  
  
  

[Unit Test on MCU Peripheral & OS]

• On-Chip에서 가장 popular한 8개의 Peripherals.
• OS/system libraries(NuttX, RIOT, and Arduino)
• SoCs (STM32 F103RB, NXP MK64FN1M0VLL12, and Atmel SAM3X8E)

 

[Real MCU Firmware Test]

드론 펌웨어 : MCU기반 Autopilot 컨트롤러. 센서, 라디오, 모터등을 조종하고, PID 제어기같은 컨트롤 알고리즘 구현.

• Quad-copter drone, Pluto drone
  
  
  

• ACC : 레지스터 분류 정확도
• SR : Status Register
• Time : 모델 인스턴스화 하는데 걸리는 시간

 

[Fuzzing]

• AFL 퍼저말고 다른 퍼저는 고려하지않음.
• Data Register를 통해 인풋을 펌웨어에 전달.
• memory error detector는 NDSS18 What you corrupt is not what you crash에서 소개한 segment tracking heuristic을 사용.

• 코드 커버리지 측면에서 수치적으로 여전히 낮게 보일수있음.
• dead code(사용하지 않는 라이브러리), 복잡한 path 조건에 최적화되지않은 AFL등의 이유를 원인으로 볼수있음.
• 그러나 input value 뿐만 아니라, input duration(얼마나 오래 인풋 값/신호가 지속되는지)이 펌웨어 실행에 영향을 줄 수 있음.
• MCU 펌웨어 퍼징에 대한 유일한 Challenge는 input duration으로 보고있음.