Упътване за декриптиране на база данни на KeePass
Онзи ден трябваше да внедря декриптиране на база данни KeePass. Бях поразен от факта, че няма нито един документ и нито една статия с изчерпателна информация за алгоритъма за декриптиране на .kdb и .kdbx файлове, като се вземат предвид всички нюанси. Това ме подтикна да напиша тази статия.
В момента има 2 версии на KeePass:
- KeePass 1.x (генерира .kdb файлове);
- KeePass 2.x (генерира .kdbx файлове).
Структурата на файла с базата данни KeePass (.kdb, .kdbx) се състои от 3 части:
- Подпис (не е криптиран);
- Заглавие (не е криптирано);
- Данни (криптирани).
След това ще опиша подробно как да дешифрирам база данни KeePass 1.x и KeePass 2.x.
Декриптиране на база данни KeePass
Точки 5, 6 и 7 се отнасят само за .kdbx файлове!
ПодписБазов подпис (4 байта)
Първият подпис е един и същ за .kbd и .kdbx файлове. Пише, че този файл е базата данни на KeePass:
Вторият подпис показва версията на KeePass и следователно е различен за .kbd и .kdbx файлове:
- 0xB54BFB65 - KeePass 1.x (.kbd файл).
- 0xB54BFB66 - KeePass 2.x предварителна версия (.kdbx файл).
- 0xB54BFB67 - KeePass 2.x след издаване (.kdbx файл).
Третият подпис е само за .kdbx файлове и съдържа версията на файла. За .kdb файлове тази информация се съдържа в заглавката на базата данни.
Така в KeePass 1.x дължината на подписа е 8 байта, а в KeePass 2.x е 12 байта.
След като базата данни е подписана, започва заглавката.
Заглавка на KeePass 1.x
Заглавката на .kdb файла се състои от следните полета:
- Флагове (4 байта): Това поле показва даликакви видове криптиране са използвани за създаване на файла:
- 0x01 - SHA256;
- 0×02 - AES256;
- 0x04 - ARC4;
- 0x08 - Две риби.
- Версия (4 байта): версия на файла.
- Master Seed (16 байта): използва се за генериране на главния ключ.
- Шифроване IV (16 байта): използва се за дешифриране на данни.
- Брой групи (4 байта): Общият брой групи в базата данни.
- Брой записи (4 байта): Общият брой записи в базата данни.
- Хеш на съдържанието (32 байта): хеш на дешифрираните данни.
- Transform Seed (32 байта): използва се за генериране на главния ключ.
- Трансформирайте кръгове (4 байта): използвани за генериране на главния ключ.
Във файловете .kdbx всяко поле за заглавка се състои от 3 части:
- ID на полето (1 байт): възможни стойности от 0 до 10.
- Дължина на данните (2 байта).
- Данни ([дължина на данните] байтове)
Заглавката на файла .kdbx се състои от следните полета:
Главният ключ се генерира на 2 етапа:
- Генериране на съставен ключ;
- Генериране на главен ключ на базата на съставен ключ.
Хеш алгоритъмът SHA256 се използва за генериране на съставен ключ. Таблиците по-долу предоставят псевдокод за генериране на съставен ключ, въз основа на това коя версия на KeePass се използва и какви входни данни са необходими за дешифриране на базата данни (само парола, само ключов файл или и двете):
Парола | sha256 (парола) |
Ключов файл | sha256 (ключов файл) |
Парола + Ключов файл | sha256(concat (sha256(парола), sha256(ключов файл))) |
Парола | sha256(sha256(парола)) |
Ключов файл | sha256(sha256(ключов файл)) |
Парола + Ключов файл | sha256(concat (sha256(парола), sha256(ключов файл))) |
Потребителски акаунт на Windows (WUA) | sha256(sha256(WUA)) |
Парола + Ключов файл + (WUA) | sha256(concat (sha256(парола), sha256(ключов файл), sha256(WUA))) |
Обръщам внимание на факта, че ако са необходими няколко обекта за дешифриране на базата данни (например парола и ключов файл), първо трябва да получите хеш от всеки обект и след това да ги свържете заедно (concat) и да вземете хеша от комбинираната последователност.
2. Генериране на главен ключ на базата на съставен ключ
- Трябва дашифроватесъставния ключ, получен по-горе, като използвате алгоритъма AES-256-EBC.
- Като ключ трябва да използвате Transform Seed от заглавката.
- Това криптиране трябва да се извърши Трансформирайте кръгове (от заглавката) пъти.
- Използвайки SHA256, получаваме хеш от криптирания съставен ключ.
- Свързваме Master Seed от хедъра с получения хеш.
- Използвайки SHA256, получаваме хеш от комбинираната последователност -това е нашият главен ключ!
Веднага след заглавката започва самата криптирана база данни. Алгоритъмът за дешифриране е както следва:
- Цялата останала част от файласе дешифрирас помощта на алгоритъма AES-256-CBC.
- Като ключ използваме главния ключ, генериран по-горе.
- Използваме Encryption IV от заглавката като вектор за инициализация.
- Последните няколко байта от дешифрираната база данни са излишни - това са няколко еднакви байта в края на файла(подплата). За да елиминирате тяхното влияние, трябва да прочетете последния байт от дешифрираната база данни - това е броят на "допълнителните" байтове, които не трябва да се вземат предвид в бъдеще.
- Използвайки SHA256, получаваме хеш от дешифрираните данни (байтовете от предходния параграф не се вземат предвид).
- Проверете дали полученият хеш съответства на полето за хеш съдържание от заглавката:
- ако хешът съвпада, тогава успешно сме дешифрирали нашата база данни! Можете да запазите декриптираните данни като .xml файл и да се уверите, че всички влизания с пароли са декриптирани правилно,
- ако хешът не съвпада, това означава, че или е предоставена неправилна парола или ключов файл, или данните са били повредени.
Веднага след полето End of Header на заглавката започва самата криптирана база данни. Алгоритъмът за дешифриране е както следва:
- Цялата останала част от файласе дешифрирас помощта на алгоритъма AES-256-CBC.
- Като ключ използваме главния ключ, генериран по-горе.
- Използваме Encryption IV от заглавката като вектор за инициализация.
- Последните няколко байта от дешифрираната база данни са излишни - това са няколко еднакви байта в края на файла (padding). За да елиминирате тяхното влияние, трябва да прочетете последния байт от дешифрираната база данни - това е броят на "допълнителните" байтове, които не трябва да се вземат предвид в бъдеще.
- Проверете дали първите 32 байта от декриптираната база данни съвпадат с полето на заглавката на Stream Start Bytes:
- ако данните съвпадат, тогава сме генерирали правилния главен ключ,
- Ако данните не съвпадат, или е предоставена неправилна парола, ключов файл или WUA, или данните са били повредени.
- Ако предишната стъпка е успешна, изхвърлете първите 32 байта. Проверка на полетоФлагове за компресиране на заглавки. Ако е използвано GZip компресиране на файлове, разопаковайте данните.
- Нека започнем да проверяваме целостта на данните. Данните са разделени на блокове, като максималният размер на блока е 1024×1024. Всеки блок от данни започва със заглавка. Структурата на заглавката е следната:
- >
Това е общо взето всичко, което исках да кажа. Надявам се това ръководство да спаси някого от ненужни главоболия и да бъде информативно и информативно =)
Коментари ( 1 )
Акума