RomRaider

I'd like to keep track of limitations of ghidra, or functionality that must be figured out before it can really be as usable as IDA.

1. [EDIT : solved, see posts later in this thread; script here https://github.com/fenugrec/nissutils/t ... ra_helpers] no processor defines (for interrupt vectors, memory areas , and peripheral register addresses).

Alternate solutions I didn't use :

- https://github.com/NationalSecurityAgen ... issues/145 : memory-mapped IO regs
- 'PERCH' plugin : only found a talk about this ( https://www.youtube.com/watch?v=ImSXkn3GAE8 ), to leverage ".per" files provided by Lauterbach such as https://www.lauterbach.com/scripts/per/cd/per7055.per

2. [EDIT : solved ] By default, the decompiler has issues with indirect jumps. See https://github.com/NationalSecurityAgen ... ssues/2452 for details. The solution is simple : one must set the ROM memory area to *not* be writeable - otherwise ghidra has to assume some pointers can change at runtime, etc.

3. [EDIT - this also appears to be solved by above method ] decompiler may not doesn't de-reference values loaded from literal pools, e.g.


4. ghidra "locks" a project file to the username that created it. This is annoying if working on the same project from different computers / sessions. Two workarounds :
- create a dummy project first, which is necessary to open the desired project as Read-only. Con : read-only.
- edit "project.prp" to change the username. Con : hackish

Anything else I've missed , or solutions / workarounds ?

The decompiler is pretty much worthless IMO. I'd add that the disassembler also struggles with the few "trapa" instructions, failing to disassemble the bytes immediately after.

The automated disassembly is pretty good, but it misses entire functions if they are called from a table. It'd be nice if it would recognize the main call tables as function pointers and not have to manually edit each label as a function. Maybe there's a way to do this more efficiently but I haven't found one.

I would really like to be able to use common struct definitions for things like the CID defs across the library of ROMs. Would certainly assist identifying associated routines. This has got to be possible, I gave it a go once, to no avail.

I also ran across PERCH, but didn't find any real resources to use.

I haven't used IDA, so I don't know what I'm missing

The disassembler does a poor job of labelling registers in functions. It doesn't recognize when the registers have been overwritten and are no longer related to the input values passed to the function.

So, apparently this "feature" can be turned off, but at that point you can't see the obvious first use of the variables passed to the function. Makes adding definitions to the functions a waste of time.

https://github.com/NationalSecurityAgen ... -642579547

So I’ve been using Ghidra exclusively for a good couple of months now. For my goals and experience level, it is FAR superior to IDA in every way imaginable.

It’s much easier to analyze the code due to the color coding + font, it feels much more intuitive and easy to use for someone who isn’t experienced with coding, it actually shows you the RAM addresses (IDA can do this, just don’t know how to make it do so), etc. Oh and showing you the actual ROM storage addresses rather than the hex value + offset is fantastic as well. I’m guessing IDA can do this as well after you dig into the settings, but the fact it doesn’t do it by default is odd. (For the version I was using)

So for those looking to analyze code for tuning purposes, Ghidra kicks IDA’s ass. But if you’re interested in boot up stuff and how the internals of the ECU works on a more code focused mindset, then IDA would probably destroy Ghidra. I’d argue that I’d still be sub 1,000 maps defined and sub 100 RAM parameters defined if I never switched to Ghidra. On top of this, IDA has been unable to locate many maps that Ghidra found on its first auto analysis run! So it’s definitely quite an impressive little thing. However, it has a bad habit of assigning hex values over 7F as storage addresses. So instead of it being 80 or the negative hex value, it’ll label it as a storage address at 0xFF80. Not sure if you can fix this within the settings, but it can get annoying at times. Especially when there’s a function at 0xFF80 haha

I've been spending a bit of time in ghidra these past few days and figured out how to solve the most annoying points I listed in the first post ! (edited the message accordingly). In short, the ROM memory area must be set as read-only, otherwise ghidra has to assume some things may change and that completely throws off the decompiler.

With that, I must say, I am impressed. Ghidra manages to track RAM xrefs much, much better than IDA (well at least 7.4 - could have improved since then, I don't really care anymore).

The last niggle is really automating the IO peripheral reg names and mem areas; with that I couldn't really see a reason to use IDA at all .

Oh yeah, and ghidra's silly notion that a "project" file is locked to a certain user - I work from different computers with different usernames, and this is a constant problem.

I actually figured out a way to do this manually. Using an import symbols script Ghidra comes with, you’re able to directly import the proper IO peripheral labels directly into Ghidra! However, this requires modifying the formatting for YOUR specific processor and it’s something that has to be manually done. So you’d copy your specific processors information, use regex or something else to reformat it to “Name Address l” (if I’m not remembering correctly, the formatting is shown in the description of the script), then use the import symbols script to import them directly into Ghidra.

So what could be done is splitting all the processors into separate, reformatted, files specifically for Ghidra and then people could just import those directly into Ghidra. I’m not sure if there’s any better ways, but this has worked perfectly for me!

Do you already have something usable for 7055/7058 ?



Exactly what I'm thinking. Let's make it happen, and I'll add those scripts to my nissutils repo. Just opened an issue to discuss the details : https://github.com/fenugrec/nissutils/issues/12

I figure it would probably make sense to be a script, which could also take care of properly defining all the mem regions as I described above ? would be nice to have a 3-step setup : load .bin file, run one script, and everything's groovy

Went through and used regex on your IDA cfg's to format them into the Ghidra formatting, as well as split them all into separate files. I can't guarantee that every single one works properly, but I quickly tested SH7055 and SH7058 and both imported without errors. Do note, these are just the variable labels and doesn't include memory regions or anything else. You would want to use the "ImportSymbolsScript.py" under the "Data" folder. Or, you can just search for it in the filter box of the Script Manager.



It's definitely a good idea! Automating as much as possible is always better than manually doing so.

Thanks @Pytrex, will take a look.



I don't think I'm seeing exactly the same issue you had, but indeed trapa is not quite processed correctly. I opened an issue for that : https://github.com/NationalSecurityAgen ... ssues/4396

Hi,

Good work guys.

For SH70xx register names, there were some .pspec files offered up in this thread https://www.romraider.com/forum/viewtopic.php?f=40&t=17796. Not sure how useful these are?

One limitation I struggle with is recognising 16bit values stored in ROM as pointers when they are in the RAM region. For example, if the 16bit value is 0x0123, I can define this to be a ‘pointer16’ data type and Ghidra will recognise it as a pointer to 0x00000123. All good. However, if it is a 16bit RAM address value, like 0x9876 (that gets sign extended to 0xFFFF9876), I couldn’t find a different data type that would allow me to define this as a pointer to 0xFFFF9876. Is there a way around this?

Thanks.

Thanks - I hadn't thought of looking on the Subaru side to see what was going on P )
I think I'll go a slightly different way though, it's a bit of a pain on linux to be messing in ghidra's install dir all the time.




I know what you mean, but it hasn't been a problem for me - the disasm and decompiler all follow the right references, since usually those literals are loaded with mov.w and then used as a pointer. For example here, there's a u16 constant 0xE800 at 06F8, but the disasm figured out it's used with sign-extension, and the xrefs to FFFFE800 all work as expected. So I actually haven't had a need to even touch that data @ DAT_06F8 .

Ok, work in progress, but I started a rough script here

https://github.com/fenugrec/nissutils/b ... an_load.py

so far it lets you pick a device type , and defines memory areas with the correct modes (readonly ROM, volatile IO).
Preferably run this only once, immediately after importing the ROM dump, before doing any auto-analysis or other work.

Ok, good enough. Actually pretty happy with the result, based on limited testing. Workflow is IMO much much better than on IDA - you don't even need to manually pick a device like 7055/7058 etc. The script guesses all this, as well as split interrupt vector tables !

Currently 7055 and 7058 are the most complete, but 7050,7051,7052,7054, and 7059 have basic mem area + interrupt vectors.

Could use some help for the IO registers - basically digest the tables in the PDF into a simple .csv file, clean up names, and boom.

Some notes from the README:

# Using
The cleanest way is to use this script as the very first step after importing the .bin file.
1. Open Script Manager
2. One of the buttons top-right is "Manage Script directories"
3. Add the directory containing this script.
4. Refresh the list of scripts : there should be a new category Nissan containing this script
5. Run script

Examples :

Here is part of a dual-IVT ROM, with the second IVT at 0x1000 :



Here, some IO regs showing correct names and xrefs:




And lastly, an example of code with nice IO reg names :

Great job Fenugrec! It’ll definitely help a ton! It’s awesome to see someone working on Ghidra scripts, as Ghidra just disassembles SH soooo much nicer than IDA imo.


Just some general notes for everyone:
- Ghidra still does a pretty lackluster job of finding functions. This is a problem as it causes stack analysis to not work as intended until the function is manually defined as a function. I’m really not sure why Ghidra struggles with this, as Nissan is VERY consistent with their start of function code.
- Ghidra sometimes struggles with figuring out RAM addresses that are called using offsets. This sometimes is a stack issue and other times is just Ghidra not seeming to want to do anything, even with assuming a register’s value.
- Figuring out the optimal auto analysis profile would be very beneficial. Atm, I feel pretty good with my auto analysis profile and all that. But I can guarantee that it’s absolutely not perfect. So creating a profile that everyone could use would be very beneficial, as this directly influences how well or how poorly Ghidra will disassemble the code.