2013-10-24 15 views
15

Le versioni precedenti di suite iWork di Apple utilizzato un semplice formato di documento:Reverse formati '13 ingegneria iWork

  • documenti erano Fasci di risorse (cartelle, zip o no)
  • il pacchetto conteneva un file index.apxl[z] che descrive la struttura del documento in uno schema proprietario ma abbastanza facile da comprendere

iWork '13 ha completamente rifatto il formato. I documenti sono ancora pacchetti, ma ciò che era nel file XML dell'indice è ora codificato in una serie di file binari con suffisso di tipo .iwa impacchettato in Index.zip.

In Keynote, per esempio, ci sono i seguenti iwa file:

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

per MasterSlide s 1 ... n e Slide s 1 ... m

Lo scopo di ciascuno di questi è abbastanza chiaro dalla loro denominazione. I file appaiono anche non compressi, con essenzialmente tutto il testo del contenuto direttamente visibile come stringhe tra i blob binari (anche se con alcuni come RTF/NSAttributedString/spazzatura correlata simile nel mezzo dei caratteri ASCII leggibili).

Ho pubblicato lo Index decompresso di un semplice esempio di documento Keynote qui: https://github.com/jrk/iwork-13-format.

Tuttavia, il formato di file nel complesso non è ovvio per me. Apple ha una lunga esperienza nell'utilizzo di semplici formati standard della piattaforma come i plist per la codifica della maggior parte dei loro documenti, ma all'inizio non vi è alcun tag di tipo chiaro, e non è ovvio per cosa sono questi file iwa.

Questi file suonano le campane? Ci sono prove che siano in qualche formato di serializzazione ragionevolmente comprensibile?

Rovistando attraverso il runtime dell'app Keynote e i dump di classe con F-Script, l'unica prova che ho trovato è per qualche uso di Protocol Buffers nelle classi di serializzazione che sembrano essere usate per iWork, ad esempio https://github.com/nst/iOS-Runtime-Headers/blob/master/PrivateFrameworks/iWorkImport.framework/TSPArchiverBase.h.

Unire rapidamente alcuni file tramite protoc --decode_raw con i primi 0 ... 16 byte eliminati non produce nulla di evidentemente utilizzabile.

+0

hai provato 'file ThemeStylesheet.iwa' per vedere se il file può capire quali sono? –

+0

Sì, e il file restituisce solo 'dati' (vale a dire, non ne ha idea). – jrk

+0

Sto anche cercando di decodificare questo formato, ma concentrandomi su Pages, quindi sto guardando 'Document.iwa'. Diverse persone hanno suggerito che Apple sta usando i buffer di protocollo, quindi ho scritto uno script per '--decode_raw' tutte le possibili sezioni del documento (ad esempio byte 100 -> 3000). Come te, non ho trovato risultati utilizzabili. – stevel

risposta

22

Ho fatto qualche lavoro reverse engineering del formato e pubblicato i miei risultati here . Ho scritto un description del formato e ho fornito anche un progetto di esempio.

Fondamentalmente, i file .iwa sono flussi di Protobuf compressi usando Snappy.

Spero che questo aiuti!

+0

Bel lavoro e documentazione! – WMIF

3

Progetto interessante, mi piace! Ecco cosa ho trovato finora.

I primi 4 byte di ciascuno dei file iwa sembrano essere una lunghezza, con un tweak. Quindi sembra che non ci sarà alcuna "magia" per verificare il tipo di file.

Guardate Slide1.iwa:
primi 4 byte sono 00 79 02 00
dimensione del file è 637 byte
prendere la prima 00 off, e invertire il byte: 00 02 79
00 02 79 == 633
637-633 = 4 byte che contengono la dimensione del file.

Questo estrae per i file di 4 ho guardato: Slide1.iwa, Slide2.iwa, Document.iwa, DocumentStylesheet.iwa

+1

Quello che vedi è chiamato "little endianness" (http://en.wikipedia.org/wiki/Endianness#Little-endian), non un "tweak" :) –