7

This is just a preferred address. Windows can load the binary at almost any address and rebase it to this new location. ImageBase: The preferred address of the first byte of image when loaded into memory; must be a multiple of 64 K. The default for DLLs is 0x10000000. The default for Windows CE EXEs is 0x00010000. The default for Windows NT, Windows 2000, ...


7

This doesn't happen during the system call. It happens in user-mode. WOW64 processes have two user-mode stacks - a 32-bit stack, which is the one you normally use, and a 64-bit stack. The WOW64 ntdll does not make system calls. Where the native 32-bit ntdll would sysenter (via an indirect call to SharedUserData!SystemCallStub) the WOW64 ntdll has an ...


3

VirtualQueryEx() fills a MEMORY_BASIC_INFORMATION record with information about a contiguous range of pages containing the queried address. This can be used to walk the address space of a process, by starting with 0 and then using mbi.BaseAddress + mbi.RegionSize as the next address to query and so on. GetMappedFileName() can give you the name of mapped ...


1

I believe what makes the difference is ASLR - Adress Space Layout Randomization - Read about it here - so basically it's just a layer of security protection. It's indeed possible to load two different processes to the same virtual address base - the virtual address abstraction makes it possible. The loading base address of a process will most likely be kept ...


1

OllyDbg shows memory regions of all types, whereas your code doesn't show MEM_IMAGE regions. Replace if ((info.State == MEM_COMMIT) && ((info.Type & MEM_MAPPED) || (info.Type & MEM_PRIVATE))) with just if (info.State == MEM_COMMIT).


1

vmlinuz.lz contains the kernel image. $ binwalk vmlinux.lz DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 12 0xC LZMA compressed data, properties: 0x6D, dictionary size: 4194304 bytes, uncompressed size: 5227488 bytes It is compressed, as Igor Skochinsky ...


1

The protections are supported only on page granularity by the CPU and you cannot change that. What you can do is in your exception handler check which address generated the fault, and if it's not the variable you want to "protect", restore permissions to the original value, single-step to allow the write be performed, then disable writes again. This is ...


1

I don't see why not. For instance, if I'm mapping a binary file into memory, I may configure its structure as such: //Visual Studio code #pragma pack(push,1) struct STRUCT1{ char dummy[0x1000 - 4]; double fDouble; }; #pragma pack(pop) struct STRUCT2{ STRUCT1 __declspec(align(0x1000)) s1; }; int main() { STRUCT2 s2 = {0}; s2.s1....


1

While it can happen as a result of hand-coded code, it is unlikely in practice to occur as a result of compiled code. Compilers generally align data appropriately such that a 4-bytes value will begin on a 4-bytes-aligned address, 8-bytes at 8-bytes, etc, to avoid alignment exceptions.


Only top voted, non community-wiki answers of a minimum length are eligible