17 August 2017, 12:59 | #1 |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
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 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?
|
17 August 2017, 17:28 | #2 |
Registered User
Join Date: Oct 2009
Location: Germany
Posts: 3,304
|
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.
|
18 August 2017, 10:08 | #3 | |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Quote:
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.... |
|
18 August 2017, 14:47 | #4 |
Registered User
Join Date: Oct 2009
Location: Germany
Posts: 3,304
|
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.
|
18 August 2017, 15:08 | #5 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,196
|
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
|
18 August 2017, 17:51 | #6 |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Cheers guys, I've set up my Action Replay III... Time to see what I can find
|
18 August 2017, 18:26 | #7 |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
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! |
18 August 2017, 19:16 | #8 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,196
|
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. |
18 August 2017, 21:57 | #9 | |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Quote:
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 |
|
19 August 2017, 13:00 | #10 |
Registered User
Join Date: Mar 2017
Location: Minehead / UK
Posts: 608
|
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. |
19 August 2017, 13:00 | #11 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
It is not. It's headerless raw code.
Quote:
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. |
|
19 August 2017, 23:56 | #12 | ||
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Quote:
Quote:
-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. |
||
20 August 2017, 01:11 | #13 |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
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 :-| |
20 August 2017, 08:50 | #14 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,196
|
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? |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Gods reverse engineering | Kroah | Retrogaming General Discussion | 127 | 27 February 2023 14:46 |
Megatraveller 1 reverse engineering | TreacleWench | Coders. General | 12 | 18 May 2020 12:46 |
Reverse engineering wiki | copse | Coders. General | 10 | 02 March 2020 09:48 |
Captive 2 reverse engineering | copse | Coders. General | 2 | 19 August 2015 21:08 |
Cadaver reverse engineering | Kroah | Retrogaming General Discussion | 8 | 11 November 2011 09:35 |
|
|