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
As your friend said, do nothing with variables ...
1 ) your std::string is not a plain ascii string it is a structure (actually a class)
so you cannot take the address and find the string
in your specific case since your string test 's length is less than the threshold you are lucky you can see it in your screenshot look for 74 65 73 74 as ascii you will notice it is "test"
and your int it appears is ...
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
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);
As @Igor Skochinsky has already commented, the software is indeed written in Visual Basic 6 compiled in native mode (VB6 also supports P-mode). You can verify this with a PE Info tool like Detect It Easy (but before that you need to unpack the ASPack wrapper).
The cause of the bug is due to multiple reasons.
The software uses an WinApi Function ...
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;
when your hook code gains control, ...
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 ...
you may either need to use the local variables or compile with optimizations disabled
I assume you are using msvc on windows ??
shown below is a snippet that was compiled on x64 for x64 in win 10 where you can clearly see the local vars being initialized and used
-rw-r--r-- 1 197121 61 Sep 25 15:24 local.cpp
Answer of blabb is correct, I will just add some more information.
You are looking at wrong window of x64 for searching values. As you can see in your picture content of this window (CPU) is automaticly trying to disassemble data in memory as code. If you want to see values it is better to look up adresses in dump window (bottom left) or in stack window (...
After I did some more digging in the APK, I found what handles the fylesystem for the emulator. It is the libmain.so binary. Because it is handled by this file, modifying it is next to imposdible, this is because .so files are akin to windiws .dll binaries and are signed. Since modifying the file is not really an option, the only alternative answer to ...
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 ...
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 ...