Reverse Engineering with Hardware Debuggers 11 Mar 10 11 Mar 10 - - PowerPoint PPT Presentation

▶
reverse engineering with hardware debuggers
SMART_READER_LITE
LIVE PREVIEW

Reverse Engineering with Hardware Debuggers 11 Mar 10 11 Mar 10 - - PowerPoint PPT Presentation

Jan 06, 2023 41 likes •232 views

Reverse Engineering with Hardware Debuggers 11 Mar 10 11 Mar 10 JASON RABER and JASON CHEATHAM ATSPI Assessment Science Team ATSPI Assessment Science Team RYTA Air Force Research Laboratory Public release authorization 88 ABW-10-1497 2

slide-1
SLIDE 1

Reverse Engineering with Hardware Debuggers

11 Mar 10

JASON RABER and JASON CHEATHAM ATSPI Assessment Science Team

11 Mar 10

ATSPI Assessment Science Team RYTA Air Force Research Laboratory

Public release authorization 88 ABW-10-1497

slide-2
SLIDE 2

Outline

  • Architecture
  • Breakpoints
  • Breakpoints
  • Macros
  • Hypervisors

Hypervisors

2

slide-3
SLIDE 3

The Hard Way

Hardware debugger / in-target probe (ITP) / in-circuit gg g p ( ) emulator (ICE)

Socket

CPU

3

slide-4
SLIDE 4

Friends with Benefits

  • Hardware debuggers can see almost everything
  • They live outside the OS, so even kernel mode

rootkits can’t hide

  • Rewriting firmware
  • They’re OS independent

J t d tibl 86 – Just needs a compatible x86 processor

4

slide-5
SLIDE 5

The Softer Side

5

slide-6
SLIDE 6

Outline

  • Architecture
  • Breakpoints
  • Breakpoints
  • Macros
  • Hypervisors

Hypervisors

6

slide-7
SLIDE 7

Ways to Break Things

  • Hardware Breakpoints

DR registers – DR registers

  • Software Breakpoints

Software Breakpoints – ICEBP (0xF1) instruction + DR7 bit 12

  • Infinite loops

– Steal a couple bytes and replace with 0xEBFE

7

slide-8
SLIDE 8

Infinite Breakpoints

  • EB FE is a jump to the same address (jmp $)

Inject the infinite loop (0xEBFE) into the application or – Inject the infinite loop (0xEBFE) into the application or driver – Halt the CPU when the system freezes, and there you y y are C

  • They’re very easy to use with an ICE

– No worries about freezing the system Don’t have to deal with virtual memory – Don t have to deal with virtual memory

  • Checksums can detect these, so place them

8

Checksums can detect these, so place them carefully

slide-9
SLIDE 9

Outline

  • Architecture
  • Breakpoints
  • Breakpoints
  • Macros
  • Hypervisors

Hypervisors

9

slide-10
SLIDE 10

More Power…

define proc pcrange(startaddr,

  • Macros can make an

l t f l

p p g endaddr) define ord4 startaddr define ord4 endaddr {

emulator very powerful

– Implement complex or repetitive tasks Detailed control of ICE

{ while (1) { if (EIP >= startaddr && EIP <= endaddr) {

– Detailed control of ICE

  • SourcePoint uses a C

like scripting language

break } else { step 4

like scripting language

– Variables, functions, control flow – Types have well-defined

} } }

Types have well defined widths

  • ord1, int4, real8, …

– Control statements for ICE

10

slide-11
SLIDE 11

Range Breakpoint

11

slide-12
SLIDE 12

Run Trace

flist (“tracelog.txt”, 1) define ord4 lasteip = EIP softremove while (1) { if (EIP > 0 C0000000 && lasteip < 0 C0000000) { if (EIP >= 0xC0000000 && lasteip < 0xC0000000) { softbreak = location=lasteip+2 softbreak = location=lasteip+3 softbreak = location=lasteip+4 softbreak = location=lasteip+5 softbreak = location=lasteip+6 lasteip = EIP go } if (EIP != endaddr) { asm eip printf("eax: “); eval eax virtual printf("ebx: “); eval ebx virtual printf("ecx: "); eval ecx virtual printf("edx: "); eval edx virtual printf("esi: "); eval esi virtual printf( esi: ); eval esi virtual printf("edi: "); eval edi virtual printf("esp: "); eval esp virtual lasteip = EIP step } else {

12

nolog stop } }

slide-13
SLIDE 13

From the Outside In

  • Emulator access is pretty raw, so we wrote some

simple forensic macros simple forensic macros – list_procs() – get_ssdt() g _ () – get_syscall_addr(name) – hook_syscall(name) – list_mods()

13

slide-14
SLIDE 14

get_syscall_addr

define proc pointer get_syscall_addr(syscall_name) define nstring syscall_name { if (syscall_name == "NtCreateProcessEx") { return ssdt_index_to_addr(0x30, 0) } else if (syscall_name == "NtCreateSection") { return ssdt index to addr(0x32 0) define proc pointer find_gdi_proc() { define pointer PsActiveProcessHead = get_head_proc() define pointer first_proc = flink_to_proc_addr(PsActiveProcessHead) return ssdt_index_to_addr(0x32, 0) } else { printf("Unknown system call\n"); return 0 } define proc pointer ssdt_index_to_addr(index, table) define ord4 index { define pointer ssdt = get_ssdt() define proc pointer get_ssdt() { d fi i t di dd fi d di () define pointer current_flink = next_proc_flink(first_proc) define pointer current_proc = flink_to_proc_addr(current_flink) while (current_flink != PsActiveProcessHead) { d fi d1 ( ) } define pointer service_table_base = ord4 ssdt return ssdt_service(service_table_base, index) } define pointer gdi_addr = find_gdi_proc() define pointer tlh_flink = proc_thread_list_head(gdi_addr) define pointer thread_list_head = flink_to_thread_addr(tlh_flink) define pointer ssdt = thread_ssdt(thread_list_head) return ssdt define ord1 type = proc_type(current_proc) if (type != 0x03) { printf("Non‐process type: %x\n", type); break; } define ord4 w32proc = proc_win32process(current_proc) } if (w32proc != 0x0) return current_proc current_flink = next_proc_flink(current_proc) current_proc = flink_to_proc_addr(current_flink) }

14

} }

slide-15
SLIDE 15

Outline

  • Architecture
  • Breakpoints
  • Breakpoints
  • Macros
  • Hypervisors

Hypervisors

15

slide-16
SLIDE 16

Blue…Something

  • ICE runs below hypervisors
  • You can go far with a few simple macros

– vmx is enabled vmx_is_enabled – vmx_goto_resume – vmx_guest_eip – vmx_exit_reason

16

slide-17
SLIDE 17

Down We Go…

17

slide-18
SLIDE 18

Nobody’s Perfect

  • You can’t single step or trace across the ring -1/0

boundary boundary

  • Finding the hypervisor is tricky

g yp y

  • Newer VM instructions can cause problems

18

slide-19
SLIDE 19

Summary The Debuginator

19