Advertisement

04.09.2008 at 11:03AM PDT, ID: 23309107
[x]
Attachment Details
[x]
The Solution Rating System

With so many solutions, how can you tell which solutions are most likely to help you and which ones are not? To provide you with a tool to use, we rate our solutions based on various elements that most accurately determine if a solution is a quality solution. To explain what factors affect the solution rating, here are the elements we take into consideration when formulating our solution rating.

  • The Grade of the Solution
  • The Zone Rank of the Expert Providing the Solution
  • The Number of Author and Expert Comments
  • The Number of Experts Contributing
  • The Feedback of the Community

Your Input Matters
Because of the way the system is set up, the most important variable in this equation is you. As a member of Experts Exchange, you are able to cast your vote on the quality of the solutions in regard to how complete, accurate, helpful and easy to understand each solution is. When you provide your feedback, each rating is adjusted accordingly. So, if you see a solution that has a poor rating that you think is a good solution, let us know by rating it. As you do, the rating will be adjusted and will become more accurate for other members of our site.

If you have any suggestions that you would like to make for our rating system, please ask a question in the Suggestions Zone of Community Support.

Thank you!

Determining the address of a variable/array using GDB?

Tags: overflow buffer determining address of a variable in assembly using GDB
hi. It is my first time using the site but I promise to grade generously and swiftly if your answer can steer me in the right direction.  I am working on a homework that has been asked about previously before:
http://www.experts-exchange.com/Programming/Languages/Assembly/Q_22967305.html
It's the same exact homework and entire assembly code of the executable if it helps you get a better idea, but I don't think you don't need to look at it to understand my problem.

I'm at the point where I have to locate the address of a particular array called buf which holds 12 chars (11 + implicit newline terminator character).  It is located in a function getbuf().  I've provided the C code and  assembly version of the code of getbuf() and my GDB session of my attempt to find the address.  The program is very simple:  you start it, enter an input, and the input is stored in buf.  The end-goal is to do buffer overflow and enter more than 12 chars so the program does more interesting things.  The problem I have is figuring out the address of the array buf (the base address, so buf[0]) so I can provide this to my input to "ret" (return) to them.  I am overwriting the entires in the array with machine instructions, so the goal is to basically provide the base address of the array as part of my input so the program ret to there.

The instructions say that we should use gdb to locate the address of the array.  We should break to getbuf and somehow find the address of buf.

I have tried to search for so many hours but everyone's buffer overflow tutorial on figuring out the address of buf assumes you have a symbol table available to you and you just need to  type x &buf to find it in gdb.  But if I do that in gdb, I get the error "No symbol table loaded"  So I need to find the address some other way...   but how?

if I look at the assembly code of getbuf, I can deduce the following:
in the lea -0xc(%ebp), %eax, it is allocating space of 12 ( -0xc) for the array buf and putting the address of ebp - 12  in register %eax. So I thought if I just find the address of %eax, which in the above gdb session, it shows it is  0xbf8e345c, I have found the base address of the array.   %ebp is  0xbf8e3468, according to the gdb session, and if we subtract 12 from that, we get 0xbf8e345c in %eax, as desired, right?

But when I try this (try to ret to 0xbf8e345c), the program complains 0xbf8e345c is an invalid instruction address.  Worse yet, every time I run the program, this address (0xbf8e345c) keeps changing (except for the 3 least significant bytes 45c which seem to remain fixed every time).  So if I were to do gdb again and look at %eax , it would be 0x?????45c.  Also, %ebp (frame pointer) and %esp (stack pointer) are changing every time I run gdb and do the same exact thing too (same exact input, but when I do info registers, it just is different each time)...I have no idea what I am doing because if they keep changing to some random address, how can I calculate this address right and accurately?

so this is where I'm at
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94:
95:
C:
int getbuf()
{
    char buf[12];
    /* Read line of text and store in buf */
    Gets(buf); 
    return 1;
}
 
Assembly:
08048f40 <getbuf>:
 8048f40:	55			push   %ebp
 8048f41:	89 e5			mov    %esp,%ebp
 8048f43:	83 ec 18		sub    $0x18,%esp
 8048f46:	8d 45 f4		lea    -0xc(%ebp),%eax
 8048f49:	89 04 24		mov    %eax,(%esp)
 8048f4c:	e8 7f fe ff ff		call   8048dd0 <Gets>
 8048f51:	b8 01 00 00 00		mov    $0x1,%eax
 8048f56:	c9			leave
 8048f57:	c3			ret
 8048f58:	90			nop
 8048f59:	8d b4 26 00 00 00 00	lea    0x0(%esi),%esi
 
GDB:
(gdb) break getbuf // Set up breakpoint to getbuf function after I type in my input
Breakpoint 1, 0x08048f46 in getbuf ()
 
 
(gdb) run < input.txt // Run the program with my input in a file input.txt
Starting program: bufbomb
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
 
 
(gdb) info frame // See what stack looks like?
Stack level 0, frame at 0xbf8e3470:
 eip = 0x8048f46 in getbuf; saved eip 0x8048f7e
 called by frame at 0xbf8e3490
 Arglist at 0xbf8e3468, args: 
 Locals at 0xbf8e3468, Previous frame's sp is 0xbf8e3470
 Saved registers:
  ebp at 0xbf8e3468, eip at 0xbf8e346c
 
 
(gdb) info registers // See what registers look like right now.
eax            0x3      3
ecx            0x0      0
edx            0x6d30b0 7155888
ebx            0x0      0
esp            0xbf8e3450       0xbf8e3450
ebp            0xbf8e3468       0xbf8e3468
esi            0x3      3
edi            0x8744018        141836312
eip            0x8048f46        0x8048f46 <getbuf+6>
eflags         0x286    [ PF SF IF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
 
 
(gdb) stepi // Move one more instruction.
0x08048f49 in getbuf ()
 
 
(gdb) info frame // See current stack information.
Stack level 0, frame at 0xbf8e3470:
 eip = 0x8048f49 in getbuf; saved eip 0x8048f7e
 called by frame at 0xbf8e3490
 Arglist at 0xbf8e3468, args: 
 Locals at 0xbf8e3468, Previous frame's sp is 0xbf8e3470
 Saved registers:
  ebp at 0xbf8e3468, eip at 0xbf8e346c
 
 
(gdb) info registers // See register information.  Notice eax should now have address of buf array.
eax            0xbf8e345c       -1081199524
ecx            0x0      0
edx            0x6d30b0 7155888
ebx            0x0      0
esp            0xbf8e3450       0xbf8e3450
ebp            0xbf8e3468       0xbf8e3468
esi            0x3      3
edi            0x8744018        141836312
eip            0x8048f49        0x8048f49 <getbuf+9>
eflags         0x386    [ PF SF TF IF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
Start your free trial to view this solution
Related Solutions: bufferbomb level2
Question Stats
Zone: Programming
Question Asked By: Destructive
Solution Provided By: Infinity08
Participating Experts: 1
Solution Grade: A
Views: 0
Translate:
Loading Advertisement...
04.09.2008 at 11:25AM PDT, ID: 21317641

Rank: Master

All comments and solutions are available to Premium Service Members only.

Start your 7-day free trial and see for yourself why Experts Exchange is the easiest and most proven technology resource in the world. Get Started

Already a member? Login to view this solution.

 
04.09.2008 at 01:05PM PDT, ID: 21318532

All comments and solutions are available to Premium Service Members only.

Start your 7-day free trial and see for yourself why Experts Exchange is the easiest and most proven technology resource in the world. Get Started

Already a member? Login to view this solution.

 
04.09.2008 at 01:16PM PDT, ID: 21318631

All comments and solutions are available to Premium Service Members only.

Start your 7-day free trial and see for yourself why Experts Exchange is the easiest and most proven technology resource in the world. Get Started

Already a member? Login to view this solution.

 
04.09.2008 at 01:37PM PDT, ID: 21318826

All comments and solutions are available to Premium Service Members only.

Start your 7-day free trial and see for yourself why Experts Exchange is the easiest and most proven technology resource in the world. Get Started

Already a member? Login to view this solution.

 
04.09.2008 at 02:41PM PDT, ID: 21319357

Rank: Master

All comments and solutions are available to Premium Service Members only.

Start your 7-day free trial and see for yourself why Experts Exchange is the easiest and most proven technology resource in the world. Get Started

Already a member? Login to view this solution.

 
04.09.2008 at 02:58PM PDT, ID: 21319484

All comments and solutions are available to Premium Service Members only.

Start your 7-day free trial and see for yourself why Experts Exchange is the easiest and most proven technology resource in the world. Get Started

Already a member? Login to view this solution.

 
 
Loading Advertisement...
20080236-EE-VQP-29 / EE_QW_2_20070628