RomRaider

Heh. Got curious, decided to take a peek, to see how different these are from Nissan ROMs. Well, they definitely weren't written by the same people!

I looked at "37820-rbb-e54-7055.bin". Found a few interesting things, maybe you guys have these marked already but if not, IMHO these are worth further investigation. I don't know if that ROM is meant to be J2534'd over CAN or K ?
*******
@07231C : some flashing code
@071E9C : definitely an IVT, with entries pointing to RAM

@071010 : copies two blocks of memory from ROM into RAM (including that 71E9C IVT and flashing code!). Called from 070F80

@070F80 : sends "0x55" on SCI2, then does a bunch of stuff, including setting vbr to 0xFFFFA630. We know where this is going...

070F80 isn't called from anywhere obvious, it's only referenced in a list of func ptrs @ 024584 . I haven't dug farther up than this.

********
@471DC : checks two consecutive bytes to match "0x68 0x6A", no doubt checking for iso9141 OBD header.

********
@465C0 : some large tree function with a switch { case ... } structure, looks like SID parsing but didn't find SID 27 at a quick glance

********
@ 39C2 weird ECUID, actually seems to be two different strings "interleaved".
@ 4CAFA copies one ECUID to buffer in a weird way. Not sure if / how this code path is invoked from the expected SID 1A handler (getECUID).
@ 47BC2 copies alternate ECUID to a buffer

It was dumped from K-Line ECU.

Got new files guys. If you need bin for comparison/unpack test/dissasembly just let me know. I've noticed that RWD unpacked files are not always exact size as should be (512k for 7055, 1M for 7058) Bad unpack or maybe it's just not raw update file? Dunno.

J2534 is a Windows x86 only API to make any J2534 device work with any software capable of using it. On the ECU side the J2534 device implements multiple ECU specific protocols on whatever comms line the ECU may support.
If you are interested... J2534 Openport 2 on Linux supporting K-line and CAN.

Very cool, will definitely be checking that out.
So it looks like there are some formatting differences in the rwd files depending on the target module type for the K-Line files. The CAN files seem to be more uniform but it's looking like the cipher changes depending on the target module type. The K-Line files may exhibit the same behavior but we won't know until we can parse the K-Line rwd format more effectively

@twizzter, I take it the rwd file you were seeing assertion errors with was the RBB rwd file? It looks like the format of the K-Line rwd files has the address to be written to before the chunk of data. The script didn't seem to like files that try to write starting at 0x00, or the beginning of the flash, so I changed the assertion from addr = addr_prev to addr >= addr_prev and that seems to work for RBB but not PRB. Still need to work on the K-Line ecu algo. As for the size discrepancies, I think it might be a space/bandwidth saving measure to handle chunks of duplicate data though I'm not sure how it determines what data to fill the voids with yet. Maybe the last 4/8/16 bytes written get rewritten until the current block of data is filled. Looking at the output of the script I think the length of the blocks are defined in Header 5.

Edit: Just went back and compared a couple pages between the piasini dump and rwd file and it's added a block of zeros after the first block (probably has to do with my change to the address assertion) that if removed lines up the patterns. Also the failure point on the PRB file is that it's using blocks half the size of what rwd-xray is expecting so K-Line file parsing definitely needs some reworking.

I was just randomly comparing unpacked files which i had from given bin pack - some of them were previously flashed trough AUD or OBD, ECU got up and run ok, so i can't be 100% sure about every file, but assume that they're fine - all of them are sized "properly" - at least for 7055 and 7058.

Upon extracting, encountered such things:
(extracted) -> (binpack reference)
37805-PND-A590-M1 -> assertion error
37805-PPA-4260 -> different files, size ok
37805-RBB-A620-M2 -> different files size (634 vs 1024k)

Also, i'm curious about firmware version naming - for example, updates are named:
37805-RBB-4060
37805-RBB-4070
37805-RBB-A620-M2

We know that 37805 means ECU module for RBB chassis. I have no idea about last part, which is supposed to be version/region - what's the difference between 4-digit/AXXX/AXXX-M2 naming, and which one is dedicated for (in this case) 37820-RBB-E54 ECU.

I've analysed bin dumped from mine ECU, looking for some strings indicating module version. Found something @39C3:
"3377880550--RRBCBA--EA504000" but i didn't manage to find anything similiar in RWD update files.


Edit: I checked more files, it appears that ECU ID exists as two types:
1) short one, like "37805-RBA-E420"
2) as @fenugrec said, long kinda-interleaved type, for example "3377880550--RRBCBA--3A106000"



To sum up - maybe i was trying to compare different software versions, same software intended for different HW revisions (region? emissions?), or not full image update files. Anyway - it's important to clarify it up.
Better to be sure about files consistency upon disassembly

It seems like every AUD dump I've come across online has been of an old version. With my fork of rwd-xray, I've md5sum verified that the calibration portion of my PZX piasini AUD dump and the extract from the RWD are identical. Now the AUD dump I have for RNA is an older version, but the common structures and strings are there with the RWD extract. While tinkering with the Kline portion rwd-xray it will pad areas it doesn't have data for with zeros. The last section of the naming is described decently in the rwd-xray readme but is basically region and version. A for NorthAmerica, E for Europe and so on. I noticed your RBB dump is E540 so I've been using the E580 for comparison when working out the K-Line decoding scheme. From the looks of it its the full flash if I understand the addressing scheme

Edit: did some digging and realized I should be using RBB-4090 instead of RBB-E580

So while I'm working out the ROM checksumming I've also started working on definitions for the ones I've extracted. Just to start I've been using the Subaru 32bitbase for seeing how the the tables appear in RomRaider, but it looks like in the way the array is parsed, the axes are swapped. For an Ignition Advance table it only display coherently with RPM on the X axis and Load on the Y. Is this something hardcoded into RomRaider or can the displayed axes be swapped?

Yes, we hit the same issue for the Nissan defs, viewtopic.php?f=8&t=13443
"swapxy"

Awesome that did it, thanks. I missed that one when I was following the Nissan developments.

Do you know if rwd-xray is now able to decode anything from the range of 37820-PZX-A07 to 37820-PZX-A21? Would anyone be able to post either such an .rwd file or the translated .bin file?

I'll try to play around in IDA and see if I can get it to disassemble properly.

As far as I can tell my changes to rwd-xray only work for the Keihin Honda CAN bus files. The attached bin is decoded from the RWD file and is verified as 0x8000 to 0xFFFFF of the internal flash. Starting at 0x4 of the reflash bin (0x8004-0x8007 of the full flash) is the address for a second IVT.
From what I can tell of the tables, they are mostly uint16 and displayed as base 10.
I had previously done some tuning for mine and recognized some of the stock tables using the free wols.
After I clean up my in-progress def I'll upload it.

Over easter I think I worked out the checksumming for the RWD files and the sh7058 based ROMs, at least I can confirm them working with the PZX ecu.
I've been able to reflash crafted RWD files and can also confirm the bad flash fallback mode. Due to an IO stall I had an incomplete reflash, after which I immediately started to reflash again and the ECU reported 37805-PZX-A010 as the software version instead of 37805-PZX-A080 that it was before, from there I made a successful reflash back to A080. The A010 version number shows up in that area < 0x7FFF of the full flash.

I'll work up a utility and wiki once things calm down from my move.

*EDIT
It doesn't look like I can upload RWD files. I'll zip one up this evening

I stand corrected that the maps seem to be int16, not unint16, at least for the ignition advance. Checked against the Fit which has some timing retard into negative degrees. The lowest the S2000 goes is 7 degrees advanced so that threw me off.

Anyone messed around with PCMFlash? They say it supports Honda/Acura CAN Bus using the Openport 2.0 cable.
http://ecutools.eu/chip-tuning/pcmflash/

https://www.s2ki.com/forums/s2000-engin ... m-1180770/

Yeah, but K-line ecus are limited to write only and software is divided into separately paid K-line and CAN modules.
Map edit could be done using BitEdit+extra software module (matsu/keihin etc, $$ as well)
I've got opportunity to work with this stuff thanks to my friend. They're good tools imo. The biggest disadvantage is you have to buy a lot of modules to cover different ecus.

I thought anything flashable using the J2534 protocol was CAN Bus? Please correct me if I'm wrong.

Also, all we need is the ability to read and/or write (with checksum correction), and a ROM dump that can be opened up in IDA. Don't need map editor as that's what RomRaider is for. I've defined ~100 maps/tables for E36 BMWs using RomRaider. I'm sure once we get a relatively inexpensive ($150 is cheap) to read/write, RR editor definitions won't be far behind. IDA will help to find new tables and later down the line, custom code.

I guess $150 for PCMFlash isn't as cheap as we'd like it to be but if it's a ready to go package that will work, it seems like it could be worth it? I need to close out some other projects before I dive into this.