I think most malware authors worth their salt who consider their creations dearly would throw in a bunch of anti-debugging tricks or even anti-analysis tricks so that easy automated analysis cannot be done.

Once discovered,Eventually an an analyst would patch the binary using OllyDBG or something similar but it still wastes their time which seems to be the point. Most of the authors don’t use any protection , but hey why write arcane assembly instructions when you could get a shiny FUD at your friendly neighborhood underground forum for $25 :p

1.The Usual Suspects

I call these as the usual classic ones which are rarely seen in new strains

IsDebuggerPresent() - Searches in the PEB (Process Environment Block) structure if IsDebugged field has a non-zero value [Which implies a debugger is running].

Can be evaded with PhantOm,Hidedebug etc

CheckRemoteDebuggerPresent()- Similar to above, does a simple check for itself or any other process, needs a process handle as input parameter and No it does not check for any remote debugger (misleading name)

FindWindow() - It’s a winapi call to check if a window with a certain name is present (“OllyDbg”) etc

NtQueryInformationProcess- Retrieves Info about a specific process using it’s process handle and passing ProcessDebugPort [ProcessInformationClass] [^n]. If it returns a non-zero value which would be the port number, then the malware knows it is being debugged.

OutputDebugString()- Basically sets a an error to occur if no debugger is running, but if a debugger is running it wont cause an error. Pseudocode be like ->

DWORD errvalue=0x147244f SetLastError(errvalue) OutputDebugString("Testing Ollydbg") if(GetLastError() != errvalue) { RunEvil(); } else exit

Handwritten assembly can also check the BeingDebuggedFlag by accessing the PEB block which is in fs:[30h] location and checking the second byte. It would get a pointer to PEB, then access the second byte in PEB structure which is BeingDebugged value and do a comparison

CloseHandle and NtClose - a very cool technique based on the fact that call of ZwClose with invalid handle generates STATUS_INVALID_HANDLE exception when the process is debugged.

2. Timing tricks

rdstc,Queryperformance and gettickcount

These are used to check the amount of time it takes for a couple of instructions to execute. Suppose a process is being debugged then definitely it would be slower and such differences can make a malware trigger off alarms and change it’s execution / flow.

More tricks such as ones used by cool kids in the block such as ponmocup and others will be discussed in the next post.

Still deciding whether to write a post/ make it into a cute little poster :|