Ошибка загрузки драйвера zwopenkey

хорошего дня Установленная версия Windows 10 — 1511 (сборка ОС 10586.164) Каждый час / два моноблок Lenovo C340 перезагружается без предупреждения. Курсор мыши останавливается, и компьютер перезагружается. Lenovo C340 Diagnostic Tools для Win 10 (x64), скачанный с сайта http://support.lenovo.com/ru/ru/products/Desktops-and-all-in-ones/Lenovo-C-Series- all — in-one / Lenovo-C340-All-in-One? linkTrack = Домашняя страница: Body_Search & beta = false, проблем с …

хорошего дня
Установленная версия Windows 10 — 1511 (сборка ОС 10586.164)
Каждый час / два моноблок Lenovo C340 перезагружается без предупреждения. Курсор мыши останавливается, и компьютер перезагружается.

Lenovo C340 Diagnostic Tools для Win 10 (x64), скачанный с сайта http://support.lenovo.com/ru/ru/products/Desktops-and-all-in-ones/Lenovo-C-Series- all — in-one / Lenovo-C340-All-in-One? linkTrack = Домашняя страница: Body_Search & beta = false, проблем с оборудованием нет.

В журнале ошибок Windows после перезагрузки появляется критическая ошибка:

Система

Поставщик
[Имя]
Microsoft-Windows-Ядро-Мощность
[Руководство]
{331C3B3A-2005-44C2-AC5E-77220C37D6B4}
ID события
41 год
Версия
3
Уровень
1
Задача
63
Рабочий код
0
Ключевое слово
0x8000400000000002


Время создания

[ОраСистема]
2016-04-01T11: 27: 37.063209100Z
EventRecordID
3403
Корреляция

Исполнение
[ID процесса]
4
[ID темы]
восемь
Канал
Система
Компьютер
Ольга

Безопасность
[ID пользователя]
С-1-5-18

EventData
BugcheckCode
265

и после каждого перезапуска параметры (разные после каждого перезапуска):
Параметр Bugcheck 1
0xa3a01f5a706d8516
Параметр Bugcheck 2
0xb3b72be0c2ee5493
Параметр проверки ошибок 3
0xffffe001d66ba040
Параметр Bugcheck 4
0x1f

SleepInProgress
0
PowerButtonTimestamp
0
BootAppStatus
0
В чем может быть проблема?
Раньше система работала на Win 8. После обновления она работала нормально в течение трех недель. Эти перезагрузки начались на прошлой неделе. Программное обеспечение, отличное от Lenovo Diagnostic Site, не было установлено.

Подскажите ответ на вопрос, в чем проблема?
Спасибо

PS При этом при возникновении критической ошибки в журнале перед ней появляются еще три ошибки:

Ошибка загрузки драйвера: PreInitControl.
Ошибка загрузки драйвера: QueryPatchConfigInfo.
Ошибка загрузки драйвера: ZwOpenKey.

И так каждый раз после перезагрузки

Источник: https://answers.microsoft.com/ru-ru/windows/forum/all/windows-10-on-lenovo-c340/56bad620-e4e4-4b79-be19-f06cf19ce623

Форум КриптоПро
 » 
Устаревшие продукты
 » 
КриптоПро CSP 3.6
 » 
Перестало работать шифрование в MS Outlook


Offline

older21

 


#1
Оставлено
:

10 сентября 2012 г. 17:58:18(UTC)

older21

Статус: Участник

Группы: Участники

Зарегистрирован: 10.09.2012(UTC)
Сообщений: 15
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз

Добрый день!

У пользователей перестало работать шифрование в MS Outlook. При попытке отправить зашифрованное сообщение, выдается ошибка «Один или несколько параметров задан неверно». В журнале событий есть такие записи:

Тип события: Ошибка
Сбой при загрузке драйвера(ов) перезагрузки или запуска системы:
CProCtrl

Тип события: Ошибка
Источник события: CProCtrl
Ошибка загрузки драйвера: ZwOpenFile.

Тип события: Ошибка
Источник события: CProCtrl
Ошибка загрузки драйвера: CreateDispatcher.

Тип события: Ошибка
Источник события: CProCtrl
Ошибка загрузки драйвера: PreInitControl.

Помогает переустановка компонента «Совместимость с продуктами Microsoft» в установщике КриптоПро CSP 3.6
После переустановки компонента служба CProCtrl начинает стартовать нормально, работа шифрования восстанавливается.

Не подскажете, что именно устанавливается этим компонентом? Хотелось бы понять, что из файловреестра повреждено. Уж очень не хочется на каждом пользователе запускать программу установки.

С уважением,
Алексей.


Вверх


Offline

SpJam

 


#2
Оставлено
:

13 сентября 2012 г. 13:38:30(UTC)

SpJam

Статус: Новичок

Группы: Участники

Зарегистрирован: 13.09.2012(UTC)
Сообщений: 3

о! что то мне кажется это из моей оперы тоже. Ттолько у меня наоборот, я не могу запросить сертификаты из Корпоративного PKI. Ошибка таже параметры в запросе не верны.


Вверх


Offline

Максим Коллегин

 


#3
Оставлено
:

13 сентября 2012 г. 14:00:04(UTC)

Максим Коллегин

Статус: Сотрудник

Группы: Администраторы

Зарегистрирован: 12.12.2007(UTC)
Сообщений: 6,259
Мужчина
Откуда: КРИПТО-ПРО

Сказал «Спасибо»: 21 раз
Поблагодарили: 661 раз в 584 постах

Хм, видимо кто-то удалил файл CProDspr.dll из System32. Что в логах антивируса и какой он?

Знания в базе знаний, поддержка в техподдержке


Вверх

WWW


Offline

older21

 


#4
Оставлено
:

13 сентября 2012 г. 17:42:13(UTC)

older21

Статус: Участник

Группы: Участники

Зарегистрирован: 10.09.2012(UTC)
Сообщений: 15
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз

Так, у нас эпидемия прекратилась…
Лечили переустановкой компонента «Совместимость с продуктами MicroSoft»

Этот компонент регистрирует CProDspr.dll и CProCtrl.sys

Так и не вышло посмотреть, кто же был виноват…


Вверх


Offline

older21

 


#5
Оставлено
:

17 сентября 2012 г. 19:45:52(UTC)

older21

Статус: Участник

Группы: Участники

Зарегистрирован: 10.09.2012(UTC)
Сообщений: 15
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз

maxdm написал:

Хм, видимо кто-то удалил файл CProDspr.dll из System32. Что в логах антивируса и какой он?

Снова началось. Действительно, удалена эта библиотека. Антивирус AVP, но в логах чисто — судя по журналам этот файл он не трогал. У пользователей нет прав доступа к системным каталогам. Осталось найти то, что удаляет эту библиотеку.


Вверх


Offline

rukus

 


#6
Оставлено
:

10 декабря 2012 г. 14:26:35(UTC)

rukus

Статус: Новичок

Группы: Участники

Зарегистрирован: 10.12.2012(UTC)
Сообщений: 3

а библиотека CProDspr.dll должна регистрироваться в системе через regsvr32 ?


Вверх


Offline

Максим Коллегин

 


#7
Оставлено
:

10 декабря 2012 г. 14:46:57(UTC)

Максим Коллегин

Статус: Сотрудник

Группы: Администраторы

Зарегистрирован: 12.12.2007(UTC)
Сообщений: 6,259
Мужчина
Откуда: КРИПТО-ПРО

Сказал «Спасибо»: 21 раз
Поблагодарили: 661 раз в 584 постах

Нет, достаточно положить в system32

Знания в базе знаний, поддержка в техподдержке


Вверх

WWW

Пользователи, просматривающие эту тему

Guest

Форум КриптоПро
 » 
Устаревшие продукты
 » 
КриптоПро CSP 3.6
 » 
Перестало работать шифрование в MS Outlook

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

     Обнаружение руткитов может быть делом довольно сложным, особенно если они работают в ядре. Причина в том, что руткит режима ядра способен менять функции, используемые всеми программами, в том числе программами защиты.

как удалить руткит с компьютераВсе средства, которые доступны программам защиты, доступны и руткиту. Какие бы направления внутри операционной системы ни блокировались, чтобы защититься от действий руткита, все они легко могут быть разблокированы.

Руткит может препятствовать запуску или правильной работе программ обнаружения или предотвращения вторжений. В конечном итоге в «гонке вооружений» между нападающим и защищающимся подавляющее преимущество у того кода, который раньше проникнет в ядро и будет исполнен.

Нельзя сказать, что для защищающегося все потеряно, но вы должны понимать, что программное обеспечение, которое сегодня успешно решает свои задачи, завтра может пропустить руткит. По мере того как разработчики руткитов выясняют, что и как делают программы обнаружения вторжений, появляются все более совершенные руткиты.

Верно и обратное: разработчики непрерывно обновляют программы обнаружения вторжений по мере появления новых технологий в разработке руткитов.

Руткит (англ. rootkit, то есть «набор root’а») — набор программных средств (например, исполняемых файлов, скриптов, конфигурационных файлов), для обеспечения:

маскировки объектов (процессов, файлов, директорий, драйверов)

контроля (событий происходящих в системе)

сбора данных (параметров системы)

Rootkit позволяет взломщику закрепиться во взломанной системе и скрыть следы своей деятельности путём сокрытия файлов, процессов, а также самого присутствия руткита в системе.

https://ru.wikipedia.org/wiki/%D0%F3%F2%EA%E8%F2

В этой статье мы рассмотрим два основных подхода к обнаружению руткитов: определение факта присутствия руткита и выявление его деятельности.

Обнаружение факта присутствия руткита

Для обнаружения факта присутствия руткита может быть использовано множество приемов. В прошлом соответствующие программы, такие как Tripwire, искали некие образы в файловой системе. Подобный подход, который до сих пор применяют основные производители антивирусных программ, вполне подходит и для обнаружения руткитов.

В основе данного подхода лежит предположение, что руткит использует файловую систему. Очевидно, что это предположение не работает, если запускать руткит непосредственно из памяти или размещать где-то в аппаратном обеспечении.

Кроме того, если противоруткитные средства запускаются непосредственно из инфицированной системы, можно заставить их работать неправильно. Для этого руткит может скрывать файлы, перехватывая системные вызовы или используя фильтрующий драйвер.

Поскольку программам, подобным Tripwire, присущи указанные ограничения, используются и другие методы обнаружения руткитов. В следующих разделах мы рассмотрим некоторые из них, применяемые для нахождения в памяти самого руткита или оставленных им улик.

Метод «охраны дверей»

Все программы должны «жить» где-то в памяти. Таким образом, чтобы найти руткит, можно исследовать память.

Исследовать память можно двояко. Первое — ловить руткит в момент его загрузки в память. При этом подходе, называемым охраной дверей (guarding the doors), проверяется все, что попадает в компьютер (процессы, драйверы устройств и т.д.).

Руткит может использовать вызовы многих системных функций, чтобы загрузить себя в память. Наблюдая за этими потенциально опасными точками программам обнаружения вторжений, иногда удается заметить руткит.

Однако контролируемых точек очень много, поэтому даже если один руткит обманет программу обнаружения вторжений, все усилия по защите пойдут насмарку.

Например, в системе IPD (Integrity Protection Driver — драйвер: защиты целостности) производства компании Pedestal Software защита была построена на перехвате функций ядра в SSDT, таких как NtLoadDriver и NtOpenSection.

Однако была найдена возможность загрузить модуль в ядро, вызвав функцию ZwSetSystemlnformation, которую IPD-драйвер не перехватывал. После того как это упущение IPD было исправлено, некто под псевдонимом Crazylord опубликовал статью, описывающую, как обойти защиту IPD-драйвера, используя символическую ссылку WDEVICEWPHYSICALMEMORY.

В результате разработчикам IPD-драйвера пришлось снова совершенствовать свое детище.

Последняя версия IPD-драйвера отлавливала следующие функции:
? ZwOpenKey;
? ZwCreateKey;
? ZwSetValueKey;
? ZwCreateFile;
? ZwOpenFile;

Для получения оптимальных результатов программы проверки целостности должны запускаться с копией проверяемого дискового образа на отдельной машине.

На данный момент компания Pedestal больше не поддерживает этот продукт.

К тому же список функций не полон. Например, еще одним способом загрузить руткит может быть проникновение в адресное пространство другого процесса. Кроме того, для загрузки DLL в другой процесс могут быть использованы другие подходы. Однако и это далеко не все доступные методы проникновения.

Поиск всех путей, которыми руткит мог бы проникнуть в систему, — это всего лишь первый шаг по защите от руткитов. В случае использования метода обнаружения при загрузке нужно решить две главные проблемы — что охранять и когда поднимать тревогу. Например, руткит может быть загружен в память через ключи реестра.

Очевидным способом выявить такую попытку является контроль функций ZwOpenKey, ZwCreateKey и ZwSetValueKey (как это делает, например, IPD-драйвер). Однако если программа обнаружения руткитов контролирует эти функции, как она узнает, какие ключи охранять?

Драйверы обычно располагаются в ключе:
HKEY_LOCAL_MACHINESystemCurrentControlSetServices

Вполне естественно наблюдать за этим ключом, но руткит может изменить и другой ключ:
HKEY_LOCAL_MACHINESystemControlSet001Services

Этот ключ используется, когда компьютер возвращается к предыдущей работоспособной конфигурации.

В данном примере мы даже не пытаемся учесть все те ключи реестра, которые отвечают за загрузку программных расширений. Кроме того, нужно учесть возможность загрузки дополнительных библиотек DLL, например, вспомогательных объектов браузера (Browser Helper Object).

Программы обнаружения руткитов должны также уделять внимание символическим ссылкам. Символические ссылки — это альтернативные имена системных объектов.

То есть объект, который вы пытаетесь защитить, может иметь более одного имени. И если ваша программа обнаружения руткитов контролирует таблицу системных вызовов, но руткит использует символическую ссылку, то истинная цель символической ссылки при вызове обработчика определена не будет.

Более того, например, ключ реестра HKEYLOCALMACHINE под этим именем не представлен в ядре. Даже если ваша программа будет перехватывать все нужные функции, количество точек, за которыми надо наблюдать, выглядит бесконечным!

Как избавиться от руткитовНо даже если предположить, что нам удалось найти все пути, которыми может воспользоваться руткит для загрузки, и мы знаем все возможные имена критических ресурсов, которые надо защищать, у нас остается проблема, как отличить «хорошие» программы от «плохих».

Нашей программе могли бы потребоваться сигнатуры для сравнения, что предполагает знание вектора атаки. Или наша программа могла бы эвристически анализировать поведение модуля, чтобы попытаться определить его намерения.

Оба этих подхода очень сложно реализовать на практике. Сигнатуры требуют знания руткита, и очевидно против неизвестного руткита они не помогут. Анализировать поведение также сложно, поскольку не ясны критерии положительных и отрицательных результатов проверки.

Столь же важно знать, когда поднимать тревогу. Эта битва за безопасность, которую ведут разработчики антивирусных программ, идет непрерывно.

Вы можете посмотреть так же записи


  1. Volynkin

    Volynkin

    New Member

    Публикаций:

    0

    Регистрация:
    11 окт 2004
    Сообщения:
    30

    Есть драйвер USB девайся написаный для WinXP и Win98… Драйвер WDM один для обеих платформ. Компилю в WinXPDDK и Win98DDK без проблем, все прекрасно работает под XP, однако не желает на Win98. При установке драйвера система пишет ошибку (Code 2) NTKERN.VXD device loader(s) for this device could not load the device driver.

    Проверку делаю из под VMWare/Win98SE сайсом из пакета 2.7 версии 4.05 по мойму. Сайс со скрипом, но всеже работает во всем этом бардаке.

    Это все предисловие, теперь вопрос:

    Выясняю, что вход в драйвер не происходит никаким образом, ошибка идет гдето в VMM32 при загрузке моего драйвера. Проблема в том, что на запрос .NTKERN в сайсе, дамп текущих событий всегда пуст. Каким образом выяснить, что всеже приводит к ошибке загрузки драйвера?


  2. NullSessi0n

    NullSessi0n

    New Member

    Публикаций:

    0

    Регистрация:
    20 янв 2006
    Сообщения:
    322

    Как ты устанавливаешь драйвер? Если загрузка драйвера вообще не происходит, значит записи о нём некорректны либо Windows не опознаёт формат драйвера (последнее наврядли, так как ты используешь подходящую DDK). К сожалению, плохо знаком с VXD. И попробуй найти перевод сообщения с кодом 2, может тогда понятно будет в чём дело.


  3. infern0

    infern0

    New Member

    Публикаций:

    0

    Регистрация:
    7 окт 2003
    Сообщения:
    811
    Адрес:
    Russia

    DDK может быть правильным, а вот версия VXD неверная.


  4. Volynkin

    Volynkin

    New Member

    Публикаций:

    0

    Регистрация:
    11 окт 2004
    Сообщения:
    30

    Драйвер ставлю вручную, через девайс менеджер. Драйвер WDM, не VXD, ntkern.vxd как раз и служит интерфейсом для WDM драйверов чтоб можно было кроссплатформенные WDM драйвера штамповать. Код ошибки не имеет никакого смысла… означает что файл не найден. Все файлы там где они должны быть.

    Вопрос собственно даже не в том как мне решить проблему загрузки, а в том как узнать через дебаггер что всеже ненравится этому ntkern…


  5. Volynkin

    Volynkin

    New Member

    Публикаций:

    0

    Регистрация:
    11 окт 2004
    Сообщения:
    30

    infern0

    есть у меня подозрения на формат файла… я с VXD не на ты. Тут еще есть один нюанс, существует старый драйвер для сходного устройства, писаный и компиленый не мной, поэтому сырцов к нему нет. Так вот при вскрытии IDA показывает совсем другой формат, нежеле тот что я получаю из Win98 DDK…. как выяснить не VXD ли это случаем?


  6. Foamplast

    Foamplast

    New Member

    Публикаций:

    0

    Регистрация:
    6 ноя 2003
    Сообщения:
    80
    Адрес:
    Russia

    Мужики, у меня вчера была такая же проблема. Дело в том, что в Win9X нет некоторых функций, вот дрова и не грузятся.

    А именно:

    KeEnterCriticalRegion()

    KeLeaveCriticalRegion()

    RtlCreateRegistryKey()

    и другие…

    В книге «Programming The Windows Driver Model» это описано и даже сказано, что автор написал свой VXD, который якобы некоторые из отсутсвующих функций эмулирует. У меня книга есть, а кода нету, так что поверьте на слово.


  7. Volynkin

    Volynkin

    New Member

    Публикаций:

    0

    Регистрация:
    11 окт 2004
    Сообщения:
    30

    Foamplast

    хмм… однако сайс не вываливается по int3 даже на DriverEntry, никакой вызов функций оттуда не происходит. Значит ntkern проверяет таблицу импорта драйвера при загрузке и если находит чтото нето, просто не загружает…

    Возможно.

    Спасибо за наводку, вечером почитаю книжку, в какой главе про это сказано?

    И все же интересно, почему .NTKERN дамп в сайсе мне ничего не выдает…ведь должен?


  8. Foamplast

    Foamplast

    New Member

    Публикаций:

    0

    Регистрация:
    6 ноя 2003
    Сообщения:
    80
    Адрес:
    Russia

    «и если находит чтото нето, просто не загружает» — естественно. Разрешение имён функций в адреса должно происходить ДО выполнения кода. В общем у меня тоже до DriverEntry() дело не доходило и я написал простейший драйвер, который заявляет о успешной загрузке записью в реестр. Он точно работает под 98. См. приложение.

    Кстати я не нашёл ничего похожего на DbgPrint() для 98. DbgView от Sysinternals пишет, что может захватывать Out_Debug_String(), однако никакого описания в DDK я не нашёл, поэтому драйвер пишет в реестр. Для успешного выполнения нужно создать ключ «HKEY_LOCAL_MACHINESystemCurrentControlSetServicesXSERV

    «.

    [​IMG] _1908087031__testwdm.zip


  9. _BC_

    _BC_

    БЦ

    Публикаций:

    0

    Регистрация:
    20 янв 2005
    Сообщения:
    759

    ещё оттуда:

    Windows 98/Me Compatibility Notes

    Windows 98/Me handles some of the details surrounding device object creation and driver loading differently than Windows XP. This section explains the differences that might affect your driver. I’ve already mentioned a few of these, but repetition can’t hurt.

    Differences in DriverEntry Call

    As I indicated earlier, the DriverEntry routine receives a UNICODE_STRING argument naming the service key for the driver. In Windows XP, the string is a full registry path of the form RegistryMachineSystemCurrentControlSetServicesxxx (where xxx is the name of the service entry for your driver). In Windows 98/Me, however, the string is of the form SystemCurrentControlSetServices<classname ><instance#> (where <classname> is the class name of your device and <instance#> is an instance number such as 0000 indicating which device of that class you happen to be). You can open the key in either environment by calling ZwOpenKey, however.

    DriverUnload

    Windows 98/Me will call DriverUnload within a call to IoDeleteDevice that occurs within DriverEntry. You care about this only if (1) your DriverEntry function calls IoCreateDevice and then (2) decides to return an error status, whereupon it (3) cleans up by calling IoDeleteDevice.

    The GLOBAL?? Directory

    Windows 98/Me doesn’t understand the directory name GLOBAL??. Consequently, you need to put symbolic link names in the DosDevices directory. You can use DosDevices in Windows XP also because it’s a symbolic link to the ?? directory, whose (virtual) contents include GLOBAL??.

    Unimplemented Device Types

    Windows 98 didn’t support creating device objects for mass storage devices. These are devices with types FILE_DEVICE_DISK, FILE_DEVICE_TAPE, FILE_DEVICE_CD_ROM, and FILE_DEVICE_VIRTUAL_DISK. You can call IoCreateDevice, and it will even return with a status code of STATUS_SUCCESS, but it won’t have actually created a device object or modified the PDEVICE_OBJECT variable whose address you gave as the last argument.


  10. Volynkin

    Volynkin

    New Member

    Публикаций:

    0

    Регистрация:
    11 окт 2004
    Сообщения:
    30

    проверил таблицу импорта… все чисто. WDMCHECK из книги также ничего не показал. Видимо чтото другое.

    Foamplast

    Твой тест драйвер загрузился без проблем, не смотря на то что у него таблица импорта идет в начале файла. Видимо чтото еще… Читаю книгу, но на первый взгляд ничего.

    Продолжаю эксперименты…


  11. Foamplast

    Foamplast

    New Member

    Публикаций:

    0

    Регистрация:
    6 ноя 2003
    Сообщения:
    80
    Адрес:
    Russia

    Раз есть драйвер, который грузится без проблем и отличающийся от него драйвер, который не грузится, то необходимо проверить 2 вещи:

    1) Синтаксис INF файла. Для Win9X должны быть отдельные разделы и другая «сигнатура» (CHICAGO вместо WindowsNT).

    2) И всё-таки наличие функций, импортируемых из «ядра». У меня именно за-за этого до DriverEntry() дело не доходило.


  12. Volynkin

    Volynkin

    New Member

    Публикаций:

    0

    Регистрация:
    11 окт 2004
    Сообщения:
    30

    Все проблемы разрешились. Выяснилось вся заморочка была в проблемном USBD.sys на Win98.

    Идем по порядку:

    Методом проб и ошибок нахожу что мой драйвер не грузится при вызове USBD_ParseConfigurationDescriptorEx, этот вызов приводит к usbd.sys, драйверу поддержки USB в винде. Однако как упоминал ранее, у меня был старый схожий драйвер (от cypress), который работает под Win98 нормально имея тот же вызов к USBD. Вскрытие старого и нового драйвера Идой показало, что все вызовы к USBD кроме USBD_GetUSBDIVersion имеют различную структуру в таблице импорта, а именно:

    Старый рабочий драйвер имел

    1. ; __stdcall USBD_CreateConfigurationRequestEx(x,x)
    2.                 extrn _USBD_CreateConfigurationRequestEx@8:dword

    А новый нерабочий драйвер:

    1. extrn USBD_ParseConfigurationDescriptorEx:dword

    Похоже Win98 USBD не принимает вызовы без __stdcall…

    Идем далее, той же идой вскрываем USBD.SYS для винды 98 и XP, и идем прямо в таблицу экспорта:

    USBD.SYS Win98:

    1. Exported entry  21. _USBD_ParseConfigurationDescriptorEx@28

    USBD.SYS WinXP:

    1. ; Exported entry   2. USBD_ParseConfigurationDescriptorEx
    2. ; Exported entry  26. _USBD_ParseConfigurationDescriptorEx@28

    Просто замечательно! похоже Win98 не имеет представления о существовании USBD_ParseConfigurationDescriptorEx (как собственно и многих других USBD функций), в то время как WinXP принимает и обрабатывает оба формата.

    Дальнейшее исследование гуглом приводик к посту Вальтера Оней (того самого кто написал книжку по разработке дров) на osronline http://www.osronline.com/lists_archive/ntdev/thread7263.html

    В итоге замена существующего usbd.lib в WINXP DDK, старой либой из WIN98 DDK решила все мои проблемы совместимости. При замене либы, вызовы компилируются в формат типа _USBD_ParseConfigurationDescriptorEx@28, поддерживаемый всеми платформами.

    Всем ответившим спасибо за идеи. Надеюсь мое пояснение избавит других от головной боли в будущем.

  13. мда…. вообщето как бы внимательней ДДК 98 читать надо )о соглашениях вызова функций


  14. Volynkin

    Volynkin

    New Member

    Публикаций:

    0

    Регистрация:
    11 окт 2004
    Сообщения:
    30

    ну да, вот только это как бы не решит мою проблему… я как бы не разрабатываю драйвера для Win98, однако нужна совместимость с этой осью… компилиться и работать все должно WinXP DDK…


WASM

A 3rd party data loss prevention driver when enabled driver verifier on it causes driver verifier bugcheck based on IrqlZwPassive Rule

The crash includes the following information:

ZwOpenKey should only be called at IRQL = PASSIVE_LEVEL.

What are some of the potential impacts to a Windows system if ZwOpenKey is used outside of IRQL=PASSIVE_LEVEL?

Is this always a serious problem that we should raise with a vendor, or only in certain scenarios.

asked Jun 30, 2017 at 12:14

Malcolm McCaffery's user avatar

2

all Zw api in kernel must be called only on PASSIVE_LEVEL. this is by design. if call it on APC_LEVEL this already will be UB some times this can work, some times produce hang or crash. say in case ZwOpenKey — registry manager can read key data from disk, if it still not in memory. so pass IRP to filesystem and wait for it complete. but Irp for completion can insert special APC (IopCompleteRequest) in calling thread. if thread on APC level — APC will not be executed, until IRQL of thread not lower to passive. but it never done — he wait on IRP complete..

another point — on exit from Zw service, system check — are UserApcPending in Thread and if yes, raise IRQL to APC_LEVEL, initiate user apc, and lower it back to PASSIVE_LEVEL (system assume that Zw called on PASSIVE_LEVEL) — so you can enter to Zw api at APC_LEVEL and exit on PASSIVE_LEVEL. can ask — why thread at some time have APC_LEVEL ? simply, because nothing to do IRQL raised ? or exist some requirements why at some point must be APC_LEVEL ? if yes, what is be if situation require stay on APC_LEVEL but thread ahead of time lower IRQL to PASSIVE_LEVEL ? really UB. in most case can be nothing. but in some case can be very nasty bug which very hard catch and research.

answered Jun 30, 2017 at 18:13

RbMm's user avatar

A 3rd party data loss prevention driver when enabled driver verifier on it causes driver verifier bugcheck based on IrqlZwPassive Rule

The crash includes the following information:

ZwOpenKey should only be called at IRQL = PASSIVE_LEVEL.

What are some of the potential impacts to a Windows system if ZwOpenKey is used outside of IRQL=PASSIVE_LEVEL?

Is this always a serious problem that we should raise with a vendor, or only in certain scenarios.

asked Jun 30, 2017 at 12:14

Malcolm McCaffery's user avatar

2

all Zw api in kernel must be called only on PASSIVE_LEVEL. this is by design. if call it on APC_LEVEL this already will be UB some times this can work, some times produce hang or crash. say in case ZwOpenKey — registry manager can read key data from disk, if it still not in memory. so pass IRP to filesystem and wait for it complete. but Irp for completion can insert special APC (IopCompleteRequest) in calling thread. if thread on APC level — APC will not be executed, until IRQL of thread not lower to passive. but it never done — he wait on IRP complete..

another point — on exit from Zw service, system check — are UserApcPending in Thread and if yes, raise IRQL to APC_LEVEL, initiate user apc, and lower it back to PASSIVE_LEVEL (system assume that Zw called on PASSIVE_LEVEL) — so you can enter to Zw api at APC_LEVEL and exit on PASSIVE_LEVEL. can ask — why thread at some time have APC_LEVEL ? simply, because nothing to do IRQL raised ? or exist some requirements why at some point must be APC_LEVEL ? if yes, what is be if situation require stay on APC_LEVEL but thread ahead of time lower IRQL to PASSIVE_LEVEL ? really UB. in most case can be nothing. but in some case can be very nasty bug which very hard catch and research.

answered Jun 30, 2017 at 18:13

RbMm's user avatar

Содержание

  1. ZwOpenKey function (wdm.h)
  2. Syntax
  3. Parameters
  4. Return value
  5. Remarks
  6. Драйвер заблокирован от загрузки [3 БЫСТРЫХ ИСПРАВЛЕНИЯ]
  7. Драйвер заблокирован от загрузки [FIX]
  8. 1. Отключить принудительное использование подписи водителя
  9. 2. Отключите антивирусную защиту или добавьте исключение
  10. 3. Запустите ваши программы с правами администратора
  11. Windows 10 на Lenovo C340 перезагружается раз в один — два часа — как исправить?
  12. Ошибка загрузки драйвера zwopenkey

ZwOpenKey function (wdm.h)

The ZwOpenKey routine opens an existing registry key.

Syntax

Parameters

Pointer to the HANDLE variable that receives the handle to the key.

Specifies an ACCESS_MASK value that determines the requested access to the object. For more information, see the DesiredAccess parameter of ZwCreateKey.

Pointer to an OBJECT_ATTRIBUTES structure that specifies the object name and other attributes. Use InitializeObjectAttributes to initialize this structure. If the caller is not running in a system thread context, it must set the OBJ_KERNEL_HANDLE attribute when it calls InitializeObjectAttributes.

Return value

ZwOpenKey returns STATUS_SUCCESS if the given key was opened. Otherwise, it can return an error status, including the following:

ZwOpenKey supplies a handle that the caller can use to manipulate a registry key. The routine provides a subset of the functionality of ZwCreateKey. For more information, see Using the Registry in a Driver.

If the specified key does not exist, ZwOpenKey returns an error status and does not return a key handle.

Once the handle pointed to by KeyHandle is no longer in use, the driver must call ZwClose to close it.

ZwOpenKey ignores the security information in the structure that the ObjectAttributes parameter points to.

If the caller is not running in a system thread context, it must ensure that any handles it creates are private handles. Otherwise, the handle can be accessed by the process in whose context the driver is running. For more information, see Object Handles.

For more information about working with registry keys, see Using the Registry in a Driver.

Источник

Драйвер заблокирован от загрузки [3 БЫСТРЫХ ИСПРАВЛЕНИЯ]

Драйвер заблокирован от загрузки . Это сообщение об ошибке, которое выдается системой Windows при попытке установить или запустить программу или программное обеспечение, несовместимое с системой, которая обеспечивает питание вашего устройства.

Итак, мы можем обсудить ситуацию несовместимости. Однако та же проблема может возникнуть, когда антивирус блокирует обсуждаемое программное обеспечение или если у вас нет прав администратора.

В этом руководстве мы перечислим решения для устранения неполадок, которые могут помочь вам решить эту проблему.

Драйвер заблокирован от загрузки [FIX]

  • Решение 1. Отключите принудительное использование подписи драйверов
  • Решение 2. Отключите антивирусную защиту или добавьте исключение
  • Решение 3 – Запустите ваши программы с правами администратора

1. Отключить принудительное использование подписи водителя

В качестве меры безопасности Windows требует наличия драйверов с цифровой подписью. Это полезная функция, которая может защитить ваше устройство с Windows 10, но в некоторых ситуациях она может стать реальным источником проблем – например, проблема «Драйвер заблокирован от загрузки». Таким образом, попробуйте исправить эту ошибку, отключив принудительное использование подписи драйверов:

  1. Запустите на компьютере окно командной строки с повышенными правами: щелкните правой кнопкой мыши значок «Пуск» Windows и выберите « Командная строка (администратор) ».
  2. В окне cmd введите bcdedit.exe /, установите nointegritychecks на и нажмите Enter.
  3. Это автоматически отключит принудительное использование подписи драйверов на вашем устройстве.
  4. Если вы хотите снова включить эту функцию, вам нужно выполнить следующую команду в окне с повышенными привилегиями: bcdedit.exe/set nointegritychecks off .

Кроме того, вы также должны следовать:

  1. Нажмите правой кнопкой мыши на Мой компьютер (или Этот компьютер) и на левой панели открывающихся окон нажмите Расширенные настройки системы .
  2. Из Системных свойств перейдите на вкладку Дополнительно и в разделе Производительность нажмите Настройки .
  3. В разделе Параметры производительности перейдите в Предотвращение выполнения данных и убедитесь, что установлен флажок Включить DEP для основных программ и служб Windows только .
  4. Затем нажмите Win + R и введите gpedit.msc.
  5. Затем перейдите в «Конфигурация компьютера» -> «Настройки Windows» -> «Локальные политики» -> «Параметры безопасности» -> проверить поведение установки неподписанного драйвера.

2. Отключите антивирусную защиту или добавьте исключение

Если вы используете программное обеспечение безопасности Windows по умолчанию или любую другую стороннюю антивирусную программу, вы можете получить сообщение об ошибке «Драйвер заблокирован от загрузки» при попытке установить новые приложения или инструменты.

Поэтому, прежде всего, выберите отключение антивирусной защиты и повторите процесс установки. Если все работает без проблем, попробуйте добавить исключение в антивирусную программу для этой конкретной программы.

Всегда включайте защиту в своей системе Windows 10, чтобы все время было в безопасности.

Говоря об антивирусных инструментах, мы настоятельно рекомендуем вам проверить некоторые из лучших антивирусных программ для вашего ПК с Windows, прежде чем стать жертвой ScanGuard.

  • ТАКЖЕ ПРОЧИТАЙТЕ : ScanGuard Antivirus: вот что вам нужно знать об этом

3. Запустите ваши программы с правами администратора

Если вы запускаете программу без прав администратора, вы можете столкнуться с проблемой «Драйвер заблокирован от загрузки».

Поэтому, прежде чем пытаться применить или установить новое приложение или процесс, убедитесь, что вы завершили фактический процесс установки с правами администратора.

У нас также есть специальное руководство о том, как стать администратором.

Заключительные мысли

Если перечисленные выше методы устранения неполадок не помогли вам, возможно, вы столкнулись с проблемой несовместимости. Убедитесь, что вы устанавливаете правильное программное обеспечение для вашей конкретной платформы Windows 10.

По любым другим вопросам, не стесняйтесь и используйте поле для комментариев ниже.

Источник

Windows 10 на Lenovo C340 перезагружается раз в один — два часа — как исправить?

хорошего дня
Установленная версия Windows 10 — 1511 (сборка ОС 10586.164)
Каждый час / два моноблок Lenovo C340 перезагружается без предупреждения. Курсор мыши останавливается, и компьютер перезагружается.

Lenovo C340 Diagnostic Tools для Win 10 (x64), скачанный с сайта http://support.lenovo.com/ru/ru/products/Desktops-and-all-in-ones/Lenovo-C-Series- all — in-one / Lenovo-C340-All-in-One? linkTrack = Домашняя страница: Body_Search & beta = false, проблем с оборудованием нет.

В журнале ошибок Windows после перезагрузки появляется критическая ошибка:

Система

Поставщик
[Имя]
Microsoft-Windows-Ядро-Мощность
[Руководство]
<331c3b3a-2005-44c2-ac5e-77220c37d6b4>
ID события
41 год
Версия
3
Уровень
1
Задача
63
Рабочий код
0
Ключевое слово
0x8000400000000002

[ОраСистема]
2016-04-01T11: 27: 37.063209100Z
EventRecordID
3403
Корреляция

Исполнение
[ID процесса]
4
[ID темы]
восемь
Канал
Система
Компьютер
Ольга

Безопасность
[ID пользователя]
С-1-5-18

EventData
BugcheckCode
265

и после каждого перезапуска параметры (разные после каждого перезапуска):
Параметр Bugcheck 1
0xa3a01f5a706d8516
Параметр Bugcheck 2
0xb3b72be0c2ee5493
Параметр проверки ошибок 3
0xffffe001d66ba040
Параметр Bugcheck 4
0x1f

SleepInProgress
0
PowerButtonTimestamp
0
BootAppStatus
0
В чем может быть проблема?
Раньше система работала на Win 8. После обновления она работала нормально в течение трех недель. Эти перезагрузки начались на прошлой неделе. Программное обеспечение, отличное от Lenovo Diagnostic Site, не было установлено.

Подскажите ответ на вопрос, в чем проблема?
Спасибо

PS При этом при возникновении критической ошибки в журнале перед ней появляются еще три ошибки:

Ошибка загрузки драйвера: PreInitControl.
Ошибка загрузки драйвера: QueryPatchConfigInfo.
Ошибка загрузки драйвера: ZwOpenKey.

Источник

Если такой «самокомпилирующийся» файл запустить, то произойдет следущее. Первые две команды закомментарены, поэтому, они игнорируются компилятором masm, но принимаются командным процессором, который, в свою очередь, игнорирует символ «точка с запятой». Управление передается на метку :make , за которой находятся инструкции для компилятора и компоновщика. Все, что находится за директивой ассемблера end, игнорируется компилятором masm. Таким образом, весь текст между командой goto make и меткой :make , игнорируется командным процессором, но принимается компилятором masm. А все, что вне (включая команду goto make и метку :make ), игнорируется компилятором masm, но принимается командным процессором. Этот метод чрезвычайно удобен, т.к. исходный текст «помнит» с какими параметрами его нужно компилировать. Я буду применять такую технику в исходных текстах драйверов, а в исходных текстах программ управления, буду пользоваться обычным методом.

Параметры компоновки имеют следующий смысл:

— Указывает компоновщику, что нужно сформировать файл драйвера режима ядра Windows NT;

— Устанавливает предопределенный адрес загрузки образа драйвера равным 10000h. Я уже говорил про это в предыдущей статье;

— Память режима ядра — драгоценный ресурс. Поэтому, файлы драйверов имеют более «мелкое» выравнивание секций;

— По умолчанию компоновщик производит файлы с расширением .exe. При наличии ключа /dll файл будет иметь расширение .dll. Нам нужно получить файл с расшрением .sys;

— В PE-заголовке имеется поле, указывающее загрузчику образа исполняемого файла, для какой подсистемы этот файл предназначен: Win32, POSIX или OS/2. Это нужно для того, чтобы поместить образ в необходимое ему окружение. Подсистема Win32 автоматически запускается при загрузке системы. Если же запускается файл, предназначенный для функционирования, например, в подсистеме POSIX, то сначала операционная система запускает саму подсистему POSIX. Таким образом, с помощью этого ключа можно указать компоновщику, какая подсистема необходима. Когда мы компилируем *.exe или *.dll, то указываем под этим ключем значение windows, которое означает, что файлу требуется подсистема Win32. Драйверу вообще не нужна ни одна из подсистем, т.к. он работает в естественной (native) для самой операционной системы среде.

Самый простой драйвер режима ядра

Вот исходный текст простейшего драйвера режима ядра.

Как и у любого другого выполнимого модуля, у драйвера должна быть точка входа, на которую система передаст управление после загрузки драйвера в память. Как и полагается в программе на ассемблере, точкой входа является первая инструкция, обозначенная меткой указанной в директиве end. У нас, как и в текстах на с, это DriverEntry, которая оформлена в виде процедуры, принимающей два параметра. Имя процедуры, естественно, может быть любым. Прототип DriverEntry выглядит так:

К сожалению, Microsoft отошла от принципа «венгерской нотации» при составлении заголовочных файлов и документации DDK. Возможно, это связано с большим количеством специфических типов данных, используемых в DDK. Хотя, в обозначении типов кое-что осталось. В исходных текстах я буду придерживаться этого принципа везде, где только возможно, т.к. настолько привык им пользоваться, что исходники не использующие «венгерскую нотацию» мне кажутся совершенно нечитабельными. Поэтом, легким движением руки, DriverObject превращается в pDriverObject, а RegistryPath в pusRegistryPath.

Типы данных PDRIVER_OBJECT и PUNICODE_STRING определены в файлах includew2kntddk.inc и includew2kntdef.inc соответственно.

— указатель на объект только что созданного драйвера.

Windows является объектно-ориентированной системой. Поэтому, понятие объект распространяется на все, что только можно, и что нельзя тоже. И объект «драйвер» не является исключением. Загружая драйвер, система создает объект «драйвер» (driver object), представляющий для нее образ драйвера в памяти. Через этот объект система управляет драйвером. Звучит красиво, но не дает никакого представления о том, что же в действительности происходит. Если отбросить всю эту объектно-ориентированную мишуру, то станет очевидно, что объект «драйвер» представляет собой обыкновенную структуру данных типа DRIVER_OBJECT (определена в includew2kntddk.inc). Некоторые поля этой структуры заполняет система, некоторые придется заполнять нам самим. Обращаясь к этой структуре, система и управляет драйвером. Итак, как вы наверное уже поняли, первым параметром, передающимся в функцию DriverEntry, как раз и является указатель на эту самую структуру (или пользуясь объектно-ориентированной терминологией — объект «драйвер»). Используя этот указатель, мы можем (и будем, но позже) заполнить соответствующие поля структуры DRIVER_OBJECT. Но, в рассматриваемых в этой части статьи драйверах этого не требуется, поэтому мы, пока, оставим pDriverObject без внимания.

— указатель на раздел реестра, содержащий параметры инициализации драйвера. Про этот раздел, мы достаточно подробно говорили в прошлый раз.

Точнее говоря, это указатель на структуру типа UNICODE_STRING. А уже в ней содержится указатель на саму Unicode-строку, содержащую имя раздела. Этот указатель драйвер может использовать для добавления (или извлечения, в чем мы очень скоро убедимся) в реестр какой-либо информации, которую он сможет в дальнейшем использовать. В этом случае необходимо сохранить путь к подразделу реестра, но не сам указатель, т.к. по выходу из процедуры DriverEntry он потеряет всякий смысл. Но, обычно этого не требуется.

О формате данных UNICODE_STRING следует сказать особо. В отличие от режима пользователя, режим ядра оперирует строками в формате UNICODE_STRING. Эта структура определена в файле includew2kntdef.inc следующим образом:

— (мне пришлось изменить оригинальное имя Length, т.к. оно является зарезервированным словом) содержит текущую длину строки в байтах (не в символах!), не считая завершающего нуля.

— максимальный размер буфера (также в байтах), в котором эта строка содержится.

— указатель на саму Unicode-строку.

Главное достоинство этого формата в том, что он явно определяет, как текущую длину строки, так и ее максимально возможную длину. Это позволяет, при операциях с такой строкой, обойтись без некоторых дополнительных вычислений.

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

Это приведет к остановке системы и появлению BSOD (Blue Screen Of Death). А выполнение такого кода приведет к перезагрузке компьютера:

Такой радикальный способ, прервать попытку исследования программы, иногда встречается в защитах. Честно говоря, я и сам на это не раз попадался 😉

В этих двух случаях, процедура DriverEntry никогда не вернет управление. Поэтому, возвращаемое ей значение не важно. Если же действия выполняемые DriverEntry будут более конструктивными, как, например, в драйвере beeper.sys, то надо вернуть системе некое значение, указывающее на то, как прошла инициализация драйвера. Если вернуть STATUS_SUCCESS, то инициализация считается успешной, и драйвер остается в памяти. Любое другое значение STATUS_* указывает на ошибку, и в этом случае драйвер выгружается системой. Вышеприведенный драйвер (srcArticle2-3simplestsimplest.sys) является самым простым, какой только можно себе представить. Единственное что он делает, это позволяет себя загрузить. Т.к. ничего кроме этого он сделать больше не может, то возвращает код ошибки STATUS_DEVICE_CONFIGURATION_ERROR. Я просто подобрал подходящее по смыслу значение (полный список можно посмотреть в файле includew2kntstatus.inc). Если возвратить STATUS_SUCCESS, то драйвер так и останется болтаться в памяти без дела, и выгрузить его средствами SCM будет невозможно, т.к. мы не определили процедуру отвечающую за выгрузку драйвера. Эта процедура должна находиться в самом драйвере. Она выполняет действия, зеркальные по отношению к DriverEntry. Если драйвер выделил себе какие-то ресурсы, например, память, то в процедуре выгрузки эта память должна быть возвращена системе. И только сам драйвер знает об этом. Но, тут я немного забежал вперед. Пока нам это не понадобится.

Драйвер режима ядра beeper.sys

Теперь перейдем к рассмотрению драйвера, программу управления которым, мы писали в прошлый раз. Мне пришлось переименовать его из beep.sys в beeper.sys, потому что, как оказалось, в NT4 и в некоторых версиях XP уже существует драйвер beep.sys. Вобще говоря, beep.sys есть во всех версиях NT (%SystemRoot%System32Driversbeep.sys), но он еще должен быть зарегистрирован в реестре. Как бы там ни было, надеюсь beeper.sys будет уникальным. Вот его исходный текст:

Задача этого драйвера, исполнять на системном динамике восходящее до-мажорное арпеджио. Что это такое, вы, наверное уже послушали. Для этого драйвер использует инструкции процессора in и out, обращаясь к соответствующим портам ввода-вывода. Общеизвестно, что доступ к портам ввода-вывода — это свято охраняемый Windows NT системный ресурс. Попытка обращения к любому из них, как на ввод, так и на вывод, из режима пользователя, неизбежно приводит к завершению приложения. Но, на самом деле, есть способ обойти и это ограничение, т.е. обращаться к портам ввода-вывода прямо из третьего кольца. В этом вы убедитесь ниже. Правда, для этого, опять таки, нужен драйвер.

На материнской плате находится устройство системный таймер , который является перепрограммируемым. Таймер содержит несколько каналов, 2-ой управляет системным динамиком компьютера, генерируя прямоугольные импульсы с частотой 1193180/ начальное значение счетчика > герц. Начальное значение счетчика является 16-битным, и устанавливается через порт 42h. 1193180 Гц — частота тактового генератора таймера. Тут есть одна тонкость, которую я не совсем понимаю. Функция QueryPerformanceFrequency из kernel32.dll действительно возвращает значение 1193180. Оно просто жестко зашито в тело функции. Но дизассемблировав hal.dll, в функции HalMakeBeep я обнаружил несколько другое значение, равное 1193167 Гц. Его я и использую. Возможно, здесь учтена какая-то временная задержка, или что-то подобное. В любом случае, пищать системным динамиком нам это никак не помешает. Я не буду подробно останавливаться на описании системного таймера. Эту тему очень любят мусолить почти в каждой книжке по программированию на ассемблере. Достаточно подробную информацию можно найти в сети.

Итак, первый звук до-мажорного арпеджио мы воспроизводим пользуясь процедурой MakeBeep1.

Выводом в порт 43h двоичного числа 10110110, мы помещаем в управляющий регистр таймера значение, определяющее номер канала, которым мы будем управлять, тип операции, режим работы канала и формат счетчика.

Затем, в порт 42h выводим 16-битное начальное значение счетчика. Сначала младший байт, затем старший.

И, наконец, посредством вывода в порт 61h значения, с установленными 0-ым и 1-ым битами, включаем динамик.

Даем данамику позвучать некоторое время, пользуясь макросом DO_DELAY. Да — примитивно, но — эффективно 😉

И выключаем динамик, сбрасывая два младших бита. При этом надо не забывать, что таймер — это глобальный системный ресурс. Поэтому, на время работы с регистрами таймера, мы запрещаем аппаратные прерывания.

Источник

     Обнаружение руткитов может быть делом довольно сложным, особенно если они работают в ядре. Причина в том, что руткит режима ядра способен менять функции, используемые всеми программами, в том числе программами защиты.

как удалить руткит с компьютераВсе средства, которые доступны программам защиты, доступны и руткиту. Какие бы направления внутри операционной системы ни блокировались, чтобы защититься от действий руткита, все они легко могут быть разблокированы.

Руткит может препятствовать запуску или правильной работе программ обнаружения или предотвращения вторжений. В конечном итоге в «гонке вооружений» между нападающим и защищающимся подавляющее преимущество у того кода, который раньше проникнет в ядро и будет исполнен.

Нельзя сказать, что для защищающегося все потеряно, но вы должны понимать, что программное обеспечение, которое сегодня успешно решает свои задачи, завтра может пропустить руткит. По мере того как разработчики руткитов выясняют, что и как делают программы обнаружения вторжений, появляются все более совершенные руткиты.

Верно и обратное: разработчики непрерывно обновляют программы обнаружения вторжений по мере появления новых технологий в разработке руткитов.

Руткит (англ. rootkit, то есть «набор root’а») — набор программных средств (например, исполняемых файлов, скриптов, конфигурационных файлов), для обеспечения:

маскировки объектов (процессов, файлов, директорий, драйверов)

контроля (событий происходящих в системе)

сбора данных (параметров системы)

Rootkit позволяет взломщику закрепиться во взломанной системе и скрыть следы своей деятельности путём сокрытия файлов, процессов, а также самого присутствия руткита в системе.

https://ru.wikipedia.org/wiki/%D0%F3%F2%EA%E8%F2

В этой статье мы рассмотрим два основных подхода к обнаружению руткитов: определение факта присутствия руткита и выявление его деятельности.

Обнаружение факта присутствия руткита

Для обнаружения факта присутствия руткита может быть использовано множество приемов. В прошлом соответствующие программы, такие как Tripwire, искали некие образы в файловой системе. Подобный подход, который до сих пор применяют основные производители антивирусных программ, вполне подходит и для обнаружения руткитов.

В основе данного подхода лежит предположение, что руткит использует файловую систему. Очевидно, что это предположение не работает, если запускать руткит непосредственно из памяти или размещать где-то в аппаратном обеспечении.

Кроме того, если противоруткитные средства запускаются непосредственно из инфицированной системы, можно заставить их работать неправильно. Для этого руткит может скрывать файлы, перехватывая системные вызовы или используя фильтрующий драйвер.

Поскольку программам, подобным Tripwire, присущи указанные ограничения, используются и другие методы обнаружения руткитов. В следующих разделах мы рассмотрим некоторые из них, применяемые для нахождения в памяти самого руткита или оставленных им улик.

Метод «охраны дверей»

Все программы должны «жить» где-то в памяти. Таким образом, чтобы найти руткит, можно исследовать память.

Исследовать память можно двояко. Первое — ловить руткит в момент его загрузки в память. При этом подходе, называемым охраной дверей (guarding the doors), проверяется все, что попадает в компьютер (процессы, драйверы устройств и т.д.).

Руткит может использовать вызовы многих системных функций, чтобы загрузить себя в память. Наблюдая за этими потенциально опасными точками программам обнаружения вторжений, иногда удается заметить руткит.

Однако контролируемых точек очень много, поэтому даже если один руткит обманет программу обнаружения вторжений, все усилия по защите пойдут насмарку.

Например, в системе IPD (Integrity Protection Driver — драйвер: защиты целостности) производства компании Pedestal Software защита была построена на перехвате функций ядра в SSDT, таких как NtLoadDriver и NtOpenSection.

Однако была найдена возможность загрузить модуль в ядро, вызвав функцию ZwSetSystemlnformation, которую IPD-драйвер не перехватывал. После того как это упущение IPD было исправлено, некто под псевдонимом Crazylord опубликовал статью, описывающую, как обойти защиту IPD-драйвера, используя символическую ссылку WDEVICEWPHYSICALMEMORY.

В результате разработчикам IPD-драйвера пришлось снова совершенствовать свое детище.

Последняя версия IPD-драйвера отлавливала следующие функции:
? ZwOpenKey;
? ZwCreateKey;
? ZwSetValueKey;
? ZwCreateFile;
? ZwOpenFile;

Для получения оптимальных результатов программы проверки целостности должны запускаться с копией проверяемого дискового образа на отдельной машине.

На данный момент компания Pedestal больше не поддерживает этот продукт.

К тому же список функций не полон. Например, еще одним способом загрузить руткит может быть проникновение в адресное пространство другого процесса. Кроме того, для загрузки DLL в другой процесс могут быть использованы другие подходы. Однако и это далеко не все доступные методы проникновения.

Поиск всех путей, которыми руткит мог бы проникнуть в систему, — это всего лишь первый шаг по защите от руткитов. В случае использования метода обнаружения при загрузке нужно решить две главные проблемы — что охранять и когда поднимать тревогу. Например, руткит может быть загружен в память через ключи реестра.

Очевидным способом выявить такую попытку является контроль функций ZwOpenKey, ZwCreateKey и ZwSetValueKey (как это делает, например, IPD-драйвер). Однако если программа обнаружения руткитов контролирует эти функции, как она узнает, какие ключи охранять?

Драйверы обычно располагаются в ключе:
HKEY_LOCAL_MACHINESystemCurrentControlSetServices

Вполне естественно наблюдать за этим ключом, но руткит может изменить и другой ключ:
HKEY_LOCAL_MACHINESystemControlSet001Services

Этот ключ используется, когда компьютер возвращается к предыдущей работоспособной конфигурации.

В данном примере мы даже не пытаемся учесть все те ключи реестра, которые отвечают за загрузку программных расширений. Кроме того, нужно учесть возможность загрузки дополнительных библиотек DLL, например, вспомогательных объектов браузера (Browser Helper Object).

Программы обнаружения руткитов должны также уделять внимание символическим ссылкам. Символические ссылки — это альтернативные имена системных объектов.

То есть объект, который вы пытаетесь защитить, может иметь более одного имени. И если ваша программа обнаружения руткитов контролирует таблицу системных вызовов, но руткит использует символическую ссылку, то истинная цель символической ссылки при вызове обработчика определена не будет.

Более того, например, ключ реестра HKEYLOCALMACHINE под этим именем не представлен в ядре. Даже если ваша программа будет перехватывать все нужные функции, количество точек, за которыми надо наблюдать, выглядит бесконечным!

Как избавиться от руткитовНо даже если предположить, что нам удалось найти все пути, которыми может воспользоваться руткит для загрузки, и мы знаем все возможные имена критических ресурсов, которые надо защищать, у нас остается проблема, как отличить «хорошие» программы от «плохих».

Нашей программе могли бы потребоваться сигнатуры для сравнения, что предполагает знание вектора атаки. Или наша программа могла бы эвристически анализировать поведение модуля, чтобы попытаться определить его намерения.

Оба этих подхода очень сложно реализовать на практике. Сигнатуры требуют знания руткита, и очевидно против неизвестного руткита они не помогут. Анализировать поведение также сложно, поскольку не ясны критерии положительных и отрицательных результатов проверки.

Столь же важно знать, когда поднимать тревогу. Эта битва за безопасность, которую ведут разработчики антивирусных программ, идет непрерывно.

Вы можете посмотреть так же записи

Содержание

  1. ZwOpenKey function (wdm.h)
  2. Syntax
  3. Parameters
  4. Return value
  5. Remarks
  6. Драйвер заблокирован от загрузки [3 БЫСТРЫХ ИСПРАВЛЕНИЯ]
  7. Драйвер заблокирован от загрузки [FIX]
  8. 1. Отключить принудительное использование подписи водителя
  9. 2. Отключите антивирусную защиту или добавьте исключение
  10. 3. Запустите ваши программы с правами администратора
  11. Windows 10 на Lenovo C340 перезагружается раз в один — два часа — как исправить?
  12. Ошибка загрузки драйвера zwopenkey

ZwOpenKey function (wdm.h)

The ZwOpenKey routine opens an existing registry key.

Syntax

Parameters

Pointer to the HANDLE variable that receives the handle to the key.

Specifies an ACCESS_MASK value that determines the requested access to the object. For more information, see the DesiredAccess parameter of ZwCreateKey.

Pointer to an OBJECT_ATTRIBUTES structure that specifies the object name and other attributes. Use InitializeObjectAttributes to initialize this structure. If the caller is not running in a system thread context, it must set the OBJ_KERNEL_HANDLE attribute when it calls InitializeObjectAttributes.

Return value

ZwOpenKey returns STATUS_SUCCESS if the given key was opened. Otherwise, it can return an error status, including the following:

ZwOpenKey supplies a handle that the caller can use to manipulate a registry key. The routine provides a subset of the functionality of ZwCreateKey. For more information, see Using the Registry in a Driver.

If the specified key does not exist, ZwOpenKey returns an error status and does not return a key handle.

Once the handle pointed to by KeyHandle is no longer in use, the driver must call ZwClose to close it.

ZwOpenKey ignores the security information in the structure that the ObjectAttributes parameter points to.

If the caller is not running in a system thread context, it must ensure that any handles it creates are private handles. Otherwise, the handle can be accessed by the process in whose context the driver is running. For more information, see Object Handles.

For more information about working with registry keys, see Using the Registry in a Driver.

Источник

Драйвер заблокирован от загрузки [3 БЫСТРЫХ ИСПРАВЛЕНИЯ]

Драйвер заблокирован от загрузки . Это сообщение об ошибке, которое выдается системой Windows при попытке установить или запустить программу или программное обеспечение, несовместимое с системой, которая обеспечивает питание вашего устройства.

Итак, мы можем обсудить ситуацию несовместимости. Однако та же проблема может возникнуть, когда антивирус блокирует обсуждаемое программное обеспечение или если у вас нет прав администратора.

В этом руководстве мы перечислим решения для устранения неполадок, которые могут помочь вам решить эту проблему.

Драйвер заблокирован от загрузки [FIX]

  • Решение 1. Отключите принудительное использование подписи драйверов
  • Решение 2. Отключите антивирусную защиту или добавьте исключение
  • Решение 3 – Запустите ваши программы с правами администратора

1. Отключить принудительное использование подписи водителя

В качестве меры безопасности Windows требует наличия драйверов с цифровой подписью. Это полезная функция, которая может защитить ваше устройство с Windows 10, но в некоторых ситуациях она может стать реальным источником проблем – например, проблема «Драйвер заблокирован от загрузки». Таким образом, попробуйте исправить эту ошибку, отключив принудительное использование подписи драйверов:

  1. Запустите на компьютере окно командной строки с повышенными правами: щелкните правой кнопкой мыши значок «Пуск» Windows и выберите « Командная строка (администратор) ».
  2. В окне cmd введите bcdedit.exe /, установите nointegritychecks на и нажмите Enter.
  3. Это автоматически отключит принудительное использование подписи драйверов на вашем устройстве.
  4. Если вы хотите снова включить эту функцию, вам нужно выполнить следующую команду в окне с повышенными привилегиями: bcdedit.exe/set nointegritychecks off .

Кроме того, вы также должны следовать:

  1. Нажмите правой кнопкой мыши на Мой компьютер (или Этот компьютер) и на левой панели открывающихся окон нажмите Расширенные настройки системы .
  2. Из Системных свойств перейдите на вкладку Дополнительно и в разделе Производительность нажмите Настройки .
  3. В разделе Параметры производительности перейдите в Предотвращение выполнения данных и убедитесь, что установлен флажок Включить DEP для основных программ и служб Windows только .
  4. Затем нажмите Win + R и введите gpedit.msc.
  5. Затем перейдите в «Конфигурация компьютера» -> «Настройки Windows» -> «Локальные политики» -> «Параметры безопасности» -> проверить поведение установки неподписанного драйвера.

2. Отключите антивирусную защиту или добавьте исключение

Если вы используете программное обеспечение безопасности Windows по умолчанию или любую другую стороннюю антивирусную программу, вы можете получить сообщение об ошибке «Драйвер заблокирован от загрузки» при попытке установить новые приложения или инструменты.

Поэтому, прежде всего, выберите отключение антивирусной защиты и повторите процесс установки. Если все работает без проблем, попробуйте добавить исключение в антивирусную программу для этой конкретной программы.

Всегда включайте защиту в своей системе Windows 10, чтобы все время было в безопасности.

Говоря об антивирусных инструментах, мы настоятельно рекомендуем вам проверить некоторые из лучших антивирусных программ для вашего ПК с Windows, прежде чем стать жертвой ScanGuard.

  • ТАКЖЕ ПРОЧИТАЙТЕ : ScanGuard Antivirus: вот что вам нужно знать об этом

3. Запустите ваши программы с правами администратора

Если вы запускаете программу без прав администратора, вы можете столкнуться с проблемой «Драйвер заблокирован от загрузки».

Поэтому, прежде чем пытаться применить или установить новое приложение или процесс, убедитесь, что вы завершили фактический процесс установки с правами администратора.

У нас также есть специальное руководство о том, как стать администратором.

Заключительные мысли

Если перечисленные выше методы устранения неполадок не помогли вам, возможно, вы столкнулись с проблемой несовместимости. Убедитесь, что вы устанавливаете правильное программное обеспечение для вашей конкретной платформы Windows 10.

По любым другим вопросам, не стесняйтесь и используйте поле для комментариев ниже.

Источник

Windows 10 на Lenovo C340 перезагружается раз в один — два часа — как исправить?

хорошего дня
Установленная версия Windows 10 — 1511 (сборка ОС 10586.164)
Каждый час / два моноблок Lenovo C340 перезагружается без предупреждения. Курсор мыши останавливается, и компьютер перезагружается.

Lenovo C340 Diagnostic Tools для Win 10 (x64), скачанный с сайта http://support.lenovo.com/ru/ru/products/Desktops-and-all-in-ones/Lenovo-C-Series- all — in-one / Lenovo-C340-All-in-One? linkTrack = Домашняя страница: Body_Search & beta = false, проблем с оборудованием нет.

В журнале ошибок Windows после перезагрузки появляется критическая ошибка:

Система

Поставщик
[Имя]
Microsoft-Windows-Ядро-Мощность
[Руководство]
<331c3b3a-2005-44c2-ac5e-77220c37d6b4>
ID события
41 год
Версия
3
Уровень
1
Задача
63
Рабочий код
0
Ключевое слово
0x8000400000000002

[ОраСистема]
2016-04-01T11: 27: 37.063209100Z
EventRecordID
3403
Корреляция

Исполнение
[ID процесса]
4
[ID темы]
восемь
Канал
Система
Компьютер
Ольга

Безопасность
[ID пользователя]
С-1-5-18

EventData
BugcheckCode
265

и после каждого перезапуска параметры (разные после каждого перезапуска):
Параметр Bugcheck 1
0xa3a01f5a706d8516
Параметр Bugcheck 2
0xb3b72be0c2ee5493
Параметр проверки ошибок 3
0xffffe001d66ba040
Параметр Bugcheck 4
0x1f

SleepInProgress
0
PowerButtonTimestamp
0
BootAppStatus
0
В чем может быть проблема?
Раньше система работала на Win 8. После обновления она работала нормально в течение трех недель. Эти перезагрузки начались на прошлой неделе. Программное обеспечение, отличное от Lenovo Diagnostic Site, не было установлено.

Подскажите ответ на вопрос, в чем проблема?
Спасибо

PS При этом при возникновении критической ошибки в журнале перед ней появляются еще три ошибки:

Ошибка загрузки драйвера: PreInitControl.
Ошибка загрузки драйвера: QueryPatchConfigInfo.
Ошибка загрузки драйвера: ZwOpenKey.

Источник

Ошибка загрузки драйвера zwopenkey

Если такой «самокомпилирующийся» файл запустить, то произойдет следущее. Первые две команды закомментарены, поэтому, они игнорируются компилятором masm, но принимаются командным процессором, который, в свою очередь, игнорирует символ «точка с запятой». Управление передается на метку :make , за которой находятся инструкции для компилятора и компоновщика. Все, что находится за директивой ассемблера end, игнорируется компилятором masm. Таким образом, весь текст между командой goto make и меткой :make , игнорируется командным процессором, но принимается компилятором masm. А все, что вне (включая команду goto make и метку :make ), игнорируется компилятором masm, но принимается командным процессором. Этот метод чрезвычайно удобен, т.к. исходный текст «помнит» с какими параметрами его нужно компилировать. Я буду применять такую технику в исходных текстах драйверов, а в исходных текстах программ управления, буду пользоваться обычным методом.

Параметры компоновки имеют следующий смысл:

— Указывает компоновщику, что нужно сформировать файл драйвера режима ядра Windows NT;

— Устанавливает предопределенный адрес загрузки образа драйвера равным 10000h. Я уже говорил про это в предыдущей статье;

— Память режима ядра — драгоценный ресурс. Поэтому, файлы драйверов имеют более «мелкое» выравнивание секций;

— По умолчанию компоновщик производит файлы с расширением .exe. При наличии ключа /dll файл будет иметь расширение .dll. Нам нужно получить файл с расшрением .sys;

— В PE-заголовке имеется поле, указывающее загрузчику образа исполняемого файла, для какой подсистемы этот файл предназначен: Win32, POSIX или OS/2. Это нужно для того, чтобы поместить образ в необходимое ему окружение. Подсистема Win32 автоматически запускается при загрузке системы. Если же запускается файл, предназначенный для функционирования, например, в подсистеме POSIX, то сначала операционная система запускает саму подсистему POSIX. Таким образом, с помощью этого ключа можно указать компоновщику, какая подсистема необходима. Когда мы компилируем *.exe или *.dll, то указываем под этим ключем значение windows, которое означает, что файлу требуется подсистема Win32. Драйверу вообще не нужна ни одна из подсистем, т.к. он работает в естественной (native) для самой операционной системы среде.

Самый простой драйвер режима ядра

Вот исходный текст простейшего драйвера режима ядра.

Как и у любого другого выполнимого модуля, у драйвера должна быть точка входа, на которую система передаст управление после загрузки драйвера в память. Как и полагается в программе на ассемблере, точкой входа является первая инструкция, обозначенная меткой указанной в директиве end. У нас, как и в текстах на с, это DriverEntry, которая оформлена в виде процедуры, принимающей два параметра. Имя процедуры, естественно, может быть любым. Прототип DriverEntry выглядит так:

К сожалению, Microsoft отошла от принципа «венгерской нотации» при составлении заголовочных файлов и документации DDK. Возможно, это связано с большим количеством специфических типов данных, используемых в DDK. Хотя, в обозначении типов кое-что осталось. В исходных текстах я буду придерживаться этого принципа везде, где только возможно, т.к. настолько привык им пользоваться, что исходники не использующие «венгерскую нотацию» мне кажутся совершенно нечитабельными. Поэтом, легким движением руки, DriverObject превращается в pDriverObject, а RegistryPath в pusRegistryPath.

Типы данных PDRIVER_OBJECT и PUNICODE_STRING определены в файлах includew2kntddk.inc и includew2kntdef.inc соответственно.

— указатель на объект только что созданного драйвера.

Windows является объектно-ориентированной системой. Поэтому, понятие объект распространяется на все, что только можно, и что нельзя тоже. И объект «драйвер» не является исключением. Загружая драйвер, система создает объект «драйвер» (driver object), представляющий для нее образ драйвера в памяти. Через этот объект система управляет драйвером. Звучит красиво, но не дает никакого представления о том, что же в действительности происходит. Если отбросить всю эту объектно-ориентированную мишуру, то станет очевидно, что объект «драйвер» представляет собой обыкновенную структуру данных типа DRIVER_OBJECT (определена в includew2kntddk.inc). Некоторые поля этой структуры заполняет система, некоторые придется заполнять нам самим. Обращаясь к этой структуре, система и управляет драйвером. Итак, как вы наверное уже поняли, первым параметром, передающимся в функцию DriverEntry, как раз и является указатель на эту самую структуру (или пользуясь объектно-ориентированной терминологией — объект «драйвер»). Используя этот указатель, мы можем (и будем, но позже) заполнить соответствующие поля структуры DRIVER_OBJECT. Но, в рассматриваемых в этой части статьи драйверах этого не требуется, поэтому мы, пока, оставим pDriverObject без внимания.

— указатель на раздел реестра, содержащий параметры инициализации драйвера. Про этот раздел, мы достаточно подробно говорили в прошлый раз.

Точнее говоря, это указатель на структуру типа UNICODE_STRING. А уже в ней содержится указатель на саму Unicode-строку, содержащую имя раздела. Этот указатель драйвер может использовать для добавления (или извлечения, в чем мы очень скоро убедимся) в реестр какой-либо информации, которую он сможет в дальнейшем использовать. В этом случае необходимо сохранить путь к подразделу реестра, но не сам указатель, т.к. по выходу из процедуры DriverEntry он потеряет всякий смысл. Но, обычно этого не требуется.

О формате данных UNICODE_STRING следует сказать особо. В отличие от режима пользователя, режим ядра оперирует строками в формате UNICODE_STRING. Эта структура определена в файле includew2kntdef.inc следующим образом:

— (мне пришлось изменить оригинальное имя Length, т.к. оно является зарезервированным словом) содержит текущую длину строки в байтах (не в символах!), не считая завершающего нуля.

— максимальный размер буфера (также в байтах), в котором эта строка содержится.

— указатель на саму Unicode-строку.

Главное достоинство этого формата в том, что он явно определяет, как текущую длину строки, так и ее максимально возможную длину. Это позволяет, при операциях с такой строкой, обойтись без некоторых дополнительных вычислений.

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

Это приведет к остановке системы и появлению BSOD (Blue Screen Of Death). А выполнение такого кода приведет к перезагрузке компьютера:

Такой радикальный способ, прервать попытку исследования программы, иногда встречается в защитах. Честно говоря, я и сам на это не раз попадался 😉

В этих двух случаях, процедура DriverEntry никогда не вернет управление. Поэтому, возвращаемое ей значение не важно. Если же действия выполняемые DriverEntry будут более конструктивными, как, например, в драйвере beeper.sys, то надо вернуть системе некое значение, указывающее на то, как прошла инициализация драйвера. Если вернуть STATUS_SUCCESS, то инициализация считается успешной, и драйвер остается в памяти. Любое другое значение STATUS_* указывает на ошибку, и в этом случае драйвер выгружается системой. Вышеприведенный драйвер (srcArticle2-3simplestsimplest.sys) является самым простым, какой только можно себе представить. Единственное что он делает, это позволяет себя загрузить. Т.к. ничего кроме этого он сделать больше не может, то возвращает код ошибки STATUS_DEVICE_CONFIGURATION_ERROR. Я просто подобрал подходящее по смыслу значение (полный список можно посмотреть в файле includew2kntstatus.inc). Если возвратить STATUS_SUCCESS, то драйвер так и останется болтаться в памяти без дела, и выгрузить его средствами SCM будет невозможно, т.к. мы не определили процедуру отвечающую за выгрузку драйвера. Эта процедура должна находиться в самом драйвере. Она выполняет действия, зеркальные по отношению к DriverEntry. Если драйвер выделил себе какие-то ресурсы, например, память, то в процедуре выгрузки эта память должна быть возвращена системе. И только сам драйвер знает об этом. Но, тут я немного забежал вперед. Пока нам это не понадобится.

Драйвер режима ядра beeper.sys

Теперь перейдем к рассмотрению драйвера, программу управления которым, мы писали в прошлый раз. Мне пришлось переименовать его из beep.sys в beeper.sys, потому что, как оказалось, в NT4 и в некоторых версиях XP уже существует драйвер beep.sys. Вобще говоря, beep.sys есть во всех версиях NT (%SystemRoot%System32Driversbeep.sys), но он еще должен быть зарегистрирован в реестре. Как бы там ни было, надеюсь beeper.sys будет уникальным. Вот его исходный текст:

Задача этого драйвера, исполнять на системном динамике восходящее до-мажорное арпеджио. Что это такое, вы, наверное уже послушали. Для этого драйвер использует инструкции процессора in и out, обращаясь к соответствующим портам ввода-вывода. Общеизвестно, что доступ к портам ввода-вывода — это свято охраняемый Windows NT системный ресурс. Попытка обращения к любому из них, как на ввод, так и на вывод, из режима пользователя, неизбежно приводит к завершению приложения. Но, на самом деле, есть способ обойти и это ограничение, т.е. обращаться к портам ввода-вывода прямо из третьего кольца. В этом вы убедитесь ниже. Правда, для этого, опять таки, нужен драйвер.

На материнской плате находится устройство системный таймер , который является перепрограммируемым. Таймер содержит несколько каналов, 2-ой управляет системным динамиком компьютера, генерируя прямоугольные импульсы с частотой 1193180/ начальное значение счетчика > герц. Начальное значение счетчика является 16-битным, и устанавливается через порт 42h. 1193180 Гц — частота тактового генератора таймера. Тут есть одна тонкость, которую я не совсем понимаю. Функция QueryPerformanceFrequency из kernel32.dll действительно возвращает значение 1193180. Оно просто жестко зашито в тело функции. Но дизассемблировав hal.dll, в функции HalMakeBeep я обнаружил несколько другое значение, равное 1193167 Гц. Его я и использую. Возможно, здесь учтена какая-то временная задержка, или что-то подобное. В любом случае, пищать системным динамиком нам это никак не помешает. Я не буду подробно останавливаться на описании системного таймера. Эту тему очень любят мусолить почти в каждой книжке по программированию на ассемблере. Достаточно подробную информацию можно найти в сети.

Итак, первый звук до-мажорного арпеджио мы воспроизводим пользуясь процедурой MakeBeep1.

Выводом в порт 43h двоичного числа 10110110, мы помещаем в управляющий регистр таймера значение, определяющее номер канала, которым мы будем управлять, тип операции, режим работы канала и формат счетчика.

Затем, в порт 42h выводим 16-битное начальное значение счетчика. Сначала младший байт, затем старший.

И, наконец, посредством вывода в порт 61h значения, с установленными 0-ым и 1-ым битами, включаем динамик.

Даем данамику позвучать некоторое время, пользуясь макросом DO_DELAY. Да — примитивно, но — эффективно 😉

И выключаем динамик, сбрасывая два младших бита. При этом надо не забывать, что таймер — это глобальный системный ресурс. Поэтому, на время работы с регистрами таймера, мы запрещаем аппаратные прерывания.

Источник

Понравилась статья? Поделить с друзьями:
  • Ошибка загрузки ежедневных заданий код ошибки 002000 как исправить
  • Ошибка загрузки драйвера nvidia
  • Ошибка загрузки драйверов алкоголь 120
  • Ошибка загрузки драйвера bad tag length
  • Ошибка загрузки драйверов alcohol 120 на windows 10