Battery firmware about dji-firmware-tools

[notsolowki]

Yea okay your helpful. Why even open your mouth then.

[ferraript]

what FW version are you talking about?

edit: I guess you mean 1.7 as I found at phantompilots forum people complaining about how FW 1.7 disabled aftermarket batteries

but that's very strange, because on 1.6, those batteries were allowed
and there is no update of battery module firmware in 1.7 (at least with P3A)
so either battery module firmware was updated for P3P only or (most likely) this restriction is included in another firmware module

[mefistotelis]

There already are 3rd party batteries. And some people are disconnecting the lipo cells and connecting their own packets to the board. I don't see much benefit in looking at this firmware.

But id someone wanted to, first step would be to look at the battery board and identify microcontroller used.

Then a proper disassembler can be used to take a look at the code.

[notsolowki]

i thought it was a different processor. im not good at disassembly OR assembly. but i know alot more about it now since ive been using your tools. thanks and @ferraript. i will always be talking about fw 1.7.6 because i dont think i would ever use any other version.

[notsolowki]

@mefistotelis. when i cranked up the speed settings the drone would go between 45-60 mph per hour, about 20-25 mps. only thing is the person i have running the firmware gets battery errors about the current. i dont get these errors at all. this persons gimbal has been moved to the front of the drone and they think that might be the problem, but i dont think it is. also it is 1 degree F where this person is flying.

[mefistotelis]

i thought it was a different processor

It is. Processors which are not focused on computational power but on driving another hardware are called microcontrollers (uC).

also it is 1 degree F where this person is flying

I'm pretty sure that was the issue. If the battery had time to cool down below zero, it would definitely act strange. There is a thermal sensor which usually blocks the drone from starting in such case.

[GlovePuppet]

It's a TI MSP430 IIRC. I guess they are authenticating the battery via a handshake on the I2C bus.

[pawelsky]

Communication with the battery is done via serial at 115200 baud and I've managed to simulate most of the communication (enough to start the motors) using an Arduino board.
https://www.youtube.com/watch?v=inKlEuTi9cA

But I agree with mefistotelis that it is not wroth spending much time on the battery firmware as the 3rd party alternatives are easily available and cheap enough.

[notsolowki]

Pawelsky can you share the code for the arduino please. Thanks!!

[pawelsky]

No, as I said I don't want to spend time on it to make it "shareable", sorry. The 3rd party replacements are good and cheap enough now.

[pawelsky]

I was just about to start translating the description of the battery communication protocol into English, but seeing the attitude above I've really lost my motivation :(

Maybe some other time...

[notsolowki]

Lost your motivation?

"No, as I said I don't want to spend time on it to make it "shareable", sorry."

OKAY

[pawelsky]

You do understand a difference between "Arduino code" and "description of the communication protocol" right?

You are really not making yoursef any favours with that attitude...

[notsolowki]

Honestly im not sure how the handshake process works

[notsolowki]

But i do have an arduino and it sounds like somthing i want to do. I want to see how it behaves when it dont detect the load on the battery.

[pawelsky]

It is not just a handshake. It is continuous exchange of vital battery parameters (including voltages, discharge current, temperature, charge level, errors, etc.)

[notsolowki]

Well if you still willing to shRe the project with me that would be great. I think it would be alot of fun. I setup my battery to 115200 and was getting somthing but not sure what to make of it. Were you able to get any english fro. The console? Thanks

[ruckusman]

@pawelsky I'm late to this party, however I do have some questions you may be able to answer easily.

I'm looking to re-use Inspire battery boards with higher capacity cells, so need to reset the discharge counter as well as the capacity reductions that the processor calculates and stores, just wondering if you've succeeded in any communications with the TI MSP430 microcontroller via the TX/RX pads, not the I2C communications between the battery and controller.

Or if that's not the place to be looking for communication to acess the usage logs, can you suggest if I should access the I2C comms instead

[pawelsky]

Never had Inspire battery in my hands. PH3 batteries communicate via UART, not I2C.

[ITANOSYS]

Sorry for digging up the post!
But: Same problem here. I have connected a 7000 mAh battery to the TB47 board.
It would be nice if I could "teach" the battery controller the new capacity. Is there a solution for this by now?

[0r10nV]

@ITANOSYS
If that still to the point, you fisrt need to figure out which gauge IC is your Intelligent Flight Battery equipped with. For Phantom 3 and Mavic Pro it's bq30z55, for Mavic Air and Spark it's bq9000 with proprietary firmware. Both could be reprogrammed using ev2300 and bqEVSW of bqStudio software after unsealing and getting full access to IC programming interface.

[pawelsky]

TB47 has BQ76930 + BQ78350

[0r10nV]

Do you know which firmware version of bq78350?
bqStudio supports v0.05, v0.06 and v1.03 only in default setup.

[pawelsky]

Unfortunately not :(

[0r10nV]

Do you have good quality pictures of TB47 battery board?
If have, send me please to orionv76(at)gmail.com
Thanks!

[pawelsky]

Here http://i.imgur.com/bjeAfxz.jpg

[0r10nV]

Thanks! Do you have any i2c or smbus adapters to read basic information from bq78350? чт, 25 апр. 2019 г. в 12:45, Pawelsky <[email protected]>:

…

Here http://i.imgur.com/bjeAfxz.jpg — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJHZPA6WXF6E5DDHQZIV4XDPSF4UXANCNFSM4C7QHINQ> .

[pawelsky]

Well, I do have EV2300, but...

...I don't have the TB47 board (the picture was found somewhere in the internet) :)

[0r10nV]

pawelsky, did you emulate SHA1-HMAC authentication sequence over UART between arduino board and P3 drone when experimented in your lab setup without genuine smart battery?
Is it battery autentication involved in P3 anyway?

[pawelsky]

No, it was not needed.

[0r10nV]

Which FW version your P3 has at the moment of experiment? 'cause DJI introduced 'challenge-responese' batery check in newer revisions

[pawelsky]

Don't know as I've sold it long time ago :), but despite the fact that the challenge-response also existed back then the authentication could simply be ignored.

[vmiceli]

Ok lads, I bought a bunch of TB47 or TB48 PCBs as the cells were removed and I hooked one of them up with a regular 22.2 5000mah LiPo and to a PC running bqstudio. The PCB has test points for the SMBus that connects the bq78530 to the MSP530 so the software can talk to the battery manager IC. I can read the registers and I can tell it is a TB48 as the Max cell capacity is larger than a TB47. The question is, will I be able to UNSEAL it and edit the params? I need to read the bq78350 pdfs and the bqstudio docs to understand how to do that...

.

[0r10nV]

From what I see device was not autodetected by bqStudio, due to strange "fffffa5" at the left side near IC icon. Can you read firmware version through Manufacture Access? This could be done in Sealed State too. To UNSEAL bq78350 first you should have valid Unseal Key. To edit params, firmware should be supported by software, otherwise they could be changed in Hex Dump with some reversing of Eeprom structure. сб, 13 июл. 2019 г. в 15:31, vmiceli <[email protected]>:

…

Ok lads, I bought a bunch of TB47 or TB48 PCBs as the cells were removed and I hooked one of them up with a regular 22.2 5000mah LiPo and to a PC running bqstudio. The PCB has test points for the SMBus that connects the bq78530 to the MSP530 so the software can talk to the battery manager IC. I can read the registers and I can tell it is a TB48 as the Max cell capacity is larger than a TB47. The question is, will I be able to UNSEAL it and edit the params? I need to read the bq78350 pdfs and the bqstudio docs to understand how to do that... [image: Capture] <https://user-images.githubusercontent.com/15876027/61171608-03cafc00-a572-11e9-9636-c8ffa1607bf6.JPG> [image: Capture1] <https://user-images.githubusercontent.com/15876027/61171626-3a087b80-a572-11e9-8825-7c20bdaa6799.JPG> . — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#17?email_source=notifications&email_token=AJHZPA4AEALXEHTLPREYBH3P7HDLRA5CNFSM4C7QHIN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ3QZWA#issuecomment-511118552>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJHZPA5SRESAQ2PU7ZBLXULP7HDLRANCNFSM4C7QHINQ> .

[vmiceli]

You are right, bqstudio didn't autodetect it. I just used one of the two predefined bq78350 profiles there. I need to understand what Manufacturer access means and how do I request a FW version thru it. What I did is push the FW_Version button on the right side and the result came in below. Does that mean anything to you? I have no experience with this stuff but I'm willing to learn and share. Anything specific you guys want to test just let me know and I'll execute it and share the results.

[0r10nV]

Yea, it's useful information!

DeviceNumber: 0x1e9b = 7835 ; i.e bq78350
FW Version: 0x0006; i.e. v0.06
FW Build: 0x0010 = 16
Chem Id: 0x3283 = 3283 (value transposed); ATL custom HVHC LiPo Cells.

Now what we can see in the bqStudio config directory

bqStudio/config/1E9B_0_06-bq78350.bqz
... targetinfo.xml
... "bqMaximus v0.06 build 16"

This is exactly what you need! Have you select correct profile?

[0r10nV]

regarding Manufacture Access, it is multifunctional SMBUS command 0x44 (and/or 0x00) through which could be performed variuos tasks like Sealing/Unsealing, Reading&Writing Eeprom, Conrolling FETs and so on, all described in datasheet well enough.

[vmiceli]

Great stuff 0r10nV! Now bqStudio is automatically detecting the chip, see screen shot below. The funny thing is that if I leave the auto refresh ON it will change the device ID near the chip picture to the fffffa5 that I had in my previous screencap that you highlighted. If I keep auto refresh to off, the chip ID won't change.

on a side note I pushed that UNSEAL button, but there was no acknowledgment from the chip (I used the default TI unseal keyword. Is it possible that this is not the correct way to UNSEAL it? I hope that the UNSEAL procedure is different and that with the right method the default TI string will unlock this battery, I'll go read the Manufacturer Access details, as it is porbably needed for UNSEALing it.

[0r10nV]

Following conditions should be met for successfull unsealing:

1. Parameter scanning (autorefresh) should be OFF.
2. At least 4s should be exposed from last MAC SMBUS transaction before start unsealing.
3. Valid UnsealKey should be used and correct endianess used for sending.
4. If done in manual mode, Unsealing should be carried out within 4s.

Normally Unseal procedure is split into 2 steps which means 32bit Key is split into 16bit halves and each sent separately within 4s time window to Manufacture Access 0x44 blockwise command in Little Endian order.
For backward compatibility with older devices some newer generation TI Gas Gauges has also Manufacture Access 0x00 word-wise command with Big Endian byte order.

Tool buttons at the right panel is just a predefined wrappers for appropriate action, they should work.
Alternatively you can use 'Advanced Comm SMB' Tab at the top of programm window.

P.S.

From screenshot provided, FCC = 5450mAh and CycleCount = 0 tell me the battery was just brand new.
Any reason to disassemble $200 pack just for LiPo cells?
Think someone who did it, is very rich man!))

[vmiceli]

Thanks 0r10nV, I bought 5 PCBs with top cover and no cells and judging from their status I think these batteries were never used and just self discharged below the threshold to turn them on. What I don't understand is that there should be a permanent fail flag for cell undervoltage, but the PCB I wired is not in a permanent fail state (I think) as I plugged it in the Inspire 1 with the 5000mAh LiPo and the Inspire worked, and armed the motors. I didn't fly it though and in the battery history there was a cell failure event (in DJI GO) so maybe there is some flag already set in it. Anayway I practised the use of the Manufacturer Access and I can get info as per the 78350 technical manual. I also tried to unseal using the command button that uses a key that comes up by default but there was no acknowledgement, and nothing happened. I wonder if I should authenticate the chi? on TI forum somebody requested a customized bzq file for the 78350-R1 chip that would show an authenticate menu item... not quite clear yet. I also found this pdf, that I don't fully understand yet...
BQ78350 Authentication and unseal Key.pdf
autentication config for bqstudio_1E9B_1_03-bq78350_R1.zip

[0r10nV]

Cell Undervoltage PF event was not set because PF was not configured at all (see Green PF_EN flag in Manufacture Status) in this battery model.
So all that was needed to recover the packs after long storage is just to precharge the cells! (imho)

May be DJI has changed his battery policy due to numerous recall because in PH3, PH4 battery packs PF is enabled for sure.

About Battery history fail events, they just for history and should not effect Drone being.

Authentication. Not concerns Unseal at all. This is for host to check if battery is genuine (DJI or non-DJI).
And you can configure bqz by yourself by editing "bqz/toolscustomization/plugins.xml".

[vmiceli]

Cool, the bqz is just a zip file with those config xmls in it. Having a genuine PCB then is no concern for authentication. I haven't been able to unseal the battery yet using the unseal command button. I'll have to try in manual mode, but the 4secs limit is very short. In the case that the unseal key is not the default one, I wonder if that key could be located in the battery firmware? May be a battery firmware update includes the ability of the MPS430 to change some of the params in the 78350 hence the need to unseal. That would need some battery firmware digging and would make that effort worthwhile if it would enable full access to battery edits...

[0r10nV]

Your assumptions make sense! At least this requires logic analyzer to sniff update process of MSP430, to reconstruct its firmware. Because update file not ready to load in IDA Pro. It has some overhead or even encryption that prevent parsing it in disassembler. May be me wrong here but this is my understanding.
Sometime ago me play with it a little (for P3 battery firmware), me have used raw binary battery firmware update module extracted from full update image, but disassembly in IDA had failed.
But me have very little experiense with IDA and zero experience with msp430)((

[mefistotelis]

The battery modules from P3X (m1100 and m1101) do not seem to be encrypted in any way. m1101 even has some readable stings inside.

I assume one of these is for MPS430, the other is for a battery variant with different chip. Don't know which is which, but this should be detecatable by looking at MPS430 programmers guide.

So does 78350 have its own firmware? Can it be built with bqStudio? If so, we can get its structure from there.

[pawelsky]

I assume one of these is for MPS430, the other is for a battery variant with different chip. Don't know which is which, but this should be detecatable by looking at MPS430 programmers guide.

Or by searching for the default unseal code string in it :)

[mefistotelis]

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...|

[pawelsky]

Looks like this is it.

[vmiceli]

Ok. This is getting very interesting. The board I have is for the Inspire 1 i.e. WM610. Should we look into that specifically or is the firmware portion relative to the battery shared between WM610 and P3X? I would think they'd be different as different battery chips are used. For what I have found, the default for the bq78350 are: default Unseal key is 04143672, and the Full Access key is FFFFFFFF. Maybe we can look them up into the WM610 battery FW if it is not encrypted?

[0r10nV]

Think we should focus on WM610 because P3X as you noticed has different gauge IC and different design.
Perhaps both would be originated from one basic reference design which developed by TI. Who knows.

Meanwhile have opened WM610_FW_V01.08.00.92_m1100.bin and it looks like really unencrypted binaries!)
Below some blocks

Offset . . . . . 0 1 2 3 4 5 6 7 8 9 A B C D E F

000000E0 ... 31 00 DA 03 4E 56 54 00 07 62 71 37 36 39 33 30 . . . . . // 1 U NVT bq76930
000000F0 ... 00 04 4C 49 4F 4E 00 62 62 91 0A 41 54 4C 20 20 . . . . . // LION bb‘ ATL
00000100 ... 4E 56 54 20 20 00 08 00 81 00 00 00 00 06 02 00 . . . . . // NVT ?

So file most probably contains both Data and Code segments and my mistake from post above was attempt to load both of them into IDA.
Correct way should be to extract Code first!

[GlovePuppet]

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?

[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