manawyrm
Themenstarter
Hi,
ich beschäftige mich zur Zeit mit einem Panasonic / Flyer 36V Akku (Flyer NKY434B2).
Ähnliche Akkus wurden vor kurzem von @gamerpaddy auseinandergenommen: (Moin, so klein ist die Welt
)
Teardown & Reparatur: Panasonic "Flyer" NKY352B2 36V 12Ah Akku
und der Nutzer @verlierer hat schon sehr gute Schritte gemacht um den Akku genauer zu verstehen:
suche Pinbelegung von Flyer/Panasonic Akku (3d-druck...)
Ich möchte an dieser Stelle einmal alles dokumentieren, was wir bisher über das Protokoll herausfinden konnten, was versucht wurde und Tipps, wie andere weiter an der Hardware arbeiten können. Die nachfolgenden Infos habe ich auf Englisch geschrieben, damit auch ein internationaler Besucher diese Info finden und nutzen könnte.
Wenn noch jemand Infos hat, Vorschläge wie wir die Firmware dumpen könnten, oder Ideen, wie sich die 20byte Challenge-Response zusammensetzt, immer her damit
An die Community: Ich wäre sehr an zusätzlicher Hardware mit dem 36V Protokoll interessiert.
Soweit ich weiß, wurde das unter den Marken Victoria, Kalkhoff, Rahleigh, Flyer, Kettler und Panasonic verkauft.
Sollte hier jemand noch defekte 36V Akkus, Ladegeräte oder Motoren haben, würde ich mich über eine Spende dieser Hardware sehr freuen (Versandkosten übernehme ich, bitte PN!), weil ich aktuell nur den einen Satz echter Hardware (an meinem Fahrrad) habe.
MCU: Renesas M37512
General information:
9600baud half-duplex UART 8n1, uses Pin 3 with -42V as idle voltage (use 5.1V z-diode and 10k resistor for RX, BC337 or similar NPN to TX)
(to work on the BMS just solder pins to the MCU directly, it's easier and UART levels already)
Packet format:
2 byte preamble (always 2x FF)
1 byte length (not including preamble, length, command and checksum)
1 byte command
n byte payload data, varying length
1 byte checksum = ((0x100 - sum of data bytes) & 0xFF)
Known commands:
B2 - Source: Charger | Destination: Battery - Request challenge response
D2 - Source: Battery | Destination: Charger - Answer challenge response
C2 - Source: Bike | Destination: Battery - Request challenge response
E2 - Source: Battery | Destination: Bike - Answer challenge response
C4 - Source: Bike | Destination: Battery - Request status information
E4 - Source: Battery | Destination: Bike - Answer status information
Example packets, charger sending Challenge-Response to battery:
Q:
R:
Q:
R:
Q:
R:
Q:
R:
Bike to battery information request:
Q:
R:
Payload data:
0294 Temperature in °F (dec x10, 66.0°F)
50 State of Charge (in percent, decimal, 80%)
0E6F Voltage (dec /100, 36.95V)
Information about the Challenge Response:
We've collected a sample of ~200000 challenge-response answers for specific bit patterns from a real battery. The answers are always completely different, even with only a single bit change. Together with the fact that the response is 160 bit aka 20 bytes in length, I fear that we are dealing with a SHA-1 hash.
That's pretty bad, because that isn't going to be possible to crack (without dumping the firmware somehow).
Dumping the firmware:
The controller has a special boot rom which can be activated by shorting 3 pins together (with resistors). In this mode the controller can be spoken to with I2C/SMBus.
Some laptop batteries use the same Renesas controller. There is this Python project:
dex6/m37512_reset
which uses the correct I2C address (0x0b). Our Flyer NKY434B2 replied at this address as well, but NACK'ed every further transactions.
There are 2 other tools, one commercial utility called BE2Works (which tried to talk to the battery at 0x16, which is the wrong address) and another DIY project written in C called SMBUSB (karosium/smbusb ). The SMBUSB tool also tries to use address 0x16, so it didn't work.
I suspect we need some sort of authentication for the boot rom to be willing to talk to us. Similar Renesas controllers require a 16 or 32-bit I2C write with a secret before you can issue the commands listed in the datasheet.
Safety tips:
To work on the BMS safely we've built a resistor ladder construction using 10x 1k resistors. Every resistor provides 1 cell voltage and is connected to the appropriate input on the BMS. The whole BMS + resistor ladder is connected via a ballast (4x 12V halogen lamps for me). A current limited supply would be ideal, but we didn't have something with the required voltage.
To enable the BMS after a complete power loss, you need to emulate a charger. To do this, apply 5V to pin 5 aka "T". In my testing the first battery voltage from the resistor ladder (4.1V) via a 120 Ohm resistor also works well.
If you're running in the normal firmware, just applying the signal shortly boots the MCU which (after a self-check) will hold the pin on it's own.
If you're running in the boot ROM, the pin needs to be connected permanently to keep the MCU powered up.
Further work:
I didn't look at either the real charger or the real bike yet. Everything so far was only done by looking at the battery and protocol dumps provided by @verlierer. Thanks a lot!
Viele Grüße,
Tobias
ich beschäftige mich zur Zeit mit einem Panasonic / Flyer 36V Akku (Flyer NKY434B2).
Ähnliche Akkus wurden vor kurzem von @gamerpaddy auseinandergenommen: (Moin, so klein ist die Welt
)Teardown & Reparatur: Panasonic "Flyer" NKY352B2 36V 12Ah Akku
und der Nutzer @verlierer hat schon sehr gute Schritte gemacht um den Akku genauer zu verstehen:
suche Pinbelegung von Flyer/Panasonic Akku (3d-druck...)
Ich möchte an dieser Stelle einmal alles dokumentieren, was wir bisher über das Protokoll herausfinden konnten, was versucht wurde und Tipps, wie andere weiter an der Hardware arbeiten können. Die nachfolgenden Infos habe ich auf Englisch geschrieben, damit auch ein internationaler Besucher diese Info finden und nutzen könnte.
Wenn noch jemand Infos hat, Vorschläge wie wir die Firmware dumpen könnten, oder Ideen, wie sich die 20byte Challenge-Response zusammensetzt, immer her damit
An die Community: Ich wäre sehr an zusätzlicher Hardware mit dem 36V Protokoll interessiert.
Soweit ich weiß, wurde das unter den Marken Victoria, Kalkhoff, Rahleigh, Flyer, Kettler und Panasonic verkauft.
Sollte hier jemand noch defekte 36V Akkus, Ladegeräte oder Motoren haben, würde ich mich über eine Spende dieser Hardware sehr freuen (Versandkosten übernehme ich, bitte PN!), weil ich aktuell nur den einen Satz echter Hardware (an meinem Fahrrad
) habe. MCU: Renesas M37512
General information:
9600baud half-duplex UART 8n1, uses Pin 3 with -42V as idle voltage (use 5.1V z-diode and 10k resistor for RX, BC337 or similar NPN to TX)
(to work on the BMS just solder pins to the MCU directly, it's easier and UART levels already)
Packet format:
2 byte preamble (always 2x FF)
1 byte length (not including preamble, length, command and checksum)
1 byte command
n byte payload data, varying length
1 byte checksum = ((0x100 - sum of data bytes) & 0xFF)
Known commands:
B2 - Source: Charger | Destination: Battery - Request challenge response
D2 - Source: Battery | Destination: Charger - Answer challenge response
C2 - Source: Bike | Destination: Battery - Request challenge response
E2 - Source: Battery | Destination: Bike - Answer challenge response
C4 - Source: Bike | Destination: Battery - Request status information
E4 - Source: Battery | Destination: Bike - Answer status information
Example packets, charger sending Challenge-Response to battery:
Q:
FF FF 14 B2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3AR:
FF FF 14 D2 F9 33 FF A6 C6 6B 39 26 EF 82 BB 6E DF 63 08 05 8E 96 96 D2 44Q:
FF FF 14 B2 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 39R:
FF FF 14 D2 AE F8 49 86 53 4C 41 87 2D 67 CD 74 5D 91 5E 72 79 6A CD C4 37Q:
FF FF 14 B2 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 96R:
FF FF 14 D2 58 3A EE ED C2 F5 C3 B3 95 72 F7 00 25 3A D7 4F 76 C1 2B 96 05Q:
FF FF 14 B2 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA F2R:
FF FF 14 D2 AB 01 C4 32 24 1D EF 96 57 5E 7F F0 8A 67 E8 71 7D 16 E3 E6 E8Bike to battery information request:
Q:
FF FF 00 C4 3CR:
FF FF 05 E4 02 94 50 0E 6F B4Payload data:
02 94 50 0E 6F0294 Temperature in °F (dec x10, 66.0°F)
50 State of Charge (in percent, decimal, 80%)
0E6F Voltage (dec /100, 36.95V)
Information about the Challenge Response:
We've collected a sample of ~200000 challenge-response answers for specific bit patterns from a real battery. The answers are always completely different, even with only a single bit change. Together with the fact that the response is 160 bit aka 20 bytes in length, I fear that we are dealing with a SHA-1 hash.
That's pretty bad, because that isn't going to be possible to crack (without dumping the firmware somehow).
Dumping the firmware:
The controller has a special boot rom which can be activated by shorting 3 pins together (with resistors). In this mode the controller can be spoken to with I2C/SMBus.
Some laptop batteries use the same Renesas controller. There is this Python project:
dex6/m37512_reset
which uses the correct I2C address (0x0b). Our Flyer NKY434B2 replied at this address as well, but NACK'ed every further transactions.
There are 2 other tools, one commercial utility called BE2Works (which tried to talk to the battery at 0x16, which is the wrong address) and another DIY project written in C called SMBUSB (karosium/smbusb ). The SMBUSB tool also tries to use address 0x16, so it didn't work.
I suspect we need some sort of authentication for the boot rom to be willing to talk to us. Similar Renesas controllers require a 16 or 32-bit I2C write with a secret before you can issue the commands listed in the datasheet.
Safety tips:
To work on the BMS safely we've built a resistor ladder construction using 10x 1k resistors. Every resistor provides 1 cell voltage and is connected to the appropriate input on the BMS. The whole BMS + resistor ladder is connected via a ballast (4x 12V halogen lamps for me). A current limited supply would be ideal, but we didn't have something with the required voltage.
To enable the BMS after a complete power loss, you need to emulate a charger. To do this, apply 5V to pin 5 aka "T". In my testing the first battery voltage from the resistor ladder (4.1V) via a 120 Ohm resistor also works well.
If you're running in the normal firmware, just applying the signal shortly boots the MCU which (after a self-check) will hold the pin on it's own.
If you're running in the boot ROM, the pin needs to be connected permanently to keep the MCU powered up.
Further work:
I didn't look at either the real charger or the real bike yet. Everything so far was only done by looking at the battery and protocol dumps provided by @verlierer. Thanks a lot!
Viele Grüße,
Tobias
).
