Learning-History-of-CFF-bug-in-iphone

Immergendoti nei font CFF e imparando per caso un bof nel parsing di cff da qualche jailbreak. solo per divertimento

Quindi.... che diavolo è CFF? Dalla mia conoscenza è un formato di file, ma proviamo a capire cosa dice wikipedia:"CFF agisce come un contenitore per memorizzare più font insieme in una singola unità nota come FontSet."(https://docs.fileformat.com/font/cff/) quindi fondamentalmente possiamo memorizzare font insieme. bello, quindi ora cosa? beh, essendo un formato di file deve avere una specifica, e sì che ce l'ha, e no non è carina perché è di 60 pagine e non ho intenzione di impararne il formato. Ma possiamo usare l'exploit dal repo github di star-master (codice sorgente di jailbreak 2.0 credo) per impararne il formato.

Quindi... Iniziamo usando lo script cff.py fornito dall'autore e apriamo anche out.cff (file .cff semplice e standard) in hxd editor.

Possiamo vedere che quando diamo in pasto il file al parse otteniamo il seguente

Quindi abbiamo già fatto qualche progresso perché possiamo già arrivare a una definizione per cff, dato che possiamo concludere che abbiamo alcune informazioni sull'header che indicano le versioni, presumo tff, l'headersize e l'absoffsize, qualsiasi cosa ciò significhi.

Quindi fino ad ora |major version(1 byte)|minor version(1 byte)|header size(1 byte) | header absoffsize(1 bytes) |

Poi andiamo oltre e abbiamo una funzione che ottiene quali font sono usati in questo file .cff. Come visto

Quindi da dove sappiamo che il suo scopo è leggere quali font sono usati? Beh, eseguendo lo strumento abbiamo ottenuto il seguente risultato in cmd

che vediamo essere i byte successivi dopo i metadati del file

Torneremo più tardi all'analisi di questa funzione, ma per ora possiamo dedurre che il formato del file è |major version(1 byte)|minor version(1 byte)|header size(1 byte) | header absoffsize(1 bytes) | ABCDEF+fonts in pack|

Inoltre vediamo che cerchiamo quelli che nello script vengono chiamati string:

Perché? Perché presumo che vogliano raccogliere info sul font usato nel pack. Dalla documentazione dicono:"Tutte le stringhe, ad eccezione delle stringhe FontName e CIDFontName che compaiono nel Name INDEX, usate da diversi font all'interno del FontSet sono raccolte insieme in una struttura INDEX e sono referenziate da un numero senza segno di 2 byte chiamato string identifier o SID. Queste stringhe, note come stringhe standard, descrivono tutti i nomi usati nei set di caratteri ISOAdobe e Expert". Comunque una cosa interessante da notare qui è che abbiamo saltato circa 41 byte per arrivare alla stringa.

successivamente otteniamo informazioni sui font presenti nel file .cff

Come cavolo facciamo? beh, raccogliamo quelli che vengono chiamati dati top dict. che diavolo è? beh, da quello che sono riuscito a capire dalla documentazione, è un dict python con alcune informazioni, codificato in un certo modo.

Coincidenza, se seguiamo l'algoritmo di decodifica:

dereferenziamo il tipo di dati strings per ottenere info sul font, quindi concludiamo che i topdict hanno semplicemente alcuni indici che successivamente vengono usati nel tipo di dati strings per ottenere info sul font

Quindi fino ad ora la definizione del file regge ancora,

|major version(1 byte)|minor version(1 byte)|header size(1 byte) | header absoffsize(1 bytes) | ABCDEF+fonts in pack|41 bytes known|25 bytes of info about font|

Bello, quindi cosa succede dopo? Beh, se ispezioniamo lo script del parser vediamo che ottiene charstring_off, private_off e andrà alla posizione charstring_off e leggerà altra roba

Ma come ci aiuta a dare un senso a una visione più ampia. Quindi concluderò bruscamente. Fondamentalmente ho fatto un diff tra due file, un cff normale e il cff corrotto.

A sinistra c'è il file .cff corrotto e a destra un file .cff normale. Se ispezioniamo il risultato a runtime

Al primo avvio del parse vediamo che tutto, come count, offsize, offbase, sono semplicemente alcuni offset fino a certi delimitatatori. Quali delimitatori? Precisamente il nome del font. Quindi come puoi vedere ('offbase', 8L) cioè dall'inizio del file fino alla prima occorrenza della stringa del font presente nel file cff

Come si può vedere anche nel "second run of parse"

vediamo all'offset 0x6c nell'hexviewer il \x0e\0xe\0xe\x0e inizio dei nostri dati malevoli

Quindi come conclusione un formato generale del file .cff

|major version(1 byte)|minor version(1 byte)|header size(1 byte) | header absoffsize(1 bytes) | ABCDEF+fonts in pack|41 bytes known|25 bytes of info about font|

E formato file personalizzato (con contenuto utente)

|major version(1 byte)|minor version(1 byte)|header size(1 byte) | header absoffsize(1 bytes) | ABCDEF+fonts in pack|41 bytes uknown|25 bytes of info about font| 4 bytes(count) | 4 bytes(offsize) | 9 bytes left to be doccumented| user content|