[Java entry] Buffer Overflow programming experience

[Java entry] experiences in buffer overflow programming-general Linux technology-Linux programming and kernel information. For details, refer to the following section. There are also a lot of information about buffer overflow on the Internet, but I found that the introduction is not very clear during the reading process, and each website is only a translation of a foreigner, not only does the content have defects, but the program cannot be called because the GCC version is different. after several days of thinking, I finally understood the real principle and wrote it out for sharing.

Test environment:
$ Gcc-v
Readingspecs from/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured :.. /configure -- prefix =/usr -- mandir =/usr/share/man -- infodir =/usr/share/info -- enable-shared -- enable-threads = posix -- disable-checking -- with-system-zlib -- enable-_ cxa_atexit -- host = i386-redhat-linux
Thread model: posix
Gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-24)

$ Gdb-v
GNU gdb Red Hat Linux (6.0post-0.20031117.6rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
Welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu ".

$ Uname-
Linux candy 2.4.21-9.EL #1 Thu Jan 8 17:03:13 EST 2004 i686 athlon i386 GNU/Linux

Instance:
There are similar instances on the Internet, but they cannot be implemented correctly because the key jump code is not correctly calculated. (GCC version is incorrect)
/************
* A. c
************/
Void function (void)
{
Char buffer [5];
Int * ret;

Ret = buffer + 28;
(* Ret) + = 10;
}

Void main ()
{
Int x;

X = 0;
Function ();

X = 1;
Printf ("% d \ n", x );

Return;
}
/* End */

People who know the C language will think that the final output result is 1, but unfortunately the output result is 0. Why? Please explain.

Instance analysis:
I won't bother with the basic knowledge of related stacks. I have introduced a lot on the Internet.
The key issue lies in how to determine the source code.
Ret = buffer + 28;
(* Ret) + = 10;
28 and 10 in

Compile (there will be warning, don't worry about it .)
$ Gcc-g-o a. c // Add-g for debugging in gdb

$ Gdb
(Gdb) disas main // get the disassembly Code as follows:
Dump of worker er code for function main:
0x08048366: push % ebp
0x08048367: mov % esp, % ebp
0x08048369: sub $0x8, % esp
0x0804836c: and $0xfffffff0, % esp
0x0804836f: mov $0x0, % eax
0x08048374: sub % eax, % esp
0x08048376: movl $0x0, 0 xfffffffc (% ebp)
0x0804837d: call 0x8048348
0x08048382: movl $0x1, 0 xfffffffc (% ebp)
0x08048389: sub $0x8, % esp
0x0804838c: pushl 0 xfffffffc (% ebp)
0x0804838f: push $0x8048474
0x08048394: call 0x8048288
0x08048399: add $0x10, % esp
0x0804839c: leave
0x0804839d: ret
End of worker er dump.

(Gdb) disas function
Dump of worker er code for function:
0x08048348: push % ebp
0x08048349: mov % esp, % ebp
0x0804834b: sub $0x28, % esp
0x0804834e: lea 0xffffffe8 (% ebp), % eax
0x08048351: add $ 0x1c, % eax
0x08048354: mov % eax, 0xffffffe4 (% ebp)
0x08048357: mov 0xffffffe4 (% ebp), % edx
0x0804835a: mov 0xffffffe4 (% ebp), % eax
0x0804835d: mov (% eax), % eax
0x0804835f: add $ 0xa, % eax
0x08048362: mov % eax, (% edx)
Zero x 08048364: leave
0x08048365: ret
End of worker er dump.

When 0x0804837d: call 0x8048348 <function> is executed in main, the address of the next instruction is saved in the stack. that is, 0x08048382. Our purpose is to modify this value to the address 0x08048389 of the next instruction, so that the statement x = 1 is blocked. the key issue is how to find the address for saving the 0x08048382 value ....

Continue to use gdb
(Gdb) l // display the source code (because the-g parameter is used during compilation)
5
6 ret = buffer + 28;
7 (* ret) + = 10;
8}
9
10 void main ()
11 {
12 int x;
13
14 x = 0;

(Gdb) B 6 // observe the memory value at the critical point
Breakpoint 1 at 0x804834e: file a. c, line 6.
(Gdb) B 7
Breakpoint 2 at 0x8048357: file a. c, line 7.
(Gdb) r
Breakpoint 1, function () at rr. c: 6
6 ret = buffer + 28;
(Gdb) I reg // observe the register value (note ebp esp eip)
Eax 0x0 0
Ecx 0xbffff01c-1073745892
Edx 0xbfffefa0-1073746016
Ebx0xb75d4e58-1218621864
Esp 0xbfffef50 0xbfffef50
Ebp 0xbfffef78 0xbfffef78
Esi 0xbffff014-1073745900
Edi 0xb75d273c-1218631876
Eip 0x804834e 0x804834e
Eflags 0x200286 2097798
Cs 0x23 35
Ss 0x2b 43
Ds 0x2b 43
Es 0x2b 43
Fs 0x0 0
Gs 0x33 51

The value of esp is 0xbfffef50.
Check the data content after 0xbfffef50 in the memory.
(Gdb) x/20x $ esp
0xbfffef50: 0x080483a0 0x08049564 0xbfffef68 0x08048265
0xbfffef60: 0x00000000 0x00000000 0xbfffef88 0x080483ba
0xbfffef70: 0xb74ca4f3 0xb75d4e58 0xbfffef88 0x08048382
0xbfffef80: 0xb7600020 0x00000000 0xbfffefe8 0xb74b5748
0xbfffef90: 0x00000001 0xbffff014 0xbffff01c 0x00000000
We can find that 0x08048382 is saved in 0xbfffef7c, so 0xbfffef7c is what ret will store in our program.
(Gdb) p & buffer
$1 = (char (*) [5]) 0xbfffef60
So we can get the first data 28. As for 10, we can get it from the disassembly code (move to the next instruction ).

(Gdb) n
(Gdb) n // then we can see that 0x08048382 is changed to 0x0804838c

(Gdb) c
Continuing.
0

Program exited with code 02.

But the shellcode-specific Positioning method needs to be analyzed to realize overflow and improve permissions, but the principle is the same as above.

Finished ..