RomRaider

Hey team,
Hoping you kind gents can help me. I've got a JDM RX-8 that I'm trying to define.

There's a lot of information about getting started with IDA or IDA Pro, but not so much on Ghidra.

I've got Ghidra up and going, but am a complete noob at this and can't get fenugrec's script to work in Ghidra.
In the meantime, I will keep searching, but so far Ghidra just loads the .bin byte by byte.

There's lots of walkthroughs with IDA Pro, is it better to spend some time there?

I've also likely got a JDM Nissan Fuga to do, but I haven't been able to download the ROM yet, so I can't say whether it's been defined or not. It's so far not listed in the definitions I garnered.

I even tried to load the Mazda RX8 ROM as a closely related ROM ID, and it was pretty clear most of the tables were different, since the data loaded with blank spots. The USDM definitions available look like they're for the turbo models, and this is a JDM NA Series 1 car.

Any help on getting started with disassembly is much appreciated, and willing to chip in for those of you who have put in the legwork.

If you post the bin for the RX8 I’ll define it for you and add it to the definitions on the RX8Man GitHub repository

That's super kind of you, mate.

I'm also happy to learn if anyone has any tips for Ghidra disassembly. I'd be keen to lend a hand doing the undefined fringe Subarus or Nissans, too, once I can get something more than just byte by byte loaded up.

I got Ghidra pulling functions and some other bits by loading it as a SH4.

Anyone have any tips for going further? Shultz has a ton of tools for IDA, but I haven’t found so many for Ghidra, and I’m doubtful they cross.

Does anyone have a ROM from a different Mazda RX8 that I can use to identify some tables? I’ll just keep poking around til I hear more.

SH2A should work better than SH4.

This is Suby centric, but still for 7058 MCUs, have a look here (some ported tools included):
viewtopic.php?f=40&t=17796

and Nissan centric, including 7058 MCUs, here:
viewtopic.php?f=65&t=17799
https://github.com/fenugrec/nissutils/t ... ra_helpers

D,

I feel like I've read those threads ten times or more. They're slowing making more sense as some of this soaks in.

I'll make another pass maybe tomorrow night, and see if I can't get gooflophase's 7055 kit added (that came out of your IDA work) and maybe give it another try.

Can anyone tell me why I'm getting this "public class" error on Ghidra? I've tried loading the scripts with edited directory, and now it's stalled here. EDIT: I've tried reloading older versions of JDK to no avail. The scripts clearly say public class at the first line. Any help is appreciated.

Dale and Fenugrec,

reloading the ROM as a SH2A with gooflophaze's contributions added to the SuperH4 languages made the CEL and WalkTheROM scripts work. The Tables script still doesn't go, and I still can't get the Nissan_Load to run.

So far, this is what it has come out with:



Sorry for attaching a photo last time, Fenugrec.. I only just read now that you don't care for snips. I'll try to quote my errors/failures as above.

If I open the Nissan_Load in Visual Studio Code I show 1K+ errors. I doubt it's got that many, because it seems some other members have got it going.

Anyway. Not sure if the 6E0E700 is the ROM ID or the CAL ID, and same with the N3YHEE000 that comes out at 6c646, but it seems to line up with a few other definitions from the turbo RX8s that have been defined. The only thing I've labelled is the ROM_ID at 2000. The other labels came out of running the two scripts that would go, with a guess at whether or not the CEL routines were together with pointers, whether the ROM is CAN or not, and what the starting address was. There is no 0335 in the ROM that is a page down from a whole set of zeros and 1s, so that wasn't a giveaway.. but there is a huge block of 00, 01, 02, and 03s.. maybe that's like the LS platform where it has [No Error Reported, No MIL but error reported, MIL on first error, and MIL on second error] as options for CEL?

I tried to also give ScoobyROM a go, but I might need to reinstall Visual Studio again. It's late and I've cooked my brain a bit by trying this over and over.

Hum that is strange. Haven't tested my scripts on windows, but even then it should all be valid, plain ASCII. Did you modify nissan_load.py at all ?



That is unlikely in a ~200-line file... does VSCode even support python at all ?

Been running through this ROM for a few weeks now in Ghidra, and have found a LOT of good stuff..

Not sure if there is a place to upload a Ghidra archive here, or how we can collaborate.

I've got the Nissan related Ghidra helpers to run, and also have a few other structures figured out that would be nice to run scripts on.

Nice !



Not really, they tend to be pretty massive files. ghidra does have built-in collaboration tools but they require a central server, and I don't know how fine-grained the access can be controlled. Never used it myself, I've rarely been in a situation when there's more than one person actually defining stuff in one same project.

I don't think ghidra db's lend themselves well to versioning by git or other external tools; it does have its own internal versioning though.
Probably easiest to upload the db archive on some external file host and delete/update it as you go.

Scripts should be fine here though, if you're unable to host them as a git repo.

This has been my experience as well.

I'll keep plugging at it, if anyone wants to hop in, just shoot me a PM and I can get you the latest archive I have.

Have made some really awesome progress working through this,

started my own Fork of the OG defs.. I'll just be throwing some experimental stuff up there as I go through the rom. Have found just about the start of everything!

https://github.com/equinox311/RX8Defs

PM me for my latest Ghidra archive.. I don't know how else to collab

I am using the 60E0FC00 as my basis, so all updates will be on that ROM. Not sure how to easily apply changes to other cal IDs.

Posting here hoping to garner some interest.

I was able to reconfigure my ECM here to read in some new CAN messages, which is really neat. My intent is to read in something like Ethanol content and then go from there for some flex fueling options..

Anyways, I am having a bit of a hard time understanding how the ECU calls functions, and as I am trying to add my own functions in obviously this is important.

Can anyone help explain these situations?



A jmp vs a jsr is confusing to me. The way it gets called makes sense, but I don't understand the _lds.l @r15+, pr after the jmp statement. Is this command essentially a rts, but just using the process status register to pull stuff from the stack to know where to return to... or...?

Maybe I am completely off the pace here.

My intent was to move all of this code to a new place in memory, where I can add a function call to deal with my new CAN message without offsetting everything else in memory. I just want to make sure I return from this newly addressed function correctly.

Thanks for anyone who can explain this a bit to me!

If you haven't already, you need the "SH-2E software manual", REJ09B0316-0200 .

7.2.25 JSR


(note : I think there's a typo there, in R[m]+4, the +4 doesn't make sense since it's an absolute destination. I could be wrong about this, but it wouldn't be the first typo in there.

The JMP is similar but omits the PR=PC step. JSR is meant to be matched with a `RTS`opcode which is:



in a simple case, you JSR to a func , and the RTS uses PR to jump back to the proper place (after the JSR's delay slot). So what do you do if you want to call a function from inside a function ? You would clobber PR on the second JSR , and lose your initial return location, so you need to push PR to stack with a "str pr,@-r15" at some point.

The func you are looking at, that has "_lds.l @r15+,pr" in the delay slot of the JMP , restoring the value of PR it had on entry. This way, "ImmoMain" can simply do a RTS, and instead of returning at 00DC5A, it will jump back to whoever called the func you're showing. Minor compiler optimization, otherwise ImmoMain would RTS to DC5A, then you'd have another RTS + nop (delay slot) for the same result.

Probably don't need to say this, but to debug function patching, you'll want to simulate your stuff in HEW first. Way easier to debug.