Programming GD32F407xx (robotic lawn mower)

[Greg J]

I have a device that I'm "hacking" based on a GD32F407xx ARM microcontroller. Does anyone know if this is just a Chinese knock-off of the ST?

The circuit also has an SPI flash, 32MB flash, which is quite surprising. I haven't examined it yet. It's 25Q32ESIG. I do wonder what they use it for.

However, I would like to be able to reprogram this device. It has a port at the bottom labeled OSBDM, which seems like an obvious place to start. Are there any other ways I could go about it? I don't want to spend £500 on tools just to be able to experiment.

This device is a cheap robotic lawn mower. It has FT1128Q motor drivers, which seem to just take PWM signals, with op-amps interfacing the microcontroller and the drivers. Overall, it's a simple device.

They left parts of the board for vision and BT/GPS components, but those were never populated. Interestingly, there's also a section for ultrasonic sensors, which is also unpopulated.

I bought this for £50 as "broken" "for parts," even though the board seems to work. I'm keen to play with it as a cheap hacking project. Any help is appreciated.

Here's a picture of the whole board for reference, before and after removing the potting.

[Doctorandus_P]

The GD devices are very similar to their STM32 counterparts. Enough so that binary images apparently mostly work, but I would nut trust on them being identical, and apparently you can also use the same programmers most of the time. If you want to know, then compare datasheets.

For myself, I've decided to mostly stay with STM32, as I have very little appetite for spending time on figuring out what the exact differences are.

[Greg J]

@Doctorandus_P It's a pre-made board. So whilst I could just replace that whole ARM thing with rp2040 or esp32, first I want to try just reusing it as is.

[ataradov]

Your first goal should be to identify the SWD pins and check if the device is locked. If it is, then the only way to reuse that board is to replace the IC.

Otherwise, devices are very similar to ST parts, but actually a little bit more performant in some cases because of their memory architecture.

[Greg J]

the device allows for software updates via USB, a it turns out - so i don;'t think the arm chip is locked down

[ataradov]

There is no native USB bootloader in that device, so it would be something proprietary. And if they dome their job right, then the firmware would be encrypted and/or signed so that you won't be able to flah anything you want. EDIT: Actually there is a USB bootloader, so you need to check if they are using that or something proprietary. The native bootloader is not really useful for production, since it requires  assertion if the pin. If your update instructions do no include pressing a button or something like this, then it is not likely that they are using the native bootloader.

Locking of the programming interface does not prevent firmware updates via a bootloader.

[Greg J]

from the instructions:


4. Turn off the robot mower at the switch underneath and place it upside down on a clean, soft surface. Now is also a good time to perform any routine maintenance such as checking and replacing blades. 

5. Using a cross-head screwdriver, remove the screws from the battery compartment in the deck of the mower. 

6. Turn the mower back on at the switch and wait for two beeps. 

7. Insert the USB flash drive and listen for 4 beeps. All time setting lights on the control panel will flash green. The program is installing. Do not remove the USB stick while the program is installing. This may result in damage to your mower.

8. When the update is finished (this may take several minutes), the mower will beep continuously. The flash drive can now be removed. The mower will beep twice indicating that the software update is complete. 

So in short, no buttons required.

[ataradov]

7. Insert the USB flash drive and listen for 4 beeps.

This is a custom bootloader. The native bootloader is a simple serial interface, it does not support USB flash drives or anything like that. And it certainly does not beep.  There is a good chance that device is locked.

Do you have an example of the firmware update binary they distribute?

[Greg J]

I do, and it comes in two files.
https://www.cleva-uk.com/pages/product-support/lawn-master-l-10-robot-lawn-mower-up-to-400-m-2

Which is weird. I ran strings on both files, they left all debugging symbols behind, it seems.

I do not know how to disassemble stuff for this particular microcontroller, hence question here Crowdsourcing, I suppose.

[ataradov]

Those are just raw ARM binaries with no headers. They do seem to have some sort of CRC at the end, so some amount of checking is still there.

I don't know why they need two images. L10_1.0.0.2.bin is mapped to the main flash starting at 0x08000000. And randomMower.bin is mapped to 0x00000000, which normally would be the alias for the same 0x08000000 address.

But all this certainly opens up a path to the custom firmware. I would still find the SWD and don't bother with the USB stuff. Given that firmware is distributed in the open, I don't see SWD being locked.

[Greg J]

what did you use to check out that this is standard arm?
I did ran it through usual Ghidra workflow, but it seems for these sorts of things I need to give it memory map. And having two files also threw me .

What I want to look for is the ability to control this remotely, using esp32 or such via bluetooth. Was hoping it will have some sort of a debugging console open, since the firmware seem to have some or all debugging symbols on!

I don't know why they split it into two. My only guess is to be able to flash it in parts? One part first, then the other?
who knows.

[Greg J]

There's a serial bus port on the board, so I plugged that in and put firmware update in the USB port. And this popped in the serial console:

Code: [Select]


start usr app jump
UpdateFlag :0
detect RM FW
RM Ver:1002 762
boot Flag 1

start MAIN board download
 ##### USB Host library started #####
 > Device Attached.
 > Reset the USB device.
 > Full speed device detected.
 > VID: 0781h
 > PID: 5595h
 > Mass storage device connected.
 > manufacture string is : SanDisk
 > product string is : Ultra USB 3.0
 > Serial Number string is : <redacted>
 > Enumeration completed.
 > To see the disk information: 
 > Press User Key…
 > Flash programming BAK ON GOING         
 > DOWNLOAD ON GOING                     
 > DOWNLOAD DONE                         
 > Flash programming BAK DONE             
 > DOWNLOAD ON GOING                     
 8020000
 8028000
 8030000
 8038000
 8040000
 8048000
 8050000
 8058000
 > DOWNLOAD DONE                         

restart
úboot Flag 0

start usr app jump

start usr app jump
boot Flag 0

start usr app jump

start usr app jump
boot Flag 0

start usr app jump

start usr app jump
[/tt]

[ataradov]

what did you use to check out that this is standard arm?

My eyes. All Cortex-Mx binaries start with the initial SP value, which would be somewhere in the SRAM address range, followed by the reset handler address and the rest of the vector table. Each entry in the table would be in the Flash address range.

I don't know why they split it into two. My only guess is to be able to flash it in parts? One part first, then the other?

No idea, it would be hard to tell without extensive reverse engineering.

[Greg J]

The board also has SPI 32MB of flash, I wonder what is that used for!
Surely the microcontroller has built in memory, and that's what the software update is for.

[ataradov]

It may be used for storing data about boundaries of your lawn and what was recently mowed or whatever robotic lawnmower needs to store.

[darkspr1te]

I quickly loaded it into ghidra, (arm 32 8thumb little endian ) used svd-loader to setup memory and peripherals ( i just used a svd file from the cmis svd collection online)


it would be easy to patch this file to dump the entire flash to uart, just edit the jump vector at the start to jump to super basic code that reads flash=0x0 and puts into uart, counts to 100 then add 1 to flash address and repeat until past 0x20000 , if you capture fia serial port using something like Realterm you can save as a bin and then import into ghidra
by the time this app code is run the uart and clocks are setup so you wont need to do that.
attached is a file i made to do that for the gd32f103 clones,
this is how it it works , in folder is the file stm32.ld and in that is the boot address where this code would start from,
Code: [Select]rom (rx)  : ORIGIN = 0x08006000, LENGTH = 242K
and if we look at the compiled rom at 0x6000 we see the stack address & reset entry vector of 0x8006231
now say if your device app boots at 0x02000 (yours actually boots at 0x20000 )
what we would do is goto the firmware file , add 0x02000 to the address and find the real 0x6000 we then delete the code after that and paste our new uart bin file there(we need to remove the blank data from 0x0 to 0x5FFF from the uart.bin) , we then go to the start of out new firmware patch file and set the new stack and entry to match our bin file (the first 8 bytes, stack and reset)
so effectively we are telling the patched firmware to jump to our new code and dump the whole flash to the serial port.


there are issues with this,
if the bootloader is activated by the application only you might not get back into it unless it one that see's the usb flash+file and just flashes, this leads onto issue two that if there is a crc check of any sorts it may fail to update with the patch or the original file.


if you attempt to dump via the SWD pins a word of caution, some Openocd tcl files will unlock you mcu when it connects, if the protection level is on 0 then it will erase the mcu for good. Stm32 cube programmer does not do this but warns you it's locked and wont read.


there is a list of ways the protections on gigadevices can be broken, look for the pdf gigivulnerability at offzone.moscow
a example is on the f405 model you can dump flash to uart via setting up dma to read flash, another trick is to load your dump code into sram then using a pi-pico to control reset and boot0/boot1 you can trick the system into running code from sram even at rdp 2




darkspr1te

[darkspr1te]

small update,
if you goto
https://gd32mcu.com/en/download/7?kw=GD32F4
and download the add on pack which will give you 3 files , then you can extract with 7zip and in the debugger folder is 
GD32F4xx.svd
load this into svd-loader in ghahidra and it will setup all the calls to device like can,uart, rcc etc and will make reverse engineering so much easier.
you can use the header files to patch the sample source uart code i provided to change to the correct address for each device,

[darkspr1te]

attached is a ghidra zip file with many functions now labeled.
remove the last .zip from it so the extention if gzf and import into you ghidra.


darkspr1te
 

[Greg J]

Amazing work darkspr1te, I'll be looking at it after work.
I can see that they have a lot of debugging strings in the firmware - so all I wanted to do initially is to just display that over serial.
I'm surprised quite complex the code is for a mower that is rather dumb. It allows mowing once a day (or every two days), for N number of hours, and bounces around randomly within wired bounds. Not super complex, you'd think.
But, if I could control it over ESP32 or something, not just get logs - that would allow me to leave their state machine in tact and add some "smarts" to it.

Or just replace the ARM chip with ESP32 to control whole thing, once I figure out which PIN does what.

They obviously made a lot of provisions for vision and ultrasonic sensors on the PCB - but never implemented it in firmware.
Likewise, PCB has provisions for GPS/Bluetooth chip (probably similar to ones in "smart" power sockets) - but it has never been implemented.

[darkspr1te]

New updated rev engineering of the bin file,
there must also be another cpu as the other file is for a NXP cpu
extract to folder and then use import function in main gahidra project menu.




darkspr1te

[Greg J]

yes, I noticed in strings references to NXP and their RTOS.
So is your suggestion that the two files are the same source but different CPUs?
I got 3 of these machines, because you can buy them relatively cheap "for parts" on eBay. One of them is never to be opened for hacking, as it is doing the actual job - but the other two don't have NXP cpu in them. So I don't know how many they released. I might be tempted to buy another one, but then - this might end up in a divorce

[Greg J]

SPI flash (32Mb/4MB) uses about 512 bytes to store settings. That's it!
I'm going to try using hydrabus to do JTAG dump. Wish me luck, I never used it for this use case.

[rodrigueza]

If the two files you mentioned are indeed sourced from the same origin but designed for different CPUs, what specific considerations should you take into account when attempting to modify or hack the firmware?