AVATAR: A Framework for Dynamic Security Analysis of Embedded - - PowerPoint PPT Presentation

▶
avatar a framework for dynamic security analysis of
SMART_READER_LITE
LIVE PREVIEW

AVATAR: A Framework for Dynamic Security Analysis of Embedded - - PowerPoint PPT Presentation

Feb 20, 2023 631 likes •1.09k views

AVATAR: A Framework for Dynamic Security Analysis of Embedded Systems Firmwares Jonas Zaddach (zaddach@eurecom.fr) Luca Bruno, Aurlien Francillon, Davide Balzarotti Outline Introduction AVATAR overview Framework components

slide-1
SLIDE 1

AVATAR: A Framework for Dynamic Security Analysis of Embedded Systems’ Firmwares

Jonas Zaddach (zaddach@eurecom.fr) Luca Bruno, Aurélien Francillon, Davide Balzarotti

slide-2
SLIDE 2

Outline

  • Introduction
  • AVATAR overview
  • Framework components
  • Use cases
  • Conclusion

2/24/14 2

slide-3
SLIDE 3

Software is everywhere

  • Embedded devices are diverse – but all of them

run software

2/24/14 3

slide-4
SLIDE 4

Reasons for embedded security

  • Embedded devices are ubiquitous

– Even if invisible, they are essential to your life

  • Can operate for many years

– Legacy systems, no (security) updates

  • Have a large attack surface

– Networking, forgotten debug interfaces, etc

2/24/14 4

slide-5
SLIDE 5

Third party security evaluation

  • No source code available
  • No toolchain available
  • No documentation available
  • Distinct tools (to flash and debug) for each

manufacturer

2/24/14 5

slide-6
SLIDE 6

Wishlist for security evaluation

2/24/14 6

  • Typical PC security toolbox

– Advanced debugging techniques

  • Tracing
  • Fuzzing
  • Tainting
  • Symbolic Execution

– Integrated tools

  • IDA Pro
  • GDB

A B C D E ≤ 0 > 0 < 8 ≥ 8 0 < x < 8

slide-7
SLIDE 7

Challenges

  • Advanced dynamic analysis needs

emulation

  • Full emulation

– Unknown peripherals – Firmware fails if peripherals are missing

  • Integration

– Support multiple vendors and platforms

2/24/14 7

slide-8
SLIDE 8

Outline

  • Introduction
  • AVATAR overview
  • Framework components
  • Use cases
  • Conclusion

2/24/14 8

slide-9
SLIDE 9

AVATAR

  • Orchestrate execution between emulator

and device

  • Forward peripheral accesses to the device

under analysis

  • Do not attempt to emulate peripherals

– No documentation – Reverse engineering is difficult

2/24/14 9

slide-10
SLIDE 10

Avatar overview

2/24/14 10

Emulator . . . mov r2, r0 mov r3, r1 add r3, r3, #1 ldr r2, [r2, #0] cmp r2, r3 . . . Device In-memory stub Memory Registers CPU state Avatar Analysis script plugins Analysis plugins

slide-11
SLIDE 11

Avatar overview

2/24/14 11

Emulator . . . mov r2, r0 mov r3, r1 add r3, r3, #1 ldr r2, [r2, #0] cmp r2, r3 . . . Device In-memory stub Memory Registers CPU state Avatar Analysis script plugins Analysis plugins

slide-12
SLIDE 12

Avatar overview

2/24/14 12

Emulator . . . mov r2, r0 mov r3, r1 add r3, r3, #1 ldr r2, [r2, #0] cmp r2, r3 . . . Device In-memory stub Memory Registers CPU state Avatar Analysis script plugins Analysis plugins

slide-13
SLIDE 13

Avatar overview

2/24/14 13

Emulator . . . mov r2, r0 mov r3, r1 add r3, r3, #1 ldr r2, [r2, #0] cmp r2, r3 . . . Device In-memory stub Memory Registers CPU state Avatar Analysis script plugins Analysis plugins

IRQ

slide-14
SLIDE 14

Outline

  • Introduction
  • AVATAR overview
  • Framework components
  • Use cases
  • Conclusion

2/24/14 14

slide-15
SLIDE 15

Emulator

2/24/14 15

Emulator Avatar Configuration Qemu GDB Remote Memory S2E Qemu Klee LLVM Analysis plugins Memory Registers CPU state

slide-16
SLIDE 16

Avatar core

2/24/14 16

Emulator Avatar Device Configuration interface GDB interface Remote memory GDB interface plugins Analysis plugins Analysis script

slide-17
SLIDE 17

Embedded target

2/24/14 17

Device In-memory stub Memory Registers CPU state Avatar JTAG server

slide-18
SLIDE 18

Target communication

  • Either a debugging interface

– JTAG – Debug Serial Interface

  • Or code injection and a communication

channel

– Custom GDB Stub + Serial Port

2/24/14 18

slide-19
SLIDE 19

Bottlenecks

  • Emulated execution is much slower than

execution on the real device

– Memory access forwarding through low- bandwidth channel is the bottleneck – In one case down to ~10 memory accesses/ sec.

  • Interrupts can saturate debug connection

2/24/14 19

slide-20
SLIDE 20

Improving performance

  • Transfer execution/state

– From the device to the emulator – From the emulator to the device

  • Migrate memory and code snippets

– Keep memory regions in the emulator – Execute IO-intensive pieces of code on the device

2/24/14 20

slide-21
SLIDE 21

Full separation mode

2/24/14 21

Emulator Device

State Register State Memory

Avatar

slide-22
SLIDE 22

Memory access optimization

2/24/14 22

Emulator Device

State Register Memory State IO Memory

Avatar

slide-23
SLIDE 23

Execute code snippets on the device

2/24/14 23

Emulator Device

State State

Avatar

Code

slide-24
SLIDE 24

Execute code snippets on the device

2/24/14 24

Emulator Device

State State Code Code

slide-25
SLIDE 25

Outline

  • Introduction
  • AVATAR overview
  • Framework components
  • Use cases
  • Conclusion

2/24/14 25

slide-26
SLIDE 26

Use case: Hard Disk

  • Recover bootloader protocol with symbolic

execution

– Inject GDB stub – Instrument flash loading – Inject symbolic values for data read from serial port – Keep track of which input leads into which code flow

2/24/14 26

http://www.s3.eurecom.fr/docs/ndss14_zaddach.pdf

slide-27
SLIDE 27

Use case: GSM Phone

  • Search vulnerabilities in SMS decoding

routine

– Connect through JTAG – Execute on device until SMS decoding – Replace SMS payload with symbolic values – Check for symbolic values in

  • program counter
  • load/store address

2/24/14 27

slide-28
SLIDE 28

Use case: Econotag

  • Find proof-of-concept bug in user

application

– Connect through JTAG – Execute on device until Zigbee packet arrives – Replace payload with symbolic values – Check for symbolic values in

  • program counter
  • load/store address

2/24/14 28

slide-29
SLIDE 29

We are adding more devices

2/24/14 29

slide-30
SLIDE 30

Outline

  • Introduction
  • AVATAR overview
  • Framework components
  • Use cases
  • Conclusion

2/24/14 30

slide-31
SLIDE 31

Future work

  • Enhance state consistency

– DMA memory changes not tracked

  • Automatically emulate peripherals
  • Improve symbolic execution

– Coherency between HW and SW – Improve bug-finding strategies

2/24/14 31

slide-32
SLIDE 32

Conclusion

  • AVATAR is a modular open-source tool to

– Enable dynamic analysis – And perform symbolic execution – On embedded devices – Where only binary code is available

A first step towards better analysis tools for embedded systems!

2/24/14 32

slide-33
SLIDE 33

Questions?

2/24/14 33

  • Thank you for listening!
  • Open source on github:

https://github.com/eurecom-s3/avatar-python

  • Project page:

http://s3.eurecom.fr/tools/avatar/

Thanks to Pascal Sachs and Luka Malisa who built an earlier prototype of the system, and Lucian Cojocar for applying and extending AVATAR

slide-34
SLIDE 34

References

  • AVATAR web page: http://www.s3.eurecom.fr/tools/avatar/
  • AVATAR: A Framework to Support Dynamic Security Analysis of Embedded

Systems' Firmwares, Jonas Zaddach, Luca Bruno, Aurelien Francillon, Davide Balzarotti

  • Howard: a dynamic excavator for reverse engineering data structures, Asia

Slowinska, Traian Stancescu, Herbert Bos

  • KLEE webpage: http://ccadar.github.io/klee/
  • S2E webpage: https://s2e.epfl.ch/
  • S2E: A Platform for In-Vivo Multi-Path Analysis of Software Systems, italy

Chipounov, Volodymyr Kuznetsov, George Candea

  • The S2E Platform: Design, Implementation, and Applications, Vitaly

Chipounov, Volodymyr Kuznetsov, George Candea

  • QEMU webpage: http://qemu.org
  • Dowsing for Overflows: A Guided Fuzzer to Find Buffer Boundary Violations,

Istvan Haller, Asia Slowinska, Matthias Neugschwandtner, Herbert Bos

2/24/14 34

slide-35
SLIDE 35

Injecting a debugger

2/24/14 35

  • Requires writing and executing memory

– Debug menus allow this sometimes – A code execution vulnerability can be used

  • Requires a communication channel

– Serial port, GPIO, Power consumption, … – GPIO

  • Requires an unused memory location in

the firmware

– Stub is about 3k of code

slide-36
SLIDE 36

Full separation mode

2/24/14 36

Emulator Device

State Register State Memory

Avatar

slide-37
SLIDE 37

Memory access optimization

2/24/14 37

Emulator Device

State Register Memory State IO Memory

Avatar

slide-38
SLIDE 38

Transfer execution from emulator to device

2/24/14 38

Emulator Device

State Register Memory State

slide-39
SLIDE 39

Transfer execution from emulator to device

2/24/14 39

Emulator Device

State

Avatar

State Register Memory

slide-40
SLIDE 40

Transfer execution from device to emulator

2/24/14 40

Emulator Device

State State Register Memory

slide-41
SLIDE 41

Transfer execution from device to emulator

2/24/14 41

Emulator Device

State Register Memory State

Avatar

slide-42
SLIDE 42

Software interrupts

  • Software Interrupts

– Are issued by an interrupt instruction in the code

  • Can be entirely emulated

– Qemu manages calling of software interrupt handlers

2/24/14 42

http://home.netcom.com/~swansont/interrupt.jpg

slide-43
SLIDE 43

Task completion interrupts

  • Triggered by application requests

– Responses aligned with firmware execution speed – E.g., signal that a requested DMA transfer has finished

  • Can be forwarded from the device to the

emulator

– A stub on the device traps interrupts and forwards them

2/24/14 43

slide-44
SLIDE 44

External event interrupts

  • Signals an external event

– Events aligned to wall-clock instead of execution time – E.g., that a time span has elapsed

  • Solution depends

– Controllable interrupts can be forwarded – Uncontrollable interrupts need to be synthesized

  • Original interrupts are suppressed
  • Emulated interrupts are inserted according to emulated

execution speed

2/24/14 44