Learning with DVRF - Step 13 - Stack buffer overflow - Phase 2

Step 13 - Stack buffer overflow - Phase 2 There are many ways people approach investigation and reverse engineering of a binary. A method that is still valid to perform is a “strings” against the binary. Who knows what kind of gems we can knock loose from performing a static analysis of a binary. Let’s recap the phases to explore with the stack buffer overflow challenge:

Phase 1 - Run it to see how it works
Phase 2 - Run floss/strings - Initial static analysis Phase 3 - Examine it with readelf/objdump - More static analysis
Phase 4 - Examine it with gdb/pwndbg - Dynamic analysis Phase 5 - Exploit it

Phase 2 - Run floss/strings (static analysis):

1. A possible second phase of testing is to examine the binary for any helpful strings that may be inside the binary. For instance, some CTF challenges may have the flag in cleartext that could be revealed with a simple “strings” examination. The “strings” program has different iterations from vendors/companies like SysInternals (owned by Microsoft) who make their own versions across operating systems. A strings program typically examines a binary for strings of text and other information (e.g. library information) and outputs that information. FireEye recently put out a new approach to “strings” which they call “floss”. In this phase, we will use floss to examine the challenge.
   
2. You can download the standalone floss binary from FireEye's GitHub page. I have already downloaded the standalone copy of floss (1.3.0 at the time of this writing) and placed it in my Documents folder. You can place this binary anywhere convenient for you.
   
3. Open up a new Terminal and browse to the location you have floss downloaded
   
4. Run floss on the stack_bof_01 challenge file
   
   
   
5. From floss, we can see a few things such as printf and the libc used:
   
   
   
6. We can see specifically that a “strcpy” function call is within this binary. We can see from sources like OWASP, MITRE, Exploit-DB, and well known researchers that the “strcpy” function is prone to being exploited.
   
7. A little bit further down we can see plaintext from within the binary:
   
   
   
8. With this challenge, there is some interesting information gleaned from this phase. We see in the strings above that if we perform some kind of correct sequence of “something”, we can get a congratulatory message saying “/bin/sh” will be performed. However, from phase 1, we entered in junk data and did not get the good message. Instead, we got the echo statement (%s) of what we sent as input and a “Try Again” message. So this at least tells us that we need to do something to get past where we were stopped in phase 1.
   
9. At the end of the floss output, we see the message “ERROR:floss:FLOSS currently supports the following formats for string decoding and stackstrings: PE”. Since this binary is an ELF file, we probably would not have been able to have any encoded messages decoded for us.
   

Floss, strings, or a similar tool is just something additional to try to see if anything good can be easily leaked out of the binary to help us out. We will continue our investigation to understand this challenge in Phase 3!