Dwdg sys что это за файл
Обновлено: 04.07.2024
| Конфигурация компьютера | |
| Процессор: Intel Core i7-3770K | |
| Материнская плата: ASUS P8Z77-V LE PLUS | |
| Память: Crucial Ballistix Tactical Tracer DDR3-1600 16 Гб (2 x 8 Гб) | |
| HDD: Samsung SSD 850 PRO 256 Гб, WD Green WD20EZRX 2 Тб | |
| Видеокарта: ASUS ROG-STRIX-GTX1080-O8G-11GBPS | |
| Звук: Realtek ALC889 HD Audio | |
| Блок питания: be quiet! Straight Power 11 650W | |
| CD/DVD: ASUS DRW-24B5ST | |
| Монитор: ASUS VG248QE 24" | |
| ОС: Windows 8.1 Pro x64 | |
| Индекс производительности Windows: 8,1 | |
| Прочее: корпус: Fractal Design Define R4 |
| Как решить проблему? Помогите. Стоп произошел при входе в спящий режим или в спящем режиме. |
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time (usually 10 minutes).
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: ffffe001ca5dc060, Physical Device Object of the stack
Arg3: ffffd0014b1b8960, nt!TRIAGE_9F_POWER on Win7, otherwise the Functional Device Object of the stack
Arg4: ffffe001c7ab73e0, The blocked IRP
Irp is active with 5 stacks 4 is current (= 0xffffe001c7ab7588)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace. Pending has been returned
cmd flg cl Device File Completion-Context
[ 0, 0] 0 2 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 ffffffffc000000e
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 16, 0] 0 2 ffffe001ca5dc060 00000000 fffff800d1a4b164-ffffe001cd4d1010
\Driver\pci nvlddmkm
Args: 00000000 00000000 00000000 00000000
>[ 16, 2] 0 e1 ffffe001cb774040 00000000 fffff8026cb2bc30-ffffe001cdb12210 Success Error Cancel pending
\Driver\nvlddmkm nt!PopRequestCompletion
Args: 00000000 00000001 00000001 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-ffffe001cdb12210
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[ 16, 0] 0 e1 ffffe001cc8266e0 00000000 fffff800d2efefd0-00000000 Success Error Cancel pending
\Driver\HidUsb mouclass!MouseClassPowerComplete
Args: 00000005 00000000 00000000 00000000
[ 16, 0] 0 e1 ffffe001cc84acf0 00000000 fffff8026cb2bc30-ffffe001c7bf24d0 Success Error Cancel pending
\Driver\mouclass nt!PopRequestCompletion
Args: 00000005 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-ffffe001c7bf24d0
Args: 00000000 00000000 00000000 00000000
ffffe001cb774040 \Driver\nvlddmkm ffffe001cb774190 InfoMask field not found for _OBJECT_HEADER at ffffe001cb774010
ffffe001cbb69040 Unable to load image \SystemRoot\system32\drivers\dwdg.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for dwdg.sys
*** ERROR: Module load completed but symbols could not be loaded for dwdg.sys
\Driver\DwDevGuard ffffe001cbb69190 InfoMask field not found for _OBJECT_HEADER at ffffe001cbb69010
ffffe001ca5dd8d0 \Driver\ACPI ffffe001c7b07010
> ffffe001ca5dc060 \Driver\pci ffffe001ca5dc1b0 Cannot read info offset from nt!ObpInfoMaskToOffset
!DevNode ffffe001ca5dd530 :
DeviceInst is "PCI\VEN_10DE&DEV_0FE1&SUBSYS_06861025&REV_A1\4&2b084dbe&0&0008"
ServiceName is "nvlddmkm"
\Driver\nvlddmkm
fffff8026ccc8970: Unable to get value of ObpRootDirectoryObject
Driver object \Driver\nvlddmkm not found <---Почему
\Driver\ACPI DriverObject ffffe001c73b7e60
Current Irp 00000000 RefCount 0 Type 00000032 Flags 00000000
DevExt ffffe001c7b07010 DevObjExt ffffe001ca5dda20
ExtensionFlags (0000000000)
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffe001cbb69040 \Driver\DwDevGuard <---И тут Доктор Веб
AttachedTo (Lower) ffffe001ca5dc060 \Driver\pci
Device queue is not busy.
BIOS Information
Vendor Insyde Corp.
BIOS Version V2.16
BIOS Release Date 01/14/2013
BaseBoard Information
Manufacturer Acer
Product VA70_HC
Chassis Type Notebook
В конце января мы анализировали мнение экспертов компании AV-TEST, специализирующейся на защите данных. Тогда они заявили, что ещё два года пользователям Windows 7 не грозят массовые атаки. При этом они призвали всех тех, кто опасается за сохранность своих данных, установить бесплатную антивирусную программу Microsoft Security Essentials. Как выяснилось, угроза существует, мало того она масштабна и несёт потенциальную угрозу миллионам компьютеров.
реклама
Вымогатель по имени Робин Гуд (RobbinHood) впервые был обнаружен в 2018 году. Опасная программа получала полный доступ к компьютеру жертвы, шифровала файлы и требовала выкуп в размере 10 000 долларов. Мало того, если пользователь не оплачивал в указанный срок, сумма выкупа увеличивалась ежедневно на те же 10 000 долларов. Ещё в 2018 году звучали подозрения, что виной всему драйвера Gigabyte, но только сейчас компания признала свою вину. Заражение происходит следующим способом: исполняемый файл Steel.exe, который находится в пакете Gigabyte gdrv.sys, распаковывает файл ROBNR.EXE, который отвечает за установку самого драйвера от Gigabyte и вредоносного ПО.
Первым делом Робин Гуд удаляет антивирус. Эксперты по безопасности Sophos заявляют, что они впервые видят такой уровень атаки. Ещё никогда вредоносная программа не использовала надёжный драйвер для проникновения в систему. По их мнению, это открывает настоящий ящик Пандоры, когда десятки и даже сотни разработчиков подобного ПО будут активно эксплуатировать такой метод.
Наиболее опасной в этом смысле видится позиция Gigabyte. Вместо того, чтобы решить вопрос, выпустив обновлённый драйвер для своих материнских плат, производитель отказался от его поддержки. Что любопытно, в новой операционной системе Windows 10 опасность заражения не столь велика, поскольку универсальные драйвера от Microsoft способны закрыть подобную дыру на большинстве новых материнских плат, не затрагивая только наиболее старые модели. Совсем другая ситуация в Windows 7. Там пользователь оказывается один на один с Робином, спастись от которого невозможно.
1. Когда и после чего это началось ?
2. Win+R
control system
скриншот окна в развернутом на весь экран, виде
3. Win+R
appwiz.cpl
посмотрите, нет ли в списке программ антивируса Bitdefender ?
4. Какой антивирус установлен ? Не Kaspersky часом ?
Сергей, здравствуйте, судя по всему, спустя несколько дней после установки Касперского. Касаемо второго вопроса, что конкретно вы бы хотели увидеть. Отвечая на третий вопрос, хочется сказать, что этой программки в списке нет. Антивирус, вы правы, бесплатный неполный касперский.
1. Хотел бы увидеть скриншот окна на весь экран после исполнения команды control system в окне "Выполнить", которое вызывается сочетанием клавиш Win+R. Команда control system покажет окно свойств системы, иногда там можно увидеть некоторые зацепки. В частности - оригинальная ли это сборка Microsoft или неоригинальная.
2. Примерно, как часто появляется данный синий экран ? Несколько раз в день ?
Пока неясно, но для начала ответьте на предыдущих два вопроса. Все эти нюансы важны. Не просто так спрашиваю.
Если отвечать вот так сразу, без уточняющих вводных, то предположительно причина в драйвере Kaspersky. А почему он сбоит, тут уже много причин может быть. Может проблемы с диском, может с файловой системой или системными файлами Windows, может в неоригинальных драйверах, установленных до этого (например драйверы, установленных с помощью сторонней программы DirverPack), может проблемы с оперативной памятью, может с обновлениями Windows. Поэтому я и задаю уточняющие вопросы, чтобы сузить круг поиска и уточнить контекст проблемы.
Нет, около раза в день. Например, вчера не было, причём после довольно длительной работы.
И уточните, какой именно продукт Kaspersky у вас установлен, можно и номер версии (вдруг у кого-то подобная проблема была и она решилась обновлением версии например).
Лёня, про "базовый" не совсем понятно. Т.е. еще что-то от компании Kaspersky осталось в списке установленных программ ?
Меня всегда интересовало низкоуровневое программирование – общаться напрямую с оборудованием, жонглировать регистрами, детально разбираться как что устроено. Увы, современные операционные системы максимально изолируют железо от пользователя, и просто так в физическую память или регистры устройств что-то записать нельзя. Точнее я так думал, а на самом деле оказалось, что чуть ли не каждый производитель железа так делает!
В чём суть, капитан?
В архитектуре x86 есть понятие «колец защиты» («Ring») – режимов работы процессора. Чем ниже номер текущего режима, тем больше возможностей доступно исполняемому коду. Самым ограниченным «кольцом» является «Ring 3», самым привилегированным – «Ring -2» (режим SMM). Исторически сложилось, что все пользовательские программы работают в режиме «Ring 3», а ядро ОС – в «Ring 0»:
Режимы работы x86 процессора
В «Ring 3» программам запрещены потенциально опасные действия, такие как доступ к I/O портам и физической памяти. По логике разработчиков, настолько низкоуровневый доступ обычным программам не нужен. Доступ к этим возможностям имеют только операционная система и её компоненты (службы и драйверы). И всё бы ничего, но однажды я наткнулся на программу RW Everything:
RW Everything действительно читает и пишет практически всё
Эта программа была буквально напичкана именно теми функциями, которые обычно запрещаются программам «Ring 3» - полный доступ к физической памяти, I/O портам, конфигурационному пространству PCI (и многое другое). Естественно, мне стало интересно, как это работает. И выяснилось, что RW Everything устанавливает в систему прокси-драйвер:
Смотрим последний установленный драйвер через OSR Driver Loader
Прокси-драйвера
В итоге получается обходной манёвр – всё, что программе запрещено делать, разработчик вынес в драйвер, программа устанавливает драйвер в систему и уже через него программа делает, что хочет! Более того – выяснилось, что RW Everything далеко не единственная программа, которая так делает. Таких программ не просто много, они буквально повсюду. У меня возникло ощущение, что каждый уважающий себя производитель железа имеет подобный драйвер:
Софт для обновления BIOS (Asrock, Gigabyte, HP, Dell, AMI, Intel, Insyde…)
Софт для разгона и конфигурации железа (AMD, Intel, ASUS, ASRock, Gigabyte)
Софт для просмотра сведений о железе (CPU-Z, GPU-Z, AIDA64)
Софт для обновления PCI устройств (Nvidia, Asmedia)
Во многих из них практически та же самая модель поведения – драйвер получает команды по типу «считай-ка вот этот физический адрес», а основная логика – в пользовательском софте. Ниже в табличке я собрал некоторые прокси-драйвера и их возможности:
Результаты краткого анализа пары десятков драйверов. Могут быть ошибки!
Mem – чтение / запись физической памяти
PCI – чтение / запись PCI Configuration Space
I/O – чтение / запись портов I/O
Alloc – аллокация и освобождение физической памяти
Map – прямая трансляция физического адреса в вирутальный
MSR – чтение / запись x86 MSR (Model Specific Register)
Жёлтым обозначены возможности, которых явно нет, но их можно использовать через другие (чтение или маппинг памяти). Мой фаворит из этого списка – AsrDrv101 от ASRock. Он устроен наиболее просто и обладает просто огромным списком возможностей, включая даже функцию поиска шаблона по физической памяти (!!)
Неполный перечень возможностей AsrDrv101
Чтение / запись RAM
Чтение / запись IO
Чтение / запись PCI Configuration Space
Чтение / запись MSR (Model-Specific Register)
Чтение / запись CR (Control Register)
Чтение TSC (Time Stamp Counter)
Чтение PMC (Performance Monitoring Counter)
Alloc / Free физической памяти
Поиск по физической памяти
Самое нехорошее в такой ситуации - если подобный драйвер остаётся запущенным на ПК пользователя, для обращения к нему не нужно даже прав администратора! То есть любая программа с правами пользователя сможет читать и писать физическую память - хоть пароли красть, хоть ядро пропатчить. Именно на это уже ругались другие исследователи. Представьте, что висящая в фоне софтина, красиво моргающая светодиодиками на матплате, открывает доступ ко всей вашей системе. Или вирусы намеренно ставят подобный драйвер, чтобы закрепиться в системе. Впрочем, любой мощный инструмент можно в нехороших целях использовать.
Через Python в дебри
Конечно же я захотел сделать свой небольшой "тулкит" для различных исследований и экспериментов на базе такого драйвера. Причём на Python, мне уж очень нравится, как просто выглядит реализация сложных вещей на этом языке.
Первым делом нужно установить драйвер в систему и запустить его. Делаем "как положено" и сначала кладём драйвер (нужной разрядности!) в System32:
Раньше в похожих ситуациях я извращался с папкой %WINDIR%\Sysnative, но почему-то на моей текущей системе такого алиаса не оказалось, хотя Python 32-битный. (по идее, на 64-битных системах обращения 32-битных программ к папке System32 перенаправляются в папку SysWOW64, и чтобы положить файлик именно в System32, нужно обращаться по имени Sysnative).
Затем регистрируем драйвер в системе и запускаем его:
А дальше запущенный драйвер создаёт виртуальный файл (кстати, та самая колонка "имя" в таблице с анализом дров), через запросы к которому и осуществляются дальнейшие действия:
И ещё одна полезная программа для ползания по системе, WinObj
Тоже ничего особенного, открываем файл и делаем ему IoCtl:
Вот здесь чутка подробнее. Я долго думал, как же обеспечить адекватную обработку ситуации, когда таких "скриптов" запущено несколько. Не останавливать драйвер при выходе нехорошо, в идеале нужно смотреть, не использует ли драйвер кто-то ещё и останавливать его только если наш скрипт "последний". Долгие упорные попытки получить количество открытых ссылок на виртуальный файл драйвера ни к чему не привели (я получал только количество ссылок в рамках своего процесса). Причём сама система точно умеет это делать - при остановке драйвера с открытым файлом, он остаётся висеть в "Pending Stop". Если у кого есть идеи - буду благодарен.
В конечном итоге я "подсмотрел", как это делают другие программы. Выяснилось, что большинство либо не заморачиваются, либо просто ищут запущенные процессы с тем же именем. Но одна из исследованных программ имела кардинально другой подход, который я себе и перенял. Вместо того, чтобы переживать по количеству ссылок на файл, просто на каждый запрос открываем и закрываем файл! А если файла нет, значит кто-то остановил драйвер и пытаемся его перезапустить:
А дальше просто реверсим драйвер и реализуем все нужные нам вызовы:
Легко и непринуждённо в пару команд читаем физическую память
PCI Express Config Space
Немного отвлечёмся на один нюанс про PCIE Config Space. С этим адресным пространством не всё так просто - со времён шины PCI для доступа к её конфигурационному пространству используется метод с использованием I/O портов 0xCF8 / 0xCFC. Он применён и в нашем драйвере AsrDrv101:
Чтение и запись PCI Config Space
Но через этот метод доступны только 0x100 байт конфигурационного пространства, в то время как в стандарте PCI Express размер Config Space у устройств может быть достигать 0x1000 байт! И полноценно вычитать их можно только обращением к PCI Extended Config Space, которая замаплена где-то в адресном пространстве, обычно чуть пониже BIOS:
Адресное пространство современного x86 компа, 0-4 ГБ
На чипсетах Intel (ну, в их большинстве) указатель на эту область адресного пространства можно взять из конфига PCI устройства 0:0:0 по смещению 0x60, подробнее описано в даташитах:
У AMD я такого не нашёл (наверняка есть, плохо искал), но сам факт неуниверсальности пнул меня в сторону поиска другого решения. Погуглив стандарты, я обнаружил, что указатель на эту область передаётся системе через ACPI таблицу MCFG
А сами ACPI таблицы можно найти через запись RSDP, поискав её сигнатуру по адресам 0xE0000-0xFFFFF, а затем распарсив табличку RSDT. Отлично, здесь нам и пригодится функционал поиска по памяти. Получаем нечто такое:
На всякий случай оставляем вариант для чипсетов Intel
Всё, теперь осталось при необходимости заменить чтение PCI Express Config Space через драйвер на чтение через память. Теперь-то разгуляемся!
Читаем BIOS
В качестве примера применения нашего "тулкита", попробуем набросать скрипт чтения BIOS. Он должен быть "замаплен" где-то в конце 32-битного адресного пространства, потому что компьютер начинает его исполнение с адреса 0xFFFFFFF0. Обычно в ПК стоит флеш-память объёмом 4-16 МБ, поэтому будем "сканировать" адресное пространство с адреса 0xFF000000, как только найдём что-нибудь непустое, будем считать, что тут начался BIOS:
В результате получаем:
Вот так в 10 строчек мы считали BIOS
Но подождите-ка, получилось всего 6 мегабайт, а должно быть 4 или 8 что-то не сходится. А вот так, у чипсетов Intel в адресное пространство мапится не вся флешка BIOS, а только один её регион. И чтобы считать всё остальное, нужно уже использовать SPI интерфейс.
Не беда, лезем в даташит, выясняем, что SPI интерфейс висит на PCI Express:
И для его использования, нужно взаимодействовать с регистрами в BAR0 MMIO по алгоритму:
Задать адрес для чтения в BIOS_FADDR
Задать параметры команды в BIOS_HSFTS_CTL
Прочитать данные из BIOS_FDATA
Пилим новый скрипт для чтения через чипсет:
Исполняем и вуаля - в 20 строчек кода считаны все 8 МБ флешки BIOS! (нюанс - в зависимости от настроек, регион ME может быть недоступен для чтения).
Точно так же можно делать всё, что заблагорассудится - делать снифер USB пакетов, посылать произвольные ATA команды диску, повышать частоту процессора и переключать видеокарты. И это всё - с обычными правами администратора:
Немного помучившись, получаем ответ от SSD на команду идентификации
А если написать свой драйвер?
Некоторые из вас наверняка уже подумали - зачем так изворачиваться, реверсить чужие драйвера, если можно написать свой? И я о таком думал. Более того, есть Open-Source проект chipsec, в котором подобный драйвер уже разработан.
Зайдя на страницу с кодом драйвера, вы сразу наткнетесь на предупреждение:
В этом предупреждении как раз и описываются все опасности, о которых я рассказывал в начале статьи - инструмент мощный и опасный, следует использовать только в Windows режиме Test Mode, и ни в коем случае не подписывать. Да, без специальной подписи на обычной системе просто так запустить драйвер не получится. Поэтому в примере выше мы и использовали заранее подписанный драйвер от ASRock.
Если кто сильно захочет подписать собственный драйвер - понадобится регистрировать собственную компанию и платить Microsoft. Насколько я нагуглил, физическим лицам такое развлечение недоступно.
Точнее я так думал, до вот этой статьи, глаз зацепился за крайне интересный абзац:
У меня под рукой нет Windows DDK, так что я взял 64-битный vfd.sys , скомпилированный неким critical0, и попросил dartraiden подписать его «древне-китайским способом». Такой драйвер успешно загружается и работает, если vfdwin запущена с правами администратора
Драйвер из статьи действительно подписан, и действительно неким китайским ключом:
Как оказалось, сведения о подписи можно просто посмотреть в свойствах.. А я в HEX изучал
Немного поиска этого имени в гугле, и я натыкаюсь на вот эту ссылку, откуда узнаю, что:
есть давно утёкшие и отозванные ключи для подписи драйверов
если ими подписать драйвер - он прекрасно принимается системой
малварщики по всему миру используют это для создания вирусни
Основная загвоздка - заставить майкрософтский SignTool подписать драйвер истёкшим ключом, но для этого даже нашёлся проект на GitHub. Более того, я нашёл даже проект на GitHub для другой утилиты подписи драйверов от TrustAsia, с помощью которого можно подставить для подписи вообще любую дату.
Несколько минут мучений с гугл-переводчиком на телефоне, и мне удалось разобраться в этой утилите и подписать драйвер одним из утекших ключей (который довольно легко отыскался в китайском поисковике):
И в самом деле, китайская азбука
И точно так же, как и AsrDrv101, драйвер удалось без проблем запустить!
А вот и наш драйвер запустился
Из чего делаю вывод, что старая идея с написанием своего драйвера вполне себе годная. Как раз не хватает функции маппинга памяти. Но да ладно, оставлю как TODO.
Выводы?
Как видите, имея права администратора, можно делать с компьютером практически что угодно. Будьте внимательны - установка утилит от производителя вашего железа может обернуться дырой в системе. Ну а желающие поэкспериментировать со своим ПК - добро пожаловать на низкий уровень! Наработки выложил на GitHub. Осторожно, бездумное использование чревато BSODами.
В Windows есть фича "Изоляция ядра", которая включает I/O MMU, защищает от DMA атак и так далее (кстати об этом - в следующих сериях)
Так вот, при включении этой опции, некоторые драйвера (в том числе RW Everything и китайско-подписанный chipsec_hlpr) перестают запускаться:
Читайте также: