Is it possible to get a complete disassembly (which can act as input to an assembler) of an executable?
When I use otool -tV a.out I get to see only the text section. Other sections like data aren't visible.
When I use gdb, the disassemble command requires a start and an end address. However I do not know how to find out the start and the end address of a binary (say a.out).
I'm trying to disassemble an executable, tinker with the assembly code and then reassemble it.
Is that possible?
It'd also help if one can find out the names of all the sections in a binary.
Try using this command, i remember using it sometime back:
otool -tvV a.out
On Mac, you can install (possibly by homebrew) binutils that includes gobjdump. You can disassemble any binary program once installed. It's open and free.
You can use the Hopper Disassembler
quote:
Hopper is a reverse engineering tool for the Mac, that lets you disassemble, decompile and debug your 32/64bits Intel Mac executables.
It costs $59, but you can download a demo to check if it gets the job done first.
EDIT
It seems you can achieve this with otool as well, according to the manual.
.B -d
Display the contents of the (_^_DATA,_^_data) section.
Also have a look at this short blog post (archive link, original is gone) that describes the mentioned use of otool, and how you can use objdump as mentioned by #Sjlver.
On linux, you can try to use objdump -D myprog
Note that this will work only if the program does not contain irregular control flow. Especially malware is often obfuscated, e.g. by inserting spurious bytes that are then jumped over.
If you're targeting this kind of programs, I've heard that one of the best products to use is IDA pro.
Related
I am trying to write a simple OS, I already wrote a bootloader but now I want to debug it, so I switched from using VirtualBox to QEMU because I saw it had better debugging.
The problem is that after I added the -s parameter to QEMU command and successfully connected via GDB, it says that the symbol table isn't loaded and that I should use the "file" command.
The only difference from what I did to what I saw people on the Internet do, is that they started GDB with gdb vmlinux, but I can't do that because I am not debugging a Linux kernel... so I figured that the issue is that I didn't start GDB with an executable, but using the "file" command on my OS image, and the compiled and linked .out file, tells me it's a "DOS/MBR boot sector", so I can't start GDB with either of them (I tried to do that anyways, but GDB failed).
Help would be appreciated.
EDIT: also, I did assemble the bootloader with the -g and --gstabs+ options.
gdb would like a file so that it can give you symbolic debugging information. For that you will need to give it a file in a format with debug info which corresponds to where your OS ends up in RAM. The "DOS/MBR boot sector" file is a disk image (the BIOS will load part of this into RAM for you, and it will then presumably finish loading code itself).
But gdb will also entirely happily let you do assembly-level debugging; you can just ignore the warning about not having a symbol table, and use the single step instruction, disassemble-from-pc and similar commands:
"disas $pc,+32" disassembles 32 bytes from the current PC
the display command prints after execution stops, so "disp /3i $pc" will print the next 3 instructions every time gdb gets control
"stepi" and "nexti" do single-instruction step/next ("step" and "next" are source-line stepping and require debug info)
How can I use Whole Program Optimization feature in Free Pascal 2.7.1 on Windows?
I get this error:
Project1.dpr(92,1) Fatal: Cannot find "nm.exe" or "" to extract symbol
liveness information from linked program
The problem is the WPO is trying to extract symbols from your executable using NM. NM is not available for Windows.
The good news is, Windows has DumpBin instead. I think you can use this directly in place of NM.
I'm studying "Compilers" and we work on Flex to program.
I create *.lex files (with any editor), convert them into lex.yy.c via flex, and then compile to a.exe using gcc.
Writing lex code in an editor like Notepad/Codeblocks/... is not only hard because everything is just BLACK, but also there is no debugging system.
The gcc compiler does tell about errors, but what i'm looking for is something i can go line by line with the code (in runtime) and see what's going on with the variables. Like the command F10 in Visual Studio.
Does anybody know a suitable program for this? Thanks alot
Concerning hightlighting, using gedit(The default GUI editor on Ubuntu and some other Linux variants) or even vim will provide that for you, you don't have to use plain notepad.
As for the debugging, yes there's what's called the GNU Debugger (aka GDB) which allows you to do typical debugging jobs after you've compiled your code, you can step line by line and examine certain variable values.
Before doing that, first compile your program with the gcc flag -g to add debug symbols to the complied result, then run gdb yourProgramName, this will run GDB and you'll be able, using certain commands, to do whatever debugging tasks you want.
I once wrote a little guide to help people get started with GDB, it might be useful.
I can't find a way for cgdb to disassemble a binary and show the assembly code with the current instruction in the code window. Is this possible and what command should I use? I'm using Mac OS X and got cgdb from the homebrew repository.
display/i $pc shows disassembly always for the current instruction, in the console window.
To show disassembly for more instructions, prefix i with the number of instructions.
For example,
display/5i $pc
shows disassembly always for the next 5 instructions.
A recent update (Feb 2017) to cgdb makes it possible to do this. You will need cgdb version 0.7.0 or newer. (At the time of writing this is the latest release). You may need to compile this from source yourself given how recent it is.
More details on adding disassembly support can be found here:
https://github.com/cgdb/cgdb/issues/44
To view the disassembly in cgdb hit esc and type :set disenter.
To go back to the source (if available), repeat this, except type :set nodis.
I am working on MacOS to defuse a binary bomb and find "gdb -tui" will be helpful. Than I found "cgdb" can make code colorful. But what we want to see is show disassembled code on the code window, the answer above only show the code line by line or only changeless lines.
Unfortunately, I find a post said that "the cgdb does not support assembly display (yet)."
https://groups.google.com/forum/#!topic/cgdb-users/E-jZCJiBAQQ
Sorry guys, cgdb does not support assembly display (yet). It's a
frequently requested feature, and when we get a little more time to
work on cgdb we will probably add this.
Starting cgdb with the -tui option is a bad idea -- the TUI (text user
interface) is an alternative curses interface to gdb, not a part of
cgdb. It will not play nice with cgdb.
Mike
--
Mike Mueller
Well, it's 12/11/15, but it seems still couldn't show the assembly code on code window like gdb in tui mode.
What is the need/use of 'symbols' in the Microsoft debugger?
I spent some time trying to figure out the debugger a while back and never was able to get it making any sense (I was trying to debug a server hang...). Part of my problem was not having the proper 'symbols'.
What are they? And why would I need them? Aren't I just looking for text?
Are there any better links out there to using it than How to solve Windows system crashes in minutes ?
You need symbols in order to translate addresses into meaningful names. For example, you have locations on your stack at every function call:
0x00003791
0x00004a42
Symbols allows the debugger to map these addresses to methods
0x00003791 myprog!methodnamea
0x00004a42 myprog!methodnameb
When you build a debug version of a program, the compiler emits symbols with the extension .PDB. It also contains line information so you can do source code debugging, etc..
You need to set your symbol search path correctly for the debugger to pick this up. IN the command window you can do
.sympath c:\symbols;c:\temp\symbols
in order to have it search for the .PDB in these directories. It will also look in the same directory that the executable is ran from.
It also might be helpful to use the Microsoft public symbols server so that you can resolve OS binaries such as NTDLL, GDI, etc.. with this path at the beginning:
.sympath SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols;c:\symbols
You will need to create c:\websymbols first.
On the Windows binary architecture, the information needed for debugging (function names, file and line numbers, etc.) aren't present in the binary itself. Rather, they're collected into a PDB file (Program DataBase, file extension .pdb), which the debugger uses to correlate binary instructions with the sorts of information you probably use while debugging.
So in order to debug a server hang, you need the PDB file both for the server application itself, and optionally for the Windows binaries that your server is calling into.
As a general note, my experience with WinDbg is that it was much, much harder to learn how to use compared to GDB, but that it had much greater power once you understood how to use it. (The opposite of the usual case with Windows/Linux tools, interestingly.)
If you just have the binary file, the only info you can typically get is the stack trace, and maybe the binary or IL(in .NET) instructions. Having the symbols lets you actually match that binary/IL instruction up with a corresponding line in the source code. If you have the source code, it also lets you hook up the debugger in Visual Studio and step through the source code.