DIGOO DG-HOSA – Part 2 Firmware Extraction and Initial Analysis

This is a continuation from a previous post: https://ben.the-collective.net/2019/08/21/digoo-dg-hosa-part-1-teardown-and-hardware/

Finding the connections

Now that I have the lay of the land for the device (which that I outlined in my previous part of the series) the first thing I looked for is the debugging connections for the main GigaDevices processor. This processor looks to be the primary processor for the device and has the most valuable firmware. Since the board was well labeled I didn’t need to use any tools like a JTAGulator or an Arduino board with the JTAGenum firmware to identify which test points are the debug interface. I was able to find the SWDIO, SWCLK, +3.3 and GND connections for the Serial Wire Debug (SWD) debug interface. This is the same interface that STM32 chips utilize and it provides similar functionality as a “standard” JTAG interface.

Serial Wire Debug (SWD) is a 2-pin (SWDIO/SWCLK) electrical alternative JTAG interface that has the same JTAG protocol on top. SWD uses an ARM CPU standard bi-directional wire protocol, defined in the ARM Debug Interface v5. This enables the debugger to become another AMBA bus master for access to system memory and peripheral or debug registers.

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2014/10/21/serial_wire_debugs-qKCT

In the image below you can see the debug test points along with the with wires soldered to them to connect to my debugger. The proximity of these test points to the GD32F105 processor, it is a good assumption that they are for that chip.

As a bonus also pictured is my wire soldered around the switch on the upper left to bypass the intrusion detection function.

For this project, I soldered wires to most of the test points across the board. This board has a ton of test points that maybe be useful to monitor signals over the course of this project. To manage the wiring for all of the test points on this project I created a test jig to keep the setup organized. The next picture shows my test setup.

The firmware extraction setup

This jig was inspired by some tweets long ago by cybergibbons where he recommended doing something similar. Once all of the test wires were in place, I hooked up my ARM debugger of choice the Black Magic Probe (BMP) from 1BitSquared and the process to started to extract the firmware.

Initially, I tried to power the board using the BMP but I found that the BMP was not able to provide enough power to the board to support the minimum number of peripherals. The BMP can only supply 100mA of power. Some lights would come on but gdb would not detect any devices connected. I ended up adding the USB connection you see in the photo to provide more power to the board.

Now that everything is powered and connected I was able to use gdb to attach to the board and dump the firmware of the device.

Extracting the firmware: gdb

The first step is to attach my local arm gdb build to the Blackmagic Probe which acts as a remote gdb server. I always find the Useful GDB commands wiki page in the BMP wiki to be very useful in refreshing my memory. The syntax and terminal output I started with are:

╭─locutus@theborgcube ~/Projects/RE-Digoo_DG-HOSA
╰─$ arm-none-eabi-gdb -ex "target extended-remote /dev/tty.usbmodemC2D9BBC31"
 GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160616-cvs
 Copyright (C) 2015 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
 and "show warranty" for details.
 This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
 Type "show configuration" for configuration details.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/.
 Find the GDB manual and other documentation resources online at:
 http://www.gnu.org/software/gdb/documentation/.
 For help, type "help".
 Type "apropos word" to search for commands related to "word".
 /Users/locutus/.gdbinit:1: Error in sourced command file:
 No symbol table is loaded.  Use the "file" command.
 Remote debugging using /dev/tty.usbmodemC2D9BBC31
 (gdb) monitor
 Black Magic Probe (Firmware v1.6.1-1-g74af1f5) (Hardware Version 3)
 Copyright (C) 2015  Black Sphere Technologies Ltd.
 License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
 (gdb) monitor swdp_scan
 Target voltage: 3.3V
 Available Targets:
 No. Att Driver
  1      STM32F1 high density
 (gdb) attach 1
 Attaching to Remote target
 0x08007b46 in ?? ()
 (gdb) dump binary memory firmware.bin 0x08000000 0x080FFFFF
 Cannot access memory at address 0x8080000

When I ran into the error at the end of the terminal output I was a bit confused until I looked at this memory layout of the chip in the datasheet and saw that I was overrunning the size of the first flash memory bank.

datasheet

After I adjusted the GDB dump command…

(gdb) dump binary memory firmware.bin 0x08000000 0x0807FFFF
(gdb)

…success!

╭─locutus@theborgcube ~/Projects/RE-Digoo_DG-HOSA
╰─$ ls -l firmware.bin
 -rw-r--r--  1 locutus  staff  524287 Nov 16 14:13 firmware.bin

I now have a copy of the firmware we can do some initial analysis of it.

Initial Analysis

First thing first like with any binary I start by running strings to get some hints on the contents of the binary and make sure it is a valid dump. I found a ton of strings showing this is a valid dump of the firmware, most notably the same markings on the board showing up in the firmware:

PCB:PG-103 VER2.3/FIRMWARE: 103-2G-J

and other strings indicate that they are using the Real-Time Operating system (RTOS) OS-III (link2) as the operating system. The Micrium site does not specifically list the Gigadevices chip in the supported just the general ARM Cortex-M3 cores as supported.

Seeing this let me know that reversing this firmware will be much more complex then I had hoped. The RTOS will add a lot of scheduling and random functions to look into. After this initial investigation, it is time to load the firmware into Radare. I used the following command when loading it up:

r2 -a arm -b 16 -m 0x0800c000 firmware.bin

This syntax sets the proper processor (-a) and CPU register size (-b) and starting memory location (-m). Once loaded I run an initial analysis job to see what Radare finds.

[0x0800c000]> aaa
 [x] Analyze all flags starting with sym. and entry0 (aa)
 [x] Analyze function calls (aac)
 [x] find and analyze function preludes (aap)
 [x] Analyze len bytes of instructions for references (aar)
 [x] Check for objc references
 [x] Check for vtables
 [x] Finding xrefs in noncode section with anal.in=io.maps
 [x] Analyze value pointers (aav)
 [x] Value from 0x0800c000 to 0x0808bfff (aav)
 [x] 0x0800c000-0x0808bfff in 0x800c000-0x808bfff (aav)
 [x] Emulate code to find computed references (aae)
 [x] Type matching analysis for all functions (aaft)
 [x] Use -AA or aaaa to perform additional experimental analysis.

[0x0800c000]> afl |wc -l
      844

Radare found 844 functions without any hints or adjustments. In some of the work I have already done, there are even more than 844 functions. Now that I have a copy of the firmware, I’ve dived in and started analyzing the firmware which as of writing is still a work in progress. As I get further along I will cover some of the techniques I am using to take apart this firmware.

Enabling old TLS / SSL ciphers in OpenSSL

I was reminded of this tip during the CTF at a recent DC207 meetup. This config change is needed on machines with modern versions of OpenSSL that have disabled the older ciphers. The issue is that the old TLS, SSL and associated cipher suites have become insecure and support is subsequently dropped in OpenSSL.

For a workaround to this, you can edit the following lines at the bottom of /etc/ssl/openssl.cnf

[system_default_sect]
 MinProtocol = TLSv1
 CipherString = DEFAULT@SECLEVEL=1

It may be required to comment out similar lines in the config if they already exist.