I'm now extending more my x86 Assembly knowledge and one of the best tools for learning is DEBUG. When I was learning Assembly(past 4 years) I was on Windows, but now I'm on Linux Ubuntu and the DEBUG tool is only for Windows. Then I want to know is there is any port or equivalent for Linux.
Remember that I don't want to debug my code, but do things like the command -r, -t, -e...
-r = info registers
-t = stepi
-e = no direct equivalent; taviso wrote a macro providing similar functionality
debug with no args starts up with some blank 64k of memory that you can play around with; GDB doesn't. That really only made sense on DOS anyhow; you'll have to start with some binary.
Maybe assemble some blank slate like so?
$ echo .globl main >a.s
$ echo main: >>a.s
$ for i in {1..65536}; do echo 'int $3'; done >>a.s
$ cc a.s
$ gdb a.out
(gdb) run
gdb is pretty much the debugger on the Linux platform. You don't specify what features you require, but it probably has them :)
I used DEBUG mostly to assemble rather than "debugging"... if that's your goal,
NASM is a good assembler with more similar syntax
Use gdb to then run the code, allow disassembly, and examine memory
gdb - the GNU project debugger is the Linux standard debugger. It is far more powerful than DEBUG (if by that you mean the old DOS tool) and you should really learn at least the basics of how to use it if you are programming on Linux.
Related
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)
When starting gdb from emacs, emacs says that gdb should be started as
gdb -i=mi
The option -i is not defined in the gdb man page. If gdb is invoked from the command line with option -i=mi, it works. So it must be specific to gdb. Where is the documentation for the -i option?
gdb -i=mi is equivalent to gdb --interpreter=mi.
In short, --interpreter=mi makes gdb present a machine-oriented text interface rather than the human-oriented command prompt you get without it. Emacs's gud buffer parses the output from this interface and presents something resembling the normal gdb interface to you.
The --interpreter flag is documented here, and the GDB/MI interface is documented here. That -i is an alias for --interpreter is mentioned in passing here.
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
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
what is the equivalent of dumpstabs -s solaris command in linux?
Regards
ven
I guess this should do the same:
objdump -g
Or maybe
readelf --debug-dump
for ELF files. You can give various options to that last command (see man readelf).
Edit: After reading the manual of objdump, I found the -G option to show the STABS (I guess this is what you want). The manual mentions the following:
This is only useful on systems (such as Solaris 2.0) in which ".stab" debugging symbol-table entries are carried in an ELF section.
So maybe what you want just isn't possible on Linux.