PLT stands for Procedure Linkage Table which is, put simply, used to call external procedures/functions whose address isn't known in the time of linking, and is left to be resolved by the dynamic linker at run time.
GOT stands for Global Offsets Table and is similarly used to resolve addresses. Both PLT and GOT and other relocation information is explained ...
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 ...
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 ...
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 ...
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.
Even stripped libraries still must retain the symbols necessary for dynamic linking. These are usually placed in a section named .dynsym and are also pointed to by the entries in the dynamic section.
For example, here's the output of readelf on a stripped Android library:
[Nr] Name Type Addr Off Size ES ...
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
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 ...
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 ...
ELF itself doesn't specify any kind of checksum. Your link error is likely due to an incorrect edit which changed some offsets within the file. If you don't adjust the offsets, you have to replace a string with a string that is no longer than the original, and you cannot add new fields unless you have a known amount of slack space available.
Use readelf -a ...
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-...
I just stumbled on this project ERESI. The project itself looks quite ambitious and supports mainly Intel and Sparc processors with some support for others. There are lots of tools as well that might come in handy. It does have one specific tool that sounds like if fits the bill exactly and quite a few others that are related:
Evarista: A work-in-...
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 ...