The risk of damaging your computer by changing memory in C ++

I know some Java, and now I'm trying to use C ++ and apparently in C ++, you can do things like declare an int array of size 6, and then change the 10th element of this array, which I understand it's just the fourth byte after the end of the memory partition that was allocated for the 6 integer array.

So my question is: if I am sloppy, is it possible to accidentally change the memory in my C ++ program, which is used by other programs on my system? Is there a real risk of seriously confusing something in this way? I mean, I know that you can just restart the computer and clear the memory if you need to, but if I do not, there can be some serious damage.

+6
source share
7 answers

It depends on your system. Formally, access beyond undefined access. In a modern general-purpose system, each user process has its own address space, and one process cannot change or even read another process (prohibiting shared memory), therefore, if you do not use it by writing kernel code, you cannot break anything outside your own process (and non-kernel code usually cannot do physical IO, so I don’t see how something in the hardware can break).

If you write kernel code or work on an embedded processor without converting or protecting memory, you can literally destroy hardware outside of the write; if the program controlling something like a nuclear power plant, you can even destroy a lot more than just the machine your code is running on.

+12
source

Each process is assigned its own virtual address space, so natural processes do not see each other's memory. Do not forget that even a buffer overflow that is local to your program can have terrible consequences - an overflow can lead to program malfunction and do something that has a lasting effect (for example, deleting all files).

+6
source

It depends on which operating system and environment you are in:

  • Normal operating system (Windows, Linux, etc.): you can mess up your own process memory. However, having a real setback can be enough. Imagine, for example, that you are calling a function that deletes files. If your memory is damaged during a call, the function parameters may be mixed up, which means deleting something else than you planned. Until you invoke file deletion procedures, etc. In programs where you test memory processing, this risk does not exist.
  • Normal OS, kernel space device driver: you can access the system memory and the memory of the current process, possibly destroy everything.
  • Simple integrated OS without memory protection: you can access everything and destroy everything.
  • Legacey OS without memory protection (Win 3.X, MS-DOS): you can access everyone and destroy everything.
+3
source

Each program works in its own address space, and one program cannot access (read / change) any other program address space (this is a memory management technology called swap).

If you try to access an address in memory that your program cannot read, this will cause segmentation or page failure, and your program will crash.

No permanent damage will be caused in response to your question.

+2
source

I'm not sure if a modern OS (especially win7) allows you to do this. OS blocks buffer overflow action as you described

0
source

During the day (DOS), some viruses will try to damage the hardware by directly programming a video or hard disk controller, but even then it was not easy or confident. Modern hardware and OS make it almost impossible for user level applications to damage the hardware. So the program away :) you will not break anything.

0
source

There is another possibility. Having a buffer overflow can allow ill-fated people to use this error and execute arbitrary code on your client computer. I think this is bad. And the most dangerous part about overflowing is that you cannot find it even after a serious over-test.

0
source

Source: https://habr.com/ru/post/893482/


All Articles