Что собой представляет формат хранения данных microsoft word
На прошлой неделе Microsoft опубликовала спецификации форматов бинарных файлов для Office. Эти форматы выглядят безумно. Формат файла Excel 97-2003 представляет собой 349-страничный файл PDF. И это ещё не всё! В документе содержится такой комментарий:
Видите ли, файлы Excel 97-2003 – это составные документы OLE, которые в свою очередь представляют собой некое подобие файловой системы в одном файле. Чтобы в этом разобраться, нужно прочитать 9 страниц документации. А сами спецификации больше похоже на структуры данных в С, чем на то, что мы привыкли называть спецификациями. Это иерархическая система файлов.
Если вы подумали, что почитаете эти форматы и за выходные набросаете утилитку для экспорта вордовских документов в свой блог, или создающую экселевские таблички на основе ваших персональных финансовых данных, то сложность и длина этих спецификаций должны были отбить у вас всю охоту. Нормальный программист решит, что формат бинарников из Office:
- сделан запутанным специально
- придуман каким-то страдающим от старческого маразма представителем кибернетической расы боргов
- создан безумно плохими программистами
- не может быть правильно создан или прочитан
Первое, что нужно понять – цели у разработчиков форматов бинарников кардинально отличались от целей разработчиков, допустим, HTML.
Они должны были очень быстро работать на очень старых компьютерах. Во времена первых версий Excel для Windows 1 мегабайт памяти был не редкостью, а работать достаточно комфортно программа должна была на процессорах 80386 с частотой 20 МГц. Множество оптимизаций сделано для ускорения открытия и сохранения файлов:
- Это форматы бинарных файлов, поэтому загрузка записи обычно означает копирование последовательности байтов с диска в память, в которой появляется структура данных С. Не происходит никакого разбора или лексического анализа данных, так как это в разы медленнее простого копирования.
- Формат файлов запутан в нужных местах для ускорения типичных операций. К примеру, у Excel 95 и 97 была функция «простого сохранения», которая использовалась в качестве ускоренного варианта документа OLE, полная версия которого была не слишком быстрой для повсеместного использования. У Word было нечто подобное под названием "быстрое сохранение". Для быстрого сохранения длинных документов 14 раз из 15 все изменения просто добавлялись в конец файла, а весь файл не перезаписывался с нуля. Для жёстких дисков того времени это означало, что можно было успеть сохранить документ, допустим, за 1 секунду вместо 30. Также это означало, что удалённые части документа всё ещё хранились в файле – а людям, как оказалось, это не было нужно.
У Office была поддержка составных документов, к примеру, можно было включить электронную таблицу в файл Word. Идеальный парсер Word должен был суметь сделать что-то умное с включённой таблицей.
Они не разрабатывались для использования в других приложениях. Довольно разумное на тот момент предположение заключалось в том, что формат Word будет писать и читать только программа Word. Поэтому когда программист из команды разработчиков Word принимал решение о смене формата файла, его волновали лишь а) скорость работы и б) минимальное количество строк в коде Word. Идеи вещей типа SGML и HTML, заменяемых, открытых и стандартизированных форматов, не были популярными, пока интернет не сделал такие вещи практичными. Этот момент пришёл через 10 лет после разработки форматов файлов Office. Всегда предполагалось использование программ для экспорта и импорта. У Word есть поддержка формата для простого обмена документами по имени RTF, существовавшего почти с самого начала.
Им нужно было отразить всю сложность приложений. Каждую галочку, каждую возможность форматирования и каждую функцию Microsoft Office необходимо было хранить в файлах. Поэтому для создания идеального клона Word, читающего его файлы, нужно было реализовать все его функции. Если вы создаёте программу для работы с текстом – конкурента Word, которая должна уметь загружать его файлы, у вас может занять немного времени сама загрузка указанных в файле опций. Но реальное отображение их всех на странице – это задача более сложная. А если её не решить, то ваши клиенты откроют вордовский файл в вашем клоне, и всё форматирование может поломаться.
Им нужно было отражать историю развития программ. Множество сложных вещей в форматах – это старые, сложные, ненужные и редко используемые функции. Они присутствуют там лишь для обратной совместимости и потому, что для разработчиков ничего не стоит оставить код в покое. Но чтобы тщательно выполнить работу разборки или записи этих файлов, вам придётся повторить всю эту работу, что была проделана в Microsoft за 15 лет. В текущие версии Word и Excel вложены тысячи человеко-часов работы, и для клонирования этих программ вам придётся вложить свои тысячи человеко-часов. Формат файла – это просто краткое обобщение всех поддерживаемых приложением функций.
Просто для примера разберём одну возможность подробнее. Лист Excel – это набор разных записей BIFF. Рассмотрим самую первую запись в спецификации – это запись под именем 1904.
В спецификации об этой записи написано весьма туманно. Просто написано, что «запись 1904 показывает, используется ли система дат 1904». Классический пример бесполезной спецификации. Если бы вы были разработчиком, и наткнулись бы на такое «объяснение», вы бы весьма оправданно пришли к заключению, что Microsoft что-то скрывает. Такое описание недостаточно само по себе, вам нужно искать дополнительную информацию. Я поясню: существует два типа листов Excel. В одних даты начинаются с 1/1/1900 (в них же ошибка високосного года специально создана для совместимости с форматом 1-2-3), в других – с 1/1/1904. Excel поддерживает оба варианта – поскольку первая его версия, для Mac, использовала второй вариант, который был системным, а Excel для Windows должен был иметь возможность импортировать файлы 1-2-3, использовавшие даты с 1/1/1900. Уже на этом месте можно расплакаться.
Оба типа файлов, 1900 и 1904, встречаются в изобилии в дикой природе, в зависимости от того, пришли они с Mac или Windows. Автоматическая конвертация дат может привести к ошибкам, поэтому Excel сам тип файла не меняет. Для разборки файлов Excel приходится работать с обоими. А это значит, что вам не просто нужно загрузить этот бит из файла, но ещё и переписать весь код разбора и показа дат, чтобы обрабатывать оба варианта. Это работа на несколько дней.
Работая над клоном Excel вы встретите множество таких скрытых деталей по работе с датами. Когда Excel преобразовывает числа в даты? Как работает форматирование? Почему 1/31 интерпретируется как 31 января текущего года, а 1/50 – как первое января 1950? Все эти детали нельзя описать без того, чтобы получившееся описание не сравнялось по объёму с исходниками Excel.
И это только одна из сотен BIFF-записей, и одна из простейших. Большинство из них настолько сложные, что могут заставить взрослого программиста рыдать.
Единственное возможное решение будет следующим. Конечно, Microsoft оказала большую услугу, опубликовав форматы файлов, но импортировать их или сохранять в них от этого легче не будет. Это безумно сложные приложения, и вы не можете просто реализовать 20% самых популярных функций и рассчитывать, что 80% остальных людей будут счастливы. Спецификации бинарников в лучшем случае сохранят вам пару минут при реверс-инжиниринге сложной системы.
Но я обещал рассказать, что с этим делать. Почти всем популярным приложениям не нужно заниматься чтением и записью бинарников от Office. Есть две альтернативы: дать Office работать самому, или использовать более простые форматы файлов.
Пусть Office работает сам. У Word и Excel есть весьма полные модели объектов, доступные через COM Automation, благодаря чему в программе можно сделать всё. Во многих случаях лучше повторно использовать код из Office вместо попыток написать его заново. Примеры:
- Открытие листа Excel, сохранение некоторых данных в ячейках, подсчёт и выдача результата.
- Использования Excel для создания графиков в формате GIF
- Вытаскивание любой информации из файла Excel без разбора форматов файлов
- Преобразование файла Excel в CSV (другой подход – использовать драйверы Excel ODBC и забирать данные через SQL-запросы)
- Редактирование документов Word
- Заполнение форм в Word
- Преобразование файлов между разными форматами, которые поддерживает Office (существуют возможности импортирования десятков форматов текстовых процессоров и электронных таблиц).
Используйте форматы попроще. Если вам просто нужно программно создать документы для Office, почти всегда есть формат получше, который затем можно свободно открыть в Word или Excel.
Microsoft Word (часто — MS Word, WinWord или просто Word) — текстовый процессор, предназначенный для создания, просмотра и редактирования текстовых документов, с локальным применением простейших форм таблично-матричных алгоритмов. Выпускается корпорацией Microsoft в составе пакета Microsoft Office.
Программа для печати текста Microsoft Word
В нашем компьютере множество самых разных программ. Какими-то из них мы пользуемся часто, другие же используем крайне редко или вообще никогда. Но есть в компьютере программы, знать и уметь пользоваться которыми просто необходимо. И одна из них – программа Microsoft Word.
Конечно, если Вы используете компьютер только для игр и общения в Интернете, то без программы Microsoft Word Вы спокойно сможете обойтись. Но в этом случае вряд ли Вас можно назвать пользователем компьютера. Ведь пользователь компьютера – это человек, который умеет выполнять на компьютере основные операции (создавать папку, копировать, удалять) и работать с популярными компьютерными программами, в числе которых Word и Excel. Кстати, когда работодатель требует от сотрудника знание ПК, это означает, в первую очередь, знание программы Microsoft Word.
Базовые знания по работе на компьютере Вы сможете получить из бесплатного курса «Обучение компьютеру».
Что такое Microsoft Word
Microsoft Word – это программа для печати текста и составления документов. Проще говоря, Microsoft Word (сокращенно Word) – это программа для печатания. То есть в этой программе можно напечатать любой тип текста: статью, документ, реферат, курсовую, диплом и даже книгу. Также в этой программе можно красиво оформить текст - добавить в него картинку или фото, выделить его части разными цветами, изменить шрифт, размер букв и многое другое. А еще в программе Microsoft Word можно составить таблицу, напечатать объявление или сделать плакат. Плюс ко всему напечатанное можно вывести на бумагу, то есть распечатать на принтере.
Что из себя представляет программа Word
Программа Word представляет из себя белый лист бумаги, на котором, используя клавиатуру компьютера, сразу же можно печатать. Причем, это не один лист бумаги: если Вам нужно напечатать много текста, и на один лист он не поместится, то программа автоматически добавит еще листы. Также напечатанный текст можно отредактировать: изменить размер букв, шрифт, начертание и многое другое. Для этого в программе Word есть специальные кнопки.
46.Программа Microsoft Excel.
Microsoft Excel – это широко распространенная компьютерная программа. Нужна она для проведения расчетов, составления таблиц и диаграмм, вычисления простых и сложных функций.
На большинстве компьютеров есть набор (пакет) программ Microsoft Office. Эти программы принято называть «офисными», так как они незаменимы при работе в офисе. Самые популярные офисные программы – Microsoft Word и Microsoft Excel.
Microsoft Word – это программа для печати текста и составления документов. О ней Вы сможете узнать из уроков раздела Microsoft Word. А сейчас поговорим подробнее о программе Microsoft Excel, или сокращенно Excel (эксэль).
Цель лабораторной работы : изучить и научиться пользоваться текстовым редактором Microsoft Word 2007. Научиться оформлять текстовые документы в соответствие с предъявляемыми требованиями.
Предварительные требования к студенту : Студент должен иметь опыт в наборе и редактировании текстов.
Длительность : Длительность лабораторной работы 3 часа. За 3 часа студент должен изучить текстовый редактор Microsoft Word 2007 и защитить лабораторную работу, ответив на вопросы преподавателя и выполнив практические задания выданные преподавателем во время защиты.
Вопросы для проверки знаний
1. Что такое цифровая подпись и что она удостоверяет?
2. Дать определение идентификация, аутентификация?
3. Что собой представляет формат хранения данных Microsoft Word 2007?
4. Что такое XML?
5. Преимущества формата Open XML?
6. Дать определение «Автозамена».
7. Дать определение «Автоформат».
8. Дать определение «Экспресс-блоки».
Задания для проверки знаний
1. Показать умение размечать страницу.
2. Создать документ, в котором текст печатается в две колонки, с
заголовком и окончанием в одну колонку (без применения таблиц).
3. Показать умение пользоваться стилями.
4. Создать себе визитку с помощью шаблона.
5. Создать три страницы с разными колонтитулами.
6. Создать документ с главами в соответствие со стилем и оформить оглавление в автоматическом режиме.
7. Создать шаблон документа в соответствии с требованием к оформлению.
8. Показать умение пользоваться «Автозаменой».
9. Показать умение пользоваться «Экспресс-блоками».
10.Показать умение оформлять текст в виде списка.
11.Показать умение оформлять текст в виде таблицы.
12.Показать умение «Рецензировать» документы.
13.Показать умение работать с «Примечаниями».
14.Составить расписание занятий в виде таблицы.
15.Начертить план кабинета, используя встроенные в Word фигуры.
16.Показать умение вставлять в документ математические выражения.
17.Показать умение вставлять формулы, способные выполнять математические операции.
18.Показать умение автоматического формирования оглавления.
19.Показать умение автоматической нумерации рисунков, таблиц,
20.Показать умение вставки ссылок на иллюстрации, таблицы формул.
21.Показать умение автоматического формирования списка литературы.
22.В соответствие с требованиями, оформить набранный Вами текст.
Требования к оформлению:
Формат текста: Microsoft Word.
Формат страницы: А 4 (210*297 мм).
Выравнивание текста: по ширине.
Поля: 20 мм – сверху, снизу, справа, слева;
Шрифт: размер (кегль) – 14; тип – Times New Roman; абзацные отступы 1,25.
Межстрочный интервал – полуторный.
Рисунки, графики, схемы должны выполняться в графических редакторах, поддерживающих векторную графику; таблица - в режиме таблиц.
Все рисунки, таблицы, графики должны быть пронумерованы и подписаны.
Название глав печатается прописными буквами, шрифт – жирный.
После отступа в 1,5 интервала следует текст, печатаемый через полуторный интервал.
В заголовке недопустимы переносы, точка в конце не ставится.
Все сноски даются в тексте в квадратных скобках:[7].
Список использованной литературы озаглавливается словом литература, набранным жирным шрифтом 14
кеглем и расположенным посередине.
В случае возникновения вопроса, обращайтесь к справке
Рис. 1 Пояснение к поиску справки
Предназначение текстового редактора Microsoft Word 2007
Текстовый редактор Microsoft Word 2007 входит в состав системы
Microsoft Office 2007 и предназначен для оформления текстовых документов.
Microsoft Office Word 2007 содержит широкий набор инструментов для создания и форматирования профессионально оформленных текстовых документов.
Рис. 2 Окно выбора создаваемого документа
Для доступа ко всем командам текстового редактора Microsoft Word 2007
используется лента команд (Ribbon). Она выполнена таким образом, чтобы обеспечить быстрый доступ ко всем командам и что бы этот доступ был энергоэкономичным.
Рис. 3 Ленточный интерфейс
Форматы хранения текстовых документов
В Microsoft Office 2007 основной формат представления данных
является формат Open XML. Расширение файла .docx на самом деле является
zip архивом, в котором хранятся в формате Open XML весь ваш документ,
включая таблицы, рисунки, диаграммы…. Microsoft Word 2007 способен сохранять документ в формате doc, docx, dot, TXT, PDF и XPS.
Приемущества формата Open XML
При использовании форматов Office Open XML сокращается размер файла, упрощается устранение неполадок с документом, а также обеспечивается защита конфиденциальных данных в документах. Каким образом это достигается?
В новых форматах для автоматического сжатия файлов используется технология ZIP. Сжатие файлов происходит при каждом сохранении без использования дополнительного программного обеспечения,
поэтому файлы имеют намного меньший размер, чем в предыдущих версиях Microsoft Office.
Файлы в формате Office Open XML состоят из нескольких модулей — различные типы данных хранятся независимо друг от друга. Каждый документ фактически представляет собой пакет ZIP, в котором хранятся несколько файлов, например файл с текстом документа, файл заголовков и файл примечаний. Таким образом, при возникновении ошибки в одном компоненте документа другие компоненты не затрагиваются, что значительно упрощает восстановление содержимого.
XML — это язык разметки, основанный на концепции разметки документа для внесения изменений. Это означает, что содержимое документа, а также данные, сохраненные приложениями Word, Excel
или PowerPoint для форматирования и управления этим содержимым,
равнодоступны. Это позволяет легко получать доступ к хранящимся в документах данным и предотвращает утечку конфиденциальных данных.
Аутентификация - процедура проверки соответствия субъекта и того,
за кого он пытается себя выдать, с помощью некой уникальной информации,
в простейшем случае - с помощью имени и пароля.
Цифровая подпись – реквизиты электронного документа,
предназначенная для защиты электронного документа от подделки,
полученный в результате криптографического преобразования информации с использованием закрытого ключа электронной цифровой подписи и позволяющий идентифицировать владельца сертификата ключа подписи, а
также установить отсутствие искажения информации в электронном документе, а также обеспечивает неотказуемость подписавшегося.
Цифровые подписи помогают удостоверить следующее:
Подлинность . Цифровая подпись помогает гарантировать, что поставивший подпись — тот, кем он является в действительности.
Целостность. Цифровая подпись помогает гарантировать, что содержимое документа не менялось и не подделывалось после ввода цифровой подписи.
Неотрекаемость . Цифровая подпись помогает доказать любой из
сторон авторство подписанного содержимого. «Отказ» означает, что владелец подписи отрицает свою связь с подписанным содержимым.
После того как в документе появилась цифровая подпись, он становится доступен только для чтения, чтобы не допустить внесение изменений.
Рис. 4 Объект отображающий, что документ подписан электронной
Для добавления строки подписи в документ выполните следующие
1. Поместите указатель мыши в то место в документе, где необходимо добавить строку подписи.
2. На вкладке Вставка в группе Текст наведите указатель мыши на стрелку рядом с Строка подписи и затем выберите значение Строка подписи Microsoft Office.
3. В диалоговом окне Настройка подписи введите сведения о лице,
которое будет подписывать эту строку подписи. Эти сведения будут отображены прямо под строкой подписи в документе. Выполните любое из следующих действий:
Введите имя подписывающего лица в поле предлагается для подписания.
Введите название должности подписывающего лица (если таковое имеется) в поле Должность предложенного подписывающего.
Введите адрес электронной почты подписывающего лица (если таковой имеется) в поле Адрес электронной почты предложенного подписывающего.
4. Если необходимо снабдить подписывающее лицо какими-либо инструкциями, впечатайте их в поле Инструкции для подписывающего.
Инструкции отображаются в диалоговом окне Подпись, в котором лицо ставит подпись.
5. Если необходимо дать возможность подписывающему лицу добавлять комментарии к подписи, установите флажок Разрешить подписывающему добавлять примечания в окне подписи.
6. Если необходимо отобразить дату подписывания документа,
установите флажок показывать дату подписи в строке подписи.
8. Для добавления дополнительных строк подписи повторите шаги 1 - 7.
Рис. 5 Вкладка для разметки страниц
Вкладка для разметки страниц показана на Рис. 5.
Изменение разметки и форматирования для отдельного раздела
Для изменения разметки и форматирования одной или нескольких страниц документа используются разрывы раздела. Например, можно разметить часть страницы с одной колонкой как имеющую две колонки,
разделить главы документа так, чтобы нумерация страниц для каждой из глав
начиналась с 1, или задать разные колонтитулы для различных разделов документа.
Примечание. В галерее шаблонов страницы Microsoft Office Word 2007 доступно множество стандартных вариантов разметки страницы.
Например, выбрав соответствующую разметку в галерее шаблонов с помощью команды Новая страница, можно добавить страницу, которая содержит одну колонку и раздел, имеющий две колонки.
Рис. 6 Два раздела с разным форматированием. 1-раздел с одной колонкой,
2-раздел с двумя колонками
Типы разрывов разделов
Разрывы разделов позволяют изменить разметку или формат части документа. Для изменения доступны следующие параметры:
Размер и ориентация бумаги
Источник бумаги для принтера
Вертикальное выравнивание текста на странице
Колонтитулы (Колонтитулы. Верхний колонтитул, который может включать в себя текст и рисунки, располагается в верхней части каждой страницы раздела. Нижний колонтитул располагается в нижней части каждой страницы. Обычно колонтитулы содержат номера страниц, названия глав, даты и имена авторов.)
Изменение разметки и форматирования документа
Для изменения разметки и форматирования документы, выполните
1. Выберите место, с которого будет начинаться текст с другим форматированием.
Можно выбрать часть документа, вставив два разрыва раздела в ее начале и
2. На вкладке Макет страницы в группе Параметры страницы выберите команду Разрывы.
Рис. 7 Группа параметры страницы
3. В группе Разрывы разделов выберите тип разрыва раздела,
соответствующий необходимым изменениям формата.
Например, при разделении документа на главы, может потребоваться начинать каждую из них с нечетной страницы. В этом случае в группе Разрывы разделов следует выбрать параметр С нечетной страницы.
Всем привет!
Этой статьей мы открываем цикл, посвященный исследованию безопасности компонентов Microsoft Office. Речь в материале пойдет о форматах данных, шифровании и получении символов.
Когда в компании Microsoft задумывался и разрабатывался масштабный пакет офисных программ Microsoft Office, вероятно, создатели надеялись на успех. Сложно сказать, могли ли они рассчитывать на его триумфальное шествие по миру впоследствии, на то, что продукт станет фактическим стандартом, а существование его растянется на десятилетия. Однако можно уверенно утверждать, что массивность приложений, количество человеко-часов, затраченных на создание, развитие, поддержку обратной совместимости компонентов продукта способствовали появлению «тяжелого наследия» в виде устаревшего, написанного десятилетия назад программного кода, составляющего ядро приложений даже в последних версиях пакета. Требования, которые предъявлялись к коду двадцать лет назад, изменились. Сегодня во главу угла ставится кроссплатформенность, масштабируемость и безопасность. При этом, расходы на значительные изменения в продукте таковы, что Microsoft предпочитает подход «не сломано – не трогай», и старательно обеспечивает обратную совместимость с самыми древними форматами документов. Не обходится и без определенного давления со стороны коммерческих и государственных структур, которые также медленно и неохотно обновляют свои технологические парки, предпочитая привычные средства в ущерб развитию и безопасности.
Покопавшись в дебрях обработчиков файлов Microsoft Office, мы готовы представить вам это небольшое исследование.
Component Object Model и хранение данных
Так может выглядеть использование приложением-контейнером разнородных компонетов независимо от их местоположения
На практике обычно подразумевается не столько сам стандарт, сколько его реализация в ОС семейства Windows. Первые версии COM были разработаны еще для 16-разрядных Windows в качестве основания для OLE (оно же теперь ActiveX). Изначальной целью разработки этих подсистем была возможность создания (!) составных документов Word и Excel для Windows 3.x, и они были выпущено на свет около 1991 года (в разных источниках даты расходятся).
Работая с приложением, пользователь изменяет изображение, содержимое окна браузера и строки в полях ввода. Само приложение взаимодействует с компонентами, вызывая их методы и устанавливая их свойства, иными словами, изменяя внутреннее состояние объектов, о внутреннем устройстве которых не имеет представления.
В один прекрасный момент пользователь решает сохранить проделанную работу и нажимает кнопку «Save». Перед нашим приложением стоит грандиозная задача — записать на диск набор данных в совершенно разных форматах, о большей части которых (и данных, и форматов) приложению ничего не известно, да и находятся они для него в недосягаемости! Именно для решения этой задачи специалисты Microsoft и разработали одновременно с COM и «родной» для Component Object Model формат файла Compound File Binary Format, а вместе с ним систему интерфейсов для взаимодействия с этим форматом и их реализаций, объединяемых под именем Structured Storage.
Структурированное Хранилище COM
Для универсального доступа приложений и компонентов к сложному, к тому же закрытому, формату CFBF, для прозрачной как для контейнера, так и для компонентов замены одного формата другим, были разработаны библиотечные интерфейсы IStorage и IStream и соответствующие API. Виртуальная структура данных, к которой получает доступ приложение посредством этих интерфейсов, представлена системой вложенных каталогов – Хранилищ (Storages), каждый из которых может содержать некоторое число последовательностей байтов – Потоков (Streams), в которых и хранятся данные.
Виртуальное представление формата CFBF (StructuredStorage)
Информация в потоках может храниться в любом удобном виде, включая текст, изображение в любом формате, зашифрованные или сжатые данные, или даже другие файлы CFBF. Не составляет труда поместить в поток и исполняемый код (в т.ч. вредоносный).
Используя соответствующие API (см. Structured Storage Reference в MSDN), приложение может создать файл-хранилище и предоставить каждому компоненту хранилище второго (третьего и т.д.) уровня или поток (несколько потоков) для сохранения состояния в любом формате. Контейнеру нет необходимости знать, в каком виде компонент запишет свои данные, а о размещении информации в файле позаботится стандартная библиотека. Когда необходимо загрузить сохраненное состояние, контейнер открывает хранилище и предоставляет загруженным компонентам возможность считать потоки по мере надобности.
- исключение необходимости для приложений сохранять многочисленные отдельные файлы для разных типов данных, в том числе, для экономии места на диске
- создание унифицированного интерфейса для работы с данными, облегчающего создание приложений, и, в особенности, COM-компонентов, работающих с составными документами
- возможность сохранять текущее состояние элемента данных в любой момент времени
- ускорение доступа к данным
Последний пункт требует отдельного рассмотрения. Разработка Структурированного Хранилища велась на заре развития COM (начало 90х годов), когда существующие аппаратные ресурсы предъявляли повышенные требования к быстродействию сложных систем, в том числе при чтении и записи дисковых файлов. Поэтому система хранения данных должна была быть максимально оптимизирована для быстродействия. Это исключало использование, к примеру, текстовых форматов, требующих значительной предварительной обработки. Напротив, двоичные форматы, позволяющие копировать данные в память с минимальными модификациями, имели преимущество.
Результатом стала дисковая реализация Структурированного Хранилища – формат составных двоичных файлов Microsoft (Compound File Binary Format). Долгое время формат оставался закрытым, спецификации были опубликованы производителем в 2006 году.
Формат CFBF представляет собой «файловую систему внутри файла» и имеет таблицу размещения файлов (FAT), таблицу секторов, директории и «потоки» — аналог дисковых файлов.
Техническое представление формата CFBF
- Ярлыки и списки быстрого доступа
- Кэш изображений и результатов поиска
- Файлы установки (msi и msp)
- «Заметки» Windows
Формат Compound Binary File в приложениях пакета Microsoft Office
Формат документов, используемый Microsoft Office, изначально также представлял собой CFBF.
Документ Word, открытый утилитой для просмотра Structured Storage
Современные версии пакета в качестве основного используют открытый, основанный на XML, формат OfficeOpen XML, однако поддержка CFBF не прекращается с целью поддержания совместимости. Необходимо заметить, что значительная масса кода, отвечающего за работу со старыми форматами документов, была разработана давно (около 20 лет назад).
Word | .doc | Legacy Word document; Microsoft Office refers to them as «Microsoft Word 97 2003 Document» |
.dot | Legacy Word templates; officially designated «Microsoft Word 97 2003 Template» | |
.wbk | Legacy Word document backup; referred as «Microsoft Word Backup Document» | |
Excel | .xls | Legacy Excel worksheets; officially designated «Microsoft Excel 97-2003 Worksheet» |
.xlt | Legacy Excel templates; officially designated «Microsoft Excel 97-2003 Template» | |
.xlm | Legacy Excel macro | |
PowerPoint | .ppt | Legacy PowerPoint presentation |
.pot | Legacy PowerPoint template | |
.pps | Legacy PowerPoint slideshow | |
Publisher | .pub | Microsoft Publisher publication |
Примеры устаревших, по-прежнему поддерживаемых форматов Office
Простой поиск по сайтам государственных структур и предприятий РФ (госзакупки, сайты административных единиц) обнаруживает обескураживающе большое количество официальной документации, выложенной в CFBF, зачастую созданной в древних версиях Office, например, 2003 года. Предоставим читателю провести этот опыт самостоятельно.
двоичный файл формата CFBF внутри документа OfficeOpenXML
Несмотря на то, что документы различных приложений Office основаны на CFBF, каждое хранилище состояний элементов OLE/ActiveX будет иметь свой собственный дополнительный формат. Нужно иметь ввиду, что они во многом сложились исторически и были оптимизированы для максимального быстродействия на слабых компьютерах.
Поддержка Хранилищ OLE форматом RTF
OLE-компонент отображения формул Microsoft EQUATION
Примером уязвимости, связанной с технологией COM Structured Storage, может служить CVE-2017-11882.
Уязвимость была обнаружена в компоненте Microsoft Office настолько древнем, что производителем были утрачены исходные коды компонента.
Для сохранения состояния элементы Редактора Формул (Microsoft Equation Editor) использовали потоки структурированного хранилища. Нарушение целостности данных в потоках приводило к многочисленным уязвимостям, первой обнаруженной из которых была CVE-2017-11882, найденная специалистами Embedi.
Поток структурированного хранилища элемента EquationEditor
Некоторые другие унаследованные двоичные форматы, используемые в пакете Microsoft Office
Графический фильтр EPS
Графический фильтр EPS представляет собой компонент Office, который отвечает за редактирование EPS-изображений. Они являются векторными и строятся при помощи интерпретации внутреннего языка Encapsulated PostScript (версия обычного PostScript с некоторыми ограничениями).
В силу своих особенностей этот язык поддерживает самые разнообразные конструкции и возможности. Благодаря чему уязвимости повреждения памяти в графическом фильтре EPS эксплуатируются достаточно легко. Богатство языка делает возможным использование техник HeapSpray (например, возможность использования циклов) и HeapFengShui (предсказуемость выделения памяти интерпретатором). Даже несмотря на то, что рендеринг изображения происходит на виртуальном принтере, а само исполнение программы «EPS» происходит в рамках изолированного интерпретатора, наличие благоприятных возможностей эксплуатации уязвимостей и старая кодовая база сделали EPS едва ли не самым распространенным вектором атаки офисных приложений.
Ввиду того, что модуль был изначально разработан компанией Access Softek, а затем передан компании Microsoft, в этом компоненте найдено и успешно эксплуатируется существенное число «неизвестных» уязвимостей. Например, в апреле 2017 года компанией FireEye Inc. были найдены уязвимости CVE-2017-0261 и CVE-2017-0262. Эти две уязвимости повреждения памяти позволили злоумышленникам построить READ/WRITE-примитивы, с помощью которых они и добились выполнения своего кода за пределами изолированного процесса («песочницы») интерпретатора PostScript. Злоумышленники могут читать и записывать произвольные участки памяти в адресном пространстве уязвимого процесса, а также могут выполнить, например, поиск необходимых ROP гаджетов для построения ROP-цепочки, делающей остальной шелл-код исполняемым.
В обоих случаях атакующие добивались исполнения произвольного кода похожим образом: создавали объект в памяти с контролируемым содержимым (это было возможно сделать при помощи R/W примитивов) и вызывали один из его методов при помощи функции PostScript.
Данные уязвимости в графическом фильтре «EPS» стали популярным вектором атаки. Причем настолько, что компания Microsoft в апреле 2017 разработала обновление, которое полностью отключает графический фильтр. Однако, патч применим только для версии MsOffice 2010 SP2 и выше.
Базы данных Access
- использование макросов VBA в качестве некоторых триггеров и хранимых процедур;
- возможность использования ссылок на другие базы данных;
- закрытость формата БД препятствует использованию существующих баз в других окружениях.
Первый недостаток весьма серьезный, поскольку VBA-макросы по своим возможностям равносильны обычным исполняемым файлам. По этой причине использование Access может стать проблемой для безопасности.
Пользователь должен доверять БД, с которой работает, и быть уверенным, что в ней не содержится вредоносный код, внесенный злоумышленником. В противном случае запрет исполнения макросов существенно сокращает функциональность приложения для работы с данными в таблицах и представлениями.
Файлы Личных Папок Outlook
Спецификация .ost не была опубликована, и формально доступ к файлу Offline Storage Table может осуществляться только посредством MAPI. На деле эти форматы очень схожи и редактирование .ost также возможно. Необходимо иметь ввиду, что синхронизация отредактированного содержимого файла Offline Storage Table с данными на сервере Exchange может привести к необратимой порче данных и утере значимой информации.
Файл владельца/OwnerFile
Проблема совместной работы над документами Office, расположенными в сетевых хранилищах, была когда-то решена при помощи временных файлов простого формата, так называемых OwnerFile. Если файл в данный момент заблокирован для редактирования, приложение ищет в той же директории файл с коротким именем формата «~$name.doc». Файл содержит имя пользователя, открывшего документ в ASCII и Unicode форматах, в обоих случаях под имя отведен фиксированный размер массива. При создании файла неиспользуемые байты массива заполняются мусорными значениями из памяти приложения, что потенциально может привести к раскрытию чувствительной информации (в целом, из-за размера файла вероятность этого невелика). Имя пользователя в файле владельца также легко подделывается.
Механизм шифрования офисных документов
Механизм парольной защиты документов впервые появился в пакете Office 95. В то время стойкости используемых алгоритмов шифрования уделялось мало внимания, как следствие, применялись алгоритмы, на которые существовали практически применимые атаки. Этот факт стал толчком к изменению механизма в последующих версиях офисных пакетов.
В таблице приведены в хронологическом порядке наиболее распространенные в данное время офисные пакеты и используемые в них по умолчанию алгоритмы шифрования.
О сложности и жуткости вордовских файлов давно ходили легенды. Известно было, что формат этот крайне запутанный, а к тому же еще и полностью засекреченный, так что о половине тамошних полей можно было только догадываться.
Не скрою, что и меня эти файлы интересовали, но дальше первой страницы описания я так продвинуться и не смог. Однако незакрытый гештальт остался.
А теперь вот жизнь заставила (или подкинула возможность) все-таки разобраться во внутренностях всем хорошо известных документов, тем более, что в Штирлица теперь играть не обязательно, достаточно скачать с сайта «Майкрософта» официальные спецификации.
Что тут можно сказать? Невольно вспоминается старый пошлый анекдот: ну ужас. Ну просто ужас, но ведь не ужас-ужас-ужас.
Слава богу, что я разбирал эти файлы на Перле, а не на каком-нибудь автокоде Си. Высокий уровень языка и куча готовых библиотек (например, для чтения разных кодовых страниц) — это дар божий.
Так что работа в совокупности заняла неделю, и самым сложным было понять внутренний формат. Конечно, понимание это не совсем полное, потому что моей задачей было вытащить из документа одни тексты без всякого форматирования, но уж это я сделал тщательно.
Итак, как же устроены вордовские файлы?
Контейнер
Начнем с того, что это совсем не вордовские файлы, а некий универсальный контейнер, в который упакованы собственно документы. В такой контейнер засунуты все файлы Офиса, а, может быть, и еще что-нибудь.
Формат контейнера называется по-разному — docfile, ole storage, compound document file. Уже сам разнобой в названиях намекает на то, что он не сильно-то и нужен, поскольку действительно полезная вещь обычно имеет одно и четкое название. Основная его идея — иметь возможность запихать в один файл несколько других. Самым разумным было бы (как и сделали в OpenOffice) упаковать все в архив ZIP (можно без архивации, если она не нужна). Формат известен огромному множеству программ, компактен, легко разбирается. Но в «Майкрософте», очевидно, процветает синдром «Not invented here». Главное — изобрести велосипед, пусть и трехколесный, но собственный.
В принципе, формат OLE Storage достаточно разумен и не производит впечатление чего-то совсем идиотского. Но… он совершенно не нужен. Фактически, это что-то типа файловой системы FAT16, засунутой внутрь отдельного файла. Это не то что стрельба из пушки по воробьям, а истребление этих самых воробьев ядерными торпедами. В документе, внутри которого лежит несколько файлов, не нужна файловая система, находящаяся не менее чем на уровне ФС времен ДОС.
Итак, файлы CDF (как их называет юниксовская утилитка file) начинаются с заголовка. В заголовке отведено место под первую сотню записей ТРФ (таблицы размещения файлов, в просторечии — ФАТ). ФАТ там самый натуральный, очень похож на то, что можно найти на досовских дискетках. Остальные записи ТРФ лежат в отдельных секторах, соединенных связанным списком. Дополнительные сектора бывают только в больших (>7мб) файлах.
По табличке ФАТ/ТРФ можно собрать содержимое любого внутреннего файла (в терминологии МС он называется потоком, но это только запутывает дело), если знать, с какого блока он начинается. Начальные блоки разных структур написаны, естественно, в заголовке. Дальше из таблицы можно вытянуть всю цепочку секторов, в котором записано содержимое этого псевдофайла.
В частности, у CDF есть корневой каталог, физически размазанный по куче секторов. Это самый настоящий каталог, опять-таки, очень напоминающий старый досовский. Правда, для эффективности (или для выпендрежа) он выполнен не просто линейным списком, а сбалансированным двоичным деревом. Это значит, что в него без потери эффективности поиска можно записывать десятки тысяч отдельных записей. Зачем это нужно в файле, в котором записей бывает обычно штук пять, ну иногда, двадцать, ну максимум сто штук (презентация с огромным количество картинок) — знают только в Редмонде. Кстати, имена файлов в каталоге хранятся в UTF16 — тоже на всякий случай.
По каталогу можно определить начальный сектор любого файла и с помощью ТРФ вытянуть всю его цепочку размещения.
Но это еще не все.
Поскольку размер блока немаленький (обычно 512 байт, по спецификации возможно также 4096), то при хранении мелких псевдофайлов, теоретически можно потерять много свободного места. Поэтому существует отдельное хранилище, поделенное на блочки по 64 байта. Хранилище опять-таки вытягивается по цепочке ФАТ.
Чтобы указать, какие блочки какому файлу принадлежат, существует отдельная табличка ФАТ или, вернее сказать, миниФАТ.
Итак, чтобы добраться до вордовского документа, надо сделать следующее:
1. Прочитать заголовок CDF
2. Загрузить в память ФАТ — таблицу размещения файлов, собрав ее по цепочке секторов.
3. Загрузить табличку МиниФАТ, собрав ее по цепочке ТРФ
4. Загрузить хранилище блочков, собрав ее по цепочке ТРФ
5. Загрузить корневой каталог, собрав ее по цепочке ТРФ
6. Разобрать каталог и преобразовать его во что-то читаемое
7. Найти в каталоге запись WordDocument
8. Если это маленький файл, то собрать его с помощью миниТРФ из хранилища для блочков.
9. Если большой, то вытянуть с диска сектора по цепочке ТРФ.
Каждый шаг сам по себе не особенно сложен, но в совокупности они вызывают исключительно недоумение. Зачем такие сложности? Почему нельзя было разместить после заголовка обыкновенный линейный каталог, а после него непрерывно, друг за другом записывать внутренние файлы?
Единственное, что можно предположить — все это сделано для того, чтобы была возможность дописывать подфайлы, не трогая начало основного файла. Надо заметить, что, во-первых, это не сильно востребованная операция, поскольку все программы обычно записывают документы от начала до конца в один проход. Исключение составляет только MS Word и то только в пресловутом режиме быстрого сохранения, проклятом пользователями. А во-вторых, даже в этих условиях все равно не получится не трогать начало основного файла, поскольку надо обновлять каталоги, ТРФ и заголовки.
В общем, «Майкрософт» в своем амплуа. Зачем делать просто, если можно сложно и запутанно?
WordDocument
Формат CDF при всей своей монструозности хотя бы логичен и не очень сложен (если сравнивать с остальным содержимым вордовского документа). Его описание занимает всего каких-то двадцать страниц — тьфу по сравнению с 300 страницами формата Ворда.
Формат документа сложно даже назвать форматом, гораздо больше к нему подойдет определение каменной летописи. Представьте себе такой каменный обрыв, на котором отпечаталось пятьдесят миллионов лет истории планеты. Вот мезозойский слой, вот кайнозойский, вот отпечаток крыла птеродактиля, а сверху уже третичные отложения. Примерно так же выглядит и документ изнутри.
Достаточно посмотреть на заголовок, который занимает чуть ли не треть файла. Заголовков целых три. Сначала идет один небольшой, в котором половина записей зияет дырами «Reserved» или «Not used». Раньше, в мезозое, там явно что-то лежало, но потом было выкинуто на свалку истории. Здесь же имеется версия записавшей программы, по которой в коде, похоже, выполняется огромный switch/case.
Затем идет второй заголовок, состоящий из шестнадцатибитовых слов. В нем нет вообще ничего полезного. В его начале прописан размер явно с таким расчетом, что здесь будут в будущем откладываться панцири простейших.
После этого идет третий заголовок, на этот раз современный, из длинных слов (32 бита). Он немерянной длины, в начале тоже указывает количество записей с прицелом на дальнейшее расширение, и в основном представляет собой список, где искать различные таблицы и куски файла — пары начало/размер. Сами таблицы, кстати, лежат не здесь, а в отдельном псевдофайле CDF под названием 0Table или 1Table (возможны варианты).
В первом заголовке написана длина самого текста и его начало. Очевидно, что во времена царя Гороха именно так его и можно было прочитать. Текст лежал одним большим куском. Забавно, что можно читать его так и сейчас, но… не всегда! На десять читаемых файлов найдется такой, у которого в середине окажутся невразумительные куски, в конце — сноски, которых там быть не должно, а в самом начале — большой кусок текста, который стерли в прошлом году. Кроме того, половина файла окажется написана китайскими иероглифами. Прискорбно заметить, что известная утилита catdoc Витуса Вагнера в некоторых случаях именно такие результаты и дает, из чего можно сделать вывод, что формат она разбирает недокорректно.
Жизнь на самом деле гораздо сложнее. Когда-то в файлах действительно был только текст, однако со временем под давлением пользователей и маркетинга накапливались различные «фичи». Под них отвели отдельные потоки — под простые сноски, под сноски концевые, под колонтитулы, под какие-то textbox (то еще извращение — на вид текст, но не текст. Назначение толком не ясно).
Начала этих потоков указаны в специальных местах заголовка, но самый первый заголовок почему-то показывает общую длину — не самого текста, а текста плюс все этих извращений. Вот и первая причина, почему в вывод многих утилит попадают надписи типа Page 1.
Где-то в архее в редактор добавили быстрое сохранение. Смысл его в том, что файл целиком не переписывается, а добавления и изменения просто дописываются в его конец, что теоретически должно быть быстрее. Предполагалось радовать этим пользователей, но фактически они остались недовольны. Особой разницы в скорости записи при этом не получается, но в файле образуется много мусора, причем из кусков, которые теоретически уже стерты. Если там была какая-нибудь секретная информация, то простым просмотром дампа файла ее можно легко обнаружить.
Для поддержки быстрого сохранения была заведена особая таблица огрызков (piece table), в которую записывается начало каждого куска и его адрес в файле. Длины нет, но ее можно высчитать, вычтя начало текущего куска из начала следующего. Однако тут тоже надо быть осторожным, поскольку огрызки перечисляются из всех потоков. Слава богу, что они идут в определенном порядке, поэтому, зная общую длину текста, легко вовремя остановиться.
Теоретически, этот сложный формат задействован только, если в заголовке установлен специальный флажок fComplex. Но… Вот на этом очередном «но» тоже прокалываются многие конверторы.
Уже в наше время в документы добавили возможность записи в Юникоде. При этом встала проблема (как по мне, надуманная): а ведь файлы получаются ровно в два раза длиннее. Поскольку ПО разрабатывают американцы, которые в душе вообще не верят в существование других азбук, и тайно считают, что всякие странные буквы бывают только в диссертациях про Древнюю Грецию, да и там встречаются только иногда, первое, что пришло им на ум — отделить чистые символы ASCII от грязных юникодовских. Первые писать по байту на символ, вторые — как получится.
Из этой идеи возникла, например, элегантная кодировка UTF-8, где двухбайтовые символы кодируются хитрыми последовательностями в духе кодирования Хаффмана. В «Майкрософте» сделали то же самое, только не так красиво. Раз уж у нас есть таблица огрызков, то запишем туда заодно и какие куски текста написаны в чистом ASCII (на самом деле сp1252), а какие — на всякого рода невразумительных алфавитах, требующих Юникода и, соответственно два байта на символ. Поэтому нынешние файлы всегда нужно разбирать с помощью таблицы кусков, невзирая на всякие там флажки. Юникодовские фрагменты там берутся как есть, только надо учитывать, что количество читаемых байтов должно быть в два раза больше количества читаемых символов. Однобайтовые фрагменты отмечаются в адресе установленным вторым слева старшим битом (почему не первым?). Чтобы узнать настоящий адрес, нужно этот бит сбросить, а адрес разделить на два (!).
Если учесть, что сама эта таблица огрызков тоже занимает место, а еще больше места в файле занимают разные двоичные деревья и таблички цепочек секторов от формата CDF, то размеры экономии текста на символах Юникода не поразят воображения даже в древнегреческих диссертациях. О файлах на великом и могучем языке и говорить нечего. Положили бы все в UTF-16 и не страдали. Ну заархивировали бы поток, раз уж так жаба давит.
После героических усилий по чтению текста, в нем самом, как ни странно, нет ничего сложного. Обычный текст (с поправкой на кодировку), кое-какие коды ниже пробела играют служебную роль. Например, 0х9 обозначает, как и положено, табуляцию, 0хА — конец страницы, 0х7 — конец ячейки таблицы и т.д. Единственная тонкость связана с полями. Начало содержимого поля обозначается как 0х13, конец поля — 0х15, имя и параметры поля отделяются символом 0х14 от того, что, собственно, видно в тексте пользователю. Но… Вторая часть может иметь в себе вложенное поле, чего многие программы не учитывают. В результате в тексте остаются огрызки вроде INCLUDEPICTURE или PAGEREF *.
Впрочем, есть еще одна мелкая пакость. Некоторые символы могут означать что-нибудь совсем другое, вроде текущей даты. Чтобы понять, простой это символ или нет, надо разбирать таблицы свойств символов, о которых ниже. Каюсь, я просто вырезал все символы с кодом ниже пробела, что не совсем достаточно, но дешево, быстро и практично.
Выдрав текст, дальше в формат я углубляться не стал. Это уже занятие для молодых и сильных духом — разобрать все эти таблицы с такими многообещающими названиями как CHP, PAPX, SHST, PLCF и все в том же духе. Занятие совсем уже для титанов — вопроизвести форматирование в точности, как это делает сам Ворд.
Кратко изложу только, что все хранится в специальных таблицах, входом в которые служит адрес символа с начала потока. Стили лежат в длинных списках, изменения в стилях — в специальных списках исключений. Локальные изменения стиля, например, при редактировании абзаца или символа хранятся в таблицах как специальные команды по изменению родительских таблиц стилей. Сами команды очень напоминают команды виртуальной машины от типичной игры-квеста.
Осталось только подвести мораль, а она банальна: что один человек придумал, то другой завсегда поломать может. Что не делает формат Ворда менее позорным, уродливым и совершенно неприспособленным для задач массового обмена информацией в гетерогенных системах.
Думаю, что «Майкрософт» столько лет его не открывала не потому, что боялась конкуренции, а просто потому что было… стыдно.
Читайте также: