Почему исполняемый файл работает без использования `VirtualAlloc` и `VirtualProtect`, несмотря на DEP

Delphi , ОС и Железо , Windows

Почему исполняемый файл работает без использования VirtualAlloc и VirtualProtect, несмотря на DEP

В данной статье мы рассмотрим вопрос, связанный с механизмами защиты памяти в операционных системах и спецификой работы кода, загруженного из внешнего файла. Вопрос задан в контексте разработки на языке Object Pascal (Delphi), что делает его особенно актуальным для разработчиков, использующих эту среду.

Описание проблемы

Пользователь столкнулся с ситуацией, когда загруженный в память исполняемый файл работает корректно, несмотря на отсутствие использования функций VirtualAlloc и VirtualProtect. Эти функции обычно используются для выделения и изменения прав доступа к участкам памяти, что может быть необходимо для выполнения кода из внешних источников. Однако в данном случае код выполняется, что вызывает вопросы о том, как это возможно и не противоречит ли это политике защиты памяти (Data Execution Prevention, DEP).

Анализ кода

Для начала рассмотрим представленный фрагмент кода, который загружает исполняемый файл в память и выполняет его:

var
  MySrcArray,
  MyDestArray: array [1 .. 15] of Byte;
  // ...
  MyBuffer: Pointer;
  TheProc: procedure;
  SortIt: procedure(ASrc, ADest: Pointer; ASize: LongWord); stdcall;
begin
  // Инициализация массива MySrcArray случайными байтами
  // ...
  // Загрузка бинарного файла в MyBuffer с использованием функции GetMem
  @SortIt := MyBuffer;
  try
    SortIt(@MySrcArray, @MyDestArray, 15);
    // Отображение результата обработки MyDestArray
  except
    // Обработка ошибок выполнения кода
  end;
  // Освобождение памяти
end;

Почему код работает?

Ключевым моментом является то, что DEP по умолчанию включен не для всех программ, а работает в режиме "по приглашению" (opt-in). Это означает, что программе необходимо явно разрешить выполнение кода из определенных участков памяти.

В контексте 32-битных программ, если изменить настройки DEP на "Включить DEP для всех программ и служб, кроме тех, которые я выберу", то приложение будет вызывать предупреждение о DEP и аварийно завершать работу.

Подтвержденный ответ

Таким образом, код работает, потому что либо он не попадает под действие DEP (например, если используется в 32-битной среде, где DEP отключен или не активирован для текущего процесса), либо система не распознает его как исполняемый код по каким-то причинам (например, ошибка в идентификации исполняемых модулей). Важно отметить, что использование такого подхода может быть небезопасным и потенциально привести к срабатыванию защиты от вредоносных программ.

Альтернативный ответ

Возможной альтернативой может быть то, что код содержит инструкции, которые не интерпретируются как исполняемые в контексте DEP, например, из-за специфики платформы или настройки системы безопасности.

Заключение

В статье мы рассмотрели, как код, загруженный из внешнего файла, может выполняться без использования функций VirtualAlloc и VirtualProtect, что обычно требуется для обхода DEP. Мы выяснили, что DEP работает в режиме opt-in, и если настройки системы не запрещают выполнение кода из загруженного файла, то такой код может выполняться успешно. Тем не менее, разработчикам следует быть осторожными и понимать потенциальные риски, связанные с обходом механизмов защиты памяти.

Создано по материалам из источника по ссылке.

Контекст вопроса связан с механизмами защиты памяти в операционных системах, в частности с DEP (Data Execution Prevention), и с возможностью выполнения кода из внешнего файла без использования функций `VirtualAlloc` и `VirtualProtect`, что обычно требует

Комментарии и вопросы

Получайте свежие новости и обновления по Object Pascal, Delphi и Lazarus прямо в свой смартфон. Подпишитесь на наш Telegram-канал delphi_kansoftware и будьте в курсе последних тенденций в разработке под Linux, Windows, Android и iOS

:: Главная :: Windows ::