Ответ 1
Основы просты. У Windows есть путь поиска для DLL, так же, как у него есть $PATH для поиска исполняемых файлов. Если вы можете выяснить, какие DLL-запросы запрашивают приложение без абсолютного пути (инициируя этот процесс поиска), вы можете разместить свою враждебную DLL где-то выше пути поиска, чтобы она была найдена до реальной версии, и Windows будет счастлива введите код атаки в приложение.
Итак, допустим, что ваш путь к поисковой системе DLL выглядит примерно так:
a) . <--current working directory of the application, highest priority, first check
b) \windows
c) \windows\system32
d) \windows\syswow64 <-- lowest priority, last check
и некоторое приложение Foo.exe запрашивает "bar.dll", который, как оказалось, живет в поддиректоре syswow64 (d). Это дает вам возможность поместить вашу вредоносную версию в пункты a), b) или c), и она будет автоматически загружена в приложение, когда приложение запрашивает bar.dll. И теперь ваш foo хорошо и trully bar'd.
Как указано выше, даже абсолютный полный путь не может защитить от этого, если вы можете заменить DLL своей собственной версией.
И, конечно же, это не ограничивается Windows. Любая ОС, которая позволяет динамически связывать внешние библиотеки, теоретически уязвима для этого.