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:
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.
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:
Thanks again for such a precise documentation. But now what are we to rely on? This is such a “sad” experience
.

English
Français
Deutsch
Italiano
日本語
Русский
Español
Čeština
polski
Português
Türkçe
Ukrainian 




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…
@pk
). 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”.
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
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?
@robert smith
Please visit our forums and ask for help there. This is not a good place to solve such issues.