This problem is linked to the halting problem on a Turing machine (which is known to be undecidable).
Approaching decompilation through emulation suppose that you have to run through all the branches of the software at least once, and reaching all possible program points cannot be guaranteed if you have to go through a (potentially) infinite loop.
Generally speaking, it depends on the platform. For example, if the software uses Intel AES extensions it is possible to find the corresponding instructions in the disassembly. If the software is compiled for other platforms and uses specific hardware accelerators it is possible to find it by accesses to specific addresses of the accelerators registers.
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, ...
I know that this question was asked some time ago, but here comes the solution working on Windows.
Note: See the last section of this answer to get the solution for other systems and architectures.
x86 32 bit files
OllyDbg2 is the tool that can be used for logging every single assembly instruction along with memory reads and writes. A short guide how to ...
I am sorry for this self-advertisement, but I am developing a tool here. My final goal is to recover the original control flow graph of virtualized binaries. But at a step of this, for visualization purpose, I have implemented a functionality to reconstruct the CFG of binaries from traces. The main implementation of this reconstrution is in the file src/lib/...
It might be useful to check the command line that was used to start the program.
Open the Details tab of Task Manager and right click on any column (Name/PID/status). Then choose "Select columns" and in the new window scroll down and check the "Command line" box (below the I/O ones).
This is called Virtual Machine Introspection (VMI) and, while definitely possible, requires you to implement parsing of the internal OS structures to isolate individual processes, modules etc instead of relying on the built-in OS support (such as used by WinDbg kernel debugger).
You can check for an example of how it could be done using IDA over VMWare's ...
Yes, you can do that. The python script doing that is attached below with appropriate comments.
r = r2pipe.open('programName', flags=['-d'])
modules = r.cmd('dmm') #list all modules along with start and end addresses
modules2 =  #modules' start addresses
moduleNames = 
#since modules is just one big ...
By default tracing is limited to reduce its overhead: it stops once it goes to a location not in the current database (external modules, runtime-allocated memory etc.), as well as functions marked as library code. You can change this behavior in tracing options (disable the “trace over” checkboxes).
Note that in some cases IDA may be unable to trace the ...
version used: ollydbg v2 but method is similar for v1 too
ollydbg allows you to log the trace i have done some crude diffs in the past as below
you can try improvise
here is the source code that's used for demo
keep in mind i had the source so i compiled it and linked with with /FIXED linker switch to vs 2017 linker so that ASLR doesn't get into ...
The only thing you can do with the dynamic analysis is to find where the final block is allocated. For this you need to enable memory allocation tracing with
gflags.exe /i yourApplication.exe +ust
Then use windbg and !heap -p -a command on the block address, it will print you the call stack which allocated this memory. So at least you'll have the idea ...