Can bus Hacking
 

Hi All,

I am from the UK and I am trying to hack the can bus on my 370z Nismo.

I have tried on the UK forums but not having any luck.

I am using the USB2CAN device from 8devices on Linux with the can-utils package. I connect to the device in terminal using the command:

sudo ip link set can0 up type can bitrate 500000

Then I send the command:

cansniffer can0 -c

I have also tried sending the messages:

7E0#1081 to start a diagnostic session
7E0#3E01 for keepalive

I am not getting any results back. Does anyone know anything about the USB2CAN device? I noticed that some of the guys on here are using the CANUSB device from Lawicel, what is the difference?

If anyone could help that would be great.

Thanks,
Mike.

Subbed.

Have you tried using dmesg and lsusb commands? Or USB2CAN_TEST.py (manual says you can download it from web)?

I will give that a go at the weekend, thanks.

I'm not sure if others have done this; I couldn't find any tools to do so, but I was able to dump my stock ECU ROM over the OBD port.

I was hoping that UpRev would give me my stock ECU ROM, but it looks like whenever they read it, it's stored encrypted on the PC

I found a work-around for that. I put it on my blog
https://leftoverpi.com/2020/01/23/re...-370z-ecu-rom/

I would like to help get more support in ROM Raider for the newer Nissans

I'll add more information to the threads when I get home from work.

Thank you for sharing the raw ECU dump! This will be VERY useful.

I discovered something interesting today. I want to put a little more work into documenting these undocumented PIDs (especially the conversion calculations). Uprev obviously knows all of this already because they can log everything with no problem. My intention was to snoop on the CAN bus while each of these PIDs were being requested one by one. I made a special cable that would allow me to pull a man in the middle on the PID requests. The CAN lines are interrupted which allows me to monitor the bus with my laptop. This is how I was able to read out my ECU ROM.

https://leftoverpi.com/wp-content/up...8-1024x768.jpg

So I started my CAN logging software on my laptop and started logging in Uprev, hoping to see the PID requests for each parameter one by one. Logging in Uprev was working and I could see correct parameters. I couldn't see it in my CAN bus logging software. I was trying to troubleshoot and noticed that I never connected the CAN lines together. So Uprev does all of their PID request logging outside of the CAN bus lines. I was thinking it's coming in over K-line, but I looked in the FSM and I didn't see K-line being brought out to an OBD pin. We have a K-line BUS but if I remember correctly the FSM says that it's for internal use only, for modules to communicate with each other. Does anyone have any info on this? If I can't see K-line traffic I'm going to have to put a scope on the vendor specific pins, and I REALLY don't want to do that inside of the car.

The latest documentation I have is for a 2016 370z, and I don't think Nissan would have changed anything since. Based on the ROM you posted, your 370 is from 2017 and I would expect it to be the same.

The K-Line is still on pin 7 of the OBD connector and goes directly to pin 117 of the ECU. Nissan sometimes calls it "K-Line" and sometimes calls it "Data Link Connector"

Try this test:
• With the CAN bus not connected, log data and look at the time between samples. The UpRev log shows time in milliseconds.
• Hook up the CAN bus and run the data logging program again.

Since the K-Line runs at 10,400 bits per second, and CAN bus runs at 500,000 bits per second, I would expect the time between data to be much faster with the CAN bus.

I suspect the UpRev software checked the CAN bus for communication, didn't see it and "failed over" to the K-line.
This would allow them to use the same code for older cars (before 2008) that don't have CAN bus.
I look forward to your test results :)

Thank you for this. I will try it later today

And my car that the ROM came from is a 2017 6MT base model

Crap... I messed up when looking up the ECU ID: 6GE2C = 2017 370Z MT

Do you have any other resources for the ROM format or CAN bus PIDs? I've been posting on the romraider forums and I'm going to put the ROM in Ida. Any clues you have will help with the disassembly

... my end goal is to get 370z ROM support in romraider, so we don't need Uprev or ECUTek. I think they have some limited support for the 350z generation, but those ECUs used a different generation micro, and they are 1MB while ours are 1.5, so I'm sure the tables will not line up

Subbed

I keep running this through my head about how to uncover these tables. Uprev stores the ROMs heavily encrypted on the PC, but when flashing it has to be decrypted. I wrote the software to regenate the ROM from the CAN bus log, so I'm thinking of using Uprev to give all cells in each of the tables the same constant value, and using a different value for each table. This way we can flash, recover the ROM from the CAN bus log, and look at the disassembly to find the table addresses from the eyecatcher numbers we put in. I don't want to do this with my ROM though. (I haven't flashed it yet because I am still under warranty). If I buy an ECU off eBay do you think I'd be able to flash and interact with it without having the immobilizer running?

subbed

So I'm sitting here in the car right now and I'm not seeing any PID requests come in over CAN. I even did an ECU dump to make sure that I was seeing that traffic in my log and that it wasn't being filtered out. Maybe uprev makes all it's PID requests over K-line?

Data is being logged @ 50hz so the bus isn't being saturated at K-line speeds.

Wow, that is odd to me....
Are you seeing any CAN Bus activity? I would expect to see activity using service $21 or $22.

How is your CAN bus sniffer set up? Pass through or listen only?
Are your filtering out every CAN ID below 0x700? -OR- just allow -7E0 & 7E8

Since your Z is from 2017, I would be surprised that they would use the slow K-Line.
BUT maybe they are using the K-Line with the NDSIII protocol? I don't know...

Well... This is VERY interesting. For those interested in making a copy of their ECU ROM, "VQ_Crazy!" on romraider has designed/built/programmed a cheap ($15+) Arduino based, CAN bus hardware solution using the OBD port to copy the ECU ROM to an SD card in 3-4 minutes!

Details are here: https://www.romraider.com/forum/view...p?f=65&t=17089

Just to put this in perspective, this is the first step to being able to tune and update our own ECU ROMs for VERY little money.

I think this will be a good first step to "open source tuning" for the 2008+ (CAN Bus) ECUs.
What do you think?

I wish I did. There is a little bit of info on RomRaider and I suspect you have already gone through it.

I have not done any disassembly in about 30 years and can only imagine how complex the 32 bit RISC ECU firmware would be.

I think the best starting point is to see if anyone has mapped an HR and use that as a starting point. As time permits, I will try the free version of WinOLS. I hope the learning curve isn't too steep.

I see full CAN bus activity from the vehicle on all expected IDs. I do not see any CAN activity from Uprev during logging. I DO see CAN bus activity from Uprev:

• When starting Uprev (reading VIN and other data)

• When dumping the ECU

• When checking and clearing code

It's not a filtering issue because I see IDs all the way from 2, to whatever tester IDs Uprev is using (I forget all of them)

As far as reading the bus, I'm using a Vector 1610 with Vector:s CANalyzer software. I can fully interact with the bus and send arbitrary messages.

I'm not familiar with the NDSIII protocol. I have plans to reconfigure my snooping cable to allow me to listen on K-Line also.

I did see that post before and its interesting for sure. I was thinking about making an add-on board to a RaspberryPI for this, which would be a cool project (I've mad a few add-on "hats" as they call it, it's not too hard). What has kept me from doing that is because I have access to some of the best CAN tools in the industry through my job, so that keeps my motivation for this low.

I post on ROMraider under the name LeftoverPi

As you suggested I'm sure the 370z ROM format follows the 350 pretty closely. The 370 ROM is 1.5Mb versus 1.0 for the 350. Best case scenario is that it's the same format as the 350s with the HR engine, with an extra .5Mb of unused space. I'd imagine it's more different for the older 350s with the DE engine.

I have the tuner version of Uprev, so I think a good start is to look at the tables that you are allowed to edit, and compare that with what I see in the ROMs disassembly. I can then cross-reference this with what we know about the 350 ROM structure.

Phase 2 would be to make very obvious edits to a table in Uprev (eg setting all values in one table to 3, in the next table to 4, etc). I can then flash and reconstruct the ROM again to see where these known values end up. For phase 2 I'm going to eBay an ECU to do this on the bench; I don't want to do this with my own ECU. If anyone has an extra one sitting around that they can sell for cheap (or donate!) this would would be a good cause!

Off topic. If successful, could you complete disable vdc?

Not through Uprev or software like ROMRaider. But you put a switch on the yaw sensor box and turn it off when you want it completely disabled

I have only looked at a few ROMs, but Nissan seems to move the tables around much more than I would have thought. I'm not sure the 350 ROM definitions will be helpful to find the 370 tables.

Also factor in some CARB/EPA required changes that were mandated around 2012, which may require more program space / ROM.

I know EcuTek creates their own higher resolution tables in different locations than stock, and UpRev might do the same, so please keep this in mind with your testing.


I look forward to your update on the K-Line. Since it runs at 10,400 baud, I guess UpRev could use it and still get a fast sample rate.

Trying to locate DTS