В этой статье я покажу, как, например, с помощью WinDbg найти, какой такой зловред (или нет) заменил адрес вызова системной функции в DLL, подгружаемым каким-нибудь приложением. Так я, к примеру, искал почему не загружается модуль защиты в конфигурацию 1С.
Для демонстрации нам понадобится приложение, которое загружает пару DLL: одну из них назовём victim (жертва), другую — хищник injector. Последнняя внедряется в жертву, заменяя вызов системной функции (для простоты возьмём Sleep), и будет вызывать AV при определённых условиях (что понадобится в следующей статье).  Т.к. приложения, написанные на Delphi, "не падают" в core-dump из-за необработаных исключений, то наше главное приложение (DLLInjectionDemo) написано на С, линковано ранним связыванием с DLL-жертвой, а для простоты воспроизведения ситуации, будет загружать DLL-injector, переданную в опциях при запуске, и вызывать в ней метод, который навредит жертве. Конкретно для этой статьи нам подошло бы приложение, написанное на любом языке программирования, но убьём двух зайцев сразу. Исходные коды приложений написаны на C и Delphi 10.3 Rio Community Edition, и компилируются MinGW и Delphi, как для Win32, так и для Win64 (а также FPC в Lazarus-е). Итак компилируем обе DLL и главное приложение для сборки make-ом от MinGW нужно прописать его в PATH, конечно и запускаем главное приложение без параметров: Затем запускаем с параметрами -L injector (напомню, что это для того, чтобы эмулировать поведение, когда у приложения уже что-то не так перед вызовом нужной функции) Тут мы видим, что наше приложение ведёт себя странно, и вместо Sleep происходит что-то неожиданное. Мы смотрим в код нашего приложения и ничего не понимаем (а также представим, что это происходит со слов пользователя программы). Тогда мы просим пользователя снять дамп приложения с помощью менеджера задач (и да, я не сделал GUI-версию, так что, для того, чтобы можно было снять дамп приложения во время его работы, я добавил ключ -i(interactive)). Так что запускаем Приложение работает (в данном случае просто ждёт ввода пользователя). Снимаем дамп этого процесса: вызываем диспетчер задач, закладку процессы, находим процесс, правая кнопка мыши, в меню выбираем "Создать файл дампа процесса...", ждём показа сообщения о завершении снятия дампа и из него копируем или запоминаем путь к файлу дампа. Затем берём в руки отладчик WinDbg, и открываем в нём этот дамп: из меню File — Open Crash Dump (Ctrl+D) или из командной строки сразу: %PROGRAM FILES%\Windows Kits\10\Debuggers\x64\windbg.exe" -z C:\Users\demo\App Data\Local\Temp\DLLInjectionDemo.DMP подсказке For analysis of this file, run !analyze -v пока следовать не будем (хотя любопытствующие могут и последовать, ничего страшного не произойдёт). Нас интересует IAT — таблица адресов импорта (Import Address Table) — DLL, в которой произошла подмена адреса (почему? потому что мы знаем, что сами хотим заменить адрес в IAT ;) ). К счастью, для анализа всех PE-структур загруженных модулей (будь то DLL или процесс) отладчик WinDbg из Windows 10 SDK (который легко и непринуждённо ставится в том числе и на Windows 7) уже имеет встроенные средства, не вынуждая нас самим отправляться на "странные берега", как бы мы это сделали в WinDbg 6, например. Так что воспользуемся своим счастьем. Сначала найдём адреса загруженных модулей: lm Nota bene: На 32-битной ОС адреса, естественно отличаются от 64-битных... Убеждаемся, что наши DLL загружены, нам нужна IAT жертвы, для этого достаточно выполнить команду !dh с ключом -a: !dh 009c0000 -a  или можно прям листаем до таблиц импорта kernel32.dll (в которой находится нужная нам функция Sleep) Nota bene: На 32-битной ОС количество секций_IMAGE_IMPORT_DESCRIPTOR отличается от таковых на 64-битной. Последнее, вероятно, связано с разницей компиляторов Delphi для этих платформ. Видим, что базовый адрес этой функции отличается от т.е. 0000000076ed0000 Найдём куда же ведёт этот адрес, другими словами — какому модулю он принадлежит? В WinDbg команда lm имеет опцию а для этого: Ага, вот кто виноват! Только нам как будто непонятно что это за модуль. Посмотрим пристальней (укажем ключ v для lm) А вот где находится наш виновник! Image path: C:\Users\demo\injector.dll Дальше выясняем уже откуда он взялся и как его удалить, но это уже история нас не касается. Вот так и мне в реальных условиях достаточно быстро удалось найти на предустановленной ОС от производителя некую странную DLL, которая перехватывала вызов функции WriteFile. Приложение из этой статьи я использую в следующей, в которой хочу показать читателю, как можно с помощью WinDbg выяснить почему (или хотя бы примерно где) приложение упало с Access Violation, произошедшим в DLL, написанном на Delphi, когда удалённая отладка недоступна по какой-либо причине. При том, что Delphi не имеет средств анализа дампа приложения, и не умеет генерировать PDB-файлы. системный разработчик