As an example of good practice, the process of reversing a program first needs to start with proper identification. Let's start with file:
It is a 32-bit ELF file-type. ELF files are native executables on Linux platforms.
Next stop, let's take a quick look at text strings with the strings command:
This command will produce something like the following output:
/lib/ld-linux.so.2
libc.so.6
_IO_stdin_used
puts
__libc_start_main
__gmon_start__
GLIBC_2.0
PTRh
UWVS
t$,U
[^_]
hello world!
;*2$"(
GCC: (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
crtstuff.c
__JCR_LIST__
deregister_tm_clones
__do_global_dtors_aux
completed.7209
__do_global_dtors_aux_fini_array_entry
frame_dummy
__frame_dummy_init_array_entry
hello.c
__FRAME_END__
__JCR_END__
__init_array_end
_DYNAMIC
__init_array_start
__GNU_EH_FRAME_HDR
_GLOBAL_OFFSET_TABLE_
__libc_csu_fini
_ITM_deregisterTMCloneTable
__x86.get_pc_thunk.bx
_edata
__data_start
puts@@GLIBC_2.0
__gmon_start__
__dso_handle
_IO_stdin_used
__libc_start_main@@GLIBC_2.0
__libc_csu_init
_fp_hw
__bss_start
main
_Jv_RegisterClasses
__TMC_END__
_ITM_registerTMCloneTable
.symtab
.strtab
.shstrtab
.interp
.note.ABI-tag
.note.gnu.build-id
.gnu.hash
.dynsym
.dynstr
.gnu.version
.gnu.version_r
.rel.dyn
.rel.plt
.init
.plt.got
.text
.fini
.rodata
.eh_frame_hdr
.eh_frame
.init_array
.fini_array
.jcr
.dynamic
.got.plt
.data
.bss
.comment
The strings are listed in order from the start of the file. The first portion of the list contained our message and the compiler information. The first two lines also show what libraries are used by the program:
/lib/ld-linux.so.2
libc.so.6
The last portion of the list contains names of sections of the file. We only know of a few bits of text that we placed in our C code. The rest are placed there by the compiler itself, as part of its code that prepares and ends the graceful execution of our code.
Disassembly in Linux is just a command line away. Using the -d parameter of the objdump command, we should be able to show the disassembly of the executable code. You might need to pipe the output to a file using this command line:
objdump -d hello > disassembly.asm
The output file, disassembly.asm, should contain the following code:
If you notice, the disassembly syntax is different from the format of the Intel assembly language that we learned. What we see here is the AT&T disassembly syntax. To get an Intel syntax, we need to use the -M intel parameter, as follows:
objdump -M intel -d hello > disassembly.asm
The output should give us this disassembly result:
The result shows the disassembly code of each function. In summary, there were a total of 15 functions from executable sections:
Disassembly of section .init:
080482a8 <_init>:
Disassembly of section .plt:
080482d0 <puts@plt-0x10>:
080482e0 <puts@plt>:
080482f0 <__libc_start_main@plt>:
Disassembly of section .plt.got:
08048300 <.plt.got>:
Disassembly of section .text:
08048310 <_start>:
08048340 <__x86.get_pc_thunk.bx>:
08048350 <deregister_tm_clones>:
08048380 <register_tm_clones>:
080483c0 <__do_global_dtors_aux>:
080483e0 <frame_dummy>:
0804840b <main>:
08048440 <__libc_csu_init>:
080484a0 <__libc_csu_fini>:
Disassembly of section .fini:
080484a4 <_fini>:
The disassembly of our code is usually at the .text section. And, since this is a GCC-compiled program, we can skip all the initialization code and head straight to the main function where our code is at:
I have highlighted the API call on puts. The puts API is also a version of printf. GCC was smart enough to choose puts over printf for the reason that the string was not interpreted as a C-style formatting string. A formatting string, or formatter, contains control characters, which are denoted with the % sign, such as %d for integer and %s for string. Essentially, puts is used for non-formatted strings, while printf is used for formatted strings.