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;
if ((0x00 == idt) && (0x08 == idt))
fp = fopen("c:\\donothing.txt", "w");
fp = fopen("c:\\breakstuff.txt", "w");
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).