/DYNAMICBASE modifies the header of an executable to indicate whether the application should be randomly rebased at load time by the OS. The random rebase is well known as ASLR (Address space layout randomization).

This option also implies “/FIXED:NO”, which will generate a relocation section in the executable. See /FIXED for more information.

In VS2008, this option is on by default if a component requires Windows Vista (/SUBSYSTEM 6.0 and greater)

This option is on by default if a component requires Windows Vista (/SUBSYSTEM 6.0 and greater).

/NXCOMPAT:NO can be used to explicitly specify an executable as not compatible with DEP.

However, the administrator can still enable the DEP even if the executable is not specified as compatible with DEP. So you should always test your application with DEP on.

Windows Vista SP1, Windows XP SP3 and Windows Server 2008 add a new API SetProcessDEPPolicy to allow the developer to set DEP on their process at runtime rather than using linker options. See the following link for more details:

If your application must run code from a memory page, it must allocate and set the proper virtual memory protection attributes.

The allocated memory must be marked PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, or PAGE_EXECUTE_WRITECOPY when allocating memory. Heap allocations made by calling the new,malloc andHeapAlloc functions are non-executable. An application can use the VirtualAlloc function to allocate executable memory with the appropriate memory protection options.

Another option is to pass HEAP_CREATE_ENABLE_EXECUTE when create the heap via HeapCreate. Then the memory allocated by the subsequent HeapAlloc will be executable.

b.Executable code in data section

They should be migrated to a code section

Security vulnerabilities are more exploitable than they would be if DEP were enabled. So you should always make your application DEP compatible and turn DEP on.

The following sampledemonstrates the code which is not compatible with DEP.

It also shows two DEP compatible ways to run the code on heap.

Running code in data section or on stack almost always implies security holes. You have to put the code in code section or heap instead.

Yes. Image rebase is normally used to prevent potential image base conflict. When ASLR is enabled, OS will rebase the executable unconditionally instead of doing it only when an image base conflict exists

Am I correct that DYNAMICBASE trades startup performance and ease of debugging for a small defense against hackers?

It eliminates all of the startup time speedup gains that one would get from setting a base address on all your DLLs at compile time.

It also eliminates any possibility of determining where an exception happened from the exception address alone, you’ll need a full .mdmp file to have any idea, obsoleting .map files. It also means that you can’t tell if two exceptions from two different runs of the program are at the same location.

With ASLR, the only difference is OS will rebase the executable unconditionally instead of doing it only when an image base conflict exists. So the problems you describe are not caused by ASLR.

When debugging, you can use RVA (Relative Virtual Address) instead of VA (Virtual Address). RVA (VA – ImageBase) will not change even if the image is rebased. The image base of the module is available in the mini dump.

In addition, ASLR’s relocation strategy has the secondary benefit that address spaces are more tightly packed than on previous versions of Windows, creating larger regions of free memory for contiguous memory allocations, reducing the number of page tables the Memory Manager allocates to keep track of address-space layout, and minimizing Translation Lookaside Buffer (TLB) misses.