We can't have too many photo's! Yes please!
Reverse engineering BMS Firmware / Reflashing BMS
- Thread starter safetyuggs
- Start date
Help Support My Nissan Leaf Forum:
ginetto
Well-known member
I posted photos of a 2012 model. No idea if it is similar to a 2013 one.Hey all, not a software expert but have 24kwh 2013 car bms (black interior) that i can poke open and do pictures of, down to microscopic level if it helps. Probably take readings of some chips etc too. But if that is already covered then nevermind
PS. don't forget to wipe your phone lenses, helps a lot with picture clarity very often!
Just received my yahooacutions 24kwh grey plug (plastic back) BMS. Very similar PCB but a few clear differences. so Yes, more pics of every variant would be great!
Did you post the back side of the board too? i don't remember seeing that in post #35.
Last edited:
ginetto
Well-known member
no, but I'll do editing the original post. is it ok?
Hi team! Joined late to the party, but still on time. Great discussions here, very interested and willing to help.
I have access to several types of BMS for the leaf in my company. Do you need any help with them? I'm not an expert in eprom reading, or JTAGing but can learn quickly if needed.
Please let me know ig you need anything from my side!
I have access to several types of BMS for the leaf in my company. Do you need any help with them? I'm not an expert in eprom reading, or JTAGing but can learn quickly if needed.
Please let me know ig you need anything from my side!
Yes… I do have a can bus interface.
Will take a few pictures on Monday for the BMSs at hand.!
Will do!Great @ramdooryou can start adding front/rear photos of different models with zoom to the main processors an eeprom codes
Crypto Cracked! Tested on 24kwh Gen1 (white socket), 24kwh grey socket, 30kwh, and I can't see a reason it wouldnt work on other BMS's too. We can now reset EEPROM parameters including SOH and HX instantly. Still working on the firmware update code but now we have full security access, that shouldn't be too compilcated.
Attachments
Wow that's impressive.
Care to share how you found this--hard work, lucky, or some special tools and skills?
The firmware that was shared here isn't a complete firmware, It's missing around 50kbytes of data which I guess is the bootloader / boot code of the BMS (There is no reset vector or interrupt vector table in the firmware and there should be).
Once I learnt this I knew the 6 x 16bit hard coded values used for the decryption function were incorrect. I coded up some brute force code to run through all the possible values and let that run overnight. being a 96bit number and only testing a fraction of a percent of the possibilities in 12hrs, this was a dead end.
I was going to code it up in a FPGA and have it running 64 variations at once at a few hundred million attempts per second (which would maybe take up to a week?) but found an easier way
There are some hard coded values in the flash that can be read without security level access, I found where these are in the firmware dala posted, and compared that to where the firmware was looking in the BMS. I adjusted the 12 or so crypto reference addresses assuming a fixed offset and I only had to brute force 32bits of those 96 to find a match which only took around 20min.
I wrote up some test code to request a seed, sent the calculated response and got a Key Valid response! I ran this in a loop to test a few hundred seed/key pairs and got a 100% success rate so I'm confident the code works as intended.
I sent over the reset SOH and tested in leafspy and it worked, then sent over the reset Lx/Cx command and that too worked. The function that resets Lx/Cx also clears 20+ other variables which i do not know what they are so maybe don't use this command on a BMS you need until I work out what its doing exactly.
There is another 0x31 command which will let you set all of the EEPROM values to whatever number you want. I'll dig deeper into this too, it'll likely help out finding what the above values do.
Should this source be shared? As it stands the only way to do this is with a Consult3 device (prohibitively expensive for most people) or using that defunct russian app. If it finds its way into leafspy or another app there'll be a whole lot of Leaf's on the market with 12bars of health and artifically high used leaf prices. I was considering adding code to test that the temperature sensors are unplugged before allowing the SOH reset, that'll somewhat prevent people resetting SOH when selling a car, but still allow Off-grid or CATL upgrades to reset their SOH. Thoughts?
Once I learnt this I knew the 6 x 16bit hard coded values used for the decryption function were incorrect. I coded up some brute force code to run through all the possible values and let that run overnight. being a 96bit number and only testing a fraction of a percent of the possibilities in 12hrs, this was a dead end.
I was going to code it up in a FPGA and have it running 64 variations at once at a few hundred million attempts per second (which would maybe take up to a week?) but found an easier way
There are some hard coded values in the flash that can be read without security level access, I found where these are in the firmware dala posted, and compared that to where the firmware was looking in the BMS. I adjusted the 12 or so crypto reference addresses assuming a fixed offset and I only had to brute force 32bits of those 96 to find a match which only took around 20min.
I wrote up some test code to request a seed, sent the calculated response and got a Key Valid response! I ran this in a loop to test a few hundred seed/key pairs and got a 100% success rate so I'm confident the code works as intended.
I sent over the reset SOH and tested in leafspy and it worked, then sent over the reset Lx/Cx command and that too worked. The function that resets Lx/Cx also clears 20+ other variables which i do not know what they are so maybe don't use this command on a BMS you need until I work out what its doing exactly.
There is another 0x31 command which will let you set all of the EEPROM values to whatever number you want. I'll dig deeper into this too, it'll likely help out finding what the above values do.
Should this source be shared? As it stands the only way to do this is with a Consult3 device (prohibitively expensive for most people) or using that defunct russian app. If it finds its way into leafspy or another app there'll be a whole lot of Leaf's on the market with 12bars of health and artifically high used leaf prices. I was considering adding code to test that the temperature sensors are unplugged before allowing the SOH reset, that'll somewhat prevent people resetting SOH when selling a car, but still allow Off-grid or CATL upgrades to reset their SOH. Thoughts?
Well done! In all of that explanation, I understand only the normal English words, but I'm keen to see a successful end to your project - even if only for selfish reasons now that my car is down to 9 bars!The firmware that was shared here isn't a complete firmware, It's missing around 50kbytes of data which I guess is the bootloader / boot code of the BMS (There is no reset vector or interrupt vector table in the firmware and there should be).
Once I learnt this I knew the 6 x 16bit hard coded values used for the decryption function were incorrect. I coded up some brute force code to run through all the possible values and let that run overnight. being a 96bit number and only testing a fraction of a percent of the possibilities in 12hrs, this was a dead end.
I was going to code it up in a FPGA and have it running 64 variations at once at a few hundred million attempts per second (which would maybe take up to a week?) but found an easier way
There are some hard coded values in the flash that can be read without security level access, I found where these are in the firmware dala posted, and compared that to where the firmware was looking in the BMS. I adjusted the 12 or so crypto reference addresses assuming a fixed offset and I only had to brute force 32bits of those 96 to find a match which only took around 20min.
I wrote up some test code to request a seed, sent the calculated response and got a Key Valid response! I ran this in a loop to test a few hundred seed/key pairs and got a 100% success rate so I'm confident the code works as intended.
I sent over the reset SOH and tested in leafspy and it worked, then sent over the reset Lx/Cx command and that too worked. The function that resets Lx/Cx also clears 20+ other variables which i do not know what they are so maybe don't use this command on a BMS you need until I work out what its doing exactly.
There is another 0x31 command which will let you set all of the EEPROM values to whatever number you want. I'll dig deeper into this too, it'll likely help out finding what the above values do.
Should this source be shared? As it stands the only way to do this is with a Consult3 device (prohibitively expensive for most people) or using that defunct russian app. If it finds its way into leafspy or another app there'll be a whole lot of Leaf's on the market with 12bars of health and artifically high used leaf prices. I was considering adding code to test that the temperature sensors are unplugged before allowing the SOH reset, that'll somewhat prevent people resetting SOH when selling a car, but still allow Off-grid or CATL upgrades to reset their SOH. Thoughts?
As to sharing your knowledge, I'm impressed by your ethics; the techbros we read about would just let it rip - provided the money was right of course! I agree that some safeguards should be in place for the reason you point to, but I suspect that they would need to be somehow stronger than simply checking for the temperature sensor. I have no idea what or how safeguards could be applied, but there are a lot of unscrupulous cheats out there and most buyers would not have a clue.
JVM
Last edited:
Wow... impressive!! Thanks for sharingThe firmware that was shared here isn't a complete firmware, It's missing around 50kbytes of data which I guess is the bootloader / boot code of the BMS (There is no reset vector or interrupt vector table in the firmware and there should be).
Once I learnt this I knew the 6 x 16bit hard coded values used for the decryption function were incorrect. I coded up some brute force code to run through all the possible values and let that run overnight. being a 96bit number and only testing a fraction of a percent of the possibilities in 12hrs, this was a dead end.
I was going to code it up in a FPGA and have it running 64 variations at once at a few hundred million attempts per second (which would maybe take up to a week?) but found an easier way
There are some hard coded values in the flash that can be read without security level access, I found where these are in the firmware dala posted, and compared that to where the firmware was looking in the BMS. I adjusted the 12 or so crypto reference addresses assuming a fixed offset and I only had to brute force 32bits of those 96 to find a match which only took around 20min.
I wrote up some test code to request a seed, sent the calculated response and got a Key Valid response! I ran this in a loop to test a few hundred seed/key pairs and got a 100% success rate so I'm confident the code works as intended.
I sent over the reset SOH and tested in leafspy and it worked, then sent over the reset Lx/Cx command and that too worked. The function that resets Lx/Cx also clears 20+ other variables which i do not know what they are so maybe don't use this command on a BMS you need until I work out what its doing exactly.
There is another 0x31 command which will let you set all of the EEPROM values to whatever number you want. I'll dig deeper into this too, it'll likely help out finding what the above values do.
Should this source be shared? As it stands the only way to do this is with a Consult3 device (prohibitively expensive for most people) or using that defunct russian app. If it finds its way into leafspy or another app there'll be a whole lot of Leaf's on the market with 12bars of health and artifically high used leaf prices. I was considering adding code to test that the temperature sensors are unplugged before allowing the SOH reset, that'll somewhat prevent people resetting SOH when selling a car, but still allow Off-grid or CATL upgrades to reset their SOH. Thoughts?
Ianlighting
Active member
Very impressive, even though I am not qualified to know how impressive this is!The firmware that was shared here isn't a complete firmware, It's missing around 50kbytes of data which I guess is the bootloader / boot code of the BMS (There is no reset vector or interrupt vector table in the firmware and there should be).
Once I learnt this I knew the 6 x 16bit hard coded values used for the decryption function were incorrect. I coded up some brute force code to run through all the possible values and let that run overnight. being a 96bit number and only testing a fraction of a percent of the possibilities in 12hrs, this was a dead end.
I was going to code it up in a FPGA and have it running 64 variations at once at a few hundred million attempts per second (which would maybe take up to a week?) but found an easier way
There are some hard coded values in the flash that can be read without security level access, I found where these are in the firmware dala posted, and compared that to where the firmware was looking in the BMS. I adjusted the 12 or so crypto reference addresses assuming a fixed offset and I only had to brute force 32bits of those 96 to find a match which only took around 20min.
I wrote up some test code to request a seed, sent the calculated response and got a Key Valid response! I ran this in a loop to test a few hundred seed/key pairs and got a 100% success rate so I'm confident the code works as intended.
I sent over the reset SOH and tested in leafspy and it worked, then sent over the reset Lx/Cx command and that too worked. The function that resets Lx/Cx also clears 20+ other variables which i do not know what they are so maybe don't use this command on a BMS you need until I work out what its doing exactly.
There is another 0x31 command which will let you set all of the EEPROM values to whatever number you want. I'll dig deeper into this too, it'll likely help out finding what the above values do.
Should this source be shared? As it stands the only way to do this is with a Consult3 device (prohibitively expensive for most people) or using that defunct russian app. If it finds its way into leafspy or another app there'll be a whole lot of Leaf's on the market with 12bars of health and artifically high used leaf prices. I was considering adding code to test that the temperature sensors are unplugged before allowing the SOH reset, that'll somewhat prevent people resetting SOH when selling a car, but still allow Off-grid or CATL upgrades to reset their SOH. Thoughts?
I think there is a strong moral obligation to withhold the ability to adjust SOH on a car. The implications for people on lower incomes (if you’re buying a 13 year old Leaf, that’s a reasonable assumption) to lose a large amount of their money, is high.
Similarly, someone’s first adventures into owning an EV could turn very sour if they find it only has a 30 mile range.
So if you’re canvassing opinions, I’d like to cast my vote strongly against this knowledge escaping into the wider world. How you do that I’ll leave to you!
So, a related question - what is your objective when you do reach the end? What will you be able to do for people?
I’m watching with great interest!
