Has anyone tried a full re-implementation of the firmware?

[emileb]

Having full source code would be amazing. If we have the full circuit diagram it would be that difficult to fully re-implement the functionality do you think?

[HSPDev]

@emileb It's a crazy project but I've just bought the scooter and will begin the work myself also.. As I see the current patcher here it works by searching/replacing values in the official files and ensuring the result still passes basic Xiaomi checks. Good thing they haven't implemented real digital signatures....

The code that can replace ASM (Assembly code) parts of the resulting output files (I assume for the "russian throttle") gives me hope.

I'm doing this because I would like to be able to hack a speed changing algorithm into the product so it can be street legal and pass all possible tests, but still have "hidden" boost available for private areas.

Stupid laws....

[emileb]

Nice idea :) Yes happy to help out if you need any, I'm a FW engineer and have implemented brushless motor control before. We need to find a complete and accurate schematic somehow.

[BotoX]

complete and accurate schematic: https://electro.club/data/users/3971/files/Driver_v1.4_3.JPG

[HSPDev]

@emileb Do you want to take the approach of reverse engineering the entire diagram and then write software for the chip? I assume @BotoX attacked the firmware files by diffing them in HEX/binary mode, and then looking for different values and some good old guess work combined with hunches and some knowledge of Assembler?

As far as we know (Botox primarily?), have they used lots of libraries and includes that would obfuscate the code during disassembly?

Having looked into the issue I'm almost partial to projects that replace the stock controller, as the motorcontroller itself is another device. I'm also currently being curious about what TIER, Voi, Bird and other rental companies do, cause it seems like the utilize the stock locking mechanism in Copenhagen (where it blinks when moved) and in general keep most of the things reliatively "stock". I assume that would include some kind of custom software job.

[BotoX]

Bird and the other companies just replace the BLE board with their own.

Disassembled Microcontroller firmware is obfuscated enough as is lol, it's almost guesswork with so little information in the assembly.

If the man can get the motor spinning then I can probably implement the rest (communication, etc.). I have no clue about motor control though, it seems like a lot of math that also depends on motor parameters that I can't even measure.

[HSPDev]

Bird and the other companies just replace the BLE board with their own.

Forgive my ignorance (got my M365 yesterday). How is the topology of the boards? We have a BLE board (I assume Bluetooth Low Energy), and we have a battery/charging circuit and we have a motor controller (which seems to be somewhat generic a.k.a. e-bike-like).

I'm curious - You mean Bird only replaces the communications module? When we perform a firmware upgrade, is it going into the BLE module, motor controller, charger controller, or somehow split up between them?

I'm just trying to grasp the high level functioning of the scooter, and you @BotoX seem to be the most knowledgeable guy on the entire internet (I can understand you are active at rollerplausch too?).

[BotoX]

The module at the top (where the power button is) is the BLE, it has an NRF n51822 MCU and runs upgradeable firmware. The BLE communicates with the ESC / DRV over single wire UART. The DRV has an STM32F103C8T6 MCU that also runs upgradeable firmware. The DRV is the heart and runs the motor, this project patches the DRV firmware. There is also some STM8 in the BMS that also has upgradeable firmware, but we don't really care about that one since it just protects the battery and gives us a few stats over UART.

The charger is the external brick, it's a simple CC/CV PSU. I'm an admin at rollerplausch yeah.