В первой части мы рассмотрели проблему, когда драйвер перезаписывает данные в страницах чужого пула. В этой части мы рассмотрим как можно определить проблемный драйвер.
Как уже было сказано единственный путь определение проблемного драйвера это использование утилиты Driver Verifier. При этом используется механизм специального пула. Суть его работы представлена на изображении ниже.
Для каждого такого специального пула выделяется 4Кб памяти и такой пул хранится в собственной странице.
Область обозначенная как “Slop bytes” используется при проверке освобождения памяти, если здесь происходит какая-либо попытка освободить память генерируется крах и указывается драйвер, который это делает.
Область обозначенная как “Guard Page No Access” используется для отслеживания попытки записи в нее. Если это происходит генерируется крах и указывается драйвер, который это делает.
По умолчанию специальный пул отключен, давайте активируем его и проверим работу на NotMyFault из первой части. Вначале запускаем NotMyFault.exe она загружает драйвер в память, теперь выполняем:
verifier /flags 1 /driver myfault.sys
и перегружаем компьютер.
Запускаем notmyfault и выбираем “buffer overflow” и нажимаем “Crash”.
Выполняем анализ дампа.
Microsoft (R) Windows Debugger Version 6.3.9600.17298 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:Downloads!Mini080915-04.dmp] Mini Kernel Dump File: Only registers and stack trace are available ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred srv*C:Symbols*http://msdl.microsoft.com/download/symbols Symbol search path is: srv*C:Symbols*http://msdl.microsoft.com/download/symbols Executable search path is: Windows Server 2008/Windows Vista Kernel Version 6002 (Service Pack 2) UP Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Built by: 6002.18005.x86fre.lh_sp2rtm.090410-1830 Machine Name: Kernel base = 0x81a08000 PsLoadedModuleList = 0x81b1fc70 Debug session time: Sun Aug 9 15:32:55.687 2015 (UTC + 3:00) System Uptime: 0 days 0:04:00.344 Loading Kernel Symbols ............................................................... ................................................................ ......................... Loading User Symbols Loading unloaded module list .... Unable to load image myfault.sys, Win32 error 0n2 *** ERROR: Module load completed but symbols could not be loaded for myfault.sys ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 100000D6, {a3b95000, 1, 9ab1561d, 0} Could not read faulting driver name Probably caused by : myfault.sys ( myfault+61d ) Followup: MachineOwner --------- kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6) N bytes of memory was allocated and more than N bytes are being referenced. This cannot be protected by try-except. When possible, the guilty driver's name (Unicode string) is printed on the bugcheck screen and saved in KiBugCheckDriver. Arguments: Arg1: a3b95000, memory referenced Arg2: 00000001, value 0 = read operation, 1 = write operation Arg3: 9ab1561d, if non-zero, the address which referenced memory. Arg4: 00000000, (reserved) Debugging Details: ------------------ Could not read faulting driver name WRITE_ADDRESS: GetPointerFromAddress: unable to read from 81b3f868 Unable to read MiSystemVaType memory at 81b1f420 a3b95000 FAULTING_IP: myfault+61d 9ab1561d 880c02 mov byte ptr [edx+eax],cl MM_INTERNAL_CODE: 0 CUSTOMER_CRASH_COUNT: 4 DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT BUGCHECK_STR: 0xD6 PROCESS_NAME: NotMyfault.exe CURRENT_IRQL: 0 ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) amd64fre LAST_CONTROL_TRANSFER: from 9ab15a24 to 9ab1561d STACK_TEXT: WARNING: Stack unwind information not available. Following frames may be wrong. 9afcabc8 9ab15a24 a3a4ef68 9afcac0c 9ab15b26 myfault+0x61d 9afcabd4 9ab15b26 9a52a990 00000001 00000000 myfault+0xa24 9afcac0c 81cea6be 9a49adf0 a3a4ef68 9a52a990 myfault+0xb26 9afcac30 81a4c92d a3a4efd8 a3a4ef68 9a49adf0 nt!IovCallDriver+0x23f 9afcac44 81c4e6a1 9a52a990 a3a4ef68 a3a4efd8 nt!IofCallDriver+0x1b 9afcac64 81c4ee46 9a49adf0 9a52a990 00000000 nt!IopSynchronousServiceTail+0x1d9 9afcad00 81c4ff10 9a49adf0 a3a4ef68 00000000 nt!IopXxxControlFile+0x6b7 9afcad34 81a52c7a 00000090 00000000 00000000 nt!NtDeviceIoControlFile+0x2a 9afcad34 77435e74 00000090 00000000 00000000 nt!KiFastCallEntry+0x12a 0025f294 00000000 00000000 00000000 00000000 0x77435e74 STACK_COMMAND: kb FOLLOWUP_IP: myfault+61d 9ab1561d 880c02 mov byte ptr [edx+eax],cl
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: myfault+61d
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: myfault
IMAGE_NAME: myfault.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4f806ca0
FAILURE_BUCKET_ID: 0xD6_myfault+61d
BUCKET_ID: 0xD6_myfault+61d
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0xd6_myfault+61d
FAILURE_ID_HASH: {5b7d79f2-2066-4a9a-3bdc-50cdc9e973f2}
Followup: MachineOwner
---------
Как видим, благодаря Driver Verifier и опции специальный пул, определение подобных ошибок намного упрощается.