Обратное проектирование iWork '13 форматов

Предыдущие версии пакета Apple iWork использовали очень простой формат документа:

  • документы были связями ресурсов (папки, с застежкой-молнией или нет)
  • пакет содержал файл index.apxl[z], описывающий структуру документа в проприетарной, но довольно простой для понимания схеме

iWork '13 полностью переделал формат. Документы все еще связаны друг с другом, но то, что было в XML файле индекса, теперь закодировано в наборе двоичных файлов с суффиксом типа .iwa, упакованным в Index.zip.

В Keynote, например, есть следующие файлы iwa:

AnnotationAuthorStorage.iwa
CalculationEngine.iwa
Document.iwa
DocumentStylesheet.iwa
MasterSlide-{n}.iwa
Metadata.iwa
Slide{m}.iwa
ThemeStylesheet.iwa
ViewState.iwa
Tables/DataList.iwa

для MasterSlide 1... n и Slide 1... m

Цель каждого из них совершенно ясно из их наименования. Файлы даже выглядят несжатыми, причем практически весь текст содержимого отображается непосредственно в виде строк между двоичными блоками (хотя некоторые из них похожи на мусор типа RTF/NSAttributedString/подобный, в середине читаемых символов ASCII).

Я опубликовал распакованный Index простой пример Keynote: https://github.com/jrk/iwork-13-format.

Однако общий формат файла для меня неочевиден. Apple имеет долгую историю использования простых форматов на платформе, таких как plists для кодирования большинства своих документов, но в начале файлов нет четкого тега типа, и для меня не очевидно, что эти файлы iwa.

У этих файлов есть кольца? Есть ли доказательства того, что они находятся в некотором разумно понятном формате сериализации?

Перекодирование через среду выполнения приложений Keynote и дампы классов с F- Script, единственное доказательство, которое я нашел, - это некоторое использование буферов протокола в классах сериализации, которые, как представляется, используются для iWork, например: https://github.com/nst/iOS-Runtime-Headers/blob/master/PrivateFrameworks/iWorkImport.framework/TSPArchiverBase.h.

Быстрое соединение нескольких файлов с помощью protoc --decode_raw с удалением первого 0... 16 байт, ничего явно не может быть использовано.

Ответы

Ответ 1

Я проделал некоторую работу по обратному проектированию формата и опубликовал мои результаты здесь. Я написал описание description и предоставил образец проекта.

В принципе, файлы .iwa представляют собой потоки Protobuf, сжатые с помощью Snappy.

Надеюсь, это поможет!

Ответ 2

Интересный проект, мне он нравится! Вот что я нашел до сих пор.

Первые 4 байта каждого из файлов iwa кажутся длиной, с настройкой. Таким образом, похоже, что не будет никаких "магии" для проверки типа файла.

Посмотрите на Slide1.iwa:
Первые 4 байта 00 79 02 00
Размер файла 637 байт
выньте первый 00 и отмените байты: 00 02 79
00 02 79 == 633
637 - 633 = 4 байта, которые содержат размер файла.

Это проверяет на 4 файла, на которые я смотрел: Slide1.iwa, Slide2.iwa, Document.iwa, DocumentStylesheet.iwa