7
I'm not sure that it is possible to answer this question without seeing all the function because correctness of local variable type recovery can be done only by understanding of the context where variables are used.
However, I'd suggest the following algorithm for dealing with local variables
in Hex-Rays:
As your friend said, do nothing with variables ...
6
1:
See the Immediates section on this 64 bit assembly reference.
Immediate values inside instructions remain 32 bits and their value is sign extended to 64 bits
There just isn't an instruction to move a 64 bit immediate value to memory (*). And because it can be emulated nicely by moving two chunks of 32 bit, there was no reason to introduce new 64 bit ...
5
TL;DR:
This is not an error from Ghidra. The values are just a naming convention, and the real instructions are correctly disassembled.
Ghidra assigns variable names based on the function entry point, and displays offsets based on that.
It seems Ghidra behaviour is like this to have a universal way to assign names, independently from the compiler.
As ...
5
you can check the IMAGE_LOAD_CONFIG_DIRECTORY structure, it has a field for the pointer to SecurityCookie's value in the image.
In very old binaries, this structure might be not used, or SecurityCookie RVA is 0 even though the binary may be using /GS. In such case you can scan for the characteristic code signature of the @__security_check_cookie@4 function:
...
4
4275451536 is greater than 2^31 (2147483648) but less than 2 ^32 (4294967296)
so it is represented as 2^31 + ( 2 ^31 * ((4275451536 - 2 ^31 ) / 2^31)
ie 2^31 * 1.990912266075611114501953125
exponent is always written with bias (1023 for 64 bit precision) added to it so 1054 = 0x41e
fractional part can be written as 1/2 + 1/4 + 1/8 + 1/16 + 1/32 ...
4
Double click the variable name in the disassembly, or press ctrl-k, to open the stack frame window. You can change your variable types there.
4
I don't think that it is possible.
Let's assume the following C code:
int f1(int p1, int p2)
{
int l1, l2, l3;
/* some code */
l1 = l1 + l2; // here is our virtual address
return l1;
}
int f2(int p3, int p4)
{
int l4, l5, l6;
return f1(p3, p4);
}
int f3(int p5, p6)
{
int l7, l8;
return f2(p5, p6) + f1(p6, p5);
}
Obviously ...
3
The second member, called buf (at location 4) is not a char. The type of that member is defined at 0x3451, and this is an array type. Its elements are each of the type defined at 0x2d04, which is a typedef named Char, which redirects to 0x29b7, which is indeed char (represented as base type signed char).
<1><3451>: Abbrev Number: 11 (...
3
So the space between esp and var1 is going to be free without any use
? that's what I want to know.
That stack space is used for the function's local variables (also known as "stack variables").
Here's a nice animated GIF that shows a function's stack frame being created and used to store local variables:
3
Visit these two webpages for information about stack and stack frames
what is meaning of the initial stack between EBP and ESP?
EBP and ESP are used in conjunction to create a stack frame. To allow for many unknowns in the execution environment, functions are frequently set up with a "stack frame" to allow access to both function parameters, and ...
3
In your case because int is 4 bytes and you want 20 element
int a[20] // --> 20 * 4 = 0x50
so it is very normal for i and i_2
The other thing is that your compiler didn't push printf arguments into stack. It pre-allocated the stack location in
var_70 = dword ptr -70h
var_6C = dword ptr -6Ch
var_68 = dword ptr -68h
and called the function like this
...
3
To examine in radare2 you can think as 'print values' and you can use:
px show hexdump
pxl display N lines (rows) of hexdump
pxr[j] show words with references to flags and code (q=quiet)
Example:
> px [nBytes] @[address][offset]
"Print hex 10 bytes at rbp plus 10"
[0x5618eccbf77a]> px 10 @rbp+10
> ...
2
The decompiler decided that ecx is used by sub_431C00 because of push ecx at the beginning of the function which fills the stack slot later used by the variable phkResult, so it may look as if the initial value of phkResult is taken from ecx:
.text:00431C00 push ecx
.text:00431C01 lea eax, [esp+4+phkResult]
.text:...
2
Welcome to RE.SE!
How to understand what the problem is?
When the function is decompiled, IDA checks for its dependencies via dataflow analysis. Basically, it asks which values have to be defined in order to make this function work.
When it encounters the first line of the function (push ecx) IDA noticed that the value of ecx is used before it was ...
2
If you have a debugger with access to symbols, then you can run to the start of the function, and then place watches on the symbol names.
In the absence of a debugger, if you can hook the function itself, then one way to do it is this:
save the original few bytes in the routine, and install a hook;
resume execution;
when your hook code gains control, ...
2
As far as I know this is not even possible in IDA 6.9 yet, and definitely not possible in IDA 5.
When encountering such cases (which are quite frequent with certain compilers), I often find it the easiest to give such variables a name that denotes them as having two different purposes shared on the same stack address.
2
probably the Buffer variable is accessed indirectly by one of the called functions and var_22C is actually part of the buffer.
2
I'd change the variable right when it's created and stored into its position. For example, if one function calls another, that other function returns the variable, and the first function stores it somewhere, this will look in assembly somewhat like
80483e7: e8 d8 ff ff ff call 80483c4 <value>
80483ec: 8b 54 24 1c mov ...
2
Finally I've found an answer.
After parsing result lies into $rbp-0xdo
(gdb) x/8w ((int*)($rbp-0xd0))
0x7fffffffdf90: 0x00000000 0x00001111 0x00002222 0x00003333
0x7fffffffdfa0: 0x00004444 0x00005555 0x00006666 0x00007777
when input is 0000:1111:2222:3333:4444:5555:6666:7777
So $rbp-0xb8 (var_b8) is similar to $rbp-0xd0+0x18, ...
2
I assume you are using *nix based systems since you mentioned gdb. If you just want to print the stack/registers when you hit a break point, you can use command to set up some print statements. See here.
Installing pwndbg makes it a lot less exhausting as it prints out the stack and registers every time you step, with labels on the stack identifying rbp and ...
1
After reading up on "shadow stack space" as suggested by @blabb it looks like this is an unoptimized build, so the 2 parameters RDX and RCX are being saved in the caller's scratch space, presumably to make debugging easier. I got most of this information from the following post:
What is the 'shadow space' in x64 assembly?
1
Generally speaking, this is not possible with any reverse engineering tool. If the programmer created custom #define statements to associate numbers with symbolic names, this information will be destroyed by the compiler very early into the compilation process, long before the binary is ultimately created. Local variable names are also not preserved in the ...
1
Borland's Turbo Debugger also has a text-window-based UI, with the stack in its own window and showing which values in which locations. It doesn't tell you what those values represent, but at least it's always visible.
1
Let's start first with finding local variables. Binary files contain multiple sections used for a plethora of purposes. The section of interest in your case is the .bss. In this sections, you're supposed to find a reference to the local variables used by your program.
Now, regarding the variable name, the only way to associate it to a relative address is ...
1
What you're actually doing there is passing pointers to the array, not the array itself. If you look at the declarations:
char * const argv[] = {"cat", "/etc/target/file"};
char * const envp[] = {NULL};
execve("/bin/cat", argv, envp);
'argv' and 'envp' are pointers to the array.
Typically, it's easiest to just ROP to execve('command', NULL, ...
1
As far as I can see this mov al, [ebp+var_22C] command works with 8 bit data (according to name al), and there is a possibility that this var_22C variable is assigned as a part of bigger entity, for example as dword, which will require different offset.
I'd suggest to watch to stack accesses around this offset, specifically ,as @Igor Skochinsky says in ...
1
IDA declares local variables as var_XXX at the start of function
In the paste below var_108 is declared as dword ptr -108h
So 0x10c - 108 = 4
If You hit K
ida would show you
.text:0040115C lea eax, [esp+4]
If I find it confusing and prefer [esp+4] to [esp + x + (-y) ] I use the script in my answer to this question
https://...
1
RtlCreateUserStack() creates the stack on thread creation (And every process has the main thread). Or more generally: The Windows PE loader.
What is the PE loader? That thing that creates a process out of an executable file on disk (or adds that executable file to a process in case of DLLs)
Your other question is why, by the time Olly breaks, there ...
Only top voted, non community-wiki answers of a minimum length are eligible
