Archive for February, 2009

# I’m on my way to South Africa

Hi all! Guess where I am now? In the dessert of cold snow, in the an international airport of Moscow on my way to Amsterdam (transit) and South Africa (the final destination). There is summer now, so from winter to summer – what’s a trip I’m going to get. Quite long trip I should say. I have not slept 3 days. My mind just freezing like beta version of Windows. But it’s worth what it costs. Far away from my den, I’m not alone. There are a lot of people here and I just enjoy talking and chasing girls. You know guys, girls are easy on trips. They’re expected to be diseased, oh, no not diseased, I mean they are just so sexy and they want what I want – find the best way to kill time.
I would rather watch girls on youtube, but wifi Internet is quite expensive here – about $10/hour. And I forgot my headset. Damn! There is so much noise, my ASUS eee has no too powerful speaker, so I hear nothing. Btw, my ASUS eee is she, not he. I’m not a gay after all. Um, don’t read this crap, I just too sleepy and type it for one reason only – do not fall asleep. It’s Moscow!!! You fall asleep and you lost everything you have had. In my case it’s ASUS eee with stuff prepared for RE-training, Nikon D80 (cheap, but good enough for me, however, I’m going to buy D300). Did I miss something? Well, cell phone, cash, etc. so, better to keep myself awake, typing any crap on my blog. Um, I will delete this post anyway :=) guess, nobody is going to read it. Well, maybe not. Maybe I’m wrong and people want to know how good (bad) Moscow it. Of course, different people have different points of view, but in general, Moscow is a huge, noise, ugly, dirty, cold city. Architecture is just awful. Much worse than Kuala-Lumpur, Tel-Aviv, Jerusalem or Amsterdam. I would not like here, I prefer to stay at my place – North Caucasus or… move to Israel, or to South Africa. Why not? Maybe I will fall in love with that place from the first sight. Who knows? The only way to find it out – check it out, making a try. So, I’m flying to South Africa.
Meanwhile – is was not easy to get my visa to South Africa! It was just a mess! We (me and Sense Post company) were very nervous about it. We all invested a lot of money and… getting a visa was a real issue, bug problem, solved from the both side. Sense Post grabbed lawyers to called to the embassy and explain how important to make a visa in time. Me? Well, I’m far away from Moscow and have no lawyers, but I asked the best traveling agency for help and it actually worked out!!! In 12 hours I’ll fly to Amsterdam. It’s about 4 hours. And about 13 hours of flying from Amsterdam to South Africa. Kind of torture, but never mind. I get used to it – changing places, planes, hotels. Sorry my terrible English. There is no dictionary, no spell-checker, and I just hate small notebook’ keyboard!!!

 

# JL/JGE Intel CPU bug as anti-reversing trick

months ago Bow Sineath (a very clever reverser!) asked me: “does JL [jump is less] instruction check ZF flag?” I said: “well, give me a second to think, well, it’s supposed to check it, otherwise it would act like JLE [jump if less or equal] and besides, JL is synonym of JNGE (jump if not great or equal), so JL should check ZF!“.

but, according to Intel’ manuals JL and JNGE check only if SF != OF. CMOVL/CMOVNGE work the same way. at that time I thought that it’s just a documentation bug and even pointed this out in my presentation on HITB 2008 conference.

fragment of Intel manual

fragment of Intel' manual

but I was wrong!!! I have checked it and found out that JL/JNGE does not check ZF flag!!! to do this I wrote extremely simple POC (if you’re too lazy to type, download source and binary):

__asm
{
mov eax, 002C2h ; S = 1, O = 0, Z = 1
push eax
popfd
jl jump_is_taken ; ==>
mov p, offset noo
jump_is_taken:
}

mov eax, 2C2h/push eax/popfd set SF with ZF and clear OF. so, SF != OF, but ZF is set. what CPU is going to do? easy to check with Olly! just load the program and start tracing. ops!!! JL is taken!!! JL ignores ZF!!! x86emu (plug-in for IDA-Pro) acts the same. didn’t check other emulators yet.

well, it’s interesting. why JL (and similar commands) ignores ZF?! guess, normal CPU command (like TEST/CMP/XOR/etc) never set ZF if result is less, so JL just ignores it. but… if we set flags manually or use other tricks… it becomes a real trap!!! consider the listing above and ask your co-worker: is the jump taken or not? I’m sure, some of them will answer: of course, the jump is not going to be taken! a good anti-reversing trick!!! I just wonder – how software is still working on buggy hardware.

JL does not check ZF flag as it is supposed to do!!!

JL does not check ZF flag as it is supposed to do!!!

 

# self-replicated processes

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 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
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 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 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.

 

# Olly Plug-ins and MS VC

oh, not again… I got so many letters “how to build Olly plug-ins with MS VC?“. so many too decide to answer here. (feel free to skip this post if you’re experienced enough). this is going to be step-by-step guide. and the first step is…

1) go to http://www.ollydbg.de/ and download PDK 1.10
2) unpack it and see. there are Plugins.hlp (documentation, but who read documentation after all?), Plugin.h (include file with all definitions); Ollydbg.def (def file for linker), Bookmark.c/Cmdexec.c/Command.c – source code of a few simple plug-ins we’re going to build; cmdline.rtf – documentation for Cmdexec.c plug-in; there is also /VC50 folder. open it and see VC-related stuff: OLLYDBG.LIB – library file for linker, *.mak and *.ds? files for make and Visual Studio. but we’re going to build plug-ins with our hands, so… what do we need?!
3) we need: OLLYDBG.LIB, OLLYDBG.DEF and PLUGIN.H. this is all!
4) let’s try to build Bookmark.c from pure command line!
5) type: “CL.EXE /LD Bookmark.c Ollydbg.lib“, where /LD – key to make DLL (as we know plug-ins are DLLs), Bookmark.c – name of plug-in to build, Ollydbg.lib – library (it should be in current directory or any directory listed in “LIB” environment variable (type “SET LIB” to see your list of LIBs dir); PLUGIN.H should be located in the current directory (you can move it to any system include directory, just type “SET INCLUDE” to see the list);
6) ok, all system are go. we’re pressing enter, and… ops!!! PLUGIN.h wants us to specify /J key (to force compiler to use unsigned char, instead of signed char by default);
7) updated command line looks like: “CL.EXE /LD /J Bookmark.c Ollydbg.lib“, we’re pressing enter and…
8) …endless list of errors of 32 unresolved externals symbols. why?!
9) the answer is: OLLYDBG.LIB is incorrect!!! ok, we have DEF file, so no problem to create the new one;
10) “lib.exe /DEF:Ollydbg.def” (lib.exe comes with Microsoft Visual C++);
11) ok, we have a new Ollydbg.lib. lets try to build the source again… what?! the same errors!!!
12) well, DEF file is wrong and has to be fixed. open it with any text editor and replace all “_” by “”, save changes and exit (of course, we’re supposed to remove only “_” prefixes, do not touching “_” symbols in the middle of functions, but we’re lucky and there is no function with “_” in the middle);
13) run “lib.exe /DEF:Ollydbg.def” again;
14) try to build the source once more: “CL.EXE /LD /J Bookmark.c Ollydbg.lib
15) fatal error LNK1120: 8 unresolved externals
16) well, 8 is less than 32, so the progress is good and fixed .lib-file is working, but… something is still broken, but… look at names of the unresolved symbols!!!!
17) __imp__DefMDIChildProcA@16, __imp__MessageBoxA@16, __imp__CreatePopupMenu@0
18) they’re obliviously belong to USER32.lib! so, just add USER32.lib to our command line!!!
19) the final (we hope so) try look like: “cl.exe /J /DL Bookmark.c Ollydbg.lib USER32.lib
20) wow!!! it was built without any single error or warning!!! we’re very happy!!!
21) copy the fresh Bookmark.dll to Olly’ Plug-in directory and check how good (bad) it is!
22) btw, don’t forget about optimization!!! “cl.exe /Ox /J /DL Bookmark.c Ollydbg.lib USER32.lib“, where /Ox means – max. optimization (of course, feel free to use other compiler keys, whatever you want!!!)

you can download fixed version of Ollydbg.lib/Ollydbg.def. I tested it with Microsoft Visual Studio 6.0 and it works fine.

 

# Olly loads Olly to bypass anti-attach tricks /* Clerk’ trick */

the problem of anti-anti-attaching came up in conversation on the legendary wasm.ru site. Clerk (a very clever guy carring a heavy plasma gun, loaded with rounds of brilliant ideas) as always offered a very elegant, yet bizarre solution (ru). I wonder – what kind of Rasta stuff makes him so creative! well, stop to expatiate, back to business.

previous posts demonstrate numerous anti-attach tricks and most of them based on the system thread, creating by OS during attaching. here they are (the tricks): BaseThreadStartThunk => NO_ACCESS, NtRequestWaitReplyPort, DbgBreakPoint

the question is – how to ask OS do not create the system thread? to do it we should know OS internals. IDA-Pro/Soft-Ice shows us that KERNEL32!DebugActiveProcess comes to NTDLL!DbgUiDebugActiveProcess, who calls NTDLL!ZwDebugActiveProcess/ NTDLL!DbgUiIssueRemoteBreakin| NTDLL!DbgUiStopDebugging (just to dissemble NTDLL!DbgUiDebugActiveProcess to see it with your own eyes).

the point is – NTDLL!ZwDebugActiveProcess does all job, attaching a debugger to the process. . as soon as NTDLL!ZwDebugActiveProcess returns status ok, the process has been attached and can be debugger. but! operation system calls NTDLL!DbgUiIssueRemoteBreakin just to notify the debugger by generating breakpoint exception, however, we don’t need it!!!

so, what we’re going to do? I prefer to use old soft-ice with global breakpoints support. just set HW or software breakpoint on NTDLL!DbgUiDebugActiveProcess or NTDLL!ZwDebugActiveProcess and skip the rest of the function. it’s easy, but soft-ice does not work with newest operation system.

Clerk found the way how to do this with Olly. the idea is: load Olly into Olly. yeah! right!

1) load Olly into Olly /* to avoid a mess lets call the first Olly (I) and the loaded copy – Olly (II) */;
2) Olly (I): Set breakpoint on NTDLL!DbgUiDebugActiveProcess: View\Executable Modules\NTDLL.DLL, CTRL-N, “DbgUiDebugActiveProcess”, F2, ENTER;
3) Olly (I): run Olly (II): press F9 several times until right corner “paused” changed by “running” meaning that Olly (II) is still under debugging but it’s running now;
4) ALT-TAB to switch to Olly (II);
5) Olly (II): File\Attach\name_of_the_trickily_process to attach (for example: to_attach_36.exe);
6) Olly (I) pops up, the breakpoint has been triggered;
7) to_attach_36.exe is still running;
8) Olly (I): press F8 several time until NTDLL!ZwDebugActiveProcess is executed;
9) to_attach_36.exe has been stopped, Olly (II) has been attached to it, Olly (II) is stopped as well;
10) Olly (I): move cursor to the next command after NTDLL!DbgUiStopDebugging, right click to context menu and “new origin here” or simple press CTRL+Gray * (“gray” means small numeral keyboard);
11) Olly (I): press F9 to run Olly(II);
12) ALT-TAB to switch to Olly (II);
13) Olly (II) shows naked screen w/o any info, to_attach_36.exe is running;
14) Olly (II): View\Threads. do you see the only one thread? the main thread of the app?! wow!
15) Olly (II): press “pause” to stop to_attach_36.exe;
16) Olly (II) updates CPU window and from that moment we can trace to_attach_36.exe as usual;

well, you got it. a nice trick to bypass anti-attaches. it’s very powerful and universal, but does not work with PEB=>LdrData . um, every technique has its own limitations.

meanwhile, you probably know, if the process is already attached to another process, we can’t attach our debugger to it. many protections use this trick – they create a child process (packed), attaches to it for dynamic unpacking. but there is a loophole. we can attach to the parent process unless the child not attached to the father. yes!!! a debugged process can attach to the debugger!!! it looks like (parent <== attach ==> child)

I’ll write about it latter, showing you how to break this chain. for now, you can play with Clerk’s trick!

Olly loaded into Olly attached to to_attach_36.exe

Olly loaded into Olly attached to to_attach_36.exe

 

# anti-attach: BaseThreadStartThunk => NO_ACCESS

another anti-attach trick. during attaching to the process, operation system creates a thread inside it and as far as we know, every thread has the start address. the address of the system thread is BaseThreadStartThunk. it calls BaseAttachComplete, who calls DbgBreakPoint in order to raise the breakpoint exception to pass control back to debugger. so, if we block BaseThreadStartThunk somehow, DbgBreakPoint will be never called and a debugger will never get control. theoretically…

…practically, operation system notifies a debugger when a new thread is about to be created, thus a debugger does not need in DbgBreakPoint at all!!! just set Option\Debugger option\Events\Break on new thread in Olly or Debug\Debugger options\Stop on thread start/exit in IDA-Pro and enjoy!!!

but, there is something else. first of all – these options are not set by default. second of all – if the system thread issues an exception – we can’t just continue execution! we need to kill the system thread to suppress the exception – not every hacker knows it and not every debugger allows us to do it (IDA-Pro does not).

well, guess, “Break on new thread” is set. this means our debugger stops _before_ executing the first command of BaseThreadStartThunk. how we’re going to generate an exception?! it’s easy! page of BaseThreadStartThunk => NO_ACCESS! of course, operation system will send exception notification to the debugger, allowing us to kill the system thread and continue executing/tracing the main one, but as it was said above not every hacker are ready to handle this situation.

ok, lets play with this trick. be warned: it’s not safe. we can’t set no access only for BaseThreadStartThunk, it affects the whole memory page where might be essential functions, but… for W2K/XP/S2K3 it works well. just… BaseThreadStartThunk is not an exported function. so, how we’re going to find where it’s located in memory? guess, the most universal way is to create a child process, attach to it, get CREATE_THREAD_DEBUG_EVENT notification and memorize u.CreateThread.lpStartAddress.

download the sources and binary of the POC to play with.

Olly fails to attach and the only way to continue debugging is to kill the system thread

Olly fails to attach and the only way to continue debugging is to kill the system thread

 

# zombie slam

back in the old days (UNIX, big iron) zombies were a real headache. what’s a zombie? it’s an orphan child – process without parents. how it might happen? well, guess, a mother process creates a children process and dies leaving the child alone in the dark. does it make a problem? for GUI apps – no problem, but console apps – are very different.

in general console apps share the same console. if we run cmd.exe from Explorer it creates a new console, but when we run format.com from cmd.exe – format.com uses the same console. it’s oblivious. oh, really?! NT is not MS-DOS!!! creating a new process (format.com) does not suspend the parent (cmd.exe). so, cmd.exe is still running. it would make a mess, if cmd.exe did not wait for finishing of format.com.

if you guys developed console shell you probably know that CreateProcess follows by WaitForSingleObject(hHandle,,) where hHandle – is handle of the created process. now, guess, the child process creates a sub-child and dies. WaitForSingleObject() returns control, but the sub-child is running and shares the same console!!!

consider the following code or download sources and binary:

// if it’s child process – output message to the console
if (c > 1) while(1) printf(“\rI’m a zombie [%c]$”, x[++c % sizeof(x) - 1]), Sleep(69);

// creating a child and terminating itself
memset(&pi, 0, sizeof(pi)); memset(&si, 0, sizeof(si)); si.cb = sizeof(si);
if (!CreateProcess(v[0], “Im zombie”, 0, 0, 0, 0, 0, 0, &si, &pi)) return printf(“-ERR:create_proc\n”);

run cmd.exe and type “zombie_bug.exe” (with extension!). wow!!! a very modern command prompt with a rotating fan! you can type cmd’ commands and they will be executed, but the rotating fan is working!!! now, start FAR manager and run zombie_bug.exe. ops! FAR has the same bug and our zombie is working again!!!

what’s it good for? fist of all we can create “resident” programs living in foreign consoles (use console API to output text into desired positions). another idea – zombie can intercept all input and if zombie output nothing to the console – nobody notices it!!! a good stealth spy.

what we’re going to do? does anybody want to send a bug report to Microsoft and FAR manager team?

zombie - alone in the dark

zombie - alone in the dark

 

# Process Explorer – bloody hell of indefinite waiting bugs

long time ago I found a bug in Process Explorer pointing out that it uses wrong algorithm of retrieving Thread Start Address. all threads created with CreateRemoteThread has Thread Start Address pointing to KERNEL32.DLL. it’s true, but help- and sense-less. I sent my bug report to Mark, but got no answer and posted it on my old blog: “bug in Process Explorer (a gift for malware)

it means that Process Explorer is not reliable enough, we can’t trust it anymore and yesterday I found more bugs. they’re very common and almost _every_ application has numerous bugs like this. are you intrigued? well, lets begin!!!

download to_attach_ldr.exe (anti-attach trick, based on damaged PEB=>PPEB_LDR_DATA – read this post for more info), run it and… ask Process Explorer to display properties of “to_attach_ldr.ex” process (yeah! “ex”, not “exe” – another bug?!). now, go to “Threads” tab and…

ops!!! Process Explorer freezes falling into infinitive loop with 100% CPU load. ~60% is to_attach_ldr.exe and ~40% is CSRSS.EXE. ok, close to_attach_ldr.exe and Process Explorer immediately wakes up. this means it just was waiting the even that was not going to happen.

ok, another example. download to_attach_33.exe (anti-attach based on intercepted NtRequestWaitReplyPort, described here ). run it and ask Process Explorer to show properties, go to “Threads” tab and… you know what will happens in the next moment. freezing!!!

freezing Process Explorer

freezing Process Explorer

we just found out how buggy Process Explorer is. but why? what’s the issue? the answer: NT has numerous functions like WaitForSingleObject, WaitForDebugEvent, etc. they all take dwMilliseconds argument specifies time to wait for an event. if the parameter is INFINITE, the function does not return until an event has occurred. the problem is – almost every programmer uses INFINITE and does not handles time out error. admit, you did this too?

Ilfak does for sure and I pointed out it before (“another EnableTracing() bug“).

ok, we got two points. first – never use INFINITE unless you’re 100% sure it works. the second point: if malware creates a malicious thread inside a trusted application – anti-attach tricks help it to survive. many anti-viruses are unable to enumerate threads in this case and some of them just freezes. very effective DoS attack against pro-active protections!!!

note: I tested Process Explorer 11.4 under W2K SP4, not tested other versions yet, but guess the bug is there.

 

# NtRequestWaitReplyPort abuses IDA-Pro

good news first. my simple anti-anti-attaching plug-in is coming soon and it works very well. meanwhile, I’m experimenting with different anti-attaching technologies and wish to share a few new (old?) tricks with you.

well, the method based on NTDLL!DbgBreakPoint (see “try to attach to me: if you can!” ) is not good enough to hurt IDA-Pro. like Ilfak said – just set “Stop on debugging start” checkbox in the debugger options to stop IDA-Pro _before_ NTDLL!DbgBreakPoint. how it’s going to help?! nothing! but we will try. press F7 several times. go to Debug\Open subviews\Open threads. do you see two threads there? one is the main thread of the app, another – the system tread, created by DebugActiveProcess() API. the point is – we don’t need the system thread anymore. we should kill it. why? the debugged application might inject bad code into it. but IDA-Pro does not allow us to kill treats.

OllyDbg does. ok, run Olly, go to Options\Debugging options\Events\Break on new thread [x]. Attach to the to_attach_31.exe. ok, OllyDbg has been stopped. now, View\Threads. do you see two threads there? current thread is the system thread. kill it! (context menu\kill thread). um, the thread does not want to die. don’t worry it’s almost dead. now, click another thread (the main), context menu, actualize it and start tracing the main thread step-by-step or just press F9 to run. the system thread is disappeared. there was injected code displaying “shit happens”, but since the thread has been killed – no shit!!! everything is just fine!!!

this is universal technology. I tested it on large malware/protectors collection and it works well! at least for Olly. for IDA-Pro we need to write a script or plug-in, killing unwanted threads.

ok, forget about NTDLL!DbgBreakPoint. back to IDA-Pro. “Stop on debugging start” is set, IDA-Pro attaches to the process (any process you want) and stops. where it stops? let me see…

NTDLL!77F88B6C ZwRequestWaitReplyPort proc near
NTDLL!77F88B6C mov eax, 0B0h ; NtRequestWaitReplyPort
NTDLL!77F88B71 lea edx, [esp+arg_0]
NTDLL!77F88B75 int 2Eh
NTDLL!77F88B77 retn 0Ch ; << here NTDLL!77F88B77 ZwRequestWaitReplyPort endp

so, IDA-Pro stops at NTDLL!77F88B77, when NtRequestWaitReplyPort NTCALL has been executed, so NtRequestWaitReplyPort (called by CsrClientCallServer) is executed _before_ stop. thus, if we intercept NtRequestWaitReplyPort – it will be easy for us to abuse IDA-Pro or do something unexpected. and IDA-Pro has nothing to do this it.

the problem is: NtRequestWaitReplyPort is very popular function and it’s used not only by debugger. so, we can’t just intercept it. we have to check the caller – the thread ID.

for example:

mov eax, fs:[18h] ; // *TIB
mov eax, [eax+24h] ; // CurrentThreadId
sub eax, [our_tid] ; // ?another Thread
jz to_old ; // => no dbg

; // perform stack overflow
die: push eax
jmp die

; // all ok, passing control to the old func
to_old: jmp ds:[old_NtRequestWaitReplyPort]

I wrote a simple POC, abusing IDA-Pro and OllyDbg. download it, run exe. do you see message – “attach to me”? well, ask Olly to attach. Olly attaches without any problems, but… the string changes to “debugger is detected” and the process is still running. wow!!! of course, we can stop the process and continue tracing, but… the point is – the debugger has been detected. how? I just injected my code into NtRequestWaitReplyPort to set global flag if we’re under debugger. the main thread checks this flag and changes its behavior if we’re under debugger. of course, in this simple case we can fix it after attaching, but imagine what happens if the injected code will wipe out all code of the app or destroy the critical structures or just free a few memory blocks cause random crashes?

OllyDbg stops too late. our code injected into NtRequestWaitReplyPort executes before, and debugger has no control under it. what’s about IDA-Pro? try to attach to to_attach_33.exe (all check box in debug options are set). what do we see? the protection tell us “debugger is detected”, the process is running, but IDA-Pro… freezes. what she is waiting for? and how to save our database? we don’t want to kill IDA-Pro, don’t we? right! kill to_attach_33.exe with Process Explorer. IDA-Pro will return from dead to alive.

IDA-Pro 5.3 fails to attach

IDA-Pro 5.3 fails to attach

well, who will break this simple crack me? who will find the way how to attach to the process do not disturbing the protection?

 

# PRNG based on REP STOS

unlike many others, REP STOS/MOVS instruction is very hard to emulate (see “self-overwritten REP STOS/MOVS, IDA-Pro 5.4 and Ko” post). at first sight it’s easy! live CPU continues executing overwritten command, right? so, take OllyDbg or IDA-Pro and write a plug-in to redesign the trace engine. if the tracer meets self-overwritten REP STOS/MOVS it memorizes it and continues executing like the real CPU does. it’s easy! what’s the problem?!

but, it’s more than meets the eye. CPU stops executing over-written REP STOS/MOVS in arbitrary moments. well, almost arbitrary. hardware interrupts force CPU to clean pipeline, stopping executing the overwritten REP STOS/MOVS command. internal CPU events also stop REP executing. different CPUs have different behavior (and different bugs :=).

this gives us… a very interesting pseudo-random number generator. if initial ECX is quite big, REP loop finishes with almost unpredictable ECX and the most interesting part is – our PRNG does not look like normal PRNG!!!

to prove it, I wrote a simple POC (plz, do not use it in commercial software, coz, due to CPU bugs sometimes it crashes with access violation or another exception, but in general it works, I’m working on the stable version now). download it and run.

the program allocates memory on the heap, copies self-overwritten REP STOSB code there, initializes ECX by 16Mb value, passes control to it and displays ECX. the point is – ECX is different every run.

my favorite Pentium-III 733 MHz Coppermine (my base PC) copies at least 64 Kb in average, see:

16685683 (91533 copied)
16575731 (201485 copied)
16755560 (21656 copied)
16770446 (6770 copied)
16670677 (106539 copied)
16759763 (17453 copied)

Pentium-4 3.2 GHz HT (my home file-server) shows pretty different result:

16044939 (00732277 bytes copied)
16777211 (00000005 bytes copied)
16777210 (00000006 bytes copied)
16777206 (00000010 bytes copied)
16777209 (00000007 bytes copied)
15788810 (00988406 bytes copied)

damn! sometimes CPU copies only 5 bytes!!! well, not “sometimes” – very often!!! it makes this trick not just PRNG, but… kind of fingerprints of CPU.