Protecting over 200 million PCs, Macs, & Mobiles – more than any other antivirus

June 1st, 2011

Wrong specifications [reloaded]

I can confirm that we at the Virus Lab “love” product specifications and documentation. My recent experience shows a discrepancy between MSDN and the real behavior of VirtualAlloc.

I’m currently revising and tweaking the memory management inside one of the emulators used in the avast! antivirus engine. The goal of my effort is to bring this emulated environment closer to the real world environment, thus I decided to make the memory management conform precisely with MSDN. But after doing that…. suddenly….. about a sixth of my test set (around 400 malware families in total) refused to emulate deep enough (as usual). And the problem was in VirtualAlloc emulation:

MSDN documentation of VirtualAlloc

Let me use a well known worm – Allaple – as an example and let me be a bit sarcastic :-) . The picture above states that a region of memory must be reserved before it can be committed. But Allaple uses a direct commitment of memory that has never ever been reserved. Hmmm, would Allaple be a successful ITW worm if this method didn’t work so far? I don’t think so. And we can give it a try.

let's show it step....... step

Here we go. The function call that is supposed to fail actually does not. It returns the valid pointer to allocated memory. The testing system is Win XP, but I gave it a shot also under Win7 x64 SP1 and guess what – it works as well:

just call this "proof of concept" :-)

Thanks again for such a precise documentation. But now what are we to rely on? This is such a “sad” experience :D .

  1. pk
    June 1st, 2011 at 14:38 | #1

    The problem is with the first BaseAddress parameter. If it’s NULL, then you can omit MEM_RESERVE flag. OS finds a valid block for you and commit. If you execute a process, then several VA blocks are already marked as reserved, e.g.:

    BaseAddress: 000c0000
    RegionSize: 00001000
    State: 00002000 MEM_RESERVE
    Type: 00020000 MEM_PRIVATE

    BaseAddress: 00265000
    RegionSize: 000fb000
    State: 00002000 MEM_RESERVE
    Type: 00020000 MEM_PRIVATE

    but I take your point, MSDN doesn’t always tell you anything…

  2. June 1st, 2011 at 15:59 | #2

    Well, I noticed that the undefined base makes the behavior somehow “special”, but since there is such trick, then it definitely must be mentioned in official API documentation. I can verify some things manually/experimentally here and there, but when it comes to memory management (which is a key part of OS), then I simply expect strict rules (what a naive expectation :D ). If there are some blocks initially reserved, could all of them be committed this way? And are they always the same size (between sessions, between different OS versions)? Will the commitment succeed for small regions and fail for huge ones? Not a single word about that in MSDN doc. There are too many degrees of freedom and that’s what each emulator coder really “likes”.

  3. robert smith
    June 4th, 2011 at 17:10 | #3

    Dear Sir A couple of months ago I purchased your anti virus but it was disabled by a virus I have since had to remove it from my computer in order to download an alternative product where do I go from here?

  4. June 6th, 2011 at 11:25 | #4

    @robert smith
    Please visit our forums and ask for help there. This is not a good place to solve such issues.

Comments are closed.