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

Погружаемся в шрифт CFF и попутно узнаём о bof в разборе cff из какого-то джейлбрейка. просто ради интереса

Итак.... что такое CFF? Насколько я знаю, это файловый формат, но давайте попробуем понять, что говорит Википедия: «CFF выступает в роли контейнера для хранения нескольких шрифтов вместе в едином блоке, известном как FontSet». (https://docs.fileformat.com/font/cff/) так что в основном мы можем хранить шрифты вместе. круто, и что дальше? что ж, раз это файловый формат, у него должна быть какая-то спецификация, и да, она есть, и нет, она не очень, потому что в ней 60 страниц, и я не готов изучать её формат. Но мы можем использовать эксплойт из github-репозитория star-master (исходный код джейлбрейка 2.0, по-моему), чтобы изучить её формат.

Итак... Мы начнём с использования скрипта cff.py, предоставленного автором, а также откроем файл out.cff (стандартный простой .cff файл) в hxd-редакторе.

Мы видим, что когда мы передаём файл в парсер, мы получаем следующее

Итак, мы уже кое-чего добились, так как уже можем дать определение для cff: мы можем прийти к выводу, что у нас есть некие метаданные о его заголовке, которые, как я предполагаю, указывают версии tff, размер заголовка и absoffsize, что бы это ни было.

Итак, на данный момент |старшая версия (1 байт)|младшая версия (1 байт)|размер заголовка (1 байт) | header absoffsize (1 байт) |

Затем мы идём дальше, и у нас есть функция, которая получает, какие шрифты используются в этом .cff файле. Как показано

Итак, откуда мы знаем, что её назначение — читать, какие шрифты используются? Что ж, при запуске инструмента мы получили следующий результат в cmd

которые, как мы видим, являются следующими байтами после метаданных файла

Вернёмся к анализу этой функции позже, но пока мы можем сделать вывод, что формат файла такой: |старшая версия (1 байт)|младшая версия (1 байт)|размер заголовка (1 байт) | header absoffsize (1 байт) | ABCDEF+шрифты в пакете|

Далее мы видим, что ищем то, что в скрипте называется string:

Почему? Потому что я полагаю, что они хотят собрать информацию о шрифте, используемом в пакете. Из доков они говорят: «Все строки, за исключением строк FontName и CIDFontName, которые появляются в Name INDEX, используемые разными шрифтами внутри FontSet, собираются вместе в структуру INDEX и ссылаются на 2-байтовое беззнаковое число, называемое строковым идентификатором или SID. Эти строки, известные как стандартные строки, описывают все имена, используемые в наборах символов ISOAdobe и Expert». В любом случае, здесь интересно отметить, что мы пропустили примерно 41 байт, чтобы добраться до строки.

затем мы получаем информацию о шрифтах, присутствующих в .cff файле

Как, чёрт возьми, мы это делаем? Что ж, мы собираем так называемые данные top dict. Что это такое? Из того, что я смог понять из документации, это python-словарь с определённой информацией, закодированной определённым образом.

По совпадению, если мы проследуем алгоритму декодирования:

мы разыменовываем тип данных strings, чтобы получить информацию о шрифте, поэтому мы приходим к выводу, что topdicts просто содержит некие индексы, которые позже используются в типе данных strings для получения информации о шрифте

Итак, до сих пор определение файла остаётся в силе: |старшая версия (1 байт)|младшая версия (1 байт)|размер заголовка (1 байт) | header absoffsize (1 байт) | ABCDEF+шрифты в пакете|41 известный байт|25 байт информации о шрифте|

Круто, так что же происходит дальше?

Что ж, если мы изучим скрипт парсера, мы увидим, что он получает charstring_off, private_off и переходит к позиции charstring_off и читает ещё кое-что.

Но как это помогает нам увидеть общую картину? Так что я резко завершу это. По сути, я сделал diff между двумя файлами: один обычный cff, другой повреждённый cff.

Слева повреждённый .cff файл, а справа обычный .cff файл. Если мы посмотрим на результат выполнения

При первом запуске парсера мы видим, что всё, такое как count, offsize, offbase, — это просто некие смещения до неких разделителей. Каких разделителей? Именно имени шрифта. Как вы можете видеть ('offbase', 8L), то есть от начала файла до первой встречи строки шрифта, присутствующего в cff файле.

Как также можно увидеть во «втором запуске парсера»

мы видим на смещении 0x6c в hex-просмотрщике \x0e\0xe\0xe\x0e — начало наших вредоносных данных

Итак, в качестве вывода, общий формат .cff файла: |старшая версия (1 байт)|младшая версия (1 байт)|размер заголовка (1 байт) | header absoffsize (1 байт) | ABCDEF+шрифты в пакете|41 известный байт|25 байт информации о шрифте|

И пользовательский формат файла (с пользовательским содержимым) |старшая версия (1 байт)|младшая версия (1 байт)|размер заголовка (1 байт) | header absoffsize (1 байт) | ABCDEF+шрифты в пакете|41 неизвестный байт|25 байт информации о шрифте| 4 байта (count) | 4 байта (offsize) | 9 байт, которые ещё предстоит задокументировать| пользовательское содержимое|