adown the stream of time, back in the old days… well in advance, after a while now and again everything will come in its proper time to put the clock back, for some time past - old UNIX tricks work! nothing new under the sun!

taking self-replication processes for example! Morris used this technique in his worm. the idea as simple as brilliant: a process forks every second, well, maybe not every second, but pretty often. what’s the point?! there’re two points guys! first! by default a debugger is able to debug only debugged process. the process, created by the debugged process is not debugged as well, like le vassal de mon vassal n’est pas mon vassal (”the vassal of my vassal is not my vassal“. so what?

let’s try to write a very simple program and try to debug it with Olly, IDA-Pro and Soft-Ice. we will see who is the beast and why I want to port Soft-Ice on Vista. this is the program. type it or download ("http://nezumi-lab.org/ffh/execlp.zip") source and binary.

main(c, v) char **v;{if (–c) printf(v[1]), execlp(v[0], v[0], &v[1][1], 0);}

it displays the argument passed via command line cutting one char every iteration. load the execlp.exe into OllyDbg, now \Debug\Arguments\ and type something like “- - - * - *”. restart the debugger by CTRL-F2 to apply changes and start the debug.

ops!!! every time when the debugger steps over 00401022!call execlp it just loses control, allowing the debugged program to fly out! did you expect something else? like what?! no way!!! le vassal de mon vassal n’est pas mon vassal!

btw, IDA-Pro 5.3 has a bug. the debugged process attached to a new console, but all children process creates another console. the secondary console is closed when the process is terminated, but the first console is still open even the debugger is terminated. OllyDbg has no this bug.

ok, what we’re going to do? I’m not a guru, so, lets find a guru and ask him or her. I would rather want to her, but… never mind. what ever. anonymouse ("https://www.openrce.org/profile/view/anonymouse")
said: “well then you can try using the modified commandline plugin get the latest from my repositary (i think the downloads doesn’t hold the latest one) and use its childdbg function to debug the childs in succession you can also use windbg with its .childdbg command here ("https://www.openrce.org/forums/posts/972") is a log of a session tracing this with ollydbg”

well, now we can debug children process as well, but… basically they’re the same. they execute the main loop and we want to trace only this loop. we’re not interested to trace start-up code every time. we want to set breakpoints, but… breakpoint affects only the parent process!!! not good. and this is the second point!

my solution is: to use hard-coded software breakpoints. just put breakpoint wherever you want with HIEW or other hex-editor (software breakpoint is just CCh byte) and load the program under your favorite debugger (IDA-Pro as an example). just do not forget to restore the original content under CCh code. for IDA-Pro and OllyDbg is easy to write a simple script/plug-in to automate the job.

ops!!! breakpoints in children processes cause crash! yes! coz they are not under debugger!!! who is supposed to catch the breakpoint expectations?! Soft-Ice of course!!! start Soft-Ice, type “I3HERE ON“, exit from Soft-Ice and run execlp.exe w/o debugger (Soft-Ice works in background).

wow!!! now we can debug children process _with_ breakpoints!!! now, our hacker’s life is a poem!!!

ok, another example (type it or download ("http://nezumi-lab.org/ffh/execlp_killme.zip") source and binary):

main(int c, char **v)
{ printf(”\rattach to me or kill me, my PID: %d”,
GetCurrentProcessId()); Sleep(33); execlp(v[0], v[0], 0, 0);}

try to attach to it or… kill the beast! just thinking the solution is simple. as the last resort press CTRL-Break, but… of course, the code might ignore it, so it’s just a loophole. real code will be not breakable by this simple trick.



http://nezumi-lab.org/blog/?p=153