RomRaider

So, it's been a long journey, but I've had my first attempt at defining a ROM (see post in Experimental Defs forum viewtopic.php?f=34&t=17794).

I used Ghidra because I couldn't justify buying IDA Pro, so I thought I would share my experience for the greater good. It's been a 3 month journey so far.

Positives of Ghidra:
- free
- can disassemble the SuperH instruction set (I didn't even know what that was a few months ago!)
- easy to use, intuitive interface, fast
- super powerful API for scripting
- analysis tools appear to do a good job of disassembly
- can do function trees
- has a decompiler (very useful for understanding complicated and nested 'if, then, else' structures)
- comes with its own help files, although they are limited (see below)
- did I say it was free?

Negatives of Ghidra:
- Not much on the net in terms of tutorials or other resources
- the help files already assume you know what you're doing, so they are a bit confusing for a novice
- the API help is very brief, which makes it hard if, like me, you didn't already know Java or Python

Very brief 'how to' guide:
- install Ghidra and the latest Java Development Kit (instructions on Ghidra website)
- start a project, and import the ROM file, plus a defined ROM
- choose 'SuperH sh2A' instruction set
- add a memory block for RAM (display memory map button, add memory block button, start 0xFFFF0000, end 0xFFFFFFFE, length 0xFFFF)
- Run the Ghidra 'analyse everything' tools
- spend a lot of time on this website reading.
- Say a huge thank you to dschultz and NFSW and follow their instructions here (viewtopic.php?t=6303) and here (viewtopic.php?t=8449)

Utilities:
- full credit to dschultz and NSFW for their C# and IDC utilities
- I have converted these for Ghidra
- provided I get permission from dschultz and NSFW, (and there is enough interest) I can make these utilities available
- caveat 1: I only know they work for my 32 bit 1MB ROM, they may need some stress testing and quality checking before they are released
- caveat 2: this is my first effort at coding in Java, so they won't be elegant
- caveat 3: it has been decades since I last coded in C, so they won't be elegant
- the utilities include: XmlToGhidra.cs (conversion of XmlToIdc.cs), MakeCELPointers.java, MakeTablePointers.java and WalkTheRom.java

That's about it. I've still got a long way to go on my disassembly/tuning journey, but my hope is that because Ghidra is free, more folks may get into the scene and help out with the ever increasing list of ECU def requests.

edit: updated: v9.2 of Ghidra now explicitly supports the sh2A instruction set, and some comments on the decomplier
edit: updated to mention adding memory block for RAM

Keep going, very interesting!

I'd be interested - I've also taken dschultz's IDA cfg files, chopped them up with python, and gotten them sorta working with ghidra.

Asking for forgiveness instead of permission -

Please note these are largely incomplete. I'm very much a RE newb and my target is a sh7055, so the other config files here have not been fully fleshed out - but once you've written the parser for one file, you might as well run the rest of them through. If you're looking to use something other than SH7055, please note you'll need to edit the ldefs file to add the pspec into the definitions - and the memory map wasn't "parseable" but is pretty easily hand editable - again, use SH7055.pspec as a template.

Also - I should note - there was (as of 9.1.2, I haven't looked at the 9.2 docs yet) almost no documentation on writing a .pspec file for ghidra. I imitated what rogerclarkmelbourne (of stm32 and others fame) did for some NXP processors, but did not go so far as to look at source. Another thing to note - since ghidra is largely targeted at x86/PE, everything is ram. I might be wholly wrong in this assumption, but I didn't discover a better way of labelling things.

Installation:
Download zip - extract and move the files into


I ran my analysis on the 7055 as SH4, not SH2a - ldefs and directory might need to be changed if I'm doing this incorrectly.

Again, all credit to dschultz for the IDA configs these are based on and rogerclarkmelbourne for some examples. I'm not looking to become a curator of these files because quite frankly I barely understand what I'm doing, but hopefully this'll kick the can down the road for someone.

Thanks gooflophaze.

I checked with dschultz and was assured that sharing is ok. So, I've attached the Ghidra Utilities here. No promises in terms of functionality - I was / am learning both Ghidra and Java at the same time, so a lot of trial and error was involved!

In terms of processor type, I originally used 'sh4' but I found that the decompiler would assume 8-byte data types in decompiled functions which really stuffed up the decompilation. The max (as far as I'm aware) is 4-byte. The SH7058 is technically 'sh2e' but seems to work fine with 'sh2a'. One minor tip: the decompiler often incorrectly determines that a function returns a value, whereas most functions on a 32 bit Suby ROM do not. If the function return data type is changed to 'void' this often improves the decompilation output.

Generally I find the decompiler is a big help - it makes the underlying logic far more readable. It does, however, seem to fail occasionally, in which case the assembly needs a closer inspection.

I'll have a look at the file you attached, although I'm a newb too and I'm not sure what to use it for? I did identify the peripheral addresses which was handy to figure out some 'RAM' addresses, but not sure how to use all the other addresses in the pspec file?

Hope the utilities are useful for someone...

I think the register names are more useful for greenfield reversing - less useful when you have a semi-known-layout and can infer table function from data instead of tracing IO on the hardware.

Permission granted! In fact, just as a blanket thing, anybody has my permission and my encouragement to take anything I've posted on RomRaider, add / extend / remix, and post the results. Any time I share something online I'm hoping that someone else will find it useful enough to build on it.

Ghidra is really nice. I'm looking forward to seeing what happens now that a lot more people have access to something even better than IDA.

Big thanks to everyone involved here. I just got Ghidra up and running on Win10, opened my known ROM ran all of the scripts & XmlToGhidra to generate the labels. Got a feeling this is now going to take up some time as I slowly work my way around the IDE, decompiler and SH7058 instruction set. Please keep posting team!.

ps/ one very minor thing is that XmlToGhidra.cs didn't like the special characters found in logger.xml on my PC but was find once they were removed

Great to hear it's been useful! I was wondering whether I'd spent all that time making a chocolate teapot...!

Judging by the number of downloads of the Ghidra Utilities, there seems to be very few folks using Ghidra.

It's surprising, because Ghidra (especially the decompiler) makes reverse engineering a ROM much much faster. And it's free. In my spare time over a number of months I managed to reverse engineer about 70% of my ROM including maps, function logic, SSM calls and overall structure. I was trying for 100% but ran out of enthusiasm a few months ago and haven't progressed it since then.

Came across a small bug in MakeTablePointers.java while working on another ROM. Bug was only occurring where Ghidra had already chosen an incorrect dataType for table data. Updated Ghidra Utilities files attached.

Also, here's a bit of disassembly I did for another purpose that might serve as a mini-tutorial for those just getting into Ghidra. This is on ROM E2WG200G and relates to tracking down how S50 - "Retard Signal from AT" works.

1. Hopefully you have found SSM base and defined the SSM functions as per the start of this thread. Start at the SSM_Get Function for Switches 72_73_74_75_50_51_52_53. This Function returns a byte value - Ghidra probably calls this local_8. The bits of local_8 represent the current state of the various switches in order from bit7 (Switch 72) down to bit0 (Switch 53)

2. At the top of this Function, there will be a list of Function calls that return values which get stored in local byte variables. Ghidra will probably call these cVar1 cVar2 etc. Find which cVar[x] results in bit3 of local_8 being set (probably using logic operator "| 8"). Then find which Function call sets this particular cVar[x]. Call this "Func_Retard_Signal_from_AT".

3. Go to Func_Retard_Signal_from_AT. It will probably return the value of a bit from a RAM location, being bit7 from 0xFFFF689C

4. Go to 0xFFFF689C and Ghidra will show you the list of XREFs, which is probably a list of functions that Write to the RAM location (W) and Read from this RAM location (R). The first couple of XREFs are initialisation related. Then there should be a function that has many XREFs, both R and W. Call this "Func_Set_Target_for_Timing_Adj"

5. Go to Func_Set_Target_for_Timing_Adj. You should see that a RAM value, 0xFFFF6894, gets set to different values (eg) 0, -5, -10, -15, -20. This is a Target that is used in the Timing Adjustment calculation. The logic determines which value to set the Target based on 0xFFFF51A1.

6. If you use Ghidra to trace it back, 0xFFFF51A1 is set by another Function which uses a value stored in 0xFFFF51F8 which is obtained via CAN (presumably from the TCU) to set 0xFFFF51A1. Basically it converts 0xFFFF51F8 from a decimal number 0, 1, 2, 3, 4, 5, 6, 7 into a bitwise representation. So if 0xFFFF51F8 is 3, then bit3 in 0xFFFF51A1 is set and so on.

7. Back in Func_Set_Target_for_Timing_Adj, 0xFFFF6894 is set to -5, -10, -15, -20 when 0xFFFF51A1 has bit1, bit2, bit3, bit4 set respectively. 0xFFFF6984 is set to 0 for any other value of 0xFFFF51A1.

8. If you use Ghidra to track back 0xFFFF6894 you'll see XREFs for Func_Set_Target_for_Timing_Adj (W) as well as XREFs for another Function where it is Read (R). Call this other Function "Func_Timing_Adjustment_Engine_Load_and_Speed"

9. Go into Func_Timing_Adjustment_Engine_Load_and_Speed. This Function works out the Timing Adjustment based on Engine Load and Speed and stores it in a RAM location 0xFFFF6898. Firstly it checks if either bit5 or bit6 of 0xFFFF51A1 is set and if so it sets 0xFFFF6898 to 0 (ie: no Timing Adjustment). Alternatively, if 0xFFFF51A1 has a value of anything other than 2, 4, 8, 0x10 (bit1, bit2, bit3, bit4 set) it skips to the bottom of the function and works out a timing adjustment based on one of two tables that lookup Engine Load and Vehicle Speed and stores this adjustment in 0xFFFF68A8. It then adds 0xFFFF68A8 to 0xFFFF6898 and stores this new Timing Adjustment in 0xFFFF6898 after capping it at 0 using a Min (a,b) function. Alternatively, if 0xFFFF51A1 was either 2, 4, 8 or 0x10 then it follows other logic as follows. If the Timing Adjustment (0xFFFF6898) is greater than the Target (0xFFFF6894) it looks up the Timing Adjustment from a Table based on Engine Load and Speed and stores this in 0xFFFF68A4. It then reduces the Timing Adjustment (0xFFFF6898) by 0xFFFF68A4 and stores this new Timing Adjustment in 0xFFFF6898 after making sure it is not less than the Target (0xFFFF6894). If, on the other hand, the Timing Adjustment is less than the Target it looks up the Timing Adjustment from a different Table based on Engine Load and Speed and stores this in 0xFFFF68A0. It then increases the Timing Adjustment (0xFFFF6898) by 0xFFFF68A0 and stores this new Timing Adjustment in 0xFFFF6898 after making sure it is not more than the Target (0xFFFF6894).

10. Other things you will come across doing the above are: The Max(a,b) function is at 0x24BC, the Min(a,b) function is at 0x24CC and one of the 3D Lookup Functions is at 0x2150

Having done the detailed digging in the code, what does all this mean? It seems like the TCU tells the ECU whether or not to apply a Timing Adjustment and what Target to aim for. If an Adjustment is to be applied, each ECU cycle it is stepped closer to the Target Timing Adjustment. The size of the steps is looked up from tables based on Engine Load and Speed.

Superb doco, scripts & examples cheers again @rimwall for sharing these with the RomRaider community. This thread got me, a newbie into the ROM, I'm surprised your Ghidra work hasn't generated more interest. btw if anyone else is getting Ghidra going be sure to use v9.2.4 as we found the bundled SH-2A defs changed after that version causing calling function arguments to be misinterpreted.

Awesome work guys! Since it has been a year, has anyone spent more time working on SH70XX processor data for Ghidra? Also, at this point in time, what have you guys found to work the best with disassembling SH7058? I've been religiously using SH4, but since SH7058 is SH2E, I'm not sure if it would be better to use SH2A or even use the SH7058 file posted by gooflophaze.

Hi Pytrex, you and fenugrec are doing some great stuff on the Nissan ECUs.

I tried SH4 once but I found the decompiler produced 8 byte data types, which don’t exist on the SH7058. So since that one attempt I’ve always used SH2A. It seems to work fine.

I used the register names a bit, but I found I was still looking them up in the hardware manual whether I had the raw register address or the shorthand register name. So I ended up not using them. Not sure if I was using the register names file incorrectly…?

The Ghidra decompiler is a massive timesaver. Most of the time I just look at the decompiler.

I appreciate the kind words! Both of us (and many others!) have definitely spent some incredible amounts of time on all of this



Ah, that might be where the largest deviance lies. I only look at assembly, and every time I've compared with IDA Pro it has been 1:1 luckily. So, I wonder if that means that assembly is still accurate, but the decompiler isn't going to be fully accurate unless you utilize SH2A.


Funny enough, I keep meeting people who greatly praise the decompiler, yet I can't stand it for whatever reason. It's not that the decompiler is bad, it's just easier for me to visualize and understand assembly I guess haha But I'm still really glad that Ghidra has it, as it seems to benefit quite a large group of people!

Hi All,

I'm just getting into the world of tuning with RomRaider. I have experience using Cobb on my Forester XT.

Not all the defs are defined for my 2007 JDM Legacy Spec B, and I would like to work on defining them myself for the learning experience.
Right now I'm looking to define more of the CELs - mainly P0420 currently since I have a downpipe.

I have Ghidra up and running, but I am having trouble running Rimwall's Ghidra Utilities.
I get an error that "the system cannot find the path specified". I have the PATH variable defined in system -> environment variables
attached is a screen shot of the error.

Thank you!