Xiaomi Smart Speaker

[phodina]

Hi @Ralim,

thanks for the tool. I've recently bought the Xiaomi Smart Speaker and peeked under the hood.

The hearth of the device is BES2300 and after looking on the internet I found this repo.

So I soldered the wires for UART, dumped the init sequence to learn it runs NuttX.

The I used your tool to attempt to dump the firmware off the board.

Could you please help me as the file is not dumped but it appears the device enters into the bootloader?

https://gitlab.com/phodina/xiaomi-mi-smart-speaker

[phodina]

Also how did you obtain the programmer.bin file?

[shymega]

This tool is intended for the PineBuds Pro, but there's no guarantee this tool will work on other BES devices.

The programmer.bin was dumped from the official BES flashing utility. We use that to boot the chip into a programming ROM.

I'm working on my fork on splitting bestool into two crates - one bestool binary, and a beslib crate, which might be able to support this smart speaker in future.

The PineBuds don't use NuttX, but instead a different RTOS.

[Ralim]

Also how did you obtain the programmer.bin file?

It is the programmer2300.bin file from the windows programming tool from bestechnic.
I was the programming tool and oh boy was it clunky. It does not support reading the firmware at all. The code path used for reading the firmware is a "memory dump" command I found in the programmer.bin via Ghidra. It is not designed to dump the firmware. As such it doesnt do things like re-set the watchdog. So if your runtime firmware has configured the watchdog to expire really quickly; it will cause havok.

The runtime code wont matter for how this software works; as we are loading the programmer into ram and booting it.

I've tested locally on 3 revisions of the bes2300; however there are lots.

Any chance you can get a logic analyser capture of the uart bus during the boot + run firmware?
If not; could you get a timestamped raw hex read of the bus somehow?

bestool needs some cleanup to handle errors more clearly, but it looks like your chip may just be hard crashing after we ask it to run the ram code. I intend to do a cleanup pass on bestool soon -- just been too busy. But maybe this is the motivation I need.

Any chance you can crapture a higher resolution closeup of the beschip; as a quick look indicates this is a different spin of the chip.

[phodina]

This tool is intended for the PineBuds Pro, but there's no guarantee this tool will work on other BES devices.

The programmer.bin was dumped from the official BES flashing utility. We use that to boot the chip into a programming ROM.

I'm working on my fork on splitting bestool into two crates - one bestool binary, and a beslib crate, which might be able to support this smart speaker in future.

The PineBuds don't use NuttX, but instead a different RTOS.

Sure, I was just wondering if it would be possible to also to use it. I also have the PineBuds so that's why I knew about this tool.

I guess it does not really matter what firmware runs there. The point is to be able to enter the bootloader and dump/flash new firmware there.

Reverse engineering the firmware might help with porting to this platform.

For start the login credentials would help - not sure if they are hardcoded in the firmware itself or computer from e.g. Serial Number.

I'll check also the official BES flashing utility

[phodina]

Also how did you obtain the programmer.bin file?

It is the programmer2300.bin file from the windows programming tool from bestechnic. I was the programming tool and oh boy was it clunky. It does not support reading the firmware at all. The code path used for reading the firmware is a "memory dump" command I found in the programmer.bin via Ghidra. It is not designed to dump the firmware. As such it doesnt do things like re-set the watchdog. So if your runtime firmware has configured the watchdog to expire really quickly; it will cause havok.

Okay, not sure if it does enable the watchdog as I don't have the firmware. But it might be possible to get it as the only way to update the speaker is Bluetooth OTA. So I could capture the binary. However, it will take me some time to setup.

The runtime code wont matter for how this software works; as we are loading the programmer into ram and booting it.

I've tested locally on 3 revisions of the bes2300; however there are lots.

Could you share what devices/evaluation boards did you encounter?

Any chance you can get a logic analyser capture of the uart bus during the boot + run firmware? If not; could you get a timestamped raw hex read of the bus somehow?

Here's the hex dump from Analog Discovery 2. hex dump

bestool needs some cleanup to handle errors more clearly, but it looks like your chip may just be hard crashing after we ask it to run the ram code. I intend to do a cleanup pass on bestool soon -- just been too busy. But maybe this is the motivation I need.

I just build the tool so I'll also check the code.

Any chance you can crapture a higher resolution closeup of the beschip; as a quick look indicates this is a different spin of the chip.

What do you mean? Closeup picture of the text on the SoC?

[phodina]

I assume the firmware is in the internal flash so dumping the code off the chip (like desoldering emmc) is out of the question, right?

Is it possible to use JTAG/SWD? Not sure what are the TPs or if the fuses are burnt but might help us if there's support in OpenOCD.

[gamelaster]

Nobody got JTAG working on BES2300 yet (afaik)

[Ralim]

Could you share what devices/evaluation boards did you encounter?

1. Pinesound dev board
2. Little Whale dev board
3. Pinebuds

Of which (2) has a different silicon rev compared to the others; and works better with one programmer.bin compared to the others. Even though the markings on the top of the chip are the same.

Here's the hex dump from Analog Discovery 2. hex dump

Is it possible to get a timstamped log?

What do you mean? Closeup picture of the text on the SoC?

yeah, just a closeup of the test (or a transcribe).

I assume the firmware is in the internal flash so dumping the code off the chip (like desoldering emmc) is out of the question, right?

Yes, I suspect there is an SPI flash die inside that holds the firmware and that is linked to a processing die.

Only way I know of to dump firmware is via the ram running code; I havent gotten stable JTAG/SWD to come up. I think I got a probe once but never stable :/

[phodina]

@Ralim here's the closeup image of the BES2300
https://gitlab.com/phodina/xiaomi-mi-smart-speaker/-/blob/ee5798bf4402029dcb71ab316f704cd21e2b8ce7/media/BES2300_Microscope.bmp

[Ralim]

Thank you.
Yeah okay good, wanted to check and be sure it wasnt a bes2300Y or bes2300YP.

I think a timestamped log / uart capture would be good. I'll also try and improve logging when I get a chance :/

[fantomgs]

Could you please help me as the file is not dumped but it appears the device enters into the bootloader?

You don't need a programmer.bin binary to dump a FW, you just need to strip from bestool the code related to upload programmer.bin and fix the address of flash from 0x3C00_0000 to 0x2C00_0000. Seems like a bootrom or a FW startup code have a support of this functionality without a programmer.

[fantomgs]

Here I posted a link to firmware and boot log from my L05B speaker duhow/xiaoai-patch#19

[fantomgs]

It looks like a format of binary code (uploaded by command 0x54) is pretty simple:

struct {
  uint32 entry;
  uint32 param;
  uint32 sp;
  u8 code[];
}

After receiving 0x55 command, bootloader will execute an uploaded code by setting stack to "sp" (if "sp" is non zero) and calling "entry(param)".
For example, if you uploading the code to RAM address 0x20001000 then you need to set "entry" value to 0x2000100D 0x0020100D (pointed to "code" body).
upd. Memory region RAMX @ 0x00200000 is mapped to RAM @ 0x20000000 but also have eXecution allowed.
upd2. Bootrom in BES23000 has restrictions for uploading code address: code_addr >= 0x20001960 && code_len + code_addr < 0x2003F000

[Ralim]

This is fantastic information.

I don't currently have a lot of time to work on this sadly, but ide gladly accept any PR's or further information you have 🤞