RomRaider

[EDIT]
This thread should be considered locked / for reference only; I'm probably not going to update it any more. Do not use the nisprog builds here, they're obsolete.
The latest and most accurate info will be found on the nissanecu wiki.

Reflashing K-line ECUs is possible with nisprog and a suitable reflash kernel
nisprog thread
reflash kernel thread
[/EDIT]

Hi people,
I worked very hard this last spring to find a way to dump + flash Nissan ROMs, specifically for QR25DE ECUs but in general for Consult-II ECUs. My target is a 2004 Sentra Spec V, and I wanted to fix a very annoying throttle-hang problem when shifting.

Well I fell a bit short of my objective, but I managed to make an OK tool for at least dumping the ROMs. I was inspired by member "jaf" on the NDS forums ( http://home.exetel.com.au/nds/phpBB3/vi ... f=10&t=148 ) , who took the brave approach of tapping directly into the CPUs diag port. From his original ROM, I reverse-engineered some of the firmware and found code that allows, over an OBD-II link, to read the ROM without opening the ECU. Very nice.

Since I'm also the current maintainer of the freediag project ( freediag.sourceforge.net ), I ported freediag to Windows and added some Nissan-specific features for ROM dumping. Those features will only work with a dumb serial interface (rs232->level shifter-> OBD2 K-line), but the dumping algorithm itself should definitely work with standard J2534 hardware. The transfer will remain slow however (it took a lot of work just to bring the transfer speeds to 11ms / byte, which is not even fast). So, recent tactrix/other J2534 interfaces will NOT work.

I want to document the dumping process, but until I write something nice & clear, here is an overview of the algorithm :
1- connect to the ECU over the OBD2 K-line @ 10.4kbps, ISO14230 protocol with fast init. Tester addr = 0xFC, dest addr = 0x10, physical addressing;
2- to dump ROM data, use a mfg-specific service ID (SID 0xAC) to request invidual address(es), max 12 per request
3- then use the standard SID 0x21 (ReadDataByLocalIdentifier) to retrieve the requested bytes
4- rinse & repeat

With the help of "jaf" on the other board, we found a lot of maps in both our ROMs, some similarities and some differences. In order to be able to re-flash the ECUs through OBD2, one would still need to figure out :

1- what & where are the checksums in the ROM ([EDIT: mostly solved, see next posts])
2- reverse the SID 0x27 SecurityAccess and SendKey challenge/response algorithm. [EDIT: solved, see posts #9,#10]
3- reverse the SID 0x34 (RequestDownload) code in the firmware to see how to send the new ROM data. [EDIT 2016: solved ! see posts much, much later : )))]
4- SID 34 actually lets you send a "payload" that you then execute. In other words, "arbitrary code execution". Solved"
5- The payload needs to take over the mcu and accept commands to do the reflash; this is the "reflash kernel". 2016/07: Pretty much solved too !

I know RomRaider is very Subaru-centric, but maybe some people here might have some interest in this... and I'm not sure where else I would post this. Since the reflashing process is of course J2534-compliant, I see no reason why Nissan reflashing could not be added to Romraider once we figure it out.


Here is how I use the attached "nisprog" build of freediag to dump my Sentra's ROM : (consult the included docs for more info) [EDIT 2015/11: this is approximately equivalent to building the latest git tree of freediag with nisprog enabled; the exact commands to enter may change slightly]

*****************
// run scantool.exe first; the following commands are entered at the scantool prompt
set
interface dumb COM3 (or COM2, etc. you may need to try "interface dumb \\.\COM7" for some serial ports)
dumbopts 0x48
l2protocol iso14230
initmode fast
addrtype phys
destaddr 0x10
testerid 0xfc
up
diag
connect
// this *HAS* to work, should say "connection to ECU established")
np 0
// this *HAS* to work, you should get the ECUID)

//then, to see if dumping will work:
np 5 0 1023
// this will dump the first 1k of ROM data on-screen, and to a new "rom-<ECUID>.bin" file.
//Make sure this data is coherent i.e. not all 0x00 or 0xFF, and no failures during transfer

//If all's well, delete that .bin file and try :

np 5 0 524287

// for a 512kB ROM. The fastest I could make this go is about 11ms/byte, so around 90-100 minutes for 512k dump.
// It would be wise to have the car battery plugged to a charger during the process.
// NOTE : if the transfer fails, it is possible to resume the dump by modifying the start address.

>disconnect
>exit

***** Notes *****
- run as few programs as possible while freediag is running.
- temporary disabling sleep / hibernate / other power-saving features may be required to dump a full ROM
*****************

My ECU (2004 QR25DE) has an SH7055 with 512kB flash. Some ECUs may have larger or smaller ROMs, according to the specific SH chip used. It's possible to make an educated guess without opening the ECU, by dumping the first 0x4000 or so, and looking for strings like "SH7058" . Many ROMs will have two such strings; one is near the string "LOADER" and is not necessarily the actual CPU type. The other occurence, typically later in the ROM, is the actual CPU. To be certain would require opening the ECU, getting the CPU part #, and looking up the datasheet.
Or maybe just trying "np 5 524288 524289"; I think the ECU would generate an error when requesting invalid addresses. I haven't confirmed this however.

This sounds like an interesting project. RomRaider is not a flashing tool, only Editor and Logger right now. For flashing we typically use EcuFlash from Tactrix. EcuFlash supports the SH processors but probably not the specific SeedKey for the Nissan ECU. I wouldn't be surprised if Tactrix already knows this but it's not part of their free product line.

Can you use a VAG-COM KKL cable with this?

Ah, I thought I saw a "ROM->flash ECU" menu command somewhere in RR, my mistake.

[EDIT] Yes, I tried with a super cheap ebay VAG KKL 409 cable and freediag works quite all right on at least my computer.[/EDIT]

For more info on supported hardware :
http://freediag.sourceforge.net/dumb_interfaces.txt
http://freediag.sourceforge.net/Support ... faces.html

In short: a working interface typically shows up as a serial port on the computer (either a virtual serial port, such as USB-RS232 devices, or connects to a real physical RS232 port), and ONLY converts voltage levels between TX/RX lines and the OBD K-line. They can be built with a few optocouplers, transistors, or an MC33290, etc., typically very simple circuits. ELM32x-compatible devices will NOT work though; at least not for a while. I think many bluetooth-OBD adaptors are of this ELM32x type, and probably won't work.

Fortunately SH7055F and SH7055SF maybe read via AUD ( provided AUD is not disabled at the very beginnng of the code ) and maybe written in bootmode.
Checksum maybe found and recalculated ( that may be not a simple task for Hitachi ecu ) or completely disabled.

The question is as follows.

Does the way to upload the ROM is applicable for a previous ecu generation ( MY99\MY00 QG engines ) based on obsolete SH7051F chip ?
This would be very helpful since those chips do not have any applicable diagnostics hardware interface.

Haha well I dug up my annotated Xtrail ROM and apparently I was more advanced than I remembered. I think I got the checksum algo mostly worked out; now thanks to the magic of XORs I was able to hack a basic checksum finder that locates the two checksum longwords in a ROM dump. It works with at least two QR25DE ROMs succesfully, but not a diesel ECU ROM I had (ECU # 23710-EB310), so there may be variants to the algo...



If that generation works with Consult-II (which is probable according to http://www.nastf.org/i4a/pages/index.cfm?pageid=3474 ), and is J2534 compatible, it may work. I'm reversing the J2534 reflashing protocol, so if your ECU uses something else, I can't help !

Of course there is still a lot of work to do before we can reflash ECUs. As I said, the only things I have so far is ROM dumping and preliminary checksum verification. The AUD port is what jaf used to succesfully reflash his ECU; I have no experience with that method.

Since the way to upload the ROM is already found you do not need AUD at all.
SHbootmode hardware is as simple as an apple pie and is described inside the RomRaider HowTo thread.

That means you are already able to tune your ecu provided the checksum algo is found and hacked or disabled and an applicable ecu definition is developed.

In bootmode you may also substitute the primary or secondary ecu bootloader with your own one for later ecu reflash thru k-line or CAN interface.

Could you upload some stock Nissan ROMs here as a base for further discussion ?

If I understand correctly, SHbootmode requires opening the ECU, and assumes that the FWE and MD1 pins are not hardwired, and that TX1D and RX1D are not connected to something else. I don't know if that's all true with Nissan ECUs...

If so, then you're right we can already reflash Nissan ECUs with SHbootmode, because:


See my previous post, I think I have the checksum algo pretty much solved. I've just tested with a 350Z ROM and it also worked. I think it's simpler, if modifying a ROM, to generate the correct checksum instead of trying to find + bypass the checksum code in the firmware.



No, I think it's against this forum's rules. But follow the links in the first post of this thread, you should find an X-Trail ROM, my Sentra ROM, and if you're clever you'll also find a 350Z ROM on that forum.
Do you have access to a Nissan ECU ? Could you try connecting to it with freediag or nisprog if you have the necessary hardware ?

I do have an applicable hardware for SH7055 based ecu hacking and flashing.
I am clever enough to find an SH7055 based Nissan ROMs and overcome checksums.
Those checkSums maybe hacked and recalculated later if time permits.
More recent Hitachi ecu's use much more complicated chechsums that probably are not reasonable to be hacked.

But.
There are MY99-MY00 Nissan ecu's based on Hitachi SH7051 not having any applicable diagnostics port. This is a problem to tackle and I hope your upload solution maybe helpful.
There is MY02-MY03 Nissan ecu based on JECS remarked Mitsubishi M32R that is completely another animal but your approach may be useful as well.

I had some free time yesterday and worked on the key algorithm. I've found two different algos, but I think one of them might be more widespread (it's the same on 3 different ROMs I have). Here's how the handshake works:

1- tester sends 0x27 0x01 (SID 27 SecurityAccess, RequestSeed);
2- ECU responds 0x67 0x01 S3 S2 S1 S0 (S3..0 is a 32bit, pseudo-random seed)
3- tester calculates key and sends it: 0x27 0x02 K3 K2 K1 K0 : SecurityAccess, SendKey (a 32-bit key).
4- If all's well, ECU responds 0x67 0x02 (positive response).

The ECU and the tester must use the same algo that uses the seed and a 32-bit encoding number ("scode"), and so the key sent by the tester must match what the ECU internally calculated.

key = genkey(u32 seed, u32 scode);

I've attached the disassembly of that key generating algo from a Sentra ROM, and some ugly C code that duplicates its function (tested in a SuperH simulator).

Now here's the catch: the tester must use the same "scode" as the ECU. Of course the ECU never gives out this number, but it's always somewhere in the ROM. It's not at a hardcoded location, but it's not too hard to find (hint : 3 ROM's I've seen all use RAM location FFFF8408 to store the calculated key, so any code that writes to that location is probably relevant). On the last ROM it took me <10 minutes to locate the scode.

What I don't know is how the Nissan J2534 software handles this, does it:

A) have an internal database of all known ECUID - scode pairs ?
B) have an automated way of extracting or guessing the scode ?
C) have a magic algo to generate a key without the scode ?

I would lean towards B) but that's as far as I got. I'm going to test this SID27 exchange on my Sentra in the next few days, and add it to my nisprog build.

[EDIT] In the process of reversing the Nissan J2534 software, I've determined that the answer is more or less A). When loading a .dat file (the ECU flash update typically purchased from Nissan), it loads the necessary 32-bit scode from that file. So I guess all ECU firmware revisions within a family (probably related to part #) use the same scode.

Done and done. It works on at least 1 car, but may be fragile. For example, after a successful SecurityAccess request, some SIDs will no longer work (like SID A4, read single byte), and trying it anyway may cause nisprog to crash. I'll investigate this later.

So, the "only" thing left to figure out in order to reflash Nissan ECUs is the method of transfering the new firmware.

Anyone else here with a Consult-II Nissan and a dumb (basic) OBDII cable ?

Ha, ha. (I posted the following to ecuhacking.activeboard.com too) . I made some progress, but no dice.
I can see when and how the data is transfered to the ECU :

- SID 27 exchange : state=2
- SID 34 80 RequestDownload; does a weird thing with interrupts and some ports, and enables SID 36 (state=3)
- SID 36 TransferData: decrypts incoming data (with the same algo as SID27 exchange, easy) and copies to RAM @ FFFF8438
- SID 37 TransferExit, state=4
- SID BF 00 ReqRamJumpCheck, doesn't seem to do much
- SID BF 01 ReqRamJump, state=5
- ???
- SID 34 81,
- SID 34 82 (requestdownload for "CPU1 area" -- probably to prepare the actual "bitstream" to be flashed.
- Actual ROM bitstream; unknown format and probably not iso14230 any more but a custom bootloader protocol.

At this point, I'm screwed because :
1) I don't know what code has been loaded at FFFF8438, but I know we "jsr FFFF8438" to there at some point so it has to be a type of bootloader

2) I don't know at what time the bootloader in RAM takes over the control of serial comms, and how. It can't be interrupt-driven since the IVT
could be erased at any point during reflashing...

3) If there are a few different versions of bootloaders (for different ECU hardware, CPU etc) I'm not sure how to handle that. It can probably be position-independant code to some extent (i.e. I'm not sure if every ECU loads the code at FFFF8438 so there can be no absolute memory references), but it has to take into account different CPUs (sh7055, 7058 at least), and possibly different wirings (i.e. do they use the same SCI pins)

4) There is *no* way I'm going to write and test a bootloader. I have only 1 ECU and I kind of need it, so any experimentation has to be relatively safe. That excludes trying to roll my own BL.

So, given the lack of interest and help, I'm taking another break from this.

1) This is bootloader start for SH7055F. It is most probably different for others.
2) At bootloader hardware init section an applicable SCI port is initialized and may be interrupt driven since InterruptVectorTable may be assigned anywhere including RAM
3) Bootloader code is different for SH7055F and SH7055S\SH7058\SH7058S. SCI ports and probably watchdog pins are not the same for different ecu generations.
4) Having made an applicable bootmode hardware you are free to test you own bootloader code without any risk to completely brick your ecu.

I'm sure glad I found this thread! I've been hacking / reverse engineering the nissan code for quite some time.

I have quite a few security keys for different vehicles (took a long ass time but I got them) and yes your security key you posted is exactly what I have for a 8U901 ECU.

I'm glad I'm not the only one trying to do this, I thought I was alone in the woods on this one haha

What I really need is a way to sniff Consult. (I have consult 3+, many cables and half a brain lol)

From what I have noticed, you send the key and then consult will upload the bin via CAN in about 40 seconds. Not sure if you can upload via K-Line doubt it but I'm no engineer here.

Hopefully we can get this project off the ground, I own a G35, 350z and have about 6 ECU's SH7055 (512kb) and SH7058 (1mb)
laying around my office so if I can help, I definitely will.

*edit* already made a XML for a 2003 350z for EcuFlash shows most tables I've found. I'm playing with the VQ's as that is what I own. Oh and your program works with a tactrix 1.3B cable, confirmed right now fyi in dumb mode

Jason

Cool. I've also collected a partial list of ECUID + key combinations, we should combine them. Maybe it's time we had a Nissan subforum on here ?


Maybe we can put those to good use ! sniffing Consult transactions will give a lot of info. Tell me more about your C3+ setup...
- is it the official standalone laptop running winXP/win7, and C3+ software ?
- is it a random laptop running C3+, plus a clone hardware gadget ?
- How does it connect to the C3+ hardware (USB/serial/bluetooth/wifi?)
- Does it use a J2534 dll ? If so, it's fairly easy to tap into the j2534 dll calls and log everything that goes through. This would be veeery efficient.
- If it uses a serial port (either physical, or a virtual COM port over a USB or wireless interface), I think we can find software to sniff the comms at the software level
- As last resort, we need to do the sniffing at the hardware level, probably at the OBD connector. A) Sniffing the K-line is straightforward, since you could just connect your openport 1.3 cable to the K-line (while the C3 is connected obviously), and load up any serial terminal software and log the data as it goes through. B) sniffing the CAN bus might be a bit more work, but very doable. I think a cheap ELM327 interface can handle that (not your OP1.3 though)


40s !? Interesting... Just dumping the ROM is about 90 minutes through the K-line !! I use it because that's what I have (my 04 Sentra has an internal CANbus that isn't wired to the OBD connector), and at least on some models that's how reflashing is done.

So I understand you can "simulate" a real, official factory reflash ? So you have access to some Nissan .dat files ?


Nice, those SH7055 ECUs should come in handy. I'm keeping my eyes open for one that I could use for tests, but they aren't cheap. Are you equipped to do some hardware hacking? (soldering wires to the PCB, nothing worse) - I'd be curious to try the "SHbootmode" trick that Sasha mentioned earlier.


Glad to hear that !! I've had exactly 0 feedback so far, until your comment. Which version did you use ? What commands did you try ?
(Note: neither will support CAN bus, unless some valiant programmer shows up to implement it. It's too much work for me)

Hi Everyone,

I wanted to see if I could revive this thread. FYI, I am a mechanical engineer and have limited programming skills/knowledge but have taken a few programming classes and am very interested in learning, especially regarding this project. I have a 2006 VQ35DE 350Z and from what I can gather it most likely has a Hitachi ECU with a SH7055 chip but I still need to confirm. I've read/downloaded everything I can with regards to reflashing the Nissan ECU's. I also have Nissan Datascan 2 which I have done some logging in but cannot figure out how to dump ROM from that program even though people say it can be done. Nisprog looks like it works well for dumping ROM though.

fenugrec - it seems to me like you are 95% there to reflashing Nissan ECU's, I was just wondering if you, or anyone, has successfully done this. At this point you can dump the ROM and edit parameters, its just difficult to reflash the information back onto the ECU correct? I'm confident this can be done by engineers on opensource forums considering UpRev provides tuning software that can accomplish this (at a steep price), so why can't we... right!? Nissan even has free software available (Nissan-CONSULT-II-Reprog) that is capable of reflashing Nissan ECU's if you have the right hardware (which I would assume could be emulated).

What's the next step and how can I help?

Thanks