Hello.
Here is a nice crackme by WarrantyVoider. From the readme file:

-----------------------------------------------------
compatibility
=============
Iīm really sorry but this crackme will not run on all computers.
=> This crackme only runs on W2K/XP. Please donīt use another OS and then complain. I tested on W2K and XP SP2.
=> You need mfc71.dll (www.dll-files.com)
*******************************************************************************
=> I think the crackme is safe but please better run it inside VmWare etc.
It might crash your system, not properly delete the files it creates, or worse.
*******************************************************************************
=> It looks shitty on W2K. I did the dialog with MFC in Visual Studio and couldnīt figure out how to use Pixels instead of DialogBase Units. Maybe you want to drop me a hint or URL? Iīm completely new at this.

your task
=========
Write a keygen, write a good tutorial. Self-keygenning is forbidden on this one, because you could do a brute-force selfkeygen without understanding anything and miss all the fun.

the crackme
===========
To start the crackme, run crackme.cmd. Depending on the speed of your CPU and harddisk it will take up to half a minute before the dialog comes up. In the dialog you can enter the name "warrantyVoider" and the serial "5B55873D" (dont press enter, this would close the dialog) to get the good-boy-message. If anything else happens the crackme is not compatible with your system. In the case Iīm really sorry, donīt waste your time, download some other cool crackme. But letīs hjope that doesnīt happen...

There are two EXE files. The first one runs silently before the second one starts. The first one is obfuscated because you donīt need to analyse it to solve the crackme.
-----------------------------------------------------

From the readme it's obvious there's something strange inside...
I'm interested in which kind of tools will you use to solve this crackme.

I wanted to submit my solution at crackmes.de but I won't do for the moment because I think this crackme represents a nice challenge. If you'll solve the crackme you can read my simple tutorial (8mb because it's a video tutorial...) downloading it from: http://woodmann.com/zairon/Zai_TableCrackMe.zip ("http://woodmann.com/zairon/Zai_TableCrackMe.zip")
Edit: the zip was password protected, not anymore...

Good luck!
Z.

ps. The video is really big because I suck in video editing and stuff like that. It's an avi file recorded using Camstudio; if you know a good way to reduce the size leaving the quality high send me a private message. Thx.

The table creation .exe crashes on my XP SP2 system. Bad luck

my xp\sp2 works

this crackme sounds interesting, thanks for the tip ZaiRoN!
I've never seen a video solution to a crackme, but now I can't watch it , I have to try this ....

cheers, 0xf001

I've taken a preliminary glance of the disassembly, it doesn't look that difficult (most of the 416Kb is the dialog bitmap, not code). Interesting concept though.

tblcrt.exe crashed on my WinXP SP2. So the TableCrackme.exe could not open the table file: %temp%\l00KuPtAbl3.%pid%.

Really strange, I have no problem running the crackme on XP (both sp1 and sp2).

LLXX: no, it's not hard but at a certain point if you don't know what to do you are lost

No problem to run either crackme's exe or ZaiRoN's

I have a dual core system, maybe that's the problem...

The crackme also doesnt run on my XP sp2... i dont know why...

Apart the problems related with the OS versions, is there someone who is trying to solve the crackme? Ok, I'll break the ice.

The crackme reads the name and use it inside inside a little routine which starts at 401270 and ends at 4012BA. It doesn't matter what it does at the moment, it's important to know that the routine uses the name to obtain a value (a dword), call it ValueFromName. The value is used in the next part of the routine, the one which starts at 4012C0:

Believe it or not the protection routine seems to be all here. The strange thing is related with the file it wants to open. I can assure you the file doesn't exist but the program wants to open it and if you step the crackme you'll see that it opens the file because it gets a file handle. Besides, look at the final compare at 401310; the crackme compares the file handle with ValueFromName.
Some questions arise...
1. Is it possible to make ValueFromName equal to a generic file handle?
2. Where is the file?
3. How can it open the file?

hmm i dont know .. i tryied this... "warantyVoider" and the serial "5B55873D" but i didnt get good-boy msg but ... so i thought crackme doesnt work...


bye

Damn, I forgot to advise you all; shame on me!!! There's an error inside the readme file. The right combination is:
name: "warrantyVoider" (without ""
serial: 5B55873D

I also changed the combination in my first post.

I used without the " " .. i attached the pic also...


bye

Don't know if you are trying or not but the project seems to be dead. I removed the password from the solution, if you were waiting for it you can now read...

Personally I cheated.
I found a keygen and used it to generate the password asked when we extract your not-anymore-protected archive. Anyway like said in PM it seems still to hard to me, but my hard drive is keeping it..
I also tried to reduce your movie size, but it seems it's already encoded so d*vx6 can't encode it, strange.

Take care with stepping neg esp with ring0 debugger

Hi deroko,

What do you mean by that exactly? I haven't done the crackme so maybe I'm missing something. Single stepping a negative esp?

Kayaker

Yes K., he was talking about stepping one of these instructions:

Indeed, stepping through those lines gives me a nice blue screen At least my VM reboots fairly quickly!

Has anyone tried dumping the .sys file? I wanted to look at it outside of a debugger but iceext's !dump doesn't seem to work. Complains about error exception encountered while dumping memory. I googled the error message but came up empty handed. Not sure if the crackme's "trick" is conflicting with iceext's hooks. But other modules dump fine, so that's probably not the case

xenakis

No stack switchin' in ring0

But anyway I did same trick as I did for previous warrantyvoider's crackme, install hook to detect neg esp, if so skip, and if instruction after it is also neg esp, skip it too

It can be debugged with this little modification of int1.

Iceext hooks the function hooked by the crackme but there isn't conflict between the crackme and iceext. I haven'tinvestigate too much in your dump problem but you can find a nice discussion about the problem in an old thread: http://www.woodmann.com/forum/showthread.php?t=5736 ("http://www.woodmann.com/forum/showthread.php?t=5736&highlight=iceext+dump+error")

Well, could be interesting to see why it doesn't work on all machines. Why don't we study what happens inside tblcrt.exe? The file is packed in some way; unpackers... where are you?

Maybe he was using some of the OSes that do not work with the crackme ?

did someone say unpacking

there is some obsfucated procedure, like morphed code, no APIs are called from it so it is same in dump:


ps. tested on win xp sp2, oep is at 401f92, code at entrypoint is apiloader

Well done Deroko!

The target gives us the opportunity to learn something about driver reversing, especially nowdays when everyone is using Ollydbg . Don't know if someone is still interested in this project but I think there's something more to do with it. I have some questions for you all (no cheaters this time ):

1. Did you find something usefull in the unpacked file?
2. Are you able to dump the sys file? Is there an easiest way?
3. How do you study the sys file? I mean, do you prefer to step it using a debugger or to approach the driver via deadlist? Which debugger are you using?
4. We all know the program hooks a specific function, can you tell us how does it hook the function?
5. The hook doesn't work on all machines, do you know why?

Good luck!

I just caught this comment, thought maybe the problem is one that Iceext always has an issue with when using !dump, in ring3 or ring0.

If a section of code is not paged in yet (i.e. you see all "?" in the data window), !dump will fail. This might or might not have been the problem. You can usually use the Softice PAGEIN command to fix the issue and dump a complete image.

Kayaker

2 -copy it before DeleteFileA kicks in
I don't know about 5, it seems like normal SSDT hook code, grab sn from ZwCreateFile, find entry in SSDT, store there hook.

ZaiRoN, thanks for the link to the previous thread. Very informative. I was able to dump the first 1000h of the sys file using !dump, anything more would not dump. As Kayaker suggested, data window showed ?'s after the first 1000h. PAGEIN command didn't work because of the IRQL issue explained in the linked thread ("IRQL must be below DISPATCH_LEVEL to page in memory".

EDIT: Well, I feel really stupid!! It's not the tools, it's human error. I was getting my image size from Rootkit Hook Analyzer, size of 4096. Should have seen it earlier. Rootkit Hook Analyzer uses decimal for size, not hex! No wonder "only" the first 1000h would dump

...which *can* result in all kinds of funny BSODs especially on HT or MP machines.

hm, interesting, can you explain it? I'm not aware of any bsods regarding ssdt hooking. (well only if hook is badly written)

tnx

In a HT (and MP even more ) environment, changing a SSDT entry is always a source of potential crashes. Mike Russinovich described this in his rant about the Sony rootkit, let me look it up...


It’s never safe to unload a driver that patches the system call table since some thread might be just about to execute the first instruction of a hooked function when the driver unloads; if that happens the thread will jump into invalid memory. There’s no way for a driver to protect against this occurrence, but the Aries driver supports unloading and tries to keep track of whether any threads are executing its code. The programmer failed to consider the race condition I’ve described. They’ll have to come up with a new approach to their rootkit sooner or later anyway, since system call hooking does not work at all on x64 64-bit versions of Windows.

P.S. The selection of post icons lacks a smiley that is melting away. I want a walkable fridge.

well that problem is solved by driver being loaded untill restart, or untill you unload in manually.



I was reffering to this

At present I'm pretty busy with my pile of work, but if anybody has a machine where it constantly fails, it should be fairly easy to step through it and check what's going on. I don't have the driver at hand nor the time to look into it, but did you check the return values on all calls related to the hooking? Maybe it's just DEP of XP SP2 jumping in? Sorry but I can't give anything more than these few suggestions at the moment. The weather is really killing me

it is completely correct hooking. That's why I'm wonderin why it fails on other systems.

Just a shot in the dark re the SSDT hook issue. I don't know if the 'crashes' that occur are due to the driver hook itself, but a crash dump analysis should pick that up.

You're right that the SSDT hook seems proper in that it doesn't unhook and the driver stays in memory. However what's different with this situation is that there is no *physical* file backing the driver image in memory, I only had a quick look but it seems the temp sys file is deleted.

Now in theory all driver code is in non-pageable memory (except for INIT), but if it was possible that in XP there could be swapping out of driver PTE's when necessary, there would be no physical paging file to back it up. Especially with the case of split TLB's (code and data), it may be possible that one of the TLB PTE's could be flushed with no way to recover it.

No idea if this is the case, I'm just trying to think of a scenario where a problem might occur because the driver file is physically deleted, leaving only the memory image of it.

Kayaker