usbliter8: l’exploit USB que Apple no pot corregir als iPhone amb A12 i A13
Billy Ellis explica usbliter8, una vulnerabilitat de la controladora USB i la configuració DART dels xips Apple A12 i A13. Un microcontrolador envia paquets USB incomplets, provoca una escriptura fora de límits i aconsegueix executar codi a la Boot ROM, però l’atac exigeix accés físic, mode DFU i maquinari especialitzat.
Un petit microcontrolador connectat per USB pot executar codi a la primera etapa d’arrencada d’alguns iPhone amb xips A12 i A13. L’exploit es diu usbliter8 i aprofita una combinació poc habitual: una controladora que accepta paquets USB incomplets i una protecció de memòria configurada en mode de pas directe.
La fallada és dins d’una cadena que no es pot substituir amb una actualització normal. Per això es descriu com a «incorregible». Però el titular necessita context: no és un atac remot, no afecta els iPhone 12 o posteriors i no desxifra automàticament les dades de l’usuari.
Billy Ellis recorre la investigació publicada pel grup Paradigm Shift, des del paquet USB de quatre bytes fins al codi que deixa el telèfon en un estat DFU controlat.
Què és la Boot ROM
Quan s’encén un iPhone, el primer codi que s’executa és la Boot ROM, anomenada també SecureROM en aquest context. Apple la grava durant la fabricació del sistema en xip i la defineix com l’arrel de confiança del procés d’arrencada segura.
La seva feina inclou:
- inicialitzar parts bàsiques del processador i la memòria;
- comprovar la signatura de la següent etapa;
- carregar un bootloader autoritzat;
- iniciar una cadena en què cada component verifica el següent.
Si una persona aconsegueix executar codi dins de la Boot ROM, pot alterar aquesta cadena abans que iOS comenci. Pot carregar un iBoot modificat, desactivar comprovacions en memòria i construir un entorn de recerca molt més privilegiat que el que proporciona una vulnerabilitat d’una aplicació.
La contrapartida és que la Boot ROM és immutable. El mateix disseny que impedeix que el programari maliciós la reescrigui impedeix que Apple substitueixi el codi defectuós amb una actualització. La correcció definitiva requereix una revisió de silici.
Quins dispositius afecta
El projecte públic implementa l’explotació per a:
- Apple A12;
- Apple A13;
- Apple S4 i S5 d’Apple Watch i altres dispositius.
En telèfons, això inclou principalment la família iPhone XS/XR i la família iPhone 11, a més de l’iPhone SE de segona generació amb A13. El codi publicat no ofereix el mateix suport per a totes les variants A12X i A12Z.
Els iPhone amb A14 o posterior, començant per la família iPhone 12, no són explotables amb aquesta tècnica perquè la protecció DART està configurada de manera diferent. El vídeo simplifica el llistat a A12 i A13 perquè se centra en l’iPhone.
Per què cal un microcontrolador especial
L’atac s’executa mentre el dispositiu està en mode DFU, el mecanisme de recuperació de baix nivell. El telèfon es connecta a una placa basada en un Raspberry Pi Pico o un microcontrolador semblant amb microprogramari específic.
No n’hi ha prou amb un programa convencional en un Mac o PC. La especificació USB estableix que un paquet de configuració o setup packet ha de tenir exactament vuit bytes. Els controladors i les API normals obliguen a transmetre paquets vàlids.
usbliter8 necessita fer una cosa deliberadament incorrecta: enviar paquets de només quatre bytes. Per aconseguir-ho, el microcontrolador genera el protocol a un nivell més baix, amb control directe sobre els senyals.
Aquest requisit limita molt el risc quotidià. Una web, una aplicació o un carregador corrent no poden reproduir l’exploit. Cal:
- tenir el dispositiu físicament;
- introduir-lo en DFU;
- connectar el maquinari preparat;
- executar el microprogramari i la cadena adequats al xip.
L’error dels tres paquets i els 24 bytes
La controladora USB reserva una zona DMA per rebre fins a tres paquets de configuració. Cada vegada que n’arriba un, un registre avança tants bytes com contingui el paquet.
En el funcionament normal:
- arriba un paquet de 8 bytes;
- el punter avança 8;
- arriba el segon i avança fins a 16;
- arriba el tercer i avança fins a 24;
- en reiniciar el cicle, la controladora resta 24 i torna al principi.
El problema és que la resta és fixa. La controladora assumeix que sempre ha rebut 3 × 8 bytes, però no comprova que sigui així.
Si l’atacant envia tres paquets de quatre bytes, el punter només avança 12. Quan el maquinari en resta 24, queda situat 12 bytes abans de l’inici del búfer.
El paquet següent s’escriu en una zona que no li correspon. Repetint el cicle, l’atac pot desplaçar l’adreça cap enrere i corrompre dades concretes de la SRAM. És un buffer underflow: l’escriptura surt pel costat inferior de la zona reservada.
Per què una escriptura de la controladora arriba a memòria sensible
Els perifèrics que utilitzen DMA no haurien de poder escriure a qualsevol adreça física. Apple disposa d’un mecanisme anomenat DART, comparable a una IOMMU, que tradueix i limita les adreces accessibles per cada dispositiu.
En els A12 i A13, la configuració utilitzada durant aquesta fase d’arrencada deixa el DART de l’USB en mode bypass. La controladora no queda confinada al seu búfer i l’escriptura fora de límits pot arribar a altres parts de la SRAM.
En xips posteriors, la protecció està configurada de manera que bloqueja aquest camí. La controladora podria conservar un comportament similar amb els paquets curts, però la fallada ja no es transforma en una escriptura arbitrària útil.
La vulnerabilitat explotable, doncs, no és una sola línia defectuosa: és la composició de l’error de comptatge i una barrera de memòria desactivada.
A12: sobreescriure l’adreça de retorn
En l’A12, la zona situada abans del búfer DMA conté part de la pila de la tasca USB. L’exploit repeteix les transaccions fins a arribar a una adreça de retorn guardada.
En sobreescriure-la, controla el comptador de programa quan el planificador torna a executar la tasca. A partir d’aquí utilitza una cadena curta de fragments de codi existent, o ROP chain, per canviar la pila i saltar a un payload més complet.
La tècnica és potent perquè ocorre abans del kernel d’iOS. No cal encadenar una vulnerabilitat de navegador, una escalada de privilegis i una evasió del sandbox: el control comença a l’arrel de l’arrencada.
A13: esquivar l’autenticació de punters
L’A13 activa a la Boot ROM els codis d’autenticació de punters, coneguts com a PAC. Una adreça de retorn modificada sense una signatura vàlida no es pot utilitzar directament.
Paradigm Shift construeix una ruta diferent:
- força la SecureROM a entrar en un estat de pànic;
- modifica el comptador de pànic perquè el dispositiu no es reiniciï;
- conserva actives les interrupcions;
- sobreescriu una taula de gestors d’interrupció USB;
- provoca una interrupció que crida un punter controlat.
Aquest camí evita dependre de l’adreça de retorn protegida. Un cop aconsegueix executar codi, el payload instal·la un gestor USB propi i torna al bucle DFU.
La diferència entre A12 i A13 mostra per què «el mateix bug» no equival al mateix exploit. Les mitigacions no eliminen necessàriament l’error de memòria, però obliguen a trobar una ruta més complexa fins al control del programa.
Què permet el codi publicat
La prova de concepte deixa el dispositiu en un estat conegut com a pwned DFU. A partir d’aquí, una eina de Python pot enviar dues ordres principals.
La primera modifica en memòria el valor que representa el mode de producció del xip i el presenta com un dispositiu de desenvolupament. No canvia físicament els fusibles; altera la còpia utilitzada en aquella arrencada.
La segona carrega una imatge iBoot personalitzada amb les comprovacions de signatura omeses. Un investigador pot extreure iBoot d’un fitxer IPSW, modificar-lo i provar-lo al dispositiu.
El procés és lligat: cal repetir l’exploit després de reiniciar. La prova pública tampoc és un jailbreak complet d’ús quotidià. Proporciona la base perquè altres projectes desenvolupin entorns de depuració, arrencades personalitzades o eines forenses.
Per què no dona automàticament accés a les dades
Controlar la Boot ROM del processador principal no elimina totes les barreres. Les claus vinculades al dispositiu i moltes operacions sensibles depenen del Secure Enclave, un subsistema separat amb el seu propi processador, memòria protegida i cadena d’arrencada.
usbliter8 no compromet directament el Secure Enclave. El codi de bloqueig i els mecanismes de retard tampoc desapareixen simplement perquè es carregui un kernel modificat.
El nou nivell d’accés pot ajudar a investigar interfícies, descobrir vulnerabilitats addicionals o construir eines forenses més avançades. Però és incorrecte convertir «execució a la Boot ROM» en «qualsevol lladre pot llegir totes les fotos».
La diferència és essencial:
- la cadena d’arrencada del processador principal queda compromesa;
- la protecció criptogràfica de dades conserva capes independents;
- calen més vulnerabilitats o credencials per arribar al contingut protegit.
Quin risc té una persona usuària
Per a la majoria de propietaris, el risc immediat és baix perquè l’atac és físic, tècnic i específic de models antics. Mantenir iOS actualitzat continua sent útil: les actualitzacions poden reforçar les capes posteriors encara que no reescriguin la Boot ROM.
Les persones amb un perfil d’amenaça elevat —periodistes, activistes, responsables d’informació sensible o objectius d’una investigació sofisticada— han de considerar que un A12 o A13 confiscat pot oferir noves possibilitats forenses.
Les mesures pràctiques són:
- utilitzar un codi llarg i únic;
- mantenir el sistema al dia;
- no deixar el dispositiu desbloquejat o sense vigilància;
- migrar a un model amb A14 o posterior si l’amenaça física és rellevant;
- esborrar de manera segura els dispositius abans de cedir-los.
No cal llençar automàticament un iPhone 11 que continua tenint un ús normal. La decisió depèn del valor de les dades i de la probabilitat que un adversari obtingui físicament el telèfon.
«Apple no pot arreglar-ho» no vol dir «Apple no pot fer res»
Apple no pot modificar la lògica gravada en els A12 i A13. Sí que pot:
- reforçar iBoot, el kernel i el Secure Enclave;
- detectar estats anòmals en fases posteriors;
- reduir el valor d’una cadena d’explotació;
- corregir vulnerabilitats complementàries;
- incorporar la protecció adequada en xips nous.
La mateixa investigació indica que A14 ja tanca la via principal mitjançant la configuració DART. La solució de maquinari existeix, només no es pot retroaplicar als xips fabricats.
Conclusions
usbliter8 és important perquè trenca una arrel de confiança que feia anys que no tenia un exploit públic comparable en generacions posteriors a l’A11. La idea central és elegant: tres paquets USB massa curts fan avançar un punter 12 bytes, el reinici en resta 24 i la controladora acaba escrivint abans del búfer.
La configuració DART converteix aquell error en accés a SRAM; les tècniques diferents per a A12 i A13 el converteixen en execució de codi; un gestor USB personalitzat el converteix en una plataforma de recerca.
És incorregible a la Boot ROM, però no és remot ni omnipotent. Requereix el telèfon, mode DFU, maquinari preparat i coneixement tècnic, i no anul·la per si sol el Secure Enclave.
Per als usuaris és una raó per entendre l’antiguitat i el perfil de risc del dispositiu. Per als investigadors és molt més: una porta estable a la primera instrucció de l’iPhone.
Contrast i context
Fonts consultades
-
01
Billy Ellis The iPhone USB Exploit that Apple Can’t Fix
-
02
Paradigm Shift usbliter8: Apple A12 and A13 SecureROM exploit
-
03
Paradigm Shift usbliter8 proof of concept
- 04
-
05
Apple The Secure Enclave
Font de treball
Transcripció amb marques de temps
Consulta la transcripció
-
0:00
, obre el vídeo en una pestanya nova
This small microcontroller has a custom firmware installed that is able to interact with the USB controller of certain iPhone models to trigger a critical vulnerability within the iPhone's boot ROM, allowing it to completely compromise the iPhone's chain of trust. We're talking about USB Literate, a new exploit for the iPhone's secure ROM, effect in a 12 and a 13 devices that was just published by Research Group Parodigm Shift. In this video, we're going to look at how this works, discuss the technical details of the vulnerability being exploited and look at the techniques used to get code execution at the earliest point in the iPhone's boot process. Photos are done already, no? The boot ROM of an iPhone, or the secure ROM as Apple calls it, is the first piece of code that runs on the device when you power it on. It's a small program located in redownly memory that implement some of the most basic core functionality to actually power up the phone. This includes setting up various load-level things such as the MMU. and ultimately validating and load in the next stage bootloader, allowing the phone to boot all the way up to the X and U-Carnall. Funer abilities within the bootroom itself allow X-Poet developers to execute their own code at this very early boot stage. This of course provides a significant level of power and control over the device, especially when compared to more common iPhone X-Poets, such as Kernel X-Poets. The difference is being able to exploit the bootroom allows you to completely defeat a large part of the iPhone's local security model at the very beginning.
-
1:00
, obre el vídeo en una pestanya nova
You can theoretically tell the bootroom to load a completely custom bootloader and subsequent kernel with all security mitigations completely disabled at source. The most famous example of this is the Czech Rain project which implements a full pre-boot environment on iOS and allows users to boot custom instances of the iOS kernel with features such as KTRR completely disabled. Basically allowing a full job rate without the need for multiple individual bugs at the kernel and user space level. And what's even cooler, these bugs are actually unpatchable due to the secure run being completely immutable in red-only memory. Software upgrades cannot change the code in the secure run, so once a vulnerability is identified, it is there forever. The USB-Literate exploit that will be looking at affects the A12 and A13 devices, which is the iPhone 10S and the iPhone 11. The iPhone 12 and newer are not vulnerable to this issue.
-
2:00
, obre el vídeo en una pestanya nova
Parodigm shift states that the vulnerability is self is not within the boot room code but rather within a bad assumption made by the iPhone's USB controller. When connected to a host computer via USB cable, packets can be sent over to the device in DFU mode. According to the USB specification, every control transfer must begin by sending a setup transaction. The data payload of this setup transaction is supposed to be exactly 8 bytes. The iPhone's USB controller stores up to a maximum of three setup packets in memory and then it will reset. When a packet is received, this special MMO register is incremented by the packet size so that the address it holds is pointing to the next available spot within this DMA memory region. The controller will happily increment this register for three packets, but on the full packet received, it will perform a reset. This reset is done by deck fermenting this special register by 24.
-
3:00
, obre el vídeo en una pestanya nova
which is 3 times the expected packet size of 8. This works and the special register now points back to the beginning of the DMA buffer and the process can continue. The BOC, however, is that there is an assumption made to decrement by a fixed size of 24, without actually verifying that the total bite size of the packet's received is 24. It turns out that with the help of additional hardware, it is possible to send setup packets that are actually smaller than 8 bytes. And with this we will have a mismatch between the total increment amount and the hard-coated decrement amount. To trigger this vulnerability we need to make use of a microcontroller, like this Raspberry Pi A2350 board, which allows us to actually send the smaller than intended set up packets over USB. Since the USB specification requires set up transactions to be 8 bytes, a normal USB stack, for example on a MacBook Pro, will not allow us to actually send these kind of broken USB packet sequences.
-
4:00
, obre el vídeo en una pestanya nova
The USB APIs that are exposed on macOS only allow us to send valid packets and not actually specify the exact bits themselves. However, with a Raspberry Pi, we can go much more low-level than this by having it run a custom firmware that acts as a USB controller itself. And this allows us to operate at the USB transaction layer directly. So the host, which in this context is the Raspberry Pi, sends three smaller setup packets, or four bytes each. which means that the value of the special MMI or register has incremented by only 12. And then the reset happens, resulting in a kind of underflow primitive, where the special register is now actually pointing to somewhere before the DMA buffer that it should be using. Receiving a full set up packet, now results in that data being written out of bounds to the memory directly before the DMA buffer. And they refer to this as a buffer underflow. Paroderm shift says they believe this to be an issue with the iPhones USB controller itself, potentially also affecting other devices that use this same controller. It's unclear if other devices would be vulnerable in the same way, however, because they go on next to describe how a specific configuration issue on certain iPhone models is actually what makes this exploitable. On a 12 and 13 devices, the USB-Dart or device address resolution table is configured incorrectly.
-
5:01
, obre el vídeo en una pestanya nova
The dark's job is to sit between hardware peripherals such as the USB controller and the main system memory, and instead of letting a device directly read and write physical memory, it should restrict it to approved buffers. On a 12 and a 13, the iPhone's dark is configured in bypass mode, allowing us to override SRAM data freely in this context. On newer iPhones, while the USB controller bug itself may still exist, the dart is now actually configured properly, preventing us from writing to the out of bounds memory in this way. So with the root cause of the bug out of the way, let's now go on to look at the exploit techniques used. As we discussed, the exploit supports two distinct chipsets, the A12 and the A13. While both of these chips have support for point-to-authentication codes, the A12 chip actually doesn't enable pack in the boot room at all. The A13, however, does, making the techniques to get code execution a little bit more complicated.
-
6:01
, obre el vídeo en una pestanya nova
For the A12 exploitation, it is actually as simple as overriding a saved return address on the boot-romed USB task stack, which happens to lie somewhere in S-RAM behind the problematic DMA buffer. So by sending more setup transactions and repeatedly incrementing and decrement in the special MMI or register, the exploit can reach a chosen location in S-RAM and craft a new setup packet designed to override one of these save return addresses. Then, direct PC control can be achieved when the Schedular performs a context which back to the USB stack. From here they execute a short drop chain and then pivot into a full shell code payload. For the A13 devices, pack is implemented in the boot ROM, so some extra steps are required to actually gain code execution. Instead of corrupting a saved return address, which are packed signed on A13, they get the secure ROM into a state where it has panicked but with interrupts still enabled.
-
7:01
, obre el vídeo en una pestanya nova
They also corrupt the global panic counter and set it to a larger value which prevents the device from rebooting and instead enters an infinite loop. Next, they override the USB interrupt request handle at table with controlled function pointers. And then when an interrupt is received, the dispatch path calls function pointers from that table without any point authentication, allowing them to get code execution and also pivot into the shell code payload. The showcode payload patches the USB request handler callback such that subsequent USB requests will instead be handled by the exploit own custom handler. And here they implement two custom USB commands. The first command allows a user to demote the device, which basically means they modify the in-memory value that mirrors the fuse bit of this iPhone. Essentially allowing someone to downgrade a production iPhone to a development one, given the medicinal capabilities.
-
8:01
, obre el vídeo en una pestanya nova
And the second command is the ability to boot a custom i-boo image, with signature checks completely bypassed. The shellcode then cleans up a few things and eventually returns execution back to the normal DFU loop. All of this happens in around one second, as you can see by the LED on the microcontroller turning green, indicating success, almost immediately after connecting the iPhone. We can then reconnect the phone to a regular computer via USB cable, and it will be recognized as a device in DFU mode. The USB Litter Oak Project provides a small Python program to interact with the two new custom USB commands that were installed by the exploit. So for example, we could extract a raw iBoot Boot Loader from an iPhone IPSW, make a mendamant and patches to it, and then boot it on the device with no issues. While the current state of this open source project is currently only intended to get the device into Pondio View mode, additional capabilities can be easily built on top of this, as we saw previously with the check-rain project.
-
9:01
, obre el vídeo en una pestanya nova
While this exploit is incredibly powerful and fully breaks the chain of trust allowing us to boot custom operating system components and disable security features, there is still an additional barrier protecting user data thanks to the iPhone's secure, Unclave processor. The authors state that while this exploit doesn't affect SEP itself, it does open up wider attack vectors to compromise it. So from the perspective of user security, the release of this exploit doesn't pose any immediate risk and even more so due to the fact that the iPhone 12 and later are not vulnerable. so many people won't be using a vulnerable device anyway. Most of the value here comes from the research opportunities that it opens up for security professionals who want to work with newer iPhones, support in iOS 26 and even 27 at this deep level. Check out the original blog post and the GitHub project down below. Thanks for watching and I'll see you in the next one.
