Re: Backward disassembling (was: Re: 2.5.63 accesses below %esp)

[Jonathan Lundell <linux@lundell-bros.com>]

At 1:16pm +0100 3/14/03, Szakacsits Szabolcs wrote:
>  > Why not? Disassemble from, say, EIP-16 and check whether you have
>>  an instruction starting exactly at EIP. If no, repeat from EIP-15,
>>  -14... You are guaranteed to succeed at EIP-0 ;)
>
>Disassembling must be started "much" earlier. From your example one
>could get the impression you want to get the instruction right before
>EIP. It's not possible to go back this way. For example if you want to
>disassemble 100 bytes before EIP you must start at EIP-100 and EIP-99
>and ... and EIP-100-max_instruction_length+1. Then you have the right
>one among them (well, 99.9% but let's don't be too pedantic).
>
>You also can't stop the above max_instruction_length iteration when
>the next instruction address matches EIP. You can have even
>max_instruction_length matches. But from the additional info (code
>after EIP, assembly "quality", available source where the crash
>happend) you could choose the right one.

Sounds similar to the problem of recognizing valid plaintext when 
breaking a code.

As a practical matter (and in the context of this being a heuristic 
debugging aid, not a guaranteed 100%-correct method), I wonder 
whether one might not tend to sync up fairly quickly to the correct 
code. For example, strings of one-byte instructions provide a 
"landing zone" for disassembly leading up to them, and illegal 
instructions provide clues that you're out of sync (not perfect, but 
perhaps good enough).

I'm not in a position to do it right now, but I'd suggest trying it: 
disassemble hunks of random code on random boundaries, and see how 
many ways there tend to be of arriving at EIP+0, given enough of a 
BEIP running start (for some definition of "enough").
-- 
/Jonathan Lundell.