BM2 - Dumping and modifying the battery monitor firmware
Part 4 of the battery monitor series - Two methods to obtain the firmware from the hardware for analysis and modification
This post is a continuation of the research into the BM2 Battery Monitor product which was found to be covertly collecting a significant amount of location data. In this post we will look at two ways of obtaining the firmware from the physical device.
Other pages in this series:
- Part 1 - Introduction
- Part 2 - Reverse engineering the AMap SDK location tracking features
- Part 3 - Reimplementing BLE functionality
Dumping flash from the device
The SoC is a Texas Instruments CC2541 MCU. According to the documentation, a custom debug protocol is supported and requires a minimum of five connections. Fortunately the battery monitor board sports an unpopulated header with exactly five connections:
According to the documentation, if the device is powered externally, the following is required: Vdd (reference voltage) Ground DC (Debug Clock) DD (Debug Data) RESET:
Using a multimeter in continuity mode, each exposed pinhole can be tracked a pin on the integrated circuit:
And finally marked on the board:
Wiring everything up to the CC-DEBUGGER and hitting the reset button, a green light indicates all systems go:
It appears that the latest versions of the
Texas Instruments Smart-RF Studio no longer supports the CC series SoC versions that use the Intel 8081 instruction set as this has been succeeded by ARM. Fortunately, an older version can be found on Github here. I have also taken a copy incase this repository goes down. You can find it here.
Using the older version of Smart-RF Studio, the CC2541 is detected and the flash can be dumped out of the device:
The emitted file is in Intel HEX format which can be converted into a binary blob using this tool.
Intel Hex is a simple format using ASCII encoding. I have marked it’s format for readability:
An easy test for reflashing modified firmware would be to change the advertised device name in the BLE beacon to something arbitrary. Locating the current device name:
Changing the string, a new checksum needs to be calculated. This calculator was used.
After reflashing using Smart RF Studio with the CC-DEBUGGER, we can see the new device name being advertised. Here [nRF Connect ]](https://play.google.com/store/apps/details?id=no.nordicsemi.android.mcp) is being used as a BLE scanner:
OTA Firmware
The app supports over the air updates with a REST API that provides a download link to the latest firmware.
The bm2 cloud APIs will happily provide us latest firmware from their service if we provide an outdated firmware version. In the meantime I have ordered a CC Debugger to test this interface and see if we can pull the firmware off directly. For those intereted in obtaining the OTA firmware:
A HTTP POST to api.quicklynks.com:8080/v1/versionInterface with the parameter vm with value of 7 or less will return the full endpoint to obtain the latest firmware in the url field.
curl http://api.quicklynks.com:8080/v1/versionInterface? -d 'method=queryFirmUpgrade&vm=8&ptype=batterymonitor2'
A subsequent request to the value in url:
FileParseUtil.parseHexFile in the decompilation offers insights into the firmware format.
com.dc.battery.monitor2.ble.upgradehex in the decompilation The 8th and 9th byte in the firmware image specifies the total size:
dd if=bm2-firmware.bin bs=1 count=8 2>/dev/null | xxd
00000000: 4e35 ffff 1000 007c N5.....|
>>> 0x7c00
31744
>>> 7936.0 * 16
126976.0
$ wc -c bm2-firmware.bin
126976 bm2-firmware.bin
More work is required to reverse the format which may be done done at a later time.
