Expiring Today—Celebrate National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

Determining the address of a variable/array using GDB?

Posted on 2008-04-09
9
Medium Priority
?
2,497 Views
Last Modified: 2010-04-21
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
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

Open in new window

0
Comment
Question by:Destructive
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 6
  • 3
9 Comments
 
LVL 53

Expert Comment

by:Infinity08
ID: 21317641
First of all, allow me to refer to the answers I gave in the other question (the one you posted the link for). It's a good reference in case you're unsure of how to approach this assignment.


>> %ebp is  0xbf8e3468, according to the gdb session, and if we subtract 12 from that, we get 0xbf8e345c in %eax, as desired, right?

And that's indeed the address of the buf.


>> But when I try this (try to ret to 0xbf8e345c), the program complains 0xbf8e345c is an invalid instruction address.

Why do you want to do that ? The point of a buffer overflow is to give more data as input than the buffer can hold. That extra data will then overwrite other memory used by different parts of the code.
In this case, the buffer is on the stack, so you'll be overwriting whatever comes after the buffer ... Find out what that is, and how you can "exploit" the buffer overflow by overwriting that value with data of your choice.
0
 

Author Comment

by:Destructive
ID: 21318532
hi Infinity08, thank you so much for your response...I have read your responses in the link, so many times, and it helped me to actually get to where he ended up being stuck at the end (which is where I am right now).  So I've finished those first two levels he was working on thanks to you and him, but I'm stuck at this part now.

It helped me to know that you confirmed this is the address of buf.  But basically, this is the syntax I am entering for my input to the program itself to maybe give you a better picture of what my train of thought is:

01 02 03 04 05 06 07 08 09 10 11 12  90 90 90 90 ** ** ** **

So as my input, I enter the format above.  The first 12 bytes correspond to the contents of buf I believe.

Then I need to add a "padding" of four bytes (four 90s, or four no ops, it doesn't matter what I enter, just four bytes of whatever).  So after these 16 bytes, if I enter in a valid memory address where those asterisk  are located (bytes 17 through 20), the program will actually "ret" (jump) to the address I specify in those four bytes.  This is what I had to do in the first two levels is ret to various functions in the program by supplying the address in those bytes.  I am overwriting the return address normally stored in those ** bytes with a different address.  So long as I enter the address in little endian of course.   So in theory, I thought if I did:

01 02 03 04 05 06 07 08 09 10 11 90 90 90 90 90 5c 34 8e bf
^                                                                                |
|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | From here, ret to where my machine instructions are (01 02 03...)

Where the first 16 bytes are actually machine instructions that I want to execute.
And the last 4 bytes are the address of buf in little endian:  0xbf8e345c

I thought it should "ret" me to 01 02 03...

So I thought if I put the address of buf where those asterisks are, the program should "ret" jump to the address of buffer and execute the machine instructions I am entering (01 02 03...), since those instructions are located beginning at buffer[0]?  I I mean, if I am not supposed to enter the buf's address in those bytes where I am overwriting the ret address, how can I get to my machine instructions?  I need to manipulate bytes 17-20 with an address, and I thought it should be buf address.. Is this not true?

...and I think I figured out that if I do not enter an input for the program, while  in gdb (just run the program and break to getbuf), the memory addresses of %ebp and %eax do not seem to change every time I run gdb.   it is still 0xbf8e345c like in my gdb session i posted here.  so that's good.

i will try some more options and see what i can do...maybe my machine instructions are the problem, not the address of buffer...

..also thanks for answering my other question about movl
0
 

Author Comment

by:Destructive
ID: 21318631
Sorry, for this part in my previous post:


01 02 03 04 05 06 07 08 09 10 11 90 90 90 90 90 5c 34 8e bf
^                                                                                |
|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | From here, ret to where my machine instructions are (01 02 03...)

I accidentally wrote 01 02 ... 11 90 90 90 90 90 (5 90s)
It meant what I wrote the first time (above that part):  01 02... 11 12 90 90 90 90 (4 90s)
0
Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

 

Author Comment

by:Destructive
ID: 21318826
OK I re-read what you said again:

"In this case, the buffer is on the stack, so you'll be overwriting whatever comes after the buffer ... Find out what that is, and how you can "exploit" the buffer overflow by overwriting that value with data of your choice."

 I have to admit I don't know what that is after the buffer (which is the the first 12 bytes of my input).  I mean, I know I have to add four more bytes of padding before I get to the part where I can modify the return address in getbuf (see lin.  What's occupying those bytes I don't really know.  I guess that should be my first objective before I do anything else?  I know that after those four bytes, I am overwriting the return address in bytes 17-20.
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 // Where I am overwriting the first twelve bytes
 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 // Where I am overwriting the return address in bytes 17-20
 8048f58:       90                      nop
 8048f59:       8d b4 26 00 00 00 00    lea    0x0(%esi),%esi

I will try thinking on it some more..thx for your speedy reply
0
 
LVL 53

Accepted Solution

by:
Infinity08 earned 2000 total points
ID: 21319357
>> I mean, I know I have to add four more bytes of padding before I get to the part where I can modify the return address in getbuf

Yes.

At this point in the code (just before this instruction) :

 8048f4c:       e8 7f fe ff ff          call   8048dd0 <Gets>

the stack looks like this :

        function return address
        ebp                                                   <--- ebp
        ...
        ...
        ...  <-\
        ...      |
        ...      |
        eax--/                                                <--- esp



>> So I've finished those first two levels he was working on thanks to you and him, but I'm stuck at this part now.

Can you explain what you did to pass them ? Just to verify, and make sure we're on the right track :)


I'm gonna get some sleep now, but I'll be back in a few hours ... Sorry.
0
 

Author Comment

by:Destructive
ID: 21319484
oh my goodness!  I GOT IT!!  thank you infinity08..

I have no idea what was my problem...but i was getting the wrong address when i was doing gdb for my buffer.  so %eax was giving me different values.. what i did was, just start all over again.  I re-wrote the machine code, got the hex values i needed all over again.  i guess i had some bug unrelated to this when i was running gdb.

but if not for you confirming for me that i was looking in the right place, for the address of buffer i might have strayed for days.. thank you so much!  you are truly an expert on assembly code...

i hope you don't mind, but i will probably ask another question soon about the next level(this is the last level)  tomorrow after i have had some time to think it over.  we will need to do something very similar to this...

Thank you for your diagram on the stack.  i will study it some more.  I will tell you I am not very comfortable with the stack so i appreciate your diagram greatly.   i will need to study it for the next level..because we must be careful when we overwrite the contents after buffer and restore them back to the stack or else it wont work this time.

about the first two levels...basically I did this:
Level 0:  Goal is to get address of function smoke.

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 ** ** ** **
Where bytes 1 through 16 are arbitrary bytes and can be anything (basically padding)
Where the ** refers to the address of function smoke in little endian.
This wil ret to smoke as desired.

Level 1:  Goal is to get to address of function fizz, but also change the paramter in fizz to your cookie
function fizz(int value)
So change value to cookie.  (By default, value is some number that is not your cookie.  I forgot which, but it doesn't matter because we just need to overwrite it with the value of our cookie)

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 ** ** ** ** xx xx xx !! !! !! !!
Where bytes 1 through 16 are arbitrary bytes and can be anything (basically padding)
Where the ** bytes refers to the address of function fizz in little endian (same placement as function smoke like previously)
Where the xx bytes refer to additional padding (no idea why we need them, just need them)
Where the !! bytes refer to your cookie (this will replace "value" to your cookie)

thanks again infinity, i really appreciate your extremely timely answers.
0
 

Author Closing Comment

by:Destructive
ID: 31447461
Thank you.  You are an expert on assembly.
0
 

Author Comment

by:Destructive
ID: 21319497
oh, and of course if i ask another question, it will be asked separately, not in this question.  Thanks again!
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 21322872
Great job :) I'm glad I could be of assistance.

And I look forward to your next question ;) I love these kind of exercises heh.
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

While opting for any web-to-print solution, you need to discuss with your team and some of your end users and know their opinions about your decisions. In this article we list down some questions you need to ask yourself.
If you are a mobile app developer and especially develop hybrid mobile apps then these 4 mistakes you must avoid for hybrid app development to be the more genuine app developer.
In this video you will find out how to export Office 365 mailboxes using the built in eDiscovery tool. Bear in mind that although this method might be useful in some cases, using PST files as Office 365 backup is troublesome in a long run (more on t…
In response to a need for security and privacy, and to continue fostering an environment members can turn to for support, solutions, and education, Experts Exchange has created anonymous question capabilities. This new feature is available to our Pr…

718 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question