DEBUGGING HTC PHONESBOOTLOADERS

HBOOTDBG22/10/2013 - HACK.LU 2013

Cédric Halbronn, Nicolas Hureau

WHO ARE WE?Cédric Halbronn - @saidelike

4 years at Sogeti ESEC LabWorked on Windows Mobile, iPhone, AndroidsecurityFocusing on vulnerability research & exploitation

Nicolas Hureau - @kalenzNew recrue at Sogeti ESEC LabLikes low-level stuff

WHAT IS A BOOTLOADER?Piece of code first executed when turning on yourphone

BOOTLOADER GOALInitializing hardwareLoading Google operating system (Android)Restore device factory state (if Android getscorrupted)Update the phone

REASONS TO LOOK INTO BOOTLOADERS?Unlocking the bootloader and rooting your device

Permanent root of your deviceInstall custom ROM (eg: Cyanogenmod)

Understanding how bootloaders really work

Very old code, good potential for vulnerabilitiesEvaluating the physical security risks

What does an attacker get access to?

ABOUT THIS TALKDebugging HTC phones bootloader

AGENDA1. 2. 3. 4. 5.

BasicsRevolutionary vulnerabilityHBOOT debuggerSimple bugConclusion

AGENDA1. Basics2. Revolutionary vulnerability3. HBOOT debugger4. Simple bug5. Conclusion

WHAT IS HBOOT?The bootloader of HTC Android phonesUsed on all HTC phones

Desire, Desire S, Desire Z, One, etc.Controlled by HTCDifferent branded Android phone ⇒ differentbootloader(eg: Samsung, Motorola, etc.)

GETTING TO KNOW HBOOTClosed sources⇒ HTC code base, not Android

2 modes: HBOOT/FASTBOOT

Helpful referencesxda-developers.comtjworld.netunrevoked hboot-tools

VULNERABILITIES IN HBOOT?Used in unlocking tools

(deprecated) (deprecated)

: 15 HTC devices supported: ~10 other HTC devices supported

: HTC One

HBOOT command to read flashmemory

HTC Desire Z (only?)

XTC clip to S-OFF the device

unrevoked3AlphaRevrevolutionaryUnlimited.IOrumrunner

read_emmc

TARGETED DEVICE

HTC Desire ZRun on a Qualcomm MSM7230 (Snapdragon S2) SoC

Baseband processor: ARM9Application processor: Scorpion (custom ARMv7design)

Release date: 2010HBOOT version: 0.85

HTC SECURITY MODEL

S-ON

HTC SECURITY FLAGEverything must be signed by HTCHBOOT does not allow to flash unsigned AndroidROM (zip)HBOOT does not allow to run unsigned code (NBHfile)HBOOT write-protects system / hboot partitionsduring boot

It is hardware-locked (S-ON flag)

⇒ Even a root vulnerability does NOT allow to writepartitions

LOCKED

HTC LOCK/UNLOCKHTC allows us to unlock our device (htcdev.com)Unlock allows HBOOT to flash an unsigned systempartition

HTC keeps control on HBOOT (we keep S-ON)

From a security perspective, unlock forces a factoryreset

Attacker can not access your data (wipe)(theorically)

BUT after unlocking your device⇒ Attacker could make HBOOT load unsigned codeand potentially access your data

GETTING HBOOT BINARYHTC proprietary codeWindows update package

RUU.exe contains a rom.zip file. Content of therom.zip file

Static analysis (IDA Pro). Raw ARM code

boot.img: Android kernel hboot_XYZ.nb0: HBOOT bootloader <- what we are looking for radio.img: Baseband code recovery.img: Recovery kernel system.img: System partition userdata.img: Data partition

DUMPING HBOOT IN RAMIDA not following some code paths

Because of uninitialized memory structures

Initialized context ⇒ get more info on how it reallyworksNeed to get code execution to read memorysnapshot

GETTING CODE EXECUTION IN HBOOTUnlock ⇒ flash custom Android

Not possible to load unsigned code

S-OFF the device with XTC clip + load unsigned NBHbinary?

Would be after HBOOT execution

Exploit a vulnerability in HBOOT?Unlock exploits = good candidates to analyze⇒ Revolutionary tool

AGENDA1. Basics2. Revolutionary vulnerability3. HBOOT debugger4. Simple bug5. Conclusion

REVOLUTIONARY15 supported HTC devicesHTC Desire Z not officially supported

But HBOOT still vulnerableAnalyzed version: 0.4pre4

INTERNAL STEPS1. Temporary "root" of the phone (zergRush)2. Rewrite "misc" partition from Android3. Reboot phone in HBOOT

"fastboot getvar:mainver" ⇒ flash patched HBOOT

"FASTBOOT GETVAR" HANDLERfastboot getvar:mainvervoid fastboot_getvar(char* var) { char buf[64]; //stack-based buffer fastboot_getvar_handler(var, buf); usb_send(buf) }

void fastboot_getvar_handler(char* var, char* buf) { if (!strcmp(var, "mainver")) { //get main version from "misc" partition sprintf(buf, "%s", fastboot_getvar_mainver())); } else { //... }

"FASTBOOT GETVAR" HANDLER"misc" partition writable from rooted Android

Possible to rewrite the main versionAfter reboot in HBOOT

Stack-based buffer overflow ⇒ code execution

GETTING CODE EXECUTION IN HBOOT(CONTINUE)

Coming back to what interests usDump HBOOT memory

Send code implementing read/write memoryprimitives

Using regular "fastboot download" commandTrigger revolutionary exploit to get code execution⇒ Dump whole memory to have HBOOT memorycontext

WHAT ABOUT DEBUGGING?Static analysis ⇒ take timeWould be helpful to have dynamic analysis toolsWould look at specific behaviors

Command parsing, package update, Androidloading, etc.

RequirementsGet code execution: OKCommunication between phone and computer:TODO

COMMUNICATIONHBOOT/FASTBOOT exposes a serial console overUSBSeveral commands

Interesting ones

"download" not implemented in fastboot computerbinary

Hook one of these commandsfastboot oem

getvar <variable> display a bootloader variabledownload [len:hexbinary] send data to the download areaoem custom manufacturer commands

AGENDA1. Basics2. Revolutionary vulnerability3. HBOOT debugger4. Simple bug5. Conclusion

DEBUGGERCode execution in HBOOT + communication: OK⇒ debugger implementation

RequirementsRead/write memory: OK (code execution)Breakpoints: TODO

BREAKPOINT IN ARMARM "bkpt" instructionWhen hitting a breakpoint

CPU triggers an exception: sets DBGDSCR.MOE to"BKPT instruction debug event"Branch at offset 0xC (prefetch abort)

BREAKPOINT HANDLING IN HBOOTBy default, no exception vector table in HBOOT

Install our own handler: no need to checkDBGDSCR.MOESetup abort stack

Save context (registers) to restore them afterhandling

BREAKPOINT HANDLING IN HBOOT

DEBUGGERDebugger on the phone: OK ⇒ need a debuggerclientRequirements

Read/write memory: OK (code execution)Breakpoints: OK (hook prefetch abort)Debugger client: TODO

GDBPROXY.PYScript interfacing GDB and debugger in HBOOT

Works as a GDB server (RSP protocol)And a client for the debugger

Any GDB client applies: arm-gdb, IDA Pro, etc.

DEBUGGERRequirements

Read/write memory: OK (code execution)Breakpoints: OK (hook prefetch abort)Debugger client: OK (any gdb client)

DEBUGGER ARCHITECTURE

Target similarities: design inspired by qcombbdbg

SUMMARYRevolutionary exploit to inject code (fastbootgetvar:mainver)Communication with debugger (hook fastboot oem)Frontend

Python script proxying requests from GDB tobackend

Handle GDB RSP and our debugger protocolRead/write memory & registersAdd/delete breakpoints

Backend: injected codeHook exception vector: prefetch abort

Called when BKPT instruction decodedSimple software breakpoints

WHAT ABOUT USING OUR DEBUGGER?Basic debugger implementation: OKUsing our debugger: TODO

AGENDA1. Basics2. Revolutionary vulnerability3. HBOOT debugger4. Simple bug5. Conclusion

FINDING A NON HARMFUL BUGIn HBOOT mode ⇒ hboot> prompt

hboot> ⇔ "fastboot oem"Execute commands

Enter the following 2 commands'A'*256 + \n + 'B'*256 + \t\nPhone not responding anymore

How are commands parsed?

PARSING HBOOT COMMANDSchar current_cmd[256];char previous_cmd[256];void hboot_command_line() { unsigned int len = 0; char* buf = current_cmd; char* current_char; while (1) { if (!usb_read(buf, 1)) //read one character break; current_char = *buf; switch (current_char) { case '\n': *buf = '\0'; //breakpoint 1 strcpy(previous_cmd, current_cmd); //breakpoint 3 hboot_handle(current_cmd); case '\t': *buf = ' '; //breakpoint 2 strcpy(buf, previous_cmd); len = strlen(buf) buf += len; //...

PARSING HBOOT COMMANDS

PARSING HBOOT COMMANDS

PARSING HBOOT COMMANDS

PARSING HBOOT COMMANDS

PARSING HBOOT COMMANDS

PARSING HBOOT COMMANDS

PARSING HBOOT COMMANDSRead one character at a time into a 256-byte bufferIf "end of command" (\n)

Save first buffer into second buffer and handlecommand

If "tabulation" (\t)Copy second buffer at first buffer end

Idea behind '\t' featureFirst buffer: current commandSecond buffer: saved commandAppend previous command to prompt withtabulation

PROBLEM IN COMMANDS PARSINGWhen using tabulation

No check that current command buffer bigenough to append previous command

Overflow the buffer of the current command

What is really happening? ⇒ Using our debuggerNote: Debugger conflicts with command console,need to switch between them

DEMOAnalyzing the problem with our debugger

PARSING HBOOT COMMANDS

Destination buffer increased when strcpySource and destination buffer adjacents

Source buffer increases as well ⇒ strcpy loopsinfinitely :(

AGENDA1. Basics2. Revolutionary vulnerability3. HBOOT debugger4. Simple bug5. Conclusion

CONCLUSIONFunctional debuggerReverse engineering to find a bug

Using the debugger ⇒ not exploitable on its ownHBOOT command parsing improvable

Debugger source code should be released soon

FUTURE WORKRevolutionary vulnerability fixed on recent devices(eg: HTC One with HBOOT 1.44)Port debugger using another vulnerability (eg:rumrunner)

Look at how rumrunner worksBuy a HTC One :)

Continue our analysis of HBOOT

THANK YOU FOR YOUR ATTENTIONcedric.halbronn@sogeti.com - @saidelike

nicolas.hureau@sogeti.com - @kalenz