RomRaider

it would probably help if you posted the bin files

Right, sorry. Been a bit ADD.
I found the RNA bin somewhere around the net before I successfully pulled the PZX bin.

Hmmm, I think one of the areas that's tripping me up Is indirect referencing of jump destinations stored in ram. I'll find code like
mov.l #dword_FFFF2810, r1
Jsr @r1
And checking the xrefs for that ram address only yields refs in the current code segmemt
That particular piece is at 0x3A8C in the PZX bin and looks like its part of the flashing code.
I did just find that I can edit ram values so I'll tinker with that tomorrow.
Has anyone tried loading an AUD dump of ram in the ram segment before?

Feel free to load the code \data into the RAM area.
This is a common way for hacking\upload an applicable loader.

Use free RAM area for code and data and stack area to hook up control.

I was actually thinking of loading a ram dump into the ram segment in IDA. I still hadn't gotten my breadboard FTDI AUD interface working so I loaded the ROM into HEW and stepped through the next function tree referenced by the Power on Reset function and adjusting branch conditions values to avoid branches that lead to functions that jump back to themselves(probably waiting for an IRQ). Once that got run through I saved the address range for RAM as a bin and loaded it in the RAM segment in IDA and reran the analysis. Turns out those orphaned chunks of code that work with FLASH_FECS and FKEY get assembled as functions in RAM so I'm guessing the big function tree at 0x1EF0 (in the PZX ROM) will setup the flash routines if calibration verification fails, but I'm still digging though. I worked my AUD interface so I'm grabbing a RAM dump from an idle state ECU and seeing what IDA sees. Also gleaned is the function at 0x8008 jumps to what looks like the main function tree and is a common entry point to the user program portion of the ROM for Honda Keihin ECUs built on the sh7058, at least as far as the dumps I've looked at.

Ecu running is not obligatory reload the flash \ flash control code into the RAM area.
You have used the correct way by putting the code to be investigated into the RAM IDA section for analysis.

My advise is to investigate what free RAM area maybe used to load you own flashing\monitoring code and how to get control to run the code for future development.

I thought I had the kinks worked out of my ftdi aud interface but it looks like I'm still getting some cross talk. Its too bad the Piasini doesn't support dumping ram. The PZX ROM does support UDS SID23 Read Memory by Address but it looks like it needs SID27 security access. I'll check for SID3D this weekend

Attached some bins.
37820-rbb-e54 is dumped using Piasini from mine ECU (04 Accord EX K24). Unmodified.
I don't know history of rest of them (ori/mod,checksum etc), but maybe they'll be helpful.

Also, found script which extracts firmware from RWD: https://github.com/gregjhogan/rwd-xray
Unfortunately didn't manage to rip all signature types (got assertion errors) but readme contains a lot of valuable information.
Looks like new thing, keeping fingers crossed for dev.


Extracted, uploaded if you still need it.

Good find on that script, I hadn't seen it before. It looks like it trips up once it get to the flash address and length, it's off by a byte for the PZX and it trips up the rest of the decode. I'll try to fix or reimplement it tonight. Sorry I didn't get back to your PM. I did manage a good dump with a piasini, I just couldn't get the ftdi method working. I've got a handful of other dumps and I'll add the RBB to the collection to compare code structure. Don't know if anyone else has looked at these, is that a full IVT at 0x802C in at least the PZX and RNA ROMs? I can dig through the RBB and RWT tonight as well

Hmmm...I think the algo is wrong in that script. I shifted everything by one byte and the output is the right length, but doesn't match the AUD dump

Edit: not everything, just everything after the designated key

What ! more than 1 person collaborating on disassembly ! awesome.

I think you guys are on the right track, if as I understand correctly you have
- complete unencrypted dump from AUD
- sample J2534 traffic ?


+1 ! It might not be easy to find, but probably there. Look for non-standard SID handlers that

- accept large packets, copying to RAM (with / without unscrambling)
- jump to an address in RAM

As you probably noticed, the code that does the reflash needs to be copied to RAM and executed from there. You cannot run from ROM and reflash. The "lower 32kB" code found might be for initial factory programming, but could also be used for normal reflash. In the Nissans I'm familiar with, there is a similar "early kernel" like that but isn't used in normal J2534 reflashes.

My thoughts on that code where that's more than likely at least a fallback if the calibration has a bad checksum but it could also be with the right RAM variables in place that's where it goes when the Session Control changes to Programming as I haven't seen anything like a kernel cross the can bus, only the reflash itself which matches the reflash file with the header and trailer stripped off. I've got this next week for spring break so I'll begin poking around SID2E and SID3D. I think with SID27 auth SID23 could dump at least 0x8000 and on on the 7058 ecus Unfortunately I think my bench ecu is toast. I've got a backup but I'm hesitant to crack it open

After some fiddling with rwd-xray I got it to decode the PZX and RNA rwd files, it still needs some tweaks for 7254 based calibrations. I wonder if these could be loaded into IDA or HEW if one mocked up a bootloader with an IVT and jump to 0x8008(for the sh7058 calibrations). That might get things rolling for the ecus that we don't have full dumps yet. Props to Gregjhogan on github for his tool rwd-xray!

Of course - just choose to load the file at a specific offset (tick "Manual load" and make sure the ROM area is setup properly). If you can live without the default IVT @ 0, you can even leave the first X bytes empty, IDA won't mind.

I went ahead and forked rwd-xray with the fixes for canbus calibration compatibility (https://github.com/dnigh/rwd-xray). I guess at this point people could start working on romraider definitions, though the checksuming still needs to be worked out. Maybe with more eyes on it it'll go faster