-3

Let's say I have an 

(int/char/..) array[10];

Can I access data outside of my programm (and by that hack or mess up stuff on my computer) using things like

array[-10000] = ...;
array[10] = ...;
array[1000] = ...;

Or is there some kind of limitation to a C-Program to keep Windows/other data secure? Because as far as I learned, you can access data outside of the array when inputting numbers bigger or smaller than the array allows it. How far out can you access data? I sometimes hear the windows-error sound when I run codes like the one above.

nobody
  • 19,814
  • 17
  • 56
  • 77
Firefighter123
  • 59
  • 1
  • 1
  • 4
  • 1
    See https://stackoverflow.com/questions/15646973/how-dangerous-is-it-to-access-an-array-out-of-bounds (the answer will be pretty much the same in MacOS, Windows, or any other consumer grade operating system: this may crash your program, but a good OS should keep it fairly isolated and not affect unrelated processes) – Flight Odyssey Dec 29 '18 at 18:37
  • 1
    (I don't know why your question was closed as too broad, it seems to me that it is probably a duplicate of the link above and maybe other questions as well, but definitely not overly broad given how well that similar question was received) – Flight Odyssey Dec 29 '18 at 18:39
  • Thank you. :) Can you please mark it as a duplicate of that question, I don't know how to. That other question is exactly the answer I neeed, I just didn't search the right keywords as it seems. – Firefighter123 Dec 29 '18 at 18:41
  • @FlightOdyssey ; Too broad perhaps because the "duplicate" is specifically about the consequences of out-of-bounds array access in C, whereas this is about whether it is possible to "hack" Windows by such method - it is a question about the Windows operating system behaviour, rather then the C programming language. Also, older questions that might get short-shrift today on SO often got a better reception when SO was hungry for content. Now it has reached critical mass, there is a different view of what constitutes a good question perhaps. – Clifford Dec 29 '18 at 18:51
  • @Clifford I suppose, but if anything I think this question is more specific, not less. Rather than just "what happens if I go out-of-bounds on an array" it's "what happens if I got out-of-bounds on an array - specifically in windows, could it compromise the security of my machine?" But I agree with the general change in norms related to older questions vs. newer, that is probably the main factor here – Flight Odyssey Dec 29 '18 at 19:17
  • @Firefighter123 `Come on, it's a good simple question.`... Says the guy who posted it. – Deanie Dec 29 '18 at 19:30
  • @Deanie Yes, because I tried making my question as clear and simple as possible. With "good" i meant easy to understand. Can't make that any clearer, can you? – Firefighter123 Dec 29 '18 at 19:33
  • @FlightOdyssey ; If not too broad, then possibly off-topic. Personally I'd not have voted either way, but I shall not vote to reopen either as I think the answer lies in the design of Windows' memory protection which is a "general computing and software" question, and well documented elsewhere: https://learn.microsoft.com/en-us/windows/desktop/memory/memory-protection. It is certainly not a C programming language issue. – Clifford Dec 30 '18 at 14:07
  • @Clifford I didn't know about that. How am I supposed to know. In university we learned, that you can acess data outside of a an array, by removing the Null-Pointer at the end and such stuff. We never learned, that windows splits tasks up, and doesn't let them interact with each other's memory. And when putting my question into Google it didn't tell me that. Kinda mean to give me so many downvotes for that question, how am I supposed to know that. ONTOP OF THAT, my teacher told me you can hack windows by creating an image, which is larger, than its meant to be. I thought this would be the same – Firefighter123 Jan 02 '19 at 21:56
  • No downvote from me. Operating system security is not a C programming language issue or specific to C programming. How are you supposed to know that? By studying operating systems. Are you studying C, software security, or operating systems? A typical buffer overrun attack works by modifying the stack frame such that when a function returns it jumps to an incorrect address where code has been injected to allow the attacker's intended code to run, from whence it can take control - the memory modified by the overrun still belongs to the attacked process. – Clifford Jan 02 '19 at 22:43
  • Don't confuse a null-pointer with a NUL _character_ used as a string terminator. They are not the same thing. – Clifford Jan 02 '19 at 22:45

2 Answers2

2

Windows and other major operating systems use virtual memory so that each running program (process) can’t access or interfere with the memory being used by other programs. Barring a security bug in the OS, you shouldn’t be able to read or write memory from other processes by reading off the ends of arrays.

The noise you’re reporting may be due to the “audible bell” character given by the escape sequence \a. If you print this character, Windows responds by playing a noise. This character is sometimes found randomly in memory, so if you walk off an array and print the contents you’ll sometimes hear sounds. That’s not a security issue - that’s the intended behavior of printing that character.

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
1

You can't do that on any modern OS, because the memory visible to your application is not the actual physical RAM in your PC. When you take the address of an object, what you actually see is a virtual address, you don't know if and where it is actually located in RAM. Any memory address you try to access, is checked and translated by the memory management unit. If you try to access an invalid address, your application will just crash, but no other process should be affected.

Please note that this is an oversimplification of what actually happens.

Fun fact: due to the virtual memory "trick", windows can actually give each 64bit application more than 100GB of memory, even if you have far less physical RAM (but don't be surprised by the abysmal performance if you actually try to use that much)

Felix G
  • 674
  • 1
  • 7
  • 17