I've just started on a project and I'm stuck. The projects goal is to trace the execution of a program. I've looked at Capstone engine, but as far as I can tell it doesn't allow live code execution and stepping. I want something that is able to trace execution, step, convert to assembly, and has an api or other way of other programming with it. GDB is perfect except for the very last part. It has an api for python, but gdb executes it rather than the other way around. So far, the only way I can see of meeting my goal is to write bindings for gdb to another language. Is this possible(seeing as it's a shell and all), or are there any other possible solutions that I'm missing?
To Clarify: Is there a library or framework that is similar to gdb in its functionality?
Is there a library or framework that is similar to gdb in its functionality?
You are looking for libgdb, but that project is dead.
However, lldb may be the answer. From linked page:
The LLDB debugger APIs are exposed as a C++ object oriented
interface in a shared library.
Your question is rather general but I can point to a few examples.
You can set your own breakpoints and then Next Until Breakpoint. The python can tell gdb to next/step/cont in the target via the gdb.execute method. I think this will meet your goal with some python enhancements.
Based on the same idea, you can look at the stack and do check for a particular function. This example shows the general way to feedback information to gdb through the python interface. You can set variables with the python code then use the gdb if/else functionality to make decisions.
I installed LiteIDE and GDB. I opened my Go project in LiteIDE and added a breakpoint to some point in the code. Then i switched back to terminal and ran the project binary that was supposed to envoke the breakpoint and nothing happened. What am i doing wrong?
You have to actually launch the executable from the IDE for breakpoints to mean anything.
Also keep in mind that gdb is mostly meaningless with Go 1.3.x and even more so with 1.4 (dev).
From https://golang.org/doc/gdb:
GDB does not understand Go programs well. The stack management, threading, and runtime contain aspects that differ enough from the execution model GDB expects that they can confuse the debugger, even when the program is compiled with gccgo. As a consequence, although GDB can be useful in some situations, it is not a reliable debugger for Go programs, particularly heavily concurrent ones. Moreover, it is not a priority for the Go project to address these issues, which are difficult. In short, the instructions below should be taken only as a guide to how to use GDB when it works, not as a guarantee of success.
In time, a more Go-centric debugging architecture may be required.
I use this package https://github.com/gostart/debug/ and so far it is the best solution that I have found.
Hope this helps.
I want to write a GUI based debugger wrapped over GDB. Because, I dont want the program to stop after watch points or break points. Instead, it should redirect the details like filename, line number, new value and stuffs to a file and continue execution.
I am pretty bad at scripting. So, I want some starting point to start developing front end for GDB. As far as I googled, this link http://ftp.gnu.org/old-gnu/Manuals/gdb-5.1.1/html_node/gdb_211.html is not much understandable for a beginner in this activity?
Hopefully, I will get help on development in C/C++.
For writing a GDB frontend, you indeed want to use the GDB/MI protocol but perhaps read this up-to-date copy instead of the older one you linked to.
Sample GDB/MI session
(Lightly edited version of this section from the GDB manual)
Launching GDB with the MI Command Interpreter
$ gdb -q --interpreter=mi2
=thread-group-added,id="i1"
(gdb)
File /bin/true
-file-exec-and-symbols /bin/true
^done
(gdb)
Break main
-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004014c0",func="main",file="true.c",fullname="/usr/src/debug/coreutils-8.17/src/true.c",line="59",times="0",original-location="main"}
(gdb)
Run and Breakpoint Hit
-exec-run
=thread-group-started,id="i1",pid="2275"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
=library-loaded,id="/lib64/libc.so.6",target-name="/lib64/libc.so.6",host-name="/lib64/libc.so.6",symbols-loaded="0",thread-group="i1"
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004014c0",func="main",file="true.c",fullname="/usr/src/debug/coreutils-8.17/src/true.c",line="59",times="1",original-location="main"}
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x00000000004014c0",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffde98"}],file="true.c",fullname="/usr/src/debug/coreutils-8.17/src/true.c",line="59"},thread-id="1",stopped-threads="all",core="1"
(gdb)
Continue
-exec-continue
^running
*running,thread-id="1"
(gdb)
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
Quitting GDB
(gdb)
-gdb-exit
^exit
Existing GDB/MI Clients
There are several GDB/MI client implementations in C, C++, Java, Python. I'll list a few that I find easy to read:
The inactive libmigdb project (sample program, public interfaces) -- The good news is that it's an attempt at creating a reusable C library. The bad news is that it's not well maintained, e.g. I think it's missing GDB non-stop mode and catchpoint commands support, features that your use case would likely need.
python-gdb-mi -- Quite readable if you know Python
The C++ GDB/MI client code in QtCreator -- Also quite readable though it's written as part of an abstraction layer to support multiple debugger engines.
You might want to also browse this list of GDB frontends.
Since you already pointed out the gdb/mi interface maybe an existing solution might give you an idea on how to address your needs. Here is a list of existing interfaces. Look at their approaches and how they address the different issues.
Another approach that might be helpful could be automated sessions. Not to discourage you from writing a gdb gui, but such an automation could be a good start to get a feeling for the steps needed and could maybe also used as a start. Maybe generating a session script and starting gdb with it. gdb -x to load a command file.
Here a link concerning automating:
What are the best ways to automate a GDB debugging session?
I hope it helps. Good luck!
Though writing new GUI tools gives you more knowledge, I suggest you to take up eclipe and modify according to your needs. It saves lot of your time as well as more flexible.
Programming a gdb wrapper to achieve your goal is way to much work.
See how you can execute script on breakpoint hits: gdb scripting: execute commands at selected breakpoint
Also take a look a gdb tracepoints: http://sourceware.org/gdb/onlinedocs/gdb/Tracepoints.html
I hope I'm asking this the right way but I am just getting started trying to learn exploit development. I've taken several tutorials and started off using gdb in Linux, which I am somewhat comfortable in. I'm now starting to use Immunity Debugger on Windows and have a question about how to view functions within the gui.
In gdb I could use the commands:
info functions
disas main
and be able to see the main function. My compiled code is unstripped for simplicity.
How can I recreate this in Immunity or OllyDbg? I want to see a list of functions so I can either examine them or set breakpoints on them. I can't seem to figure it out!
Thanks!
This can be achieved programatically in ImmunityDebugger:
module = imm.getModule('calc.exe')
if not module.isAnalysed():
module.Analyse()
functions = imm.getAllFunctions(module.getBase())
# functions is a list of function addresses in calc.exe
There is also another function:
imm.searchFunctionByName('name_to_search')
But in my experience, this is not very reliable. IDA Pro is the better way to achieve this. Its disassembly engine is superior to Ollydbg. You could get the function offets from IDA and then find them in Ollydbg.
Lastly, I would recommend WinDbg if you are doing exploit development. It takes time to learn it, but is more powerful and feature-rich than Ollydbg ( kernel debugging, for instance).
What kind of debugging tools you've been using to debug working binaries?
Is there are debugging toolkits in addition to GDB?
The only reason is that I'm quite new for system debugging and I've been debugging my system service.
Sultan
I'd recommend Valgrind [1]. It's quite useful when dealing with memory leaks and segfaults.
The segfaults can be tracked by letting GDB run (without any breakpoint) and check the backtrace ('bt' command), after the crash.
P.S.: I don't remember if Valgrind is avaliable for other systems, but since you asked about alternatives to GDB, I'm assuming you're on a *nix box.
Have a nice debugging.
[1] http://valgrind.org/
Assuming you are on Linux systems, one of the most valuable tool is valgrind.
I don't really use anything else except for precondition/postcondition check in the code itself (i.e. assertion on methods' input values).