Memory addresses

Just wondering, is there a way to examine a program and find out which memory addresses it uses for what? Say I had a compiled C++ program that stores the int 5 into a memory address, is there a way I could find the address of this int using a 3rd party program (a hexer maybe?)?

 

Log in or Sign up to hide all adverts.

Your compiler should have options for viewing such things.

 

Log in or Sign up to hide all adverts.

The compiler has the choice of locating your int in stack space, heap space, or in a register. If it chooses stack or heap space, you cannot know the address of the variable at compile-time -- only at run-time.

When the program is run, its stack and heap are allocated, and the code and data portions are loaded into memory. Addresses (say, of a subroutine, or a variable) are stored in the object file on disk in relative format; when the code is put into memory to be run, a special part of the operating system called the loader is responsible for translating all of these addresses into absolute addresses, or for setting up segment pointers that allow the translation to be done on the fly (depending upon the architecture).

The end result is that it is impossible to know the exact address of a variable or subroutine until the code has been loaded into memory. You will have to use a debugger to find the final address; your compiler doesn't know, as it's only concerned with the relative addresses in the object files. The compiler has no idea where your code will end up in memory when it's run.

You can quite easily insert a printf statement (or the corresponding icky cout statement) into your code to list the address at runtime:

printf("My int is at location %x\n", &myInt);

You can also look at the assembly code the compiler generates; this may give you some good insight for guesswork. However, a good compiler will put a lot of variables in registers; if so, you'll know that your variable is always in a certain register, but only when your process is running. Whenever the OS interrupts your program and lets another run for a bit, the register values are saved off in a piece of OS memory you likely won't be able to access from a user program.

Bottom line: The compiler doesn't know; you'll have to use a run-time tool like a debugger to look at the object code after it has been loaded.

- Warren

 

Log in or Sign up to hide all adverts.

Re: Re: Memory addresses

oops

 

Thanks chroot. Will a debugger work for other .exe files as well? Lets say I run some program that I didn't compile, will the debugger list the addresses of it as well?

Also, is the printf statement used in C++? I'm going through the SAMS Teach Yourself C++ In 21 Days book and so far all I've seen is cout

 

Not unless the .exe was compiled with the debugging info turned on. Otherwise you'll just get a mass of nearly indecipherable assembly. This is what crackers have to do to steal software.

If you can be more specific as to your ultimate goal with this, perhaps we can help more. I don't think the road you're taking with this "address of a variable" question is a good one.

C++ is an extension of C. Anything that can be used in C can also be used in C++.

- Warren

 

If you're asking if I'm going to use this to crack programs the answer is no. I don't endorse cracking, and I never will. Programmers work hard to create programs and deserve to be compensated for their work, as does the company producing it. The only cracked program I have on my computer is 3DS Max, simply because I cannot afford to spend $600 on a program I rarely use.

I'm just trying to understand how variables are assigned into memory, where they are kept, how they are accessed and so on. The book I'm reading gives a short explanation on it, but I feel if I have an in depth knowlege of how RAM actually works I can use that knowlege to write better or more efficient programs. That and I just find Memory kind of intriguing.

Anyway, if you could point me to a site or something that will explain memory in more detail that would be great too. I just figured that being able to see how and where the variables are assigned would help me in understanding RAM.

[edit]Just curious though, how would finding memory addresses help you crack a program? I thought cracks only change registry keys or the files that come with the program themselves.[/edit]

 

I really don't care if you steal software -- I was just asking if there was some point to your questions, so that I can tailor my answers to your purpose.

Just about any textbook on operating systems will discuss the loading process and address translation. There are three steps in going from source code to executable image in RAM: compilation, linking, and loading.

If you can figure out where a program keeps the flag that indicates if you have or have not paid, you can insert an instruction to always set that flag true.

- Warren

 

Alright, let me see if I got this figured out.

Lets say two variables are loaded into the memory, A and B. Lets say variable A is located beneath variable B on the stack. Now if the program wants to access variable A, everything above it on the stack (variable B) is discarded? Or are they simply ignored by the program?

The way this book explains it is that the memory stack is like a series of cubby-holes (like drawers) stacked up on eachother. Then a pointer moves to the location on the stack a program instructs it to. Everything below that pointer is now part of the stack, and everything above it is declared invalid and ignored. Is this at least semi-right?

And thanks for your help so far =)

 

A stack is just an array of cubbyholes which is operated on in only two ways: 1) by putting ("pushing") a new value at the end or 2) by removing ("popping") the value that currently is at the end.

Compilers don't really declare variables "on the stack;" the stack is really used for communication between two routines. When one routine desires to call another, it pushes the parameters of the call onto the stack in an agreed-upon order, then pushes its return address, then jumps to the first instruction in the subroutine. The callee pops the return address off, stores it somewhere (usually a register), pops off its arguments and does its work. When it's time to return to the caller, it pushes the return address back onto the stack, and runs an RTS (return-to-sender) instruction.

So if you write a function like this:

int square(int x) {
return x*x;
}

The assembly (in generalized pseduocode here) would look like this:

square: pop R1 ; store the return address (which is, by convention, always at the top of the stack) in register R1.
pop R2 ; store the value of 'x' passed by the caller in register R2.
mult R2, R2 ; multiply R2 by itself, storing the result in R2.
push R2 ; push the new squared value of 'x' onto the stack
push R1 ; push the return address onto the stack
rts ; return to sender (return to calling function)

The argument x is pushed onto the stack by the calling function before the call is made. In this sense, the variable x only exists on the stack. It doesn't have a defined memory address; if the function "square" is called in several places within your program, the physical address of x could be different everytime, depending on what's below it on the stack.

Often, the compiler immediately moves this variable from the stack into a register to operate on it, though, as I showed -- so sometimes you can consider the register to be the 'absolute address' where x lives in the scope of the function "square."

- Warren

 

If you're programming in asm of whatever type, you can: 1) know the exact location of variables in registers, since registers are a type of memory; 2) specify RAM locations as you see fit, as long as you don't fool around with areas important to other tasks.

For example, one of my tasks at the moment is writing a MIPS assembler, which involves specifically allocating RAM locations all over the place.