#c #pointers
#c #указатели
Вопрос:
Я пытаюсь понять указатели и интересуюсь некоторыми вещами. Например, если я запускаю ту или иную программу, могу ли я изменить значения некоторых шестнадцатеричных чисел, которые не используются этой программой? Делает ли ОС что-то, чтобы защитить себя?
int num1 = 1;
int num2 = 2;
int *var1,var2;
var2 = num1 num2;
var1 = amp;var2;
for (int counter1 = 0; counter1 < 100000; counter1 ) {
*(var1 counter1) = 0;
}
Комментарии:
1. Зависит от платформы, но большинство операционных систем. Другие времена остались позади, около 40 лет назад. Как среда выполнения отреагирует на это — это другой вопрос. Неопределенное поведение.
2. Программа просто имеет неопределенное поведение. Хотя в большинстве случаев подобный код вызывает ошибку seg, поскольку считывает / изменяет ограниченную память.
3. Спасибо за ответы, но как тогда программы редактора памяти получают доступ к этой памяти?
4. Даже внутри программы это может легко привести к сбоям. Если вы перезаписываете что-либо в стеке вызовов, обычно происходит сбой при возврате функции или вскоре после этого. При записи в стек вызовов вы можете перезаписать локальные переменные, и если это классы с виртуальными функциями или деструкторами, вероятность сбоя высока. Даже для базовых типов это может привести к разного рода проблемам, таким как преобразование строк или индексов с нулевым завершением в массив.
5. Кроме того, поскольку ваш код содержит неопределенное поведение, конечная программа может не выполнять то, что вы думаете, потому что оптимизатор иногда предполагает, что программа не содержит неопределенного поведения для выполнения некоторой оптимизации, такой как изменение порядка инструкций. Из-за этого несколько бессмысленно пытаться понять программу, содержащую неопределенное поведение . Кроме того, компилятор может заметить, что записанная память никогда не используется, и удалить этот код.
Ответ №1:
В большинстве современных ОС память вашего процесса изолирована от памяти любого другого процесса и самой ОС. Таким образом, хотя ваш код может испортить память вашего собственного процесса и нанести большой ущерб, вы не можете нанести вред другим процессам таким образом, и вы не можете нанести вред ОС.
Краткая историческая справка: так было не всегда, и это все еще не так в некоторых операционных системах (обычно для встроенных устройств, специализированной электроники и т. Д.). В таких ситуациях вы можете полностью уничтожить память всей системы и других процессов. Это одна из причин того, что версии Windows до Windows XP (ME, 95, 3.1 и т. Д.) Были Настолько нестабильными. Один мошеннический процесс может вывести из строя всю систему.
Привилегированный код обычно может считывать или записывать память других процессов, даже сегодня.
Комментарии:
1. Не могли бы вы открыть «Привилегированный код», пожалуйста, вы имеете в виду права администратора?
2. Не только права администратора, процессы (во всяком случае, в Windows) имеют токены безопасности, и вам может потребоваться повышение для доступа к памяти процесса. Что вы можете сделать, если у вас есть права администратора, но это должно быть явно запрошено. Смотрите Документы WriteProcessMemory, на которые ссылается другой комментатор.
Ответ №2:
Я думаю, это зависит от того, где вы его запускаете, но обычно существует защита памяти, что означает, что вы не можете просто записывать вне памяти процессов.
Комментарии:
1. Имеет смысл, но существуют программы редактирования памяти, что означает, что они могут обращаться к памяти других программ. Как они это делают тогда?
2. @RisenShadow Иногда ОС предоставляет функции, например, в Windows есть ReadProcessMemory и WriteProcessMemory . Я не уверен насчет Linux, но я думаю, что ptrace можно использовать для подобных вещей.
3. @RisenShadow В основном ОС будет изменять доступ к памяти каждый раз, когда происходит переключение контекста потока (процесса). Таким образом, каждая программа обычно имеет доступ только к своей собственной памяти (изолированной среде).
4. @Phil1970 но по-прежнему не объясняет, как программы редактирования памяти получают к ним доступ
5. @likle ссылки на ReadProcessMemory и WriteProcessMemory являются отличным дополнением к вашему ответу, спасибо!