Оригинал

P.S. Спасибо vaber за предоставленную ссылку.

В ОС Windows 2000, Windows XP и Windows 2003 для этого необходимо отредактировать файл boot.ini. Для ОС Windows Vista и Windows 7 необходимо использовать команду bcdedit. Полное описание процедуры [...]]]> Операционная система Windows предоставляет разработчикам возможность использования альтернативного файла ядра. Прежде всего, это необходимо для того, чтобы заменить обычное ядро ОС на checked build.

В ОС Windows 2000, Windows XP и Windows 2003 для этого необходимо отредактировать файл boot.ini. Для ОС Windows Vista и Windows 7 необходимо использовать команду bcdedit. Полное описание процедуры находится в MSDN.

В документации ясно сказано, что имя альтернативного файла ядра должно удовлетворять требованию 8.3 (имя_файла.расширение):

kernel file

Directs the operating system loader to load an alternate kernel. The specified file must be located in the %SystemRoot%\system32 directory, and its file name must conform to 8.3−character format.

Проведем эксперимент с Windows XP и Windows Vista.

Для Windows XP необходимо отредактировать файл boot.ini. Скопируем ядро в %system32% (у меня это ntoskrnl.exe) в файл 12345678.exe и пропишем его в boot.ini:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=»Microsoft Windows XP Professional» /noexecute=optin /fastdetect /debug /debugport=COM1: /baudrate=115200 /kernel=12345678.exe
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=»Microsoft Windows XP Professional» /noexecute=optin /fastdetect

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

kd> dd PsLoadedModuleList L2
8055b1c0 81bfc390 81bf1780
kd> dt nt!_LDR_DATA_TABLE_ENTRY 81bfc390
+0×000 InLoadOrderLinks : _LIST_ENTRY [ 0x81bfc328 - 0x8055b1c0 ]
+0×008 InMemoryOrderLinks : _LIST_ENTRY [ 0x0 - 0x0 ]
+0×010 InInitializationOrderLinks : _LIST_ENTRY [ 0x0 - 0x0 ]
+0×018 DllBase : 0x804d7000
+0x01c EntryPoint : 0x806aeb2c
+0×020 SizeOfImage : 0×216680
+0×024 FullDllName : _UNICODE_STRING «\WINDOWS\system32\12345678.EXE»
+0x02c BaseDllName : _UNICODE_STRING «ntoskrnl.exe»
+0×034 Flags : 0×4004000
+0×038 LoadCount : 1
+0x03a TlsIndex : 0
+0x03c HashLinks : _LIST_ENTRY [ 0x0 - 0x2247c2 ]
+0x03c SectionPointer : (null)
+0×040 CheckSum : 0x2247c2
+0×044 TimeDateStamp : 0
+0×044 LoadedImports : (null)
+0×048 EntryPointActivationContext : (null)
+0x04c PatchInformation : 0x0074006e

Отлично, мы смогли загрузить альтернативное ядро. Теперь изменим имя файла на более длинное, например, на 123456789.exe и повторим эксперимент.

kd> dd PsLoadedModuleList L2
8055b1c0 81bfc390 81bf1780
kd> dt nt!_LDR_DATA_TABLE_ENTRY 81bfc390
+0×000 InLoadOrderLinks : _LIST_ENTRY [ 0x81bfc328 - 0x8055b1c0 ]
+0×008 InMemoryOrderLinks : _LIST_ENTRY [ 0x0 - 0x0 ]
+0×010 InInitializationOrderLinks : _LIST_ENTRY [ 0x0 - 0x0 ]
+0×018 DllBase : 0x804d7000
+0x01c EntryPoint : 0x806aeb2c
+0×020 SizeOfImage : 0×216680
+0×024 FullDllName : _UNICODE_STRING «\WINDOWS\system32\ntoskrnl.exe»
+0x02c BaseDllName : _UNICODE_STRING «ntoskrnl.exe»
+0×034 Flags : 0×4004000
+0×038 LoadCount : 1
+0x03a TlsIndex : 0
+0x03c HashLinks : _LIST_ENTRY [ 0x0 - 0x2247c2 ]
+0x03c SectionPointer : (null)
+0×040 CheckSum : 0x2247c2
+0×044 TimeDateStamp : 0
+0×044 LoadedImports : (null)
+0×048 EntryPointActivationContext : (null)
+0x04c PatchInformation : 0x0074006e

Очевидно, что операционная система проигнорировала длинное имя файла ядра.

Теперь повторим эксперимент на Windows Vista. Скопируем ядро (у меня это ntkrnlpa.exe) в файл 12345678.exe, установим альтернативное ядро и перезагрузим компьютер с активным отладчиком ядра.

C:\Windows\System32>bcdedit /set kernel 12345678.exe
The operation completed successfully.

C:\Windows\System32>bcdedit /enum
Windows Boot Loader
——————-
identifier {current}
device partition=C:
path \Windows\system32\winload.exe
description DebugEntry
locale en-US
inherit {bootloadersettings}
osdevice partition=C:
systemroot \Windows
kernel 12345678.exe
resumeobject {603268e3-3922-11de-a356-966f5237e32f}
nx OptIn
detecthal No
usefirmwarepcisettings No
debug Yes

kd> dd PsLoadedModuleList L2
81952c70 82f69bb8 82f6f7b0
kd> dt nt!_LDR_DATA_TABLE_ENTRY 82f69bb8
+0×000 InLoadOrderLinks : _LIST_ENTRY [ 0x82f69b48 - 0x81952c70 ]
+0×008 InMemoryOrderLinks : _LIST_ENTRY [ 0x818f0ae4 - 0x14 ]
+0×010 InInitializationOrderLinks : _LIST_ENTRY [ 0x0 - 0x0 ]
+0×018 DllBase : 0x8183b000
+0x01c EntryPoint : 0x819274b0
+0×020 SizeOfImage : 0x3b9000
+0×024 FullDllName : _UNICODE_STRING «\SystemRoot\system32\12345678.exe»
+0x02c BaseDllName : _UNICODE_STRING «ntoskrnl.exe»
+0×034 Flags : 0×4000
+0×038 LoadCount : 1
+0x03a TlsIndex : 0
+0x03c HashLinks : _LIST_ENTRY [ 0x0 - 0x372038 ]
+0x03c SectionPointer : (null)
+0×040 CheckSum : 0×372038
+0×044 TimeDateStamp : 0
+0×044 LoadedImports : (null)
+0×048 EntryPointActivationContext : (null)
+0x04c PatchInformation : (null)
+0×050 ForwarderLinks : _LIST_ENTRY [ 0x0 - 0x74006e ]
+0×058 ServiceTagLinks : _LIST_ENTRY [ 0x73006f - 0x72006b ]
+0×060 StaticLinks : _LIST_ENTRY [ 0x6c006e - 0x65002e ]

Результат как на Windows XP. Повторим эксперимент с длинным именем файла ядра.

kd> dd PsLoadedModuleList L2
81919c70 82f69bb8 82f6f7b0
kd> dt nt!_LDR_DATA_TABLE_ENTRY 82f69bb8
+0×000 InLoadOrderLinks : _LIST_ENTRY [ 0x82f69b48 - 0x81919c70 ]
+0×008 InMemoryOrderLinks : _LIST_ENTRY [ 0x818b7ae4 - 0x14 ]
+0×010 InInitializationOrderLinks : _LIST_ENTRY [ 0x0 - 0x0 ]
+0×018 DllBase : 0×81802000
+0x01c EntryPoint : 0x818ee4b0
+0×020 SizeOfImage : 0x3b9000
+0×024 FullDllName : _UNICODE_STRING «\SystemRoot\system32\123456789.exe»
+0x02c BaseDllName : _UNICODE_STRING «ntoskrnl.exe»
+0×034 Flags : 0×4000
+0×038 LoadCount : 1
+0x03a TlsIndex : 0
+0x03c HashLinks : _LIST_ENTRY [ 0x0 - 0x372038 ]
+0x03c SectionPointer : (null)
+0×040 CheckSum : 0×372038
+0×044 TimeDateStamp : 0
+0×044 LoadedImports : (null)
+0×048 EntryPointActivationContext : (null)
+0x04c PatchInformation : (null)
+0×050 ForwarderLinks : _LIST_ENTRY [ 0x0 - 0x74006e ]
+0×058 ServiceTagLinks : _LIST_ENTRY [ 0x73006f - 0x72006b ]
+0×060 StaticLinks : _LIST_ENTRY [ 0x6c006e - 0x65002e ]

Очевидно, что ОС Windows Vista и Windows 7 умеют работать с длинными именами, которые не удовлетворяют требованию 8.3.

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

Вкратце суть алгоритма сводилась к следующему: в [...]]]> Как известно, в операционной системе Windows (2000, XP, 2003) существует механизм защиты системных файлов, также известный как Windows File Protection. Данный механизм не позволяет изменять или удалять критичные объекты операционной системы, в частности системные DLL и различные драйверы. В случае обнаружения изменений ОС восстанавливает такие файлы.

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

В скором времени данный алгоритм изучили и были придуманы многочисленные способы обхода данной технологи. Использование недокументированных функций системной библиотеки sfc_os.dll или изменение sfc.dll/sfc_os.dll стали широко использоваться в различных вредоносных программах.

Но не это нас интересует, а то, как видоизменился данный механизм в операционных системах Windows Vista и Windows 7.

В данных операционных системах Microsoft полностью отказалась от данной технологии и перешла на технологию Windows Resource Protection. Теперь в системе нет следящего потока, а доступ к файлам ограничивается операционной системой с помощью DACL и ACL, стандартного механизма защиты Windows. Однако даже у администратора нет прав на изменение или удаление системных файлов.

Поэкспериментируем с операционной системой Windows 7 RTM и попробуем удалить какой-либо системный файл.

Так выглядит попытка удаления системного файла, которую я отследил с помощью Process Monitor

Посмотрим свойства файла

Как и было сказано даже у администратора нет прав на изменение файла.

Посмотрим, как с этим обстоят дела у TrustedInstaller

Как мы видим — полный контроль над файлом.

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

Все это не очень удобно, если необходимо произвести изменение нескольких файлов. Попробуем найти способ проще. Для этого воспользуемся отладчиком WinDbg и утилитой psgetsid, которая умеет транслировать имя в SID и обратно:

C:\1>psgetsid «NT SERVICE\TrustedInstaller»

PsGetSid v1.43 — Translates SIDs to names and vice versa
Copyright (C) 1999-2006 Mark Russinovich
Sysinternals — www.sysinternals.com

SID for NT SERVICE\TrustedInstaller:
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

Теперь перечислим все процессы в системе и попробуем найти хотя бы один имеющий нужные нам права:

kd> !for_each_process «r $t0 = @#Process; r? $t1 = @@c++(((nt!_EPROCESS*)@$t0)->Token.Object); !token -n @$t1 & 0xFFFFFFF8;»

Приведу лишь token первого процесса (системного):

_TOKEN 87a01398
TS Session ID: 0
User: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
Groups:
00 S-1-5-32-544 (Alias: BUILTIN\Administrators)
Attributes — Default Enabled Owner
01 S-1-1-0 (Well Known Group: localhost\Everyone)
Attributes — Mandatory Default Enabled
02 S-1-5-11 (Well Known Group: NT AUTHORITY\Authenticated Users)
Attributes — Mandatory Default Enabled
03 S-1-16-16384 Unrecognized SID
Attributes — GroupIntegrity GroupIntegrityEnabled
Primary Group: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
Privs:
02 0×000000002 SeCreateTokenPrivilege Attributes -
03 0×000000003 SeAssignPrimaryTokenPrivilege Attributes -
04 0×000000004 SeLockMemoryPrivilege Attributes — Enabled Default
05 0×000000005 SeIncreaseQuotaPrivilege Attributes -
07 0×000000007 SeTcbPrivilege Attributes — Enabled Default
08 0×000000008 SeSecurityPrivilege Attributes -
09 0×000000009 SeTakeOwnershipPrivilege Attributes -
10 0x00000000a SeLoadDriverPrivilege Attributes -
11 0x00000000b SeSystemProfilePrivilege Attributes — Enabled Default
12 0x00000000c SeSystemtimePrivilege Attributes -
13 0x00000000d SeProfileSingleProcessPrivilege Attributes — Enabled Default
14 0x00000000e SeIncreaseBasePriorityPrivilege Attributes — Enabled Default
15 0x00000000f SeCreatePagefilePrivilege Attributes — Enabled Default
16 0×000000010 SeCreatePermanentPrivilege Attributes — Enabled Default
17 0×000000011 SeBackupPrivilege Attributes -
18 0×000000012 SeRestorePrivilege Attributes -
19 0×000000013 SeShutdownPrivilege Attributes -
20 0×000000014 SeDebugPrivilege Attributes — Enabled Default
21 0×000000015 SeAuditPrivilege Attributes — Enabled Default
22 0×000000016 SeSystemEnvironmentPrivilege Attributes -
23 0×000000017 SeChangeNotifyPrivilege Attributes — Enabled Default
25 0×000000019 SeUndockPrivilege Attributes -
28 0x00000001c SeManageVolumePrivilege Attributes -
29 0x00000001d SeImpersonatePrivilege Attributes — Enabled Default
30 0x00000001e SeCreateGlobalPrivilege Attributes — Enabled Default
31 0x00000001f SeTrustedCredManAccessPrivilege Attributes -
32 0×000000020 SeRelabelPrivilege Attributes -
33 0×000000021 SeIncreaseWorkingSetPrivilege Attributes — Enabled Default
34 0×000000022 SeTimeZonePrivilege Attributes — Enabled Default
35 0×000000023 SeCreateSymbolicLinkPrivilege Attributes — Enabled Default
Authentication ID: (0,3e7)
Impersonation Level: Anonymous
TokenType: Primary
Source: *SYSTEM* TokenFlags: 0×2000 ( Token in use )
Token ID: 3ea ParentToken ID: 0
Modified ID: (0, 3eb)
RestrictedSidCount: 0 RestrictedSids: 00000000
OriginatingLogonSession: 0

Попробуем во всем выводе в консоли WinDbg найти SID TrustedInstaller. На моем тестовом стенде ничего найдено не было. Но ведь есть сервис, который может изменять системные компоненты и находится он в \Windows\servicing\TrustedInstaller.exe, а запустить его мы можем вручную из вкладки Services. Называется он Windows Modules Installer и имеет следующее описание: «Enables installation, modification, and removal of Windows updates and optional components. If this service is disabled, install or uninstall of Windows updates might fail for this computer.»

После запуска можно повторить команду вывода Token для каждого процесса или найти Token вручную в процессе TrustedInstaller.exe.

PROCESS 85f79030 SessionId: 0 Cid: 0910 Peb: 7ffd3000 ParentCid: 01e8
DirBase: 3ef59520 ObjectTable: 90e37080 HandleCount: 121.
Image: TrustedInstaller.exe

kd> ? poi( 85f79030 + 0xf8 ) & 0xFFFFFFF8
Evaluate expression: -1730040888 = 98e1abc8

0xf8 – это смещение до Token в структуре nt!_EPROCESS, а Token – это структура nt!_EX_FAST_REF:

kd> dt nt!_EX_FAST_REF
+0×000 Object : Ptr32 Void
+0×000 RefCnt : Pos 0, 3 Bits
+0×000 Value : Uint4B

Поэтому необходимо отбросить младшие 3 бита адреса.

kd> !token -n 98e1abc8
_TOKEN 98e1abc8
TS Session ID: 0
User: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
Groups:
00 S-1-16-16384 Unrecognized SID
Attributes — GroupIntegrity GroupIntegrityEnabled
01 S-1-1-0 (Well Known Group: localhost\Everyone)
Attributes — Mandatory Default Enabled
02 S-1-5-32-545 (Alias: BUILTIN\Users)
Attributes — Mandatory Default Enabled
03 S-1-5-6 (Well Known Group: NT AUTHORITY\SERVICE)
Attributes — Mandatory Default Enabled
04 S-1-2-1 (no name mapped)
Attributes — Mandatory Default Enabled
05 S-1-5-11 (Well Known Group: NT AUTHORITY\Authenticated Users)
Attributes — Mandatory Default Enabled
06 S-1-5-15 (Well Known Group: NT AUTHORITY\This Organization)
Attributes — Mandatory Default Enabled
07 S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 (Well Known Group: NT SERVICE\TrustedInstaller)
Attributes — Default Enabled Owner
08 S-1-5-5-0-1412741 (no name mapped)
Attributes — Mandatory Default Enabled Owner LogonId
09 S-1-2-0 (Well Known Group: localhost\LOCAL)
Attributes — Mandatory Default Enabled
10 S-1-5-32-544 (Alias: BUILTIN\Administrators)
Attributes — Default Enabled Owner
Primary Group: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
Privs:
03 0×000000003 SeAssignPrimaryTokenPrivilege Attributes -
04 0×000000004 SeLockMemoryPrivilege Attributes — Enabled Default
05 0×000000005 SeIncreaseQuotaPrivilege Attributes -
07 0×000000007 SeTcbPrivilege Attributes — Enabled Default
08 0×000000008 SeSecurityPrivilege Attributes -
09 0×000000009 SeTakeOwnershipPrivilege Attributes -
10 0x00000000a SeLoadDriverPrivilege Attributes -
11 0x00000000b SeSystemProfilePrivilege Attributes — Enabled Default
12 0x00000000c SeSystemtimePrivilege Attributes -
13 0x00000000d SeProfileSingleProcessPrivilege Attributes — Enabled Default
14 0x00000000e SeIncreaseBasePriorityPrivilege Attributes — Enabled Default
15 0x00000000f SeCreatePagefilePrivilege Attributes — Enabled Default
16 0×000000010 SeCreatePermanentPrivilege Attributes — Enabled Default
17 0×000000011 SeBackupPrivilege Attributes — Enabled
18 0×000000012 SeRestorePrivilege Attributes — Enabled
19 0×000000013 SeShutdownPrivilege Attributes -
20 0×000000014 SeDebugPrivilege Attributes — Enabled Default
21 0×000000015 SeAuditPrivilege Attributes — Enabled Default
22 0×000000016 SeSystemEnvironmentPrivilege Attributes -
23 0×000000017 SeChangeNotifyPrivilege Attributes — Enabled Default
25 0×000000019 SeUndockPrivilege Attributes -
28 0x00000001c SeManageVolumePrivilege Attributes -
29 0x00000001d SeImpersonatePrivilege Attributes — Enabled Default
30 0x00000001e SeCreateGlobalPrivilege Attributes — Enabled Default
33 0×000000021 SeIncreaseWorkingSetPrivilege Attributes — Enabled Default
34 0×000000022 SeTimeZonePrivilege Attributes — Enabled Default
35 0×000000023 SeCreateSymbolicLinkPrivilege Attributes — Enabled Default
Authentication ID: (0,3e7)
Impersonation Level: Anonymous
TokenType: Primary
Source: Advapi TokenFlags: 0×2000 ( Token in use )
Token ID: 158ec1 ParentToken ID: 0
Modified ID: (0, 158ff6)
RestrictedSidCount: 0 RestrictedSids: 00000000
OriginatingLogonSession: 3e7

А теперь давайте подменим Token процесса FAR.exe на Token процесса TrustedInstaller.exe:

PROCESS 84c9e030 SessionId: 1 Cid: 08d0 Peb: 7ffda000 ParentCid: 07b0
DirBase: 3ef593c0 ObjectTable: 90fe1308 HandleCount: 264.
Image: Far.exe

kd> ed 84c9e030+f8 98e1abc8

После этих нехитрых манипуляций файловый менеджер FAR получает все необходимые права и может изменять и/или удалять защищаемые системные файлы без каких-либо изощрений с захватом прав пользования отдельного файла.

Одной из самых объемных и важных документаций для программистов является MSDN (Microsoft Developer [...]]]> Грамотная документация — залог здоровья и спокойствия программиста. Причем начинающего программиста, так как эксперт проблему решит намного быстрее. Да и не впервой ему — эксперту сталкиваться с плохой документацией, с программным кодом без комментариев и прочими неприятными вещами.

Одной из самых объемных и важных документаций для программистов является MSDN (Microsoft Developer Network). Для низкоуровневых программистов и программистов драйверов существует отдельная документация WDK (Windows Driver Kit), входящая в состав MSDN. В MSDN перечислены функции, параметры к ним, объяснения, примеры кода и многое другое.

Большая документация — сложный продукт. В любом сложном продукте есть недочеты, ошибки и недоработки. Встречаются они и в документации, ведь все мы люди, все мы ошибаемся. Недавно с такой ошибкой столкнулся и я.

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

Прототип функции ZwNotifyChangeKey выглядит так:

NTSTATUS
ZwNotifyChangeKey(
  __in HANDLE  KeyHandle,
  __in_opt HANDLE  Event,
  __in_opt PIO_APC_ROUTINE  ApcRoutine,        // указатель на нашу функцию
  __in_opt PVOID  ApcContext,
  __out PIO_STATUS_BLOCK  IoStatusBlock,
  __in ULONG  CompletionFilter,
  __in BOOLEAN  WatchTree,
  __out_bcount_opt(BufferSize) PVOID  Buffer,
  __in ULONG  BufferSize,
  __in BOOLEAN  Asynchronous
  );

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

Функция должна быть определена так:

typedef VOID (NTAPI *PIO_APC_ROUTINE) ( IN PVOID ApcContext, IN PIO_STATUS_BLOCK IoStatusBlock, IN ULONG Reserved )

Не суть важно, что тут за параметры, главное — то, что у функции три аргумента. Это важно.

В одном из драйверов мне понадобилась эта функция. Я написал весь сопутствующий код, использовал функцию, скомпилировал драйвер, положил в нужное место и запустил. Система упала в BSOD. ‘Не в первый и не в последний раз’, — подумал я и начал проверять параметры функции. Все было идеально, все было правильно, а BSOD повторялся каждый раз.

Google не смог мне помочь с данной проблемой и пришлось разбираться самому. Потратив некоторое количество часов, я выяснил, что в недрах операционной системы при определенных обстоятельствах указатель PIO_APC_ROUTINE трактуется совершенно по-другому, как указатель на структуру WORK_QUEUE_ITEM, в которой содержится указатель на нами определенную функцию. И этого не было в документации, эту информацию я даже не смог найти в сети.

Структура выглядит следующим образом:

typedef struct _WORK_QUEUE_ITEM {
    LIST_ENTRY List;
    PWORKER_THREAD_ROUTINE WorkerRoutine;        // указатель на нашу функцию
    __volatile PVOID Parameter;
} WORK_QUEUE_ITEM, *PWORK_QUEUE_ITEM;

Функция должна быть определена так:

typedef VOID (*PWORKER_THREAD_ROUTINE)( IN PVOID Parameter )

И она принимает всего один параметр. И это важно.

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

Ошибки бывают разные, но ошибки в документации дорогого стоят. До следующих ошибок, а они обязательно будут.

Оригинал

Как это обычно бывает перед релизом, что-нибудь обязательно ломается. Так и в этот раз у меня сломался рабочий ноутбук, а точнее умер жесткий диск. Долго ли, коротко ли, но я купил новый диск и решил поставить Windows Vista (у Sony Vaio большие проблемы с установкой Windows XP, которая не видит жесткого диска при установке).

Решено было поставить версию Home Premium, так как для работы вполне должно хватать. Я взял английскую версию, так как не переношу никаких переводов операционной системы, особенно на русский язык. Инсталляционный код не думая взял с задней крышки ноутбука. Все прошло относительно быстро и успешно. Однако после второй перезагрузки получаю BSOD. Удивился я очень сильно, настолько сильно, что с первого раза даже не успел рассмотреть номер STOP-ошибки. Со второго раза все-таки разглядел STOP 0x0000012A.

kd> !analyze -show 0x0000012A
MUI_NO_VALID_SYSTEM_LANGUAGE (12a)
Windows did not find any installed, licensed language packs for the system default UI language.
Arguments:
Arg1: 00000000, The subtype of the bugcheck.
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Пришлось брать ядро, загружать в IDA и смотреть.

Вызов функции MUIBugCheck с нашим заветным кодом

Из этой функции вызывается MUIBugCheck, она есть в SSDT

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

Так в чем же все-таки дело? А дело все в том, что я поставил английскую версию операционной системы, а ввел ключ от русской версии. Вот такая хитрая Vista. Берегите свои нервы, пользуйтесь только правильными ключами и правильными версиями. В итоге была поставлена английская Windows Vista Enterprise с правильным ключом.