spiralbl0ck/learning-history-of-cff-bug-in-iphoneMergulhe na fonte CFF e, coincidentemente, aprenda sobre um bof na análise de cff a partir de algum jailbreak. só por diversão
Mergulhe na fonte CFF e, coincidentemente, aprenda sobre um bof no parsing de CFF a partir de um jailbreak. só por diversão
Então.... o que diabos é CFF? Então, pelo que sei, é um formato de arquivo, mas vamos tentar entender o que o wikipedia diz: "CFF atua como um contêiner para armazenar várias fontes juntas em uma única unidade conhecida como FontSet." (https://docs.fileformat.com/font/cff/) então, basicamente, podemos armazenar fontes juntas. legal, e agora? bem, como é um formato de arquivo, ele tem que ter alguma especificação, e sim, ele tem uma, e não, não é legal porque tem 60 páginas e eu não estou disposto a aprender o formato. Mas podemos usar o exploit do repositório star-master no github (código-fonte do jailbreak 2.0, eu acho) para aprender sobre o formato.
Então... Começamos usando o script cff.py fornecido pelo autor e também abrimos o arquivo out.cff (arquivo .cff simples padrão) no editor HxD.
Podemos ver que, quando alimentamos o arquivo para o parse, obtemos o seguinte
Então já fizemos algum progresso, pois já podemos chegar a uma definição para CFF, já que podemos concluir que temos alguns metadados sobre seu cabeçalho que indicam as versões tff, presumo, o tamanho do cabeçalho e o absoffsize, seja lá o que isso possa ser.
Então, até agora |versão principal(1 byte)|versão secundária(1 byte)|tamanho do cabeçalho(1 byte) | absoffsize do cabeçalho(1 bytes) |
Depois, vamos mais longe e temos uma função que obtém quais fontes estão sendo usadas neste arquivo .cff. Como visto
Então, de onde sabemos que o propósito dela é ler quais fontes estão sendo usadas? Bem, ao executar a ferramenta, obtivemos o seguinte resultado no cmd
que vemos serem os próximos bytes após os metadados do arquivo
Voltaremos mais tarde à análise dessa função, mas por enquanto podemos deduzir que o formato do arquivo é |versão principal(1 byte)|versão secundária(1 byte)|tamanho do cabeçalho(1 byte) | absoffsize do cabeçalho(1 bytes) | ABCDEF+fontes no pacote|
Além disso, vemos que procuramos pelo que é chamado de string no script:
Por quê? Porque eu presumo que eles querem coletar informações sobre a fonte usada no pacote. Pela documentação, eles dizem: "Todas as strings, com exceção das strings FontName e CIDFontName que aparecem no Name INDEX, usadas por diferentes fontes dentro do FontSet, são reunidas em uma estrutura INDEX e são referenciadas por um número sem sinal de 2 bytes chamado identificador de string ou SID. Essas strings, conhecidas como strings padrão, descrevem todos os nomes usados nos conjuntos de caracteres ISOAdobe e Expert". De qualquer forma, uma coisa interessante a notar aqui é que pulamos aproximadamente 41 bytes para chegar à string.
em seguida, obtemos informações sobre as fontes presentes no arquivo .cff
Como diabos fazemos isso? Bem, coletamos o que é chamado de dados do top dict. O que diabos é isso? Bem, pelo que consegui entender da documentação, é um dict Python com certas informações, codificadas de uma certa maneira.
Coincidentemente, se seguirmos o algoritmo de decodificação:
desreferenciamos o tipo de dados strings para obter informações sobre a fonte, então concluímos que os topdicts simplesmente têm alguns índices que depois são usados no tipo de dados strings para obter informações sobre a fonte.
Então, até agora, a definição do arquivo continua valendo,
|versão principal(1 byte)|versão secundária(1 byte)|tamanho do cabeçalho(1 byte) | absoffsize do cabeçalho(1 bytes) | ABCDEF+fontes no pacote|41 bytes conhecidos|25 bytes de informação sobre a fonte|
Legal, então o que acontece agora? Bem, se inspecionarmos o script do parser, vemos que ele obtém charstring_off, private_off e vai para a posição charstring_off e lê mais algumas coisas
Mas como isso nos ajuda a ter uma visão mais ampla? Então vou concluir isso abruptamente. Basicamente, fiz um diff entre 2 arquivos, um cff normal e o cff corrompido.
À esquerda está o arquivo .cff corrompido e à direita está um arquivo .cff normal. Se inspecionarmos o resultado da execução
Na primeira vez em que executamos o parse, vemos que tudo, como count, offsize, offbase, é simplesmente alguns offsets até certos delimitadores. Que delimitadores? Precisamente o nome da fonte. Então, como você pode ver ('offbase', 8L), ou seja, do início do arquivo até a primeira ocorrência da string da fonte presente no arquivo cff
Como também pode ser visto na 'segunda execução do parse'
vemos no offset 0x6c no hexviewr o \x0e\0xe\0xe\x0e início de nossos dados maliciosos
Então, como conclusão, um formato geral do arquivo .cff
|versão principal(1 byte)|versão secundária(1 byte)|tamanho do cabeçalho(1 byte) | absoffsize do cabeçalho(1 bytes) | ABCDEF+fontes no pacote|41 bytes conhecidos|25 bytes de informação sobre a fonte|
E formato de arquivo personalizado (com conteúdo do usuário)
|versão principal(1 byte)|versão secundária(1 byte)|tamanho do cabeçalho(1 byte) | absoffsize do cabeçalho(1 bytes) | ABCDEF+fontes no pacote|41 bytes desconhecidos|25 bytes de informação sobre a fonte| 4 bytes(count) | 4 bytes(offsize) | 9 bytes restantes a serem documentados| conteúdo do usuário|
