Восстановление паролей к PWL-файлам

Автор: (c)PolASoft, 2003
WWW: www.InsidePro.com
Версия документа: 1.0

Содержание

• Введение
• Формат PWL-файлов Windows'OSR2/98/ME
• Описание алгоритмов, используемых для шифрования PWL-файлов
• Оптимизация алгоритмов восстановления паролей
• Заключение

Введение

PWL-файлы (или так называемые парольные кэши Windows) - это файлы с именами пользователей компьютера и с расширениями *.PWL (к примеру, Master.PWL, Sales.PWL и пр.), которые находятся в директории Windows.

Это файлы, в которых хранятся различные аккаунты (т.е. сочетание логин/пароль) данного пользователя, т.е. пароли ко всем ресурсам, при первом подключении к которым в окне ввода пароля был включен флажок "Запомнить пароль". Таким образом, в нем хранятся пароли к "расшаренным" ресурсам сети, пароли на подключение к NetWare/NT-серверам, пароли на Dial-Up-соединения и пр.

Функция запоминания паролей в Windows реализована давно и была введена с "благой" целью - облегчение работы пользователей. И действительно - зачем вводить каждый раз при подключении к провайдеру пароль "q6Rf8UI24dq" :) , когда можно один раз ввести его с бумажки, а потом забыть про этот пароль вообще. Таким образом, Windows собирает все пароли пользователя, шифрует их с помощью логина (имени пользователя) и текущего пароля пользователя (т.е. того пароля, который вводится при загрузке Windows) и хранит в этом PWL-файле.

Естественно, все эти данные зашифрованы определенными алгоритмами, и для их дешифрования необходимо знать пароль пользователя - а это фактически пароль на вход в Windows. А так как людям свойственно забывать свои пароли, то подбор пароля, во-первых, позволяет его "вспомнить", а во-вторых, позволяет просмотреть список аккаунтов этого пользователя, которые Windows сохраняет в этом PWL-файле, например, там может быть и забытый пароль на подключение к провайдеру. ;)

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

И сразу оговорюсь, что речь пойдет только о PWL-файлах операционных систем Windows'OSR2/98/ME, т.к. в PWL-файлах ОС Windows'3.11/95 методы шифрования гораздо проще и подбор пароля любой сложности - дело одного часа работы любой программы по восстановлению к ним паролей, в том числе и PWLInside.

Вся информация в тексте о времени выполнения фрагментов кода в тактах дана для следующих типов процессоров:

1. Intel Pentium MMX/II/III и все Celeron'ы из этих семейств.
2. AMD K6-II/III, все Duron'ы и Athlon'ы.

Примеры кода, приведенные ниже, даны в синтаксисе Microsoft Visual С++ v6.0 и MASM v7.0.

Формат PWL-файлов Windows'OSR2/98/ME

Информация о формате PWL-файлов компанией Microsoft нигде и никогда не документировалась, и, хотя в Интернете можно найти много различных документов по форматам PWL-ок, вся эта информация взята из практического использования этих файлов и в основном написана авторами программ, аналогичных PWLInside.

Подробно рассмотрим в качестве примера следующий PWL-файл:

1. Сразу оговорю следующие ограничения PWL-файлов: в файле может находится максимум 16 блоков ресурсов. Максимальное количество ресурсов в файле - 255. Это ограничения самой Windows. В каждом блоке может располагаться любое количество ресурсов, но их суммарное количество не может быть больше 255. И еще одно ограничение PWL-файла - то, что он не может быть больше 64кБ.
2. Итак, первое, что мы видим - это сигнатура (т.е. первые 4 байта файла), которая равна 0x968582E3, сразу же замечу, что у PWL-файлов от Windows'3.11/95 сигнатура другая - 0x4E464DB0.
3. По смещению 0x4 следует DWORD с неизвестным содержимым.
4. По смещению 0x8 следует WORD. Он определяет общее кол-во ресурсов в файле. В нашем примере - 2 ресурса.
5. Начиная с адреса 0x00A до адреса 0x109 располагается странная таблица размером 255 байт. Какую она содержит информацию, известно лишь Microsoft. Есть предположение, что там хранятся номера ресурсов, хотя эта таблица для декодирования данных из файла в принципе не нужна.
6. Начиная с адреса 0x109 до адреса 0x208 находится другая таблица (тоже размером 255 байт), в которой хранится такая информация: любой байт из этой таблицы равный i (кроме 0xFF) означает, что i-й блок содержит ресурсы. Количество одинаковых байт равных i в данной таблице отражает количество ресурсов в i-м блоке. В нашем примере - 1-й байт в таблице показывает, что у нас имеются ресурсы в 13-м (0x0D) блоке, а 2-й байт в таблице показывает, что у нас имеются ресурсы в 3-м блоке ресурсов.
7. По адресу 0x208 находится DWORD (у нас он равен 0x00000252), который определяет смещение CryptoSign. Кстати, я в этом поле других значений не видел ни в одной PWL-ке!
8. С адреса 0x20C по 0x24C располагается массив CryptoSeed[16], он необходим для декодирования всех 16 блоков ресурсов.
9. По адресу 0x24C располагается CheckSeed (DWORD), с которого и начинается декодирование PWL-файла.
10. Далее идут два нулевых байта. Какую они несут функцию - неизвестно.
11. По адресу 0x252 располагается массив CryptoSign (16 байт).
12. По адресу 0x262 располагается массив CheckSign (16 байт) - этот массив вместе с CryptoSign является "контрольным значением" для определения правильности пароля. Их применение рассмотрим ниже.
13. По адресу 0x272 располагается массив из 15 WORD'ов - это адреса 15 блоков ресурсов, начиная со второго. Адрес же первого ресурса всегда один и тот же и составляет 0x290. Эти адреса уже являются зашифрованными. Посмотрим, что это будут за байты после декодирования правильным паролем:
    0270: .. .. 92 02 94 02 96 02 B2 02 B4 02 B6 02 B8 02
    0280: BA 02 BC 02 BE 02 C0 02 C2 02 C4 02 D8 02 DA 02
    
    Как мы видим - действительно там находятся адреса! Эти адреса никогда не могут быть одинаковыми и получается, что если блок ресурсов пустой, то он все равно занимает 2 байта  - это мы видим на начальных адресах: 0x292, 0x294 - эти значения ссылаются на "мусор", ресурсы же в этом файле находятся по адресам 0x296 ... 0x2B2 и 0x2C4 ... 0x2D8 - это видно по тому, что разница между этими соседними адресами больше двух байт и т.к. мы уже отмечали, у нас 3-й и 13-й блок имеют ресурсы (см. пункт 6).
14. А с адреса 0x290 начинаются непосредственно ресурсы. Эти данные также зашифрованы. После дешифрования мы увидим, что с адресов 0x296 и 0x2C4 действительно есть что-то, похожее на ресурсы :)
    0290: 4C 9C 50 94 C9 82 1A 00 0A 00 08 00 01 03 43 52 |L.P...........CR
    02A0: 49 53 54 49 41 4E 5C 44 68 65 6C 6C 67 61 74 65 |ISTIAN\Dhellgate
    02B0: E3 A8 CF DD 80 8A 8D 9A 1B 97 6B B9 BD F0 AE 9A |....?.....k.....
    02C0: 5C D4 20 88 12 00 05 00 05 00 00 04 4D 41 50 49 |\. .........MAPI
    02D0: 00 4D 41 50 49 00 28 F3 1D B2 90 80             |.MAPI.(....?

Описание алгоритмов, используемых для шифрования PWL-файлов

Ниже подробно опишем те алгоритмы, которые используются при шифровании данных в PWL-файлах. Т.к. подробные описания RC4 и MD5 можно найти в различных источниках, то я опишу их поверхностно, т.к. предполагаю, что читатель либо знает принципы работы этих алгоритмов, либо сам сможет найти в Интернете подробные их описания, хотя бы в тех же RFC.

RC4

Краткое описание: на входе имеем ключ размером 16 байт, на выходе получаем массив из 256 байт, в котором равномерно и псевдослучайно распределены байты от 0 до 255, причем их распределение зависит от входного ключа:

MD5

MD5 - это не что иное, как операция свертки 64 байт в 16.
Посмотрим как эта функция описана в официальном документе - RFC1321 с небольшими упрощениями и нашими комментариями:

В итоге получаем из входного массива x (16 DWORD'ов) массив state (всего 4 DWORD'a).

Завершающая процедура XorT алгоритма RC4

Эта часть RC4 (не описанная выше), которая декодирует необходимые данные с помощью массива M:

Стандартный алгоритм восстановления паролей к PWL-файлам

1. Считываем из исходного PWL-файла по смещению 0x24C - CheckSeed (DWORD).
2. -//- по смещению 0x252 - CryptoSign (16 байт).
3. -//- по смещению 0x262 - CheckSign (16 байт).
4. Формируем массив X (размером 64 байта) следующим образом:
• 0xFFFFFFFF (DWORD)
• Логин в верхнем регистре
• 0x0 (1 байт)
• CheckSeed (DWORD)
• 0x80 (1 байт)
• 0x0 (по адрес 0x37 включительно)
• По адресу 0x38 записываем (0x48 + (длина логина << 3)) (DWORD)
• 0x0 (до конца массива)
5. Выполняем MD5 (массив X), получаем массив Cnt (16 байт), т.е. производим свертку логина.
6. Формируем массив Y (размером 64 байта) следующим образом:
• Логин в верхнем регистре
• 0x0 (0x11 байт)
• 0x80 (1 байт)
• 0x0 (по адрес 0x37 включительно)
• По адресу 0x38 записываем (0x88 + (длина логина << 3)) (DWORD)
• 0x0 (до конца массива)
7. Формируем массив Z (размером 64 байта) следующим образом:
• Пароль
• 0x0 (1 байт)
• Cnt (16 байт)
• 0x80 (1 байт)
• 0x0 (по адрес 0x37 включительно)
• По адресу 0x38 записываем (0x88 + (длина пароля << 3)) (DWORD)
• 0x0 (до конца массива)
8. Выполняем MD5 (массив Z), получаем массив Key (16 байт), т.е. производим свертку пароля.
9. Выполняем RC4, используя в качестве ключа Key.
10. Копируем во временный буфер Temp (32 байта):
• CryptoSign (16 байт)
• CheckSign (16 байт)
11. Выполняем процедуру XorT (массив M, массив Temp), получаем модифицированный массив Temp.
12. Копируем первые 16 байт из массива Temp в буфер Y с адреса (длина логина + 1)
13. Выполняем MD5 (массив Y), получаем массив TempKey (16 байт).
14. Сравниваем 16 байт массива TempKey и вторые 16 байт из массива Temp и если они не равны, то инкремент пароля и возврат на пункт 7, иначе - пароль верный!

Алгоритм декодирования ресурсов из PWL-файла с правильным паролем

1. После нахождения правильного пароля прогоняем функцию XorT с индексами не 1...33, а 33...63. Таким образом мы декодируем 15 адресов блоков с ресурсами. Должны получиться значения типа 0x292, 0x294 и т.д. Как мы помним, адрес 1-го блока всегда равен 0x290. Таким образом, у нас будет массив Res[17] типа WORD, в первое значение - 0x290, далее 15 декодированных адресов, а последний WORD - это размер файла (в примере выше это будет значение 0x2DC).
2. Далее следует цикл на 16 (проверка блоков с ресурсами), в начале его вычисляем разницу между соседними адресами N - если разница между ними равна 2, то переход на следующий адрес.
3. Если N > 2, то данный i-й блок содержит ресурсы.
4. Формируем новый массив X (размером 64 байта) следующим образом:
• 0xFFFFFFFF (DWORD)
• Логин в верхнем регистре
• 0x0 (1 байт)
• CryptoSeed[i] (DWORD) - это значение берем из массива по адресу 0x20C, причем i - это номер блока ресурсов.
• 0x80 (1 байт)
• 0x0 (по адрес 0x37 включительно)
• По адресу 0x38 записываем (0x48 + (длина логина << 3)) (DWORD)
• 0x0 (до конца массива)
5. Выполняем MD5 (массив X), получаем массив Cnt (16 байт), т.е. производим свертку логина с нужным CryptoSeed.
6. Формируем массив Z (размером 64 байта) следующим образом:
• Пароль
• 0x0 (1 байт)
• Cnt (16 байт)
• 0x80 (1 байт)
• 0x0 (по адрес 0x37 включительно)
• По адресу 0x38 записываем (0x88 + (длина пароля << 3)) (DWORD)
• 0x0 (до конца массива)
7. Выполняем MD5 (массив Z), получаем массив Key (16 байт), т.е. производим свертку пароля.
8. Выполняем RC4, используя в качестве ключа Key.
9. И теперь полученным массивом M начинаем декодировать весь блок с ресурсами длиной N процедурой, аналогичной XorT. Причем начинаем использовать массив M также с 1-го значения (не с нулевого(!)) до 255, если ресурс больше 255 символов, то i "переваливает" байтовую границу и уже массив M начинает использоваться с нуля, а не с единицы.
10. Посмотрим на приведенном выше примере структуру первого из наших декодированных ресурсов:
    0290: .. .. .. .. .. .. 1A 00 0A 00 08 00 01 03 43 52 |..............CR
    02A0: 49 53 54 49 41 4E 5C 44 68 65 6C 6C 67 61 74 65 |ISTIAN\Dhellgate
    
    Ее формат такой:
    • длина ресурса (WORD), в нашем примере - 26(0x1A) байт.
    • длина логина (WORD), в нашем примере - 10 символов.
    • длина пароля (WORD), в нашем примере - 8 символов.
    • BYTE, назначение которого пока точно не известно.
    • тип хранимого ресурса (BYTE):
    • 1 = NT Domain
    • 2 = NT Server
    • 3 = Shared
    • 4 = MAPI
    • 6 = Dial-Up
    • 18 = NetWare
    • 19 = WWW
    Далее располагаются логин, а после него - пароль.
    В нашем примере - тип ресурса "Shared", логин "CRISTIAN\D", пароль "hellgate".
    (Примечание: для Shared-ресурсов запись CRISTIAN\D будет означать следующее: CRISTIAN - имя компьютера, а D - ресурс, предоставленный для общего пользования.)
    
11. Далее анализируем текущий блок с ресурсами, пока не перевалили за N, "поглядывая" в таблицу по адресу 0x109, т.к. в PWL-файлах между блоками ресурсов очень часто бывает "мусор" (неисповедимы пути Microsoft), а в этой таблице будет точное указание - в каком блоке сколько ресурсов.

Оптимизация алгоритмов восстановления паролей

Вот и начинается самое интересное. ;)
Посмотрим, что же мы можем сделать для повышения быстродействия вышеприведенных алгоритмов.

RC4 (1-я часть)

1. Сразу же бросается в глаза инициализация массива значениями от 0 до 255, которое происходит при каждом новом значении ключа (т.е. фактически при каждом новом пароле). Как же можно сделать ее более эффективной?

Выход есть - инициализировать массив не побайтно (256 команд), а, например, используя 32-битные регистры процессора, по 4 байта за 64 команды - и действительно, выигрыш по времени будет в 4 раза (конечно же, если массив M выровнен минимум по границе DWORD'a). А есть ли еще более "широкие" регистры, чтобы за одну команду "махом" записывать бОльшее кол-во байт? Регистры FPU отпадают, т.к. операции с ними выполняются очень долго, остаются, конечно же, MMX-регистры:

У читателя, наверное, возник вопрос - почему мы инициализируем EDI не на начало массива M, а на его середину?
Просто дело в том, что при таком варианте программы дополнительное смещение к EDI будет приводить к увеличению длины команды MOVQ всего на один байт (знаковый диапазон -128...+127) и команда получает длину в 4 байта. А если, к примеру, прибавить к EDI +256, то смещение будет расширено до DWORD'a и длина команды увеличится до 7 байт. Использование же более коротких команд является предпочтительным, т.к. идет более "плотное" заполнение буфера предвыборки команд и более оптимальное их декодирование процессорами.

И еще - вдумчивый читатель скажет, что есть ведь еще более "широкие" XMM-регистры - те, которые используются в наборах команд SSE (которые, кстати, поддерживают и Athlon'ы) и SSE2 от Intel. Используя их, можно оперировать с памятью блоками по 16 байт за такт!

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

RC4 (2-я часть)

Теперь рассмотрим "перетасовку" байт в массиве M, используя входной ключ.
Здесь получается такая картина - на обработку одного байта массива M необходимо минимум 7 команд, покажем это на примере одной итерации:

1. Использование команды MOVZX ESI,AL устраняет следующий конфликт на процессорах Intel: обращение к 32-битному регистру сразу после модификации его младшей (16- или 8-битной) части. В этом случае ко времени выполнения команды добавляется несколько тактов штрафа. Кстати, на процессорах от AMD таких штрафов нет. :)
2. Конфликты по чтению/записи в одну кэш-линейку процессора.
   Известно, что при обращении к ячейке памяти процессор считывает из памяти (или кэша 2-го уровня) не одну эту ячейку, а целую строку (например, 32 байта), которую и размещает в кэше 1-го уровня. При этом ВСЯ эта строка помечается как доступная либо только для чтения, либо для записи. Поэтому, если прочитать байт по адресу X, а потом записать байт по адресу (X + 1), то несмотря на то, что байт по адресу (X + 1) уже в кэше(!), процессор после выполнения первой команды должен сначала "освободить" всю строку, а лишь потом снова ее загрузить, но уже для записи в нее, что, естественно, приводит к штрафам. Но, т.к. алгоритм формирует равномерное распределение байт, то такие конфликты возникают нечасто.
3. Возможно, есть еще ряд конфликтов именно по работе с памятью, т.к. такие алгоритмы - это для процессоров не самый "удобный" код :)

Итого на весь алгоритм RC4 уходит: 5 x 256 = примерно 1280-1300 тактов.
Конечно же, подразумевается, что никаких циклов нет и код весь "развернут".

Вроде бы ничего с эти поделать уже нельзя, но пытливый ум подсказывает, что и здесь можно "рыбку половить". ;)

И действительно - рассмотрим ту часть кода, где вычисляемый индекс A суммируется с байтом из массива Key.

Индекс - это же один байт(!), который суммируется с текущим байтом M[i].
А затем суммируется с байтом из массива Key.

А если сразу суммировать два байта (одной командой) для 2-х разных ключей и, соответственно, 2-х разных паролей не в 8-битном регистре, а в 16-битном? Сказано - сделано.

В результате скорость упала.
Да-а-а, значит прирост от этого не перекрыл увеличение "накладных расходов" из-за того, что теперь в программе формируется два массива Z, два массива M и пр. Плюс штрафы от использования 16-битных команд в 32-битном коде.

Ну что ж, а если одновременно 4 байта для 4-х паролей? ;)
Та-а-ак, здесь уже относительно начального (однопарольного) варианта есть прирост производительности на 3-5%.

А если еще "шире"? :)
"Конечно же, MMX!" - скажете Вы и будете правы! :))

И вот мы приходим к тому варианту, который и был реализован в PWLInside и дал прирост скорости относительно начального варианта на 20-25%. Все просто:

1. Формируем 8 массивов M, которые располагаются в памяти таким образом:
   - 0-й байт 1-го массива
   - 0-й байт 2-го массива
   ...
   - 0-й байт 8-го массива
   - 1-й байт 1-го массива
   - 1-й байт 2-го массива
   ...
   - 1-й байт 8-го массива
   и так далее.
   
2. Формируем 8 паролей, идущих "подряд" при переборе выбранным алфавитом.
   
3. На основе этих восьми паролей через вызов MD5 формируем 8 массивов Key в таком же порядке:
   - 0-й байт массива Key от 1-го пароля
   - 0-й байт массива Key от 2-го пароля
   ...
   - 0-й байт массива Key от 8-го пароля
   - 1-й байт массива Key от 1-го пароля
   - 1-й байт массива Key от 2-го пароля
   ...
   - 1-й байт массива Key от 8-го пароля
   и так далее.
   
4. И вот что получаем - теперь все 8 индексов для разных паролей хранятся в одном(!) MMX-регистре, в разных его 8-битных частях.
   Помните строчку:
   A += (M[i] + Key[i % 16]);
   
   Теперь этот фрагмент кода для 8-ми паролей (и ключей, соответственно) выполняется двумя MMX-командами:
   mov edi,offset M
   mov ebp,offset Key
   ...
   pxor mm0,mm0 ;Начальные значения обнуляем
   ...
   ;Вот этот фрагмент:
   paddb mm0,qword ptr [edi] ;Все восемь A += M[i] 
   paddb mm0,qword ptr [ebp] ;Все восемь A += Key[i % 16]
   
   Вот в чем неоспоримое достоинство MMX-регистров - возможность оперировать с 8-, 16- или 32-битными частями всего регистра независимо друг от друга!
   
5. После этого выделяем байты из MM0 любым способом, формируем адреса, меняем байты в массивах M и далее все то же самое, что выше.
6. И, конечно же, инициализация массивов M будет такая же, что приведена выше - по 40 тактов на один пароль. Но 8 раз.

А если использовать XMM-регистры, то можно анализировать 16 паролей одновременно и это даст еще прирост скорости, но только на тех процессорах, которые поддерживают набор команд SSE. Попробуйте, может следующий "прорыв" в области восстановления паролей к PWL-файлам сделаете именно Вы! ;)

MD5

Первый момент в оптимизации этого алгоритма - это замена следующих макросов с 4-мя логическими операциями:

Второй же момент заключается в следующем: присмотримся внимательно к пункту 7 стандартного алгоритма и увидим, что если мы ограничим пароль для перебора 16-тью символами (т.к. на бОльшую глубину перебор уже бесполезен), то при формировании буфера Z у нас остаются несколько DWORD'ов, которые заполнены нулями. Посмотрим, какие именно:

16 символов пароля + 1 байт нуля + Cnt (16 байт) + 1 байт (0x80) = итого 34 байта или 9 DWORD'ов.

Далее у нас идут нули, до конца же массива занят еще только один DWORD - x[14].

И фактически пустые DWORD'ы - это x[9], x[10], x[11], x[12], x[13] и x[15].

Поэтому, во всех 64 итерациях (4 блока по 16 строк) алгоритма MD5, везде, где к результату прибавляется какой-то из этих DWORD'ов, то его можно не прибавлять вообще - там же нуль!

Этот нехитрый маневр увеличивает скорость данной конкретной реализации MD5 еще на 8-10%.

Кстати, эту идею можно развить и дальше:

• При длине пароля 8..12 символа игнорировать x[8].
• При длине пароля 4..8 символа игнорировать x[7] и x[8].
• При длине пароля 1..4 символа игнорировать x[6], x[7] и x[8].

Итого - после всех этих манипуляций время выполнения алгоритма MD5 стало занимать ~280-320 тактов, т.е. в среднем около 5 тактов на каждую из 64 итераций. Неплохо. :)

Но, уже создавая эту статью, у меня появились определенные мысли, как можно еще оптимизировать этот код. ;) Вполне возможно, что в следующей версии PWLInside будет еще что-то новенькое в плане оптимизации MD5!

Я также надеюсь, что вышеприведенная информация по оптимизации RC4 и MD5, возможно, поможет кому-нибудь, кто использует эти алгоритмы в своих разработках и позволит с минимальными "затратами" сделать эти программы еще более быстрыми :)

Стандартный алгоритм восстановления паролей к PWL-файлам

Внимание! А на "десерт" - самое вкусненькое ;) - то, что позволило в свое время программе PWLInside существенно увеличить скорость перебора и по этому параметру здорово "оторваться" от своих конкурентов.

Оказывается, для быстрой оценки - тот пароль или нет, можно пункты 10...14 не выполнять, а значит и не вызывать второй раз MD5, который (как уже было сказано) выполняется около 300 тактов, что дает прирост скорости еще на 20-25%!

Дело вот в чем.

Если внимательно присмотреться к процедуре декодирования ресурсов, то мы увидим, что с помощью массива M после пункта 9 стандартного алгоритма при проходе с правильным паролем мы декодируем:

• начальный буфер Temp - это не что иное, как 32 байта исходного PWL-файла с адреса 0x252,
• смещения (адреса) блоков ресурсов с адреса 0x272,
• и, наконец, сами ресурсы.

Если он лежит в диапазоне 0x292...(длина PWL-файла), то есть вероятность, что этот пароль верный! Для окончательной же проверки правильности пароля нужно выполнить пункты 10...14, т.к. только в этом случае (когда совпадут все 16 байт массива Temp), можно быть уверенным, что это именно верный пароль.

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

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

Поэтому код предварительной оценки пароля в упрощенном виде будет выглядеть так:

Таким образом, зачем нам делать пункты 10...14 и проверять 16 байт, когда можно выполнить "упрощенный" вариант процедуры XorT и проверить всего 2 байта! ;)

При всем моем уважении к Microsoft, однако, это еще одна их "дыра" в реализации качественных методов хранения паролей пользователей!

Итак, что мы получили в среднем:

• ~40 тактов на инициализацию массива M.
• ~300 тактов на первый проход MD5.
• ~1000 тактов на проход RC4.
• ~150 тактов на все остальное (формирование массива Z, инкремент пароля, "упрощенная" функция XorT, проверки и пр.)

Дело в том, что микроархитектура P4 по сравнению с P-II/III была существенно переработана - увеличено время выполнения команды (до 20 стадий), изменились размеры строк кэша данных и кода и еще ряд "усовершенствований", поэтому этот код (в особенности, реализация алгоритма RC4) для P4 не является оптимальным и в следующей версии PWLInside будет модифицирован. При этом на процессорах AMD, даже последних, таких проблем не возникает - на Athlon'e XP 1700+ (1466МГц) с ядром ThoroughBred программа исправно выдает около миллиона паролей в секунду. Вот так AMD делает аналоги процессоров Intel в чем-то лучше, чем сама Intel. :)

Заключение

Вот и подошло к концу наше описание. Надеюсь, теперь по работе с PWL-файлами от Windows'OSR2/98/ME ни у кого не осталось "темных пятен". Видно, что данные алгоритмы можно было бы прооптимизировать еще больше с применением команд современных процессоров, но - операционные системы этих поколений уже уходят "в прошлое" - процент этих ОС и так уже невысокий, со временем снижается все больше и больше, и восстановление паролей к PWL-файлам уже не столь актуально, как несколько лет назад.

Хотя, возможно, стоит еще поработать в этой области. ;)

Сейчас основной процент ОС семейства Windows - это Windows'2000, Windows'XP, а теперь уже и Windows'2003. Так как у всех этих систем ядро другое (на базе NT), то и методы хранения, шифрования, а также восстановления ;) паролей пользователей тоже другие.

В них информация о паролях пользователей хранится в SAM-файлах, которые представляют собой ветку "HKEY_LOCAL_MACHINE\SAM" реестра Windows, и пароли зашифрованы другими алгоритмами, нежели в PWL-файлах.

Но(!) - несмотря на все попытки Microsoft создать максимально надежный механизм авторизации, все их методы почему-то имеют явные огрехи - это наглядно демонстрируют как методики, описанные выше, так и методы хранения и шифрования паролей в SAM-файлах.

В операционных системах Windows'NT, начиная с 6-го сервис-пака, Windows'2000, Windows'XP (а по всей видимости и в Windows'2003) применяется дополнительное шифрование хешэй пользователей (которые и так получены путем шифрования паролей определенными алгоритмами) с использованием утилиты Syskey.

Данный механизм успешно просуществовал несколько лет. Его многократно пытались взломать, но все попытки были безуспешны, пока этой проблемой не заинтересовались мы с Ocean'ом. ;)

И механизм был "взломан"! Это наглядно демонстрирует программа SAMInside.

Но про SAM-файлы и методы восстановления к ним паролей расскажу как-нибудь в другой раз. :)

Особую благодарность выражаю Ocean'у, т.к. только наша с ним совместная деятельность в этой области привела к появлению на свет таких программ как PWLInside, SAMInside и ряда других.

Удачи всем!