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.
Related
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.
I have a x86_64 machine, and it can run IA32 process because I have installed a 32bits library. Now I want to know what's the platform that a running process is using? 64bits or 32bits?
The only way I can access the process is a ptrace system call; I don't have executable file (like I can just execute the file but I don't have read and write permissions), so I can't get the ELF header.
The OS I'm using is Ubuntu 14.04 LTS.
I don't want to get executable file, and then analyse the ELF format. The ONLY WAY I can access the process is ptrace, or other system calls same as ptrace if you know, please tell me. Because I want to analyse the process in a C program.
This was also asked on https://unix.stackexchange.com/questions/106234/determine-if-a-specific-process-is-32-or-64-bit, with limited success / viability for detection methods other than checking ELF headers after getting to them in various ways.
Looking at /proc/<pid>/maps for 64-bit addresses looks viable. So does checking the bitness of /proc/<pid>/exe:
$ file - < /proc/$(pidof a.out)/exe
/dev/stdin: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=ff6b5084918be4e4daf7e4315fa4d6dd6a039ae7, for GNU/Linux 4.4.0, with debug_info, not stripped
(Or file -L to follow symlinks. If you just use file /.../exe, it tells you symbolic link to /tmp/a.out.)
Note that files in /proc track the actual inode, so replacing /tmp/a.out with a different executable does not throw this off. Opening it for reading will open the actual executable that this process has mapped, separate from the name it would report via a readlink() system call. If that inode has no directory entries anymore, file will report symbolic link to /tmp/a.out (deleted), but opening for reading will still get the contents. And renaming a.out will get the kernel to report the new name as the symlink, like /tmp/bar.
This answer previously suggested looking at /proc/<pid>/personality, but the difference I was seeing was that a 32-bit process had the READ_IMPLIES_EXEC bit set. That's likely because I built a 32-bit executable from asm sources I had been playing with at the time, without the .note.GNU-stack,"",#progbits that overrides the default of executable stacks, previously implemented by making all pages executable: Unexpected exec permission from mmap when assembly files included in the project
A 32-bit executable compiled by gcc -m32 has personality 00000000, same as 64-bit /bin/sleep. So this isn't a useful detection mechanism, unfortunately. I was hoping that 32-bit processes would have some bits set like ADDR_LIMIT_32BIT, but apparently that's implicit for a 32-bit process, perhaps as part of the "execution domain" like PER_LINUX32.
I got 00400000 (just READ_IMPLIES_EXEC) for a 32-bit process with executable stacks (and everything else). (And 00440000 when I had it stopped in a debugger.) The proc(5) man page says it tells you the personality as set by personality(2).
Kernel source for personality bit-numbers: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/personality.h
glibc's copy: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/sys/personality.h;hb=HEAD
Mostly leaving this part of the answer here in case the part about decoding personalities is useful to future readers. It's not relevant to finding the bitness of a running process.
Try using xocopy to create a copy of the executable in question and dump the ELF header from the copy created.
This tool and the problem you are describing was discussed elsewhere and that discussion may be helpful to you as well.
I have seen a document here http://www.codeproject.com/Articles/3472/Finding-crash-information-using-the-MAP-file. This example is all about crash seen in Windows file? I am looking for the same mathematics that has been done here for the crash generated on Linux systems. If I get the crash on Linux, then how will I debug the issue in the similar lines like Microsoft document http://www.codeproject.com/Articles/3472/Finding-crash-information-using-the-MAP-file. Please help?
Is load address and the code segment address are same in Linux? what is the following in Linux as mentioned in the link "The first part of the binary is the Portable Executable (PE), which is 0x1000 bytes long."?
PE is windows format. Linux uses ELF. Of course you can parse ELF manually, but you shouldn't - gdb could do that for you. Even more, you can use addr2line utility to map address to file/line in source code (of course both of these will require debug build).
Map files are rarely used in linux - it usually just a part of debug executable. It could be dumped from debug build, however, but it don't have too much practical value.
Also, take a look at How to use addr2line command in linux
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)
I've been trying to make GNU gdb 6.5-14 to use the source code embedded on the object file when debugging, instead of scanning some directories for it.
The main reason is that I develop for an embedded platform and I cross compile, which means that all the source is in my computer.
I read about the -ggdb3 flag, that includes a lot of extra info, including the source code. So I started compiling with that flag.
Doing a objdump -S src/lib/libfoo.so indeed prints out all the source code with the assembly code intermixed with the source code, so I'm guessing that it does indeed contain that info.
The only thing is that GDB does not print it, unless I run from a nfs mounted version of my workspace that contains the source.
Does anyone know how can I instruct gdb to look in the object file for code instead of relying on external files?
Employed Russian is correct -- gcc never embeds source code in object files.
What it does do (with any -g setting) is add paths to where the source file can be found.
GDB can use these paths to find the source files. And if you happen to set up the exact same paths on your embedded file system as the paths where you keep your source code on the host system, you can trick gdb into finding them.
Your guess about what -ggdb3 does is totally incorrect; the object files do not contain the source. You can prove that by running 'strings -a libfoo.so'.
Your best bet is to learn how to use remote debugging -- you can then use GDB from host (which has access to all the sources); with an added advantage that you need much less memory on target. See gdbserver in "info gdb".