Dissasembling machine code BEFORE the current program counter 
Author Message
 Dissasembling machine code BEFORE the current program counter

Is there any accurate method of determining the machine code opcodes
directly above the current instruction pointer? I'm trying to break machine
code down into 'blocks' deliniated by unconditional modification of the
instruction pointer (eg. call/jump/ret/relative jump/etc.). This is actually
intended to analyse blocks of Zilog Z80 machine code but I assume the
methods will be very similar to breaking down x86 machine code.
The instruction pointer should ideally be able to be given at any location
(it is assumed that the location given will produce valid machine code) and
the block in which the code at that pointer is located should then be
disassembled.

Thanks for any help,
Andrew



Wed, 26 Sep 2001 03:00:00 GMT  
 Dissasembling machine code BEFORE the current program counter

mure.freeserve.co.uk> writes

Quote:
>Is there any accurate method of determining the machine code opcodes
>directly above the current instruction pointer?

No. There is no 100% accurate way that you can tell whether the
instruction right before the current one is "mov ax, 04EBh" or an
unconditional short jump. In fact, it could be both for there exist
programs that occasionally jump into the middle of an instruction in
order to make reverse engineering the code a bit harder.

Quote:
> I'm trying to break machine
>code down into 'blocks' deliniated by unconditional modification of the
>instruction pointer (eg. call/jump/ret/relative jump/etc.). This is actually
>intended to analyse blocks of Zilog Z80 machine code but I assume the
>methods will be very similar to breaking down x86 machine code.
>The instruction pointer should ideally be able to be given at any location
>(it is assumed that the location given will produce valid machine code) and
>the block in which the code at that pointer is located should then be
>disassembled.

For x86, a 99% accurate way is to start disassembly somewhat before the
given EIP and discard the first 16 or so instructions of the disassembly
as potential rubbish. Most of the time it will have syncronized itself
after that.

The number 16 is derived from a sort-of-worst-case scenario where you
disassemble single byte instructions that actually are part of one
multi-byte instruction. Still, this is just a rule of thumb and there
are cases in which this doesn't work at all.

You could also use the current IP as a forced syncronization point ie.
if the stream of disassembly output does not contain the instruction IP
points to, re-start the disassembly pass one byte earlier (or later)
than the previous one, repeat until match, give up after n cycles where
the most accurate way to calculate n is to take the integer portion of
the value you obtain when you multiply the price of a pint down at your
local by the current day of month and add 9 to it, for good measure.

For the Z80 with a shorter maximum instruction length, things may be
different but I think that in real- world code, the disassembly will
eventually syncronize itself.

Regards,

Michael Tippach



Wed, 26 Sep 2001 03:00:00 GMT  
 Dissasembling machine code BEFORE the current program counter

Quote:

>                                                            This is
actually
>intended to analyse blocks of Zilog Z80 machine code but I assume the
>methods will be very similar to breaking down x86 machine code.

No, it's radically diferent with x86 machine code.  Backtracking from
a given point in x86 code is not necessarily a deterministic process,
and while that might also be true for a Z80, it can much much more
difficult to disambiguate instructions from data especially starting
with 386 code where there are 3 different sizes of immediate data
and also a possible SIB byte+data at the end of a memory or LEA
instruction.  On a Pentium classic at least, if the previous code
has been executed and is still resident in cache, you can read the
MSRs to find instruction boundaries but x86 code, like DNA, can be
and actually sometime is written so that its interpretation depends
on the starting point so even knowing the instruction boundaries
you have no absolute guarantee that you have deciphered all
interpretations of a given sequence of code that the containing
program actually uses.


Wed, 26 Sep 2001 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Sample code for Grey Code counter

2. Lisp Based Machine Code (Simulators) [was Re: Lisp Machines]

3. Lisp Based Machine Code (Simulators) [was Re: Lisp Machines]

4. Incrementing counter from state-machine

5. Dissasemble/trace a .SYS driver

6. dissasembling a dll - help

7. Verilog Code for Counters and Decoders

8. How to implement a Gray Code counter?

9. gray code counter in asyn FIFO design

10. grey code counter

11. Do gray code counters comsume less power

12. Coding Help with Counters

 

 
Powered by phpBB® Forum Software