Обратное проектирование 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