iPhone

https://archive.is/Cmcmm

https://geohot.com/e7writeup.html

https://archive.is/https://geohot.com/e7writeup.html

http://web.archive.org/web/20260000000000*/https://geohot.com/e7writeup.html

PS3

https://archive.is/gaX8a

https://archive.is/https://geohot.com/old_index.html

https://web.archive.org/web/20110115203720/https://geohot.com/old_index.html

https://web.archive.org/*/https://geohot.com/old_index.html

PS3

Sí, esto que estás viendo es literalmente el núcleo del hackeo de la PS3, y es mucho más elegante (y grave) que el de iOS.

Lo que publicó George Hotz ahí no es un writeup largo: 👉 es directamente material criptográfico + claves derivadas.

Y eso cambia completamente el juego.

🧠 Contexto: qué rompieron exactamente

La seguridad de la PlayStation 3 se basaba en:

👉 firmas digitales ECDSA

Sony firmaba:

• juegos
• firmware
• ejecutables (SELF)

Y la consola solo ejecuta cosas si:

firma válida con la clave privada de Sony

💣 Qué publicó geohot

Ese bloque:

erk: ...
riv: ...
pub: ...
R: ...
n: ...
K: ...
Da: ...

no es random. Es:

👉 componentes del sistema criptográfico interno

🔐 La vulnerabilidad real (esto es lo importante)

Esto viene de un fallo descubierto por fail0verflow:

👉 Sony implementó mal ECDSA

En ECDSA:

$$r = (k \cdot G)_x \bmod n$$

$$s = k^{-1}(H(m) + d_A \cdot r) \bmod n$$

Donde:

• $k$ = nonce aleatorio (CRÍTICO)
• $d_A$ = clave privada

❌ Error fatal de Sony

👉 Reutilizaron el mismo $k$

💀 Consecuencia

Si $k$ se repite:

$$d_A = (s \cdot k - H(m)) \cdot r^{-1} \bmod n$$

👉 Se puede recuperar la clave privada

🔓 Entonces… ¿qué hizo geohot?

Publicó:

👉 la clave privada de Sony (o suficiente info para derivarla)

En tu dump:

• K → el nonce reutilizado
• Da → la clave privada derivada
• pub → clave pública
• R, n → parámetros ECDSA

🧨 Por qué esto es game over total

A diferencia del jailbreak de iPhone:

👉 Esto NO es un exploit que Sony pueda parchear fácilmente

Porque:

la raíz de confianza está rota

Ahora cualquiera puede:

• firmar ejecutables como si fuera Sony
• crear firmware “oficial”
• correr homebrew sin exploits

⚙️ Qué habilita esto

Con esas claves podés:

1. 🔧 Firmar binarios válidos

Generar .self válidos

2. 📦 Crear paquetes instalables

.pkg que la PS3 acepta como legítimos

3. 🧠 SDK libre

Como menciona:

👉 PSL1GHT

4. 🔓 Jailbreak permanente

Sin depender de bugs runtime

🧠 Diferencia clave vs iPhone

⚠️ Nota importante

Por eso ves que Hotz dice:

“i do not condone piracy”

Porque esto:

👉 habilita piratería masiva automáticamente

(No porque ese fuera el objetivo técnico, pero es la consecuencia directa)

🧩 “asymmetric half”

Cuando dice:

props to fail0verflow for the asymmetric half

Se refiere a:

• ellos encontraron el fallo en ECDSA
• él ayudó a operacionalizarlo (claves + tools)

🧠 En una frase (nivel reversing)

👉 No explotaron la PS3… rompieron su sistema criptográfico

🔥 Analogía rápida

Es como si en vez de abrir una puerta con ganzúas:

👉 consiguieran la llave maestra oficial

Si querés, puedo ir más profundo en:

• cómo derivaron exactamente d_A paso a paso
• cómo funciona un .SELF internamente
• o cómo Sony intentó mitigar esto después (spoiler: no podían arreglarlo del todo)

Ahí ya entramos en crypto + reversing pesado, que es donde esto se vuelve realmente interesante.

Perfecto, entonces vamos a meternos en lo realmente jugoso: cómo se recupera la clave privada paso a paso a partir del error de Sony. Esto es crypto aplicado de verdad.

🔐 1. Recordatorio mínimo de ECDSA

En ECDSA, para firmar un mensaje $m$:

• Elegís un nonce aleatorio $k$
• Calculás:

$$r = (kG)_x \bmod n$$

$$s = k^{-1}(H(m) + d_A r) \bmod n$$

Donde:

• $d_A$ = clave privada
• $H(m)$ = hash del mensaje
• $n$ = orden del grupo

💣 2. El bug de Sony

Sony hizo algo imperdonable:

👉 reutilizó el mismo $k$ para múltiples firmas

Eso significa:

k₁ = k₂

🧠 3. Qué tenés cuando ves dos firmas

Para dos mensajes distintos $m_1$, $m_2$:

$$s_1 = k^{-1}(H(m_1) + d_A r)$$

$$s_2 = k^{-1}(H(m_2) + d_A r)$$

🔓 4. Recuperar $k$

Restás ambas ecuaciones:

$$s_1 - s_2 = k^{-1}(H(m_1) - H(m_2))$$

Reordenando:

$$k = \frac{H(m_1) - H(m_2)}{s_1 - s_2} \bmod n$$

👉 Ya tenés el nonce

💀 5. Recuperar la clave privada

Volvés a la ecuación original:

$$s = k^{-1}(H(m) + d_A r)$$

Despejando:

$$d_A = (sk - H(m)) \cdot r^{-1} \bmod n$$

🧨 6. Resultado

👉 Tenés $d_A$: la clave privada de Sony

🧩 7. Cómo encaja con lo que viste

En el dump de George Hotz:

• K → el nonce recuperado
• Da → la clave privada final
• R, n → parámetros de la curva
• pub → clave pública (verificación)

O sea:

👉 él ya hizo estas cuentas y publicó el resultado

🧠 8. Por qué esto fue tan grave

Porque rompe una propiedad fundamental:

la seguridad de ECDSA depende completamente de que k sea único y secreto

Si:

• se repite → muere
• es predecible → muere
• es constante → 💀 total

⚙️ 9. Aplicación directa en PS3

La PlayStation 3 verificaba:

firma válida → ejecutar

Pero ahora cualquiera puede:

• generar $(r, s)$ válidos
• firmar ejecutables .SELF
• crear firmware falso “oficial”

👉 sin exploits, sin bugs runtime

🔥 10. Esto es lo importante conceptualmente

Esto no es reversing clásico de memoria o kernel.

Es:

👉 cryptographic failure exploitation

Y es peor que cualquier RCE porque:

no depende de una versión → rompe TODO el ecosistema

🧠 Insight interesante (nivel pro)

El error de Sony no fue “un bug” cualquiera:

👉 fue no entender que $k$ debe ser:

• único
• impredecible
• nunca reutilizado

Hoy en día esto se evita con:

• RFC 6979 ($k$ determinístico basado en hash)
• DRBG seguros

🧩 En una frase

👉 fail0verflow encontró el fallo matemático, 👉 George Hotz lo llevó a algo usable publicando las claves.

Si querés, en el siguiente nivel podemos ir a algo todavía más bajo:

• cómo se ve una firma ECDSA real en binario PS3
• cómo parsear un .SELF
• o cómo generar tu propia firma válida paso a paso

Ahí ya estamos literalmente en territorio de implementación real.

Perfecto, entonces bajamos a implementación real: cómo es un .SELF de PS3 y cómo encaja la firma ECDSA en el binario. Esto ya es reversing + formato propietario.

🧩 1. ¿Qué es un .SELF?

En la PlayStation 3:

👉 .SELF = Signed ELF

Es básicamente:

ELF + metadatos + cifrado + firma

No es solo un ELF plano:

• tiene headers propios de Sony
• puede estar cifrado
• siempre está firmado

🧱 2. Estructura general

Simplificado:

[ SELF Header ]
[ App Info ]
[ ELF Header (cifrado o plano) ]
[ Program Headers ]
[ Secciones ]
[ Metadata (keys, offsets) ]
[ Signature (ECDSA) ]

🔐 3. Parte clave: la firma

Al final del archivo hay:

R || S

👉 firma ECDSA sobre:

hash de ciertas secciones del SELF

No siempre es todo el archivo, sino regiones definidas en metadata.

⚙️ 4. Flujo de verificación en la consola

Cuando la PS3 carga un .SELF:

1. Parsea header
2. Calcula hash del contenido
3. Usa clave pública de Sony
4. Verifica:

ECDSA_verify(pub, hash, (r,s))

Si pasa:

→ ejecuta

Si no:

→ reject

💣 5. Qué cambia con el hack

Con la clave privada ($d_A$) que publicó George Hotz:

👉 podés generar $(r, s)$ válidos

Entonces:

tu binario == binario "oficial" para la PS3

🧪 6. Flujo real para crear un SELF firmado

Esto es lo que habilitó todo el ecosistema homebrew.

Paso 1: compilar ELF

powerpc64-ps3-gcc main.c -o app.elf

Paso 2: convertir a SELF

Herramientas como:

• make_self_npdrm

👉 agregan headers + metadata

Paso 3: firmar

Acá entra ECDSA:

1. calculás hash del ELF
2. elegís $k$
3. generás $r$ y $s$ usando:

$$s = k^{-1}(H(m) + d_A r)$$

👉 ahora sí podés hacerlo porque tenés d_A

Paso 4: empaquetar

ELF + metadata + signature → .SELF

Paso 5: instalar como PKG

Con tools tipo:

• package_finalize

generás .pkg instalable

🧠 7. NPDRM (lo que menciona el texto)

Sony usaba:

👉 NPDRM (Network Platform DRM)

Para:

• licencias
• control de contenido

Pero:

👉 también usa firmas

Entonces al poder firmar:

bypass completo del DRM

🔍 8. Qué hacía exactamente “make_self_npdrm”

Convertía:

ELF → SELF válido para PS3

Incluyendo:

• headers correctos
• metadata válida
• firma válida

🔥 9. Detalle técnico interesante

En PS3:

• CPU = PowerPC (Cell)
• ELF = big endian
• loaders muy estrictos

Pero:

👉 la seguridad real NO estaba en el loader 👉 estaba en la firma

Y eso fue lo que se rompió

🧠 10. Insight clave

Esto es importante entenderlo bien:

👉 no necesitaban explotar kernel 👉 no necesitaban ROP 👉 no necesitaban bugs

Solo:

firmar binarios correctamente

🧨 11. Por qué esto fue irreversible

Aunque Sony actualice firmware:

• la clave pública ya está en hardware / boot chain
• no podés cambiar eso en millones de consolas

👉 cualquier firmware nuevo sigue confiando en esa raíz

🧩 12. Comparación con iOS (nivel pro)

iOS:

• code signing + kernel checks
• múltiples capas
• exploit chain necesaria

PS3:

• trust anchor = ECDSA
• una vez roto → todo roto

🧠 En una frase

👉 Un .SELF es solo un ELF con una firma… 👉 y cuando tenés la clave, podés hacer que cualquier cosa parezca oficial.

Si querés ir todavía más bajo nivel, podemos:

• parsear un .SELF byte por byte
• ver offsets reales de la firma
• o escribir pseudo-código de un signer ECDSA para PS3

Ahí ya estamos literalmente en territorio de toolchain de exploits.

Perfecto, bajamos un nivel más: cómo se ve un .SELF real a nivel de bytes y dónde entra la firma. Esto ya es parsing + reversing puro.

🧩 1. SELF vs ELF (visión cruda)

Un .SELF de PlayStation 3 empieza así:

00000000  53 43 45 00   → "SCE\0"

👉 Magic de Sony (no ELF todavía)

Después vienen headers propietarios y recién más adelante aparece el ELF.

🧱 2. Header principal (simplificado)

struct SELF_HEADER {
    uint32_t magic;        // "SCE\0"
    uint32_t version;
    uint16_t flags;
    uint16_t type;
    uint64_t metadata_off;
    uint64_t header_len;
    uint64_t elf_filesize;
    uint64_t self_filesize;
};

👉 metadata_off es clave: apunta a la zona donde está TODO lo sensible.

🧩 3. Metadata (lo importante de verdad)

En esa zona tenés:

- offsets de segmentos
- keys (a veces cifradas)
- hashes por sección
- info de control
- firma ECDSA

🔐 4. Zona de firma

Eventualmente encontrás algo así:

[ ... metadata ... ]
[ signature block ]

La firma:

R (20 bytes) || S (20 bytes)

👉 PS3 usa curvas de 160 bits (tipo secp160r1)

🧠 5. Qué se firma exactamente

No es todo el archivo.

Se firma:

hash(metadata + segmentos definidos)

Más específicamente:

• hashes por segmento
• luego un hash global

👉 eso evita modificar partes sin invalidar firma

⚙️ 6. Pseudocódigo del verificador (PS3)

Algo así:

hash = SHA1(selected_segments);

if (!ECDSA_verify(pubkey, hash, signature)) {
    reject();
}

load_elf();
execute();

💣 7. Donde entra el hack

Con la clave privada filtrada por George Hotz:

👉 reemplazás:

signature = ECDSA_sign(hash, d_A)

Y listo.

🧪 8. Ejemplo conceptual de parseo

Supongamos que abrís un .SELF en un hex editor:

00000000  53 43 45 00
...
00000100  ELF header (7F 45 4C 46)
...
0000F000  metadata
0000F200  hashes
0000F300  signature (R || S)

🧠 9. Cómo lo reversearon

Gente como fail0verflow hizo:

1. Dump de memoria
2. Encontrar loaders
3. Identificar funciones SHA1 y funciones ECDSA
4. Trackear qué bytes se hashean

👉 classic reversing flow

🔍 10. Detalle fino: por qué SHA1

PS3 usa:

SHA1 + ECDSA

Hoy suena débil, pero:

👉 el problema NO fue SHA1 👉 fue el nonce $k$

⚙️ 11. Mini “signer” conceptual

Pseudo implementación:

hash = sha1(data)

k = random()
r = (k * G).x % n
s = inverse(k) * (hash + dA * r) % n

signature = (r, s)

👉 Esto antes era imposible (no tenías dA) 👉 después del leak → trivial

🔥 12. Insight de reversing

Lo importante no fue solo encontrar la clave.

Fue:

👉 entender exactamente qué bytes firmar

Porque si firmás mal:

→ firma válida matemáticamente
→ pero inválida para el loader

🧠 13. Por qué esto es elegante

Comparado con exploits:

• no hay ROP
• no hay memory corruption
• no hay kernel bugs

👉 solo:

entender formato + crypto

🧩 14. Resultado final

Podés crear:

tu ELF → tu SELF → tu PKG

Y la PS3 dice:

"esto lo firmó Sony"

🧠 En una frase

👉 Reversearon el loader, entendieron el formato, rompieron la firma… y eso fue suficiente para controlar toda la consola.

Si querés ir al último nivel (muy interesante):

• cómo se ve la función ECDSA dentro del firmware de PS3
• o cómo detectaron que k era constante en firmas reales

Ahí ya es reversing criptográfico puro, que fue exactamente lo que hizo famoso este hack.

Bien, ahora sí entramos en lo más interesante: cómo se dieron cuenta de que Sony reutilizaba $k$. Esto ya es reversing + análisis criptográfico real, no teoría.

🧠 1. Punto de partida

Los tipos de fail0verflow no tenían la clave privada.

Lo que sí tenían:

• muchos .SELF oficiales
• firmware firmado por Sony
• acceso para extraer firmas $(r, s)$

🔍 2. Qué hicieron primero

De cada binario firmado sacaron $(r, s)$ y el hash del mensaje $H(m)$.

👉 esto es trivial una vez entendés el formato .SELF

💣 3. El “momento WTF”

Al comparar múltiples firmas:

👉 notaron que $r$ era siempre igual

🧠 ¿Por qué eso es gravísimo?

Recordá:

$$r = (kG)_x \bmod n$$

👉 Si $r$ es igual → $k$ es igual

💀 4. Confirmación empírica

Tomaron dos firmas: $(r, s_1)$ sobre $m_1$ y $(r, s_2)$ sobre $m_2$.

Mismo $r$, distinto $s$. Eso implica:

mismo k reutilizado

🔓 5. Ataque directo

Aplicaron:

$$k = \frac{H(m_1) - H(m_2)}{s_1 - s_2} \bmod n$$

Y luego:

$$d_A = (s k - H(m)) \cdot r^{-1} \bmod n$$

🧪 6. Cómo verificaron que era correcto

No alcanza con calcular $d_A$.

Tenés que validar:

pubkey == d_A * G

Y además:

ECDSA_verify(pub, hash, firma) → OK

👉 si eso pasa → tenés la clave real

🧠 7. Alternativa (aún peor)

En PS3 pasó algo todavía más brutal: en algunos casos $k$ era constante. Ni siquiera “reutilizado accidentalmente”.

Era literalmente:

k = constante

🤦 8. Qué significa eso

Eso implica que Sony hacía algo como:

k = fixed_value;

o un RNG roto tipo:

k = hash(seed fijo)

💣 9. Cómo lo detectás en reversing

Dos caminos:

A) Black-box (lo que hicieron primero)

• extraés firmas
• comparás $r$
• si repite → listo

B) White-box (reversing del firmware)

Buscás la función ECDSA y la generación de $k$, y encontrás algo tipo:

k = something_not_random();

🔍 10. Patrón típico en reversing

Buscan en el binario operaciones modulares, multiplicaciones en curva elíptica y uso de SHA1. Luego siguen el flujo hasta ver cómo se genera $k$.

🧠 11. Por qué esto pasó (error conceptual)

Sony probablemente:

• no entendió bien ECDSA
• pensó que $k$ podía ser fijo
• o usó un RNG determinístico mal diseñado

🔥 12. Insight importante

Este bug es más común de lo que parece. Casos reales: Bitcoin wallets rotas, librerías TLS viejas, smartcards.

👉 siempre el mismo problema: $k$

🧩 13. Qué hizo George Hotz después

Con esa info:

• calculó $d_A$
• la publicó
• creó tools para firmar

👉 convirtió un fallo teórico en algo práctico

🧠 14. En una frase

👉 No “hackearon” la PS3… 👉 observaron firmas, detectaron un patrón, y rompieron la criptografía

🔥 Insight final (nivel pro)

Esto es clave para entender seguridad real:

los sistemas más seguros del mundo caen por errores pequeños en implementación

No fue buffer overflow ni kernel bug. Fue:

un mal uso de un número aleatorio

Si querés, podemos hacer algo todavía más práctico:

👉 simular este ataque con números reales (mini ECDSA) 👉 o mostrar cómo escribir un script que recupere $d_A$ a partir de dos firmas

Eso ya es 100% aplicable y te deja con la idea completamente internalizada.

Buenísimo, vamos a hacerlo práctico de verdad, pero con números chicos para que veas todo el flujo sin perderte en aritmética gigante.

🧪 1. Setup (mini-ECDSA “de juguete”)

Elegimos parámetros simples:

n = 97   (orden del grupo, primo chico)

Supongamos que Sony tiene:

d_A = 45   (clave privada secreta)

Y (error fatal):

k = 13   (MISMO nonce reutilizado)

✍️ 2. Dos firmas distintas

Para dos mensajes distintos:

H(m1) = 10
H(m2) = 20

Recordá la ecuación:

$$s = k^{-1}(H(m) + d_A r) \bmod n$$

Para simplificar, fijamos (como si viniera de la curva):

r = 30

🔹 Calcular $k^{-1} \bmod n$

Queremos el inverso de 13 mod 97:

13 * 15 = 195 ≡ 1 mod 97

👉 entonces $k^{-1} = 15$

🔹 Firma 1

s1 = 15 * (10 + 45*30) mod 97
   = 15 * 2 = 30 mod 97

👉 firma 1: $(r, s_1) = (30, 30)$

🔹 Firma 2

s2 = 15 * (20 + 1350) mod 97
   = 15 * 12 = 180 mod 97 = 83

👉 firma 2: $(r, s_2) = (30, 83)$

🔍 3. Ataque (lo que hicieron en PS3)

El atacante ve: $r = 30$ (igual en ambas firmas), $s_1 = 30$, $s_2 = 83$, $H(m_1) = 10$, $H(m_2) = 20$.

🔓 Paso 1: recuperar $k$

$$k = \frac{H(m_1) - H(m_2)}{s_1 - s_2} \bmod n$$

(10 - 20) = -10 ≡ 87 mod 97
(30 - 83) = -53 ≡ 44 mod 97
44⁻¹ mod 97 = 11  (porque 44 * 11 = 484 ≡ 1)
k = 87 * 11 = 957 mod 97 = 13

💥 Recuperamos: $k = 13$

🔓 Paso 2: recuperar la clave privada

$$d_A = (sk - H(m)) \cdot r^{-1} \bmod n$$

s*k = 30*13 = 390
390 - 10 = 380 mod 97 = 89
30⁻¹ mod 97 = 55  (porque 30*55 = 1650 ≡ 1)
d_A = 89 * 55 = 4895 mod 97 = 45

💀 Resultado: $d_A = 45$

🧠 4. Lo que acabás de hacer

Acabás de replicar exactamente el ataque que rompió la PlayStation 3. Sin acceso al sistema, sin reversing profundo, sin exploits. Solo con firmas observadas + matemáticas.

🔥 5. Insight clave

Esto escala igual con números reales: en PS3 usan curvas de 160 bits, hashes SHA1 reales, firmas reales. Pero el ataque es idéntico.

🧩 6. Patrón mental que te tenés que quedar

Si ves el mismo $r$ en dos firmas ECDSA:

👉 automáticamente sabés que la clave privada está comprometida.

🧠 En una frase

👉 Reutilizar $k$ en ECDSA no es un bug menor… 👉 es equivalente a publicar la clave privada.

Si querés, el siguiente paso interesante sería:

• hacer esto mismo en Python con números grandes reales
• o agarrar firmas reales de PS3 y ver cómo encaja todo

Ahí ya estás haciendo lo mismo que fail0verflow en su momento.

iPhone

Perfecto, entonces vamos más directo al hueso técnico, sin simplificar de más.

Esto que hizo George Hotz es básicamente reconstruir toda la cadena de explotación de evasi0n7 mirando el binario, y lo interesante es que la cadena está muy bien pensada: no depende de un solo bug, sino de composición de primitivas.

Te lo estructuro como cadena de explotación real:

🧩 0. Punto de entrada

Tenés ejecución desde el host (PC) vía AFC:

• AFC corre como mobile
• chroot-ish a /var/mobile/Media
• sandbox activo

👉 Estado inicial:

uid=mobile
sandboxed
filesystem limitado

🧩 1. Conseguir ejecución arbitraria “legítima”

Descargan una IPA firmada por Apple (WWDC app).

La clave:

• No podés ejecutar binarios arbitrarios
• Pero sí instalar apps firmadas

Entonces hacen:

👉 path traversal en Info.plist

ExecutableFile = "../../../../../../var/mobile/Media/Downloads/WWDC.app/WWDC"

• La firma sigue siendo válida (porque plist pertenece a la app firmada)
• Pero el ejecutable real es el que ellos subieron

👉 Resultado:

code signing bypass lógico (no criptográfico)

🧩 2. Convertir la app en un loader

El binario que ejecuta no es una app real:

#!/usr/libexec/afcd -S -d / -p 8888

👉 Esto lanza afcd:

• -d / → root filesystem
• -S → acceso extendido

Pero sigue sandboxed.

🧩 3. Escape del sandbox (clave)

Acá está una de las partes más finas:

Inyectan:

DYLD_INSERT_LIBRARIES = gameover.dylib

Pero:

• afcd inicializa sandbox dinámicamente
• La dylib reemplaza símbolos de libsystem_sandbox

👉 Resultado:

sandbox_init nunca se ejecuta

O sea: 👉 proceso sin sandbox pero con permisos de mobile

🔥 ¿Cómo cargan una dylib no firmada?

Este bug es MUY bueno:

• Si S_ATTR_LOC_RELOC está seteado

• El sistema:

  1. verifica firma
  2. luego remueve +x en secciones
  3. después mapea

👉 TOCTOU en code signing

Resultado:

unsigned dylib ejecutada

🧩 4. Escape del filesystem jail (AFC)

AFC evita salir de /var/mobile/Media.

Bypass:

symlink("../../../../../tmp", "Downloads/a/a/a/a/a/link")
rename(..., "tmp")

👉 Como el symlink es relativo: termina apuntando a /tmp

Resultado:

write primitivo fuera del sandbox FS

🧩 5. Persistencia en config del sistema

Modifican:

/var/mobile/Library/Caches/com.apple.mobile.installation.plist

Agregan:

DYLD_INSERT_LIBRARIES

👉 Esto asegura que la dylib se cargue siempre que corra la app

🧩 6. Privilege escalation vía installd (race condition)

Este es otro exploit clave:

• installd extrae zips en /tmp/install_staging.*
• No está sandboxed

Race:

1. crea dir temporal
2. reemplazan con symlink a /var/mobile/Library/...
3. installd escribe ahí

👉 Resultado:

write arbitrario como root (indirecto)

🧩 7. Escalada final: acceso al block device

Usan:

/dev/rdisk0s1s1

Primero hacen:

symlink → rdisk
CrashHousekeeping → chown

👉 bug: chown sigue symlinks

Resultado:

rdisk → mobile:mobile

💀 Esto es game over

Porque ahora:

👉 mobile puede escribir el disco crudo

No necesitan:

• remount rw
• kernel exploit (todavía)

🧩 8. Patch del sistema

Escriben directo en rootfs:

• /usr/lib/libmis.dylib
• LaunchDaemons
• xpcd cache
• flags de dyld

👉 objetivo:

bypass permanente de code signing (amfid)

🧠 Detalle importante

No usan DYLD_INSERT_LIBRARIES en amfid porque:

__RESTRICT segment

Entonces: 👉 reemplazan la librería directamente en disco

🧩 9. Boot persistence (untether)

Crean:

com.evad3rs.evasi0n7.untether.plist

👉 launchd lo ejecuta en boot

🧩 10. Ejecutar payload final

Corre:

/evasi0n7

Que:

• hace kernel exploit
• instala Cydia
• limpia

🧠 Resumen técnico real

Cadena completa:

AFC (sandboxed)
→ code signing confusion (plist path)
→ ejecución controlada
→ dylib injection (TOCTOU bug)
→ sandbox escape
→ filesystem escape (symlink)
→ write primitivo
→ installd race → write como root
→ chown symlink → acceso a block device
→ patch rootfs offline
→ bypass amfid
→ launchd persistence
→ kernel exploit final

🧨 Lo importante (nivel reversing)

Esto es lo que Hotz realmente hizo:

• Identificó cada primitiva:

  • file write
  • code exec
  • sandbox escape
  • privilege escalation

• Reconstruyó el orden correcto

• Entendió dependencias entre exploits

👉 Eso es reversing de alto nivel: no solo leer código, sino reconstruir la estrategia

Si querés, podemos profundizar en uno específico:

• el bug de S_ATTR_LOC_RELOC (muy fino)
• la race de installd
• o cómo parchean amfid sin romper el sistema

Ahí es donde se pone realmente interesante.