Как найти зловреда (нет) с WinDbg

Вступление

В этой статье я покажу, как, например, с помощью 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 и главное приложение

> msbuild /t:build victim.dproj /p:Platform=Win32;Config=Debug;DCC_Exeoutput=.
> msbuild /t:build injector.dproj /p:Platform=Win32;Config=Debug;DCC_Exeoutput=.
> mingw32-make

для сборки make-ом от MinGW нужно прописать его в PATH, конечно

и запускаем главное приложение без параметров:

C:\Users\demo>DLLInjectionDemo.exe
Sleeping 100 milliseconds
Done!

Затем запускаем с параметрами -L injector (напомню, что это для того, чтобы эмулировать поведение, когда у приложения уже что-то не так перед вызовом нужной функции)

c:\Users\demo>DLLInjectionDemo.exe -L injector
Loading injector
Searching...
oleaut32.dll
advapi32.dll
user32.dll
kernel32.dll
kernel32.dll
user32.dll
version.dll
kernel32.dll
kernel32.dll
netapi32.dll
oleaut32.dll
Injected
Sleeping 100 milliseconds
New sleep instead of 100
Done!

Тут мы видим, что наше приложение ведёт себя странно, и вместо Sleep происходит что-то неожиданное. Мы смотрим в код нашего приложения и ничего не понимаем (а также представим, что это происходит со слов пользователя программы). Тогда мы просим пользователя снять дамп приложения с помощью менеджера задач (и да, я не сделал GUI-версию, так что, для того, чтобы можно было снять дамп приложения во время его работы, я добавил ключ -i(interactive)). Так что запускаем

c:\Users\demo>DLLInjectionDemo.exe -i -L injector
Loading injector
Searching...
oleaut32.dll
advapi32.dll
user32.dll
kernel32.dll
kernel32.dll
user32.dll
version.dll
kernel32.dll
kernel32.dll
netapi32.dll
oleaut32.dll
Injected
Sleeping 100 milliseconds
New sleep instead of 100
Done!
Press ENTER...

Приложение работает (в данном случае просто ждёт ввода пользователя). Снимаем дамп этого процесса: вызываем диспетчер задач, закладку процессы, находим процесс, правая кнопка мыши, в меню выбираем "Создать файл дампа процесса...", ждём показа сообщения о завершении снятия дампа и из него копируем или запоминаем путь к файлу дампа.

Затем берём в руки отладчик 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

Loading Dump File [C:\Users\alex\AppData\Local\Temp\DLLInjectionDemo.DMP]
User Mini Dump File with Full Memory: Only application data is available

Symbol search path is: srv*
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Thu Jul  4 08:46:18.000 2019 (UTC + 3:00)
System Uptime: 17 days 12:25:45.404
Process Uptime: 0 days 0:00:10.000
........................
For analysis of this file, run !analyze -v
ntdll!NtRequestWaitReplyPort+0xa:
00000000`77bcddfa c3              ret

подсказке 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

0:000> lm
start             end                 module name
00000000`003b0000 00000000`003db000   injector   (deferred)             
00000000`00400000 00000000`00412000   DLLInjectionDemo   (deferred)             
00000000`00520000 00000000`00616000   victim     (deferred)             
00000000`6e580000 00000000`6e5b4000   libmingwex_2   (deferred)             
00000000`72870000 00000000`72886000   netapi32   (deferred)             
...

Nota bene: На 32-битной ОС адреса, естественно отличаются от 64-битных...

Убеждаемся, что наши DLL загружены, нам нужна IAT жертвы, для этого достаточно выполнить команду !dh с ключом -a:

!dh 009c0000 -a

или можно прям

0:000> !dh victim -a

File Type: DLL
FILE HEADER VALUES
     14C machine (i386)
       A number of sections
5E5F4251 time date stamp Wed Mar  4 09:53:21 2020

       0 file pointer to symbol table
       0 number of symbols
      E0 size of optional header
    A18E characteristics
            Executable
            Line numbers stripped
            Symbols stripped
            Bytes reversed
            32 bit word machine
            DLL

OPTIONAL HEADER VALUES
     10B magic #
    2.25 linker version
   CE400 size of code
   1BA00 size of initialized data
       0 size of uninitialized data
   CF79C address of entry point
    1000 base of code
         ----- new -----
0000000000400000 image base
    1000 section alignment
     200 file alignment
       2 subsystem (Windows GUI)
    5.00 operating system version
    0.00 image version
    5.00 subsystem version
   F6000 size of image
     400 size of headers
       0 checksum
0000000000000000 size of stack reserve
0000000000000000 size of stack commit
0000000000100000 size of heap reserve
0000000000001000 size of heap commit
       0  DLL characteristics
   DD000 [      A4] address [size] of Export Directory
   DA000 [    105C] address [size] of Import Directory
   F3000 [    2A00] address [size] of Resource Directory
       0 [       0] address [size] of Exception Directory
       0 [       0] address [size] of Security Directory
...

листаем до таблиц импорта kernel32.dll (в которой находится нужная нам функция Sleep)

Nota bene: На 32-битной ОС количество секций_IMAGE_IMPORT_DESCRIPTOR отличается от таковых на 64-битной. Последнее, вероятно, связано с разницей компиляторов Delphi для этих платформ.

...
  _IMAGE_IMPORT_DESCRIPTOR 00000000005fa03c
    kernel32.dll
              005FA398 Import Address Table
              005FA11C Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

       003C7C7C    0 Sleep
       76EE184A    0 VirtualFree
       76EE1832    0 VirtualAlloc
       76EE16DC    0 lstrlenW
       76EE4422    0 VirtualQuery
       76EE110C    0 GetTickCount
...

Видим, что базовый адрес этой функции отличается от

0:000> !dh kernel32

File Type: DLL
FILE HEADER VALUES
     14C machine (i386)
       4 number of sections
5708A7E3 time date stamp Sat Apr  9 10:57:39 2016

...
         ----- new -----
0000000076ed0000 image base
...

Найдём куда же ведёт этот адрес, другими словами — какому модулю он принадлежит?

В WinDbg команда lm имеет опцию а для этого:

0:000> lma 003C7C7C    
Browse full module list
start             end                 module name
00000000`003b0000 00000000`003db000   injector   (deferred)             

Ага, вот кто виноват! Только нам как будто непонятно что это за модуль. Посмотрим пристальней (укажем ключ v для lm)

0:000> lma 003C7C7C v
Browse full module list
start             end                 module name
00000000`003b0000 00000000`003db000   injector   (deferred)             
    Image path: z:\habr\DLLInjectionDemo\injector.dll
    Image name: injector.dll
    Browse all global symbols  functions  data
    Timestamp:        Wed Mar  4 09:53:12 2020 (5E5F4248)
    CheckSum:         00000000
    ImageSize:        0002B000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

А вот где находится наш виновник!

Image path: C:\Users\demo\injector.dll

Дальше выясняем уже откуда он взялся и как его удалить, но это уже история нас не касается.

Вот так и мне в реальных условиях достаточно быстро удалось найти на предустановленной ОС от производителя некую странную DLL, которая перехватывала вызов функции WriteFile.

Приложение из этой статьи я использую в следующей, в которой хочу показать читателю, как можно с помощью WinDbg выяснить почему (или хотя бы примерно где) приложение упало с Access Violation, произошедшим в DLL, написанном на Delphi, когда удалённая отладка недоступна по какой-либо причине. При том, что Delphi не имеет средств анализа дампа приложения, и не умеет генерировать PDB-файлы.