Getting the entrypoint
If you have no useful symbol, you first need to find the entrypoint of the executable. There are several ways to do it (depending on the tools you have or the tools you like the best):
$> readelf -h /bin/ls
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Get Ready for an Adventure!
You need a few things for your quest! Let's start at the beginning.
QEMU and GDB
QEMU is an emulator for various architectures. Generally, it's used to emulate an entire PC (i.e. to run a virtual machine). However, for debugging a single program this is not necessary. On Linux, you can use QEMU User-Space emulation.
$ sudo ...
The tool we used for the talk, binviz, is available here: binviz_0.zip.
Some papers are here:
And, there is also an earlier Black Hat talk, in addition to the one I
did with Sergey:
I haven't used it in a while but binviz was written in Visual C# (VS2005
or maybe ...
This project is an interactive binary visualization tool, a radical
evolution of the traditional hex editor. By translating binary
information to a visual abstraction, reverse engineers and forensic
analysts can sift through mountains of arbitrary data in seconds.
Even previously unseen instruction sets and data formats can be easily
located and ...
Let me summarize the links given at https://reverseengineering.stackexchange.com/a/1993/12321 without going into serious disasembly analysis for now.
When the Linux kernel + dynamic linker is going to run a binary with exec, it traditionally just dumped the ELF section into a known memory location specified by the linker during link time.
So, whenever ...
To answer to this question, we have first to rephrase it a bit. The real question can be stated like this:
What are the symbols that cannot be removed from an ELF binary file ?
Indeed, strip removes quite a bit of information from the ELF file, but it could do a bit more (see the option --strip-unneeded from strip or the program sstrip for more about ...
UPDATE: GDB 8.1 has a starti command, as mentioned below by /u/ruslan
Setting a breakpoint on an unmapped address before starting the target process does this, effectively. It's not correct functionality, but rather a side-effect of the failure to set the breakpoint.
(gdb) break *0
Breakpoint 1 at 0x0
Starting program: /home/user/ld.so
Error in ...
The .bss has no content. It's simply a tip to the loader to preallocate some space when starting the program. It will be all 0s at the execution and won't hold any useful information until the program writes to it. After that, you can use a debugger to dump the memory and explore its content.
Check the Wikipedia page for more information.
You can use radare2 or one of the alternatives below to generate a full call-graph in dot format.
First of all, install radare2 from git repository:
$ git clone https://github.com/radare/radare2.git
$ cd radare2
After you've downloaded and installed radare2, open your binary and perform analysis on it ...
Yes, obviously you can. radare2 has built-in features to handle binary headers. This including reading, parsing and modifying the headers of the binary. And this is not different for elf or pe files, it will work great with both.
[*] you ran this binary!
$ r2 -w -nn example.elf
There are a plethora of things programmers do not know about how ELF binaries work internally. And, unfortunately, there's almost no solid references apart from two or three which broadly cover the subject. Many tools (linkers, loaders, assemblers, debuggers, ...) remain a mystery for most of you. When it comes to linkers and loaders, the main reference is ...
The data visualizing tool I saw used in the talk seems to be almost identical if not identical to the BinVis tool available on Google Code. A screenshot of some of the features:
Note: the above is an old version as I could not install the latest on my PC; see Google code site for more.
These are graphic dumps from the source data. I use this extensively, with a hex reader I wrote myself -- it's a great way to quickly locate "data" (see the difference between .text and .data) and larger structures (which often contain repeating or similar data on the same offsets).
The top images show raw data dumped as grayscale information: each byte is ...
It's very easy to prevent the UPX tool to unpack an UPX compressed file. If you take a look to the source code you will see that it checks for the magic string UPX_MAGIC_LE32 in p_lx_interp.cpp. So, I simply changed all matches of the string (in binary chunks) "UPX!" to "AAA!". I copied /bin/ls (ELF64) to another folder and packed with UPX. Then I edited it ...
Seems like relocation. If you look at the addresses in your first listing, you will notice that these addresses are unusually low. That's probably because gdb displays file offsets there (although I have no idea why that is the case for you).
When you run the file, the loader kicks in and maps the sections to the virtual address space of the program, and ...
Note that all of the NOPs end (and the next function begins) at ...C0, ...F0. The compiler and/or linker inserted padding bytes so that the functions begin at 0x10 aligned addresses.
Different compilers / linkers will use different values for these bytes. I've seen 90 (nop), CC (int3), as well as multi-byte NOPs that exactly fill the space ...
The .ctors section is a list of pointers terminated with -1 (0xFFFFFFFF), so it does not make sense to disassemble it. If you rearrange the bytes as data, you get:
__CTOR_LIST__: .long 0xffffffff
__CTOR_END__: .long 0x00000000
So, for whatever reason, the resulting exe does not actually use the .ctors section. I suspect the linker instead placed the ...
Radare2 is also able to collect the callgraph of a program based on its binary only.
Some time ago, I asked this question which is somehow related to yours and one of the author of Radare2 answered:
Recursive traversal disassembling with Radare2?
Yet, if you want a graphical representation of the callgraph here is the way to do:
$> radare2 /usr/bin/...
There're two broad ways in which you can declare JNI functions.
The first is the more obvious way in which the JNI function has to follow a specific naming convention like JNIEXPORT void JNICALL Java_com_app_foo_bar. You can easily identify such functions using readelf.
The other not so obvious way is to use RegisterNatives. Here your functions can have ...
Apart from the classix UPX, you should take a look at Burneye (With its crackers, UNFburninhell and Burndump) and elfuck. They are pretty old, but still interesting.
If you are interested about tricks that can be used, this is a good introduction by aczid, and I would also recommend Binary protection schemes for a more complete overview.
Someone also ...
I wrote https://github.com/REMath/implementations/blob/master/code_examples/plot_hex.py which implements the ngram method presented Conti as well as a clustering component to isolate visual properties.
It was present on the stack before and esp, 0xfffffff0 instruction that aligns the stack to 16 bytes. This instruction doesn't erase the data that was previously at esp (so ecx-4 still points to the return address), but stack pointer points now to possibly different value than at the begining of the function. So there is a need to push the return value ([ecx-...
This is just the ugly AT&T syntax. In Intel syntax it's:
jmp dword ptr [eax*4+0x80509e4]
And yes, it's most likely a jump table.
You can switch objdump to Intel syntax by adding -M intel to the command line.
I'm afraid your intentions to find memory usage may need both static and dynamic analysis. Run-time events can cause more or less memory usage. I will write my general findings about reversing Go binaries, you can choose for your application-specific solution from below.
There is no decompiling tool available for Go language. Although according to this ...
Seems like lscan is written to work with IDA. However, lscan is based on FLIRT signature files which can be also read by radare2 (See the Zignatures section of this answer). There are several things you can do with radare2 to achieve similar results:
Import IDA databases to radare2
You can easily import IDC and IDB files from IDA to radare2 using a simple ...
Ghidra Export Binary Feature
UPDATE AS OF June 2021:
The preliminary release notes list this as a feature for Ghidra 10, which should be released "mid to end of June 2021":
New exporters that write programs imported with the PE and ELF loaders back to their original file layout have been added.
Any file-backed bytes that were modified by the user ...
The short answer is that the .dynsym table is used by the dynamic linker (also referred to as the runtime loader or RTLD) at program load time to determine which DLLs to map into the address space of the program being loaded into memory. As a result, the .dynsym section is mapped to a loadable segment (specifically, the text segment) and therefore included ...
The .bss block started by symbol (also called Uninitialized data segment - bss is an old assembly instruction on an ancient IBM chip) section is supposed to contain global variables and static variables uninitialized or initialized to 0 or NULL. The .bss section is usually non existing until your program starts executing, this is why you can't retrieve its ...