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 ...


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: ...


5

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 ...


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 ...


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.


3

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 ...


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 > ...


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 ...


2

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 ...


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

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.


1

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:...


1

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 ...


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

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

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