logo
banner
Download the FREE 5-IP version of the GFI LANguard network vulnerability scanner!
line
HOME
TOOLBOX
ON MY MIND RIGHT NOW
MISC
ABOUT
line
forest

Evading the Norman SandBox Analyzer

Background

The Norman SandBox Analyzer runs malicious code samples in an emulated environment while logging their actions. In practice it is more or less impossible to make an emulated environment perfectly similar to the real thing. It is therefore possible to write malicious code that does not behave maliciously when run in the Sandbox Analyzer. Here I will give one example of such a technique. My intention is not to show that the Norman Sandbox is worse than other sandboxes, or give new ideas to malware writers - but rather to point out, and exemplify, an inherent weakness in sandboxes in general.

A sample evasion technique

The following code creates the file c:\donothing.txt according to the Sandbox Analyzer, while it creates the file c:\breakstuff.txt on a real computer running a real copy of Windows.

unsigned char idt[6];

__asm
{
    sidt idt
}
if ((0x00 == idt[0]) && (0x08 == idt[1]))
{
    fp = fopen("c:\\donothing.txt", "w");
    fclose(fp);
}
else
{
    fp = fopen("c:\\breakstuff.txt", "w");
    fclose(fp);
}

The problem in this particular case is the limit of the IDT. According to the Intel documentation: "Because IDT entries are always eight bytes long, the limit should always be one less than an integral multiple of eight (that is, 8N-1).". However, the Sandbox Analyzer incorrectly uses a limit of 800h, which is not an integral multiple of eight minus one. Therefore it is trivial to create a piece of malware that does one thing in the Sandbox Analyzer and another thing completely in a real computer (or even in a virtual machine like VMware for that matter).


/Arne



© Arne Vidstrom. All rights reserved.