Reverse Engineer the Leaf and making it work good (tm)

[nickandre]

I am a thoroughly geeky computer and electrical engineer interested in doing some reverse engineering work on my 2013 SV Leaf. To that end, it's probably worthwhile to identify the overall modules at work within the system and which can be replaced. For the intents and purposes, we can group modules by their interface to the main (CAN) bus as that is the level at which we can physically disconnect them using my crowbar and replace them with an open source component (FreeRTOS or Linux-based etc).

Assuming that we can't split the software for a single component without a fair amount of todo, we need to identify the entire set of required (drivetrain etc.) functions that any block implements at the CAN bus level before tinkering can begin. I think the first question to contend with is which portion of the Vehicle data is sent via the CAN bus. I'm going to assume (perhaps incorrectly) that, like in other vehicles, the CAN bus is relatively insecure, a lot (if not most) of the vehicle information is sent over it, and once access is granted we can snoop on the messages and figure out what does what:

1. What information is accessible via the CAN bus? Can we, for instance, read accelerator pedal position? Can we compile these functions into a big document?
2. What are the overall modules within the Leaf system that transmit each relevant type of information and how can they be grouped? Take (1) above and group them under their device, tally which are required for vehicle operation and which (if any) are superfluous.

Anyways, here is my list of hypothetical crazy ideas to make the leaf a really cool car (tm):

1. (probably "pretty easy" given the limited drivetrain-required functionality and lack of integration to other system components) Replace the entertainment system with a custom OS that can play FLAC files off the second SD card. Remove useless functionality (nav system). Replace the cellular modem with a 4G unit and network software that isn't implemented in such a fashion that it takes literally 3 days to download a JSON list of charging stations. Remove the polite voice that indicates the TCP connection state (what is this, 1980?). (Also I refuse to pay money to "upgrade" to a 2006-era cellular modem.)
2. Provide limited integration between the HUD and the main screen (why are there two entirely independent sets of settings?). Make the HUD useful (see 4).
3. Modify the drivetrain control. I'm not talking down to the SVM level - ideally we could simply alter the mapping of accelerator/break pedal input, eco, and B mode so that it wasn't absolutely and entirely foolish. B mode enables max regen down to a full stop, D mode doesn't enable regen without break pedal, and no god damn creep. Avoid destroying traction control and ABS in the process. Bonus points if we can alter the D mode break pedal behavior to engage maximum regen before mechanical breaks activate.
4. Provide real information on the HUD. Replace the GOM with kWH. Provide a single HUD display box that does efficiency, % charge remaining, KWh remaining, miles to empty for a CONFIGURABLE and not VOODOO MAGIC DERIVED miles/kwh. (Why the hell, despite there being plenty of room to display all parameters on one window, do we have to click through 17 of them to see what we want to see?)
5. Implement Cruise Control to match an efficiency requirement.
6. For the main system, use a cool API like google maps to attain estimated range given terrain for a route. Tie this into the above cruise control efficiency attainer to use altitude info.

Some of this is definitely easier than others. I would hazard to guess the modularity is less-than-ideal at a physical CAN bus level and that the embedded software would be hard to split apart, but I know others have done a fair amount of work at that level so we can at least ascertain the difficulty before I break out the crowbar, soldering iron, and JTAG programmer.

EDIT: I almost forgot: modify the vehicle sounder to make my car do the Jetsons noise.

 

[Reddy]

Welcome. FYI, many of the real geeks have left the forum or post only sporadically. You should go back and read historical threads from 2010-2012. There are/were a lot of smart people working on their Leafs back then. Good luck.

 

[NocturnalWalt]

Hi nickandre. I haven't been following this forum for a very long time myself but looking back through old posts I would have to agree with Reddy that there was a lot more interesting reverse engineering work (particularly on CAN bus messages) going on in this forum back in 2010-2012 than there is now. It is a bit of a shame as there still is plenty of potential to make what I consider a good car much better. But the work done back then is still a solid base for any of us wanting to take it further.

I like some of your ideas (the Jetson's one made me laugh), but the projects you've got in mind are a bit different to the areas I've been researching and focussing on. However there is some overlap of common stuff. My main interest lies around the VCM and the LBC and the CAN bus interaction between these two devices. I haven't made any progress worthy of posting yet as I have mostly been looking at the work done here in the past as well as info in the factory service manuals. Actually, I can think of one interesting thing I've learned recently worthy of posting. Playing around with Consult 3+ which I've got access to, it appears that when the car is at full throttle and between 0-30mph the VCM doesn't ever ask the inverter for the maximum possible torque. So faster acceleration in that speed range is quite possible with just VCM remapping and that that is exactly what Nissan has recently done in their top spec JDM Aerostyle models.

http://ev.nissan.co.jp/LEAF/AERO/

I figure that if you, me and others get back into Leaf reverse engineering and share any interesting results then that will tend to suck in more people with a similar interest which would be great.

 

[nickandre]

Interesting. I've noticed, for instance, that if you hold the accelerator pedal static that the power applied and indicated increases quite drastically with speed.

The one caveat with tweaking such parameters is that it's quite possible for the Space-Vector-Modulation Inverter to apply sufficient power to reap havoc downstream, so sometimes those limits are placed in there for good reason. Some of it is definitely traction-control related (have you tried examining the behavior while toggling that setting?).

I've been going over the CAN protocol and I think the Telematics/Nav system is probably the best place to start. Few actual required functions for the

I wonder how protected their system is/how easy it would be to start dumping firmware off some of these modules. You have to wonder if they can't secure an API how they possibly know to code protect their microcontrollers

Can you elaborate on the Consult III+ functionality? Has anyone tried to poke around with a reverse engineering suite in that software package? How about sniffing the bus to see what messages it transmits?

--Nick

 

[NocturnalWalt]

Hi Nick. Quite a bit was done a few years ago with sniffing the CAN bus and monitoring Consult 3+ commands and responses. You can check out the following thread on that here:

http://mynissanleaf.com/viewtopic.php?f=44&t=11676&hilit=EV+CAN+active+sampling#p269432

I think a lot of that info went into making LeafSpy Pro what it is today. Actually, searching to find that link for you I noticed it's under Board index -> LEAF Ownership Accessories / Mods / LEAF CANBus which isn't somewhere I normally look. There is still more happening in there than I thought which is good to see.

I haven't seen much of anything regarding people getting firmware out of the micros in various modules, but that would be really cool when/if we got to that point.

 

[grandizer52]

So on top of geekdome...anyone notice the antenna looks like the reflex gun from star blazers when they battled the gamilons on pluto...

 

[Brenthasty]

Please hack away, I just stripped one down to its uni body chassis! Put the parts up for sale on ebay to pay for the very educational experience of upcycling a leaf...

It appears the motor and drive could be actuated with a standard off the shelf inverter drive in place of the existing nissan built unit.

Thanks for helping to open source the world...

 

[nickandre]

There's no question that I could use an off the shelf three phase SVM inverter, which might be fun.

But tbh Nissan has done a lot of good work (just botched a few really annoying things).

I've recently debated reaching out to Nissan to see if I can chat with an engineer on the leaf.

PS any chance I can get the vehicle control system or entertainment system for my hackery? I think the best bet for a first project is a new entertainment system or at a minimum new firmware with Apple car stuff in it.

--Nick

 

[collink]

I haven't seen much of anything regarding people getting firmware out of the micros in various modules, but that would be really cool when/if we got to that point.

I haven't gotten there yet (so many projects...) but I thought about using UDS to try to extract firmware. UDS has specific provisions to allow for firmware upload and download. That's how an automaker can update the firmware on the various vehicle systems without having to take things apart. I know that several UDS speaking devices exist on the Leaf because I've queried them. But, I haven't actually gotten to trying to get any of the devices to agree to a firmware offload. I think it might be possible but generally the ECU will require a security check before allowing this. So, it depends on how hard they locked down the security.

 

[caederus]

... I thought about using UDS to try to extract firmware. UDS has specific provisions to allow for firmware upload and download. That's how an automaker can update the firmware on the various vehicle systems without having to take things apart. I know that several UDS speaking devices exist on the Leaf because I've queried them.

This is something I've been meaning to try doing too, but my early attempts did not go well. Just sending what I thought would be the innocuous 0x3E "Tester Present" seemed to cause major confusion to some devices! I see some UDS SIDs that do work:

• 0x10 Diagnostic Session Control
• 0x14 Clear Diagnostic Information
• 0x19 Read DTC Information
• 0x22 Read Data By Identifier

But other messages follow the form of UDS but have a unknown SIDs, e.g. 0x3B/0x7B:

(1468765774.946770) can0 RX - - 71D#023B00FFFFFFFFFF
(1468765774.964385) can0 RX - - 72D#067B0040014003FF

But, I haven't actually gotten to trying to get any of the devices to agree to a firmware offload. I think it might be possible but generally the ECU will require a security check before allowing this. So, it depends on how hard they locked down the security.

It would be very helpful to have a candump log of a dealer doing a firmware upgrade - does anyone already have one they'd be willing to share, or a way to obtain one?

 

[NocturnalWalt]

It would be very helpful to have a candump log of a dealer doing a firmware upgrade - does anyone already have one they'd be willing to share, or a way to obtain one?

Sorry I don't have a firmware update log, but I have observed how the security check works that collink referred to on at least one of the control modules on the Leaf. To be allowed to access protected functions, first the diagnostic tool must pass a test that the ECU gives it. To start the test the ECU sends a pseudo-random number. Based on that number and a 'secret' algorithm, the diagnostics tool generates a 64-bit key which must be correct before access is granted. Apparently other vehicles in the early 2000s used a similar security system but with a 32-bit key which could be cracked by brute force. But with a 64-bit key brute force isn't an option. Also, because the ECU generates a different pseudo-random number each time, a single log of a firmware update wouldn't help with getting past the security - but it still would be very interesting to see. So it isn't exactly going to be easy, but all is not lost.

Also, I'm pretty confident that the Leaf isn't UDS compliant, although many of the commands are shared with UDS.

 

[nickandre]

Yeah that smells like RSA/asymmetric cryptography which will be difficult to crack unless you're the NSA. Easiest way to do that would not be sniffing but instead disassembly of code on the programmer itself to find the key, which perhaps is easier than hardware extracting the code off the ECU.

Anyone know if the firmware upgrade uses the Consult tool?

 

[NocturnalWalt]

Anyone know if the firmware upgrade uses the Consult tool?

Yes - Consult definitely can perform firmware updates on various control modules in the Leaf. Supposedly the following modules can have firmware upgrades:

VCM, LBC, Inverter, Instrument Cluster, High voltage A/C, Electric P/S, AV System, BCM, ABS, IPDM, airbag and head light leveller.

As far as I'm aware there are currently no other tools other than Consult that have the ability to perform firmware updates on any of the control modules in the Leaf.

 

[FalconFour]

I can at least pop in with my findings on the Jetsons noise question. :lol:

I dug through the VSP (Vehicle Sound for Pedestrians - or I've also seen Vehicle Sound Processor) module and made some discoveries. See here: http://www.mynissanleaf.com/viewtopic.php?t=20339

What I found was that, while the interior sounds (the little power-button sounds I call "Japanese Utopia sounds") are stored on the easily-accessible EEPROM chip, the exterior sounds appear to be entirely synthetic - generated by the sound chip's CPU and firmware. So, hacking those sounds is significantly more difficult than hacking the interior sounds - which I couldn't even get working. I think the CPU and EEPROM are chained together, by the CPU validating the checksum of data in the EEPROM before playing it. Making even a couple bytes' modification causes it to not play the sound at all.

Yeah, the security in the Leaf is pretty intense. Much of it stems not from Nissan trying to keep people from hacking it, but from the decades of experience they have in engineering and production - you want to be sure things are intact and functional before going to use them. They want suppliers and parts to work perfectly together, and they want their huge network of dealers and service centers to do things properly. Things need to be authorized, negotiated, and play nicely together all across the board. Making something break protocol would be a mess.

You practically have to be a Nissan ZEV engineer, one that actually worked on the LEAF team, to even scratch the surface of most of those wishlist items It was way easier on older cars that weren't so overly secure, but with so many little independent microcontrollers - no doubt there's at least one, maybe two, in the Guess-O-Meter alone - it's really hard to even get started on a simple thing like tweaking the exterior sound. :/

(though, granted, you could totally redesign & replace the VCM box... but... well, yeah.)

 

[Durandal]

Sorry I don't have a firmware update log, but I have observed how the security check works that collink referred to on at least one of the control modules on the Leaf. To be allowed to access protected functions, first the diagnostic tool must pass a test that the ECU gives it. To start the test the ECU sends a pseudo-random number. Based on that number and a 'secret' algorithm, the diagnostics tool generates a 64-bit key which must be correct before access is granted. Apparently other vehicles in the early 2000s used a similar security system but with a 32-bit key which could be cracked by brute force. But with a 64-bit key brute force isn't an option. Also, because the ECU generates a different pseudo-random number each time, a single log of a firmware update wouldn't help with getting past the security - but it still would be very interesting to see. So it isn't exactly going to be easy, but all is not lost.

Also, I'm pretty confident that the Leaf isn't UDS compliant, although many of the commands are shared with UDS.

Do you think this is really an asymmetric key situation, or something more simple that you see in a lot of Cisco devices for securing common password encryption like a 1 way function hash? So, (some key) + (psudeo random from ECU) -> Hash. This means also that the key that is combined with the pseudo random number is likely stored on the ECU somewhere, in addition to likely being in memory on the Consult tool temporarily. It makes me wonder if there is a way to get the chips from an older ECU and do a dump of the EPROMS. The easier method is likely doing a memory dump from the laptop that has the Consult tool loaded on it at the point it performs the authentication.

Anyhow, I found a bunch of what look like bootleg tools for Consult III Plus on eBay.
http://www.ebay.com/itm/new-Nissan-Consult-3-and-Nissan-Consult-4-Security-immo-Card-for-Immobilizer/221393470242?_trksid=p2047675.c100005.m1851&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D1%26asc%3D40147%26meid%3Ddcb1f39769654d66bbc5748a85fc6118%26pid%3D100005%26rk%3D2%26rkt%3D3%26sd%3D221559333940

http://www.ebay.com/itm/Latest-V34-11-Consult-3-Plus-for-Ni-ssan-Consult-3-Consult-2-Diagnostic-Tool/391456285331?_trksid=p2047675.c100009.m1982&_trkparms=aid%3D888007%26algo%3DDISC.MBE%26ao%3D1%26asc%3D40147%26meid%3D26ee4037e94b467f8f73a129595b6909%26pid%3D100009%26rk%3D1%26rkt%3D1%26sd%3D172300048309

I'm certainly interested to see what can be accomplished with the Leaf through some innovation by people a little smarter than me on the subject.

 

[triflic]

Telematics Question for those technically inclined.

I am a Canadian 2012 SL Leaf owner, but the car is AMERICAN. Even though I can talk to the Rogers Canada 2G cellular service, it was sending the information back to AT&T via 'roaming' 2G. When AT&T cut off 2G service, my telematics / App access has stopped working (i.e. no more updating SOC, or preheating vehicle, or capturing any other data in the system.)

I am wondering, if I can just move over to a completely CANADIAN access, my NISSANCONNECT app is already working in Canada as I was getting full service up until recently despite being no where near USA cellular towers. But the loss of the AT&T 2G has definitely broken the chain.

I'm trying to get in touch with a Nissan Telematics Engineer, but NISSAN-USA is putting up roadblocks to direct communication.

Have done a number of searches in this forum, and I've only found that there are at least 2-3 others with the same problem since Jan1, 2017.

Thoughts?

 

[explorer232]

Telematics Question for those technically inclined.

I am a Canadian 2012 SL Leaf owner, but the car is AMERICAN. Even though I can talk to the Rogers Canada 2G cellular service, it was sending the information back to AT&T via 'roaming' 2G. When AT&T cut off 2G service, my telematics / App access has stopped working (i.e. no more updating SOC, or preheating vehicle, or capturing any other data in the system.)

I am wondering, if I can just move over to a completely CANADIAN access, my NISSANCONNECT app is already working in Canada as I was getting full service up until recently despite being no where near USA cellular towers. But the loss of the AT&T 2G has definitely broken the chain.

I'm trying to get in touch with a Nissan Telematics Engineer, but NISSAN-USA is putting up roadblocks to direct communication.

Have done a number of searches in this forum, and I've only found that there are at least 2-3 others with the same problem since Jan1, 2017.

Thoughts?

You need replace TCU with one from canadian leaf and via nissan connect app pair new car with VIN stored in new (replaced) TCU.

 

[Jsprinkle]

I am a thoroughly geeky computer and electrical engineer interested in doing some reverse engineering work on my 2013 SV Leaf. To that end, it's probably worthwhile to identify the overall modules at work within the system and which can be replaced. For the intents and purposes, we can group modules by their interface to the main (CAN) bus as that is the level at which we can physically disconnect them using my crowbar and replace them with an open source component (FreeRTOS or Linux-based etc).

Assuming that we can't split the software for a single component without a fair amount of todo, we need to identify the entire set of required (drivetrain etc.) functions that any block implements at the CAN bus level before tinkering can begin. I think the first question to contend with is which portion of the Vehicle data is sent via the CAN bus. I'm going to assume (perhaps incorrectly) that, like in other vehicles, the CAN bus is relatively insecure, a lot (if not most) of the vehicle information is sent over it, and once access is granted we can snoop on the messages and figure out what does what:

1. What information is accessible via the CAN bus? Can we, for instance, read accelerator pedal position? Can we compile these functions into a big document?
2. What are the overall modules within the Leaf system that transmit each relevant type of information and how can they be grouped? Take (1) above and group them under their device, tally which are required for vehicle operation and which (if any) are superfluous.

Anyways, here is my list of hypothetical crazy ideas to make the leaf a really cool car (tm):

1. (probably "pretty easy" given the limited drivetrain-required functionality and lack of integration to other system components) Replace the entertainment system with a custom OS that can play FLAC files off the second SD card. Remove useless functionality (nav system). Replace the cellular modem with a 4G unit and network software that isn't implemented in such a fashion that it takes literally 3 days to download a JSON list of charging stations. Remove the polite voice that indicates the TCP connection state (what is this, 1980?). (Also I refuse to pay money to "upgrade" to a 2006-era cellular modem.)
2. Provide limited integration between the HUD and the main screen (why are there two entirely independent sets of settings?). Make the HUD useful (see 4).
3. Modify the drivetrain control. I'm not talking down to the SVM level - ideally we could simply alter the mapping of accelerator/break pedal input, eco, and B mode so that it wasn't absolutely and entirely foolish. B mode enables max regen down to a full stop, D mode doesn't enable regen without break pedal, and no god damn creep. Avoid destroying traction control and ABS in the process. Bonus points if we can alter the D mode break pedal behavior to engage maximum regen before mechanical breaks activate.
4. Provide real information on the HUD. Replace the GOM with kWH. Provide a single HUD display box that does efficiency, % charge remaining, KWh remaining, miles to empty for a CONFIGURABLE and not VOODOO MAGIC DERIVED miles/kwh. (Why the hell, despite there being plenty of room to display all parameters on one window, do we have to click through 17 of them to see what we want to see?)
5. Implement Cruise Control to match an efficiency requirement.
6. For the main system, use a cool API like google maps to attain estimated range given terrain for a route. Tie this into the above cruise control efficiency attainer to use altitude info.

Some of this is definitely easier than others. I would hazard to guess the modularity is less-than-ideal at a physical CAN bus level and that the embedded software would be hard to split apart, but I know others have done a fair amount of work at that level so we can at least ascertain the difficulty before I break out the crowbar, soldering iron, and JTAG programmer.

EDIT: I almost forgot: modify the vehicle sounder to make my car do the Jetsons noise.

Howdy Friend. I just got “kicked” off another string because I do not know the proper way to use the chat. Please excuse me for improper protocol while I learn.
I am very interested in someone or a lab that can look at and modify CAN buss data for the Leaf.

We simply need the Chademo port to connect to the traction battery without the car panicking so that we can access the high voltage and transfer to a home backup power system via a standard solar string charge controller.

Any suggestions? We have been looking since 2016 with our first lab Leaf and gave nothing but empty promises to show for it.
Even the Chinese setec unit we brought in only connected for a few seconds before the USA leaf firmware disconnected. Overseas they say this unit works fine. Nissan doesn’t like the idea for the USA apparently.

Thank you.

 

[KazooBruce]

I think the firmware is different in the USA leaf's. I am sure that someone knows the firmware codes somewhere, and could confirm it. I found out in this forum that our 2017 back up alarm could be turned off with leaf spy. But US DOT had Nissan move the setting into a section that could not be modified (like from RAM to ROM) in later models so it could not be disabled. I am afraid that no CAN command will allow two way power flow on the CSS port, changing the firmware or replacing the controller might be the only way to make it happen. I will follow this thread incase you do figure it out.