Accusoft's Blog

This is the final article in my two part series on my motivation and process for making MEM_TOP_DOWN a per-process flag. Previously, in Part 1, I explained user-mode solutions that I thought fell short. In Part 2, I will cover reverse engineering the OS mechanism behind MEM_TOP_DOWN and how to use it.

Knowing that NtAllocateVirtualMemory is responsible for allocating memory it is reasonable to assume that the code path that handles the MEM_TOP_DOWN flag passed in as a parameter is the same code path that handles the MEM_TOP_DOWN set in the AllocationPreferences in the registry.  

For this exercise I’ll be using examples from the 32-bit kernel as the analysis is easier to follow, for our purposes the 64-bit kernel behaves the same way.

Read more to learn how to use MEM_TOP_Down.

In this two part series I’ll discuss my motivations and process for making MEM_TOP_DOWN a per-process flag.  In Part 1 I’ll explain user-mode solutions that I think fall short and in Part 2 I’ll cover reverse engineering the OS mechanism behind MEM_TOP_DOWN and how to make use of it.

When porting 32-bit code to 64-bit it is common to have pointer truncation bugs.  Pointer truncation arises from the difference in sizes between pointer types, ‘void*’, and the integral types, ‘int’, ‘long’.  On 32-bit architectures all of these types are the same size, on 64-bit Windows ‘void*’ is twice as large as ‘int’ and ‘long’.

These bugs remain undetected because most applications do not use a lot of memory and the virtual addresses allocated are below the 4GB mark that fits into a 32-bit value.  A project compiled with strict warnings can usually find these issues, and if not the compiler then static analysis tools are good at finding them as well.  However, even those tools won’t help you if you’ve written your own ASM optimizations and mistakenly used EAX instead of RAX.

Read more to learn how and why you make MEM_TOP_Down a per-process flag.