 Это перевод с названием Дорога к Созданию Айфона, докладщика Брандон Азад. Эппл представил новую технологию КТРР и Брендон Азад нашел одну дорогу. Он будет представлять, как он смог обойти КТРР и как он смог найти Айфон, в котором можно искать ошибки с помощью дебагора. Приветствуйте его. Спасибо вам большое. Я очень рад здесь быть с вами. И сегодня я хочу вам представить мою дорогу вам, как я построил эту систему и которую я готовил очень долго. Что я имею в виду, как я говорю, Айфон дебагобы? Я хочу вам дать контекст. Я буду говорить о чем-то, о чем не говорят слишком часто в публике. Это Development Used Devices или прототипа Айфона. Это все именно для одного контекста. Это типы Айфонов, которые имеют возможности дополнительного дебагинга. Сейчас очень низким уровнем можно заниматься дебагингом. Например, прямо в bootloader и регистрии менять. И это вещи, которые очень важны для инженеров у Эппла. Но Эппл не хочет, чтобы они были включены в выпущенной версии Айфонов. Чтобы присоединиться к этим устройствам, к этим тулам, нужно специальный тип провода. Это профессиональный провод. Например, Канзи Кэбе. У него специальный коннектор Lightning с одной стороны. И у него есть модуль, который позволяет коммуникацию с Айфоном через дебагинг протокол. И с другой стороны его USB протокол. И этот USB конец можно подключить к лаптопу. И в лаптопе вы можете пользоваться этой программой, например Astris. Это нет софтвера, которая Эппл позволяет всем. Но это код, который не открытый, который Эппл санкционирует, если им пользуешься. Но люди могли добыть этот софтвер. И вот скринчот, как кто-то мог дебаг-проб. И присоединил свой Айфон к этой системе. И вы видели отпечатки регистров. И это очень низкого уровня возможности дебаггинг. Я не пользуюсь deaf-used devices. Я имя не пользуюсь, я не хочу имя пользоваться, чтобы делать мою работу. Но это было бы очень, помогало бы очень сильно, если бы такие возможности были. Вот мой цель. Я хочу построить свои возможности иметь. Мой самодельный телефон разработчика. Я хочу менять код Kernel, код ядра. Я хочу инитировать код. Я хочу стандартные возможности дебаггера, например, ставить точки, остановки. Я хочу пользоваться обычными дебаггерами. Я не хочу пользоваться специальной софтвер, как asterisk. Я хочу, чтобы этот телефон мог быть актуализирован. Я не хочу три месяца заниматься этим. И Apple имеет возможность сделать аптейд. И все станет работать. И я не смогу дебаггером заниматься изыском ошибка. Ошибок. То это не будет помогать. Я хочу еще пользоваться амортизацией этой системы за несколько лет. Есть, например, возможности, которые дают апдейты реальными на устройстве. Последняя вещь, которую я хотел бы сказать, на таком устройстве можно использовать порты, которые производятся напрямую в Apple. Я хотел бы еще упомянуть важную вещь, которая случилась в области безопасности. Несколько дней, когда я открыл код. Этот эксплойт гораздо мощнее, чем возможности, которые существуют в KTRW. Я хочу вам сказать, что вы знали, что много из этих тезисов, которые я оставлю, они уже неправильны. Они были правильны, когда я начал это. И будущие платформы будут пользоваться load exploits. Почему KTRW так важно? Самая первая вещь, которая на моем списке стоит, это исправлять память ядра. Это обычно не слишком сложно. Можно просто ее читать, на многих устройствах можно ее модифицировать. Но на айфоне Apple включила KTRW. И главная мысль в этом, что есть в ядре такое деление каша. И пока система уже исполняется, Apple хочет, чтобы те отделы, которые уже не... Ни которых нельзя писать, чтобы они не были исполнимыми. Вот есть часть, которая не должна быть изменяемая. Но есть часть, которая тоже стоит защищать. Например, есть просто цепочки, есть другие, изменимые, есть целостаницы. И KTRR запирает эту часть память. Как мы знаем, KTRR означает Kernel text only region, то есть часть ядра, которую только можно считать. Это защита чтения исключительного или выполнения. Работает на чипов Apple A10 и позже. Если в цепочке защищенного загружания системы, это включено, то оно работает. Нельзя новый исполнимый код добавлять в систему, а только уже существующий. Как понять, как это работает больше в детали. Вот посмотрим на эту диаграмму, как работает часть вычислительной, часть процессора. Внизу вы видите MMU, самая высшая форма KASHA, это L2, справа от этого AMCC. И это соединено к D-RAM. Вот Kernel живет здесь. И вот это Apple хочет защищать и пользоваться для этого технологии KTRR. Давайте посмотрим на одно ядро вычислительного процессора. Вот части MMU они показывают начало и наконец диаграмма. Если процессор хочет писать на часть, которая не находится в D-RAM, то это будет разрешено системой. Но если система хочет вы внутри этого написать, то KTRR это не будет разрешать. ММУ будет это видеть и сделать так, чтобы эта инструкция не сработала. Если процессор хочет выполнить инструкцию, которая находится снаружи от этого D-RAM, то эта система может это узнать и все равно она не будет работать. Следующее — это не полная картинка всего, что нужно нам знать для того, чтобы защищать эту часть памяти. Вы видите здесь еще отдельные приборы, которые могут соединяться контроллеры, чтобы защищать от их тоже. Мы думаем, что Apple пользуется AMCC, чтобы защищать D-RAM от приборов, которые присоединены к системе. Вот так выглядит система, чтобы поддерживать KTRR. Есть один определенный кейс, если KTRR вступает в режим SNOW. Если в ММУ регистры погружаются в режим SNOW, они теряют свое значение. Если процессор возвращается из SNOW, то эти регистры заполняются снова. Вектор сброса, который исполняется, если процессор возвращается из SNOW. Apple добавил код в этот код восстановления регистров. Начало и конец этой функции этот код находится внутри заблокированного региона. Потом записывает этот код значение регистров туда, где они должны быть, и проверяет их значение. Если память заблокирована на ММУ, теперь у нас в общем есть понятие, как работает KTRR. Теперь можно поговорить, как можно обойти или сломать KTRR. Две исторические вещи для слома. Впервые эта уязвимость была найдена Лука Тадеско. Он заметил, что Apple оставил... часть кода, которой был не исполняемым, но внутри. И этот код находился в этом регистре TTBR1L1. Это означает, что если вы можете изменить значение этих регистров, тогда память будет замепт на другие новые регионы. И в виртуальная память будет находиться в другой области. KTRR в этом случае полностью работа способна. Мы не можем изменить конкретные данные, но мы можем изменить область памяти. И таким образом можно изменить KTRR в полной области, только на частичной области. Второй возможный обход KTRR в теории, скорее чем на практике. В операционной системе версии 11.1.2 способ дебага был имплементирован напрямую в процессор Apple. Если вы считаете архитектуру RAM и просмотрите архитектуру ARM онлайн, и считаете значение регистров, дебага, вы можете использовать эти значения, чтобы имплементировать exceptions. И это примерно то же самое, что использование дебагера на Macbook. Регистры дебаггера, которые один может использовать, они все равно еще функциональны. Он выяснил это, он построил что-то, что работает с LOLDB, доказал, что это работает и может изменять регистры в любом порядке. Он не может execution нам заниматься, но почти. Как можно противим MacTRR? Я искал места, которые работают в нескольких версиях. Я искал в iBootback, парсинге, там ничего не нашел. Потом я прочитал в процессоре ARM, там ничего не нашел. Потом я еще искал в cache L2, если там возможности. Я немножко не понял, как к iTRR работает, я думал, есть дорога, чтобы испортить cache. Я пытался несколько вещей делать, но это не работал и поэтому я это не очень отставил. После этого я сделал что-то совсем что-то другое. Я играл с интераптами и я смог бесконечный цикл создать. При этом процессор один не отвечал уже, и система не показала. Но что действительно поймало мое внимание, это паника попытки принудительной остановки процессора 1. Нету MSR. Вот я думал, что есть еще какой-то частный интерфейс и специальный регистр контроля, который только может пользоваться через этой системой защиты. И я что-то совсем новое пытался сделать. Я хотел выяснить, что тут происходит. Я достал код, исходный CPU, и я нашел эту функцию DbWrap RALT CPU. И он берет индекс процессора, который должен быть остановлен. И часть, которая действительно останавливает процессор, и работает так. Функция считает биритм-понтер, по названию DbWrap RALT, и она берет. И это, похоже на то, что это специальный какой-то регистр imim.io. И это, наверное, какой-то частный интерфейс Apple. Вот еще одна вещь, которую очень интересно мне показалось. Это CoreSight. Что это такое? Потом вернемся к этому. Что это? MLDB RAP RALT CPU with state. Это делает фактически то, что в та функция, которую мы только что посмотрели, но, кроме этого, она еще читает данные регистра. И как она делает? Это вообще-то очень удивительно. Вот вы видите. Вот вы видите, что регистры могут быть прописаны. Но самая интересная часть, это вот эта. Она в начале берет код операции. И берет. Это и записывает в DbWrap. Следующая ступень, это ее берет и записывает DbWrap. И потом читает ее оттуда. И ее записывает бафер XI. Это очень интересно, потому что MLDB DbWrap Instruction как-то выполняет динамические генерированные инструкции. И это показывает нам как KTR. Аналогию, как KTR. Работает. Но здесь вы видите, что может любой код исполняться. Это очень интересно. Этот код выполняет то, что одно, сделать это в теории, а другое, делать практику. Я написал пару вещей вместе, чтобы увидеть, что внутри этого буфера. Что я нашел, чтоégись сюда, чтобы увидеть, что внутри этого буфера, что я нашел, что в этом буфере были значения регистров, значения CPSR-регистра, указывало на то, что режим ядра активирован. PC было выглядело как вектор сброса. Может быть, это похоже на физический адрес? Очень быстро я заметил, что этот адрес вектор сброса. Нам удалось загрузить вектор сброса, когда он находился в режиме ядра. До того момента, как ММЮ загружен, ядро не защищено. Следующий вопрос был, как мы можем использовать это, чтобы обойти ки террор? Вопрос, который надо ответить до этого, что делает CoreSight. У меня не было идеи, что вообще делает эта функция. Я нашел онлайн ссылки на CoreSight в контексте внешнего интерфейса отладки. На самом деле, оказалось, что это способ всех функций, которые используют дебаг инструкции MSR. CoreSight предлагает почти все те же самые функции для этой отладки. И важная деталь, что интерфейс MMIO, они другие части hardware, в этой части встроены основные элементы для дебага. Это даже не первый раз, когда люди пробовали использовать регистры, чтобы получить высший уровень ядра. В 2019 году эти регистры были использованы на андроидах, чтобы сбросить безопасность, обойти безопасность. Чтобы одно ядро могло запустить код другого ядра. Можно немножко обобщить. Архитектура для отладки на чипе. Достоп через MMIO, регистров отладки, хорошо документированный руководство процессора ARM Перси 8. Можно устанавливать бейкпоинты, бейкпоинты, исполнять инструкции, и виртуальная память, регистров дебага, использованная Ян Биром, чтобы создать собственное ядро, которое можно отлаживать. Идея, которую я решил использовать внешний дебагинг, чтобы пользоваться этим, чтобы KTRR никогда не был включен. Вот, мы ступенчат, исполняем все эти инструкции, потом мы делаем почти все шаги до инициализации, а потом перепрыгиваем эту часть. Это интересная идея, но у нас нет, к сожалению, все инструменты, которые можем использовать. Мы знаем, что мы можем любые инструкции исполнять, но у нас нет возможности потом снова восстановить исполнение после остановки. Потом еще есть одна проблема, немножко интереснее. Мы используем процессором, чтобы по другой процессоре сбросить, но нам нужно это делать каждый раз, когда ядро почти каждый раз. Я не знал, как делать эти вещи, поэтому я только подумал, немножко поиграться с этим частным регистром, который я нашел раньше. Source Code немножечко объясняет это, но несколько битов не объясняет. Просто поиграться, посмотреть, что происходит. И я не смеюсь, только из-за чистой удачи я смог выяснить. Бит 3 сбрасывает, а бит 26 держит включенным ядро. И атака, которую мы раньше объясняли, работает оптимально, после того, как мы нашли эту возможность. КТРА не включается, и мы перепрыгиваем эту часть. КТРА каждый код кернала может быть выполнено. Спасибо. Мы нашли способ обойти КТРА. Давайте поговорим о том, как создать дебагер, который может все это сделать. Много способов, на самом деле, для этого я хочу обсудить следующее. Первое, надо изменить адреса ядра. Необходимо загрузить память. Необходимо... Необходимо правильно организовать задержки. Необходимо организовать коммуникацию между каналами. Когда мы обходим КТРА и выполняем ShellCode, даже когда мы деактивировали КТРА в процессорах, он еще активирован в модуле AMCC. Память страницы, которые физически внутри памяти их нельзя изменить. Нам необходимо изменить таблицу памяти ядра. Для того, чтобы разрешения кекста разрешили нам сделать память исполняемой. Основные страницы, root pages, таблицы, сохранены в регионе КТРАР. Регистр TTIBR и Latin указывает на заблокированный режим памяти. И мы хотим изменить, чтобы он указывал на другой адрес. Новую таблицу памяти. И тогда у нас будет возможность изменить ядро. Загрузка и в результате загрузить расширение ядра. Необходимо получить память ядра для кекста, копировать двоечную версию кекста, динамично перекомпелировать, связать символы ядра. И сейчас можно начать создавать ядро. Монитор, ядро-монитор зарезервированная для КТРВ. Другие ядра, которые работают в нормальном режиме, брейкпоенты, которые вводят ядро в режим hold и включают режим отладки. И ядро-монитор опрашивает команды дебага и перенаправляет их. Странные ошибки ядра, например, ау-пей-паник, нет ядра. Ау-пей-остановки, проблема один. Процессор, который всегда включен, посылает сигналы, задержки, AP на IP, которые должны быть обработаны, или, в другом случае, ау-пей-паник входит в режим паники. Watchdog timer может быть деактивирован, reverse-engineering, файла, кекста, модуля ядра, Apple S5. И я не смог найти путь выключения других прерываний. Первый хак — системные прерывания на ядре-монитора. Большой хак. Следующая проблема, которая возникла, Deadlock на IRQ, прерываний. Исполнение на ядре-монитора могло использовать jump на IRQ handler в тот момент, когда ядро в режиме дабага остановлено и приводило к критическому задержке IRQ, так называемый спинлок. Второй хак — только ядро, которое в режиме hold, если прерывания включены, и IRQ находится не в критическом регионе. Это достаточно просто проверить, что ядро находится ли ядро пришими дабага, находится ли IRQ в критическом регионе. И тогда все проблемы IRQ пропадут. Сейчас нам необходимо обходиться с ядром, и следующая проблема — как мы можем подключиться к ядру. Последовательный порт, достаточно быстро, USB, быстро, Wi-Fi как опция доступна. Негативные части были для последовательного порта. Необходимо определённое hardware, чтобы доставить коммуникацию между устройством и iPhone. USB — специальный USB стек, и для Wi-Fi необходимо было написать определенный custom driver. Важно, что если мне захочется установить breakpoint, то мой дабагер должен коммуницировать с дабагером, который внутри MMU. И для этого необходимо имплементировать hardware driver. Я выбрал USB, потому что это было проще. Контроллер USB на использованный на iPhone называется Designerware HighSpeed USB 2.0 on the go. Это частные интерфейсы, и они не используют open source hardware. Я попробовал поискать и сойти этот веб-сайт специального driver и я не нашёл драйвера, но я нашёл один драйвер похожий. Это было не то, что я хотел идти, но там можно было посмотреть описание регистров. Полная имплементация, имплементирование hardware использованного на iPhone. Самая первая часть, которая включается в iPhone, она нуждается в this and that. Я Apple's secure ROM включал и её разобрал и разобрал часть стека USB и заново её заимплементировал. Это было достаточно тяжело и тянулось, но в конечном итоге я мог включить мой пас и его записывать как легитимный Apple. Единственная часть, которую ещё осталось нам сделать, это часть GDB. Это достаточно легко, сравнительно с другими частями. Только нужно несколько частей прочитать и их протянуть. И после того, как это было сделано, я мог заниматься дебагом через USB без специальных драйверов или ещё чего-то. Вот, я сделаю одну, я надеюсь, очень быструю демонстрацию, как пользоваться этим дебагом. Вот у меня iPhone, который вы можете видеть здесь, сейчас вы можете видеть на лаптопе, но как только я буду включать дебагер, не будет видно эта часть. Что я могу сделать, это включить эту программу, которая будет включать эту часть. И после этого я включаю LLDB и LLDB за... Мы после этого можем продолжить XA-спекуцию. И вы можете, что прибор всё ещё отвечает, можно пользоваться программами, апами, и всё. И после этого я сделаю точку. И вот у меня программа на Прегоры, и она будет вызывать Минкор с определёнными аргументами, и есть возможность включать девайс, но для этой демонстрации я проустановленную программу буду вызывать. И это это останавливает iPhone. Мы можем сейчас заниматься дебагером. Мы можем смотреть, что в регистрах. И мы видим аргументы, которые включены там. Мы можем пользоваться всеми возможностями дебагера стандартного. Вот мы будем смотреть на точку. Будем ставить Watchpoint. И мы видим что-то, что что Breakpoint. Можем Watchpoint после этого снова выключить, и после этого после этого мобильник становится снова пользоваем мы. И вы видите все возможности дебагера. Спасибо большое. Вот source code можно в Google Zero Project Zero можно посмотреть. Это очень-очень веселый проект был. И я хотел облегчить немножко дебагинг iPhone. Спасибо вам. Пять минут для вопросов. Пожалуйста, подойдите к микрофонам. 3-4-5. Возможно ангелы сигнала найдут вопросы. Микрофон один. Спасибо за представление. Все, что вы сделали можно сделать этим дебагером. Как вы видите проблемы безопасности. Например, если iPhone расблокирует дебагинг вы имеете в виду бурам, баг или все. Все вместе. Я точно не уверен. Это не моя область исследований. Можно ли вы их использовать уязвимости? Некоторые можно использовать для удаленной атаки, для ресета процессора. И в любом случае полное устройство в руках такера. Третий микрофон. Посмотрели ли вы в DriverLinux? Да. Когда я полностью имплементировал USBStack проблема, по которой я не смог найти OpenSource имплементирование, было, что я искал на другие вещи. И имя дебагера USBStack было другим у Apple. Интересный доклад. Мой вопрос не вопрос, а комментарий. Первый раз в первые когда это было доступно в публике. И это эти уязвимости находятся люди используют их и находят их. Сначала к вашему комментарию. Все, что я сделал в этом проекте полностью моя работа. Почти все работа других людей, основано на работе других людей. Первый раз, когда я увидел iBoot и StackCode я не готов работать с этой StackCode. Большие аплодисменты.