GDB's "No symbol table is loaded" when trying to "strace" - linux

I'm trying to strace a thread (or a process, for that matter) on the system through gdb, using strace -p <pid>.
I get the following message:
No symbol table is loaded. Use the "file" command.
Make static tracepoint pending on future shared library load? (y or [n])
I've seen solutions offering to use file <file-name>, but in my case, when I have no file to run, what do I have to do?
Thanks.

The strace you are looking for is a command-line tool, not a GDB command. Exit GDB to run it.

Related

Debugging an ELF file

I've got this EFL file which I need to debug/step-through. It's a reverse engineering competition. All I need to do is to find out the value of a register at a particular point in time and in a particular place. I used Hopper Disassembler to find out the address of interest.
Here's the problem. I don't know how to debug an ELF file. It's my first time debugging in a Linux environment. Learning how to execute the ELF file itself took me a while. I execute by using
ld-linux.so.2 ./[EFLFILE] [arguments]
Is there a way I can atleast attach a debugger onto the proess? I can't even find it with the ps command. Also, I've heard that it's possible to have remote debugger; to have a debugger running on a windows machine and have the binary to be examined running on a linux.
Could anyone help me achieve just any of this?
Usually an ELF file can be executed as follows:
$ /path/to/elffile [arguments]
To debug it using GDB you can do:
$ gdb /path/to/elffile
Or passing arguments:
$ gdb --args /path/to/elffile arguments...
In your case:
$ gdb --args ./[EFLFILE] [arguments]
Then type run or simly r and press < Enter >.
Type help to get help on the gdb commands.
Note: if your program needs some external libs, before running it, you should define LD_LIBRARY_PATH pointing on the folder containing those libs (export LD_LIBRARY_PATH=/the/path/to/libs)

Search symbols again after setting debug-file-directory

I've established a build process that makes binaries and then separates the debug info from them (build-ids are enabled).
The build can also generate the .gdbinit files with the lines like set debug-file-directory <dir>, so the debugger can find them (there are lots of executables and libraries in the project).
But when I run $ gdb myprogram, gdb can't find the symbols. I have to do (gdb) file myprogram to redo the search for the debug-symbols file. It seems that .gdbinit is executed after opening myprogram.
How to make it automatic?
Basically, .gdbinit file is used to setup debugging environment (add aliases for long commands, load custom commands, setup print modes, etc. ), not a particular debugging session.
Taking a look at gdb startup order and considering that home .gdbinit works ok, it cannot be achieved with local .gdbinit file (order of operations should be set debug-file-directory, file). I think you can modify your build/debug process for using gdb wrapper script with gdb command script (the same as .gdbinit but call it start.gdb for example to avoid confusion):
gdb_x:
#!/bin/sh
gdb -x ./start.gdb "$#"
start.gdb:
# this file is generated for .. by ...
set debug-file-directory <>
set debug-file-directory <>
Or, as a workaround, if you can bare with the fact that commands will run twice:
gdb -x ./.gdbinit <>
which can be avoided with (and deserves again wrapper script):
gdb -iex "set auto-load local-gdbinit off" -x ./.gdbinit <>

keeping the whole gdb output log in file

Is there some way to keep the gdb log in a file.
I found:
$gdb run.o
(gdb) set logging file mylog.txt
(gdb) set logging on
(gdb)r
But it just keeps the logs of commands.
is there any option to have all the logs in a file ?
Yes, and no.
GDB cannot do it because output from the program being debugged is not visible to it.
The poor-man's way to do it is using tee:
gdb <blah> | tee logfile
That will work, but you'll find that the interactive features of GDB are missing (autocomplete, paging, etc.).
My preferred method is to use the logging feature in my terminal. I use "Terminator" with its "logger" plugin enabled, but I'm sure there are other options.
is there any option to have all the logs in a file
From man script:
script makes a typescript of everything printed on your terminal.
It is useful for students who need a hardcopy record of an interactive
session as proof of an assignment, as the typescript file can be
printed out later with lpr(1).

View source for standard Linux commands e.g. cat, ls, cd

I would like to view the source code for a Linux command to see what is actually going on inside each command. When I attempt to open the commands in /bin in a text/hex editor, I get a bunch of garbage. What is the proper way to view the source on these commands?
Thanks in advance,
Geoff
EDIT:
I should have been more specific. Basically I have a command set that was written by someone who I can no longer reach. I would like to see what his command was actually doing, but without a way to 'disassemble' the command, I am dead in the water. I was hoping for a way to do this within the OS.
Many of the core Linux commands are part of the GNU core utils. The source can be found online here
The file you are opening is the binary executables which are the stuff the kernel passes to the CPU. These files are made using a compiler that takes in the source code you and I understand and turns it via a number of stages into this CPU friendly format.
You can find out the system calls that are being made using strace
strace your_command
Most likely you can download the source code with your distribution's package manager. For example, on Debian and related distros (Ubuntu included), first find which package the command belongs to:
$ dpkg -S /bin/cat
coreutils: /bin/cat
The output tells you that /bin/cat is in the coreutils package. Now you can download the source code:
apt-get source coreutils
This question is related to reverse engineering.
Some keyword is static analysis and dynamic analysis
use gdb to check that the binary file have symbol table inside or not. (if binary compile with debugging flag, you can get the source code and skip below step)
observe program behavior by strace/ltrace.
write seudo-code by use objdump/ida-pro or other disassembler.
run it by gdb to dynamic analysis and correct the seudo-code.
A normal binary file can be reverted back to source code if you want and have time. Conversely, an abnormal program is not easy to do this, but it only appear on specific ctf competition. (Some special skill like strip/objcopy/packer ... etc)
You can see assembly code of /bin/cat with:
objdump -d /bin/cat
Then analyze it and see what command can be launch.
Another way of approaching is strings /bin/cat, it is usefull make a initial idea and then reverse it.
You can get the source code of every linux command online anyway :D

gdb in backtrack

I've just tried using gdb on BackTrack Linux and I must say that its awesome. I wonder how gdb in backtrack is configured to act this way.
When I set a breakpoint, all the register values, a part of the stack, a part of the data section and the next 10-15 instructions to be executed are printed. The same happens when I step or next through the instructions.
I find this amazing and would love to have this on my Ubuntu machine too; how could I go about doing this?
They seem to be using this .gdbinit file:
https://github.com/gdbinit/Gdbinit/blob/master/gdbinit
I'm guessing that this is done using a post command hook:
http://sourceware.org/gdb/current/onlinedocs/gdb/Hooks.html#Hooks
inside of a system wide gdbinit:
http://sourceware.org/gdb/onlinedocs/gdb/System_002dwide-configuration.html
which may or may not reference shell commands and/or use gdb python scripts.
try:
strace gdb /bin/echo 2>&1 | grep gdbinit

Resources