RomRaider

I'm guessing the problem is that Ghidra requires the script's filename to match the script name. So if you rename the output file to "XmlToGhidra.java" it should work. By 'output file' I mean the file that you generated by running XmlToGhidra.exe.

I figured it out. Turns out the file XmlToGhidra was outputting had an error. It would write "public class XmlToGhidra extends GhidraScript" instead of "public class tables extends GhidraScript"
Thanks again for your help. Time to take a dive down the rabbit hole and read through everything.

That's great that it is solved.

Note that it's not really an error. XmlToGhidra assumes the script name is "XmlToGhidra.java". This could be made user-selectable, but I never got round to improving the code. It was easier just to rename the file.

Finally got around to setting this up and having a play.
I'd been previously disassembling with the Linux ISO I downloaded. Having something like Ghidra is a perfect alternative for someone like me at the level I'm at to easily transition to, who doesn't have a whole catalogue of definitions to transfer over, like some of the other guys here.

I've successfully used the XML export tool to transfer what I have done to Ghidra and am continuing on from there almost seamlessly (Again, I'm not where near a level where I would recognise anything being messed up anyway).
I think this is a great tool for those who are interested to get started and at the very least have a poke around, without the need to sort out acquiring software like IDA.. one way or another.

I do have a question.
Is there any way for Ghidra to automatically make a reference to a location once the data has been displayed as a dword like IDA?
For this example I have manually created a reference to c7054 (CTRL+ALT+R) while c7762 remains un-referenced. It's not a whole lot of time lost but figured I'd check while I'm still getting used to it.

If I understand the question correctly, you want to convert the ddw data type to a pointer data type?

Click on the row you want to change, press ‘c’ to clear the data type, and then ‘p’ to convert it to a pointer. You may not need the ‘c’ step, I don’t have my Ghidra machine on to check.

Note: one advantage of it being a pointer is it picks up the label of the item being pointed to.

Yeah cool - that works. Cheers.

Clearing the data type doesn't look to be needed for previously defined data types and can be made into a pointer as is.

I'm very new to this and have been trying to learn as much as I can. I have an ECU from a forester E2VG221d SH7058 and I'm having some issues that I haven't been able to figurer out.

I imported the .BIN set language as SH-2A, set up the memory map using fenugrec script, I select basic, yes for the first and last option and no for interrupt vector. I run the Analyze. Then I ran the script from the xmltoghidra.java that rimwall converted for us from dschultz IDA script. I have several tables that do not have a reference. I'm not sure on how to fix this.

I'm also having an issue with the open loop fuel table being split up by a DAT_0008e326

I appreciate all the info that has been shared on this. I'm excited to keep learning if any one has any tips or suggestions let me know, thank you!

It's all working fine. Just need to run MakeTablePointers.java and it will clean it all up by formatting the table headers and the table data.

For your ROM, enter start as 0x8bc54 and end as 0x8fa87.

You don't have to run MakeCELPointers.java because this has already been done by XmlToGhidra (because the CELs are defined in the RR ECU defs file for your ROM). But if you do run it, it will format the CEL area for you. You will probably end up with duplicate label names for the CEL switches.

You're on your way to in-depth knowledge of your ROM...

rimwall thank you for the quick reply! Running the MakeTablePointers script did the trick! My understanding is that it was for making a file that's used to make RomRaider deffs. Maybe that's what the WalkTheRom is for? I'll go back to the original post and re read everything.

I'm not sure if I can explain the solution I found for the Open Loop B well. Basically what I found is that "DAT_0008e326 XREF[1]: 0008e17a (R)" had a Xref to a LAB that was used in a Function and it had a reference to a "LAB_0008e120" that was supposed to be a "DAT_0008e120" Table. So once I deleted it, it removed the "DAT_0008e326 XREF[1]: 0008e17a (R)" and now my Open Loop B looks normal! I just delete the bookmarks, re analyze and the assembly language looks normal. This all need to be done before running the MakeTablePointers otherwise It wouldn't let me fix it.

another question I have is I have a few functions with "param_1", undefined2, and ushort. Is this normal or is there something deferent I need to do?

No worries.

param_x means the decompiler (based on the assembly) thinks the function is passed an argument. This is based on r4 being the default 1st arg, r5 being the second and so on. It assumes r0 is the return value. The decompiler doesn’t always get it right, you have to understand the logic for that particular function to decide if it’s right. If you need to change it you can edit the function signature.

The undefineds and ushorts etc are fine. It’s just the decompiler assigning default names and types to the variables it decides exist.

- 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,

Hey, I don't mean to be picky but you used two different names which need to be edited: (scripts)

So what I did was add this to the class:

Then where ever you had "[ENTER_SCRIPT_DIRECTORY_HERE]" I replace it with:

And similarly in the other scripts so you only have to update myExportDir to the directory you wish to save the results in. This should be able to be tied to the working directory.

Good work BTW!

Thanks! I was a Ghidra noob at the time so it was an ordeal writing those scripts using only the Ghidra API notes. I've yet to find any friendly reference info on writing Ghidra scripts.


haha! I started with "directory" but I thought that was too Commodore-64-era so I changed it to "folder". Obviously missed one!

Thanks for the code improvement. I have since expanded MakeTablePointers.java to handle the wider range of table structures in TCUs. I should post that up when I get a chance.

This may be helpful as you define the decompiled functions in Ghirda for SH processors.
https://llvm-gcc-renesas.com/manuals/SH ... ation.html

Cool, thanks. I had worked out most of that by doing the RE, but definitely handy for folks to have it all in a reference doc.