Recently I got the itch to take something apart and modify it in an externally noticeable way. First I started looking at my sons toys as a source of equipment to modify, one specifically caught my eye. It was a leapfrog globe that was intended to teach kids about different continents, countries and oceans on planet Earth. I am still looking at modifying this toys firmware but it is going to require some equipment and skills that I have yet to acquire, so I put it back together and switched gears, aiming my sight at my wife’s Oxford 3 Rower. It is expensive, and not mine so consent is always paramount in these situations, and after having obtained it I began by unscrewing the four screws on the back of the control panel.
This exposed the rear of the front face where two connectors needed to be removed in order to relocate to my desk for further investigation.
Process
I started simply by searching for information regarding the chips that I could see on the board, mainly looking for datasheets to help me better understand what to target for firmware modification.
Chip Information
- EFM32G232F128G
- ARM Cortex-M3 @ 32 MHz
- Data Link
- HT1625
- RAM Mapping 64×8 LCD Controller
- Data Link
- HCT14
- Hex Schmitt-Trigger Inverter
- Data Link
Having noticed the ARM chip I really wanted to know where the firmware for it was stored. With MCU’s like this it seemed to me it could be on a SPI part or stored on device, and after looking around a bit for anything that looked like a memory without luck so I figured the likely option was it would be stored on the MCU itself. Lucky for me it appeared that a debug header (likely used for flashing the firmware in production) was left on the device. If you look closely at the traces for that header you can see that two of the pins go to the upper right of the chip, and in the datasheet sure enough those are debug ports!
A bit of multi-meter probing later and I had a basic pinout for this debug header!
After some searching I learned I would need a debugger for this, which is available here. Looking at that page now I see someone has had an issue with the device, but it worked seamlessly for me on this project, so buy at your own risk.
Now, it is important to mention, if you are following along, that the flash on this chip is read only when you receive it from the factory and unlocking the flash region of the chip will erase it. So it is of utmost importance that you first read the flash region to a file before attempting a write back or unlocking it. I nearly erased this part without having a binary file — luckily I had read the memory to a file to disassemble it before and had saved it to my file system…
Some other things that you will need:
- pyOCD
- Python based tool and API for debugging, programming, and exploring Arm Cortex microcontrollers.
- EFM32 DFP
- Simply install this with pyOCD on the command line
pyocd pack install EFM32G232F128- A Hex Editor Software
- For this I used Visual Studio Code with the Hex Editor extension
Once you have that all setup and your debugger wired to the target board and plugged into your PC we get to start exploring things. Lets start by building our safety and reading the flash memory to a file. To enter our live shell run:
pyocd cmd -t EFM32G232F128Once in the shell run:
show mapThis will tell you the layout of your chips memory (because mine is unlocked it looks a bit different than the one you likely see)
What you want to note is the ‘Flash’ type, this is where the main program usually resides on any given MCU, from this you will need the start and size values. So lets go ahead and backup this information by simply running the following from our shell with the values we have:
savemem <Start> <Size> oxford3rowerfirmware.binInspecting the Binary
Binary inspection is something I have done in the past when I was a kid using other peoples tools, after having attended university for CS I have a better understanding of how these binaries are produced — but I still use other peoples tools :). I started by using Ghidra to look at the disassembled assembly code, but this is unnecessary for the small modification we will be making.
Speaking of, in this article we will be focused on simply changing strings in the firmware. One thing I wish we had the ability to change is the default usernames — in the firmware they are simply ‘User 1’ through ‘User 4’, this makes it difficult to remember who you are when you are sharing the rower with your family. So lets just do that, change the users strings to something more meaningful.
If you are using Visual Studio Code with the hex editor extension simply open the binary you have stored in Visual Studio Code and search for the string ‘User 1’ this should take you to the location of the string we want to replace:
It is a good idea to make a copy of this file as backup before making modifications. When ready double click the ‘U’ and type out a name that fits in the same number of characters as ‘User 1’ with a space after. Save it and now we have something we can flash onto the chip.
This is where we get to the irreversible space, after the next required step the MCU will have non-bootable firmware. In fact the next command will completely erase what is on there in order to make it writable. From the shell run:
THIS IS IRREVERSIBLE, BE SURE YOU FOLLOWED THE STEPS TO BACKUP YOUR FIRMWARE AND PROCEED AT YOUR OWN RISK
unlockAt this point your chip should be erased, you can confirm this by reading a 32 bits of memory from the base of memory:
rd 0x0This should result in a read of all F’s for this MCU that signifies the flash memory is erased.
As the final step we need to run the command that will flash our new desired firmware onto the device:
loadmem 0x0 <Filename>.bin
If all went as it did for me you now have modified firmware on your device! Simply unplug the power and plug the power back in hit the power button and cycle through the users to see your changes!
Thank you for reading, please feel free to leave a comment below with any other modifications you dare try!