reverse engineering the tomtom runner pt. 1

57
Hacking the Internet of Things: TomTom Runner Smartwatch Luis Grangeia | @lgrangeia September 2015 Confraria de Segurança da Informação

Upload: luis-grangeia

Post on 14-Jan-2017

648 views

Category:

Engineering


1 download

TRANSCRIPT

Hacking the Internet of Things: TomTom Runner SmartwatchLuis Grangeia | @lgrangeia

September 2015 Confraria de Segurana da Informao

OverviewIntroductionMotivationsAttack surfaceAnalysisExploitationNext steps

Introduction

IntroductionSaw these guys

Introductiondoing this:

Remote Exploitation of an Unaltered Passenger Vehicle - Charlie Miller and Chris Valasek

IntroductionI want to do that!Lots of uncharted territory in IoT hackingEmbedded systems is not my fortGetting to learn new stuff: WIN

Not done yet!

Motivations

MotivationsTo get started at reverse engineering and IoT hackingIoT == Embedded ARM devices connected to the internetARM is the trend in mobile computingIoT Reversing actually seems easier than x86 reversing less exploit mitigationsBending closed hardware to my will is way cooler than hacking a general purpose system

Target: TomTom Runner

Running SportswatchBluetooth LE + GPSSyncs with PC via USB, smartwatch via BluetoothClosed system

Why the TomTom Runner?Other targets were considered:SPoQ SQ-100:AVR Microcontroller (not ARM)Firmware is not encryptedNo Bluetooth (ANT operates on same frequency though)Deemed Not Cool Enough

Why the TomTom Runner?Other targets were considered:Volkswagen RCD 510:My cars head unitFirmware is encryptedExpensiveArchitecture unknownAttached to car(maybe later )

TomTom RunnerExternal hardware

Dot matrix LCDDecent battery (lasts weeks)USB 2.0 InterfaceBluetooth + GPSBeeper + BuzzerFour-way D-PAD

Rules of EngagementRule 1: No physical tampering!its waterproof!Rule 2: Do not brick it!Almost did, several times

Rule 3: There are no rules

Attack Surface

Attack SurfaceUSB InterfaceBluetoothUser Interface

Attack Surface

AnalysisUSB, Firmware, Dissection

Attack Surface: USBObtain Firmware via forced upgrade (Tomtom Mysports Connect)

Attack Surface: USBBetter alternative: Linux!Linux TomTom GPS Watch Utilitiesgithub.com/ryanbinns/ttwatchUse the source!Firmware is available here:download.tomtom.com/sweet/fitness/Firmware/E9030000/FirmwareVersionConfigV2.xml

Main Firmware fileFirmware for the GPS ModuleLanguage resource files (eng / ger/ por / etc.)Manifest files (configuration settings)Firmware for the BLE ModuleNote to TomTom: Use SSL!

Reversing the main firmwareBinwalk:

Reversing the main firmwareComparing different versions of the same file (vbindiff)

Reversing the main firmwareBest guess: AES Encrypted, ECB modeMAC Validated (ECB block shuffling fails)This hypothesis is reinforced by a document from Atmel (more on that in a sec)

Other firmware filesBLE Firmware is not encrypted: Flashed by the main firmwareMD5 Validated:

GPS Firmware also not encrypted

opening the deviceFCC == X-Ray Vision!Every RF device sold in USA opened, photographed, testedSearchable and available for everyoneSearch:http://fcc.iothanks @dominicgs !

opening the deviceAtmel ATSAM4S8CMain CPU (MCU):Micron N25Q032A13ESC40FSerial flash memory (4MB)Texas Instruments CC2541:Bluetooth ModuleCSR SiRF starV 5e GNSSGPS Module (off screen)

Google helps: A look inside the TomTom GPS Watchhttp://www.eetasia.com/ART_8800713547_1034362_NP_cb9c106d.HTM

USB Protocol ReversingDevice resets when USB is connected / disconnectedDevice not usable while in USB modeMost of the USB communication is Reading / Writing files to EEPROMLanguage filesRace / Exercise filesPreferences filesFirmware files:When the device reboots, the bootloader checks for the presence of firmware files, and flashes them (if valid)

USB Protocol ReversingThe basics of the protocol were already reversed:github.com/ryanbinns/ttwatch

My fork: github.com/lgrangeia/ttwatchttdiag tool sends raw USB commandsParses USBPCap files (captured from the oficial Windows software)

USB Protocol ReversingProtocol Format (this one formats the EEPROM)09 | Size | Seq | CMD| [arguments]

255 possible commands (some with arguments)Fuzzing found interesting stuff (about 60 different commands):Test menuDiagnostic messagesScreenshotsetc.Interesting attack surface, might yield results later.

OUT: 09 02 D1 0E IN:01 16 D1 0E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

## Response message "01 06 17 28 00 00 00 18" appears to be ## "unused command"

0x00# unused0x01# unused0x02# open file for writing0x03# delete file0x04# write file data0x05# get file size0x06# open file for reading0x07# read file data request0x08# unknown (appears file related)0x09# read file data response0x0a # find close file 0x0b # unused0x0c # close file0x0d # creates a new config file (0x00f20000) if one doesn't exist0x0e # *** WARNING*** clears eeprom0x0f # returns 20 null bytes0x10 # resets device, returns data0x11 # find first file0x12 # find next file0x13# unused0x14 # get current time0x15 # appears also time related (date?)0x16 # returns 4 null bytes0x17 # acks, returns nothing0x18# Enters test mode! menu!# Test mode commands:# down: test gps open sky# up: test gps chamber# left:test_ttff# right:ohr_read_sensor

0x19# Appears to exit test mode, resets device0x1a # unknown (used), returns 4 bytes of data (battery?)0x1b # returns 12 null bytes0x1c # write to lcd controller0x1d # reset gps processor "wait 1 minute before disconnecting USB"0x1e # "Reset GSD done!"

0x1f # returns 4 byte null0x20 # get product id0x21 # get firmware version0x22 # returns 1 byte null0x23 # returns 65 00 00 or 66 00 00 (some levels?)0x24# returns 4 byte null0x25# take screenshot! 0x0086000n0x26# no data0x27# unused0x28 # get ble firmware version0x29# "jenkins-berlin-rcl 68 2015-06-18_10-43-37"0x2a # "undef"0x2b # "RCL"0x2c # "1969105"0x2d # no data0x2e # 00 3C 28 7A 00 00 01 67 00 00 00 73 00 00 00 25 00 00 00 00# these could be registers:0x2f # seems to accept 4 byte argument, flag register? 00 00 3F 950x30# 00 02 80 000x31# appears to accept 4 byte argument, last byte is response size (good to fuzz)0x32 # unused0x33# 12 bytes return0x34# 12 bytes return, also dependant of argument (good to fuzz)

0x35 # "nothing to report"