13 May 2009, 15:43 | #1 |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
Advice on disassembling non-relocatable code
Has anyone got any advice for ways to successfully disassemble code that was initially assembled as non-relocatable ie. was probably originally made with org statements or crunched with one of those fixed location packers to place it at fixed memory locations on loading?
When I say 'successfully disassemble' I mean well enough that I could get it to reassemble and run again as relocatable code. For example, how could I go about changing statements like: jsr $3670a or subq.w #1,$38604 into relocatable equivalents like: jsr subroutine or subq.w #1,counter Is such a thing even possible? I would presume yes but I'm no expert by any means as you'll have already figured out from the fact that I'm asking! |
13 May 2009, 16:06 | #2 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
First of all, creating fully working disassembled code of absolute address code is not easy! You need to carefully examine the code to decide what is a label and what is an absolute offset. As an example take this piece of code:
Code:
move.l #$50000,d0 Obviously you need to know the base address of the code to calculate the offsets. In ReSource you have a function "Origin->Specify" which is used if you need to disassemble absolute address code. ReSource will calculate all offsets relative to this address then. Still, this is anything but easy and very time consuming to do. Good luck! |
13 May 2009, 20:56 | #3 |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
My first thought is: oh dear, one of the 'daddies' of generally all things asm round here is telling me it's complicated... Might be a step too far for me in that case.
But, you don't get anywhere if you don't try as they say. Worth a stab and I'll hopefully learn some stuff too. Cheers StingRay |
14 May 2009, 10:27 | #4 | |
Digital Corruption
Join Date: Jan 2007
Location: Dorrigo/Australia
Age: 60
Posts: 355
|
Hi PMC,
Quote:
If so, this is a pretty easy task. Say for example that program loaded at $080000-$09FFFF, and complete ignores the normal Memory allocation system. You need to: 1. Use a monitor program to AllocAbs this memory area. (if not possible, grab a similar block at say $180000-$19FFFF, and tweak the loader module to load code here instead). 2. Load the program code in after tweaking the loader module to return to the operating system. 3. Use ReSource to dissassemble the raw memory block. 4. Any references inside the upper/lower bounds typically need to be de-referenced. Hope this helps, Red p.s. Easier if you have access to a WinUAE machine, and the built-in debugger. |
|
14 May 2009, 11:15 | #5 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
Using AllocAbs is not what I call relocatable... Also you can do all this using "Origin->Specify" in ReSource as I already said, no need to load the file into memory and patching/writing a loader etc.
Last edited by StingRay; 14 May 2009 at 11:21. |
14 May 2009, 13:01 | #6 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
Hi,
Can you put the original file into the zone. I want also try. Regards |
14 May 2009, 21:43 | #7 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,655
|
I'm a bit of a noob at disassembling, but if he just wants something assemblable (new word, wohoo!) that he can look through and pick bits of code from, doesn't he just have to specify the origin and then start setting data types until end of program?
No nice labels, and as Stingray said some references could be constants instead of offsets, but the source would assemble and work I think? |
14 May 2009, 21:57 | #8 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
If he would just like to have something that he can assemble again he could just use ReSource, disassemble it and use ORG/LOAD to assemble it to original address. That's however not what he wants. So he would indeed have to specifiy the origin in ReSource and carefully decide what is a relative offset and what is a constant etc (i.e. must NOT be changed). Not sure what he's trying to disassemble, if it's an old intro/demo he may also have to fix/change some code to have fully relocatable code (screens aligned to 64k boundaries, fixed plane addresses in the copperlist (dc.w $e0,$7,$e2,$0 f.e.)). For small things it's easy and simple but if there's a lot of code it will require a lot of needlework.
|
15 May 2009, 08:41 | #9 |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
Watcha chaps.
What I've been messing with is disassembling one of my favourite old skool demos - Phenomena's Flight Of Dreams II. I'm doing this cos I want to learn more about disassembling and also I want to look at the routine that does that wavy pic thing in the middle of the screen. I've written about three different routines myself that attempt something similar but none of them give such a nice result. I've been finding that I'm learning the most when I have a good think about an effect, have a few stabs at coding what I think will give the same effect and, depending on the results, then look at other source codes (if I can find them...) to see how an effect was actually done successfully. This way I'm gradually expanding my understanding. But I digress... After reading StingRay's advice on disassembling absolute code I did this: First, I decrunched the executable demo file with XFDDecrunch. Then I made a possibly incorrect assumption (not sure...) in that XFDDecrunch output showed "saving relocated image (addr: $35BEC jmp: $35BEC)". For my first stab at disassembling with Origin --> Specify, I've therefore assumed that $35BEC is where the ByteKiller cruncher orginally used was set to ORG the demo to on loading. So, I loaded the binary image of the decrunched demo into ReSource and set Origin --> Specify as $35BEC. This changed absolute references in the code to relative references. Then I did a disassemble. This seemed to work quite well - much better than just doing a disassemble without setting the Origin - as ReSource made quite a good job of separating code from data, for example correctly identifying things like the ASCII scroll text from the demo which it didn't do until I set Origin --> Specify. Since then I've been going through the data sections and trying to make sure they're set to the correct format. And that's as far as I've gotten... Now you can all tell me what an idiot I've been and how wrong I am! Don't worry about hurting my feelings, I can take it. |
15 May 2009, 09:31 | #10 | ||
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
Quote:
Quote:
Edit: Just had a quick look, there shouldn't be any problems disassembling the demo, no fixed screen addresses, even uses buffers for the screens etc. Should be very easy to disassemble. If you do it correctly, it should run anywhere in chipmem. Last edited by StingRay; 15 May 2009 at 10:11. |
||
15 May 2009, 10:54 | #11 |
noodle
Join Date: Jun 2007
Location: europe
Posts: 247
|
advice : first search save system and init routines.
$9a(a6), $96(a6), $9c(a6), $80(a6)... you can reach the new VBL interruption and the Copperlist addresses : $80, $6C with the copperlist registers, you can start to understand a little bit more what are some addresses "move.l #$3a082,d0 move.l d0,$3853e ; $dff0e2 (bitplan 1) ..." and know where are the screens/logo buffers and after that, what do subroutine jsr xxxxx ... |
15 May 2009, 12:03 | #12 | |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
Quote:
I do have a quick question. On disassembling the demo there's a paticular section in the code that looks like this: Code:
lbc00069a addq.w #1,lbw000b1c.l dc.w $c79 lbw0006a2 dc.w 6 dc.w 3 dc.w $6708 Code:
lbc00069a addq.w #1,lbw000b1c.l cmpi.w #6,lbw000b1c.l lbw0006a2 equ *-6 |
|
15 May 2009, 12:44 | #13 |
Registered User
Join Date: Jun 2008
Location: somewhere else
Posts: 524
|
Yes this have the same meaning and this is probably self modifying code (the #6 here is probably modified somewhere else in the program via a move to lbw0006a2) .
Beware that there's some bugs in resources like all the 4.w, a6 being disassembled as 4,a6 (or $6c.w as $6c) thus taking one word more than the original code when being re-assembled, this can be important in absolute code context as that will shift the rest of the data as well so any absolute reference may be broken. |
15 May 2009, 13:15 | #14 | ||
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
Quote:
If you set the data type to words, you'll see something like dc.w $0c79 (opcode for cmp) dc.w 6 (this word gets modified). Edit: not pattern break but speed! Quote:
Last edited by StingRay; 15 May 2009 at 13:27. |
||
15 May 2009, 14:27 | #15 |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
Success.
I've got a disassembled, relocatable version of Flight Of Dreams II now. Just assembled and ran it with Devpac with no problems. Thanks for all your explanations chaps - they really helped a lot. Now I just need to try working out which routines do what to learn some new things. Cheers boys! |
15 May 2009, 14:35 | #16 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
Congrats. Now have fun peeking around in the code. =)
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Disassembling an A600 | Revival9001 | support.Hardware | 2 | 31 January 2017 07:01 |
Disassembling games to find out the game logic? | Jonathan Drain | Coders. General | 14 | 20 November 2012 02:24 |
Disassembling resource | copse | Coders. General | 1 | 02 April 2012 03:36 |
Disassembling and reassembling | absence | Coders. General | 7 | 22 September 2009 15:30 |
Disassembling games for fun | crabfists | Coders. General | 69 | 29 October 2008 11:20 |
|
|