Shulou(Shulou.com)06/01 Report--

The editor will share with you how to analyze binary files on Linux. I hope you will get something after reading this article. Let's discuss it together.

File

What it does: help determine the file type.

This will be the starting point for your binary analysis. We deal with files every day, not all files are executable types, in addition to a variety of file types. Before you begin, you need to know the types of files to analyze. Is it binary file, library file, ASCII text file, video file, picture file, PDF, data file and so on?

The file command will help you determine the type of file you are working with.

$file / bin/ls / bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID [sha1] = 94943a89d17e9d373b2794dcb1f7e38c95b66c86, stripped $$file / etc/passwd / etc/passwd: ASCII text $

Ldd

What it does: print shared object dependencies.

If you have used the above file command on an executable binary, you will certainly see the "dynamic link dynamically linked" message in the output. What does it mean?

When developing software, we try not to recreate the wheel. There is a common set of tasks required by most software programs, such as printout or reading from standard input / open files. All of these common tasks are abstracted into a set of common functions that everyone can use instead of writing their own variants. These commonly used functions are placed in a library called libc or glibc.

How do I find the libraries on which executable programs depend? This is what the ldd command does. Running this command on dynamically linked binaries displays all dependent libraries and their paths.

$ldd / bin/ls linux-vdso.so.1 = > (0x00007ffef5ba1000) libselinux.so.1 = > / lib64/libselinux.so.1 (0x00007fea9f854000) libcap.so.2 = > / lib64/libcap.so.2 (0x00007fea9f64f000) libacl.so.1 = > / lib64/libacl.so.1 (0x00007fea9f446000) libc.so.6 = > / lib64/libc.so.6 (0x00007fea9f079000) libpcre.so.1 = > / lib64/libpcre .so.1 (0x00007fea9ee17000) libdl.so.2 = > / lib64/libdl.so.2 (0x00007fea9ec13000) / lib64/ld-linux-x86-64.so.2 (0x00007fea9fa7b000) libattr.so.1 = > / lib64/libattr.so.1 (0x00007fea9ea0e000) libpthread.so.0 = > / lib64/libpthread.so.0 (0x00007fea9e7f2000) $

Ltrace

What it does: the library calls the tracker.

We now know how to use the ldd command to find a library on which an executable depends. However, a library can contain hundreds of functions. Of these hundreds of functions, which are the actual functions being used by our binaries?

The ltrace command displays all functions that are called from the library at run time. In the following example, you can see the name of the function being called and the parameters passed to the function. You can also see what these functions return on the far right of the output.

$ltrace ls _ libc_start_main (0x4028c0, 1, 0x7ffd94023b88, 0x412950 strrchr ("ls",'/') = nil setlocale (LC_ALL, ") =" en_US.UTF-8 "bindtextdomain (" coreutils ") "/ usr/share/locale") = "/ usr/share/locale" textdomain ("coreutils") = "coreutils" _ _ cxa_atexit (0x40a930, 0,0 0x736c6974756572) = 0 isatty (1) = 1 getenv ("QUOTING_STYLE") = nil getenv ("COLUMNS") = nil ioctl (1 21523, 0x7ffd94023a50) = 0 > fflush (0x7ff7baae61c0) = 0 fclose (0x7ff7baae61c0) = 0 + exited (status 0) + $

Hexdump

What it does: display the contents of the file in ASCII, decimal, hexadecimal, or octal.

This usually happens when you open a file with an application and it doesn't know what to do with it. Try to open an executable file or video file with vim, and all you will see on the screen is garbled.

Opening an unknown file in hexdump can help you see the specific contents of the file. You can also choose to use some command line options to view the file data represented in ASCII. This may help you understand what type of file it is.

$hexdump-C / bin/ls | head 00000000 7f 45 4c 46 02 01 00000000 000 00 | .ELF. | 00000010 02 00 3e 0001 000000 d4 42 40 00000000000 |.. > .B @. | 00000020 4000000000000 f0c3 01 0000000000 | @. | 0000003000000000000 4000 | 38 00 09 0040 00 1f 00 1e 00 |. @ .8. | 00000040 06 000000 05 00000040 000000 000000 000 |. | 00000050 40 0040 000000 000040 0040 000 000 000 | @. | 00000060 f8 01 000000 f8 01 000000 000 f8 01 000000 000 |. | | 00000070 08 000000 000000 00 03 000000 04 000 |. | 00000080 38 02 000000000000 38 02 40000000000 38 02 40000000000000 | 8.00009038 02 400000000001c 0000000000000000000 | 8.00000.000 | $|

Strings

What it does: print a string of printable characters in a file.

If you are just looking for printable characters in binary, then hexdump seems a bit overkill for your usage scenario, you can use the strings command.

When developing the software, a variety of text / ASCII information will be added to it, such as print information, debugging information, help information, errors, etc. As long as this information exists in the binary file, you can dump it to the screen with the strings command.

$strings / bin/ls

Readelf

What it does: displays information about the ELF file.

ELF (executable and chainable file format Executable and Linkable File Format) is the mainstream format of executable files or binary files. It is not only the mainstream file format of Linux systems, but also the mainstream file format of various UNIX systems. If you have used a tool like the file command, which tells you that the file is in ELF format, the next step is to use the readelf command and its various options to further analyze the file.

When using the readelf command, it is useful to have a reference to the actual ELF specification. You can find the specification here.

$readelf-h / bin/ls ELF Header: Magic: 7f 45 4c 46 02 01 00 00 00 Class: ELF64 Data: 2's complement Little endian Version: 1 (current) OS/ABI: UNIX-System V ABI Version: 0 Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x4042d4 Start of program headers: 64 (bytes into file) Start of section headers: 115696 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 9 Size of section headers: 64 (bytes) Number of section headers: 31 Section header string table index: 30 $

Objdump

What it does: display information from an object file.

Binaries are created from the source code you write, which is compiled by a tool called a compiler. The compiler generates machine language instructions relative to the source code, and then CPU performs specific tasks. These machine language codes can be interpreted by mnemonics called assembly language. Assembly language is a set of instructions that can help you understand what is done by a program and ultimately performed on the CPU.

The objdump utility reads binary or executable files and dumps assembly language instructions to the screen. Knowledge of assembly language is essential for understanding the output of objdump commands.

Keep in mind that assembly language is architecture specific.

$objdump-d / bin/ls | head / bin/ls: file format elf64-x86-64 Disassembly of section .init: 00000000402150: 402150: 48 83 ec 08 sub $0x8 mov 0x218e6d% RSP 402154: 48 8b 05 6d 8e 21 00 mov 0x218e6d (% rip),% rax # 61afc8 40215b: 48 85 c0 test% rax,%rax $

Strace

What it does: track system calls and signals.

If you have used the ltrace mentioned earlier, think of strace as similar. The only difference is that the strace tool is not a library that tracks calls, but rather tracks system calls. The system call is where you dock with the kernel to do the job.

For example, if you want to print something to the screen, you will use the printf or puts function in the standard library libc; however, at the bottom, there will eventually be a system call called write to actually print something to the screen.

$strace-f / bin/ls execve ("/ bin/ls", ["/ bin/ls"], [/ * 17 vars * /]) = 0 brk (NULL) = 0x686000 mmap (NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS,-1,0) = 0x7f967956a000 access ("/ etc/ld.so.preload", R_OK) =-1 ENOENT (No such file or directory) open ("/ etc/ld.so.cache") O_RDONLY | O_CLOEXEC) = 3 fstat (3, {st_mode=S_IFREG | 0644, st_size=40661,...}) = 0 mmap (NULL, 40661, PROT_READ, MAP_PRIVATE, 3,0) = 0x7f9679560000 close (3) = 0 > fstat (1, {st_mode=S_IFCHR | 0620, st_rdev=makedev (136,1),...}) = 0 mmap (NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS,-1 0) = 0x7f9679569000 write (1, "R2 RH\ n", 7R2 RH) = 7 close (1) = 0 munmap (0x7f9679569000, 4096) = 0 close (2) = 0 exit_group (0) =? + exited with 0 + $

Nm

What it does: list the symbols in the object file.

If the binaries you are using are not stripped, the nm command will provide you with valuable information embedded in the binaries during compilation. Nm can help you identify variables and functions from binaries. You can imagine how useful this would be if you couldn't access the source code of the binaries.

To demonstrate nm, we quickly wrote a Mini Program, compiled with the-g option, and we will see that the binary is not stripped.

$cat hello.c # include int main () {printf ("Hello world!"); return 0 } $$gcc-g hello.c-o hello $$file hello hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID [sha1] = 3de46c8efb98bce4ad525d3328121568ba3d8a5d Not stripped $$. / hello Hello worldview $nm hello | tail 0000000000600e20 d _ _ JCR_END__ 0000000000600e20 d _ _ JCR_LIST__ 00000000004005b0 recording _ libc_csu_fini 00000000400540 libc_start_main@@GLIBC_2.2.5 _ libc_csu_init U _ 0000000040051d T main U printf@@GLIBC_2.2.5 00000000400490 t register_tm_clones 00000000400430 T _ start 00000000601030 dating _ TMC_END__ $

Gdb

What it does: GNU debugger.

Well, not everything in binaries can be statically analyzed. We did execute commands that run binaries (for analysis), such as ltrace and strace;. However, the software consists of conditions that may result in different alternative paths being executed.

The only way to analyze these paths is to stop or pause the program at any given location in the runtime environment, and be able to analyze the information before moving on.

This is what debuggers do, and on Linux, gdb is the de facto standard for debuggers. It can help you load programs, set breakpoints in specific places, analyze memory and CPU registers, and more. It complements the other tools mentioned above and allows you to do more runtime analysis.

One thing to note is that once you load a program using gdb, you will see its own (gdb) prompt. All further commands will be run at this gdb command prompt until you exit.

We will use the hello program we compiled earlier and use gdb to see how it works.

$gdb-Q. / hello Reading symbols from / home/flash/hello...done. (gdb) break main Breakpoint 1 at 0x400521: file hello.c, line 4. (gdb) info break Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000400521 in main at hello.c:4 (gdb) run Starting program: / home/flash/./hello Breakpoint 1, main () at hello.c:4 4 printf ("Hello world!") Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.6.x86_64 (gdb) bt # 0 main () at hello.c:4 (gdb) c Continuing. Hello world! [Inferior 1 (process 29620) exited normally] (gdb) Q $after reading this article, I believe you have some understanding of "how to analyze binaries on Linux". If you want to know more about it, you are welcome to follow the industry information channel. Thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.