English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 17 August 2017, 12:59   #1
bloodline
Registered User

 
Join Date: Jan 2017
Location: London
Posts: 22
Reverse engineering from an executable

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


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?
bloodline is offline  
AdSense AdSense  
Old 17 August 2017, 17:28   #2
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 1,710
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.
daxb is offline  
Old 18 August 2017, 10:08   #3
bloodline
Registered User

 
Join Date: Jan 2017
Location: London
Posts: 22
Quote:
Originally Posted by daxb View Post
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....
bloodline is offline  
Old 18 August 2017, 14:47   #4
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 1,710
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.
daxb is offline  
Old 18 August 2017, 15:08   #5
jotd
Cat freak
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 45
Posts: 1,883
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
jotd is offline  
Old 18 August 2017, 17:51   #6
bloodline
Registered User

 
Join Date: Jan 2017
Location: London
Posts: 22
Cheers guys, I've set up my Action Replay III... Time to see what I can find
bloodline is offline  
Old 18 August 2017, 18:26   #7
bloodline
Registered User

 
Join Date: Jan 2017
Location: London
Posts: 22
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!
bloodline is offline  
Old 18 August 2017, 19:16   #8
jotd
Cat freak
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 45
Posts: 1,883
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.
jotd is offline  
Old 18 August 2017, 21:57   #9
bloodline
Registered User

 
Join Date: Jan 2017
Location: London
Posts: 22
Quote:
Originally Posted by jotd View Post
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
bloodline is offline  
Old 19 August 2017, 13:00   #10
MartinW
Registered User

 
Join Date: Mar 2017
Location: United Kingdom
Posts: 108
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.
MartinW is offline  
Old 19 August 2017, 13:00   #11
meynaf
68k wisdom
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon (France)
Age: 44
Posts: 2,370
Quote:
Originally Posted by jotd View Post
If MLM is a true executable.
It is not. It's headerless raw code.


Quote:
Originally Posted by bloodline View Post

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...

Last edited by meynaf; 19 August 2017 at 15:04.
meynaf is offline  
Old 19 August 2017, 23:56   #12
bloodline
Registered User

 
Join Date: Jan 2017
Location: London
Posts: 22
Quote:
Originally Posted by meynaf View Post
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...

Quote:

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!?

Last edited by bloodline; 20 August 2017 at 00:26.
bloodline is offline  
Old 20 August 2017, 01:11   #13
bloodline
Registered User

 
Join Date: Jan 2017
Location: London
Posts: 22
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 :-|
bloodline is offline  
Old 20 August 2017, 08:50   #14
jotd
Cat freak
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 45
Posts: 1,883
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?
jotd is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Megatraveller 1 reverse engineering TreacleWench Coders. General 11 27 February 2017 11:51
Captive 2 reverse engineering copse Coders. General 2 19 August 2015 21:08
Gods reverse engineering Kroah Retrogaming General Discussion 68 26 August 2013 13:28
Cadaver reverse engineering Kroah Retrogaming General Discussion 8 11 November 2011 09:35
Reverse engineering wiki copse Coders. General 9 14 December 2009 01:25

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 01:51.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.25028 seconds with 12 queries