amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

[Login] [Register] [Forgot your password?]

< Next messagePrior message >
17.May.2023



Reverse Engineering: Speedball 2
In terms of games (software), reverse engineering is the process of analysing the code and content of the game to understand how it works. A GitHub page provides software tips and learning materials for interested developers. In this case, Simon Frankau has taken on the Amiga classic Speedball 2.

Based on his previous analysis of the Sega Megadrive version, he used the reverse engineering tool Ghidra for the disassembly. Below, he described to us how he followed the boot process to obtain a memory image:
  • Disassemble the boot block (first couple of sectors of the ADF) to find how it loads the second-level loader. The boot block uses ROM routines, so I had to learn about how to call the OS from assembly.
  • Once I knew where the second-level loader was in the disk image, I could disassemble that. This loads the main binary. The second-level loader has its own disk routines, so I got to learn about the sector encoding of Amiga disks (with MFM) and the blitter.
  • From there, I learnt where the main binary was, and could extract it from the ADF. It's compressed, so I reversed the compressor and wrote my own implementation to decompress the binary.
  • At this point, I had a memory image representing the game after loading and decompressing. I loaded it into Ghidra and worked through it, understanding it and giving names to all the functions and variables, and adding comments.
  • I also built tools to extract and the graphics and sounds and make them accessible.
As he goes on to describe, the copy protection (although the game has been cracked) uses Rob Northen's Copylock, a kind of trace vector decoder. To undo this, I used FS-UAE's debugger to track what it was doing.

Overall, this project would have helped him immensely to learn a lot about the Amiga, as the game makes good use of the hardware:
  • It uses the copper for scrolling and palette management.
  • It uses the blitter to render sprites and do disk decoding.
  • It uses the sound hardware and vertical blanking interrupt for a mod-player-like sliced player.
  • It uses the CIA and other i/o for keyboard and joystick.
  • Some graphics resources were embedded IFFs, so I learnt about them.
The code would have been pretty good, in his opinion - he could usually figure out what the developers were up to, even though there were no symbols or comments, and he discovered few bugs. He found it amusing that the copy protection routine, despite its complexity, only changes three memory locations.

Despite the hardware differences, the code is very similar to the Megadrive version, which would a) show how easy it is to port it to 68000 platforms and b) make decoding the Amiga version easier.

The binary would contain a few pieces of dead code, such as a team-selection menu, but unlike the Megadrive version there are not cheat codes.

The AI was pretty simple, given how well it plays! The AI doesn't cheat: it interacts with the rest of the game by writing to the variables that would otherwise be written to by the joystick routine for a two player game. (dr)

[News message: 17. May. 2023, 06:05] [Comments: 0]
[Send via e-mail]  [Print version]  [ASCII version]
< Next messagePrior message >

.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.