逆向工程iWork '13格式

Question

苹果iWork套件的早期版本使用了非常简单的文档格式：

• 文档是资源的绑定(文件夹，压缩或不压缩)
• 该包包含一个index.apxl[z]文件，该文件描述了一个专有的但相当容易理解的模式的文档结构。

iWork '13已经完全重做了这种格式。文档仍然是包，但是索引XML文件中的内容现在被编码在一组二进制文件中，文件的后缀.iwa被打包到Index.zip中。

例如，在基调中，有以下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和Slides 1…我

从它们的命名来看，每一种方法的目的都是非常清楚的。这些文件看起来甚至是未压缩的，基本上所有的内容文本都直接可见为二进制blobs之间的字符串(尽管在可读的ASCII字符中有一些类似于RTF/NSAttributedString/类似的垃圾)。

我在这里发布了一个简单示例主题文档的未打包的Index：https://github.com/jrk/iwork-13-format。

但是，总体的文件格式对我来说并不明显。苹果有着悠久的历史，它使用简单、平台标准的格式(如plist)来编码大部分文档，但在文件开头没有明确的类型标记，我也不清楚这些iwa文件是什么。

这些文件让人想起什么了吗？是否有证据表明它们处于某种合理的可理解的序列化格式中？

通过使用F脚本查看主题应用程序运行时和类转储，我发现的唯一证据是在序列化类中使用一些协议缓冲区，这些缓冲区似乎用于iWork，例如：https://github.com/nst/iOS-Runtime-Headers/blob/master/PrivateFrameworks/iWorkImport.framework/TSPArchiverBase.h。

用第一个0 protoc --decode_raw快速地将几个文件通过…16字节截取没有产生明显的可用。

Answer 1

我做了一些工作，反向工程了格式，并发表了我的结果这里。我编写了一个格式的描述，并提供了一个示例项目。

基本上，.iwa文件是使用Snappy压缩的Protobuf流。

希望这能有所帮助！

Answer 2

有趣的项目，我喜欢！这是我到目前为止所发现的。

每个iwa文件的前4个字节似乎是一个长度，并进行了调整。因此，看起来不会有任何“魔法”来验证文件类型。

看看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