intraarterial injection: fixing old bugs in Vista ms-guys inevitably add new ones. don’t ask me for proofs unless you want to hurt your face-painting wretched system ("http://fc00.deviantart.com/fs43/f/2009/103/5/0/Anime_Goth_Girl_by_SakuChan94.jpg"). do you know the system I’m talking about? good! the following code has no impact on NT, W2K, XP, but… it freezes malformed Vista. it just hangs the system up! (I tested Vista SP0). download ("http://nezumi-lab.org/ffh/CloseHandler.zip") the binary or compile the file by yourself.

while(CreateFile(”KPNC”, GENERIC_READ, FILE_SHARE_READ, NULL,OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL) != INVALID_HANDLE_VALUE);

get off the subject: remember a simple anti-dbg trick with closing a non-existing handler? something like CloseHandle(0xBADC0DE) or CloseHandle(0xBADC0DE). if we’re under a debugger - OS generates C0000008h (INVALID HANDLE) exception. no debugger means no exception. the problem is: how to close an assuredly invalid handler? if you didn’t open it, any system DLL might opened it. of course, you can use GetHandleInformation() to check: if the handler has been opened, but… it’s too obvious (for hackers) and too trivial to be interested for us. there is another way — our way.

flowing well: has it never come in upon your mind how OS assigns handlers? a handler is DWORD, right? but it’s impossible to get all values busy. some values will be taken, but some of them should be free, because it’s impossible to open all of 4,294,967,296 possible handlers. it’s out of the limit! so, lets perform a fast research of system internals. what we’re going to do is: to consume all handlers until CreateFile() says: “no more handlers, I give up“. well, time to call GetHandleInformation() and check: is there any predictable template? which handlers are taken and which are not?

dead marines: holly cow!!! just look at it!!! wow! this is the very template we looked for! handlers 0h .. 02h are taken, handler 07h is taken as well, but… the rest of them fits the following equation: (((x - 0×12) % 04). so, it’s easy to determine handlers that will be not taken whatever happens to them, thus these handlers will definitely raise an exception on the close attempt. the point is: closing a handler like 1Bh looks reasonable from hacker’ point of view, but it’s just a way to generate an exception under debugger.

HANDLE: 00h is invalid
HANDLE: 01h is invalid
HANDLE: 02h is invalid
HANDLE: 03h is valid
HANDLE: 04h is valid
HANDLE: 05h is valid
HANDLE: 06h is valid
HANDLE: 07h is invalid
HANDLE: 08h is valid
HANDLE: 09h is valid
HANDLE: 0Ah is valid
HANDLE: 0Bh is valid
HANDLE: 0Ch is valid
HANDLE: 0Dh is valid
HANDLE: 0Eh is valid
HANDLE: 0Fh is valid
HANDLE: 10h is valid
HANDLE: 11h is valid
HANDLE: 12h is valid
HANDLE: 13h is invalid
HANDLE: 14h is valid
HANDLE: 15h is valid
HANDLE: 16h is valid
HANDLE: 17h is invalid
HANDLE: 18h is valid
HANDLE: 19h is valid
HANDLE: 1Ah is valid
HANDLE: 1Bh is invalid
HANDLE: 1Ch is valid
HANDLE: 1Dh is valid
HANDLE: 1Eh is valid

Achilles’ spear: so, you got it! we have the magic formula allowing us to check any arbitrary value. take 0xBADC0DEh for example. download ("http://nezumi-lab.org/ffh/CloseHandler.zip") the sources of IsInvalid.c and call IsHandlerInvalid(0xBADC0DE) or simile run IsInvalid.exe. as you can see, 0xBADC0DE could not be taken, so it’s a good choice to cause an exception.

ok, another try — 0xDEADBEEF. just pass the value to our magic function and… ops! it says: “HANDLE: DEADBEEFh is possibly valid“, so it’s potentially unsafe to use CloseHanlde(0xDEADBEEF). oh, come on! fat chance to close a file, opened by system or custom DLL, but… it’s still possible. btw, VMProtect ("http://www.vmprotect.ru/") uses CloseHanle(0xBADC0DE), which is safe. coincidence? or… anyway, Dermatolog (???? ????????, ???????????? –the geek who created it) is a very wise guy and his protector is one of the best. it’s stuffed by anti-dbg tricks and it was a pleasure for me to dig them up. what’s about you?

http://nezumi-lab.org/gif/XPSP3_doesnotwanttodie.pnghandler consuming leads to consume kernel memory as well (handler_explorer.exe is running), sorry for the Russian screen-shoot, will appreciate your help, if somebody send me eng one (info # re - lab . org )




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