It is also easy using x64dbg. When you break on the WriteProcessMemory the handle will be at [esp+0x4] in the memory.
After you write down the handle (in this case 0xDC) you may go to the Handles tab in the x64dbg main window, then Right click -> Refresh. All the handles associated with your debugged process will be listed. Now you need to find the ...
which debugger are you using ?
most debuggers will decipher the handle on the spot
that is you can find out the handle info when you have broken on the WriteProcessMemory() Call itself
here is how you can do it with windbg
i am debugging ollydbg and olllydbg ais debugging calc.exe
ollydbg is setting a breakpoint in calc.exe (uses WriteProcessMemory() )
You can use jdb to attach to a running program without having compiled it with debug flags.
on my machine with jdb located at /usr/local/jdk/jdk1.8.0_202/bin/jdb
and pid of my running java process = 14476
sudo /usr/local/jdk/jdk1.8.0_202/bin/jdb -connect sun.jvm.hotspot.jdi.SAPIDAttachingConnector:pid=14476
However if you did not compile your program with ...
Many programs, especially malware, start a suspended child process (CreateProcess variants), overwrite its code with their own (WriteProcessMemory with or without VirtualAllocEx) and resume the main thread (ResumeThread).
Also look for ReadProcessMemory, it is possible that the call to OpenProcess that you see is actually the same process reading from its ...
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 ...
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.
Is movq rax, xmm0 buggy in Radare2?
No, it's just not fully implemented in all debuggers yet.
Native Debugger Works!
This instruction works fine using the native debugger. The native debugger is launched with r2 -d yourFileGoesHere. Alternatively, if you are already in r2 looking at the file, but r2 wasn't launched with the -d switch, the file can be ...
osboxes@osboxes:~/proto/bin$ ll | grep stack0
-rwsr-xr-x 1 root root 22412 Jan 22 07:16 stack0*
bash: ./stack0: No such file or directory
The program is marked as executable, but trying to execute it says there is no such file or directory. I didn't even notice it, because radare2 and gdb were able to execute it.
The point of the debugger is to show what actually is in memory and not what happens to be present in the database. That said, I imagine you can come up with some script based on visit_patched_bytes(), get_original_byte() and get_db_byte().
Yep, the answer depends on what exactly you are trying to achieve.
In terms of analyzing the .NET app itself, you can get a complete source code by using, e.g. DotPeek written by JetBrains. You can even export it into a fully-functional Visual Studio Project, build it and debug. However, some apps may be obfuscated.
Another scenario is when a .NET app is a ...