Exetools - Creating a buffer overflow ?

Exetools (https://forum.exetools.com/index.php)

- General Discussion (https://forum.exetools.com/forumdisplay.php?f=2)

- - Creating a buffer overflow ? (https://forum.exetools.com/showthread.php?t=2512)

Creating a buffer overflow ?

As I understand it most buffer overflow exploits must be found by the cracker, and it must be able to influence the target variable once the overflow has occured.

Instead of just finding these overflow exploits, wouldn't it be possible to in fact force the buffer to overflow? i.e, If you somehow were able to manipulate the values of the bounds?

i.e

Quote:

Buffer Overflow: the Basics
A buffer is a contiguous allocated chunk of memory, such as an array or a pointer in C. In C and C++, there are no automatic bounds checking on the buffer, which means a user can write past a buffer. For example:

int main () {
int buffer[10];
buffer[20] = 10;
}

The above C program is a valid program, and every compiler can compile it without any errors. However, the program attempts to write beyond the allocated memory for the buffer, which might result in unexpected behavior. Over the years, some bright people have used only this concept to create havoc in the computer industry. Before we understand how they did it, let's first see what a process looks like in memory.

hxxp://www.linuxjournal.com/article.php?sid=6701

What I'm saying is that when you disassemble the program you should search for where that [10] is assigned in asm, and then change it to a [0]. That way the overflow would always occur.

Of course you probably wouldn't change the asm code, but you could do a live memory hack, like a simple game trainer does to change the [10] to a [0].

What would be the point of this? Considering the fact that most buffer exploits are doing over the intenet, where you don't have access to the machine to change any of the assembler - you only have the interface of the program that is running.

Secondly, once the program has compiled, trying to change a static buffer size to less than it was orignally set to would be very difficult, as if it was a global variable, it would most likely be a space in the exe, and local variables would simply be space on the stack.

Quote:

Originally posted by Squidge
What would be the point of this? Considering the fact that most buffer exploits are doing over the intenet, where you don't have access to the machine to change any of the assembler - you only have the interface of the program that is running.

Secondly, once the program has compiled, trying to change a static buffer size to less than it was orignally set to would be very difficult, as if it was a global variable, it would most likely be a space in the exe, and local variables would simply be space on the stack.

Edit: I mean for patching an RSA key or stuff like that.

If you want to do that, just write the process memory. No need for buffer overflow exploits.

Hehe, I once thought about this too.
The interesting point would be to find a possible weak point in the serial checking routines of e.g. some RSA 1024 based protection schemes. Then you maybe could break that scheme with a special buffer overflow serial.

And how do you think is it working?

Yeah, that'll be the difficult part ;)

I actually never tried to find a possible victim, as it's probably impossible, because e.g. GetDlgItemText, etc. all have a parameter that limits the length of text you can enter.
Furthermore, if there was an (easy) way to do, someone would probably have done it already.