Получаване на JTAG при iPhone 15
Оригиналът е на stacksmashing
Даниел Десподов преди 31 секунди 2 СподелиНай-четени
IT НовиниДаниел Маринов - 21:05 | 08.10.2023Какво съставлява израелската противоракетна система „ Железен купол “
АвтомобилиДаниел Маринов - 21:20 | 08.10.20235 неща, които би трябвало да спрете да вършиме, в случай че карате кола с ръчна скоростна кутия
ХардуерДаниел Маринов - 20:03 | 08.10.2023Русия ще употребява неразрешените графични процесори Nvidia H100 за построяването на доста мощни суперкомпютри
Даниел Десподовhttps://www.kaldata.com/Новинар. Увличам се от модерни технологии, осведомителна сигурност, спорт, просвета и изкуствен интелект.Преди месец Apple показа iPhone 15 – своя първи смарт телефон с USB-C конектор. От година и половина се занимавам с хардуерно хакерство за iPhone, като да вземем за пример разработихме адаптер за сериен JTAG за iPhone, наименуван Tamarin Cable. Компанията Apple най-сетне мина към USB-C, тъй че ми беше любопитно дали нещо сходно може да се направи и с iPhone 15. Предварително поръчах този телефон, няколко платки и комплект електронни съставни елементи.
Преди всичко би трябвало да се каже, че това не е накърнимост или джейлбрейк, просто проучвам USB-C в iPhone 15 и се развличам с хакването на хардуера.
Но дано да стартираме през цялото време. Какво тъкмо съставлява JTAG? Методът JTAG в началото е създаден през 80-те години на предишния век за тестване на печатните платки и тяхната целостност благодарение на интерфейса boundary scan. Но през днешния ден под JTAG нормално се схваща интерфейс за дебъгване на процесори на ниско равнище. JTAG може да се употребява за достъп до паметта, прекъсване на процесора, постъпково осъществяване на командите и така нататък в самото начало на процеса на пускане, даже преди операционната система да се задейства със софтуерен дебъгер. SWD, или Serial Wire Debug, всъщност е различен електрически интерфейс към JTAG, основан от Arm. Оригиналният JTAG изисква най-малко четири извода, до момента в който SWD се нуждае единствено от два.
И по този начин, дано преминем към iPhone 15. iPhone с конектор Lightning имаше чип Tristar, който позволяваше да превключвате щифтовете на конектора в разнообразни режими, като изпращате нужните байтове посредством SDQ протокол. Беше допустимо да превключите iPhone в режими Serial, JTAG или USB. Като се има поради броят на наличните пинове на USB-C, си помислих, че Apple евентуално е направила нещо сходно с iPhone 15. Заслужава да се означи също, че новият iPhone не е първото USB-C устройство на Apple, да вземем за пример MacBook Pro с M1 и iPad Pro към този момент имаха USB-C. Когато започнах да диря информация за тях, открих, че екипът от 2019 година T8012 е проучвал USB-C в MacBook Pro и е открил, че в MacBook Pro с чипа за сигурност T2 единият от USB-C конекторите може да бъде мултиплексиран в два разнообразни режима. Един от членовете на екипа на T8012 съумя да смъкна фърмуера на чипа ACE, виновен за това; посредством противоположното инженерство на фърмуера той откри, че Apple употребява функционалност на USB-C, която се споделя VDM (Vendor Defined Messages).
VDM разрешава случайна връзка по линиите CC (Channel Configuration) на конектора USB-C. Тези линии нормално се употребяват за ориентировка и подаване на зареждане, само че могат да се употребяват и за случайни връзки. Чрез назад инженерство стана ясно, че благодарение на командите на VDM е допустимо да се превключва режимът на обособените контакти на USB-C конектора, да вземем за пример в сериен режим.
Проектът Asahi Linux разполага с превъзходен инструмент, наименуван macvdmtool. Той дава опция за потребление на ACE чипа в един MacBook за връзка с ACE чипа в различен MacBook. Това ви разрешава да изпращате известия, дефинирани от доставчика, и да вземем за пример да получавате Serial Boot Lock непосредствено в MacBook
Разговарях с teamstar и той сподели, че това работи даже на неговия iPad Pro с USB-C, тъй че VDM наподобява като превъзходен метод да получите JTAG на iPhone 15. Като направих още няколко изследвания, открих страхотната платка Central Scrutinizer, основана на инструмента vdmtool на плана Asahi Linux. По създание това е реализация на macvdmtool, основана на Raspberry Pi Pico, тъй че може да се употребява за изпращане на случайни VDM известия. След като изучих архитектурата на оптичния датчик на този хардуер, взех решение да купя няколко подготвени печатни платки без съставни елементи и да конфигурирам единствено тези, които ще ми трябват за връзка с iPhone. Поставих FUSB302 – програмируем USB-C контролер, някои схеми за промяна на равнището, пасивни съставни елементи (кондензатори и резистори) и ги запоих на гърба на Raspberry Pi Pico.
След това изпробвах това устройство с Mac M1 и то работеше. Успях да рестартирам Mac-а, да го превключа в режим DFU и даже да прегледам връзките през серийния конектор благодарение на логичен анализатор.
След това изпробвах работата на Central Scrutinizer с iPhone 15. Свързах платката към телефона и следих интензивността в блокировката, само че нищо не се получи. Не можех да рестартирам iPhone и липсваха доста от известията, маркиращи триумфа на MacBook. Дойде време да мина към дебъгване. Първо желаех да видя дали методологията VDM въобще може да работи, по тази причина тествах инструмента macvdmtool с iPhone 15. Той работеше, можех да рестартирам телефона и даже да получа достъп до серийната подпора, което значи, че методологията като цяло работи, единствено че към момента не с Central Scrutinizer. Опитах се да проучвам логиката на USB PD. Една от мислите ми беше, че когато включа iPhone към Mac, той стартира да се зарежда, само че не и когато го включа към Central Scrutinizer. Също по този начин забелязах, че във фърмуера на Central Scrutinizer конфигурацията Power Delivery е настроена на 0 милиампера, тъй че устройството не може да подава сила.
Реших да ревизира захранващата линия VBUS с осцилоскоп. Оказа се, че когато iPhone не е включен, тази линия поддържа до 5 V, само че когато iPhone е включен, VBUS се колебае малко, а по-късно се задържа на 2,5 V, макар че би трябвало да има 5 V. Помислих, че това е казусът, по тази причина започнах да мисля по какъв начин да го реша. За благополучие решението беше открито в чекмеджето ми с съставни елементи. R5524 е комутатор за USB зареждане, който разрешава подаване на зареждане към USB конектора. Благодарение на дребен хак с магнитен проводник сътворих своя трансформация. Също по този начин поправих цената на Power Delivery във фърмуера, като я зададох на случайна стойност, с цел да покажа, че поддържаме подаването на сила.
И по този начин, настъпи моментът на истината. Включих iPhone и всичко стартира да работи! Получават се същите известия в логовете като в тази ситуация с MacBook, а когато изпратим команда за рестартиране с Central Scrutiniser, iPhone се рестартира. Нещо повече, в логическия анализатор, обвързван към изводите на SPU, виждаме boot lock. Страхотно! Central Scrutinizer работи с iPhone. Но към момента нямаме JTAG.
И по този начин, по какъв начин да вкараме JTAG в iPhone, а освен серийна връзка? В хода на моето изследване попаднах на страницата с хардуерната документи на Asahi Linux. Авторите са създали реверсивно инженерство на другите дейности, които могат да се изпращат посредством VDM. Например, те изпращат командата 306, с цел да се получи серийна подпора или UART подпора. В края на страницата обаче имаше забавна тестова записка:
„ Има огромна възможност да е SWD “ е тъкмо това, което се търси. Затова потърсих командата 306 в базата с кодове на Central Scrutinizer и открих този ред, в който просто замених 306 с 206.
Но с цел да ревизира дали това ще работи, ми беше нужна малко по-сложна скица. Според документите изводите имат напрежение 1,2 V, тъй че ми трябваше референтно напрежение за дебъгъра. Запоих дребен куплунг, който ми даваше маса и 1,2 V от една от схемите за смяна на равнището. По създание проектът ми беше да изпратя известие VDM 206 до iPhone посредством Central Scrutinizer. Надявах се, че по този метод ще преконфигурирам двата SBU извода на USB-C, с цел да осигуря SWD („ JTAG “ интерфейс с два извода), след което ще мога просто да включа SWD дебъгер в изводния конектор на Central Scrutinizer и при шанс да се свържа посредством JTAG.
Ето по какъв начин наподобява приключената тестова скица с дебъгер, Central Scrutinizer и iPhone:
Свързах и осцилоскоп към SBU изводите, с цел да мога да следя какво се случва по сигналните линии. Опитах се да се свържа с дебъгъра, имаше някаква интензивност на осцилоскопа, само че за жалост дебъгерът даваше единствено неточности, като че ли нищо не беше обвързвано. Но почакайте: бях свързал двата извода, нужни за SWD, само че какво ще стане, в случай че инцидентно съм ги свързал неправилно? Имаше 50/50 възможност това да се случи. Затова просто размених кабелите и пробвах още веднъж. Още нещо: изходът в този момент наподобява напълно друго, споделя, че е намерил врата за дебъгване на нулевия проводник:
И даже може да се прочете ID регистъра на врата за премахване на неточности. Така че въпреки всичко получихме SWD в iPhone 15. Въпреки това виждаме някои неточности, не може да откри AP или врата за достъп до дебъгване. И това е предстоящо: създаваните в комерсиалната мрежа iPhone просто не могат да се дебъгват без експлойт, да вземем за пример, с цел да дебъгваме iPhone X с Tamarin, ще ни е нужен експлойтът BootROM Checkmate. Така че, макар че JTAG работи, няма да можем да дебъгваме процесора. Въпреки това, даже и при iPhone 15 в бъдеще ще можем да изследваме доста забавни неща със SWD.
Проектът Central Scrutinizer ми хареса.
