I hope this is not a silly error. I've been having that error for a couple days and I can't figure out what is going on. Hopefully someone can find what I did wrong.


This is a very simple program, all it does is it ask the user for an X and Y value. Then the user can move that point by entering 'u' for up, 'r' for right, 'd' for down, 'l' for left and 's' to stop and end. I have tried to bulletproof the program so that even if you enter something like 'uawefawfawawf' only the first character will be checked and the rest will be dropped. Something weird is going on though. The value of y gets changed after I scan for a character when multiple characters are entered. Example:

x ? 4
y ? 5
4 , 5
Move ? uuuuu
---------Debug x : 4
---------Debug y : 7697781
4 , 7697782

What makes my Y change like that?

Edit: Also, what really throws me off is the fact the between the 'move ? ' and the 'debug', nothing is changing my Y.
Note: The reason 7697781 changes to 7697782 is because my code takes the first character 'u' and since it stands for up, it adds 1 to the Y. Since it's a loop, the first printf that prints the X and Y is executed again. (I didn't show the rest of the output.)

Post has been edited 1 time(s), last time on Nov 5 2011, 5:28 pm by Apos.

I just ran the above code and it worked fine in VS2010 in a C++ console application.



Not sure how you're getting a weird y value because I couldn't reproduce it.

You are scanning a string into a char:
char clear;
scanf("%s", &clear);

So its overflowing and you're facing the consequences. You should use %c not %s, or use getchar()

I'm guessing it depends on your compiler.

That worked! I wonder how I missed that... It also explains why Roy was not getting any error, his compiler is probably interpreting it differently. (Now I'm going to go hide in a corner.)

I don't understand why it was overflowing into Y... Do overflows really overflow in the other variables? Or it has to do with the variable' address?

A memory overflow is literally that - the content will be written into the memory addresses that is referenced, and then overflow into the following memory addresses.

If those memory addresses aren't used for anything, you're fine. If those memory addresses are used for variables, the variables will become corrupted. If those memory addresses hold executable instructions as part of the code, then during execution your program will attempt to execute that memory location and do whatever it has been interpreted as. This is how memory overflow exploits are written: a hacker finds a location in memory that can be overflowed and they examine the nearby memory addresses and craft the overflow in such a way that when it gets to an executable block it jumps to an entirely separate area of code (that they have installed or memory overflowed in another way) to carry out their malicious intent. For example with EUD actions a very clever person could write an EUD action in such a way that Starcraft would launch a keylogger or install a virus in the users computer, because EUD actions are a form of memory overflow (editing memory addresses that are not supposed to be edited).

Exploiting a memory overflow has always seemed mind-bogglingly difficult to me, but people do it. It also means that when you hear about "remote execution" bugs that are fixed in a windows update or whatever, that while the security flaw exists, it doesn't necessarily mean that anyone has actually written an exploit for it.

In the VC++ IDE, the default mode is debug mode and in that mode it puts extra padding around variables, IIRC.

Overflowing into the memory that contains the program's executable code isn't normally possible because the memory is read-only (at least on Windows I know this is the case). Exploitable memory overflows typically involve overwriting a return address stored on the stack to make a function return to a different place in memory when the return instruction is hit as functions are finished and return. The return address will be modified to try to point to the code that they are trying to execute.

Windows has long had the capability to mark memory with flags for whether it can be read, written, or have code executed from it. The latter was not enforced until processors supported a flag to mark which memory can or cannot have code executed from it. Windows uses this by marking code sections of a program as executable and all other sections in memory as non-executable (as of XP SP2). Server versions of Windows will by default enable this for all programs, but consumer versions will by default only do it for programs that opt in for it. This doesn't make exploits impossible, but it makes them more difficult since you can't directly get your exploit code executed. It is likely possible to construct data in the stack in such a way that a series of function calls are made, however. This could potentially be set up to download a program and run it. To counter that, many core Windows dll files have their addresses randomized so that it will be difficult for an exploit writer to embed the correct address of the function they want to call (as of Vista).