.PST вариант №
Файлы с расширением .pst представляют собой файлы личного хранилища Outlook (также называемые таблицей личного хранилища), в которых хранится разнообразная информация о пользователях. Информация о пользователе хранится в папках разных типов, включая электронные письма, элементы календаря, заметки, контакты и несколько других форматов файлов. Файлы PST используются для архивирования данных электронной почты в автономном режиме, которые впоследствии можно загружать и просматривать в различных приложениях.
Спецификации формата файла PST
Формат файла PST спецификации доступен от Microsoft в качестве бесплатного и безотзывного бесплатного патентного лицензирования через Open Specification Promise. .
Тип форматов PST
Форматы файлов PST подразделяются на два типа в зависимости от кодировки типа файла. Файлы PST с кодировкой ANSI являются старыми форматами файлов и поддерживаются только в Outlook 2002 и более ранних версиях. Такие файлы имеют максимальный размер 2 ГБ (2^^31^^ байт) и не поддерживают Unicode. Более современный тип формата файла, основанный на кодировке Unicode, снимает ограничение на размер файла и может достигать максимального размера данных 50 ГБ.
Логическая организация формата файла PST
В основе формата файлов PST лежит B-дерево, которое упорядочивает данные и позволяет выполнять поиск, последовательный доступ, вставки, удаления и т. д. в логарифмическом масштабе. Общая структура файла PST состоит из трех слоев.
«Уровень базы данных узлов (NDB)» — уровень базы данных узлов находится на нижнем уровне файла PST и включает базу данных узлов. Эти узлы фактически представляют собой низкоуровневые хранилища файлов формата PST. Уровень NDB состоит из заголовка, информации о размещении файлов, блоков и BT-деревьев (Node BTree и Block BTree) с точки зрения хранения. Узлы и блоки уровня NDB связаны через BID данных, который является одним из четырех свойств ссылки на узел, т.е. NID (идентификатор узла), NID родителя, BID данных (BID блока) и BID подузла.
Уровень списков, таблиц и свойств — уровень LTP обеспечивает логическое понимание концепций более высокого уровня поверх NDB. Помимо других элементов, уровень LTP в основном состоит из контекста свойств (PC) и контекста таблицы (TC). PC представляет собой набор свойств, а TC представляет собой двумерную матрицу набора свойств и их наличия. Эффективная реализация ПК и ТС, уровень LTP использует следующие два типа структур данных поверх узла NDB:
- Heap On Node (HN) — позволяет распределять поток данных узла на небольшие фрагменты переменного размера.
- BTree on Heap (BTH) - BTH обеспечивает удобный и практичный способ поиска по данным. PC, описанные выше, реализованы как BTH и поэтому реализованы путем построения внутри структуры HN.
«Уровень обмена сообщениями» — на этом уровне реализованы правила и бизнес-логика более высокого уровня для работы с файлами PST. Логический вывод этого уровня приводит к объектам «Папка», объектам «Сообщение», объектам «Вложения» и «Свойствам», что стало возможным благодаря объединению слоев LTP и NDB. На этом уровне также определяются правила и требования, которым необходимо следовать при изменении содержимого PST.
Физическая организация формата файла PST
Высокий уровень файловой организации PST-файла показан на рисунке ниже. Это просто обзор различных концепций логических элементов файла PST.
Информация заголовка PST
Структура HEADER файла PST расположена в самом начале файла по смещению 0. Он содержит информацию метаданных о файле PST и информацию ROOT для доступа к структурам данных уровня NDB, описанным выше. Структура HEADER различается для версий формата PST файлов Unicode и ANSI.
Заголовок начинается с 4-байтового магического слова !BDN, представленного байтами (0x21, 0x42, 0x44, 0x4E). Еще одно 2-байтовое магическое число, SM (0x53, 0x4D), расположено по смещению 8 от начала файла. Информация о версии (ANSI или Unicode) находится со смещением 10 от начала файла. Шестнадцатеричное значение (0x17) указывает файл Unicode PST, а 0x0E или 0x0F представляет формат файла ANSI.
| Поле | Описание |
|---|---|
| dwMagic (4 байта) | ДОЛЖЕН быть “{ 0x21, 0x42, 0x44, 0x4E } ("!BDN”)" |
| dwCRCPartial (4 байта) | 32-битное значение CRC из 471 байта данных, начиная с wMagicClient (0ffset 0x0008) |
| wMagicClient (2 байта) | ДОЛЖЕН быть “{0x53, 0x4D}”. |
| wVer (2 байта) | Версия формата файла. Это значение ДОЛЖНО быть 14 или 15, если файл является файлом ANSI PST, и ДОЛЖНО быть 23, если файл является файлом Unicode PST. |
| wVerClient (2 байта) | Версия формата файла клиента. Версия, соответствующая формату, описанному в этом документе, — 19. Создателям нового PST-файла на основе этого документа СЛЕДУЕТ инициализировать это значение равным 19. |
| bPlatformCreate (1 байт) | Это значение ДОЛЖНО быть установлено на 0x01. |
| bPlatformAccess (1 байт) | Это значение ДОЛЖНО быть установлено на 0x01. |
| dwReserved (8 байт) | |
| bidUnused (только 8 байт Unicode) | Неиспользуемое заполнение добавлено при создании формата файла Unicode PST. |
| bidNextP (Unicode: 8 байтов; ANSI: 4 байта) | BID следующей страницы. Страницы имеют специальный счетчик для распределения значений bidIndex. Из этого счетчика выделяется значение bidIndex для BID для страниц. |
| bidNextB (только 4 байта ANSI): | Следующая ставка. Это значение является монотонным счетчиком, который указывает BID, который будет назначен для следующего выделенного блока. Значения BID увеличиваются с шагом 4. Дополнительные сведения см. в разделе 2.2.2.2. |
| dwUnique (4 байта) | Это монотонно возрастающее значение, которое изменяется каждый раз при изменении структуры HEADER файла PST. Функция этого значения состоит в том, чтобы предоставить уникальное значение и гарантировать, что CRC HEADER различны после каждой модификации заголовка. |
| rgnid[] (128 байт) | Фиксированный массив из 32 NID, каждый из которых соответствует одному из 32 возможных NID_TYPE (NID_TYPE, NID_TYPE_NORMAL_FOLDER, NID_TYPE_SEARCH_FOLDER, NID_TYPE_NORMAL_MESSAGE,NID_TYPE_ASSOC_MESSAGE) |
| qwUnused (8 байт) | Неиспользуемое пространство; ДОЛЖЕН быть установлен на ноль. Только в формате Unicode PST. |
| root (Unicode: 72 байта; ANSI: 40 байтов) | КОРНЕВАЯ структура (раздел 2.2.2.5). |
| dwAlign (4 байта) | Неиспользуемые байты выравнивания; ДОЛЖЕН быть установлен на ноль. Только в формате Unicode PST. |
| rgbFM (128 байт) | Устаревший FMap. Это больше не используется и ДОЛЖНО быть заполнено 0xFF. Читатели ДОЛЖНЫ игнорировать значение этих байтов. |
| rgbFP (128 байт) | Устаревший FPMap. Это больше не используется и ДОЛЖНО быть заполнено 0xFF. Читатели ДОЛЖНЫ игнорировать значение этих байтов. |
| bSentinel (1 байт) | ДОЛЖЕН иметь значение 0x80. |
| bCryptMethod (1 байт) | Указывает, как кодируются данные в файле PST. ДОЛЖНО быть установлено одно из предопределенных значений (NDB_CRYPT_NONE, NDB_CRYPT_PERMUTE, NDB_CRYPT_CYCLIC). |
| rgbReserved (2 байта) | Сдержанный; ДОЛЖЕН быть установлен на ноль. |
| bidNextB (8 байт) | Указывает следующее доступное значение BID. Только в формате Unicode PST. |
| bidNextB (ТОЛЬКО Unicode: 8 байт) | Следующая ставка. Это значение является монотонным счетчиком, который указывает BID, который будет назначен для следующего выделенного блока. Значения BID увеличиваются с шагом 4. Дополнительные сведения см. в разделе 2.2.2.2. |
| dwCRCFull (4 байта) | 32-битное значение CRC из 516 байтов данных, начиная с wMagicClient и заканчивая bidNextB включительно. Только в формате Unicode PST. |
| ullReserved (8 байт) | Зарезервировано; ДОЛЖЕН быть установлен на ноль. Только формат файла ANSI PST. |
| dwReserved (4 байта) | Зарезервировано; ДОЛЖЕН быть установлен на ноль. Только формат файла ANSI PST. |
| rgbReserved2 (3 байта) | |
| bЗарезервировано (1 байт) | |
| rgbReserved3 (32 байта) |
Защита данных
В целях безопасности файлы PST также могут быть защищены паролем, что требует, чтобы загрузочное приложение применяло пароль, прежде чем его можно будет просмотреть. Пароль, примененный к файлу PST, хранится в хранилище сообщений. Однако это не обеспечивает надежной защиты данных, поскольку пароль можно удалить с помощью доступных средств. Кроме того, указанный пользователем пароль не используется как часть ключа для кодирования и декодирования алгоритмов шифрования. Таким образом, защита данных, к которым могут получить доступ неавторизованные стороны, бесполезна. Хранение пароля в виде хэша CRC-32 исходной строки также делает его слабым методом защиты данных от грубой силы.
