Memory hacking / memory allocation : why does this work and how?

Question

What i know is you look for some address of of some variables in the software you're trying to manipulate . And once you find it you then try to find the "base pointer" for it so no matter where the process is , you can still access those variables.I mean when the process is restarted the variables would have different addresses , but still you know where they are .

Now what i don't get is why is this possible ?

lets say i do this in C++ :

int *x = (int*)malloc(sizeOf(int));

isn't that dynamic ? and shouldn't x be placed in a "random" address that was free at the time ? Basically what I'm asking about is where is x really when that code is executed?

EDIT : i mean like usually variables like health are stored in addresses like game.exe + 0000caff , and then you can always find them there .

Gonna depend on OS among other things. You haven't given nearly enough info for us to tell how you are "hacking" your target executable. You also will probably need to look at the assembler output a bit to figure out how things are being stored. — Michael Dorgan, Apr 20 '15 at 23:03
_" And once you find it you then try to find the "base pointer" for it so no matter where the process is , you can still access those variables."_ Can you give an actual sample how `x`'s value is the same for repeatedly runs of your process, please. And also have in mind, that there are concepts like a _virtual address space_ for processes, that depends on the actually used OS's policies. — πάντα ῥεῖ, Apr 20 '15 at 23:04
edited the question , i meant why is x address at same offset from the process while its supposed to be dynamic ? — vlatkozelka, Apr 20 '15 at 23:07
@vlatkozelka: There's a confusion here I think. `x` appears to be a global pointer, and globals are almost always at the same offset every time. It _points_ at a "random address that was free at the time". Even if `x` is local to a function, they may sometimes end up at the same offsets each time, depending on how it's programmed. There's a thousand exceptions to everything I said though, like [Address Space Layout Randomization](http://en.wikipedia.org/wiki/Address_space_layout_randomization) — Mooing Duck, Apr 20 '15 at 23:20
_"isn't that dynamic ? and shouldn't x be placed in a "random" address that was free at the time ?"_ Yeah but the program contains a pointer to it... Actually, `*x` is at the "random" address. Not `x`. — Lightness Races in Orbit, Apr 20 '15 at 23:21

score 4 · Answer 1 · answered Apr 20 '15 at 23:20

x is a variable which holds an address of an integer.

malloc allocates memory on the heap, but x is still located on the stack (if you declare it in a functio).

How ever, your programm has diffrent parts of memory, one for global variables and constants, one for source code, some for resources, one for dynamic stuff (heap) and some others.

Lets assume your x is located in the part for global variables and points to the heap. Then x has a static address.

This address can be found in the source code part by assembler instructions like mov eax , [0x123]. This assembler instruction also has an address which is relative to the module where the instruction is located. These modules can be loaded dynamicly (e.g. by LoadLibrary), but the offset from the modules base address to the instruction is fixed.

To get data where x points to:

base = getModuleBaseAddress("modulename")
addressOfX = base + offset
valueOfX = *addressOfX

Most objects are not located on the stack and can be referenced by a modules address, a fixed offset to jump to the instruction where objects pointer is used and some offsets to get objects variavles.

To find objects in memory you can also use a pattern scan to scan the memory.

score 4 · Accepted Answer · answered Apr 20 '15 at 23:21

The following is from the perspective of 32-bit x86 architecture, other architectures may do things differently. Also, I assumed that the single line of code was in a function.

First remember what the declaration int* x means, loosely it can be read as "the variable x will contain the address of an integer"

The variable x is a local (or automatic variable) which means its location is determined at compile time, and storage space for it is allocated when the function is activated (most likely on the stack).

The value contained in x is a dynamic address (and probably located on the heap).

So what you have is a binding between the variable x and some location in the activation frame of the function. Excusing the poor ASCII art, something like this (address are notional, also remember that the stack grows down):

             ~            ~
             |            |
             +------------+
    0x04000  |            |<----   ebp
             +------------+
             |            |
             +------------+
    0x03ff8  |     x      | 
             +------------+
             |            |
             +------------+
    0x03ff0  |            |<----  esp
             +------------+

Now we have to register values ebp (the extended base pointer) and esp (the extended stack pointer) that define the bottom and top of the activation frame on the stack. So in assembly, if you want to locate where x is stored is is based on an offset from the base pointer.

Another way of thinking about it that the variable name x is an alias for the memory location epb-8. Because, this is how the compiler lays out memory the storage location for x will always be located at the same offset from the base pointer.

Now, during multiple runs the value of the base pointer might change, as long as I can find the base pointer for the activation frame, I can find the storage location for x and fiddle with it.

score 0 · Answer 3 · edited May 23 '17 at 12:06

"and shouldn't x be placed in a "random" address that was free at the time ?"

If you run a process in an operating system, the pointer values actually used are likely to address kind of virtual address spaces available for particular storage duration categories, that are associated to your process with a concrete region of RAM and ROM addresses, and those are managed by the operating system.

So if you have the same dynamic storage duration de-/allocations in sequence, these are likely to receive the same (virtual) address with each run of the program. There's nothing random at this level.

Memory hacking / memory allocation : why does this work and how?

3 Answers3