Get Ready for an Adventure!
You need a few things for your quest! Let's start at the beginning.
QEMU and GDB
QEMU is an emulator for various architectures. Generally, it's used to emulate an entire PC (i.e. to run a virtual machine). However, for debugging a single program this is not necessary. On Linux, you can use QEMU User-Space emulation.
$ sudo ...
It is actually very simple and works for me just fine as you can see in the following gif:
First you need to figure out the tty of the terminal you want to redirect the STDIO to (a.k.a Terminal 2, T2).
You can do this by simply execute:
This tty will soon be used on the rarun2 profile file.
Meantime, let's put T2 to sleep by using sleep ...
I have thought carefully before adding this as "Another Answer" rather than editing my existing answer that I posted above this morning.
I feel that this answer deserves another post of its own as it's not just a simple continuation of the material posted in my answer above.
I have spent over 2 hours on this post to avoid just cutting and pasting content ...
UPDATE: GDB 8.1 has a starti command, as mentioned below by /u/ruslan
Setting a breakpoint on an unmapped address before starting the target process does this, effectively. It's not correct functionality, but rather a side-effect of the failure to set the breakpoint.
(gdb) break *0
Breakpoint 1 at 0x0
Starting program: /home/user/ld.so
Error in ...
Very easy, if I got you right:
Make an Ida project from the DLL, i.e. drag and drop the dll into the blank Ida page.
In Menu Debugger, Process Options, put the path to your exe into the textbox "Application", Into "input file" put the path to your DLL. Confirm with OK.
Start with menu Debugger, Start Process or F9.
Your breakpoint should be hit.
(OP didn't specify if he knows how structures are laid out. Looks like he assumes they aren't complex. I'll answer a more general question to avoid locality issues by assuming the structures are somewhat complex)
Few ways to find the other structures come to mind:
Scanning memory for signatures
Once you have a few examples of the structures, maybe the ...
This program uses the PharLap DOS extender, as can be seen in its MZ header. The 32-bit executable program starts at offset 18A0, per "offset within header of relocation table" (see http://www.program-transformation.org/Transform/PcExeFormat), and at that position you can see the correct signature P3. According to the header info, the executable's length is ...
As promised, I am back to post a more specific answer to the question that was asked by the OP.
Decided to write this as a separate answer as I believe that this content stands out on its own and would not properly fit in with either of the two answers that I posted above.
Addressing his first issue :
In this case though, the whole settings is a ...
The technique of jumping to 64bit code from a 32bit WOW64-ed process is commonly called "Heaven's gate" when performed manually. This is usually done to use 64bit features (such as manipulating 64bit processes by calling 64bit versions of windows APIs) or by malware to make debugging more difficult, which is coincidentally what you seem to be experiencing ;)....
funcap uses IDA's debugging API to record function
calls in a program together with their arguments (before and after).
This is very useful when dealing with malware which uses helper
functions to decrypt their strings, or programs which make many
Here is a way how you would go back to the caller. The following is a small C++ crackme for demonstration
printf("Enter your password : \n");
In OllyDBG and ImmunityDbg, in Options->Debugging Options-> Events you have an option "Break on new module". If this option is set, whenever a new DLL is loaded, Olly/Immdbg will break and let you do your business.
In Windbg follow Debug-> Event Filters, in the list you will find Load module, on the side set the options to "Enabled" and "Handeled" which ...
2 great disassemblers... lost in time. SPECIFICALLY for DOS and 16 bit programs. They were the IDA PRO of THEIR days...
WCB (EXTREMELY rare to find. NEVER misses beginnings of a routine. NEVER)
SOURCERER (IF you can find it. THE disassembler to go to when professionals wanted to disassemble any file. INDUSTRIAL strength, MORE OPTIONS that you can throw a ...
This approach is commonly called "differential debugging". I know of the following tools that can help with it:
PaiMei from Pedram Amini
MyNav by Joxean Koret
IDA's trace replayer allows diffing two execution traces (also implemented by Joxean)
BinNavi has this feature
simple differ by @dionthegod
a script from Carlos Garcia which uses WinAppDbg framework ...
The gdb terms (and commands) are step and next and the difference is that step continues to run until it changes line of source code, while next doesn't trace into a subroutine, but rather skips over it. The stepi and nexti commands are similar but operate at the machine instruction level rather than source code level. Read more in The Fine Manual.
I still think this will create a BSOD, what's more I think that this is deliberate. It makes perfect sense to assume that this is deliberate once piecing all the puzzle pieces together. The source incompatibility will inevitably force that the developer notices the change of type for KeNumberProcessors from PCCHAR to CCHAR. The likeliest error is: error ...
According to this link, it should be possible to find the function in use with the following steps:
Attach gdb to the currently-running PHP process: gdb -p <processid>
Load in the PHP .gdbinit file for your version of PHP (available from here)
Use the zbacktrace command to display the currently-running PHP script
gdb -p 4584
Binaries are usually stripped. For ELF binaries, you can check it with file command
$ file /bin/true
/bin/true: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x73796652ea437df8ac7b3ba1864a7ac177e27600, stripped
Notice the stripped at the end of file's result. It means, among ...
Immunity Debugger is forked from OllyDbg v1.10.
So you should use the latest version of OllyDbg (currently v2.01) instead of Immunity Debugger if you want any OllyDbg v2-specific features/fixes. If you don't need those OllyDbg v2-specific features/fixes though, then there's no benefit to using OllyDbg v1.10 over Immunity Debugger.
You can easily view it using Visual Panels in radare2. Here's a teaser:
First of all, install radare2 from git repository:
$ git clone https://github.com/radare/radare2.git
$ cd radare2
To debug a program with radare2 call it with the debug flag -d:
$ r2 -d /bin/ls
Now the program is opened in debug mode.
"I'd like to see details on how to hook and step into the function
that processes a button click event in a UWP app."
I would suggest using the EventHook Library which is intended to hook global windows user events.This is available as a Nuget Package.
The Project Repo (named as Windows User Action Hook) is available on Github and my fork can be ...
Go to the memory window in Ollydbg. Find the code section (usually .text) of the module you want to break on return to. Right click the memory section and set break-on-access or hit F2. You'll break once execution reaches that memory. You can also change the memory access to read only and you'll get an exception when execution hits that memory segment.
Make sure if you have the correct breakpoint address
issue lm an exe without symbol will be shown as
start end module name
00400000 0040f000 image00400000 (no symbols)
compare the NtHeader->AddresssOfEntrypoint with @$exentry
0:000> r $t0 = image00400000
0:000> ?? ((ntdll!_IMAGE_NT_HEADERS *) @@( poi( @$t0 + 0x3c ...
I wrote some articles (search for radare2) about using r2 for crackmes, and there is a talk section on the official website.
Also you can find useful articles from the blog.
Also, feel free to come ask questions on the irc channel.
I'm not sure I fully understood you, but I'll give it a try anyway.
The following instructions will explain how to achieve something like this:|
radare2 comes with its own webserver. Although at first, it might seems like an overkill, its actually quite useful, especially when you want to debug embedded systems, or simply to execute commands from a remote ...
Yes, you can do kernel debugging using two VMs. You will need to connect their serial ports.
The above is for Windows. OS X setup needs to be done manually: http://www.dcl.hpi.uni-potsdam.de/research/WRK/2011/01/running-wrk-on-mac-os-with-vmware-fusion/index.html
In the connection string ...