shellcoder | Create shellcode from executable or assembly code | Hacking library

When I print a variable's address, is it showing the relative ( virtual ) address or the physical address in where the variable located in the memory ?

The counterpart to a relative address is an absolute address. That has nothing to do with the destinction between virtual and physical addresses.

On most common modern operating systems, such as Windows, Linux and MacOS, unless you are writing a driver, you will never encounter physical addresses. These are handled internally by the operating system. You will only be working with virtual addresses.

Why does this code produces the same stack pointer value for each run ( from shellcoder's handbook , page 28) ?

On most modern operating systems, every process has its own virtual memory address space. The executable is loaded to its preferred base address in that virtual address space, if possible, otherwise it is loaded at another address (relocated). The preferred base address of an executable file is normally stored in its header. Depending on the operating system and CPU, the heap is probably created at a higher address, since the heap normally grows upward (towards higher addresses). Because the stack normally grows downward (towards lower addresses), it will likely be created below the load address of the executable and grow towards the address 0.

Since the preferred load address is the same every time you run the executable, it is likely that the virtual memory addresses are the same. However, this may change if address layout space randomization is used. Also, just because the virtual memory addresses are the same does not mean that the physical memory address are the same, too.

Does any program that I will run produce this address ?

Depending on your operating system, you can set the preferred base address in which your program is loaded into virtual memory in the linker settings. Many programs may still have the same base address as your program, probably because both of you are were using the same linker with default settings.

The virtual addresses are only per program? Let's say I have 2 programs: program1 and program2. Can program2 access program1's memory?

It is not possible for program2 to access program1's memory directly, because they have separate virtual memory address spaces. However, it is possible for one program to ask the operating system for permission to access another process's access space. The operating system will normally grant this permission, provided that the program has sufficient priviledges. On Windows, this is can be accomplished for example with the function WriteProcessMemory. Linux offers similar functionality by using ptrace and writing to /proc/[pid]/mem. See this link for further information.

There are couple of things that could go wrong here:

• The store of the shell code address is optimized away because it is derived from a stack variable, and nothing reads from the stack afterwards.
• The store is optimized away because it is out of bounds.
• The offset calculation from the local variable is wrong, so the shellcode address does not overwrite the return address. (This is what happens when I compile your example.)
• The execution is redirect, but the shellcode does not run because it is located in the non-executable .data segment. (That would cause the process to terminate with a signal, though).

1. gets read terminating byte in and replaced it with NULL byte and thus your desired ret was broken with that NULL byte.
2. The offset you saw in disassembly codes is NOT the real address, you compiled the program with PIE flag set so the real address may look like 0x55555????58a, that's why gdb didn't allow you to insert a break point because you might try to do b *0x58a or something. Compile with -no-pie would make life easier.

Well, the data & code are just bytes. Only how you interpret them makes them what they are. Code can be interpreted as data and vice versa. In most case it will produce the something that's invalid but anyway it's possible.

Attributes of the section are dependant on the linker and most of them by default make the .text section RO, but it doesn't mean it can't be changed.

The whole example is a clever way to obtain the address of /bin/sh just by using the call. Basically the call places on the stack the address of the next instruction (next bytes) and in this case it will be the address of this string so pop esi will get that address from the stack and use it.

But several things just feel wrong

Yes, they are. It isn't unusual for a book to have typographical errors. Usually, you should look for a published list of errata when you see something that makes you scratch your head. The publisher's website is a good place to look, as is the author's. I don't know what the book's exact title is, so I can't search for it myself, but you should be able to find it easily.

Of course, it may not be that simple. Books by less-reputable publishers often won't make an errata list available, and less-popular books often don't have enough readers to have caught the errors. You can do your part by locating the author's email address and notifying them of the errors you've found. Or, if you aren't sure whether they're errors, asking the author to clarify. (You don't want to expect the author to provide a personal tutorial for you, but specific questions about things published in their books are always fair game.)

lea 0xffffffd8(%ebp), %edi, it is my understanding that the first part means multiply the base pointer by 0xffffffd8, that seems incorrect

In this case, it is your understanding of what the code does that's incorrect. I blame this demented AT&T syntax. The translation to Intel syntax is: