Push 0
Push Offset AcceptCache
Push 0FFh
Push 0
Push 0
Call WNetEnumCachedPasswords

Где процедура AcceptCache является точкой обратного вызова и принимает два параметра, первый из которых - адрес элемента парольного кэша, про структуру кэша мы поговорим дальше. В вашей программе можно писать так:
Mov EAx,[ESp+4]
...............
Ret 8h
На самом деле ничего писать не надо, все уже и так реализовано в моей программе PWLHACK v4.02, которую можно взять по адресу указанному в конце этой статьи. Как вы уже успели понять, на залогиненной машине возможно элементарно получить весь список парольных ресурсов со всей сопутствующей критической (с точки зрения безопасности) информацией. Виват, Micro$oft! Кстати, во всей литературе, которую я читал про защиту информации, слова MS-DOS и Windows не упоминаются вообще (разве что во введении, причем единожды ;-). В принципе, описанный выше механизм работы с парольным кэшем суть существенный просчет (даже на фоне прочей дырявости) в системе безопасности Windows. Раз уж я заговорил о дырках... скажу еще пару слов (все это делает PWLHACK v4.02), ресурсы предоставляемые машиной в сеть для публичного использования хранятся в регистри (причем вместе с паролями). Вот как это происходит: Software\Microsoft\Windows\CurrentVersion\Network\LanMan. Начиная отсюда под ключами располагаются сетевые каталоги плюс вспомогательная информация (флаги, пароли и проч.) Хотите знать механизм шифрования паролей? Вот он: Seed=6Ah; ForEach Password (Ror Seed,1; Character Xor Seed) Все желающие могут чуть-ли не батником добавлять шаровые ресурсы в машину (при условии физического доступа к ней). Управлением локальными ресурсами машины, предоставляемыми в сеть, занимается VSERVER.vxd, а обменом информацией с удаленными серверами VREDIR.vxd Безусловно, в связке работают так же MSNET32.dll, MSNP32.dll и проч. Физически парольный кэш располагается в каталоге %WINDIR% и имеет расширение .PWL, причем список файлов, составляющих парольный кэш, находится в SYSTEM.ini в разделе [Passwords Lists]. Интересен такой момент, имя файла есть имя пользователя обрезанное до 8 букв (8.3 стандарт на имена файлов). Если имена 2-х пользователей совпадают в первых 8-ми буквах, и различны, то работать сможет только второй из них, первый потеряет все настройки, т.к. парольный файл второго затрет аналогичный файл существовавший до него. Никаких проверок не производится, уф! Физически всю работу производит модуль MSPWL32.dll Кстати, еще один факт слабой проработки кодирования защитных модулей, заменой 3-х байтов полностью отключается весь механизм шифрования файлов, составляющих парольный кэш, затем due to технические причины автоматически является легальным любой вводимый пароль, вот иллюстрация:
-[MSPWL32.crk]-------------------------------------------------------- Windows 95-98 passwords. (C) by *HW* [W95 & OSR/2] All passwords are legal and *.PWL's are not encrypted.
MSPWL32.DLL
00000511: 30 90 <ик>
00000512: 0C 90
00000513: 28 90
[W98 4.10.1691] All passwords are legal and *.PWL's are not encrypted.
MSPWL32.DLL
00001241: 30 90
00001242: 0C 90
00001243: 28 90
-[MSPWL32.crk]--------------------------------------------------------
Заменяемые байты есть команда наложения гаммы на файл (XOR кого-то с кем-то), об этом мы поговорим подробнее чуть ниже. При обработке файлов используются алгоритмы RC4 (RFC-.... ну нет у меня интернета) и MD5 (RFC-1321). На настоящий момент уже появился алгоритм RC5 (можно ожидать его применения в дальнейшем). Алгоритм RC4 является алгоритмом потокового шифрования и считается вполне устойчивым, MD5 - алгоритм создания дайджестов (сверток) сообщений, достаточно быстр в реализации, разработчик R.Rivest. Про MD5 мы поговорим особо в дальнейшем. Итак, подошло время технической информации.
2. Обзор реализации парольных кэшей Windows v4.0.1111 (a.k.a. 95 OSR2)
Начнем как обычно, с Си-подобного заголовка .PWL файлов этой версии Windows, продолжим пояснениями.
#define OSR_PwlSign 0x968582E3 // Somebody calls it "“‚…–"
#define OSR_PwlBase 0x290
#define OSR_PwlHdrOfs 0x252
typedef struct { /* OSR PWL checking sign */
byte CryptoSign[0x10]; /* Crypto sign */
byte CheckoSign[0x10]; /* Checko sign */
word ResOffsets[0xF]; /* Resources offsets. */
} check_pack;
typedef struct { /* version depended OSR PWL partition */
dword HdrOfs; /* Offset to CryptoHdr */
dword CryptoSeed[0x11]; /* Resource CryptoSeed */
word UnkAlign; /* ?? Just alignment */
check_pack Check; /* Checking crypt-sign */
} OSR_pwl_data;
typedef struct { /* PWL file header itself */
dword Sign; /* .PWL file signature */
dword UnknownC; /* ?? Strange counter */
byte ResLink[0x100]; /* Resource link index */
byte ResKey[0x100]; /* Resource key entry */
union {
W95_pwl_data W95_Data; /* W95 format PWL data */
OSR_pwl_data OSR_Data; /* OSR format PWL data */
} HdrV;
} pwl_hdr;
Общая структура файла осталась без изменений, те же ресурсные входы, механизм доступа по каналам (точкам входа) и проч. Но что-то ведь изменилось? Как минимум, изменилась сигнатура файла, теперь это OSR_PwlSign, соответственно изменилось и положение ресурсной информации, она теперь обычно располагается по смещению OSR_PwlBase Появилось дополнительное поле HdrOfs имеющее как правило значение OSR_PwlHdrOfs, по данному смещению располагаются описатели ресурсных точек входа (смещения внутри файла, соответственно размер ресурсного канала есть ResOffsets[i+1]-ResOffsets[i]), ну, если более точно, то структура check_pack. Поскольку работа с ресурсами была описана выше, то перейдем к новому моменту: открытию парольного кеша. И вот теперь начинаются проблемы. Первоначально пароль вместе с константой 0xFFFFFFFF, а так же CryptoSeed[0x10], именем пользователя и паролем сворачивается в MD5 хеш, длинной 4 DWord'a (за 2 прохода, вначале имя, затем пароль). После этого расшифровывается участок файла check_pack (алгоритмом RC4), затем выполняется еще одна MD5 свертка, в ней участвуют имя пользователя и поле CryptoSign[] в результате должна получиться сигнатура CheckoSign[], тогда и только тогда пароль расценивается допустимым. Как видим, исправлены все недостатки предыдущего формата ресурсного файла. В частности, реализация переборщика показала, что скорость снизилась в 2 раза, по сравнению с вариантом из Windows v4.0 (38 тыс. pps против 55 тыс. pps) Исправлены также недостатки малой длинны свертки пароля и тривиальная зависимость свертки от пароля. Хочется отметить такой факт, что поля ввода в диалогах позволяют ввести пароль максимально до 14 символов и преобразуют его к верхнему регистру (справедливо для версий Windows v4.0-4.0.1111). Это существенно сокращает пространство для перебора. А как с одиноковой гаммой для каждого ресурсного канала? Теперь, при создании ключа для шифрования, используют поля CryptoSeed[i], причем пропускание этой информации сквозь MD5 не позволяет говорить о прямой реконструкции гаммы даже при знании некоторых ресурсов.

3. Дополнения и изменения в операционной системе Windows v4.1 (a.k.a. 98)
Их очень немного, прежде всего, сняли ограничения с полей ввода в диалоговых окнах (теперь можно ввести свыше сотни символов в имя пользователя и в пароль). Так же, при логине имя пользователя выбирается из списка, что позволяет достаточно просто использовать длинные имена пользователей (что очень замедляет перебор). Жаль, но пароль из списка выбирать нельзя ;-) Вот и все, форматы файлов изменений не претерпели. Была дополнительно переписана MSPWL32.dll, конечно же она стала в 2 раза больше объемом (такое ощущение, что мировые производители винчестеров - одно из подразделений фирмы Micro$oft). Больше назвать нечего.
1. Обзор реализации парольных кэшей Windows v4.0 (a.k.a. 95)
Для начала я приведу Си-подобную структуру расписывающую отдельные поля этого файла, затем будут комментарии.
#define W95_PwlSign 0x4E464DB0 // Some guys call it "MFN"
#define W95_PwlBase 0x23C

typedef struct { /* version depended W95 PWL partition */
byte UserName[20]; /* Padded owner name */
word ResOffsets[0xF]; /* Resources offsets. */
} W95_pwl_data;

typedef struct { /* PWL file header itself */
dword Sign; /* .PWL file signature */
dword UnknownC; /* ?? Strange counter */
byte ResLink[0x100]; /* Resource link index */
byte ResKey[0x100]; /* Resource key entry */
union {
W95_pwl_data W95_Data; /* W95 format PWL data */
OSR_pwl_data OSR_Data; /* OSR format PWL data */
} HdrV;
} pwl_hdr;
Итак, файл содержит в самом начале сигнатуру W95_PwlSign, заголовок имеет размер W95_PwlBase, собственно, с этого смещения располагаются (обычно) зашифрованные ресурсы. Поле UnknownC увеличивается с течением времени при модификации файла и является скорее всего версией парольного кэша (вернее не столько версией, сколько возрастом). Теперь ключевой момент, доступ к ресурсам. Он осуществляется по 16-ти точкам входа (соответствующая индексация осуществляется по телу ресурса), это позволяет значительно ускорить доступ к ресурсной информации и не расшифровывать лишний раз "критические" данные (впрочем, их все равно потом в памяти _не_ затирают). Лирическое отступление: я часто замечал вольную работу со стеком и регистрами библиотечных функций Windows (здесь и далее версия не ниже 4.0). Имеется ненулевая вероятность получения интересной информации после отработки многих системных вызовов. (Скажем, многие функции осуществляют поиск файла по системному маршруту: текущий каталог, затем %WINDIR%, затем PATH и т.п. Достаточно часто после выхода из такой функции в EDx содержится указатель на полный путь найденного файла, это лишь пример... Только пример для думающего человека...) Собственно, файл кэша может содержать максимально 255 ресурсов. Поля массива ResLink[] содержат номера ресурсов (в случае, если необходим итеративный, а не ассоциативный доступ), эти поля индексируют поля ResKey[], содержащие номера точек входа (другими словами - номера каналов ресурсов) в ресурсном файле. Почему именно такая двухуровневая система? Возможно по соображениям простоты вставки-удаления элементов (ну лень им было возиться со списками и проч., файлы, кстати, вычитываются по кусочкам, т.е. по 2-4-...-256 байта, как раз полями).
Открытие парольного кэша осуществляется следующим образом: сворачивается пароль в 4-х байтовый хеш, затем по хешу строится таблица RC4 и осуществляется расшифровка полей UserName и ResOffsets, поле UserName должно содержать имя пользователя. Ресурсы в каждом канале зашифрованы независимо друг от друга, но одним и тем же ключевым значением. Вспомним о том, что RC4 потоковый алгоритм. Практически всегда зная имя пользователя (которое выровнено 0-ми на 20-ти байтовую границу) мы получаем начало гаммы, затем предполагая определенные значения смещений ресурсов (на основе полей ResKey и ResLink, а так же знания константы W95_PwlBase) мы можем получить еще несколько (до 15*2) байтов гаммы, итого max 50 байтов гаммы, это позволит нам расшифровать max по 50 байтов каждого ресурсного входа, абсолютно без всякого предположения о пароле пользователя. Данную задачу решала программа Glide в свое время. Этот нюанс в применении стойких криптоалгоритмов даже явился источником нескольких журнальных статей в околокомпьютерной журналистике. В настоящее время это уже история, так как только у нас еще используют чистую Windows v4.0 без обновлений. Второй путь: ключ для RC4 шифрования короток, 2^32, полный перебор может быть осуществлен за сутки (даже менее). А это значит, что парольные кэши Windows v4.0 гарантированно _не_ защищают хранящуюся в них информацию. Рассмотрим поближе формат канала ресурсов, именно в таком формате ресурсы получает точка обратного вызова для WNetEnumCachedPasswords (по одному ресурсу на вызов).
Offset Size Meaning
0 Word Total resource size
2 Word Resource descriptor size (name of a link, network drive,
game server e.t.c.)
4 Word Security information size (password for link, for network
printer e.t.c. )
6 Byte Resource number (absolute)
7 Byte Resource type descriptor (6-DialUp, 3-NetLink, e.t.c.)
Стоит добавить, что ресурсы далеко не всегда текстовые строки. MAPI хранит в парольных кэшах свои бинарные данные, а Novell Network Provider хранит имя пользователя и логин на сервер как 2 строки закрытые 0 в "секретном" поле ресурса. Все желающие поисследовать файлы .PWL могут воспользоваться ключем /LIST:E программы PWLHACK v4.02 Еще один момент: это процедура свертки пароля в Windows v4.0 Очевидно, что такая свертка достаточно просто обратима (возможна генерация некоторого множества паролей для отдельно взятого хеша).
; EDx - hash, EBx - Pointer to password.
W95_Hash_Pwd Proc
Xor EDx,EDx
W95_Hash_Next: MovZx EAx,Byte Ptr [EBx]
Add EDx,EAx
Rol EDx,7
Inc EBx
Or Al,Al
Jnz Short W95_Hash_Next
Ret
W95_Hash_Pwd EndP
Наверное, мне больше нечего добавить в этом разделе, думаю, что пора переходить к следующему. Micro$oft иногда прислушивается к мнению "прогрессивной общественности", особенно в вышеописанном случае, иначе она не была бы Micro$oft.