Ghidra for amiga disassembling

[copse]

I see that Ghidra supports "68xxx" and there's a executable file loading extension. Has anyone given a shot? Thoughts? I've been thinking about playing around with my disassembler, but wondering if I am better off using Ghidra, especially since people talk about "ghidra servers" and mutual reverse engineering efforts.

https://github.com/lab313ru/ghidra_amiga_ldr/

[alexh]

It's being used extensively to reverse engineer Ambermoon

[Nightshft]

When I try to build the amiga_ldr extension using gradle I just get this error. (I've not used gradle before). Any Ideas how to solve this?

Btw, I installed JDK 17.0.7 and Gradle 8.1.1.

Edit:

Now I was able to build Bartmans fork of the extension with gradle.
However still no luck in installing the extension.
In the "Install Extensions" list the entry is there, but in red colour.

Am I supposed to build the extension using gradle or just place the folder/zip at the right place and Ghidra will build it when selected?
Sorry, I don't have experience in this...
Using Ghidra 10.3 public btw...

[paraj]

I just downloaded the release (https://github.com/BartmanAbyss/ghid...s/tag/20230525) and installed that without compiling it myself, and it works fine with Ghidra 10.3. No need to compile it yourself unless you want to.

To install, open file->install extensions..., press the green + button and select the zip file (don't extract it).

[Nightshft]

Well now that really took some tries...
but now it works. Thanks paraj

Note:
Ghidra 10.3.1 still wouldn't take it.
Extension version for [extname.zip] is incompatible with Ghidra.
I had to edit extension.properties to reflect version 10.3.1 and then it worked finally =)

[copse]

Thanks for the notes paraj and nightshift. These are valuable hints to save time, much appreciated.

[arkiruthis]

I used Ghidra for finding the terrain gen in PowerMonger, but I have a question about it.

The "Languages" section of Ghidra, without realising I selected the "68000 Coldfire" language option initially thinking it was just 68000.

There's language options for 68020 and 68040 big endian as well. It worked fine, but for amiga dissassembly I'm not 100% sure which one I should be using. There doesn't seem to be a 68000 "default" big endian option and I don't think Coldfire was the same chip.

[Thomas Richter]

The coldfire instruction set is a subset of the 68000 instrution set, so some instructions would likely be marked as invalid. The 68020 is a superset of the 68000 instruction set. As long as the source does not use any of the 68040 specific instructions, or only 68000 instructions, you would be safe.

[a/b]

Coldfire aka cpu32, you can check the m68k programmer's ref guide if you are interested in details. Basically, it has a small subset of the 68020+ stuff, doesn't have all of the base 68000 stuff, and it has some exclusives that 68000+ don't have.

[arkiruthis]

Thank you both!

[hop]

I'm using Ghidra with the Amiga extension to analyse a C executable, which uses the small data model. Is it possible to pass a base register and value to the analysis so to that data labels can be derived? The equivalent of the ira config BASEREG and BASEADR directives.

[paraj]

Originally Posted by hop

I'm using Ghidra with the Amiga extension to analyse a C executable, which uses the small data model. Is it possible to pass a base register and value to the analysis so to that data labels can be derived? The equivalent of the ira config BASEREG and BASEADR directives.

Window->Script Manager->Scripts->Amiga->ApplyRegBase is the closest you'll get AFAIK (only works for A4).

[hop]

Magic! That seems to have worked thanks.

[arkiruthis]

I've been analysing a raw RAM export (.data) from WinUAE in Ghidra for quite a while now. Naming functions, renaming labels and data areas, etc.

I want to swap out the RAM data for another snapshot (.data), where I think certain areas will have been updated, but I'm not seeing an easy way to do this?

It's a difficult thing to phrase as a question in Google as well (and google seems to be pretty bad lately, no idea why, so I'm not getting good results there either).

[copse]

This sounds like a general Ghidra problem and nothing Amiga specific beyond the context of the data. You should be able to search for people doing this for other architectures.

There is a default symbol import plugin. In the worst case you might be able to see how to export/import symbols and other metadata.

[copse]

Does anyone have any experience with getting Ghidra to recognise jump tables that it does not already recognise in decompiled Amiga code?

My long term Pool of Radiance disassembling project was accelerated by finding that the C# rewriting of disassembled or decompiled Curse of the Azure Bonds PC code had almost identical data structures and code to my Amiga decompilation. But it's stalled on the ECL script VM given Ghidra didn't pick up on the jump tables and map in all the functions.

For reference in case anyone is interested, I had a long term Resource file of my disassembly and saved out the program file from Resource with my symbols. Then I imported that into Ghidra. A lot of my work has I think been perhaps not being clear on where the boundaries of what I am told the Pascal (?) compiler's statically linked functions are thunked in and documenting those structures and functions. But it only has to be done once I guess, then all gold box games are mostly an exercise in repeating the first (given the visible Amiga Pool of Radiance and PC Curse of the Azure Bonds similarities).

[copse]

Anyone tried updating the amiga plugin for Ghidra 11?

[alexh]

Originally Posted by copse

Anyone tried updating the amiga plugin for Ghidra 11?

Yes

https://ghidra.nicode.net/

[copse]

Nice, will give it a shot. Thanks Alex.

[copse]

Just installed 11.0.1 and the 11.0 Amiga extension from nicode. I get a version mismatch message for 11.0.1 not being 11.0, but can click through it. No errors so far.