Security Summer School

User Tools

Site Tools

session:04-gdb

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
session:04-gdb [2014/07/02 23:43]
rcaragea 		session:04-gdb [2020/07/19 12:49] (current)
Line 1: Line 1:
-====== Session 04 Extra ======+====== Refresher. Taming GDB ======
  
 Although it is a powerful tool, gdb is pretty cumbersome to use by itself. Even simple tasks such as execution tracing are made difficult by the lack of "friendliness". Although it is a powerful tool, gdb is pretty cumbersome to use by itself. Even simple tasks such as execution tracing are made difficult by the lack of "friendliness".
 To overcome this, we're going to use a wrapper over gdb that greatly enhances its default functionality. This tool is called "Python Exploit Development Assistance for GDB", in short: peda. To overcome this, we're going to use a wrapper over gdb that greatly enhances its default functionality. This tool is called "Python Exploit Development Assistance for GDB", in short: peda.
 Even though there are lots of goodies included in it we're going to go only over what we need right now. Even though there are lots of goodies included in it we're going to go only over what we need right now.
- 
  
 ====== Installation ====== ====== Installation ======
Line 29: Line 28:
 set history size 32768 set history size 32768
 set history expansion on set history expansion on
 +
 +# By default peda clears the screen after most commands, displaying a single
 +# context frame at a time and allowing you to access the previous/next frame
 +# using Shift+PageUp/Shift+PageDown. However, that might not work in your
 +# terminal, leaving you unable to access any older information. If that is the
 +# case, uncomment the following line:
 +#
 +#pset opt clearscr off
 </file> </file>
 ====== Basic stuff ====== ====== Basic stuff ======
 The most common actions done in gdb are: setting breakpoints, stepping through program execution and examining memory. The following are commands you need to know: The most common actions done in gdb are: setting breakpoints, stepping through program execution and examining memory. The following are commands you need to know:
   * ''run [args]'' => restart the program with [args] as args   * ''run [args]'' => restart the program with [args] as args
-  * ''stepi'' => execute the current instruction and go to the next one - if it's a call instruction go to that subroutine (step into) +  * ''stepi'' (or simply ''si'') => execute the current instruction and go to the next one - if it's a call instruction go to that subroutine (step into) 
-  * ''nexti'' => execute the current instruction and go to the next one - if it's a call instruction execute the whole subroutine in the background (step over) +  * ''nexti'' (or simply ''ni'') => execute the current instruction and go to the next one - if it's a call instruction execute the whole subroutine in the background (step over) 
-  * ''break'' => set a permanent breakpoint on an address or function+  * ''break'' (or simply ''b'') => set a permanent breakpoint on an address or function
   * ''info break'' => display all current breakpoints set   * ''info break'' => display all current breakpoints set
   * '' delete 2'' => delete the breakpoint with index 2 (from the list of current breakpoints)   * '' delete 2'' => delete the breakpoint with index 2 (from the list of current breakpoints)
-  * ''continue'' => continue execution after hitting a breakpoint (or receiving a signal)+  * ''continue'' (or simply ''c'') => continue execution after hitting a breakpoint (or receiving a signal)
   * ''hexdump <addr> [/NR]'' => dump NR lines of memory starting from <addr>. (by default NR is 1)   * ''hexdump <addr> [/NR]'' => dump NR lines of memory starting from <addr>. (by default NR is 1)
   * ''x /s <addr>'' => dump a **string** starting from <addr> (''/100s'' would dump 100 strings)   * ''x /s <addr>'' => dump a **string** starting from <addr> (''/100s'' would dump 100 strings)
   * ''x /wx <addr>'' => dump a **dword** starting from <addr> (''/100wx'' would dump 100 dwords)   * ''x /wx <addr>'' => dump a **dword** starting from <addr> (''/100wx'' would dump 100 dwords)
  
 +<note info>
 +
 +In order to provide command line arguments to a program run under gdb we can use (assume the name of the program is ''test'' and the command line arguments are ''arg0 arg1 arg2''):
 +<code bash>
 +gdb test
 +... # GDB banner is skipped
 +gdb-peda$ run arg0 arg1 arg2 
 +</code>
 +
 +In order to redirect both ''stdin'' and ''stdout'' to two separate files, we can use (the name of the program is still ''test'' and thetwo files that we redirect to and from are ''inputfile'' and ''outputfile''):
 +<code bash>
 +gdb test
 +... # GDB banner is skipped
 +gdb-peda$ run < inputfile > outputfile
 +</code>
 +
 +Obviously, one could combine the two examples into one, meaning that command line arguments, standard input and standard output are all controlled from inside GDB. This is great for debugging your exploits in an automated way.
 +<code bash>
 +gdb test
 +... # GDB banner is skipped
 +gdb-peda$ run arg0 arg1 arg2 < inputfile > outputfile
 +</code>
 +</note>
 +
 +===== Practice the basic stuff =====
 Let's find out how to do these on a previous crackme from session 01.Remember that the point was that it implemented a custom ''my_strcmp'' function such that ltrace/strace did not work. We now redo that task using gdb-peda: Let's find out how to do these on a previous crackme from session 01.Remember that the point was that it implemented a custom ''my_strcmp'' function such that ltrace/strace did not work. We now redo that task using gdb-peda:
  
Line 148: Line 180:
 Breakpoint 1, 0x080484fc in my_strcmp () Breakpoint 1, 0x080484fc in my_strcmp ()
 </code> </code>
-If you remember from the last session, the parameters passed to a function are on the stack. Because we have just arrived at this function using a ''call'' instruction, the return address is placed at the top of the stack (0x8048620). Immediately afterwards are the two parameters to the function: with "bla bla bla" being my input and "WXXHYIWE5yWic9vnmMGlA" the correct input.+If you remember from the last session, the parameters passed to a function are on the stack. Because we have just arrived at this function using a ''call'' instruction, the return address is placed at the top of the stack (0x8048620). Immediately afterwards are the two parameters to the function: with "bla bla bla" being my input and "WXXHYIWE5yWic9vnmMGlA" the correct input (obviously, the two should match, therefore your job now is to input the value that the program expects).
  
 Note that peda automatically //telescopes// addresses (dereferences and interprets the data) Note that peda automatically //telescopes// addresses (dereferences and interprets the data)
Line 247: Line 279:
   * Download level01 from Smash the stack and solve it using peda. Break on ''*main'', step through the execution and figure out what it does and how to crack it.   * Download level01 from Smash the stack and solve it using peda. Break on ''*main'', step through the execution and figure out what it does and how to crack it.
 <code> <code>
-$ scp level1@io.smashthestack.org:/levels/level01 . # Password is level1+$ scp level1@io.netgarage.org:/levels/level01 . # Password is level1
 </code> </code>
  
session/04-gdb.1404333804.txt.gz · Last modified: 2014/07/02 23:43 by rcaragea

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki