RomRaider

After reading the two pages, it looks like it shouldn't be difficult to dump an ECU using CAN.
-or- did I miss something?

Over the weekend, I will manually (via terminal) send the first few commands to my ECU and see if it responds the same.

My ECU (1NX4A - 2011 G37) supports K-line and CAN,so it will be interesting to see what happens.

what result?

I haven't looked at any code or ROM disassembly, but "I have heard of" (more than one) OEM that use a RP160 hash to determine if an ECU should be reflashed. Basically after a new SW is flashed to the ECU, it will calculate the RP160 hash over some or all of the ROM and store it to NVRAM. As part of the programming sequence, the test tool will request this hash from the ECU and compare it to it's own calculation of the hash over the ROM that it wants to load. If the hashes are equal then no flashing occurs.

So I got my Uprev cable and it was finally warm enough to go out and take a dump of my ecu (2017 370z). I was interested in taking a look at their ROM Editor software in IDA, but it turns out that they use one of the more sophisticated obfuscation tools (Themida/WinLicense), and I want no parts of that right now (I'm a little surprised by this because I thought Uprev had a tiny dev team). In any case, I'm sure the .bin that was saved on my laptop is obfuscated too. I have a full CAN log, so I'm going to do a quick sanity check to see if the transferred data is what's actually showing up in the .bin file. If it's been obfuscated then I should be able to write a quick perl script to reconstruct the ROM from the CAN log. Is there anything that anyone is interested in me taking a closer look at while I'm in there?

Attached the CAN log from dumping my ecu with Uprev's cable+software. I will wait to post the bin to see if they've screwed around with it, or if it's straight off the ecu.

2017 370z base model 6MT

Moderator: ROM removed, please read posting rules before submitting ROMs or maps.

I read the forum rules and I'd like clarification as to why my upload was removed. It is neither a ROM nor a map. It is a CAN log of an ECU dump.

Thanks

I think it's too close to being a commercial-tuned ROM - I didn't check the log but it's probably not very difficult to extract Uprev's custom ROM from it, and that would be a problem.

What did you want to learn from that log ? if it's just the stock ROM you want, nissan-techinfo might have an update .dat for your ecuid already.
If it's the dump process you're interested in, then I think you could probably post short extracts of your log (maybe just the first few % ).

But it wasn't UpRev custom ROM. It's a dump of a bone stock 2017 370z. I took a CAN bus log while the stock ROM was being read. There's nothing special about the CAN log; just a bunch of service 0x23 requests. I posted it because I can't find any ROMs for a 370z and I'm going to reconstruct it (again, there is nothing proprietary. If I didn't use the word Uprev in my own post it would be impossible to know). I don't believe this violates any forum rules

... It feels like the moderator just saw that there was an attachment in a post with the word "Uprev" and deleted it without bothering to understand what its really referring to.

Yes, I also would have assumed it was an Uprev base ROM just reading the last few posts. It was easy to make the connection, don't take it the wrong way. I think it's OK to repost, as it's pretty much equivalent to posting a stock .dat or .bin

If it had been one of their ROMs, it's fairly easy to recognize once reassembled anyway.

That's really what I was getting at; whether or not I should be OK to repost that. I'll be more clear next time with my wording lol.
I wrote a small tool that I believe will reconstruct the ROM .bin from the CAN log.

Unfortunately I can't find a stock ROM from my vehicle to verify. The ROM I constructed looks to be right, but I need something concrete.

I'm going to throw this one out there to see if anyone can help:
Does anyone have a CAN log of an ECU dump AND the resulting ROM binary that was dumped. I'd like to run the log through my tool and verify the output is correct.

I even tried flashing all 0xFF and all 0x00 to the ECU (in my case tool was only flashing area from 0x8200 to 0x80000) and I do have such logs if you want to experiment.

writing for all 0xFFs was loking like this


flashing all 0x00s gave the below log



Didn't have much time and motivation to finish this up yet

My approach for that scenario would be to make sure you got an even 500k/1M/2MB file, then decrypt it if necessary (usually standard nissan algo for repro files, but a SID23 dump should be plaintext). And last, run nisrom on it - if it find all expected checksums, it's almost guaranteed to be ok.

If not, I'd check the beginning and ends of the ROM - first hundred bytes or so should be a valid interrupt vector table; the end should be mostly blank (0xFF) except a 4-byte signature that looks like 'NHU.'


@Shuher: you probably figured this out already, but in case it wasn't clear :

would split like this



And again the data is encrypted with nissan's standard algo, it is recognizable by producing 4-byte patterns when encrypting constant data.

I didn't From the time we were discussing it I didn't bother much in CAN reprog as I purchased a commercial tool for it, which I used only 3 times maybe.
So thanks for clarifications, you saved me couple of evenings with IDA - I still have a plan to finish K+CAN cable support in nisprog (it's about 30% ready now) and then make the CAN reprog happen with this nice tool.

But this will happen after I complete ASCD algo dissection - such a wierd stuff or I just dumb

Thanks for the suggestions; I think I may be on the right track. The ROM that I reconstructed is exactly 1.5MB in size (which I've read is the correct size for Z34s). The first 0x398 bytes is a repeating table, and the end of the file is padded with 0xFF. I see the "NHU" signature 124 bytes from EOF. I also have another checksum (?) at the very end; it's 6 bytes.