PDA

View Full Version : Disassembling Amiga roms with IDA, how?

dELTA
March 6th, 2003, 19:21
I have an Amiga rom-file. The format is "adf", and it's some standard type of packed Amiga disk format.

I would like to disassemble the program located in this rom, but IDA cannot (quite understandable) read the format. I must first extract the executable file from it I guess (68000-assembler based executables, they should be supported by IDA).

Does anyone know how I can extract the pure files out of that adf-file, so that I can disassemble them? All the converter programs I can find can only convert it to a genuine amiga floppy disk (which cannot be read by PC's mind you).

Any ideas?

PS.
The reason for this is that I want to _remove_ a trainer from a game in such a rom file. I can only find it in a version where the trainer is applied whether I want it or not, and that sucks.
JailBox
March 7th, 2003, 14:15
Hi dELTA

Go take a look at wotsit dot org, they got some info on ADF
Manko
March 7th, 2003, 14:29
I'm wondering... Is this a kikstart-bootdisk for Amiga 1000?

Anyway... Since the amiga emulator reads this format... Use the emulator to load it. Then use the tool for extracting Amiga-roms to file and save it to your hd...
If you're lucky it's just a file on that disk. Then just copy to hd...

Will it work? Be glad to hear if it does....

/Manko
dELTA
March 7th, 2003, 14:30
Thanks for the tip JailBox. If I now only can find a website where I can download 2 weeks of spare time I'm sure I would have great use of it.

Is there possibly anyone who's got a tip of a somewhat more practical nature?
dELTA
March 7th, 2003, 14:38
Manko, the idea is good and I've had it too, but the problem is that I cannot find any emulator or tool that can export data to the "outside of the emulator", and hence I cannot store anything from inside the emulator to a file on my physical disk. Also, just so you know, the roms are mounted as floppy disks in the emulator.
Manko
March 7th, 2003, 15:01
Hmm... UAE can use ide-hds... Easy to get anything out the amiga then.

But maybe you're not using PC?
ehrgel... let me rephrase... Maybe you're not using windows? Is there a linux version of ida?

/Manko
squidge
March 7th, 2003, 16:58
I've seen an Amiga emulator that allow you to "mount" a PC directory as a Amiga harddrive. Can't remember the name however
dELTA
March 8th, 2003, 08:26
Thanks for the tips! I will try to get the executable file out of the rom (disk image) with UAE. If I succeed, and succeed in patching the game, I fear it will be even harder to get the patched file back into a disk-image file though, but let's hope for the best.
Manko
March 8th, 2003, 08:41
Hmm... Me, stupid! I thought you were talking about the kickstart_rom all the time, when you were in fact just talking about a gamedisk...

I guess, worse case, this mightbe a trackread-bootdisk. If so, you're gonna have to get a hold of some old amiga "cracking" tools to extract and unpack the gamefiles... This might involve some amount of learning if you haven't got the skills since earlier... Hmm.

Ok, maybe not SO difficult. It unpacks itself and then you "dump" to disk... Well, well...

On the other hand, it MIGHT be even easier. Sometimes games WAS put on normal amiga-filesystem-disks...

BUT if you get it out, crack it, and want to put it back... It's easy!
You just put it to the mounted HD in WIN, and then in emulator copy it to disk, replacing original...

If it's trackdisk, though, you'll have to edit the trackloader and maybe repack with something and put to disk again...

I'm eager to hear statusrepports!

/Manko
dELTA
March 8th, 2003, 09:05
Thanks again for the info Manko. It's actually my friend who's got the Amiga emulator and the file, so I've asked him now to try to get the file out with UAE and send it to me, and if he succeeds I will take a look at removing the trainer from it. So, status reports will depend on how lazy he is to get out the file from that disk, but if he succeeds, I'll be sure to tell you how it all went.
Manko
March 8th, 2003, 09:17
Hehe... A thought just occured to me... It might actually be easier to get a hold of a version of the game, without a trainer, just searching the net. ;P (OK, stupid me, you wrote in the first post, you had (or your friend) already searched... But anyway...)

What's the name of the game?

/Manko
dELTA
March 8th, 2003, 14:10
The name of the game is "Gravity Force", and for some reason all copies of this old Amiga rom-file that is in circulation seem to have the trainer in them (even the ones that don't claim to have it).

PS.
My friend did of course own a legal copy of this game 15 years ago on his Amiga, he promised.
SiNTAX
March 19th, 2003, 06:22
Ohh this brings back fond memories.. hell I wonder why I bothered to make trainers if people just want to get rid of them :-)

Why do you want to remove the trainer? For the exercise or because it fails to run on your UAE?

Since there is a trainer on the game, it means that it was already cracked. So most likely you will find a trackloader in the bootsector. It is probably patched to first load the trainer, which will then put a value somewhere in memory indicating which trainer options you request.

Afterwards the main game will be loaded and at the start of it, there might be a patch routine that reads that value that the trainer left behind and then put the necessary redirections in place.


In the old days, there was no IDA.. so for game stuff, Action Replay was used.. and for normal executables, Resourcer, was your friend (the Amiga equivalent of IDA -- also very powerful)



Anyway.. if you get stuck and need advice.. feel free to ask.
dELTA
March 19th, 2003, 11:01
Nice to hear from people from the good old days, thanks for the tips SiNTAX.

I still havent been able to disassemble the code in the first place though, and hence I cannot analyze the code either. I did figure myself that the loader code would be quite easy to identify and patch away somewhere in the very beginning of the code though, like you say.

The reason for wanting to remove the trainer is that it is impossible to disable it, and hence the game looses much of its fun when you're always invincible and can go through walls and so on.

The disk does not seem to have a file system, could that be the case? Was it usual that the code execution just started in the boot sector, and then it loaded any further needed data from the disk "manually", hence not needing any real file system?

Also, could Action Replay disassemble code, or just search/compare data, like the Action Replay's for most products today? How did you otherwise disassemble code that was not in "normal executables" like you called it?

Thanks!
dELTA
Manko
March 19th, 2003, 12:24
Hi again!

Yup, the thing I called a trackloader is found first in the bootsector which you can easily read/write with tools for the amiga. (Dunno where to get those now, though.)

Yup, trackloaders was very common on game-diskettes. It was faster. And it was perhaps deemed to be more secure... ?

I don't remember much about the various cartridges, though I owned one variant which was often updated, and you could program it yourself too... Hmm... whatever it was named...
But they were deffinitely much more powerfull than what you mention about todays variants.

It's sad I remember so little... Anyway, hope to hear more on this from more knowledgable people...

/Manko

Quote:
Originally posted by dELTA
Nice to hear from people from the good old days, thanks for the tips SiNTAX.

I still havent been able to disassemble the code in the first place though, and hence I cannot analyze the code either. I did figure myself that the loader code would be quite easy to identify and patch away somewhere in the very beginning of the code though, like you say.

The reason for wanting to remove the trainer is that it is impossible to disable it, and hence the game looses much of its fun when you're always invincible and can go through walls and so on.

The disk does not seem to have a file system, could that be the case? Was it usual that the code execution just started in the boot sector, and then it loaded any further needed data from the disk "manually", hence not needing any real file system?

Also, could Action Replay disassemble code, or just search/compare data, like the Action Replay's for most products today? How did you otherwise disassemble code that was not in "normal executables" like you called it?

Thanks!
dELTA
SiNTAX
March 26th, 2003, 10:25
Quote:
Originally posted by dELTA
Nice to hear from people from the good old days, thanks for the tips SiNTAX.

I still havent been able to disassemble the code in the first place though, and hence I cannot analyze the code either. I did figure myself that the loader code would be quite easy to identify and patch away somewhere in the very beginning of the code though, like you say.

The reason for wanting to remove the trainer is that it is impossible to disable it, and hence the game looses much of its fun when you're always invincible and can go through walls and so on.

The disk does not seem to have a file system, could that be the case? Was it usual that the code execution just started in the boot sector, and then it loaded any further needed data from the disk "manually", hence not needing any real file system?

Also, could Action Replay disassemble code, or just search/compare data, like the Action Replay's for most products today? How did you otherwise disassemble code that was not in "normal executables" like you called it?

Thanks!
dELTA


Are you looking at the disk via UAE in AmigaDOS, or just looking at the UAE .ADF file?! If I'm not mistaken, the ADF file is just a dump of every sector on the disk -- an amiga disk being 80 tracks, 2 sides, 11 sectors/cylinder, 512 bytes/sector -> 512*11*80*2 = 901120 bytes in total.. )

So.. the initial trackloader (or the complete one, if it's a compact version) will be in the first 1024 bytes of the file. If you put those 1024 bytes in another file and then use IDA and tell it it's 68000 code, then you should be able to disassemble it. (the first 4 bytes = 'DOS\0' if my memory serves me right).

Depending on the trackloader, it will use AmigaDOS or the hardware directly. The AmigaDOS version will issue a JSR -offset(a6) (where offset = _LVODoIO of dos.library -- check google for the parameters
The hardware version will be more complicated, as that one will step the floppy head itself and do the MFM decoding.. but most crackers used a self-made routine which usually was called with track/sector start + length... you might wanna search for the hex byte $4489 or $55555555.. the first is the MFM sync word, the second is a mask that is used for the MFM decoding.. if you find those, it's a hardware loader. -- don't forget that 68000 is big endian.


As for the action replay... yups it had a disassembler (without labels or anything... sometimes also refered to as a monitor instead of a disassembler). Searching for bytes was ofcourse also possible.. as was assembling instructions (it was always a bit of a guess what address you had to use on a branch etc.. as you had no labels

As for disassembling code not in executables... well an Action Replay could freeze the Amiga at any time and allow you to poke around in memory.. so if you knew where stuff got loaded, you could patch it. (but ofcourse, there were also anti-action replay tricks -- but I'll keep that for another mail :-))
SiNTAX
March 26th, 2003, 10:55
Quote:
Originally posted by Manko

Yup, trackloaders was very common on game-diskettes. It was faster. And it was perhaps deemed to be more secure... ?
/Manko


The reason was probably that you could use up all available memory and didn't have to leave AmigaDOS intact.. ie. you could take over the complete machine (which 98% of the games did).. and once you took over the machine, there was no other way than to write your own diskloader to load data from floppy..

People that had to write loaders, didn't really feel like writing the amiga dos filesystem layer also. Most used offset+length.. but some games had loaders that used a custom filesystem.

Most also used non standard syncs, layouts to prevent copying.

Popular anti-copy tricks used at the time:

- using more than 80 tracks (easily copied if you knew)
- using non standard syncs (you needed the sync to know where the start of the data was, as there is no start/end on a circle
- increased write density of the data.. ie putting more data on a track than a normal drive could write, reading was no problem with a normal drive... you could copy these disks with a normal drive by slowing down the drive motor.

Probably the most widely used protection was RNC (Rob Northern Computing) -- this prot used the single step->decode eip (pc) trick to prevent reversing. 1 track was used as copy protection (non-std sync and written with a special copier.. altho you could still copy it with a normal drive, if you had the right tool )


Those were the days... sniff..
dELTA
March 26th, 2003, 15:04
Thanks for the info SiNTAX, a very interesting and fun history lesson!

A while ago I looked at the ADF specification, and then disassembled the whole ADF-file as a "binary file" of 68xxx format in IDA. IDA then wants an entrypoint offset from me, so I gave it the entrypoint where the first sector started in the file.

As you said, it first had a couple of instructions, and then an a6-relative call. IDA did completely misunderstand this call, and after that all was crap. I knew that the a6-register was pointing somewhere into a system library, but not where.

Would the trainer code presumably be placed after this call (i.e. it would be executed after the return of this call) or would it in some way be reached before the return of that call, and in that case how would I locate it?

dELTA
SiNTAX
March 26th, 2003, 19:02
Quote:
Originally posted by dELTA

As you said, it first had a couple of instructions, and then an a6-relative call. IDA did completely misunderstand this call, and after that all was crap. I knew that the a6-register was pointing somewhere into a system library, but not where.

Would the trainer code presumably be placed after this call (i.e. it would be executed after the return of this call) or would it in some way be reached before the return of that call, and in that case how would I locate it?

dELTA


The load will probably look like this then (code snippet grabbed from a google search):

movea.l (4).w,a6
move.w #CMD_READ,(IO_COMMAND,a1)
move.l #$78000,(IO_DATA,a1)
move.l #$2C00,(IO_LENGTH,a1)
move.l #$400,(IO_OFFSET,a1)
jsr (_LVODoIO,a6)

As you can see, the jsr expects a structure in A1, filled with load address, length and offset of the data to load. (the A6 is loaded with the value at $4 which is a fixed address on the amiga that contains the exec.library address). When the bootsector code is called, A1 already points to a valid IORequest structure, so you just need to fill in the correct value to load something else.

The first load will probably load the trainer bit, jump to it and on return load the rest OR the load loads the gamecode+the trainer in 1 go, and then the boot loader jumps to the trainer, which then shows a menu or whatever and then jumps to the address of the game code.

You need to follow the code to know what happens.
dELTA
March 28th, 2003, 06:41
Well, the problem with "following the code" is sadly that it just seems to end in the middle of nowhere (according to IDA's understanding of it anyway).

The initial code, which is quite similar to your example, is the following:

Code:


ROM:0000000C                 movea.l (dword_4).w,a6

ROM:00000010                 move.l  a1,-(sp)

ROM:00000012                 move.w  #2,$1C(a1)

ROM:00000018                 move.l  #$2A00,$24(a1)

ROM:00000020                 move.l  #loc_78000,$28(a1)

ROM:00000028                 move.l  #$200,$2C(a1)

ROM:00000030                 jsr     -$1C8(a6)

ROM:00000034                 jmp     loc_78000

IDA craps out on me if I try to display the opcodes ("Division by zero", kaboom, crash...).

As you can see, there is a jump immediately after the call to the operating system procedure.


Here is the code that is located at the destination of this jump:

Code:


ROM:00078000 loc_78000:

ROM:00078000                 move.b  -(sp),-(a6)

ROM:00078002                 move.l  $2929(a1),-(a4)

ROM:00078006                 move.l  $2929(a1),-(a4)

ROM:0007800A                 btst    d6,(a3)

ROM:0007800C                 move.b  (a6),-(a3)

ROM:0007800E                 move.b  (a6),d3

ROM:00078010                 move.b  (a6),d3

ROM:00078010 ; ---------------------------------------------

ROM:00078012                 dc.b $16 ;   What's this?

ROM:00078013                 dc.b $63 ;   IDA won't decode.

ROM:00078014                 dc.b   0 ;  

ROM:00078015                 dc.b   0 ;  

ROM:00078016                 dc.b   0 ;  

ROM:00078017                 dc.b   0 ;  

ROM:00078018                 dc.b   0 ;  

ROM:00078019                 dc.b   0 ;  

ROM:0007801A                 dc.b   0 ;  

ROM:0007801B                 dc.b   0 ;  

ROM:0007801C                 dc.b   0 ;  



... and so on ...

As you can see, the code simply seems to stop in the middle of nowhere? That is, if the two bytes that IDA can't understand isn't some kind of jump?

Any ideas?
SiNTAX
March 30th, 2003, 18:36
Quote:
Originally posted by dELTA

Code:


ROM:0000000C                 movea.l (dword_4).w,a6

ROM:00000010                 move.l  a1,-(sp)

ROM:00000012                 move.w  #2,$1C(a1)

ROM:00000018                 move.l  #$2A00,$24(a1)

ROM:00000020                 move.l  #loc_78000,$28(a1)

ROM:00000028                 move.l  #$200,$2C(a1)

ROM:00000030                 jsr     -$1C8(a6)

ROM:00000034                 jmp     loc_78000

IDA craps out on me if I try to display the opcodes ("Division by zero", kaboom, crash...).

As you can see, there is a jump immediately after the call to the operating system procedure.


Well if you follow my reasoning before, you should be able to see what this is doing

loc_78000 is ofcourse the ADDRESS the data is loaded to. And the other 2 params are the size of the data to load and the offset on disk where to load from (I don't have the docs anymore, so I'm not sure what is what.. my guess is that the #$200 is probably the offset, and #$2A00 the size of the data to load).

So.. instead of letting IDA disassemble 78000, just grab 2A00 bytes from your ADF file, located at offset $200 and resource that (and tell IDA that it's base address is 78000)

.01 way there.. 0.99 to go
dELTA
April 2nd, 2003, 06:51
Ah, I see, cool. The code at this location actually looks like a typical trainer stub. A bunch of apparent inline patches, and some other smaller code. Sadly, I feel I'm a bit in over my head in this 68000 asm and also lacking the necessary Amiga system knowledge to actually do something about it. It doesn't make it any better either that IDA can't understand the file format, so lots of adresses are wrong, and it's a real pain in the ass from this point on to know where any absolute jump or call will land.

Well, it was an interesting insight anyway.

dELTA
SiNTAX
April 2nd, 2003, 15:01
Right.. did this just for the fun of it, as the trainer DID work OK, ofcourse if you don't enable Collision Detection in your emulator, well...

(Config->Chipset->Collision Level set it to FULL instead of the default SPRITES ONLY)


Anyway as for how to patch the actual trainer thingy:

Code:


RAM:00078122 loc_0_78122:                            ; CODE XREF: RAM:0007812Aj

RAM:00078122                                         ; RAM:0007814Aj

RAM:00078122                 cmpi.b  #-1,($DFF006).l

RAM:0007812A                 bne.s   loc_0_78122



** this waits till the video beam is out of sight (bit like vertical retrace)





RAM:0007812C                 bsr.w   sub_0_782E2



** probably those dancing copper bars, didn't really look



RAM:00078130                 btst    #$A,($DFF016).l

RAM:00078138                 bne.s   loc_0_78142



** test RMB



RAM:0007813A                 move.l  #'RGHT',d5

RAM:00078140                 bra.s   loc_0_78152

RAM:00078142 ; ---------------------------------------------------------------------------

RAM:00078142 

RAM:00078142 loc_0_78142:                            ; CODE XREF: RAM:00078138j

RAM:00078142                 btst    #6,($BFE001).l

RAM:0007814A                 bne.s   loc_0_78122



** test LMB



RAM:0007814C                 move.l  #'LEFT',d5

RAM:00078152 

RAM:00078152 loc_0_78152:                            ; CODE XREF: RAM:00078140j


So.. register D5 is filled with LEFT/RGHT depending on which button you pressed. Then lateron, the D5 is checked and the game code is patched:

Code:


RAM:00078270                 cmpi.l  #'RGHT',d5

RAM:00078276                 bne.s   loc_0_78286

RAM:00078278                 clr.w   (word_0_3DB98).l

RAM:0007827E                 move.w  #$4A79,(word_0_3ED68).l

RAM:00078286 

RAM:00078286 loc_0_78286:                            ; CODE XREF: RAM:00078276j


Just before this snipped is another load, probably the gamecode itself.

Pretty straight forward stuff.. this was fun.. pity it wasn't a harder target
dELTA
April 4th, 2003, 11:33
Thanks SiNTAX!
Always nice to see people doing obscure things that their really good at. Maybe I can show off my x86 cracking skills in some forum in 20 years or so, when it has become a forgotten art too.

About that collision detection, is it implemented in hardware in the Amiga somehow since it could be fixed with a setting in the emulator?!? How is this possible?

dELTA
SiNTAX
April 4th, 2003, 17:26
Quote:
Originally posted by dELTA
Thanks SiNTAX!
Always nice to see people doing obscure things that their really good at. Maybe I can show off my x86 cracking skills in some forum in 20 years or so, when it has become a forgotten art too.


You make me feel old! Ohwell the language/toolbox change, but the concepts stay the same.

Quote:


About that collision detection, is it implemented in hardware in the Amiga somehow since it could be fixed with a setting in the emulator?!? How is this possible?

dELTA


Amiga had 'sprites' (like the C64, or the 'object' concept on GBA, SNES).

The custom chips could do collision detection in hardware for sprites (ie. sprite-to-sprite, or sprite-to-bitmap).

Since emulating those custom chips is very cpu intensive (esp. cycle-exact), you can turn it off in UAE.


If you don't know the concept of sprites, just compare it to a hardware cursor of your GFX card.. ie a small piece of bitmap that you can freely move around on the screen, just by setting it's coordinates. (VERY fast operation.. just 2 MOV's). Amiga could display 8 sprites on 1 scanline (or more with some trickery).. vertical size wasn't limited, horizontal was.

Anyway.. all that hardware support from those custom chips was what made the amiga special. (the same like today, ie your GeForce4 making your PC special )
dELTA
April 5th, 2003, 06:40
Cool! I'd never think that they had hardware graphic support all the way back then. As always, thanks for the tales from the good old days SiNTAX, very interesting!

dELTA
naides
April 1st, 2004, 19:48
Quote:
[Originally Posted by dELTA]Cool! I'd never think that they had hardware graphic support all the way back then. As always, thanks for the tales from the good old days SiNTAX, very interesting!

dELTA


I just want to thank Delta for this relevant thread!!! It is already a classic
dELTA
April 1st, 2004, 20:28
Haha, you bastards, watch it so I don't make that a forum rule for real.
Kayaker
April 1st, 2004, 21:47
Oh I think I peed myself...
dELTA
April 2nd, 2004, 07:56
Haha, shut up, I'm trying to scare the non-admins here!
JMI
April 2nd, 2004, 13:55
Has dELTA even been here for two years? I know what his postbit says, but he's an admin and can change it. I certainly don't recall him being here in 2001 when I joined.

Regards,
JMI
April 2nd, 2004, 17:21
O.K.

Upon further "reversing" of one of the old backups of the board, I can report that dELTA posted here 2 times in 2000, with the earliest being on 10-30-2000 in thread 1108 (and 1179); 5 times in 2001, with the first being 02-26-2001 (1456) and last on 08-22-2001 (1756). All of these posts were as "Guest." As late as 03-23-2002, dELTA was still posting as "Guest."

The first post I have found with dELTA as a "registered" poster is dated 08-25-2002 (thread 3670) so it would appear that some "changes" have been made somewhere in that "join date. (The directorate denies any implication in the preceeding statement as to who may be responsible for any changes. )

Just for the record, the backups do not go back beyond thread 90 and Kayaker has a post in thread 91, dated 10-31-2000, which is the first I can find. The first one of my own I have found is in thread 460, dated 04-23-2001, which IS consistent with my own "join date."

So it would appear that dELTA could "protest" he had "been here" longer than two years , but it would appear also to be correct to state that he would not have been a "member" for two years until around August of 2004.

Anyone wishing to "confirm" this information may use:

http://www.woodmann.com/forum/showthread.php?t=

with the mentioned thread numbers and confirm my findings.

Regards,
Woodmann
April 2nd, 2004, 18:05
Howdy,

The problem is from changing board software if I recall correctly.
There was also a time when we had a problem with database transfer
and had the temp board.

For the record, listing the first 10, oldest first:

Kayaker
Fake51
LaptoniC
JimmyClif
CrackZ
Woodmann
dELTA
+SplaJ
Mike
esther

How the hell I am not at least #2 baffles me

Woodmann
dELTA
April 2nd, 2004, 20:46
Thanks for looking that up JMI, I actually always knew that I didn't "adjust" my join date far back enough, but since I didn't know the real date I held back a little to make sure I didn't "cheat" at least. Now it's adjusted to the date of that first post you found, even though I know I was practically here from day one anyway. This fact is even quite conveniently supported by the fact that I am referring to "the old board" in that first post of mine you mention above. And actually, I was not posting as a guest at that time either, but my original account was deleted due to some technical problems, and I had to create a new one. All posts made by any account that has been deleted are automatically turned into "guests", which is the explanation for that.

Anyway, I've been around since even before +Fravia himself came up with the great idea to start a forum at all. and at that time I had already read each and every article on his fantastic original static site too, mind you.
JMI
April 2nd, 2004, 21:37
So dELTA, what you are telling me is that you are the one who gave +Fravia the idea to start the Forum in the first place. Maybe either he or Tolkien, whose picture is often posted as +Fravia's, was
actually your father. No wait, I know who your father is. And that your Mom can cook.

And even though you had read all that stuff on the "static site" by the time you were 18 or so, and were in on the start of the Forum, you still seem to have had only 10 or so posts in the two years between 10-30-2000 and 08-25-2002, followed by 860 more since August 2002. So, young man, just what the heck were you doing during those two years.

And Woody, you're always #1 in my book.

And I supect that I'm still really the "oldest."

Regards,
dELTA
April 3rd, 2004, 07:02
Quote:
And even though you had read all that stuff on the "static site" by the time you were 18 or so, and were in on the start of the Forum, you still seem to have had only 10 or so posts in the two years between 10-30-2000 and 08-25-2002, followed by 860 more since August 2002. So, young man, just what the heck were you doing during those two years.

Oh, I don't know, cracking stuff, lurking, getting a master's degree in computer science? Or maybe it has something to do with the board problems woodmann mentions, or the earlier problems with my account.