Norman releases new advanced tools for analyzing and preventing malware

Norman releases new advanced tools for analyzing and preventing malware for technical users

http://www.norman.com/News/Press_releases/39739/en

http://www.norman.com/Product/Sandbox-products/en

 

They claim that it is immune to anti-debugging tricks ( http://www.norman.com/microsites/malwareanalyzer/Technology/faq/37624/en-us ). This is probably true for most of it: you cannot the breakpoints when you are running inside the matrix.

I just wonder if it can handle correctly the cpuid/rdtsc trick [1]. In other words, does the emulated-CPU maintain a count of fake cpu cycles ? Does the expected gain worth the overhead ? If not, this is a "red pill" that does not require any system call.

On the other hand, the easiest way to detect emulation is probably to interact with the environment (file system, etc.), since an emulated one has to be much more simple than a real one. IMHO, the ideal solution for a "sandbox analyzer" would be to have files, folders, processes, etc. read from the real system and copied from the real environment to the emulated one "on the fly" if needed (i.e. when altered or executed). Unfortunately, the same strategy cannot be applied to network connections.

[1] It consists in counting the number of CPU cycles between two instructions. This number may depend on the CPU type, but the author of the program knows the acceptable range. If the value returned is out of this range, it can be assumed that the program is being debugged or single-stepped, since some cpu cycles needed for debugging are also included in the total.

 

I already saw code in malware that specificially detects the Norman Sandbox, so it is the usual cat & mice game as before.

BTW, the Analyser is a nice tool!

 

Aren't FP operations still an issue of all emulators?

 

There are examples here:
http://sandbox.norman.com/live_5.html?logfile=1088425&menulang=
http://sandbox.norman.com/live_5.html?logfile=1049190&menulang=

Yeah, I've already seen a PoC that displayed a "sandbox detected" in a message box when run inside the sandbox, but it was based on the knowledge of the fake system (filenames, etc). Detecting a fake windows installation is easy, and this kind of trick is hard avoid if the sandbox is running inside the AV engine, with limited resources in terms of RAM and CPU, but it could be avoided - at least in some cases - in a product like analyzer pro.

I was wondering who were the clients for such tools. Is there a sufficient market ? Are you guys from other companies using tolls like the analyzer pro (I mean, would you buy it from another AV company) ?


Back to the RDTSC trick, I tried to see if it was supported in Bochs. It looks like it is supported (see get_TSC() function in proc_ctrl.h/.cpp) but I could not understand how the total number of ticks were computed (pc_system.h/.cpp). But this comment, in cpu.h, gives some hints:

// TSC: Time Stamp Counter
// Instead of storing a counter and incrementing it every instruction, we
// remember the time in ticks that it was reset to zero. With a little
// algebra, we can also support setting it to something other than zero.
// Don't read this directly; use get_TSC and set_TSC to access the TSC.


@Rejzor:

I'm pretty sure they claim to support floating point and MMX. Don't know about sse, sse2.