Followup: breakpoint the stack buffer overflow from executing maliciouscode like SQL Slammer worm

["Peter Huang" <yinrong () rogers com>]

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