Ghidra disassembler / decompiler supports 68000

[mark_k]

Has anyone else checked out the recently-released Ghidra tool? It's an interactive disassembler/decompiler which was developed by the NSA. Kind of similar in functionality to IDA Pro + Hex-Rays decompiler, except it's free and open source, written in Java.

It supports several CPU architectures including 68000. The decompiler works too! This could make reverse-engineering and understanding 68000 code a lot easier. Maybe it could help with porting 68000 code to C too (e.g. crunchers/decrunchers).

It doesn't support the Amiga load file format but does support ELF. But assuming it's possible to convert Amiga load files to ELF that's not a huge problem.

Here's a screenshot I took after loading a Kickstart ROM image into it:
hXXps://www.media!fire.com/view/eldsf8c599m1t9p/Pic.png/file
[EAB doesn't allow direct links; change hXXtps to https, remove !]
That was done with basically no manual analysis on my part. Note the decompiled version on the right side.

It would be great if people who know Java and the Amiga could contribute stuff like Amiga load file support, register names etc. And maybe definitions from the include files which are built into ReSource. There's a GitHub repository where eventually pull requests could be made?

[nogginthenog]

I saw this in the usual places but I didn't imagine it supports 68k. The reversed C looks interesting.
No source on github yet. Are the NSA hacking us

[malko]

Looks interesting, but.... ~280MB archive for a disassembler / decompiler (1GB HD space after install). Ouch !

[mark_k]

Not to mention the Java runtime if you don't already have it. But it's not like you'll be installing it on your old Amiga HD...

After unpacking you could browse through the directory tree and delete all the source code archives (filenames ending in -src.zip) which should free up a little space.

[Minuous]

It's written in Java and also presumably full of NSA spyware, those two things probably explain the bloat.

[StingRay]

Originally Posted by Minuous

also presumably full of NSA spyware

That's why it is Open Source, right...

[Minuous]

And who has audited every line of this huge amount of code? Eg. an accidental flaw like Heartbleed in a small widely used piece of code can go unnoticed for years. Let alone if someone actually wanted to obfuscate and hide something in a much larger piece of code. Also there is the possibility of compromises further up the tool chain.

[StingRay]

Originally Posted by Minuous

And who has audited every line of this huge amount of code?

Apparently you have as you already know that there "presumably" is spyware hidden... Are they selling tin foil hats again these days?

[Minuous]

So you missed the whole Snowden thing? https://www.dailydot.com/layer8/nsa-...rview-blarney/ But that's all just a figment of my (and the rest of the world's) imagination I suppose?

[Gorf]

As much as I am aware of the use of spyware by these organizations: It would make no sense in this case, so it is highly unlikely:

It is the NSA - so everybody expects something fishy and every hacker or foreign service would be glad to find some evidence (spyware, backchannel) in the code. So it will be looked at very closely.

The NSA has plenty of other and better tools to spy on people.

Spying is not the primary goal of this release - at least only in a very indirect way:
the NSA is hoping for some input from the open source community, to
a) make their own software better and
b) identify coders that are good at dissembling binaries for later recruitment.

[WayneK]

I somehow doubt the NSA are going to backdoor a tool that is going to be used by a large number of the world's best reverse engineers... that would seem like a certain path to an epic fail.

On topic - it's a pretty impressive tool honestly, even if I'm more used to IDA. My only complaint is the analysis time, it's about 10* slower than IDA on a decent sized PE file for example. But it does indeed support 68000 (and good ARM support also), which a free IDA does not, so I guess it wins by default?

[Hewitson]

That C "code" is pretty ugly to say the least. Why would you want to convert asm to C anyway? Sounds like a huge amount of work, and the end result being that the code runs slower.

[Gorf]

Originally Posted by Hewitson

That C "code" is pretty ugly to say the least. Why would you want to convert asm to C anyway? Sounds like a huge amount of work, and the end result being that the code runs slower.

to better/easier understand what is happening?

If you are a master in 68k-asm you probably don't need it, but such a tool, can give you more insight of the code structure

[Hewitson]

Doesn't look like it gives a lot of insight to me. I'd rather read the asm (and I'm far from a master in 68k).

Maybe it could be useful if the C "decompiler" was improved.

[dalek]

I think the point is to convert back to a common "standard" so that it's easier to run malware analysis and heuristic scans on the decompiled code.

For example - malware that targets a particular library vulnerability - that happens to be compiled for arm/x86/68k/power which was originally written in a high level language...

[meynaf]

Originally Posted by Hewitson

Doesn't look like it gives a lot of insight to me. I'd rather read the asm (and I'm far from a master in 68k).

Quite valid point for 68k. But it's less obvious for e.g. x86, for which i'd personnally prefer bad C...

Originally Posted by Hewitson

Maybe it could be useful if the C "decompiler" was improved.

It might be a great tool if it were able to produce C that actually compiles and works. But i doubt anything can do this (my attempts at hex-rays failed).

[StingRay]

Originally Posted by Minuous

So you missed the whole Snowden thing? https://www.dailydot.com/layer8/nsa-...rview-blarney/ But that's all just a figment of my (and the rest of the world's) imagination I suppose?

Sure, it really has a lot to do with the tool being discussed here. But yes, it is probably full of spyware and completely unusable as it was made by the NSA. Feeling better now?

[mark_k]

Originally Posted by Hewitson

Doesn't look like it gives a lot of insight to me. I'd rather read the asm (and I'm far from a master in 68k).

Maybe it could be useful if the C "decompiler" was improved.

Bear in mind (if you're just going from the screenshot I uploaded) that the decompiler output is as-is, without any hints from me. As you work on a disassembly, you can name variables and specify their types (e.g. pointer to a specific structure) and give functions proper names. Then the decompiler output will become much better, closer to (maybe even better than) the original source code.

For hardware-hitting Amiga code, it would be fairly easy to teach Ghidra about the custom chip and CIA registers so accesses to them could automatically show register names.

It also seems possible to teach it about compiler library functions so they would be recognised automatically. Kind of similar to the way ReSource's CFuncs.rcl can recognise some Aztec C library functions. No more wasting time disassembling a function only to discover it's printf().

[mark_k]

How to convert Amiga hunk executables to ELF? I tried using vlink latest release binary, vlink_AmigaM68k.lha) and it gives an internal error (must be a vlink bug?) when I tried to convert C:List. That executable just contains a single code hunk, nothing fancy.

> vlink -b elf32m68k List
Warning 12: "List" is already an executable file.

INTERNAL ERROR: elf32_makeshdrs(): PHDR " dummy" offs 84 != 52
.
Aborting.

[Bruce Abbott]

Originally Posted by Hewitson

That C "code" is pretty ugly to say the least. Why would you want to convert asm to C anyway?

For some architectures it makes sense, but 68k machine code is so easy to follow that it probably isn't worth converting to C (I found the 'C' code in the sample screen shot was harder to understand than the disassembly, even with its funny syntax).

Sounds like a huge amount of work, and the end result being that the code runs slower.

It might not be slower, but this decompiled 'C' code is only one step above assembler. All the real high level stuff was lost during compilation and can never be retrieved.

Originally Posted by mark_k

As you work on a disassembly, you can name variables and specify their types (e.g. pointer to a specific structure) and give functions proper names. Then the decompiler output will become much better,

Sure you could do that, but it's a lot of work - probably more than just rewriting the program from scratch. And the decompiled output still won't look much like the original source code, unless it is able to identify specific compiler constructs and reproduce them accurately (so unless the NSA suddenly gets an interest in ancient Amiga C compilers...).

(maybe even better than) the original source code.

Unless the original source code was deliberately obfuscated I very much doubt the decompiled output will be better. More likely it will be a bloated hard to follow mess.