Reverse engineering from an executable

[bloodline]

Hi all,

I have a few days of free time coming up so I have decided to "reverse engineer" the old Megalomania executable to see where the sector data is stored, which would allow a more detailed trainer mode.

Over at the Ultimateamiga forum, Hungry Horace found the offsets for the island data.

The island type array can be found at offset 0x14080, it is an array of 28 bytes each one representing the land colour of the 28 islands:

0 = Light brown

1 = White

2 = Light Green

3 = Yellow

4 = Grey

5 = Dark Brown

6 = Dark Green

Change the values found here natural alters the island colour.

The next array is the island shape array and that can be found at 0x1409C.

This is a 448 byte array, with each island being represented by 16 bytes in a 4 by 4 grid like so:

0x0 0x1 0x2 0x3

0x4 0x5 0x6 0x7

0x8 0x9 0xA 0xB

0xC 0xD 0xE 0xF

With each byte representing the sector type (colour and coastline).

So far so good!

Now I need to try and find where the sector data is found. There appear to be two pieces of information store about each sector. The available elements (and their quantities) and the elements required for each weapon . Both of these things these appear to be fixed at the start of the game as they are the same each time you play the same sector, but are different per sector.

The location of the elements data is the first thing I want to find, this seems simple as no sector can have more than 4 elements, and we know

what each sector should have (published in Amiga Format: http://amr.abime.net/amr_popup_picture.php?src=amiga_format/magscans/af030_1992_01/166.jpg&c=54149 )

So my quest is to find where the elements for the first sector can be found.

My first assumption is that the element types will be an array of 4 bytes each indexing the element type (assuming 0 means no element) so the top sector of Aloha with Rocks (0x2), Slate (0x4), Solarium (0x8) and Herbrite (0xA) would probably look like 0x0204080A in the executable.

Searching through the executable does not find that sequence... Perhaps I made one too many assumptions?

So next I decided to search for the element quantities. The top sector starts with 100 Rock, 100 Slate, 50 Solarium and 75 Herbirite. Looking for the byte sequence 0x6464324B found nothing, so I thought about how elements are mined in 0.5 quantities. And since saving memory is a consideration, my guess the actual values used by the game engine are double what we see in the GUI, which probably divides by two for display… So I searched for 0xC8C86596, again this found nothing…

Is anyone here able to offer any advice?

[daxb]

When searching for byte sequence and don`t find something you could try to search for word or long size values. If a single byte search doesn`t give to much results you can check manually around the found for the other values. Ok, it is guessing but with some luck.

[bloodline]

Originally Posted by daxb

When searching for byte sequence and don`t find something you could try to search for word or long size values. If a single byte search doesn`t give to much results you can check manually around the found for the other values. Ok, it is guessing but with some luck.

Thanks daxb! I have tried looking for larger types but still nothing... I think one (or all) of my assumptions must be wrong

I have two thoughts now...
1. Run the code through a disassembler like ReSource and trying to remember 68k assembler (it's only been 20 years ) and actually try and follow the code.
2. Try using the decrementing opcode finder in Action Reply MkIII (I have an A500 and an AR MKIII ready to go... just no CRT), and see if I can find where the element data is being decremented....

[daxb]

I would start with 2. because it is (or seems) easier/less frustating. I think the way was/is to find the value and set a watchpoint at that address to get the code section. If you can remember assembler enough then it should be at least doable. If you succeed got the 1. way for a more pleasant examine experience.

[jotd]

Yeah it is almost impossible to disassemble staticaly and understand. Better fire up winuae with trainer tools to find interersing addresses and start from there

[bloodline]

Cheers guys, I've set up my Action Replay III... Time to see what I can find

[bloodline]

Ok, it looks like the mlm executable is loaded in at address 0x4000... so located 16k into the Chipram, locoing at an absolute address obviously avoids the need to relocate the code

Now time to try and watch what the code is doing!

[jotd]

you can use "RELOC" from whdload package to create a relocated image. If MLM is a true executable.

Note that IDA Pro can read amiga executables.

[bloodline]

Originally Posted by jotd

you can use "RELOC" from whdload package to create a relocated image. If MLM is a true executable.

Note that IDA Pro can read amiga executables.

The free version of IDA seems to be windows, and I'm currently Mac at the moment.

Anyway... I'm having a tough time with the Action Replay stepping tool... it keeps crashing the game

I've also been thrown a curve ball, in the form of a 298.5 quantity of slate in a sector on Cilla... I can't now guess what size variable I'm really looking for!

Fingers crossed Chris Chapman is passing by this thread and gives me a few hints

[MartinW]

The free version of IDA also doesn't do 68k or Amiga hunk, I looked into this about 2 weeks ago. The non free version is out of the question price-wise for small hobby projects such as this. When I used ReSource I found that on the executable I gave it, it was not able to correctly determine where code started and data began for example.

Maybe that's something that I need to train it. I've not had time to sit down and go through the very detailed documentation that it comes with yet. In my case I'm not working with a game so I don't know if the Action Replay would be applicable. I guess it would be applicable for any Amiga executable.

[meynaf]

Originally Posted by jotd

If MLM is a true executable.

It is not. It's headerless raw code.

Originally Posted by bloodline

So next I decided to search for the element quantities. The top sector starts with 100 Rock, 100 Slate, 50 Solarium and 75 Herbirite. Looking for the byte sequence 0x6464324B found nothing, so I thought about how elements are mined in 0.5 quantities. And since saving memory is a consideration, my guess the actual values used by the game engine are double what we see in the GUI, which probably divides by two for display… So I searched for 0xC8C86596, again this found nothing…

Is anyone here able to offer any advice?

I suggest you have a look at position 0x8228. I don't know what to find exactly, but if you want values such as 64,32,4B then there are many of them in this area.
If you know how many sectors exist in the game and all the values that depend on them, then perhaps you could map these (there are 72 16-bit values here).
Or maybe this is just something else, of course

EDIT:
Found 0064,0001,0032,004B,0064 at offset C734. Another place for you to look at...

[bloodline]

Originally Posted by meynaf

I suggest you have a look at position 0x8228. I don't know what to find exactly, but if you want values such as 64,32,4B then there are many of them in this area.
If you know how many sectors exist in the game and all the values that depend on them, then perhaps you could map these (there are 72 16-bit values here).
Or maybe this is just something else, of course

Good call... but I've tried to align what I can see with values in the game and nothing really adds up...

EDIT:
Found 0064,0001,0032,004B,0064 at offset C734. Another place for you to look at...

Ok... this looks promising... I'm going to see how altering these figures affect the game.

-edit- No... Altering the values here have no effect on Aloha

If only there was some unique and distinctive value to search for!?

[bloodline]

Ok, So I edited the island Aloha in memory (at address 0x1809C) by adding more sectors to the map... and these sectors are playable :-o . The values element in the unedited sectors is now different... So this means the Element data must be generated not stored.

My guess it that the element types are generated using pseudo random generator with a set starting seed to ensure the same values each time... Hungry Horace hinted at this...

My quest then, would appear to be futile :-|

[jotd]

Without IDA pro, you have IRA & search replace (isn't so bad).

About ARIII crashing the game: told you so It's better to use WinUAE with either built-in debugger or built-in HRTMon (closer to ARIII in terms of interface). Less chances to crash. 0 chance to crash with winuae debugger since it doesn't have to do anything with the CPU. It just breaks the emulator.

Not to mention you have access to powerful read/write memory breakpoints ...

And if you want to hack your game, why not fixing the random seed so you master what is generated?