Some interesting CTF stuff that did happen to me, however, is that I got to speak with Invisigoth again, @tlas for the first time in person, and I actually met Mezzendo on the shuttle ride to the Riv.  Getting to speak with these guys is like somebody from the deep South having a conversation with a NASCAR driver or WWE wrestler.  I try not to get all geeked out by other people because, after all, they are just other people.  But it was great to get to interact with them in person rather than virtually.  They were all very personable and seem glad to talk to me.  Unfortunately, although DefCon is a great place to met these guys, their extra time is definitely limited.  Maybe next year I’ll get into a few of the parties and have a better chance to interact with them.

So, congratulations to Sk3wl0fr00t for their domination of so many outstanding teams.  Of course, from reading @tlas’ recap it looks like they have lit the fire under l@stplace and I’m willing to bet that we have not heard the l@st of them.  I do think, however, that this just means that the competetion is going to become stiffer each year that passes.  This will also put pressure on Kenshoto to keep coming up with outstanding and ground-breaking scenarios for these competitions.

One thing that did catch my eye while I was walking around DefCon was a flier for a $100,000 CTF in South Korea.  For some reason I cannot find the flier now but I guess it is similar to the April competition that was written up on The Dark Visitor back in March.  I have a feeling that we are going to see this turn into big competitions like we have seen with console gaming.  Imagine a circuit where you just do CTF for a living.  It seems like a good way to quickly base and build up your skills.  And, when all is said and done, back to the corporate world for damn fine consulting fees.  Well, we can all dream, right?!!!!

Go forth and do good things,

Don C. Weber

Go forth and do good things,

Don C. Weber

bt hello # nasm -f elf hello.s
hello.s:1: error: attempt to define a local label before any non-local labels
hello.s:1: error: parser: instruction expected
hello.s:2: error: attempt to define a local label before any non-local labels
hello.s:2: error: parser: instruction expected
hello.s:3: error: attempt to define a local label before any non-local labels
hello.s:4: error: attempt to define a local label before any non-local labels
hello.s:4: error: parser: instruction expected
hello.s:5: error: attempt to define a local label before any non-local labels
hello.s:6: error: attempt to define a local label before any non-local labels
hello.s:6: error: parser: instruction expected
hello.s:7: error: attempt to define a local label before any non-local labels
hello.s:7: error: parser: instruction expected
hello.s:9: error: parser: instruction expected
hello.s:10: error: parser: instruction expected
hello.s:11: error: parser: instruction expected
hello.s:12: error: parser: instruction expected
hello.s:13: error: symbol `movl’ redefined
hello.s:13: error: parser: instruction expected
hello.s:14: error: parser: instruction expected
hello.s:15: error: symbol `addl’ redefined
hello.s:15: error: parser: instruction expected
hello.s:16: error: parser: instruction expected
hello.s:17: error: parser: instruction expected
hello.s:18: error: symbol `subl’ redefined
hello.s:18: error: parser: instruction expected
hello.s:19: error: symbol `subl’ redefined
hello.s:19: error: parser: instruction expected
hello.s:20: error: symbol `pushl’ redefined
hello.s:20: error: parser: instruction expected
hello.s:22: error: symbol `addl’ redefined
hello.s:22: error: parser: instruction expected
hello.s:23: error: symbol `movl’ redefined
hello.s:23: error: parser: instruction expected
hello.s:26: error: parser: instruction expected
hello.s:27: error: parser: instruction expected
hello.s:28: error: parser: instruction expected
bt hello #

It wasn’t after a lot of reading that I realized that the two syntaxes are completely different. This explained why my attempts at correcting these errors did not work at all. Of course, hunting for the problem lead me to some very useful resources.

• AMD64 Architecture Programmer’s Manual Volume 1: Application Programming
• Using Assembly Language in Linux.
• Linux Assembly Tutorial: Step-by-Step Guide
• The Netwide Assembler: NASM
• AT&T Assembly Syntax

From these resources I determined there were three ways to compile and run the Hello World assembly code program. For the AT&T syntax a developer could use the GCC command or a combination of the AS and LD commands (yes, as I am working on Linux, case sensitivity does matter, but I am using caps for emphasis). The INTEL syntax requires the use of NASM and LD. The following output shows the compilation performed in each case. Note the size of the executable generated by the GCC command (ouch!!).

NASM Command

bt nasm # nasm -f elf hello.asm
bt nasm # ld -s -o hello_nasm.exe hello.o
bt nasm # ./hello_nasm.exe
Hello World
bt nasm # ls -al
total 20
drwxr-xr-x 2 root root 4096 Apr 26 23:46 ./
drwxr-xr-x 3 root root 4096 Apr 26 23:39 ../
-rw-r–r– 1 root root 685 Apr 26 23:46 hello.asm
-rw-r–r– 1 root root 720 Apr 26 23:46 hello.o
-rwxr-xr-x 1 root root 536 Apr 26 23:46 hello_nasm.exe*
bt nasm #

AS Command

bt as # as -o hello_as.o hello_as.s
bt as # ld -s -o hello_hello_as.o
bt as # ./hello_as.exe
Hello World

bt as # ls -al
total 20
drwxr-xr-x 2 root root 4096 Apr 27 00:00 ./
drwxr-xr-x 4 root root 4096 Apr 26 23:55 ../
-rwxr-xr-x 1 root root 444 Apr 27 00:00 hello_as.exe* <-NOTE: Size Winner Is AS
-rw-r–r– 1 root root 620 Apr 27 00:00 hello_as.o
-rw-r–r– 1 root root 770 Apr 27 00:00 hello_as.s
bt as #

GCC Command

bt hello # gcc -o hello.exe hello.s
bt hello # gcc -s -o hello_stripped.exe hello.s
bt hello # ls -al
total 32
drwxr-xr-x 4 root root 4096 Apr 27 00:48 ./
drwxr-xr-x 12 root root 4096 Apr 23 20:19 ../
drwxr-xr-x 2 root root 4096 Apr 27 00:00 as/
-rwxr-xr-x 1 root root 7932 Apr 27 00:48 hello.exe*
-rw-r–r– 1 root root 766 Apr 26 22:59 hello.s
-rwxr-xr-x 1 root root 2808 Apr 27 00:48 hello_stripped.exe* <-NOTE: Even stripped GCC is bigger
drwxr-xr-x 2 root root 4096 Apr 26 23:54 nasm/
bt hello # ./hello.exe
Hello World

bt hello # ./hello_stripped.exe
Hello World

bt hello #

It is very easy to see that how you compile the assembly code leads directly to the size of the executable and, perhaps, the speed and stability as well. Of course I cannot prove either of these theories, but I will take this guess because of the additional systems calls that go into the GCC version.

What I can do, in the meantime, is show you how these programs appear after they have been run through a disassembler. The versions compiled via AS and NASM are amazingly similar. The version compiled through GCC, however, is not even close. It’s output really shows how the additional libraries play a roll in the overall size of this executable. To disassemble these programs I will use the latest version of atlas’ Disass-3.0. I’ll leave the download and installation of this tool up to you.

NASM

bt nasm # disass-cli hello_nasm.exe
VirtualMemory:init:section: .text
BEGIN Processing Sub: ELF Start, .text (8048080) …..END Processing Sub: ELF Start, .text (8048080)
disass v3.00 Enhanced Disassembler
ELF HEADER OBJECT:hello_nasm.exe
= Intimate Details:
==Magic: ELF
==Type: Executable file
==Machine Arch: Intel 80386
==Version: 1
==Entry: 0×08048080
==Program Headers(offset): 52 (0×34) bytes
==Section Headers(offset): 256 (0×100) bytes
==Flags: 0L
==Elf Header Size: 52 (0×34 bytes)
==Program Header Size: 32 (0×20 bytes)
==Program Header Count: 2 (0×2)
==Section Header Size: 40 (0×28 bytes)
==Section Header Count: 7 (0×7)
==Section Header String Index 6 (0×6 bytes)

= Sections:
Elf Section: [ ] VMA: 0×00000000 offset: 0 ent/size: 0/ 0 align: 0
Elf Section: [ .text] VMA: 0×08048080 offset: 128 ent/size: 0/ 35 align: 16
Elf Section: [ .got.plt] VMA: 0×080490a4 offset: 176 ent/size: 0/ 0 align: 1
Elf Section: [ .data] VMA: 0×080490a4 offset: 164 ent/size: 0/ 12 align: 4
Elf Section: [ .bss] VMA: 0×080490b0 offset: 176 ent/size: 0/ 0 align: 1
Elf Section: [ .comment] VMA: 0×00000000 offset: 176 ent/size: 0/ 31 align: 1
Elf Section: [ .shstrtab] VMA: 0×00000000 offset: 207 ent/size: 0/ 46 align: 1

= Program Headers:
[ Loadable program segment] VMA: 0×08048000 offset: 0 memsize: 163 align: 4096 (filesz: 163) flags: 5
[ Loadable program segment] VMA: 0×080490a4 offset: 164 memsize: 12 align: 4096 (filesz: 12) flags: 6
Dynamics:

Virtual Memory: hello_nasm.exe, start: 8048080, flags: 0

====== Section Header: .text ======
====== Starting Address: 0×08048080 Length: 0×0023
====== File Offset: 0×0080 Size in File: 0×0023
====== Size in Memory: 0×0000
==================

Subroutine: ELF Start, .text (8048080) 9 lines 0×23 bytes
Starting address: 8048080 Ending address: 80480a2

; ELF Start, .text
8048080: \xb8\x04\x00\x00\x00 mov $0×4, %eax
8048085: \xbb\x01\x00\x00\x00 mov $0×1, %ebx
804808a: \xb9\xa4\x90\x04\x08 mov $0×80490a4, %ecx ; .got.plt, .data, ‘Hello World
‘ (.data)
804808f: \xba\x0c\x00\x00\x00 mov $0xc, %edx
8048094: \xcd\x80 int $0×80
8048096: \xb8\x01\x00\x00\x00 mov $0×1, %eax
804809b: \xbb\x00\x00\x00\x00 mov $0×0, %ebx
80480a0: \xcd\x80 int $0×80
80480a2: \xc3 ret
End Subroutine: ELF Start, .text (8048080) 9 lines 0×23 bytes
8048080: ELF Start, .text
80490a4: .got.plt, .data, ‘Hello World
‘ (.data)
80490b0: .bss

bt nasm #

AS

bt as # disass-cli hello_as.exe
VirtualMemory:init:section: .text
BEGIN Processing Sub: ELF Start, .text (8048074) …..END Processing Sub: ELF Start, .text (8048074)
disass v3.00 Enhanced Disassembler
ELF HEADER OBJECT:hello_as.exe
= Intimate Details:
==Magic: ELF
==Type: Executable file
==Machine Arch: Intel 80386
==Version: 1
==Entry: 0×08048074
==Program Headers(offset): 52 (0×34) bytes
==Section Headers(offset): 204 (0xcc) bytes
==Flags: 0L
==Elf Header Size: 52 (0×34 bytes)
==Program Header Size: 32 (0×20 bytes)
==Program Header Count: 2 (0×2)
==Section Header Size: 40 (0×28 bytes)
==Section Header Count: 6 (0×6)
==Section Header String Index 5 (0×5 bytes)

= Sections:
Elf Section: [ ] VMA: 0×00000000 offset: 0 ent/size: 0/ 0 align: 0
Elf Section: [ .text] VMA: 0×08048074 offset: 116 ent/size: 0/ 35 align: 4
Elf Section: [ .got.plt] VMA: 0×08049098 offset: 167 ent/size: 0/ 0 align: 1
Elf Section: [ .data] VMA: 0×08049098 offset: 152 ent/size: 0/ 15 align: 4
Elf Section: [ .bss] VMA: 0×080490a8 offset: 167 ent/size: 0/ 0 align: 4
Elf Section: [ .shstrtab] VMA: 0×00000000 offset: 167 ent/size: 0/ 37 align: 1

= Program Headers:
[ Loadable program segment] VMA: 0×08048000 offset: 0 memsize: 151 align: 4096 (filesz: 151) flags: 5
[ Loadable program segment] VMA: 0×08049098 offset: 152 memsize: 16 align: 4096 (filesz: 15) flags: 6
Dynamics:

Virtual Memory: hello_as.exe, start: 8048074, flags: 0

====== Section Header: .text ======
====== Starting Address: 0×08048074 Length: 0×0023
====== File Offset: 0×0074 Size in File: 0×0023
====== Size in Memory: 0×0000
==================

Subroutine: ELF Start, .text (8048074) 9 lines 0×23 bytes
Starting address: 8048074 Ending address: 8048096

; ELF Start, .text
8048074: \xb8\x04\x00\x00\x00 mov $0×4, %eax
8048079: \xbb\x01\x00\x00\x00 mov $0×1, %ebx
804807e: \xb9\x98\x90\x04\x08 mov $0×8049098, %ecx ; .got.plt, .data, ‘Hello World
‘ (.data)
8048083: \xba\xa5\x90\x04\x08 mov $0×80490a5, %edx ; ‘\x0c’ (.data)
8048088: \xcd\x80 int $0×80
804808a: \xb8\x01\x00\x00\x00 mov $0×1, %eax
804808f: \xbb\x00\x00\x00\x00 mov $0×0, %ebx
8048094: \xcd\x80 int $0×80
8048096: \xc3 ret
End Subroutine: ELF Start, .text (8048074) 9 lines 0×23 bytes
8048074: ELF Start, .text
8049098: .got.plt, .data, ‘Hello World
‘ (.data)
80490a5: ‘\x0c’ (.data)
80490a8: .bss

bt as #

GCC

bt hello # disass-cli hello.exe
VirtualMemory:init:section: .init
BEGIN Processing Sub: .init, (), _init(), , _init (8048260) …..END Processing Sub: .init, (), _init(), , _init (8048260)
VirtualMemory:init:section: .plt
BEGIN Processing Sub: .plt, (), (8048278) …..END Processing Sub: .plt, (), (8048278)
BEGIN Processing Sub: __libc_start_main() (PLT) (8048288) …..END Processing Sub: __libc_start_main() (PLT) (8048288)
VirtualMemory:init:section: .text
BEGIN Processing Sub: ELF Start, .text, (), _start(), , _start (80482a0) …..END Processing Sub: ELF Start, .text, (), _start(), , _start (80482a0)
BEGIN Processing Sub: __libc_csu_fini(), __libc_csu_fini (8048400) …..END Processing Sub: __libc_csu_fini(), __libc_csu_fini (8048400)
BEGIN Processing Sub: __libc_csu_init(), __libc_csu_init (80483a0) …..END Processing Sub: __libc_csu_init(), __libc_csu_init (80483a0)
BEGIN Processing Sub: __do_global_ctors_aux(), __do_global_ctors_aux (8048450) …..END Processing Sub: __do_global_ctors_aux(), __do_global_ctors_aux (8048450)
BEGIN Processing Sub: frame_dummy(), frame_dummy (8048340) …..END Processing Sub: frame_dummy(), frame_dummy (8048340)
BEGIN Processing Sub: call_gmon_start(), call_gmon_start (80482d0) …..END Processing Sub: call_gmon_start(), call_gmon_start (80482d0)
BEGIN Processing Sub: __do_global_dtors_aux(), __do_global_dtors_aux (8048300) …..END Processing Sub: __do_global_dtors_aux(), __do_global_dtors_aux (8048300)
VirtualMemory:init:section: .fini
BEGIN Processing Sub: .fini, (), _fini(), , _fini (8048480) …..END Processing Sub: .fini, (), _fini(), , _fini (8048480)
disass v3.00 Enhanced Disassembler
ELF HEADER OBJECT:hello.exe
= Intimate Details:
==Magic: ELF
==Type: Executable file
==Machine Arch: Intel 80386
==Version: 1
==Entry: 0×080482a0
==Program Headers(offset): 52 (0×34) bytes
==Section Headers(offset): 3484 (0xd9c) bytes
==Flags: 0L
==Elf Header Size: 52 (0×34 bytes)
==Program Header Size: 32 (0×20 bytes)
==Program Header Count: 7 (0×7)
==Section Header Size: 40 (0×28 bytes)
==Section Header Count: 34 (0×22)
==Section Header String Index 31 (0×1f bytes)

= Sections:
Elf Section: [ ] VMA: 0×00000000 offset: 0 ent/size: 0/ 0 align: 0
Elf Section: [ .interp] VMA: 0×08048114 offset: 276 ent/size: 0/ 19 align: 1
Elf Section: [ .note.ABI-tag] VMA: 0×08048128 offset: 296 ent/size: 0/ 32 align: 4
Elf Section: [ .hash] VMA: 0×08048148 offset: 328 ent/size: 4/ 40 align: 4
Elf Section: [ .dynsym] VMA: 0×08048170 offset: 368 ent/size: 16/ 80 align: 4
Elf Section: [ .dynstr] VMA: 0×080481c0 offset: 448 ent/size: 0/ 89 align: 1
Elf Section: [ .gnu.version] VMA: 0×0804821a offset: 538 ent/size: 2/ 10 align: 2
Elf Section: [ .gnu.version_r] VMA: 0×08048224 offset: 548 ent/size: 0/ 32 align: 4
Elf Section: [ .rel.dyn] VMA: 0×08048244 offset: 580 ent/size: 8/ 8 align: 4
Elf Section: [ .rel.plt] VMA: 0×0804824c offset: 588 ent/size: 8/ 8 align: 4
Elf Section: [ .init] VMA: 0×08048260 offset: 608 ent/size: 0/ 23 align: 16
Elf Section: [ .plt] VMA: 0×08048278 offset: 632 ent/size: 4/ 32 align: 4
Elf Section: [ .text] VMA: 0×080482a0 offset: 672 ent/size: 0/ 480 align: 16
Elf Section: [ .fini] VMA: 0×08048480 offset: 1152 ent/size: 0/ 27 align: 16
Elf Section: [ .rodata] VMA: 0×0804849c offset: 1180 ent/size: 0/ 8 align: 4
Elf Section: [ .eh_frame] VMA: 0×080484a4 offset: 1188 ent/size: 0/ 4 align: 4
Elf Section: [ .ctors] VMA: 0×080494a8 offset: 1192 ent/size: 0/ 8 align: 4
Elf Section: [ .dtors] VMA: 0×080494b0 offset: 1200 ent/size: 0/ 8 align: 4
Elf Section: [ .jcr] VMA: 0×080494b8 offset: 1208 ent/size: 0/ 4 align: 4
Elf Section: [ .dynamic] VMA: 0×080494bc offset: 1212 ent/size: 8/ 200 align: 4
Elf Section: [ .got] VMA: 0×08049584 offset: 1412 ent/size: 4/ 4 align: 4
Elf Section: [ .got.plt] VMA: 0×08049588 offset: 1416 ent/size: 4/ 16 align: 4
Elf Section: [ .data] VMA: 0×08049598 offset: 1432 ent/size: 0/ 28 align: 4
Elf Section: [ .bss] VMA: 0×080495b4 offset: 1460 ent/size: 0/ 4 align: 4
Elf Section: [ .comment] VMA: 0×00000000 offset: 1460 ent/size: 0/ 108 align: 1
Elf Section: [ .debug_aranges] VMA: 0×00000000 offset: 1568 ent/size: 0/ 136 align: 8
Elf Section: [ .debug_pubnames] VMA: 0×00000000 offset: 1704 ent/size: 0/ 37 align: 1
Elf Section: [ .debug_info] VMA: 0×00000000 offset: 1741 ent/size: 0/ 642 align: 1
Elf Section: [ .debug_abbrev] VMA: 0×00000000 offset: 2383 ent/size: 0/ 118 align: 1
Elf Section: [ .debug_line] VMA: 0×00000000 offset: 2501 ent/size: 0/ 511 align: 1
Elf Section: [ .debug_str] VMA: 0×00000000 offset: 3012 ent/size: 1/ 174 align: 1
Elf Section: [ .shstrtab] VMA: 0×00000000 offset: 3186 ent/size: 0/ 295 align: 1
Elf Section: [ .symtab] VMA: 0×00000000 offset: 4844 ent/size: 16/ 1984 align: 4
Elf Section: [ .strtab] VMA: 0×00000000 offset: 6828 ent/size: 0/ 1104 align: 1

= Program Headers:
[ Entry for header table itself] VMA: 0×08048034 offset: 52 memsize: 224 align: 4 (filesz: 224) flags: 5
[ Program interpreter] VMA: 0×08048114 offset: 276 memsize: 19 align: 1 (filesz: 19) flags: 4
[ Loadable program segment] VMA: 0×08048000 offset: 0 memsize: 1192 align: 4096 (filesz: 1192) flags: 5
[ Loadable program segment] VMA: 0×080494a8 offset: 1192 memsize: 272 align: 4096 (filesz: 268) flags: 6
[ Dynamic linking information] VMA: 0×080494bc offset: 1212 memsize: 200 align: 4 (filesz: 200) flags: 6
[ Auxiliary information] VMA: 0×08048128 offset: 296 memsize: 32 align: 4 (filesz: 32) flags: 4
[ Indicates stack executability] VMA: 0×00000000 offset: 0 memsize: 0 align: 4 (filesz: 0) flags: 7
Dynamics:
libc.so.6 Name of needed library
0×8048260L Address of init function
0×8048480L Address of termination function
0×8048148L Address of symbol hash table
0×80481C0L Address of string table
0×8048170L Address of symbol table
0×59L Size of string table
0×10L Size of one symbol table entry
0×0L For debugging; unspecified
0×8049588L Processor defined value
0×8L Size in bytes of PLT relocs
0×11L Type of reloc in PLT
0×804824CL Address of PLT relocs
0×8048244L Address of Rel relocs
0×8L Total size of Rel relocs
0×8L Size of one Rel reloc
0×8048224L Unknown: 0×6FFFFFFEL
0×1L Unknown: 0×6FFFFFFFL
0×804821AL Unknown: 0×6FFFFFF0L
0×0L Marks end of dynamic section

Virtual Memory: hello.exe, start: 80482a0, flags: 0

====== Section Header: .init ======
====== Starting Address: 0×08048260 Length: 0×0017
====== File Offset: 0×0260 Size in File: 0×0017
====== Size in Memory: 0×0000
==================

Subroutine: .init, (), _init(), , _init (8048260) 8 lines 0×17 bytes
Starting address: 8048260 Ending address: 8048276

; .init, (), _init(), , _init
Called from: __libc_csu_init(), __libc_csu_init (80483a0) at 80483b6
8048260: \x55 push %ebp
8048261: \x89\xe5 mov %esp, %ebp
8048263: \x83\xec\x08 sub $0×8, %esp
8048266: \xe8\x65\x00\x00\x00 call 0×80482d0 ; call_gmon_start(), call_gmon_start
804826b: \xe8\xd0\x00\x00\x00 call 0×8048340 ; frame_dummy(), frame_dummy
8048270: \xe8\xdb\x01\x00\x00 call 0×8048450 ; __do_global_ctors_aux(), __do_global_ctors_aux
8048275: \xc9 leave
8048276: \xc3 ret
End Subroutine: .init, (), _init(), , _init (8048260) 8 lines 0×17 bytes

====== Section Header: .plt ======
====== Starting Address: 0×08048278 Length: 0×0020
====== File Offset: 0×0278 Size in File: 0×0020
====== Size in Memory: 0×0004
==================

Subroutine: .plt, (), (8048278) 4 lines 0×10 bytes

; .plt, (),
JMPed from: __libc_start_main() (PLT) (8048288) at 8048293
8048278: \xff\x35\x8c\x95\x04\x08 pushl 0×804958c ; ‘\x00\x00\x00\x00\x00′… (.got.plt+0×4)
804827e: \xff\x25\x90\x95\x04\x08 jmpl *0×8049590 ; ‘\x00\x00\x00\x00\x8e\x82\x04\x08′… (.got.plt+0×8)
8048284: \x00\x00 add %al, (%eax)
8048286: \x00\x00 add %al, (%eax)
End Subroutine: .plt, (), (8048278) 4 lines 0×10 bytes

Subroutine: __libc_start_main() (PLT) (8048288) 3 lines 0×10 bytes

; __libc_start_main() (PLT)
Called from: ELF Start, .text, (), _start(), , _start (80482a0) at 80482bc
8048288: \xff\x25\x94\x95\x04\x08 jmpl *0×8049594 ; __libc_start_main()
804828e: \x68\x00\x00\x00\x00 push $0×0
8048293: \xe9\xe0\xff\xff\xff jmp 0×8048278 ; jmp .plt, (), (8048278) :-1b:
End Subroutine: __libc_start_main() (PLT) (8048288) 3 lines 0×10 bytes

====== Section Header: .text ======
====== Starting Address: 0×080482a0 Length: 0×01e0
====== File Offset: 0×02a0 Size in File: 0×01e0
====== Size in Memory: 0×0000
==================

Subroutine: ELF Start, .text, (), _start(), , _start (80482a0) 28 lines 0×30 bytes
Starting address: 80482a0 Ending address: 80482cf

; ELF Start, .text, (), _start(), , _start
80482a0: \x31\xed xor %ebp, %ebp
80482a2: \x5e pop %esi
80482a3: \x89\xe1 mov %esp, %ecx
80482a5: \x83\xe4\xf0 and $0xf0, %esp
80482a8: \x50 push %eax
80482a9: \x54 push %esp
80482aa: \x52 push %edx
80482ab: \x68\x00\x84\x04\x08 push $0×8048400 ; push __libc_csu_fini(), __libc_csu_fini (8048400) :+155:
80482b0: \x68\xa0\x83\x04\x08 push $0×80483a0 ; push __libc_csu_init(), __libc_csu_init (80483a0) :+f0:
80482b5: \x51 push %ecx
80482b6: \x56 push %esi
80482b7: \x68\x74\x83\x04\x08 push $0×8048374 ; push frame_dummy(), frame_dummy (8048340) (+0×34) :+bd:
80482bc: \xe8\xc7\xff\xff\xff call 0×8048288 ; call __libc_start_main() (PLT) (8048288) :-34:
80482c1: \xf4 hlt
80482c2: \x90 nop
80482c3: \x90 nop
80482c4: \x90 nop
80482c5: \x90 nop
80482c6: \x90 nop
80482c7: \x90 nop
80482c8: \x90 nop
80482c9: \x90 nop
80482ca: \x90 nop
80482cb: \x90 nop
80482cc: \x90 nop
80482cd: \x90 nop
80482ce: \x90 nop
80482cf: \x90 nop
End Subroutine: ELF Start, .text, (), _start(), , _start (80482a0) 28 lines 0×30 bytes

Subroutine: call_gmon_start(), call_gmon_start (80482d0) 26 lines 0×30 bytes
Starting address: 80482d0 Ending address: 80482ff

; call_gmon_start(), call_gmon_start
80482d0: \x55 push %ebp
80482d1: \x89\xe5 mov %esp, %ebp
80482d3: \x53 push %ebx
80482d4: \x83\xec\x04 sub $0×4, %esp
80482d7: \xe8\x16\x00\x00\x00 call 0×80482f2 ; call (local) :+1b:
80482dc: \x81\xc3\xac\x12\x00\x00 add $0×12ac, %ebx
80482e2: \x8b\x83\xfc\xff\xff\xff mov 0xfffffffc(%ebx), %eax
80482e8: \x85\xc0 test %eax, %eax
80482ea: \x74\x02 jz 0×80482ee ; jz (local) :+4:
80482ec: \xff\xd0 call *%eax

Referenced by: (local) at 80482ea
80482ee: \x58 pop %eax
80482ef: \x5b pop %ebx
80482f0: \x5d pop %ebp
80482f1: \xc3 ret

; __i686.get_pc_thunk.bx(), __i686.get_pc_thunk.bx
Called from: __libc_csu_fini(), __libc_csu_fini (8048400) at 8048409
Called from: __libc_csu_init(), __libc_csu_init (80483a0) at 80483ab
Called from: (local) at 80482d7
Called from: .fini, (), _fini(), , _fini (8048480) at 8048487
80482f2: \x8b\x1c\x24 mov (%esp), %ebx
80482f5: \xc3 ret
80482f6: \x90 nop
80482f7: \x90 nop
80482f8: \x90 nop
80482f9: \x90 nop
80482fa: \x90 nop
80482fb: \x90 nop
80482fc: \x90 nop
80482fd: \x90 nop
80482fe: \x90 nop
80482ff: \x90 nop
End Subroutine: call_gmon_start(), call_gmon_start (80482d0) 26 lines 0×30 bytes

Subroutine: __do_global_dtors_aux(), __do_global_dtors_aux (8048300) 31 lines 0×40 bytes
Starting address: 8048300 Ending address: 804833f

; __do_global_dtors_aux(), __do_global_dtors_aux
Called from: .fini, (), _fini(), , _fini (8048480) at 8048492
8048300: \x55 push %ebp
8048301: \x89\xe5 mov %esp, %ebp
8048303: \x83\xec\x08 sub $0×8, %esp
8048306: \x80\x3d\xb4\x95\x04\x08\x00 cmpb $0×0, 0×80495b4 ; .bss, (), completed.1(), __bss_start(), _edata(), , completed.1, __bss_start, _edata
804830d: \x74\x1b jz 0×804832a ; jz (local) :+1d:
804830f: \xeb\x2b jmp 0×804833c ; jmp (local) :+2d:
8048311: \xeb\x0d jmp 0×8048320 ; jmp (local) :+f:
8048313: \x90 nop
8048314: \x90 nop
8048315: \x90 nop
8048316: \x90 nop
8048317: \x90 nop
8048318: \x90 nop
8048319: \x90 nop
804831a: \x90 nop
804831b: \x90 nop
804831c: \x90 nop
804831d: \x90 nop
804831e: \x90 nop
804831f: \x90 nop

Referenced by: (local) at 8048333
JMPed from: (local) at 8048311
8048320: \x83\xc0\x04 add $0×4, %eax
8048323: \xa3\xa0\x95\x04\x08 mov %eax, 0×80495a0
8048328: \xff\xd2 call *%edx

Referenced by: (local) at 804830d
804832a: \xa1\xa0\x95\x04\x08 mov 0×80495a0, %eax
804832f: \x8b\x10 mov (%eax), %edx
8048331: \x85\xd2 test %edx, %edx
8048333: \x75\xeb jnz 0×8048320 ; jnz (local) :-13:
8048335: \xc6\x05\xb4\x95\x04\x08\x01 movb $0×1, 0×80495b4 ; .bss, (), completed.1(), __bss_start(), _edata(), , completed.1, __bss_start, _edata

JMPed from: (local) at 804830f
804833c: \xc9 leave
804833d: \xc3 ret
804833e: \x89\xf6 mov %esi, %esi
End Subroutine: __do_global_dtors_aux(), __do_global_dtors_aux (8048300) 31 lines 0×40 bytes

Subroutine: frame_dummy(), frame_dummy (8048340) 37 lines 0×60 bytes
Starting address: 8048340 Ending address: 804839f

; frame_dummy(), frame_dummy
8048340: \x55 push %ebp
8048341: \x89\xe5 mov %esp, %ebp
8048343: \x83\xec\x08 sub $0×8, %esp
8048346: \xa1\xb8\x94\x04\x08 mov 0×80494b8, %eax
804834b: \x85\xc0 test %eax, %eax
804834d: \x74\x21 jz 0×8048370 ; jz (local) :+23:
804834f: \xb8\x00\x00\x00\x00 mov $0×0, %eax
8048354: \x85\xc0 test %eax, %eax
8048356: \x74\x18 jz 0×8048370 ; jz (local) :+1a:
8048358: \x83\xec\x0c sub $0xc, %esp
804835b: \x68\xb8\x94\x04\x08 push $0×80494b8 ; .jcr, (), __JCR_LIST__(), __JCR_END__(), , __JCR_LIST__, __JCR_END__
8048360: \xe8\x9b\x7c\xfb\xf7 call 0×0
8048365: \x83\xc4\x10 add $0×10, %esp
8048368: \x90 nop
8048369: \x8d\xb4\x26\x00\x00\x00\x00 lea 0×0(%esi), %esi

Referenced by: (local) at 804834d
Referenced by: (local) at 8048356
8048370: \xc9 leave
8048371: \xc3 ret
8048372: \x90 nop
8048373: \x90 nop

; main(), main
Referenced by: ELF Start, .text, (), _start(), , _start (80482a0) at 80482b7
8048374: \xb8\x04\x00\x00\x00 mov $0×4, %eax
8048379: \xbb\x01\x00\x00\x00 mov $0×1, %ebx
804837e: \xb9\xa4\x95\x04\x08 mov $0×80495a4, %ecx ; hello(), hello
8048383: \xba\xb1\x95\x04\x08 mov $0×80495b1, %edx ; ‘\x0c’ (.data) , hlen(), hlen
8048388: \xcd\x80 int $0×80
804838a: \xb8\x01\x00\x00\x00 mov $0×1, %eax
804838f: \xbb\x00\x00\x00\x00 mov $0×0, %ebx
8048394: \xcd\x80 int $0×80
8048396: \xc3 ret
8048397: \x90 nop
8048398: \x90 nop
8048399: \x90 nop
804839a: \x90 nop
804839b: \x90 nop
804839c: \x90 nop
804839d: \x90 nop
804839e: \x90 nop
804839f: \x90 nop
End Subroutine: frame_dummy(), frame_dummy (8048340) 37 lines 0×60 bytes

Subroutine: __libc_csu_init(), __libc_csu_init (80483a0) 35 lines 0×60 bytes
Variables:
fffffff0 ( 10) _____________________________________________________
Starting address: 80483a0 Ending address: 80483ff

; __libc_csu_init(), __libc_csu_init
Referenced by: ELF Start, .text, (), _start(), , _start (80482a0) at 80482b0
80483a0: \x55 push %ebp
80483a1: \x89\xe5 mov %esp, %ebp
80483a3: \x57 push %edi
80483a4: \x56 push %esi
80483a5: \x31\xf6 xor %esi, %esi
80483a7: \x53 push %ebx
80483a8: \x83\xec\x0c sub $0xc, %esp
80483ab: \xe8\x42\xff\xff\xff call 0×80482f2 ; call call_gmon_start(), call_gmon_start (80482d0) (+0×22) :-b9:
80483b0: \x81\xc3\xd8\x11\x00\x00 add $0×11d8, %ebx
80483b6: \xe8\xa5\xfe\xff\xff call 0×8048260 ; call .init, (), _init(), , _init (8048260) :-156:
80483bb: \x8d\x83\x20\xff\xff\xff lea 0xffffff20(%ebx), %eax
80483c1: \x8d\x93\x20\xff\xff\xff lea 0xffffff20(%ebx), %edx
80483c7: \x89\x45\xf0 mov %eax, 0xfffffff0(%ebp)
80483ca: \x29\xd0 sub %edx, %eax
80483cc: \xc1\xf8\x02 sar $0×2, %eax
80483cf: \x39\xc6 cmp %eax, %esi
80483d1: \x73\x1f jnc 0×80483f2 ; jnc (local) :+21:
80483d3: \x89\xd7 mov %edx, %edi
80483d5: \x8d\x74\x26\x00 lea 0×0(%esi), %esi
80483d9: \x8d\xbc\x27\x00\x00\x00\x00 lea 0×0(%edi), %edi

Referenced by: (local) at 80483f0
80483e0: \xff\x14\xb2 calll *(%edx, %esi, 4)
80483e3: \x8b\x4d\xf0 mov 0xfffffff0(%ebp), %ecx
80483e6: \x46 inc %esi
80483e7: \x89\xfa mov %edi, %edx
80483e9: \x29\xf9 sub %edi, %ecx
80483eb: \xc1\xf9\x02 sar $0×2, %ecx
80483ee: \x39\xce cmp %ecx, %esi
80483f0: \x72\xee jc 0×80483e0 ; jc (local) :-10:

Referenced by: (local) at 80483d1
80483f2: \x83\xc4\x0c add $0xc, %esp
80483f5: \x5b pop %ebx
80483f6: \x5e pop %esi
80483f7: \x5f pop %edi
80483f8: \x5d pop %ebp
80483f9: \xc3 ret
80483fa: \x8d\xb6\x00\x00\x00\x00 lea 0×0(%esi), %esi
End Subroutine: __libc_csu_init(), __libc_csu_init (80483a0) 35 lines 0×60 bytes

Subroutine: __libc_csu_fini(), __libc_csu_fini (8048400) 30 lines 0×50 bytes
Variables:
fffffffc ( 4) _____________________________________________________
fffffff8 ( 4) _____________________________________________________
fffffff4 ( 4) _____________________________________________________
Starting address: 8048400 Ending address: 804844f

; __libc_csu_fini(), __libc_csu_fini
Referenced by: ELF Start, .text, (), _start(), , _start (80482a0) at 80482ab
8048400: \x55 push %ebp
8048401: \x89\xe5 mov %esp, %ebp
8048403: \x83\xec\x18 sub $0×18, %esp
8048406: \x89\x5d\xf4 mov %ebx, 0xfffffff4(%ebp)
8048409: \xe8\xe4\xfe\xff\xff call 0×80482f2 ; call call_gmon_start(), call_gmon_start (80482d0) (+0×22) :-117:
804840e: \x81\xc3\x7a\x11\x00\x00 add $0×117a, %ebx
8048414: \x89\x7d\xfc mov %edi, 0xfffffffc(%ebp)
8048417: \x8d\x83\x20\xff\xff\xff lea 0xffffff20(%ebx), %eax
804841d: \x8d\xbb\x20\xff\xff\xff lea 0xffffff20(%ebx), %edi
8048423: \x89\x75\xf8 mov %esi, 0xfffffff8(%ebp)
8048426: \x29\xf8 sub %edi, %eax
8048428: \xc1\xf8\x02 sar $0×2, %eax
804842b: \x8d\x70\xff lea 0xffffffff(%eax), %esi
804842e: \xeb\x04 jmp 0×8048434 ; jmp (local) :+6:

Referenced by: (local) at 8048437
8048430: \xff\x14\xb7 calll *(%edi, %esi, 4)
8048433: \x4e dec %esi

JMPed from: (local) at 804842e
8048434: \x83\xfe\xff cmp $0xffffffff, %esi
8048437: \x75\xf7 jnz 0×8048430 ; jnz (local) :-7:
8048439: \xe8\x42\x00\x00\x00 call 0×8048480 ; .fini, (), _fini(), , _fini
804843e: \x8b\x5d\xf4 mov 0xfffffff4(%ebp), %ebx
8048441: \x8b\x75\xf8 mov 0xfffffff8(%ebp), %esi
8048444: \x8b\x7d\xfc mov 0xfffffffc(%ebp), %edi
8048447: \x89\xec mov %ebp, %esp
8048449: \x5d pop %ebp
804844a: \xc3 ret
804844b: \x90 nop
804844c: \x90 nop
804844d: \x90 nop
804844e: \x90 nop
804844f: \x90 nop
End Subroutine: __libc_csu_fini(), __libc_csu_fini (8048400) 30 lines 0×50 bytes

Subroutine: __do_global_ctors_aux(), __do_global_ctors_aux (8048450) 30 lines 0×30 bytes
Starting address: 8048450 Ending address: 804847f

; __do_global_ctors_aux(), __do_global_ctors_aux
8048450: \x55 push %ebp
8048451: \x89\xe5 mov %esp, %ebp
8048453: \x53 push %ebx
8048454: \x52 push %edx
8048455: \xbb\xa8\x94\x04\x08 mov $0×80494a8, %ebx ; .ctors, ‘\xff\xff\xff\xff’ (.ctors) , (), __CTOR_LIST__(), __fini_array_end(), __fini_array_start(), __init_array_end(), __init_array_start(), , __CTOR_LIST__, __fini_array_end, __fini_array_start, __init_array_end, __init_array_start
804845a: \xa1\xa8\x94\x04\x08 mov 0×80494a8, %eax
804845f: \xeb\x16 jmp 0×8048477 ; jmp (local) :+18:
8048461: \xeb\x0d jmp 0×8048470 ; jmp (local) :+f:
8048463: \x90 nop
8048464: \x90 nop
8048465: \x90 nop
8048466: \x90 nop
8048467: \x90 nop
8048468: \x90 nop
8048469: \x90 nop
804846a: \x90 nop
804846b: \x90 nop
804846c: \x90 nop
804846d: \x90 nop
804846e: \x90 nop
804846f: \x90 nop

Referenced by: (local) at 804847a
JMPed from: (local) at 8048461
8048470: \x83\xeb\x04 sub $0×4, %ebx
8048473: \xff\xd0 call *%eax
8048475: \x8b\x03 mov (%ebx), %eax

JMPed from: (local) at 804845f
8048477: \x83\xf8\xff cmp $0xffffffff, %eax
804847a: \x75\xf4 jnz 0×8048470 ; jnz (local) :-a:
804847c: \x58 pop %eax
804847d: \x5b pop %ebx
804847e: \x5d pop %ebp
804847f: \xc3 ret
End Subroutine: __do_global_ctors_aux(), __do_global_ctors_aux (8048450) 30 lines 0×30 bytes

====== Section Header: .fini ======
====== Starting Address: 0×08048480 Length: 0×001b
====== File Offset: 0×0480 Size in File: 0×001b
====== Size in Memory: 0×0000
==================

Subroutine: .fini, (), _fini(), , _fini (8048480) 11 lines 0×1b bytes
Starting address: 8048480 Ending address: 804849a

; .fini, (), _fini(), , _fini
8048480: \x55 push %ebp
8048481: \x89\xe5 mov %esp, %ebp
8048483: \x53 push %ebx
8048484: \x83\xec\x04 sub $0×4, %esp
8048487: \xe8\x66\xfe\xff\xff call 0×80482f2 ; call call_gmon_start(), call_gmon_start (80482d0) (+0×22) :-195:
804848c: \x81\xc3\xfc\x10\x00\x00 add $0×10fc, %ebx
8048492: \xe8\x69\xfe\xff\xff call 0×8048300 ; call __do_global_dtors_aux(), __do_global_dtors_aux (8048300) :-192:
8048497: \x5a pop %edx
8048498: \x5b pop %ebx
8048499: \x5d pop %ebp
804849a: \xc3 ret
End Subroutine: .fini, (), _fini(), , _fini (8048480) 11 lines 0×1b bytes
0: (), (), (), (), (), (), (), (), (), (), (), (), ./../include/libc-symbols.h(), ./../include/libc-symbols.h(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/config.h(), ./../include/libc-symbols.h(), (), (), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/csu//(), abi-note.S(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/csu/abi-tag.h(), abi-note.S(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/config.h(), abi-note.S(), (), ./../include/libc-symbols.h(), ./../include/libc-symbols.h(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/config.h(), ./../include/libc-symbols.h(), (), (), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/csu//(), abi-note.S(), init.c(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/csu/crti.S(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/csu/defs.h(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/csu/defs.h(), initfini.c(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/csu/crti.S(), (), ./../include/libc-symbols.h(), ./../include/libc-symbols.h(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/config.h(), ./../include/libc-symbols.h(), (), (), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/csu/crti.S(), crtstuff.c(), crtstuff.c(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/csu/crtn.S(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/csu/defs.h(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/csu/defs.h(), initfini.c(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/csu/crtn.S(), (), ./../include/libc-symbols.h(), ./../include/libc-symbols.h(), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/config.h(), ./../include/libc-symbols.h(), (), (), /glibc-tmp-91a3c13f482c0e54fcb31801829d957b/glibc-2.3.6/build-glibc-2.3.6/csu/crtn.S(), __libc_start_main@@GLIBC_2.0(), _Jv_RegisterClasses(), __gmon_start__(), (), __libc_start_main(), _Jv_RegisterClasses(), __gmon_start__()
8048114: .interp, ‘/lib/ld-linux.so.2′ (.interp) , (),
8048128: .note.ABI-tag, ‘\x04′ (.note.ABI-tag) , (),
804812c: ‘\x10′ (.note.ABI-tag)
8048130: ‘\x01′ (.note.ABI-tag)
8048134: ‘GNU’ (.note.ABI-tag)
804813c: ‘\x02′ (.note.ABI-tag)
8048140: ‘\x04′ (.note.ABI-tag)
8048144: ‘\x01′ (.note.ABI-tag)
8048148: .hash, ‘\x03′ (.hash) , (),
804814c: ‘\x05′ (.hash)
8048150: ‘\x04′ (.hash)
8048154: ‘\x01′ (.hash)
8048158: ‘\x02′ (.hash)
804816c: ‘\x03′ (.hash)
8048170: .dynsym, (),
8048180: ‘=’ (.dynsym)
8048188: ‘\xde’ (.dynsym)
804818c: ‘\x12′ (.dynsym)
8048190: ‘.’ (.dynsym)
8048194: ‘\xa0\x84\x04\x08\x04′ (.dynsym)
804819c: ‘\x11′ (.dynsym)
804819e: ‘\x0e’ (.dynsym)
80481a0: ‘\x01′ (.dynsym)
80481ac: ‘ ‘ (.dynsym)
80481b0: ‘\x15′ (.dynsym)
80481bc: ‘ ‘ (.dynsym)
80481c0: .dynstr, (),
80481c1: ‘_Jv_RegisterClasses’ (.dynstr)
80481d5: ‘__gmon_start__’ (.dynstr)
80481e4: ‘libc.so.6′ (.dynstr)
80481ee: ‘_IO_stdin_used’ (.dynstr)
80481fd: ‘__libc_start_main’ (.dynstr)
804820f: ‘GLIBC_2.0′ (.dynstr)
804821a: .gnu.version, (),
804821c: ‘\x02′ (.gnu.version)
804821e: ‘\x01′ (.gnu.version)
8048224: .gnu.version_r, ‘\x01′ (.gnu.version_r) , (),
8048226: ‘\x01′ (.gnu.version_r)
8048228: ‘$’ (.gnu.version_r)
804822c: ‘\x10′ (.gnu.version_r)
‘ (.gnu.version_r)
804823a: ‘\x02′ (.gnu.version_r)
804823c: ‘O’ (.gnu.version_r)
8048244: .rel.dyn, ‘\x84\x95\x04\x08\x06\x04′ (.rel.dyn) , (),
804824c: .rel.plt, ‘\x94\x95\x04\x08\x07\x01′ (.rel.plt) , (),
8048260: .init, (), _init(), , _init
8048278: .plt, (),
8048288: __libc_start_main() (PLT)
80482a0: ELF Start, .text, (), _start(), , _start
80482d0: call_gmon_start(), call_gmon_start
80482f2: __i686.get_pc_thunk.bx(), __i686.get_pc_thunk.bx
8048300: __do_global_dtors_aux(), __do_global_dtors_aux
8048340: frame_dummy(), frame_dummy
8048374: main(), main
80483a0: __libc_csu_init(), __libc_csu_init
8048400: __libc_csu_fini(), __libc_csu_fini
8048450: __do_global_ctors_aux(), __do_global_ctors_aux
8048480: .fini, (), _fini(), , _fini
804849c: .rodata, ‘\x03′ (.rodata) , (), _fp_hw(), , _fp_hw
80484a0: ‘\x01′ (.rodata) , _IO_stdin_used(), _IO_stdin_used(), _IO_stdin_used
80484a2: ‘\x02′ (.rodata)
80484a4: .eh_frame, (), __FRAME_END__(), , __FRAME_END__
80494a8: .ctors, ‘\xff\xff\xff\xff’ (.ctors) , (), __CTOR_LIST__(), __fini_array_end(), __fini_array_start(), __init_array_end(), __init_array_start(), , __CTOR_LIST__, __fini_array_end, __fini_array_start, __init_array_end, __init_array_start
80494ac: __CTOR_END__(), __CTOR_END__
80494b0: .dtors, ‘\xff\xff\xff\xff’ (.dtors) , (), __DTOR_LIST__(), , __DTOR_LIST__
80494b4: __DTOR_END__(), __DTOR_END__
80494b8: .jcr, (), __JCR_LIST__(), __JCR_END__(), , __JCR_LIST__, __JCR_END__
80494bc: .dynamic, ‘\x01′ (.dynamic) , (), _DYNAMIC(), , _DYNAMIC
80494c0: ‘$’ (.dynamic)
80494c4: ‘\x0c’ (.dynamic)
80494c8: ‘\x60\x82\x04\x08\x0d’ (.dynamic)
80494d0: ‘\x80\x84\x04\x08\x04′ (.dynamic)
80494d8: ‘\x48\x81\x04\x08\x05′ (.dynamic)
80494e0: ‘\xc0\x81\x04\x08\x06′ (.dynamic)
80494e8: ‘\x70\x81\x04\x08\x0a’ (.dynamic)
80494f0: ‘Y’ (.dynamic)
80494f4: ‘\x0b’ (.dynamic)
80494f8: ‘\x10′ (.dynamic)
80494fc: ‘\x15′ (.dynamic)
8049504: ‘\x03′ (.dynamic)
8049508: ‘\x88\x95\x04\x08\x02′ (.dynamic)
8049510: ‘\x08′ (.dynamic)
8049514: ‘\x14′ (.dynamic)
8049518: ‘\x11′ (.dynamic)
804951c: ‘\x17′ (.dynamic)
8049520: ‘\x4c\x82\x04\x08\x11′ (.dynamic)
8049528: ‘\x44\x82\x04\x08\x12′ (.dynamic)
8049530: ‘\x08′ (.dynamic)
8049534: ‘\x13′ (.dynamic)
8049538: ‘\x08′ (.dynamic)
804953c: ‘\xfe\xff\xff\x6f\x24\x82\x04\x08\xff\xff\xff\x6f\x01′ (.dynamic)
804954c: ‘\xf0\xff\xff\x6f\x1a\x82\x04\x08′ (.dynamic)
8049584: .got, __gmon_start__(), (),
8049588: .got.plt, (), _GLOBAL_OFFSET_TABLE_(), , _GLOBAL_OFFSET_TABLE_
804958c: ‘\x00\x00\x00\x00\x00′… (.got.plt+0×4)
8049590: ‘\x00\x00\x00\x00\x8e\x82\x04\x08′… (.got.plt+0×8)
8049594: __libc_start_main()
8049598: .data, (), data_start(), __data_start(), , data_start, __data_start
804959c: __dso_handle(), __dso_handle
80495a0: ‘Hello World
‘ (.data) , p.0(), p.0
80495a4: hello(), hello
80495b1: ‘\x0c’ (.data) , hlen(), hlen
80495b4: .bss, (), completed.1(), __bss_start(), _edata(), , completed.1, __bss_start, _edata
80495b5: ‘GCC’ (.bss)
80495b8: _end(), _end

bt hello #

Dang, the GCC output is so big and convoluted, I couldn’t keep up with it.

Now that we have seen the output of these files, you are probably asking yourself, “Why are disassemblers important?” Well, they analyze the executable for us so that we do not have to open the file in a hex editor and then begin decrypting the system calls and opcodes. It also provides us with the locations of various interesting instructions and data within the virtual memory. I am certain that atlas has programmed in more features that I have not implemented here and I’m willing to place a bet that he has something very interesting in the works for future versions of Disass-3. For now we are just going to have to wait.

Of course I know that none of this is very exciting. Just so you know, I did try to think of something that would liven it up a little bit. Alas, it did not happen. But at least I did learn a thing or two about Assembly. Hopefully you did as well.

Go forth and do good things,

Don C. Weber

assembly, programming, gcc, c, nasm, ld, Disass-3.0, Security Ripcord

Sure enough altas emailed me several days later. We quickly agreed to an interview but because of constant battles with SPAM filtering, multiple projects on both sides, and several conference presentations by atlas, we just did not get it completed until a few days ago. During one of the emails I asked atlas to mention some of the things that he was working on to help me write some pointed questions directed towards his interests. He mentioned a few:

I have been doing some fun stuff with 16-bit real mode, kernel module play in
Linux, BIOS hacking, and of course disassembly and programmatic debugging.

My first thought was “Uh, oh.” Sure, I have heard of all of this but if you followed my failings with writing exploits for a simple buffer overflow you know that I am not going to be able to dig very deeply into these topics. I did some quick research on the topics. Then I reviewed his latest posts on his toolkit, atlasutils and reviewed his presentation on Vulncatcher. I started to get a little frustrated. After all, I did not want to waste the excellent opportunity just because I do not have a grasp of the integrate details of complex software and hardware relationships. Ahhh, bingo. I hit the nail on the head. Looking over everything that I can find on altas I realized that he has one of those special eyes for detail. He can see the integrate relationships within complex systems and understand how to research them. Or, at least, he understands it enough to try and manipulate the relationship. Hacking at its finest, its very core. Excellent. I might not be able to delve deeply into his research, but I can at least find out his opinions on this complexity.

First, a little Bio on altas stolen from his ShmooCon 2008 introduction.

atlas is an average joe who spends his time learning new ways to make computer systems dance. When he’s not slicing and dicing windows and unix binaries, he’s writing tools to make vulnerability research simpler and more enjoyable. His hobbies include deadlisting (opcode disassembly), vulnerability research, and lately he’s been working on processor emulation and kernel-mode internals. atlas leads the capture-the-flag team, 1@stplace, who recently won back-to-back victories at defcon, which he blames on his teammates. “I surround myself with brilliant people,” he quips.

So, without further ado, atlas.

DefCon CTF

1. You have lead your team to two straight victories in the DefCon CTF.
Has this part of your life run its course or is it still challenging enough
to give it another run?

Wow… it’s still challenging! Each year we have been extremely challenged by
amazing talent. There is still immense question of how well we will place
this year, with the outstanding talent the Naval Postgrad School puts forth
each year, Vigna’s team has provided some serious domination in the past, we
have several international teams which are doing very well, and other talent
not yet “displayed” at defcon. We have to go in each year focused on doing
our best, regardless of who and what challenges we face. How many more years
I have left to give is another question. It’s a very consuming weekend, and
quals weekend, even though we don’t currently have to qualify, is challenging
as well.

2. Your team is obviously very skilled but the types of personalities I
imagine that are involved are use to individual performance and behavior.
Was it a challenge to lead them and keep them focused on goals that
benefitted the group as a whole? I.E. tracking down a problem that might
be too difficult for the competition or not worth the effort.

If I’ve done anything really well in CTF it is selecting amazing people. They
have always been an honor to lead, and have actually helped me lead them in
more ways than I can count.

3. Have you or your team members seen benefits develop from the amount of
time and effort you have placed in getting ready for DefCon CTF?

Oh totally. A few of my guys, myself included, have changed career paths
based largely on how well they’ve proven themselves at ctf. I can’t speak
for the others, but I’m quite happy with the results. I think we’ve all seen
improvements in our daily tasks and our abilities to achieve our goals.
We’ve built strong friendships within the team which has been very good.
Management also responds well to our wins, as they are more likely to think
we know what the heck we’re talking about.

4. Are you personally going to give it another run? Will l@stplace return
as the same team or will you select different members to keep the blood
fresh and challenge high?

We’ll return the same team we left. I’ve been fortunate to find such amazing
guys, hand-selected them based on their talent, skill and personality, and
formed lasting friendships that transcend defcon. I’m confident from our
talks offline that we will all be returning this year, Lord willing.

5. Do you believe that there are real world teams, criminal or govenment,
performing detailed and near real-time application analysis to penetrate
businesses and government systems, much in the same manner that the teams
in the last DefCon CTF were doing?

Certainly. Absolutely. No Comment.

Program Research and Exploit Writing

6. What was your background before you started really moving into program
and architecture research?

I had been a coder since I was young, but got a career in sys-admin work, then
moved into data-telecom where I was responsible for many security-related
services, then got drafted into security.

7. To me some of the concepts are difficult to grasp and implement when
there are resources. What did you do to help you get over the hump and
begin to fully understand the intricacies of low level programming and
analysis?

Gave up. Then I redoubled back. I was freaked out at the possibility I’d
fail. So I decided that I couldn’t do it. Once I had finished freaking out
I decided to work it and grow. Some people could and were doing this stuff,
what’s the cost of throwing myself into the learning curve and seeing where
it lead?

8. Your toolset, atlasutils, is a combination of python programs and
script that include a disassembler and other tools that help located and
provide information to exploit vulnerabilities. I have noticed that Dave
Aitel likes to talk about writing his own debuggers as well. Is this
because the tools that are out there are not useful, you have different
ideas that did not go into the usual debugger, or that you just need
something to help fit a specific niche? Or, it is just fun to write your
down debugger?

To quote a very good friend of mine, I write code because I’m lazy. Truth
is, using others’ tools is tiring, since I have to learn to think like
them… Writing my own forces to me to learn how to think about the things
I’m trying to do, then write tools that help me next time I have to do them.
I hope people find my tools useful, but they’re really for my benefit. I
often write my own tools because I’m forced to learn the details better…
and then I can add my own whizbang fun new stuff on from there. For
instance, I’m rewriting disass, because there was an upper-limit in binary
size, above which it simply took forever to process because of inefficient
use of memory. It was also very “dogmatic”, and not agile. Some code I want
to disassemble is packed/encrypted and wrapped with an unpacker/decryptor.
That means the data/code actually changes post-loading. Disassemblers have
to account for that, which means they have to be “agile”, or able to adjust
how they view the memory setup of a binary. I’m also working parts of the
remake of disass into an emulator (no, not complete emulation) which will
allow me to better address certain laborious tasks.

9. When you are developing these tools, how do you pick a program to
analyze? Do you generate your own vulnerable code or find something with
known vulnerabilities to analyze?

When developing tools I try to use them on anything I want to analyze, just to
see them break (and wow they break). Sometimes it’s code I’ve snagged from
ctf, sometimes it’s my own code, sometimes it’s POSIX code or Win32 code, or
<insert-your-fav-commercial-app> code.

10. As I look at the types of research you are performing I start to
wonder if computers are just too complex. Or if the higher level
programming languages that we have just cannot securely support all of the
low level functionality. Then I start thinking about the interactions and
complexity added by software and hardware interaction, BIOS, and firmware
and my head really starts to spin. What are your thoughts on this
complexity and how it is affecting the security of technology as a whole?

Well, you’ve really nailed it. Computers have become very complex indeed…
and continue to do so. In many layers of “synthesis” the computer industry
has striven to group low-level functions into simple-to-use functionality;
for the developers and ultimately the end users.
Each iteration of simplification masks many details from the users/developers,
and with the disappearance of those details comes many assumptions.
Assumptions are inevitable in our industry because you can’t teach *every*
administrator and developer *every* detail about the computer. Some in the
security field have attained a great deal of understanding those details…
and we tend to hail them as deities.
False assumptions and the state of mind induced by details-overload work
together to provide vulnerabilities for attackers to leverage. Sometimes
those vulnerabilities highlight a loss of communication, laziness, lack of
understanding, or simply mistakes.

This dilemma is not going away. We continue to see layered-development and a
push for ease-of-use at every level. Ease-of-use tends to be directly
counter to security, in that we enable users and developers to do mighty
things without realizing the truth of what they are doing. For example,
without proper education and focus on security, thousands of SQL-Servers were
put on the Internet with a blank SA password (the default).

Security must become a baked-in part of the development culture. Developers
need to be screened for how seriously they take security, and continually
trained and updated on new security problems, such as format-string bugs and
buffer overflows in the 90s. When the next new common programming flaw is
identified, those mistakes must be put in front of developers to warn them
and instruct what the computer is actually doing, or how attackers are
leveraging the flaws to do evil things. Each development team needs to have
someone who understands how to think like an evil d00d. I venture to say
that every developer should become that person.

This complexity provides plenty of playground for attackers, but hackers are
rising to the occasion, finding enjoyment in understanding systems better
sometimes than their creators. We insert stop-gap protections like ASLR and
anti-corruption techniques and hackers find ways around them. Worse than the
time lost in the creation and adoption of those protections is the
complacency they allow developers, who wrongfully think they are protected.
With all the complexity of just learning someone else’s API and interacting
with third-party products, as well as designing corporate-wide API’s that
hundreds of developers may use, they are happy to think on the good sides to
such protections, without being able to understand the details or
limitations. Even if they have the base-knowledge to understand, they simply
are seldom given the time.

11. With this complexity, how can developers fix it? I mean, programmers
just do not have the time and resources to think of every little piece of
the puzzle. We cannot expect them to. So, how do developers protect their
projects? Do we just need to realize that we are in a constant state of
possible exploitation and accept that very expensive systems will get
exploited and we better have a good incident response team?

See above… Good incident handling teams are invaluable for an organization.
Teams who understand proactive security and the patching process are equally
important. Consider them “stoppers” and “sweepers” if you like futbol.

In the end, the ball is the developer’s court. Each person who writes code
needs to learn the details of what they are doing, and accept responsibility
for the security of their work. If format-string bugs seem impossible to
exploit, that developer needs training (SANS SEC504 is generally very good
for that). If XSS doesn’t seem to be a big deal, training is necessary.
Aside from great training, that SANS course will likely provide networking
opportunities with people who think evil all day every day. BlackHat and
defcon are also good venues, but likely less substantive. We need to stop
training our developers only about how to enable things… because that only
enables exploits.

12. Along the lines of complexity, most of the technologies that are put
out there, operating systems and applications, automatically have these
complexities built into them as features. The Center of Internet Security
has long benchmarks to help guide administrators through steps that help
them limit their exposure to some of these complexities, but with each new
release of a product the administrator has to be worried about what is new
or what was modified that exposes the environment to additional risk. What
recommendations can you make to these administrators as they are taking
these complexities into consideration?

Good luck? The truth is that CIS spits out some outstanding documents to help
us get a certain level of security with the least outlay of effort. It’s a
bang-for-your-buck arrangement. Unfortunately no benchmark or security guide
is going to take the place of a solid understanding of the technologies one
is using. Best case, CIS guides serve as a litmus test and a guide to
someone who already has a great understanding and the curiosity to know their
playground well. Someone who knows enough to know how much they don’t know
so they welcome the help, but someone who plays with their tech and groks
it… because they want to. This is the part where I get to piss a lot of
people off… if you don’t love security or IT or IS… get out. There are
many professions where you may be happier and more successful. Computers
have become the next “Doctor” or “Lawyer” profession, where people flood
Computer college programs in hopes of a mighty paycheck. Those people
everyone views as gods in this industry are people who would tinker anyway,
even if they were janitors during the day. And if you *do* tinker and wind
up in the industry… get yourself some security understanding. Learn to
think as your opponent… think about how someone who hates your guts and
your programs would mess with them. Get the training, from an organization
or a friend if you cannot afford formalized training.
And remember, patching is a vital, ongoing process organization-wide.

@

Go forth and do good things,
Don C. Weber

atlas, exploits, vulnerabilities, defcon, ctf, atlasutils, vulncatcher, InGuardians, skoudis, Security Ripcord, atlas wandering, l@astplace