Disassembler for 68K

[jotd]

Magic Pockets level format was so clear that I reverse engineered it without looking at the source

I agree that trying to look up obvious counters is the way to go. Same goes for lives when you're trying to reverse gameplay, player position vs enemies, etc... Start by something, and work your way up. Instead of staring at the code all day.

[zero]

Originally Posted by jotd

I use to find mainloops all the time for instance to find levelskips or insert CD-music play. I have a good technique with WinUAE. Let me explain.

Play the game and break with shift+F12.

First get rid of the case where you're in an interrupt with "fi RTE", then "t". Unless there's a trap within an interrupt, that should get you back in non-VBL part of the game.

Note down the value of A7. Then use "fi" instruction to find next RTS and "t" to return from it. See if A7 increases. If it doesn't, that's because the RTS is from a subroutine. So ignore that one.

After a few moments, you find the highest A7 value. Means that you're in the main loop. Put breakpoints here and there to find the point beyond which the breakpoint doesn't hit. There's probably a label, and below a BRA to it.

Thanks, that's great advice and I'll try it!

[zero]

Originally Posted by WayneK

Since the first post was about reversing the level format, if the individual levels are loaded from disk I would find the disk loader (search for writes to DFF07E/DSKSYNC, work back to find the loader entrypoint then find references to this) and breakpoint after loading to find what the game does with the loaded data (typically depack it then parse it, so it should be one of the first few subroutines called after loading).

It pre-loads everything and I think it probably uses AmigaDOS to do it since the disk is standard AmigaDOS format.

My progress so far is to decode the level tiles and tile map, they are in a trivial format on disk. It's just the enemy placement I can't figure out. There must be some data with all the enemies locations and some stuff about what kind they are, what type of shots they have etc. Actually it's probably just indexes to lookup tables because the enemy behaviour changes with the difficulty level. On normal a lot of them don't shoot back, on hard everything does.

[zero]

Originally Posted by hitchhikr

I realize that i didn't include the .rs (for Resource): http://franck.charlet.pagesperso-ora...mp/side_rs.zip

Thanks. What do I open it with?

[hitchhikr]

The Resource disassembler, i uploaded the latest version in the zone.

Be sure to use "New Syntax" (in "option 1") (fixes a bug).

[jarre]

and for windows you can use IDA PRO V6.8, which you can find here:

https://ufile.io/bly28

[kamelito]

Does IRA recognize hunks symbols if présents in the executable and use them in the produced source file ?

[jotd]

yes, it does. What I'd like is a tutorial to do multi-pass with IRA. This is my number one choice because it's batch (at least for first pass) and you can rework the text using batch tools.

I've written a few python tools over IRA to make system calls appear clearly for instance, or to detect self modifying code or cpu dependent loops.

One python module I discovered today was capstone (directly available via pip/pypi). It can disassemble a huge number of CPUs and even 68060 is supported. I made a quick test:

import capstone

code = b"\x4E\x71\xf2\x10\x44\x00"   # NOP + a FPU 040 instruction

md = capstone.Cs(capstone.CS_ARCH_M68K,capstone.CS_MODE_M68K_040)

for i in md.disasm(code, 0x1000):

    print("0x%x:\t%s\t%s" %(i.address, i.mnemonic, i.op_str))

this prints

0x1000: nop
0x1002: fmove.s (a0), fp0

[phx]

Originally Posted by jotd

yes, it does. What I'd like is a tutorial to do multi-pass with IRA.

I am aware that a good tutorial for IRA is needed. Reassembly is always multi-pass, until you reach the point that the source may be freely modified without risking to break something.

I did an extensive tutorial in german on the a1k.org forum, several years ago. Maybe a quick translation could already be helpful, but better would be to rewrite everything based on the latest IRA version.

Otherwise, anybody may always ask me for help.

[zenox98]

Originally Posted by phx

I am aware that a good tutorial for IRA is needed. Reassembly is always multi-pass, until you reach the point that the source may be freely modified without risking to break something.

I did an extensive tutorial in german on the a1k.org forum, several years ago. Maybe a quick translation could already be helpful, but better would be to rewrite everything based on the latest IRA version.

Otherwise, anybody may always ask me for help.

Even a Google translated version of your tutorial would be helpful , for me at least Any chance of a link, please ?

[Cyprian]

Originally Posted by zenox98

even a google translated version of your tutorial would be helpful , for me at least any chance of a link, please ?

+1

[jotd]

rule is: always write in english. After a while someone requests it

thanks in advance for the tutorial!

[kamelito]

Is there an option to recognize symbols? I can see that it found some but not all of them.
What is the link of your German tutorial ?
Better use deepl than google.

[phx]

Unfortunately a link to a1k makes no sense, because most sections are only accessible after registration.

Ok, so I just invested two hours to quickly translate the original tutorial text and copied everything over. The tutorial can be found here:
http://eab.abime.net/showthread.php?p=1387237

Hope it helps, although the tutorial is nearly 7 years old. But as far as I could see everything shown there should still work with recent IRA versions. Questions to IRA might be asked in the linked thread.

[zero]

Thanks for the assistance. I need to find some time to put into learning how to do this.

I was really hoping to avoid having to get too in depth with it and just get enough of a hint as to how Sidewinder interprets the level data files. It's probably not that complicated, I bet it's just some tile X/Y coordinates for spawning and probably some kind of virtual machine for movement.

[zero]

I've been trying out Ghidra with the Amiga hunk extension. I think it's struggling with Sidewinder because the game was written in assembler.

For example, there are a lot f lines like this:

*(int *)(unaff_A4 + -0x60f0) = iVar2;

Ghidra can't seem to understand the concept of using A4 as a data structure pointer.

A4 is hard coded to 0x22cede, which doesn't make a lot of sense to me. That appears to be right in the middle of autoconfig space on an A500.

[kas1e]

Today is the beginning of 2022, and I tried both IDA 7.5 (with all decompilers it has) and Ghidra.

IDA doesn't have by default decompiler to C pseudo-code from 68k, only disassembler. And do not know if it has it at all anywhere. But by default IDA has amiga-hunk support. So for disassembler needs it out of the box. But as it wants to be compiled by "as" probably there will be hard times to make reassemble from it. So IRA there won.

Through, IDA has decompiler for PowerPC (if anyone there in interest about at all), so I for sake of test trying simple:

#include <stdio.h>
int main()
{
     printf("asdfadsf");
}

And compile it for AmigaOS4, and IDA with PPC decompiler bring me back that:

int __cdecl main(int argc, const char **argv, const char **envp)
{
  puts("asdfadsf", argv, envp);
  return 0;
}

Of course, an example is nothing and very easy, but still, it shows that at least the basics of PowerPC decompilation works more or less ok. Surely it will have issues on bigger projects but at least it will help readability for sure. And as i aware there is no normal powerpc decompiler (i mean decompiler to c-pseudo-code, not disassembler).

But that for PPC, for 68k IDA didn't have c-pseudo-decompiler. And I don't find any in google (maybe anyone knows if there are any?)

But on Ghidra, while it didn't have by default support of AmigaHunks and which you install separately for example from there: https://github.com/lab313ru/ghidra_amiga_ldr , it does have decompiler for 68k by default. And together with the amiga_hunk extension, it gives pretty interesting results.

Disassemble by default different from IRA, but looks more readable. For example part about OpenWindow used from BlitBasic call on IRA:

MOVE.W D0,46(a4)
MOVEA.L A4,a0
MOVEA.L (A7)+,A4
JSR -204(A6)
MOVE.L D0,A3

Ghidra on the same place:

        10013e22 39 40 00 2e     move.w     D0w,(0x2e,A4)=>DAT_10014630
        10013e26 20 4c           movea.l    A4,A0
        10013e28 28 5f           movea.l    (SP)+,A4
        10013e2a 4e ae ff 34     jsr        (-0xcc,A6=>exec_AllocAbs)                        undefined dos_WaitForChar(pointe
                                                                                             undefined exec_AllocAbs(pointer 
                             -- Call Destination Override: exec_AllocAbs (0033f0cc)
        10013e2e 26 80           move.l     D0,(A3)

So a bit fucked up with JSR LVO (At it not exec), but probably because it can only detect bases for exec and dos, but not for others, we have that. Need to add, that when i use Jdot's "cheapres.py" it also fails to detect those bases, but at least wrote "unknown" on that place. But what is most good, is that decompiler in Ghidra works. And that is what it gives me for the same place of OpenWindow() call:

  DAT_10014630 = (undefined2)(*(ushort *)(DAT_10014620 + 0x14) & 0xffff000f);
  DAT_1001460a = unaff_D3b;
  DAT_1001460b = unaff_D4b;
  iVar1 = exec_AllocAbs((undefined *)
                        (DAT_1001461c & 0xffff0000 | *(ushort *)(DAT_10014620 + 0x14) & 0xffff000f),
                        DAT_10014620);
  *unaff_A3 = iVar1;
  if (iVar1 != 0) {

See, while it fucked with system call, of course, it still shows us how arguments are passed. And we can see types, places, values, etc. While with pure disassemble I am as one who knows only C a bit and very little of asm understand nothing and i were in needs to spend few hours to understand simple stuff, with such a decompiler all things start to be understandable out of the box.

Also, Ghidra's decompiler is good for all those "if/else" loops, see attach at the end of the post.

For sake of tests i also tried on Ghidra the same test case with prinfs of amigaos4 build (so PowerPC) binary (which is ELF).

Ghidra there detect ELF out of the box, i only was in needs to choose in language "PowerPC:BE:32:default:default" and have for the same printf such an output:

undefined4 main(void)

{
  puts("asdfadsf");
  return 0;
}

So, about the same as IDA.

In other words, and IMHO:

for amigaos3/68k: IRA + Ghidra defaul + amigahunk plugin
for amigaos4/powerpc: IDA or Ghidra can be used both.

[Bruce Abbott]

Originally Posted by kas1e

So a bit fucked up with JSR LVO (At it not exec)

Bummer! That wouldn't affect straight reassembly, but is a problem if you are trying to understand what the code does or translate it to a different language.

For example part about OpenWindow used from BlitBasic call... what is most good, is that decompiler in Ghidra works. And that is what it gives me for the same place of OpenWindow() call:

  DAT_10014630 = (undefined2)(*(ushort *)(DAT_10014620 + 0x14) & 0xffff000f);
  DAT_1001460a = unaff_D3b;
  DAT_1001460b = unaff_D4b;
  iVar1 = exec_AllocAbs((undefined *)
                        (DAT_1001461c & 0xffff0000 | *(ushort *)(DAT_10014620 + 0x14) & 0xffff000f),
                        DAT_10014620);
  *unaff_A3 = iVar1;
  if (iVar1 != 0) {

See, while it fucked with system call, of course, it still shows us how arguments are passed. And we can see types, places, values, etc.

Looks like garbage to me. But I can read 68k assembler better than C. With assembler I know what I am looking at. With C I have to think about it. For example, what exactly does "*(ushort *)" mean, and why is it being ANDed with 0xffff000f? Doesn't look like OpenWindow parameters to me!


Blitz BASIC was written in assembler and we have the source code for it, so I'm not sure what use 'decompiling' to C is when the original wasn't written in C.

While with pure disassemble I am as one who knows only C a bit and very little of asm understand nothing and i were in needs to spend few hours to understand simple stuff, with such a decompiler all things start to be understandable out of the box.

If you are more comfortable with C than assembler that's fine, but It may be more important to understand how code works on the Amiga. Decompiling old programs is of limited use IMO. Fine for seeing how something was done, fixing bugs or hacking games, but better to write your own code from scratch for anything serious.

[kamelito]

@bruce
Any estimated date for a public release of your disassembler?

[Bruce Abbott]

Originally Posted by kamelito

@bruce
Any estimated date for a public release of your disassembler?

Hoping to have something ready by the end of this week. Still have a few bugs to iron out, but right now I am mostly just tidying up the source code and splitting it into smaller sections to make it easier to focus on. I also need to write some instructions (perhaps in Amigaguide format) as what seems obvious to me might not be to you!

I will put a 'beta' version on The Zone for you guys to rip to shreds give me some feedback on before committing to a full public release.