I'm using an Ubuntu 14.04 machine with binary exploitation exercises (learning how to use buffer overflows, write shellcodes, etc).
So far, I've been able to run these programs, written exclusively in C and compiled with gcc, via gdbserver and connect to it with IDA Pro 6.8 remotely.
However, right now there's a program that I'm trying to run and it doesn't hit breakpoints set in IDA. There's clearly communication between the two, and I can execute the program via IDA, but it doesn't stop at any breakpoints I set, including ones in the program's execution flow that would have definitely been hit. I set breakpoints on addresses, so unavailable debugging information can't be the reason.
Also, it works perfectly fine when I debug it with gdb.
I thought it was because I turned on ASLR, but when I turned it back off it still didn't work. What could be the reason?
The program was compiled like this (one file only):
gcc -pie -fPIE -fno-stack-protector -o prog prog.c
In order for break points to work on lines or (not-exported) functions, the program needs to have debugging symbols. Your gcc command line does not include those. In that situation, if you were to create a break point on a memory address, the break point would work; but it does not work for lines and not-exported functions, since the necessary information for the debugger (or the gdbserver stub) is just not available.
To fix, add the -g parameter to your gcc command line.
Related
I'm asking this because I've been given a task which I don't yet know how to handle. You see, we're in a situation where we can execute legacy a.out programs on a virtual machine running a really old linux kernel. We would like the native MinGW gdb to debug the program somehow. It's been proposed that we convert the a.out file into a PE file containing debug symbols and send it to GDB to process, while actually running the UNIX a.out file on the virtual machine. The only available debug symbols that comes with the a.out file is STABS, since the version of GCC used on the VM is very old.
I understand that it's possible to add STABS debug information into a PE file. GCC does it, and I've done experiments with objdump and gdb comprehensively enough to come to to the conclusion that STABS works with MinGW GDB. So how do I achieve it? How did GCC approach it?
Thank you.
I see many tutorials on gdb asking to use -g option while compiling c program. I fail to understand what does the -g option actually do.
It makes the compiler add debug information to the resulting binaries. This information allows a debugger to associate the instructions in the code with source code files and line numbers. Having debug symbols makes certain kinds of debugging (like stepping through code) much easier, if not possible at all.
The -g option actually has a few tunable parameters, check the manual. Also, it's most useful if you don't optimize the code, so use -O0 or -Og (in newer versions) - optimizations break the connection between instructions and source code. (Most importantly you have to not omit frame pointers from function calls, which is a popular optimization but basically completely ruins the ability to walk up the call stack.)
The debug symbols themselves are written in a standardized language (I think it's DWARF2), and there are libraries for reading that. A program could even read its own debug symbols at runtime, for instance.
Debug symbols (as well as other kinds of symbols like function names) can be removed from a binary later on with the strip command. However, since you'll usually combine debug symbols with unoptimizied builds, there's not much point in that - rather, you'd build a release binary with different optimizations and without symbols from the start.
Other compilers such as MSVC don't include debug information in the binary itself, but rather store it in a separate file and/or a "symbol server" -- so if the home user's application crashes and you get the core dump, you can pull up the symbols from your server and get a readable stack trace. GCC might add a feature like that in the future; I've seen some discussions about it.
i am using gcc 4.4.3 on ubuntu 10.4 32bit machine.
i use 'gdb' to debug my code. Since few days i am seeing that whenever i debug code gdb steps into the c library functions used in the code also(like printf,fgets etc). This shows a long list of calls from one function to other.see the attached screen shot.
Previously gdb was working fine just stepping over my own code.
Maybe i am being novice !! But it is sometimes really irritating when gdb shows me numerous lines which i am not interested in the present context.
If someone can guide me as in how to turn off/on this feature and what can be cause of it being switched on on its own(i don't remember doing anything).
Many thanks.
i used to do that previously also but then it never went into any of the lib functions
You (or someone) have installed libc6-dbg package. Before that, GDB couldn't step into libc functions, because they didn't have any debug info. Now they do, and it can.
Either get out of the habit of typing step when you want next, or un-install libc6-dbg.
I'm trying to debug a Windows program compiled using MinGW's gcc that only ever segfaults when run outside of gdb (probably some race condition... lovely.) The problem is, when the program crashes and I'm not running GDB, I can't get a stack trace... I have the option to open up the program in MSVC when it crashes, but MSVC can't read gcc's debugging symbols and so the stack trace it gives me is useless.
Is there a way to get Windows to create a core dump that I can then later open in MinGW's gdb? Alternatively, is there a way to take MSVC's stack trace (which has raw addresses but no symbols) and use gcc to get a human-readable trace?
windows does not create core files (on linux they are dumped by the kernel iirc)
you can try to attach with gdb with the crash dialog opened but I doubt it will work
if you use msvc instead you can create a minidump debuggable in visualstudio but there is no way to create same dump with gcc
google made a software that you may find useful, but I'm not sure it can produce stuff with gcc
http://code.google.com/p/google-breakpad/
or you can set drmingw as jit debugger
drmingw -i
I'm sure it is possible to get something like a backtrace also on mingw, since mingw compiled llvm is able to dump a trace
http://code.google.com/p/backtrace-mingw/
looks like simpler but I've not tested it
compile with -g3 (and if you can -O0)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I am working on C/C++ on UNIX and have often seen core files. Many times the core files are difficult to debug to find the actual cause of core or the segmentation fault. Could you please suggest me an efficient debugger?
For segmentation faults, memory leaks, uninitialized data and such, running your program through valgrind is always a good idea. If you are especially interested in memory leaks, the option "--leak-check=full" pays off.
And yes, learn gdb. It takes a little time, but it's worth it.
I think most C compilers on most flavors of *nix support -g to include debugging symbols within the object files, so if you do:
cc -g -c file1.c
cc -g -c file2.c
cc -g file1.o file2.o -o program
./program
Then when you run program if it crashes it should produce a more easily debugged core file. The first two lines just compile source files (producing .o files), the third line tells the compiler to call the linker to link the source files into an executable (passing -g here may not actually do anything if the linker does not have to do anything special to produce an executable with debugging symbols, but it should not hurt anything), and the last line runs the program. You should make sure that you do not tell the compiler to do optimizations when you are trying to debug (unless you find that it does not have errors unless optimizations are turned on) because optimizations typically make the more difficult to follow.
Since I don't know what platform you are on or what tools you have available (or really even what C compiler you are using) so it is difficult to give more specific advice. You should read the man page (manual) for your complier. From the command line type:
man cc
And that should bring up a manual page that tells you lots of things about the compiler on your system. This may tell you how to tell the compiler to produce more warning messages, which could help you find your errors before even running your programs. (note that some warnings may only be produced if you compile with certain optimizations turned on, so even though you probably won't want to debug the optimized program you may want to compile it with optimizations and extra warnings turned on just to see if they tell you anything).
Your Unix system probably has some type of debugger installed. Most Linux machines set up for C development have gdb installed. gdb can be used to run your program in debug mode or to analyze a core file. If you have gdb you can:
gdb ./program
it will start up ready to run your program. If you do:
gdb ./program ./core
it will behave similarly except that it will be as though you were debugging and your program just crashed. From this state the quickest and most helpful thing you can do is to
(gdb) bt
Here (gdb) is the prompt and bt is a command that says to produce a back-trace. That means a call stack, which shows what function the program was in when the failure happened, and what function called that function, and what function called that function, and on and on up to the first function. This can be confusing because it will often show library functions as the most recent called, but this usually means that you have passed in some bad data somewhere along the way that is causing the problem.
gdb is a large and complex program so if it is on your system you should take the time to read up on it.
If it is not on your system then you should find out what similar tools are. Some of the graphical debuggers (either within an IDE or not) act as front ends to command line debuggers and some even support several different command line debuggers, so if you are able to use one of the graphical debuggers you may not actually have to worry about what actual back end command line debugger is being used.
Use gdb. It is the defacto standard Unix C/C++ debugger and as of version 7.0 has reversible debugging features (you can go backwards in time). These reasons alone make it at least worthwhile to check it out.
I really like Totalview. The parallel debugging features are what make me like it as much as I do.
Generally, gdb is an excellent debugger (though it takes a bit to learn). There are also various frontends, some with a GUI, such as DDD or cgdb.
If you explain where specifically you are having trouble, we may be able to better recommend which debugger will help you most.
As suggested above gdb is an excellent debugger. But in the linux terminal debugging larger projects with gdb is little more complex. Simple reason is it is completely command line interface. So i would suggest kdevelop which internally uses the gdb in graphical manner. This debugging tool helped me a lot in debugging my big projects in very easy manner. Let me know if you need any help in using this tool.