Battery firmware

[notsolowki]

i notice the battery firmware is not encrypted. i wonder what could be done to the battery controller so aftermarket batteries could be connected

[vmiceli]

The question is, will I be able to UNSEAL it and edit the params?

I'm confused, why do you think the unseal secret is in the battery controller firmware? Does the PH3/4 need to unseal the device to use the battery?

That is more a hope than anything else as if the battery firmware changes involve any battery chip parameter then the MSP430 would need to unseal the bq78350... if that's not the case and the unseal password is not the default one than it would be very hard to make progress...

[GlovePuppet]

Just for giggles I put my LA on the SMBus between the micro and the 78350. I've attached the log tho it looks like my 78350 has an issue. Maybe this will help when reversing the micro's FW.

batt_boot.txt

So does 78350 have its own firmware?

Yes, see the data sheet

[0r10nV]

@pawelsky One tip from TI support how to unseal with default key using Advanced Comm tab.

https://e2e.ti.com/support/power-management/f/196/t/714232?Compiler-BQ78350-R1-BQ78350-R1

[vmiceli]

I think the inspire 1 batteries don't use the default unseal key, I tried the command button that should provide the easiest way to do that but nothing happens (the two bits that report the battery state are still both set to 1 i.e. battery is sealed). The command 0x0035 that reads the unseal key reports the result of the previous command and not the unseal/full access key. So it looks like we are stuck and in need to find a different way to get that key... hopefully from the inspire battery firmware, not sure there would be any way to hack into the bq78350...

[mefistotelis]

There is only 1 battery firmware in WM610 packages (ie. WM610_FW_V01.11.01.50_m1100.bin), and it seem to be equivalent of first (m1100) battery firmware for P3X.

Can you make photos of the boards where chip markings are visible?

[vmiceli]

Didn't got the sting directly, but there is a variation of it in m1101:

$ hexdump -C P3X_FW_V01.11.0020_m1101.bin | grep -B1 "\(67[ ]*45[ ]*23[ ]*01\|76[ ]*54[ ]*32[ ]*10\|01[ ]*23[ ]*45[ ]*67\)"
000058f0  54 e6 10 03 5c 13 5c 13  5a 13 5a 13 5a 13 5a 13  |T...\.\.Z.Z.Z.Z.|
00005900  08 ef cd ab 89 67 45 23  01 47 08 10 32 54 76 98  |.....gE#.G..2Tv.|
00005910  ba dc fe f8 08 10 32 54  76 98 ba dc fe 40 ef cd  |......2Tv....@..|
00005920  ab 89 67 45 23 01 11 22  33 44 55 66 77 00 cc cc  |..gE#.."3DUfw...|

@mefistotelis why did you search the strings below? Are these the default unseal keys of the P3X's bq30z55? (67[ ]45[ ]23[ ]01|76[ ]54[ ]32[ ]10|01[ ]23[ ]45[ @]*67)"

[mefistotelis]

Not the whole keys, just a variation of first 4 bytes. You attached a PDF file containing the key.

[0r10nV]

WM610_FW_V01.11.01.50_m1100.bin is the latest update.

previous packages are WM610_FW_V01.08.00.92_m1100.bin WM610_FC350Z_FW_V01.09.01.40_m1100.bin

p.s. picture of TB47 BMS is in earlier post of 25.04.2019 by Pavelsky

[mefistotelis]

Found the picture; thanks.

While m1100 uses the MSP430-specific assembly (confirmed that with IDA), m1101 has a different one. I suspect it might be port of the same code to MSP432, which is ARM. Looking at ARM code may be easier.

To load m1100 with IDA, use offsets from "Memory Organization" table within datasheet.

[0r10nV]

Can you make screenshot how disassembly progress bar is looks like after loading m1100 module? To see how much of code is recognised...

[mefistotelis]

I did not made full analysis, nor I defined all MMIO areas; but sure, here's my screenshot:

[0r10nV]

Thanks, looks very good as for the initial analysis, will follow your advice.

[mefistotelis]

To properly load the file, we'd have to figure out base address of the file within flash space. The assembler uses absolute addressing quite often, so most calls are invalid (I loaded it at 0x8000).

To analyze the firmware after loading, we would need source of basic libraries from the environment used to compile the FW. I suspect it's IAR Embedded Workbench; but only old versions (up to 7.12) have support of this architecture.

m1101 doesn't look like ARM after all.. seem like the same MSP430 asm.

[0r10nV]

TI has some reference designs for MSP430 and fuel gauges (other then bq78350), they collected in their slva413a.zip archive, there are IAR EW and TI CCS projects inside together with libraries but still not sure how to link them to IDA Pro if they will match for that purpose at all.

[vmiceli]

Just another idea, the unseal key is made up of two bytes. If we represent them with the 4 Hex number, each number has a possible 16 state, then the number of combination should be 16^4=65536. Or if we use binary, a 16 digit binary with each bit with two possible state would be 2^16=65536. That is a pretty low number so doing a brute force attack to unseal the chip (with an arduino on SMBus) would be feasible. I can talk to the chip on SMBus while the battery pack is off so the MSP430 is not interfering at all making this even more efficient. Did I do my math wrong? Or the unseal code is a very easy one to break? It is also possible that the chip won't accept too many requests to unseal and shut itself off...

[0r10nV]

Unseal key is 32-bit (4 bytes) long. So full keyspace is 2^32 = 4294967296 possible combinations. Multiply them on 4s delay between failed attempts and brute-force time would be about 500years!

[GlovePuppet]

Yeah, you won't brute force it but you might get some clues from a side channel.

The datasheet is full of "wait 250ms and then read the result" which makes me believe they thought of timing attacks but that leaves power analysis....

[pawelsky]

Well, given DJI used the default unseal key in PH3 I would assume they did the same for Inspire. Maybe the byte order is just wrong when issueing the unseal command?

[0r10nV]

Me can confirm that default key is in PH4 batteries (ATL NVT, DJ009), but PH3 is not, at least batteries with Manufacture Name "ATL NVT", Device Name "DJ005". I know one DJI P3 and P4 owner who has digged into both of theirs batteries. After long storage some of P3 and P4 batteries were in UnderVoltage latch (PF is enabled in that packs). P4 batteries were succesfully PF cleared and restored using bqEVSW and default unseal key. More difficult situation turned out with P3 ones. Default key did not work. For sure! Not to waste $150packs he took advantage of local repair workshop where technician has unsealed and unlock the batteries and immediately changed the keys to default to avoid possible unique keys leackage. As workshop service is expensive enough, he baught new bq30z55 and replaced them in his another batteries.

[mefistotelis]

in their slva413a.zip archive, there are IAR EW and TI CCS projects inside together with libraries

I couldn't find that zip. But I found the accompanying pdf, and a variation on that code named "MSP430-Software-for-bq" on some dodgy Chinese site.

[0r10nV]

Have rechecked and links not available now. Year ago it was ok for sure. So have sent you arch in PM as do not know the reason of zip removal. If someone else interested just tell me.

[mefistotelis]

The firmware does not seem to be plain flash content. When trying to match interrupt handlers to find base address, I've noticed different handlers suggest different address:

<my int handler addr> - <addr in int vector> = <difference which I expected to be constant>
b1ae-b11a = 94
c06c-c04c = 20
c110-c0f8 = 18
c28e-c282 = 0C
c2fe-c2f2 = 0C

Maybe the file is divided into blocks, and each has additional 4 byte header?

[0r10nV]

Make sense. Has noted last 2 entries have same difference perhaps.

I'd preffered first to find simple raw msp430 binaries, i.e. 'blinky', and examine them in Hex Editor and in IDA Pro to see how genuine code is looks like before crack this 'nut'. But quick searching on the net gave me nothing. So will try to install TI CCS and to compile 'blink LED' from source code examples.

[mefistotelis]

I expect 4 byte header every 128 bytes.

Yeah, compiling a basic project is a good idea. We will get binary at all stages of creation, plus the map file with exact memory mapping.

[pawelsky]

Me can confirm that default key is in PH4 batteries (ATL NVT, DJ009), but PH3 is not, at least batteries with Manufacture Name "ATL NVT", Device Name "DJ005".

Interestind. Then the default key mefisto found in the PH3 binary must be the HMAC authentication one.

[vmiceli]

Me can confirm that default key is in PH4 batteries (ATL NVT, DJ009), but PH3 is not, at least batteries with Manufacture Name "ATL NVT", Device Name "DJ005". I know one DJI P3 and P4 owner who has digged into both of theirs batteries. After long storage some of P3 and P4 batteries were in UnderVoltage latch (PF is enabled in that packs). P4 batteries were succesfully PF cleared and restored using bqEVSW and default unseal key. More difficult situation turned out with P3 ones. Default key did not work. For sure! Not to waste $150packs he took advantage of local repair workshop where technician has unsealed and unlock the batteries and immediately changed the keys to default to avoid possible unique keys leackage. As workshop service is expensive enough, he baught new bq30z55 and replaced them in his another batteries.

@0r10nV He didn't happen to annotate the non-default key that was in the PH3 batteries? I could try that one on the TB48...

I was wondering if the process involves SHA-1 authentication before the bq78350 can be unsealed... I enabled the authentication plugin in bqstudio but it doesn't start on the bq78350 in the TB48 I have, it gives an error with a list of Java exceptions... maybe that's a good sign :-)

[0r10nV]

He not have it. Workshop technician have changed genuine key to default one as soon as battery was connected to ev2300. They keep it in secret and not disclose to anyone because it's their business.

[0r10nV]

| Then the default key mefisto found in the PH3 binary must be the HMAC authentication one |

Don't know what those strings used for, but msp430 does not involved in HMAC calculation at all. It can not authenticate the battery because it is already part of this battery. Drone CPU does do it. MSP430 is just a repeater between Drone and Gas gauge. So authentication key is shared between bq30z55 and main authenticator on Drone side. If we would like to find another key we should dig into Drones binaries.

[vmiceli]

My plan for the weekend is to capture with the logic analyzer the SMBus comms between MSP430 and 78350 and the serial comm to the Inspire 1. I guess we should be able to see the authentication process. Unfortunately it appears that we are stuck with the battery unsealing process that would be the best scenario to implement larger battery packs natively...

[0r10nV]

If your target is just a large capacity battery then there is one simple trick to make gas gauge correctly reporting State of Charge. It's to reduce Current Sense Resistor proportionally to increased capacity. And that's it! This way goes Chinese double-power copy battery producers. This way goes even DJI in some of genuine battery packs. In FB1 for Dji Mavic Pro for example. Sense resistor is half of nominal value and all Current and Capacity parameters measurements are done with 1:2 ratio. Then Relative State of Charge is calculated correctly. Other parameters doubled in msp430 when reporting to Drone over uart.

[vmiceli]

@0r10nV yes, you are absolutely right and I'm aware of the sense resistor halving etc... The reason to have access to the 78350 is to be able to reset their cycle count and the prorated capacity they report. Unless you have a brand new PCB (like the one I happened to stumble upon), the battery parameters would be deteriorated based on usage. Then obviously there is the challenge of being able to remove any limitation and even do a proper battery cycle training on the specific larger cell of choice :-)

[vmiceli]

Folks, not much progress so far, I was wondering the followig:

In the case of phantom 4, 0r10nV says that DJI used the default unseal key for the bq30z55. Since we know what that key is, should we be able to find that sequence by opening the battery portion of the PH4 FW in an hex editor (and assuming the key is in there?). I guess I'm not sure on what the hexdump of a binary files gives me...

I also wrote a little cpp program that will compare the hexdump of two binary files and look for common sequences with more than a prefixed lenght. (4 numbers). My idea is that if the unseal key is indeed in the battery FW than it should show as a common sequence on multiple firmware binaries. Again, I'm not sure if this is the correct approach on the content of an hexdump of a binary...

[vmiceli]

No luck so far with unsealing the I1 battery. Out of curiosity I converted an official bq78350 FW bq78350_v0_06_build_16.srec to bin file and sure enough you can see the default keys are in there:

I also compared the P3 battery firmware with the I1 and listed all the hex sequences of 4 or more bytes that are common hoping that if the 1100 module holds the unseal key that could be common to both. Unfortunately there are quite a few common strings :-(. I was hoping to get the P4 1100 module as it has been reported that it has the TI default keys, but I have been unable to extract the a binary copy from a P4 firmware file. Can anyone help with that? That would finally answer if the unseal key is in the battery FW...

[pawelsky]

I also compared the P3 battery firmware with the I1 and listed all the hex sequences of 4 or more bytes that are common hoping that if the 1100 module holds the unseal key that could be common to both.

That I'm afraid was a waste of time as the BQ30Z55 chip in P3 battery uses 16 byte long keys.

[mefistotelis]

I was hoping to get the P4 1100 module as it has been reported that it has the TI default keys, but I have been unable to extract the a binary copy from a P4 firmware file. Can anyone help with that?

Download with this: https://github.com/cs2000/DankDroneDownloader Then un-TGZ. Then use dji_imah_fwsig.py to unsign the module.

That's all.

[vmiceli]

@mefistotelis

Found it for the PH4. The default key is in the 400 module. The question is how to find it for the Inspire 1 now

The default Key for the bq30z55x

found in the m400

[pawelsky]

Keep in mind that this may be the HMAC authentication key rather than the unseal/full access one (although they have the same value in case of P4)

[vmiceli]

@pawelsky

Yes, very likely, and in the case of the I1 it appears to be:

Or maybe these are the two UNSEAL and FULL ACCESS words? :-) it doesn't look like they work though...

[pawelsky]

it doesn't look like they work though...

Make sure to enter it with correct endianness...

[vmiceli]

Actually comparing different firmware versions (m400 modules) only the 01 23 45 67 89 AB CD EF is common, so this isn't probably the HMAC (because it is too short?). I'll try to use it as unseal keyword then...

[prefer-to-repair]

Hello, most if not all of this thread is way way beyond me but you folks might be able to help me, if you are so inclined. I got a dead P3 battery in amongst a bag of bits, the battery will not charge ( I had it connected for hours) nor will it switch on. I tried various button pressing resets that I have read about and these did not work, So I opened the case to get access to the cells and top circuit board, is there another board buried in amongst the cells themselves? Presuming the board required 0V etc. to reset I disconnected the balancer? cable and the positive high current lead between the cells to the top circuit board (was this a mistake?) and charged the cells via direct connections to their terminals (they were below 10V at the start). When charged I disconnectted the charger and let the battery stand like that over night. The following day I then reconnected the high current lead, at which point all the green LEDs came on, and then reconnected the balancer? cable. The battery switches on and off with the normal light sequence but after switching on three of the green LED's go out. It appears that the connector to the drone's terminals remains some how isolated.

I suspect there is some means of reseting the board, (other than my attempt above) possible with jumpers between various points on the board and was wondering if you folks know of it? If so could you tell me how to do this? Do you need or want good clear photos of the board's top and bottom? Alternatively is the a correct connection sequence for reconnecting a physically disconnected board to the cell cluster and balancer? cable?

I realise the cells had dropped to a very low voltage and that they may have been rendered useless but at the moment they seem ok and assuming I can get the battery as a whole working again they would be subject to several test flight before I placed any reliance on them' Thanks

[0r10nV]

Hello! Your battery has encountered CUV (Cell UnderVoltage) event due to deep discharge or long storage and PF (Permanent Faulure) flag was set in the bq30z55 battery Gas Gauge. Charge and Discharge FETs was disabled thus isolating main power to the battery socket. Disconnecting board from the cells is not solving the problem. To reset error it's required special battery repairing software and hardware like cp2112, philips i2c-lpt or TI ev2300(ev2400) adapters.

[mefistotelis]

While at it, can you make quality photos of the battery board, both sides? The ph3 battery photos I have on the wiki are quite poor.

[prefer-to-repair]

mefistotelis, I will work on the photos. 0r10nV, so, at a guess, not within my capabilities?

[prefer-to-repair]

Is the attached of suitable quality? They are phone photos with cropping done in MS paint, if the resolution is too low I can try using gimp or taking photos using a proper DSLR.

To get the lettering on the chips, if I can it lookslike it's going to have to be a DSLR, that will be later today

[0r10nV]

@prefer-to-repair, If you are not planning to repair smart batteries in the future, and have never dealt with them before, then yes, it will be too complicated and time&money consuming job. Just consider that ev2300 adapter costs like a new P3 battery. But it's not enough. Particulary this battery protected from unauthorised access to programming level, so you could not use free TI bqEVSW tools to reset battery errors. You first need to unseal it. For that job you need third-party battery unlocking software. The cheapest software tools with good passwords dictionary costs $200/year. Which makes one-off repair absolutely unreasonable. So in your case the optimal solution is to find out nearest Laptop Batteries Recelling Workshop and send them battery for unlocking. They have all sw&hw tools required for this. Additionaly they could set up deafault unseal key and configure your battery as "never-locked", so PFF would not set if your battery will encounter deep discharge again.

[prefer-to-repair]

0r10nV, thanks but a pity :-( mefistotelis here you go

[prefer-to-repair]

0r10nV, a couple more questions if I may ask. Say I wanted to swap a 'good' board from a damaged battery to this group of cells what disconnection, if any, switches the board off? i.e. if I kept the board 'powered' via a set of jumper leads from these cells to the solder joints marked B+ & B- would the moved board stay switched on?

Out of curiousity with regards to battery worshops do individual chips have to be removed from the board to reset them?

An idea came to mind and since I may have previously made a mistake by acting before I asked I will now ask before I act. Please say if this is a stupid idea and or dangerous. What would happen if I made jumper connections between B- & P- and between B+ & P+, i.e. bypassed the "Charge and Discharge FETs". connected the battery to the drone and. if the battery powered the drone, tried a firmware up date via the drone, if updating the firmware is even possible? Thanks

[0r10nV]

If me understand you right, you plan to 'hot-swap' the boards, i.e. to interchange locked and good ones with both being powered on. If so, you should focus at paralleling and equalyzing the cells of both batteries to make board swapping invisible to battery monitoring IC. But this procudere is not compulsory for changing the boards in general. If you will follow simple rules, good board will not be locked. First, unsolder main 'B+' wire from PCB. Secondly, disconnect balancing socket, thus powering off the PCB. At last, unsolder 'B-' wire.

For connecting replacement board procedure should be done in reverse order.

Some people reported that they firstly disconnect the balancing socket, then main wires and all gone well, so battery was not locked.

In any case attention should be payed to how balancing socket is handled. Unplugging and plugging must be carried out as fast and distinct action, all socket pins must come in contact simultaneously to prevent skew.

Chinese after-market P3 batteries has the same BMS like genuine ones but configured as 'never-locked', so replacement could be done in any order. If you will have opportunity to get PCB from knock-off 'good-copy' battery, try use it instead of genuine one.

Regarding battery workshops IC's resetting. Chip removing not required. They connect ev2300 (or compatible adapter) to PCB points marked as GND, SCL, SDA and then clear the Permanent Failure by means of software.

Some words about FETs bypassing. Before Smart Batteries come to the scene, LiPo cells were usually connected to Drones and RC-models power line by means of simple plugs without any protection boards. In such a case all caution should be taken as to battery charging, discharging, balancing etc.

Firmware updating over UART in P3 batts concerns only MSP430. Me believe it would be possible in case FETs is bypassed, but PF flag is set in another, the bq30z55 Gas Gauge IC. It resides behind first IC on another bus, called SMBUS and thus remains untouched during updating, so this will not clear PFF.

[prefer-to-repair]

Thank you for the answers, they are most helpful