Reverse Engineering the TomTom Runner pt. 1
Download as PPTX, PDF2 likes2,984 views
The document discusses the hacking of the TomTom Runner smartwatch, highlighting motivations, attack surfaces, and exploitation methods. It covers methods of firmware extraction, USB protocols, and vulnerabilities identified in the device, along with future steps for further exploitation involving data exfiltration and custom firmware creation. The author emphasizes the weak security of IoT devices and the potential real-world consequences of such vulnerabilities.
![USB Protocol Reversing
• Protocol 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 menu
• Diagnostic messages
• Screenshots
• etc.
• 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](https://image.slidesharecdn.com/reverseengineeringiot-part1-160411102416/85/Reverse-Engineering-the-TomTom-Runner-pt-1-29-320.jpg)
![• LR [R14] =
0x00426a75
subroutine call return
address
• PC [R15] =
0x2001bf54 program
counter
• We’re in SRAM (heap
or stack)
• Return address is in
Flash region
• Nice.](https://image.slidesharecdn.com/reverseengineeringiot-part1-160411102416/85/Reverse-Engineering-the-TomTom-Runner-pt-1-47-320.jpg)
![After some fiddling...
R0 = 0x00000000
R1 = 0xffffffe3
R2 = 0x00000002
R3 = 0x00000029
R12 = 0x00000000
LR [R14] = 0x00441939 subroutine call return
address
PC [R15] = 0x000000cc program counter](https://image.slidesharecdn.com/reverseengineeringiot-part1-160411102416/85/Reverse-Engineering-the-TomTom-Runner-pt-1-48-320.jpg)
![Arbitrary code execution
Crashlog - SW ver 1.8.42
R0 = 0x00000000
R1 = 0x00001337
R2 = 0x00000013
R3 = 0x00000037
R12 = 0x00000000
LR [R14] = 0x00441939 subroutine
call return address
PC [R15] = 0x2001a48c program
counter
.thumb
mov r2, #0x13
mov r3, #0x37
add r1, r3, r2, lsl #8
Yep, reliable arbitrary, code execution on my wrist!](https://image.slidesharecdn.com/reverseengineeringiot-part1-160411102416/85/Reverse-Engineering-the-TomTom-Runner-pt-1-49-320.jpg)
Reverse Engineering the TomTom Runner pt. 1
- 1. Hacking the Internet of Things: TomTom Runner Smartwatch Luis Grangeia | @lgrangeia September 2015 Confraria de Segurança da Informação
- 3. Introduction
- 5. Introduction •…doing this: “Remote Exploitation of an Unaltered Passenger Vehicle” - Charlie Miller and Chris Valasek
- 6. Introduction • “I want to do that!” • Lots of uncharted territory in IoT hacking • ‘Embedded systems’ is not my forté… • Getting to learn new stuff: WIN Not done yet!
- 7. Motivations
- 8. Motivations • To get started at reverse engineering and IoT hacking • IoT == Embedded ARM devices connected to the internet • ARM is the trend in mobile computing • IoT Reversing actually seems easier than x86 reversing • less exploit mitigations • “Bending” closed hardware to my will is way cooler than hacking a general purpose system
- 9. Target: TomTom Runner • Running Sportswatch • Bluetooth LE + GPS • Syncs with PC via USB, smartwatch via Bluetooth • Closed system
- 10. Why the TomTom Runner? • Other targets were considered: • SPoQ SQ-100: • AVR Microcontroller (not ARM) • Firmware is not encrypted • No Bluetooth (ANT operates on same frequency though…) • Deemed Not Cool Enough™
- 11. Why the TomTom Runner? • Other targets were considered: • Volkswagen RCD 510: • My car’s head unit • Firmware is encrypted • Expensive • Architecture unknown • Attached to car • (maybe later )
- 12. TomTom Runner External hardware • Dot matrix LCD • Decent battery (lasts weeks) • USB 2.0 Interface • Bluetooth + GPS • Beeper + Buzzer • Four-way D-PAD
- 13. Rules of Engagement • Rule 1: No physical tampering! • it’s waterproof! • Rule 2: Do not brick it! • Almost did, several times… • Rule 3: There are no rules
- 14. Attack Surface
- 15. Attack Surface • USB Interface • Bluetooth • User Interface
- 16. Attack Surface
- 18. Attack Surface: USB • Obtain Firmware via forced upgrade (Tomtom Mysports Connect)
- 19. Attack Surface: USB • Better alternative: Linux! • Linux TomTom GPS Watch Utilities • github.com/ryanbinns/ttwatch • Use the source! • Firmware is available here: • download.tomtom.com/sweet/fitness/Firmware/E9030000/ FirmwareVersionConfigV2.xml
- 20. • Main Firmware file • Firmware for the GPS Module • Language resource files (eng / ger/ por / etc.) • Manifest files (configuration settings) • Firmware for the BLE Module • Note to TomTom: Use SSL!
- 21. Reversing the main firmware • Binwalk:
- 22. Reversing the main firmware • Comparing different versions of the same file (vbindiff)
- 23. Reversing the main firmware • Best guess: • AES Encrypted, ECB mode • MAC Validated (ECB block shuffling fails) • This hypothesis is reinforced by a document from Atmel (more on that in a sec)
- 24. Other firmware files • BLE Firmware is not encrypted: • Flashed by the main firmware • MD5 Validated: • GPS Firmware also not encrypted
- 25. “opening” the device • FCC == X-Ray Vision! • Every RF device sold in USA opened, photographed, tested • Searchable and available for everyone • Search: • http://fcc.io • thanks @dominicgs !
- 26. “opening” the device • Atmel ATSAM4S8C • Main “CPU” (MCU): • Micron N25Q032A13ESC40F • Serial flash memory (4MB) • Texas Instruments CC2541: • Bluetooth Module • CSR SiRF starV 5e GNSS • GPS Module (off screen) Google helps: “A look inside the TomTom GPS Watch” http://www.eetasia.com/ART_8800713547_1034362_NP_cb9c106d.HTM
- 27. USB Protocol Reversing • Device resets when USB is connected / disconnected • Device not usable while in USB mode • Most of the USB communication is Reading / Writing files to EEPROM • Language files • Race / Exercise files • Preferences files • Firmware files: • When the device reboots, the bootloader checks for the presence of firmware files, and flashes them (if valid)
- 28. USB Protocol Reversing • The basics of the protocol were already reversed: • github.com/ryanbinns/ttwatch • My fork: github.com/lgrangeia/ttwatch • ‘ttdiag’ tool sends raw USB commands • Parses USBPCap files (captured from the oficial Windows software)
- 29. USB Protocol Reversing • Protocol 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 menu • Diagnostic messages • Screenshots • etc. • 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
- 30. ## Response message "01 06 17 28 00 00 00 18" appears to be ## "unused command" 0x00 # unused 0x01 # unused 0x02 # open file for writing 0x03 # delete file 0x04 # write file data 0x05 # get file size 0x06 # open file for reading 0x07 # read file data request 0x08 # unknown (appears file related) 0x09 # read file data response 0x0a # find close file 0x0b # unused 0x0c # close file 0x0d # creates a new config file (0x00f20000) if one doesn't exist 0x0e # *** WARNING*** clears eeprom 0x0f # returns 20 null bytes 0x10 # resets device, returns data 0x11 # find first file 0x12 # find next file 0x13 # unused 0x14 # get current time 0x15 # appears also time related (date?) 0x16 # returns 4 null bytes 0x17 # acks, returns nothing 0x18 # 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 device 0x1a # unknown (used), returns 4 bytes of data (battery?) 0x1b # returns 12 null bytes 0x1c # write to lcd controller 0x1d # reset gps processor "wait 1 minute before disconnecting USB" 0x1e # "Reset GSD done!" 0x1f # returns 4 byte null 0x20 # get product id 0x21 # get firmware version 0x22 # returns 1 byte null 0x23 # returns 65 00 00 or 66 00 00 (some levels?) 0x24 # returns 4 byte null 0x25 # take screenshot! 0x0086000n 0x26 # no data 0x27 # unused 0x28 # get ble firmware version 0x29 # "jenkins-berlin-rcl 68 2015-06-18_10-43-37" 0x2a # "undef" 0x2b # "RCL" 0x2c # "1969105" 0x2d # no data 0x2e # 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 95 0x30 # 00 02 80 00 0x31 # appears to accept 4 byte argument, last byte is response size (good to fuzz) 0x32 # unused 0x33 # 12 bytes return 0x34 # 12 bytes return, also dependant of argument (good to fuzz) 0x35 # "nothing to report" <- could be error logs 0x36 # unused...
- 34. EEPROM File structure • Device contains 4MB EEPROM with a primitive filesystem • Each file can be read or written to via USB (and bluetooth) • Name structure is 32 bit values • Coincident with firmware files
- 36. Exploitation
- 37. Status • We have a fairly large external attack surface: • USB • EEPROM Files • read / write all files • Bluetooth (fairly unexplored)
- 38. Problems • We have zero knowledge of the operating environment • Address Mappings / Threads / Libs / Interrupts??
- 39. Challenges • Get our code running on the device • First try: • Fuzzing the language files • ASCII strings Buffers overflow?
- 40. Language Files • List of NUL terminated ASCII strings • First 4 bytes: length of all strings inc. nulls (little endian) • Next 4 bytes: number of strings (little endian)
- 41. Language Files • Tested printf() style format strings • Tested zero length strings • Tested oversized files
- 42. Zero length language file (video) • Empty strings, non-empty number of strings • Result: Partial look into stack region?
- 43. Big language file (video) • String buffer over 6000 bytes • Result: Crash!
- 44. Language files • Device resets (interesting)… • A mistery file appears (0x00013000)…
- 45. First crash!
- 46. Address Space • Collected a LOT of crash dumps • Read (and must read more) ARM documentation • Note: • This is an ARM Cortex M4 CPU • Works in ARM Thumb-32 mode exclusively • No ASLR (predictable) • Not many memory controls (SRAM is executable)
- 47. • LR [R14] = 0x00426a75 subroutine call return address • PC [R15] = 0x2001bf54 program counter • We’re in SRAM (heap or stack) • Return address is in Flash region • Nice.
- 48. After some fiddling... R0 = 0x00000000 R1 = 0xffffffe3 R2 = 0x00000002 R3 = 0x00000029 R12 = 0x00000000 LR [R14] = 0x00441939 subroutine call return address PC [R15] = 0x000000cc program counter
- 49. Arbitrary code execution Crashlog - SW ver 1.8.42 R0 = 0x00000000 R1 = 0x00001337 R2 = 0x00000013 R3 = 0x00000037 R12 = 0x00000000 LR [R14] = 0x00441939 subroutine call return address PC [R15] = 0x2001a48c program counter .thumb mov r2, #0x13 mov r3, #0x37 add r1, r3, r2, lsl #8 Yep, reliable arbitrary, code execution on my wrist!
- 50. • Still not sure where we are exactly in SRAM • Most likely heap segment (stack is too far below) • We can return to the calling subroutine and resume execution • No clue about stack status • But no clue where else we can jump to/call • Wild guess: derivative of FreeRTOS? • Only door to the outside world is crash file. • Main goal: obtain AES key to decrypt firmware and “turn the lights on” Not quite there yet
- 51. • Still figuring out address space Currently...
- 52. Next Steps
- 53. Next steps • Achieve efficient data exfiltration • AES key may be extractable from bootloader • Possible exfiltration vectors: • Menu strings • File operations / Hardfault handler • System calls • Once firmware key is found, custom firmware is possible
- 54. Next steps • Explore same issues via Bluetooth • Watch is usable during bluetooth connection • Most USB commands appear to work via Bluetooth • github.com/dlenski/ttblue • Lots of potential here
- 55. Help needed! • Do you have a tomtom runner/multisport/cardio? • Can you borrow one? • Do you like reversing? • Do you know ARM Thumb-2 instruction set? • Do you like to read hardware datasheets? Join us! (there will be beer)
- 56. Takeaways • IoT is friendly for noob reversers • Cutting edge exploit development for x86/x64? Not so much • This is not earth shattering end of world vulnerability • Get your risk assessment on (hackers usually suck at it) • IoT security is weak. Real consequences / deaths for some fields: • (self driving) cars, airplanes, pacemakers, etc. • Think twice before connecting your car/airplane to the internet.
- 57. Thanks! Questions? Luis Grangeia | @lgrangeia September 2015 Confraria de Segurança da Informação