10

I'm disassembling an executable:

(gdb) disas main
Dump of assembler code for function main:
0x004012d0 <main+0>:    push   %ebp
0x004012d1 <main+1>:    mov    %esp,%ebp
...

Each time the memory address is the same:0x004012d0.

Isn't the memory address to be dynamically assigned by the OS?

UPDATE

Now I see it's virtual space,and it can be randomized on some platforms.

Can someone post a gdb dump that changes ?

Earlz
  • 62,085
  • 98
  • 303
  • 499
Mask
  • 33,129
  • 48
  • 101
  • 125
  • suggest you tag your questions accordingly – Paul R Mar 31 '10 at 19:46
  • 3
    No,it's not necessary to restrict the topic to windows only. – Mask Mar 31 '10 at 19:51
  • Based on gdb in question and based on disassebmly format I would guess the question originated in Linux. It seems I am wrong - somebody is probably using gdb for Windows as well. – Suma Mar 31 '10 at 19:59

8 Answers8

4

I think the problem here (at least on Linux) might be gdb trying to help out, from the docs:

set disable-randomization

set disable-randomization on

This option (enabled by default in gdb) will turn off the native randomization of the virtual address space of the started program. This option is useful for multiple debugging sessions to make the execution better reproducible and memory addresses reusable across debugging sessions.

This feature is implemented only on gnu/Linux. You can get the same behavior using

         (gdb) set exec-wrapper setarch `uname -m` -R

http://sourceware.org/gdb/current/onlinedocs/gdb/Starting.html

UPDATE: I've now checked this and it does seem to be the case for me (running Linux 2.6.28). Compile a simple Hello World program and start gdb with no command-line args (we don't want to load the program before overriding the disable-randomization setting) and then enter:

(gdb) set disable-randomization off
(gdb) file ./a.out
(gdb) break main
(gdb) run
(gdb) disas printf

The address of printf is different each time the program is run.

Community
  • 1
  • 1
Mike Dinsdale
  • 1,491
  • 9
  • 8
3

It depends on the OS. Most of the time the address of the binary stays the same. This is important for exploiting memory manipulation bugs, such as buffer overflows. The address of linked libraries under Linux will always be different due to ASLR. Under Windows Vista and Windows 7 the binary's virtual memory space is also randomized each time it is executed, so the function address will be different for each run.

rook
  • 66,304
  • 38
  • 162
  • 239
  • Seems you're wrong,I just tried to disassemble an executable in linux,and it's the same each time,too. – Mask Mar 31 '10 at 20:10
  • 1
    Note that The Rook is talking about libraries, so you might not see this effect on the `main` function – Mike Dinsdale Mar 31 '10 at 20:17
  • 1
    @Mask, yeah Linux's ASLR doesn't randomize memory with in the TEXT memory segment. Windows 7 and vista does. Linux's ASLR will randomize the HEAP, STACK and dynamically linked libraries. – rook Mar 31 '10 at 20:52
2

That is a virtual address. The physical address is known to the OS, but each process has its own virtual address space. A relocatable image is likely to get the same mapping everytime, especially the main executable. But it is not guaranteed. An example is DLLs. DLLs may load in different order, resulting in different virtual addresses between runs, because as DLL 1 is loaded, then DLL 2 cannot be loaded into that virtualaddress and must get its own address.

codenheim
  • 20,467
  • 1
  • 59
  • 80
2

Yes and no. The physical memory is allocated by the OS, and only the OS is aware of where your program is in physical RAM. Your program only sees the virtual address, which will always be the same if everything is loaded in the same order.

tloach
  • 8,009
  • 1
  • 33
  • 44
2

Executable relocation

Some executables are set so that they are always loaded at the same address. Some are set so that they are "relocatable". The option controlling this in Visual Studio linker is called /FIXED. Even such executables are most often loaded at preferred address. Newer OS (Win7, Vista) randomize the loading address for some executables to improve security (attacking process loaded at unknown address is harder) - this is called ASLR. Note: Even executable marked as /FIXED:NO is not assumed to be suitable for ASLR. Developer needs to allow ASLR explicitly for the executable.

Virtual address space

Note: It is important to understand the process owns the whole address space. Multiple processes have each address space of their own, therefore if you launch the same executable multiple times, there is no reason why it could not be loaded at the same address every time.

Community
  • 1
  • 1
Suma
  • 33,181
  • 16
  • 123
  • 191
  • Does ASLR modify the virtual address or the physical address? – Mask Mar 31 '10 at 19:50
  • 1
    Virtual. The physical address can always change over time (even within one execution) with or without ASLR as pages are swapped in and out of memory. – Tyler McHenry Mar 31 '10 at 19:54
  • Exactly: Physical address is something which is completely hidden from you. I have been programming Windows games for more than 10 years, often doing even a low-level stuff, but I have never ever had need to care about physical addresses. To tell the true, I would not even know how to check a physical address for some memory page. – Suma Mar 31 '10 at 19:57
  • @Suma,can you post a gdb dump that actually changes? – Mask Mar 31 '10 at 20:01
  • I am sorry, the computer I am on now is XP only, I do not know how to demonstrate this on XP. With Vista and an executable marked as "/DYNAMICBASE" it should be fairly easy. – Suma Mar 31 '10 at 20:07
  • I just tried on linux only to found it's fixed,too.Which is different from what @The Rook said. – Mask Mar 31 '10 at 20:12
  • No. He said dll (linked library) address is varied on Linux, not the executable one. – Suma Mar 31 '10 at 20:22
  • What about the `main`,is it fixed on all platforms for all processes? – Mask Mar 31 '10 at 20:32
0

It depends on the operating systems. In most modern operating systems with virtual memory there is no need for executable code to be relocatable, but in older operating systems, and in some specialised operating systems (e.g. real-time, embedded) code overlays may be used in conjunction with position-independent code and jump tables. In this case it's possible for a function's address to change, e.g. if its code segment is swapped out and then swapped back in at a different address.

Paul R
  • 208,748
  • 37
  • 389
  • 560
0

These are terminologies from computer security. In the past it was fixed address (< 1996, according to LKML, but it is only recently that executeable began to be compiled as relocatable, in order to implement ASLR. (But much longer ago, all libraries have been compiled as relocatable, so that libraries can be reloaded into different addresses if necessary - read dynamic relocation but due to order of loading, those main syscall API is normally loaded into fixed address.) Even today,

doing a gdb /bin/ls and following by "run", u will discover that default address is not change:

(gdb) disassemble __open Dump of assembler code for function open: 0xb7f017f0 <+0>: cmpl $0x0,%gs:0xc 0xb7f017f8 <+8>: jne 0xb7f0181c

Anyway, ASLR originate with PaX - read the wiki, it covered a lot on the requirements of implementing ASLR.

Why ASLR? To prevent 2 types of attack: http://en.wikipedia.org/wiki/Return-to-libc_attack and http://en.wikipedia.org/wiki/Return-oriented_programming, because both attack assumed your code area if fixed in memory.

Peter Teoh
  • 6,337
  • 4
  • 42
  • 58
-3

Why would the OS pick a different address?

When the OS execs a process, it loads an executable file into a virtual memory space. Along the way, it will resolve any relative and/or symbolic references. Assuming that you have the same executable, and the same shared libraries, and start it the same way that you did the previous time, it would be very strange for the OS to decide to load the executable in a different way.

Anon
  • 345
  • 2
  • 6
  • 1
    Incidentally, if you edit your question to indicate exactly which OS you're using, it's possible that someone could give you a better explanation of how that particular OS loads and links a program. – Anon Mar 31 '10 at 19:36
  • 1
    Some OS's pick a different address for each execution, its called ASLR. – rook Mar 31 '10 at 19:41
  • 1
    The OS can pick a different address, for example, with a DLL. It is relocatable and dependent on the order in which it was loaded. If DLLs are loaded dynamically, they may be loaded in a different order across executions of the same program. – codenheim Mar 31 '10 at 19:43
  • @mrjoltcola, @The Rook - did you read my response? I didn't say that the OS *couldn't* choose a different address, I said that given *the same starting conditions* there's no reason why it would. – Anon Mar 31 '10 at 19:51
  • 1
    I read your response before you edited it. And it _still_ says "Why would the OS pick a different address?" Rook and I both provided reasons why, hence my downvote. – codenheim Mar 31 '10 at 19:54
  • @mrjoltcola - (1) I never edited my response, (2) the first line is what's known as a rhetorical question. – Anon Mar 31 '10 at 19:59
  • 1
    I apologize, it appeared to read a little better the 2nd time, so I assumed it was edited. I disagree with your rhetorical question, and I have listed the reason why. I agree with the rest of your answer, but your rhetorical question implies that the OS won't pick a different address, misleading, even if it is an edge case. – codenheim Mar 31 '10 at 20:05