I have just started using KDbg and am having a hard time finding the answer to my question. I open a file in KDbg (I opened an executable written in assembly), there is a pop up that says
GDB: Reading symbols from /home/myputer/Desktop/ASMdirectory/chapter5/eatsyscall/eatsyscall...done.
How do I get the option to run the program in the debugger and add breakpoints and etc. It doesn't allow me to click the button to run the program or add any breakpoints, is there an issue here? Am I missing a step? Thanks in advance. BTW I'm using Linux(Ubuntu) and NASM for my assembler.
What are the versions of software you are running?
For example I am running
Ubuntu 12.04,
kdbg 2.5.0 (KDE Development Platform 4.8.5),
gdb 7.4-2012.04,
nasm 2.09.10
You are using Duntemann's book, yes?
I am assuming you changed SECTION .txt to SECTION .text because
when GDB attempts to read symbols it reports "done" instead of "Can't find any code sections in symbol file"
I would recommend using gdb directly instead of kdbg. I do not know of a way to get kdbg to show disassembled code or list (or how to send any gdb commands directly). I think the best that can be done is:
Run kdbg
Open the executable
Switch to the Breakpoints tab
Enter "_start" (which I believe is the only visible symbol you have) in the edit box.
Hit the "Add Breakpoint" button
Hit the "Run" button
Execution should have broken at _start
Switch to the Registers tab
Hit the "Step into by instruction" button to walk through your code
Kdbg does not seem to be able to restart execution. It seems the program must be killed then run again.
Related
If I try to start debugging through the command "Open" of x64dbg, debugging stops without ever starting and a series of missing DLL errors are shown on the screen.
If I just open the program from WIN and THEN I use the attach command by selecting the process, debugging works.
Unfortunately I wanna "investigate" from the moment the program starts and not when it is already started.
How can I solve it ?
You need some anti-anti-debugging plugins (such as ScyllaHide) for x64dbg mentioned in this page to counter anti-debugging attempts and do some patching if needed:
https://github.com/x64dbg/x64dbg/wiki/Plugins
i coded a big project that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs. I searched a long time to find the heap error, but didnt find anything. The problem is i need the running .exe of the programm, so i wanted to ask if there is a possibility to link the windows debugger to the .exe so it always starts with it.
If it doesn't crash right away, maybe this helps:
You can run the executable.
Open your solution in visual studio. Make sure it's the same build.
Open the DEBUG menu and click attach to process.
A window will open, listing all processes that are running. Select the executable that's crashing
Click the DEBUG menu again and select Exceptions (ctrl-alt-E)
Make sure the checkbox "Thrown" is checked for Common Language Runtime Exceptions
Now crash your application.. It will halt at the line that causes it.
Also look for environment directives. like #IF DEBUG #END IF. or #IF RELEASE That kind of stuff. Tricked me a couple of times too..
Good luck. Hope this helps!
You can do various things. First make sure you have a "big out try block" in main. i.e. put the main logic in a try can catch exceptions and report these clearly. This probably isn't what's happening in your case.
You can attach a debugger - including Visual Studio, to a running process - see the "Attach to process" option under the debug menu. If it's built with debug symbols, which you can do, even for release code this may help. If it's optimised you may find it difficult though.
Finally, you could generate a crash dump and inspect that after it's failed. See docs on MiniDumpWriteDump. There are several examples on its usage. Or you can install an abort handler: See here. This mentions _set_abort_behavior which if invoked with _CALL_REPORTFAULT will generate a crash dump too.
In lldb command line, I can stop execution of a program (which has no debug symbols) with the --stop-at-entry option by writing:
(lldb) target create /bin/ls
Current executable set to '/bin/ls' (x86_64).
(lldb) process launch --stop-at-entry
Process 22250 launched: '/bin/ls' (x86_64)
Process 22250 stopped
* thread #1: tid = 0xc46fa, 0x00007fff5fc01028 dyld`_dyld_start, stop reason = signal SIGSTOP
frame #0: 0x00007fff5fc01028 dyld`_dyld_start
dyld`_dyld_start:
-> 0x7fff5fc01028: popq %rdi
...
I would prefer, however, to work in the Xcode (5) IDE for lldb. Is the same thing possible there? I can successfully attach to a process through Menu Debug->Attach to Process-> By Process Identifier or Name. If you enter an application name there, lldb will take over that process as soon as it is launched. However, I see no way of stopping execution when the program starts up, i.e. the equivalent of --start-at-entry. Nor do I see a way of entering the respective commands in the lldb window within the IDE, as the application is not launched yet.
Is this possible in the IDE?
Not sure what you are trying to do, but lldb does have a setting to stop on shared library loads:
(lldb) settings set target.process.stop-on-sharedlibrary-events 1
which will cause the program lldb is debugging to stop when a new shared library gets loaded. Not much goes on in the process before the first shared library load, so this will catch it pretty early on.
You can put lldb Xcode-specific setting commands in ~/.lldbinit-Xcode file and they will only apply to lldb instances called from Xcode.
This helps keeping separate settings.
From lldb(1):
FILES
lldb will read settings/aliases/commands from three files at
startup, if they exist.
First, it will read a ~/.lldbinit-debugger command file. If you are
using the lldb command line interface, this is ~/.lldbinit-lldb. If
you are using lldb inside a GUI debugger like Xcode this will be
~/.lldbinit-Xcode.
Entirely doable, at least under Xcode 7.
In an existing Xcode project, create a new schema. In the schema settings, under "Run", specify "Other executable" and choose the one you want. In schema properties, you may also specify command line, working directory, custom environment, etc...
Neither target.process.stop-on-sharedlibrary-events nor settings show target.process.stop-on-exec was having the desired effect for me.
Starting at the very bottom of the stack, I saw _dyld_start, dyldbootstrap::start, and dyld::_main.
Creating a symbolic breakpoint for dyld::_main, specifying the module as dyld, worked for me to get the debugger very early in the startup process.
Trying to set breakpoints on the first two functions did not work for me. I believe that may have something to do with dyld rebasing itself inside that second function: the code isn’t running where the debugger expects it to be in memory until the third frame.
Is there a way to connect gdb to hopper, then load a dylyb that is loaded by an app and then run the app while stepping through the dylib code? is there a way to do this?
Today (2020) actually you can debug dylibs by opening them in a separate window before starting debugger. When you go back in the callstack window it shows the actual code in the window of dylib. You can also place breakpoints and do whatever you want in it.
For debugging to work you should remove the codesigning of the main executable.
I asked the developer and got a reply indicating that this feature (debugging a dylib), is not available in the current version.
The best way to go for now seems to be to use the available tools to find the right place to edit the code and then reassemble it.
Is there a way to follow a program's execution through DLL code in hex?
For example, I want to see what sections have just been read when I press a button. It has to work for x64 DLL's.
Thanks!
Yes you load the process into debugger and single step it.
Load the project in visual studio.
Press 'Play' or F5 to start the program in the debugger.
You will need to eventually halt execution sometime so you can start stepping through code or assembly code. You can do this by inserting a breakpoint, or breaking the execution by hitting the break command in the visual studio IDE.
Once halted, you can right click in the code view window, and select "Show Disassembly". Then it will show you the machine instructions.
Also in the watch window in the visual studio debugger, the right click pop up menu has an option to display all variables as hexidecimal. I'm beginning to prefer hex myself lately, because I can see invalid memory patterns easier.
You can use the tool at http://ircdb.org to log function calls arbitrary DLLs.
It's name is SocketSpy, because initially it was created for tracing winsock.dll only, but it does allow you to trace other dlls.
From http://fixunix.com/programmer/95098-tracing-library-dll-calls-win32.html
Use Option->Default Break Point List
Menu to add or remove soft breakpoints
from attached DLLs. Put soft
breakpoints only at function you need
to maximize execution time.
Soft breakpoint means that socketspy
does not stop at this breakpoint, only
log breakpoint information. Hard
breakpoint means that socketspy DOES
STOP at this breakpoint, and
Breakpoint dialog is opened. Specify
what calls should be captured ALL,
FROM EXE FILE or from DLLs (Combobox).
Specify log file File->Open Log File
menu if you want to save function
DLLs' calls into the text file, enable
logging (check box).
Then select a new or already action
process (Select Process button). The
tool can be used in NT/2000/XP only
Alternatively, there is StraceNT, which can trace arbitrary Dlls. It is available for free from http://www.intellectualheaven.com/default.asp?BH=projects&H=strace.htm
I've not used it, but I once stumble upon an Intel tool, which samples the context of the Instruction Pointer, and is able to use symbol files to convert IP to an actual function name... VTune maybe?
I guess there might be other such tools
UPDATE: aka. "statistical profilers"...
Debugging using IDE does not show you the assembly language equivalent of the execution of an IL instruction. You need to write your own hooks to a proper disassembler.