For a while now, I’ve had some fun with simple buffer overflows under Microsoft’s Windows environment. Using either Ollydbg or Immunity debugger this was quite easy (well the learning curve wasn’t so bad). I’ve written a few posts and made a few simple videos showing the process. Nothing exciting but if it helped someone getting started, well I’m happy. For a long time I’ve been interested in trying the same thing on the Linux platform. Same principal really, just the tools charge… and what a change! Going from a nice and easy to follow graphic user interface:
To a black & white command line interface:
As you can see, the difference is subtle but there (sarcasm). My hope is this will be the first of many blog entries documenting my torment. I’ll be referencing “Hacking: The Art of Exploitation 2nd”, written by Jon Erickson, often throughout these entries. Most of the screen shots and vulnerable code used will be taken out of the book, or variations that I might whip out myself.
First thing I had to figure out with GDB was… where the heck is everything! Having been playing around with Immunity for so long (well 2 years isn’t long…), I was having trouble getting my bearings. Having to type in commands to see stuff I usually see right away under Windows. So this will be my first entry. Let’s compare what is where when comparing GDB to Immunity. Seeing that Windows and Linux are very different, comparing the two won’t be easy. I’ll be running the same application under Backtrack Linux (or I could say Backtrack GNU/Linux if Richard Stallman ever reads this) and Windows XP SP3 English Professional (and if Bill ever reads this, yes it’s a legit copy). Yes I know nothing will be the same, just doing this for consistency’s sake…
One thing that’s easy to find under Immunity (or Ollydgb) are the CPU registers. Usually found on the top of the windows and to the right.
Under GDB one needs to enter the “info registers” command.
As we can see, a little more information is displayed without any hassle with Immunity. Still everything is there. Typing the command can be shorten using “i r” (short for info registers). So far this is pretty easy.
Next up is the disassembled code, which is found top left corner (by default) in Immunity.
Using the “disassemble” command and giving it an address to start disassembling, you get something like the screenshot below. I choose EIP seeing that’s where both applications are “paused” at the moment.
The “Stack” is clearly shown in Immunity at the bottom right of the window. Automatically displaying stack changes depending on function calls and the application’s progress.
Under GDB (as far as I know so far) displaying this information is not so user friendly. Seeing that the ESP register points at the top of the stack, you need to examine it and decide how far down the stack you want displayed. The command expects 2 arguments, the location of the address and the format in which it’s displayed. I prefer the HEX format, but it can be displayed in octal, base-10 and binary.
As you can see, it will take some time to get used to. Having to type commands just to take a peek at something you may have just looked at a few moments ago. Taking notes using GDB is probably a good idea. There are GUIs out there for the debugger. Only tried one which comes installed on Backtrack 4. It seems to confirm everything I written into this little entry, but mistakes are possible. Remember I am writing this for two reasons. Firstly to learn and teach myself, taking notes and writing this as I go along. Secondly, taking my notes and typing them up in a blog entry format so others can follow along. So we have to expect some degree of inaccuracy.
So this is hopefully part one of many. Doing this has helped me better visualize where things are in GDB in relation to what I was used to in Ollydgb. Hope this helps a few kick start their brain as well.