How is Ghidra compared to ReSource 6.02?

[LittleSandra88]

Dear all =)

Ghidra lists 68xxx as supported, so is that the one to use instead of ReSource 6.02?

Does anyone use Ghidra for their WHD work?

Hugs
Sandra =)

[jotd]

I don't

I'm using IRA + cheapres.py (that I have written). Text files, old school.

I tried Ghidra on a Z80 program it looped forever and did produce nothing... I suspect that old CPUs are better off with older tools. Kroah made a killing with IDAPro 68000.

[meynaf]

ReSource can directly produce a source that will assemble and run.
Ghidra does not.

[LittleSandra88]

Originally Posted by meynaf

ReSource can directly produce a source that will assemble and run.
Ghidra does not.

I found this howto which links to this plugin.

It can handle the the 68000 platform, and thanks to a plugin called ghidra_amiga_ldr, it can specifically handle Amiga executable files.

Or is this plugin to resolve another problem?

[LittleSandra88]

Originally Posted by jotd

I don't

I'm using IRA + cheapres.py (that I have written). Text files, old school.

I tried Ghidra on a Z80 program it looped forever and did produce nothing... I suspect that old CPUs are better off with older tools. Kroah made a killing with IDAPro 68000.

So the way IRA works, is that you do an initial run, write a config file what you want to change, and then run IRA again. And then repeat?

[meynaf]

Originally Posted by LittleSandra88

I found this howto which links to this plugin.

Reverse engineering and resourcing are two different things.
A disassembly listing is not an assemblable source.

[paraj]

In my limited experience Ghidra is an OK supplement, but doesn't really work that well with most amiga software (even if it's written in C and doesn't use dynamic loading/encryption) as common idioms aren't handled, e.g. custom calling conventions (limited support, but requires much effort), negative struct offsets, etc.

BTW the plugin mentioned here https://eab.abime.net/showthread.php?t=111845 seems to be an improvement, but isn't compatible with latest ghidra, so I haven't tried it.

[jotd]

Originally Posted by LittleSandra88

So the way IRA works, is that you do an initial run, write a config file what you want to change, and then run IRA again. And then repeat?

it's supposed to work that way, but I don't use it like that. I run it once, then I have written a post-processing tool (cheapres.py) which is able to find LVOs, custom chip offsets, annotate Ax-relative jumps and in the latest version you can name offsets/variables in special comments at the start of the asm file (which avoids to use a config file).

[LittleSandra88]

Originally Posted by paraj

In my limited experience Ghidra is an OK supplement, but doesn't really work that well with most amiga software (even if it's written in C and doesn't use dynamic loading/encryption) as common idioms aren't handled, e.g. custom calling conventions (limited support, but requires much effort), negative struct offsets, etc.

BTW the plugin mentioned here https://eab.abime.net/showthread.php?t=111845 seems to be an improvement, but isn't compatible with latest ghidra, so I haven't tried it.

Ok, thanks for clearing that out. I'll stick with ReSource then =)

[LittleSandra88]

Originally Posted by jotd

it's supposed to work that way, but I don't use it like that. I run it once, then I have written a post-processing tool (cheapres.py) which is able to find LVOs, custom chip offsets, annotate Ax-relative jumps and in the latest version you can name offsets/variables in special comments at the start of the asm file (which avoids to use a config file).

With ReSource I often have to change a data block into code, because it guessed wrong. How do you handle this case in IRA?

[jotd]

this is the most annoying issue IRA doesn't do better than the rest because it's a difficult issue. Maybe the worst issue.

I have other tools to detect data "sections", but they're not perfect. If you have one illegal instruction somewhere between 2 labels you could tell that the whole block is data, except that sometimes the entrypoint of the next routine is in a table somewhere and you're missing it because there's no direct jump / label to it (that's when you're reversing absolute assembled code, doesn't happen when reversing relocated executables)

So now I try to relocate all the code when it's not already relocated, figuring out jump tables. If you have all entrypoints figured out, then it's more secure to detect data in code "sections".

[LittleSandra88]

Originally Posted by jotd

this is the most annoying issue IRA doesn't do better than the rest because it's a difficult issue. Maybe the worst issue.

I have other tools to detect data "sections", but they're not perfect. If you have one illegal instruction somewhere between 2 labels you could tell that the whole block is data, except that sometimes the entrypoint of the next routine is in a table somewhere and you're missing it because there's no direct jump / label to it (that's when you're reversing absolute assembled code, doesn't happen when reversing relocated executables)

So now I try to relocate all the code when it's not already relocated, figuring out jump tables. If you have all entrypoints figured out, then it's more secure to detect data in code "sections".

Ok, then it makes more sense =)

[kamelito]

I use resource quite a bit but I use more IRA and cheapres.py these days because the iteration os a lot faster. To determine datas vs code I have WinUAE running and use Monam.

[jotd]

get the latest cheapres.py: https://github.com/jotd666/amiga68ktools.git

there's a nice FAQ I've written where new features are explained.

[phx]

Originally Posted by jotd

it's supposed to work that way, but I don't use it like that. I run it once, then I have written a post-processing tool (cheapres.py) which is able to find LVOs, custom chip offsets, annotate Ax-relative jumps

Hmm... but wouldn't cheapres.py be more effective if you call IRA with

-preproc

and then do a few iterations to find code/data?

and in the latest version you can name offsets/variables in special comments at the start of the asm file (which avoids to use a config file).

But the config file is your friend!
You could even assign symbol names in the config file, which stay on further iterations.

Of course, it always depends on what you want to do with the reassembled source. Do you just want to have a quick look what it does (then your approach could be sufficient), or do you want to modify and assemble it into a new executable?

[alexh]

Ambermoon was disassembled using Ghidra by Nico Bendlin and Pyrdacor with help from KermitFrog using a forked version of ghidra_amiga_ldr which has since been merged back upstream and and re-sourced using an exporter written by Pyrdacor.

It's a very impressive project.

https://github.com/Pyrdacor/AmigaAsm

I am not involved, so I don't know the full details, only screenshots of them working. As the code is understood and branch labels changed from their auto-generated ones to readable ones, macros defined the code slowly appears to becoming almost high level code once again. I think that is the power of Ghidra you can create a high-level description of the disassembly as you go. As a result Ambermoon is becoming more maintainable and modifiable while retaining the ability to be reassembled (unmodified) into a 1:1 binary.

It has allowed Pyrdacor to find and fix lots of bugs. Before re-sourcing bugfixes could only be made if the fix was the same size (or smaller) than the original code, now it doesn't matter. It has allowed him to make sweeping changes such as his universal executable that replaces separate English and German versions and loads text from files making it much easier to maintain and add new localisations.

[Wepl]

I use ReSource because I usually need to understand how code works. This is for me best achived by navigating through the code. Which is supported by interactive working with ReSource. I can also save my work (deciding code/data, labels, comments). Also searching in ReSoure is powerful.

[hop]

Originally Posted by jotd

get the latest cheapres.py: https://github.com/jotd666/amiga68ktools.git

My typical ira scripts disassemble, reassemble the diff the output vs input.
I've just added a call to cheapres.py in there (nice!).

I've just found myself modifying the cheapres.py source to add these lines:

    INCLUDE "custom.i"
    INCLUDE "LVOs.i"

I looked for a way of forcing vasm to include files on the command line, but couldn't find one. What's your solution for this, or do you always hand-edit after disassembling?

[copse]

I've switched over to ghidra. The code might not compile directly when I am done, due to use of non-standard data types and so on, but I can run a script over the code and probably only have to write it once for any future projects.

I am currently working on disassembling a chunk of memory saved out from WinUAE.

Some notes:

• One particular feature I like is going to a label and pressing CONTROL+SHIFT+f and I get a window with all the locations where that address is being referenced in a table alongside the code at each location.
  
• I don't know if it is possible in Ghidra, but I do miss Resource's macros. I am going word, word, string repeatedly. But if it has set the type of the string automatically it drags in a ambiguous byte from the preceding word, and I have to untype the string before I can set the type of the second word.
  
• Also finding broken code where there are unknown bytes in the middle of it is something I haven't been able to do in Ghidra easily.
  
• Both misidentify data as addresses if the value is in the range of the binary file memory location. But that's likely hard to avoid.

Ghidra is fine. I'd say give it a shot. Maybe you have to bodge the plugin version to get it to load in the latest release, given it's not actively maintained. But that's not a deal breaker.