Avatar 2 : A Multi-target Orchestration Platform Marius Muench, - - PowerPoint PPT Presentation

▶
avatar 2 a multi target orchestration platform
SMART_READER_LITE
LIVE PREVIEW

Avatar 2 : A Multi-target Orchestration Platform Marius Muench, - - PowerPoint PPT Presentation

Sep 17, 2022 2.53k likes •2.94k views

Avatar 2 : A Multi-target Orchestration Platform Marius Muench, Dario Nisi, Aur elien Francillon & Davide Balzarotti Workshop on Binary Analysis Research 2018 Introduction Dynamic B inaryA nalysis 1 Motivation Having a huge

slide-1
SLIDE 1

Avatar2: A Multi-target Orchestration Platform

Marius Muench, Dario Nisi, Aur´ elien Francillon & Davide Balzarotti Workshop on Binary Analysis Research 2018

slide-2
SLIDE 2

Introduction

Dynamic B inaryA nalysis

1

slide-3
SLIDE 3

Motivation

  • Having a huge variety of tools is awesome
  • But analysis state is mostly local to the single tools
  • A lot of effort to integrate specific tools into other

2

slide-4
SLIDE 4

Being able to interconnect debuggers, emulators and analysis frameworks greatly benefits dynamic binary analysis

2

slide-5
SLIDE 5

A link to the past

2014: The avatar framework:

  • Connects S2E and OpenOCD/GDB
  • Targets ARM firmware
  • Partial emulation together with real hardware

Zaddach, Jonas, et al. ”AVATAR: A Framework to Support Dynamic Security Analysis

  • f Embedded Systems’ Firmwares.” NDSS 2014.

3

slide-6
SLIDE 6

A link to the past

2014: The avatar framework:

  • Connects S2E and OpenOCD/GDB
  • Targets ARM firmware
  • Partial emulation together with real hardware
  • Tightly coupled to S2E and OpenOCD/GDB

Zaddach, Jonas, et al. ”AVATAR: A Framework to Support Dynamic Security Analysis

  • f Embedded Systems’ Firmwares.” NDSS 2014.

3

slide-7
SLIDE 7

Imagine a tool that ...

4

slide-8
SLIDE 8

Imagine a tool that ...

4

slide-9
SLIDE 9

Imagine a tool that ...

4

slide-10
SLIDE 10

Imagine a tool that ...

4

slide-11
SLIDE 11

Imagine a tool that ...

4

slide-12
SLIDE 12

Imagine a tool that ...

4

slide-13
SLIDE 13

Imagine a tool that ...

4

slide-14
SLIDE 14

Imagine a tool that ...

4

slide-15
SLIDE 15

Imagine a tool that ...

4

slide-16
SLIDE 16

One framework to orchestrate them all?

  • Capable of interconnecting a variety of tools
  • Expose a consistent API to the analyst
  • Easy scriptability
  • Operate in an highly asynchronous environment

Careful crafted architecture required

5

slide-17
SLIDE 17

Avatar2- The architecture

Avatar2 T arget0 Execution Protocol Memory Protocol Endpoint0 Register Protocol T argetn Execution Protocol Memory Protocol Endpointn Register Protocol

. . . . . . . . .

6

slide-18
SLIDE 18

Additional features

  • Architecture independent design
  • Internal memory layout representation
  • Legacy python support
  • Peripheral modeling
  • Plugin System
  • Assembler/Disassembler
  • Orchestrator
  • Instruction Forwarder

7

slide-19
SLIDE 19

Examples

Example I: Facilitating replication & reproduction Example II: Symbolic Execution & Complex Software Example III: Record & Replay for Firmware

8

slide-20
SLIDE 20

Example I - Replicating Harvey

  • Proof of concept implementation of HARVEY [1]
  • Malware for a COTS PLC
  • The plc utilizes multiple boards
  • Code injection via JTAG

[1] Garcia, Luis, et al. ”Hey, My Malware Knows Physics Attacking PLCs with Physical Model Aware Rootkit.” NDSS 2016. 9

slide-21
SLIDE 21

Figure 1: Harvey’s modifications to the GPIO-output ISR1

1Taken from [1]. Original title: ”Figure 5. Original GPIO-output update ISR assembly code compared to modified subroutine with branch to malicious code.”

10

slide-22
SLIDE 22

1 from avatar2 import Avatar, ARMV7M, OpenOCDTarget 2 3 output_hook = ’’’mov r5,0xfffffffd 4

mov r4, r5

5

mov r5, 0

6

b 0x2000233E’’’

7 8 avatar = Avatar(arch=ARMV7M) 9 avatar.load_plugin(’assembler’) 10 11 t = avatar.add_target(OpenOCDTarget, openocd_script=’harvey.cfg’, 12

gdb_executable=’arm-none-eabi-gdb’)

13 14 t.init() 15 t.set_breakpoint(0xd270) 16 t.cont() 17 t.wait() 18 19 t.inject_asm(’b 0x20002514’,addr=0x20002338) 20 t.inject_asm(output_hook,addr=0x20002514) 21 22 t.cont()

11

slide-23
SLIDE 23

Example I - Results

  • Implementation of PoC in approx. 30 lines of Python
  • All of this could –and has – been done without avatar2
  • Unified and centralized interface
  • Easy to exchange scripts
  • Modifications can easily be integrated

12

slide-24
SLIDE 24

Example II - Symbolic Execution of Firefox

  • Firefox with inserted bug
  • Executed concretely inside gdb until function of interest
  • Automated memory layout extraction from gdb
  • Transfer of layout into angr
  • Memory contents copied-on-read
  • Symbolic function arguments
  • Analysis of only one thread

13

slide-25
SLIDE 25

Example II - Results

  • Implementation in approx. 60 lines of Python
  • Execution statistics:
  • Approximatly 10 minutes of runtime2
  • 36 executed basic blocks
  • 21 uniquely accessed pages
  • Found the bug
  • angr alone was not able to find the bug
  • Could be achieved by tedious population of state without

avatar2

  • Demonstrates State Transfer and Orchestration capabilities

2Hardware: VM with four Intel Xeon E5-2650L cores and 16GB of RAM

14

slide-26
SLIDE 26

Example III - Recording Firmware Execution

  • Dynamic binary analysis of firmware often requires the device
  • PANDA [2] allows to record and replay execution
  • Allows exchange of executions for further analysis without the

device

[2] Whelan, Ryan J., et al. ”Repeatable Reverse Engineering with the Platform for Architecture-Neutral Dynamic Analysis.” MIT Lincoln Laboratory Lexington 2015. 15

slide-27
SLIDE 27

1 from avatar2 import

ARMV7M, Avatar, OpenOCDTarget, PandaTarget

2 3 avatar = Avatar(arch=ARMV7M) 4 avatar.load_plugin(’orchestrator’) 5 6 nucleo = avatar.add_target(OpenOCDTarget, [...]) 7 panda

= avatar.add_target(PandaTarget, [...])

8 9 rom = avatar.add_memory_range(0x08000000, 0x1000000, 10

file=firmware)

11 ram = avatar.add_memory_range(0x20000000, 0x14000) 12 mmio= avatar.add_memory_range(0x40000000, 0x1000000, 13

forwarded=True, forwarded_to=nucleo)

14 15 avatar.init_targets() 16 [...] 17 panda.begin_record(’panda_record’) 18 avatar.resume_orchestration(blocking=False) 19 [...] 20 avatar.stop_orchestration() 21 panda.end_record()

16

slide-28
SLIDE 28

Example III - Results

  • Implementation in approx. 30 lines of Python
  • Successful recording of firmware’s execution
  • Replayable without presence of hardware
  • Without avatar2, cumbersome implementation of peripherals

required

  • Demonstration of separation between execution and memory

17

slide-29
SLIDE 29

Discussion

  • So far, only five targets implemented
  • Achieving genericity is difficult
  • Overhead for implementing new targets varies
  • Unsolved challenges for analysis of embedded devices
  • Interrupts
  • Debug access

18

slide-30
SLIDE 30

Conclusion

  • Multi-target orchestration is not limited to firmware
  • We are just at the beginning ...
  • More tomorrow morning!
  • ”What You Corrupt Is Not What You Crash: Challenges in

Fuzzing Embedded Devices.”

  • Session 1A: IoT, Kon Tiki Ballroom, 12.20pm

19

slide-31
SLIDE 31

Artifacts?

  • The full framework is open source:

https://github.com/avatartwo/avatar2

  • Presented examples at:

https://github.com/avatartwo/bar18_avatar2

  • Pre-built vagrant box:

avatar/2bar18 avatar2

20

slide-32
SLIDE 32

Backup slide #1: Changes to QEMU

Avatar2 provides a costomized QEMU

  • All located in a single subfolder: hw/avatar
  • New board: Configurable Machine
  • Already present in the first avatar
  • Allows flexible configuration of emulated hardware
  • New peripheral: remote memory
  • Communicates with avatar2 via posix message queues
  • Utilizes custom remote-memory protocol

21

slide-33
SLIDE 33

Backup Slide #2: Event handling in avatar2

  • Targets are emitting events
  • Events are registered by protocols forwarded to the avatar2

core

  • Fast queue for execution state updates
  • Enables callbacks and inspection mechanisms

22