1

You have the IDA View and Hex View right. When on IDA View you select an instruction you can see the instruction selected in Hex View as well. However, if you select a "data instruction" like "Format = dword ptr -10h" which is a stack variable, you don't see it in the hex view. It doesn't select the bytes corresponding to the variable definition. I mean I know the variable is going to be there in memory but somewhere on the hex view should tell me "hey allocate this stack variable" but it doesn't.

It's probably obvious by now, I'm a beginner in reverse engineering, I've been reading the book from http://beginners.re/ . While I do know some assembly and have been able to reverse simple things, I have these knowledge gaps I'd like to fill. Thank you!

Improve this question

1 Answer 1

Reset to default
2

Stack variables live in the stack's address space, not in the module's address space. Thus, there's nothing that the Hex View could show you statically.

Improve this answer
8
  • Ok so you have the text segment, data segment, bss segment. They all exist in the module's address space and get loaded into memory right? However in memory there are 2 more segments that don't exist in the module's space address, which is stack and heap. I thought the variables in the data segment(module's address space) were loaded to the stack, so I know where they come from, but what about these stack variables that aren't defined anywhere in the program, how do they end up in the stack? Thank you.
    – savram
    Jan 30, 2015 at 0:29
  • 1
    For each thread in the process, the operating system will create a region of memory for that thread's stack, so there can be multiple stack memory regions in a given process's address space. Similarly, the program's code may create multiple heap memory regions in the process's address space. The variables in the data segment are global variables (not stack variables); they are not automatically loaded onto the stack. Stack variables (also known as local function variables) are written to and read from the stack at runtime by the functions to which they belong.
    – Jason Geffner
    Jan 30, 2015 at 0:44
  • 1
    Unfortunately, in your example, IDA is using the same variable name (Format) for both a local stack variable and a global variable, hence the confusion. The Format in the []s is for the local stack variable; the Format in offset Format is for the global variable in the .rdata section. I'd recommend renaming one of these Format variables in IDA to make it less confusing.
    – Jason Geffner
    Jan 30, 2015 at 1:26
  • 1
    In the function prologue there will usually be an instruction that reserves the stack space needed for local variables. E.g. sub esp, 10h (to reserve 16 bytes) or push ecx (to reserve 4 bytes). Sometimes the compiler overlays local variables on the stack space occupied by function parameters, if it doesn't need those anymore (i.e. when they're past their live ranges). Then there might not be an explicit reservation for locals.
    – DarthGizka
    Jan 30, 2015 at 9:25
  • 1
    The Format = dword ptr -10h is not an instruction, ghost or otherwise. It's a declaration that allows it to put a meaningful name to stack references, even though the stack pointer keeps fluctuating (at least in 32-bit mode). IDA does it by picking a fixed frame of reference (usually the return address) and accounting for the current value of ESP with a literal number, e.g. push [esp+4+foobar] if the 'logical' stack pointer has a value of 4 currently. That way one and the same stack location always gets the same name; otherwise it would be [esp] in one place and [esp+10h] in another.
    – DarthGizka
    Jan 30, 2015 at 22:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.