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.
Related
I want to retrieve the executable from a core dump and the output of any linux package used to get this information should contain execfn in it's output.
Here are the following things which I have tried so far :
$ file kms
kms: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/test', real uid: 1000440000, effective uid: 1000440000, real gid: 0, effective gid: 0, execfn: '/test', platform: 'x86_64'
The file command only works for specific cores and it's not a generic solution because some core dump gives following output.
$ file ss
ss: ELF 64-bit LSB core file x86-64, version 1 (SYSV), too many program header sections (6841)
gdb command doesn't work for all core dumps in the same manner. The output using gdb command is inconsistent. The output received by gdb command for some core dump is not the same as strings command.
$gdb kms
Core was generated by `/test'.
I even tried strings package and I think it gives proper output but the format doesn't contain execfn for it to be used in my solution
$ strings kms | grep ^/ | tail -1
/test
Can anyone please suggest any linux package which will help me in retrieving executable from core dump which contains execfn in it's output.
Try running the file(1) command on your core(5) file. But that requires your core file to be complete. See below and gcore(1) with strace(1) and ptrace(2).
If your ELF executable (see elf(5)) was built with DWARF debugging information then you should have enough information in your core file. See also gdb(1) and this answer.
DWARF debugging information is obtained by compiling and linking your program -if it was compiled with GCC (or with Clang) so using a recent gcc, g++, gfortran, clang, clang++ command - with the -g (or -g2 ....) flag.
Be aware of setrlimit(2). You may need to use the ulimit builtin of GNU bash (see bash(1) and the documentation of GNU bash...), or the limit builtin of zsh to increase the core size file limit.
If your core dump limit size (i.e. RLIMIT_CORE for setrlimit) is too small, it is preferable to raise it and run again your program. A good developer could disable core dumps in an executable. My guess (perhaps wrong) is that a too small core limit size might be consistent with your observations.
If your interactive Unix shell is something else that /bin/bash (e.g. fish) be sure to read its documentation. See also passwd(5), ps(1) -to be used as ps $$, pstree(1), top(1).
See also proc(5). You might try cat /proc/$$/limits or /bin/cat /self/limits in your terminal before running your program there. Perhaps /bin/cat /proc/version could be needed to understand more.
Your Linux kernel can also be configured to avoid core dumps. Ask for details on kernelnewbies and read more about SE Linux. Some Linux kernels accept gzcat /proc/config.gz as root, but other don't, to query their configuration. You could need root access with sudo(8) or su(1). See credentials(7).
On Linux, you might be interested by Ian Taylor libbacktrace. RefPerSys and GCC are using it.
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
As the title says, I am looking for a debugger that works on x86 Linux that can help find ROP gadgets, which are small pieces of assembly instructions. When I'm on Windows I use Ollydbg because it has a "Search for Sequence of Commands" utility but I have yet to find a similar debugger for Linux. Tried Evan's Debugger but it didn't have a way of searching the assembly instructions. Ideas?
ROP Gadget has an -asm command line arg ("Search a specific instructions on exec segment") and supports ELF binaries.
I know a good one from here: https://github.com/0vercl0k/rp/downloads
The linux86 version is okay, but I'd suggest downloading the win-x64 version.
It's said to be better.
After you've downloaded it, type these commands in the terminal:
sudo mkdir /opt/rp
sudo mv rp-lin-x64 /opt/rp/
stat -c %a /opt/rp/rp-lin-x64
sudo chmod 755 /opt/rp/rp-lin-x64
sudo ln -s /opt/rp/rp-lin-x64 /usr/bin/rp64
I have a file called commanKT and want to run it in a Linux terminal. Can someone help by giving the command to run this file? I tried ./commonRT but I'm getting the error:
"bash: ./commonrt: cannot execute binary file"
[blackberry#BuildMc MainApp]$ ls -al commonKT
-rwxrwxr-x. 1 sijith sijith 10314053 Feb 27 16:49 commonKT
To execute a binary, use: ./binary_name.
If you get an error:
bash: ./binary_name: cannot execute binary file
it'll be because it was compiled using a tool chain that was for a different target to that which you're attempting to run the binary on.
For example, if you compile 'binary_name.c' with arm-none-linux-gnueabi-gcc and try run the generated binary on an x86 machine, you will get the aforementioned error.
To execute a binary or .run file in Linux from the shell, use the dot forward slash friend
./binary_file_name
and if it fails say because of permissions, you could try this before executing it
chmod +x binary_file_name
# then execute it
./binary_file_name
Hope it helps
The volume it's on is mounted noexec.
:-) If not typo, why are you using ./commonRT instead of ./commonKT ??
It is possible that you compiled your binary with incompatible architecture settings on your build host vs. your execution host.
Can you please have a look at the enabled target settings via
g++ {all-your-build-flags-here} -Q -v --help=target
on your build host? In particular, the COLLECT_GCC_OPTIONS variable may give you valuable debug info. Then have a look at the CPU capabilities on your execution host via
cat /proc/cpuinfo | grep -m1 flags
Look out for mismatches such as -msse4.2 [enabled] on your build host but a missing sse4_2 flag in the CPU capabilities.
If that doesn't help, please provide the output of ldd commonKT on both build and execution host.
This is an answer to #craq :
I just compiled the file from C source and set it to be executable with chmod. There were no warning or error messages from gcc.
I'm a bit surprised that you had to 'set it to executable' -- my gcc always sets the executable flag itself. This suggests to me that gcc didn't expect this to be the final executable file, or that it didn't expect it to be executable on this system.
Now I've tried to just create the object file, like so:
$ gcc -c -o hello hello.c
$ chmod +x hello
(hello.c is a typical "Hello World" program.) But my error message is a bit different:
$ ./hello
bash: ./hello: cannot execute binary file: Exec format error`
On the other hand, this way, the output of the file command is identical to yours:
$ file hello
hello: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
Whereas if I compile correctly, its output is much longer.
$ gcc -o hello hello.c
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=131bb123a67dd3089d23d5aaaa65a79c4c6a0ef7, not stripped
What I am saying is: I suspect it has something to do with the way you compile and link your code. Maybe you can shed some light on how you do that?
The only way that works for me (extracted from here):
chmod a+x name_of_file.bin
Then run it by writing
./name_of_file.bin
If you get a permission error you might have to launch your application with root privileges:
sudo ./name_of_file.bin
Or, the file is of a filetype and/or architecture that you just cannot run with your hardware and/or there is also no fallback binfmt_misc entry to handle the particular format in some other way. Use file(1) to determine.
your compilation option -c makes your compiling just compilation and assembly, but no link.
If it is not a typo, as pointed out earlier, it could be wrong compiler options like compiling 64 bit under 32 bit. It must not be a toolchain.
full path for binary file. For example: /home/vitaliy2034/binary_file_name. Or
use directive "./+binary_file_name".
'./' in unix system it return full path to directory, in which you open terminal(shell).
I hope it helps.
Sorry, for my english language)
1st login with su
su <user-name>
enter password
Password: xxxxxx
Then executer command/file, it should run.
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.