aslr

In Linux, I've tried (just for fun) to modify the kernel source in process.c create a stack address that has more entropy, i.e. in particular the line: sp -= get_random_int() % 8192; When I change this too much, the kernel halts or I get some seemingly undefined behavior. I'm guessing that this causes PAGE_ALIGN() to fail in some way? I'm not that interested in why PAGE_ALIGN() in particular fails, or exactly what piece of code in the kernel that fails (although that too would be nice to know); I'm more interested in why the stack must reside in a particular region at all. What is the

I expect that due to Address Space Layout Randomization (ALSR) a process forked from another process will have different addresses returned when calling mmap . But as I found out, that was not the case. I made the following test program for that purpose. All the addresses returned by malloc are exactly the same for the parent and the child. Note that the malloc for cl1 , cl2 , pl1 , pl2 internally uses mmap because they are large blocks. So, my question is, why mmap is not returning different addresses even in the presence of ALSR. Maybe its because the seed for randomization here is the same

If I am not mistaken, ASLR will make the local variables in C compilers have a different address each time I run the program. But when I tried it in Turbo C++ and Dev-CPP IDE, it just returns a similar address for local variables. The code i tried: #include <stdio.h> #include <conio.h> int main() { int x = 10; int *ptr = &x; printf("%d", ptr); getch(); return 0; } Before, I thought the address of the local variables are the same because it is allocated in the same stack area and thus the same memory address. But when i found a thread here in stackoverflow about ASLR, it made me did these. I

For Windows 8 application certification, there are (among other) these requirements: 3.2 Your app must be compiled using the /SafeSEH flag to ensure safe exceptions handling 3.3 Your app must be compiled using the /NXCOMPAT flag to prevent data execution 3.4 Your app must be compiled using the /DYNAMICBASE flag for address space layout randomization (ASLR) I wasn't able to find out how to enable either of these in C++Builder XE. For /NXCOMPAT and /DYNAMICBASE , one can use editbin.exe from VS or peflags.exe from Cygwin. Though I would feel more confident about possible side-effects, if there

I want to know if someone could access libraries with function addresses that would be the same from one instance of the program to the other? The address space layout will be pretty consistent from run to run on the same device. A lot of the major system libraries are preloaded by zygote, and so inherited as shared mappings by the children it forks off to differentiate into applications. I suppose remapping them at the virtual memory level would be possible, but would incur a sort of dynamic-re-linking penalty and would be fairly tricky to implement. 来源： https://stackoverflow.com/questions

Windows 7 has Heap randomization and Stack randomization features. How could I manage it? How they are affects performance of my application? Where I could find more information on how it works? I'm using Visual Studio 2008 for developing C++ programs. I can't find any compiler's options for that features. Ok, Heap randomization and Stack randomization are Windows features, but have to be explicitly enabled for each process at link time. Mark Russinovich described how it is work in his 5-th Windows Internals book. Stack randomization consists of first selecting one of 32 possible stack

I'm writing my program in VS2010 and the build target is .NET 4. I believe that the DEP compatibility flag is on by default. Is that true? Is .NET also compatible by default with ASLR , and is ASLR turned on by default for my process, or do I have to request it at runtime? Yes, the NXCOMPAT flag is turned on by the standard .NET language compilers since .NET 2.0 SP1. ASLR is essentially automatic in .NET programs by virtue of the JIT compiler. Where it will place the JIT compiled machine code is unpredictable. Albeit that it will likely be repeatable on the exact same machine with the exact