Date: Tue, 11 Feb 2003 08:57:42 -0500
From: Peter Huang <[email protected]>
To: [email protected]Subject: Followup: breakpoint the stack buffer overflow from executing maliciouscode like SQL Slammer worm
Andrew McGill emailed me with the following comments:
> This is a nice technique - however it is quite probable that a
> jmp esp instruction can be found which is preceeded by an
> innocuous instruction ( add bx,si ; jmp esp ... ) ... "quite
> probable" in the above means I haven't actually looked.
That was a very good question. Actually, I thought about the above more
after my original post and came up with the following. The basic concept is
⌠there will be no void parameter function call or traditional WINAPI call■.
For a void parameter function:
1. Call SomeVoidFunction()
The compiler will generate this code such as:
Push 0
Call SomeVoidFunction
Add esp, 4 ; can be pop ecx etc.
In the called function SomeVoidFunction itself, it is coded as:
Add [esp+4], 0cch
ret
2. Call SomeApiFunction(par1, par2 .. )
The compiler will generate this code such as:
Push 0
Push ..
Push par2
Push par1
Call SomeApiFunction ; PASCAL-style
Add esp, 4 ; can be pop ecx, etc
In the called function SomeApiFunction itself, it is coded as:
Mov [esp+4+X << 2], 0cch ; where x is the parameter number
Ret X << 2
3. For a normal C function with parameter, it is still coded as:
add [esp+4], 0cch
ret
This method will work to call old existing libraries because it just wastes
a few cycles with ⌠push 0■ and ⌠add esp, 4■.
However, the 0CCh-inserted libraries or object files will not work with old
call methods (without extra push 0 and pop).
Best regards
Peter Huang
For the latest update on this thread, pls visit
http://members.rogers.com/yinrong/articles/BreakpointBufferFlow.htm
