Advice on disassembling non-relocatable code

[pmc]

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!

[StingRay]

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:

	move.l #$50000,d0

The original code was running at say address $40000. Now, how to interpret the $50000 here? It can either be a relative offset (i.e. $40000+($50000-$40000)) or just a constant that is used for something. Without examining (and understanding) the disassembled code you won't be able to create a working disassembly that is relocatable.

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!

[pmc]

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

[RedskullDC]

Hi PMC,

Originally Posted by pmc

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

Do you know the original load address, upper/lower bounds of the program, and start address?
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.

[StingRay]

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.

[Asman]

Hi,

Can you put the original file into the zone. I want also try.

Regards

[Photon]

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?

[StingRay]

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.

[pmc]

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.

[StingRay]

Originally Posted by pmc

So, I loaded the binary image of the decrunched demo into ReSource and set Origin --> Specify as $35BEC.

Origin $35BEC is correct.

Originally Posted by pmc

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.

You aren't wrong. That's how to do it. Watch out for fixed addresses in the copperlist for logos etc. ReSource obviously can't create labels in that case (Hint: watch the offsets in the titlebar and create the labels yourself). You'll also have to write code to initialise the planepointers then of course. =) Good luck disassembling the demo, if you get stuck just post in this thread and I'll try to help you.


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.

[heavy]

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

[pmc]

Good luck disassembling the demo, if you get stuck just post in this thread and I'll try to help you.

You're an asm hero and a gent. Thanks StingRay.

I do have a quick question. On disassembling the demo there's a paticular section in the code that looks like this:

lbc00069a   addq.w #1,lbw000b1c.l
                dc.w $c79
lbw0006a2  dc.w 6
                dc.w 3
                dc.w $6708

If I move the first of these dc.w lines to the top of the ReSource display and manually set the data type to code, the display then shows as this:

 
lbc00069a   addq.w #1,lbw000b1c.l
                cmpi.w #6,lbw000b1c.l
lbw0006a2  equ *-6

Which one is correct, is there any difference? - I presume not as in memory, the assembled code would still just be the same sequence of bytes. What does *-6 mean in this case? I know that * is a standard reference in C64 6510 assemblers for denoting the current position of the program counter - does the same apply in this instance?

[hitchhikr]

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.

[StingRay]

Originally Posted by pmc

 
lbc00069a   addq.w #1,lbw000b1c.l
                cmpi.w #6,lbw000b1c.l
lbw0006a2  equ *-6

Which one is correct, is there any difference? - I presume not as in memory, the assembled code would still just be the same sequence of bytes. What does *-6 mean in this case? I know that * is a standard reference in C64 6510 assemblers for denoting the current position of the program counter - does the same apply in this instance?

This is selfmodifying code in the replay routine, used to handle pattern break I think. The *-6 means "-6 bytes from current PC" which would be lbW0006a2-6 which is the "cmp.w #xx" instruction (4bytes for the absolute address, 2 bytes for the opcode) that gets modified.
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!

Originally Posted by hitchhikr

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.

If you enable the "New Syntax" checkbox in the "Options1" menu ReSource handles the short addressing modes correctly. I agree that it is a bug though.

[pmc]

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!

[StingRay]

Congrats. Now have fun peeking around in the code. =)