Lame anti-debugging

This surely is the worst anti-debugging attempt that I've seen in my whole life.
But yeah, it works.

This sample I ran across is a parasite that uses TEA to encrypt infected files before "swallowing" them. At least, resources are extracted so the infected program will keep the same icon, etc...

Anyway.

When run, the sample creates a new thread and exits. This thread logically opens the file itself to, amongst other things, extract and decrypt the original file.
Obviously, the virus author doesn't really like people chopping up its creation in a debugger so at the very beginning of the thread, you can see the following code:

Did you see the trick?

Looks like a very standard call to CreateFile but if you step into this code in your debugger, you'll be disappointed when CreateFile will actually return INVALID_HANDLE_VALUE.
The thread will then terminate and no infection will occur.

Well, no magic here. Your debugger owns a handle to the debugged program and the virus calls CreateFile with a null dwShareMode argument.
So, basically, if this file has been opened already by another program (no matter it's a debugger or not), the virus just terminates.

So, yeah, you can patch dwShareMode within your debugger or patch the file itself in your favourite hex editor.

I'm still wondering. When it comes to malwares, the bad guys are always very weird.
They think about some crypto, hiding processes and files, etc... but the only trick they found to prevent debugging was a parameter of CreateFile().

Mmmm, no, I don't get it... But at least it gave me a good laugh :)