AWBO Buffer Overflow Exercise

[lupin]

I think the bad chars problem is being originated from the method I'm currently using. Is there a better way to send the string to the program when it's opened with immdbg?

Im assuming awbo2.exe takes input via STDIN - in a command shell perhaps? (I havent tried it myself...)

Id probably first try to use your script to write those same characters to a file, and then check that file with a Hex editor to confirm it contains exactly what you wanted (this will eliminate the script as a potential cause of the problem).

If the script seems to work as expected, then try it again with awbo2.exe, but each time you try it replace one of the unique characters with something you know that is good (\x42 for example), and see if that changes the structure of the buffer once it gets into memory in the debugger. This is how you identify bad characters. The first one Id try is the \x00 - its a string terminator and is often a bad character in buffer overflows entered in this manner.

[trojanrs]

Im assuming awbo2.exe takes input via STDIN - in a command shell perhaps?

Yes, that's correct.
I could not redirect the output of that command to a file so I built a program(just gets input without any filters) in order to analise the memory after input. In fact, the problem is indeed on my script, since \xeb could not be found in the memory with the rest of the test string I sent...

Can someone think about other methods of sending the attack string in this case?

Thanks lupin for the help so far =)

[lupin]

Yes, that's correct.
I could not redirect the output of that command to a file so I built a program(just gets input without any filters) in order to analise the memory after input. In fact, the problem is indeed on my script, since \xeb could not be found in the memory with the rest of the test string I sent...

Can someone think about other methods of sending the attack string in this case?

Thanks lupin for the help so far =)

Maybe write it to a binary file and then input the contents of the file into the awbo2.exe program via command line redirection.

e.g.

File "badbuffer" contains your data in binary format (use perl or python or a hex editor or your other tool of choice to create the file with binary data in it.)

Then run awbo2.exe like so:

awbo2.exe <badbuffer

[trojanrs]

ok, I've created the binary file with a python script and checked it with an hex editor, everything was as I expected it to be, but when I ran the command the program crashed...
Can I use this method with awbo2.exe attached to the debugger?
I've also searched for some immunity script that could insert the string into stdin but no success there...

[lupin]

ok, I've created the binary file with a python script and checked it with an hex editor, everything was as I expected it to be, but when I ran the command the program crashed...
Can I use this method with awbo2.exe attached to the debugger?
I've also searched for some immunity script that could insert the string into stdin but no success there...

You're right of course, this method makes it difficult to attach a debugger.

Haven't had a chance to try it yet, but something like this may work.

[trojanrs]

I've used the plugin you sugested and it worked like a charm!
I've tested the exploit with the windows/exec payload and booom, calculator!

Steps to a calculator =) :
1- Insert attack string into program's stdin (awbo2.exe < bin)
2- Catch execution with olly's plugin (Catcha!)
3- Overflow and jump to a pop pop ret
4- Return execution to jump short
5- Run jump backwards assembly code
6- Jump to NOPs
7- Decode and execute payload

Seems very simple now...
Thank you very much for the help provided!

[lupin]

Seems very simple now...
Thank you very much for the help provided!

Happy to help. I appreciate it when I can respond to a thread like this without having to spoonfeed, it makes a nice change from what usually happens when I respond to threads in the Newbie forum...