Artículo: AppStore 0 - JailBreak 1 (Actualizado)

La protección DRM de apple para las aplicaciones de pago del AppStore ha caido del todo, o casi del todo. Los genios que existen en el mundillo digamos que han encontrado un método para saltarse la protección, de modo que cualquier persona que tenga genuinamente la aplicación de pago sea capaz de parchearla in situ, eliminarle la protección y posteriormente sacarla por SFTP y hacerla pública. Estoy seguro que en cientos de sitios ilegales estarán ya. Por el momento se de buena tinta de al menos 17 aplicaciones completamente funcionales, la mayoría juegos. Y eso solo en unas horas. Lo que está claro es que esto va a ser un golpe bastante duro al Store, y posiblemente Apple tome medidas al asunto... pero está claro que hasta septiembre y la actualizacion de firmware 2.1 dudo mucho que Apple pueda hacer algo. Hablamos que ilegalmente cualquier iPhone o iPod Touch tendrá acceso a las aplicaciones de pago de Apple. Tan solo es cuestión de días o horas que el 80% de las aplicaciones estén circulando libremente por internet. Desde aquí? recordar que usarlas es completamente ilegal, además de que evidentemente esas aplicaciones estarán sin actualizaciones. Las aplicaciones se introducirían via SFTP y modificando permisos, aunque es cuestion de tiempo que aparecan incluso repositorios piratas en el Installer con ellas.

El problema? que el método inventado funciona... para todas.

Como viene siendo normal, recordar que esto tan solo es un manual para aprender, en modo alguno para obtener un beneficio pirateando aplicaciones de pago, que aunque son los precios desmesurados no es una razón para realizar algo ilegal. Por ello recuerdo una vez más que tan solo se trata para fines EDUCATIVOS.


Antes de explicar como se hace vamos a resumirlo por pasos:

1º. Hacen falta algunas herramientas de depuración y edición dentro del mismo Ipod
2º. Evidentemente la aplicación ORIGINAL a la que queremos realizarle el parche.
2º. Todo el proceso se realizará dentro de nuestro dispositivo, con lo que es necesario un dispositivo 2.0 JB, acceso por SSH y estar familiarizado con lineas de comando y algunas utilidades unix.


En realidad es un proceso ya bastante conocido en el mundo del cracking, y tiene toda su teoría de fondo, bastante lógica por cierto. Así que como es costumbre, vamos a explicar antes la teoría de fondo para que se comprenda lo que estamos explicando:

Todas las aplicaciones del Store están protegidas por DRM. Para entenderlo de una forma simple... Cuando compramos una aplicación del Store con nuestra cuenta, esa aplicación es descargada para nosotros. Dicha aplicación está firmada exprofesamente para nosotros, tiene nuestros datos. Así mismo, el sistema de DRM del iPod/iPhone contiene igualmente nuestros datos. De modo que cuando la aplicación se introduce en nuestro dispositivo y la ejecutamos, nuestro dispositivo comprueba la firma de la aplicación (certificados digitales, RSA) para verificar si es de Apple y en segundo lugar nuestra firma. Si todo está correcto nuestro dispositivo puede leer y decodificar la aplicación y ejecutarla. Luego digamos que la aplicación en sí está encriptada.

Esto hace que sea imposible copiar aplicaciones entre dos dispositivos diferentes. Se podría entrar por SSH, copiar la aplicación y dársela a otro!! pero en seguida el dispositivo de la otra persona al comprobar la firma de la aplicación se daría cuenta que no es válida, dado que los credenciales no son los suyos. No puede desencriptar la aplicación y por consiguiente no puede ejecutarla.

Pero hemos dicho que el proceso es: primero comprobar las firmas al ejecutarla, y si es válida desencriptarla, y despues ejecutarla. Luego los posibles vectores de ataque serían:

1º. Hacernos con la firma de Apple, es decir, con su clave privada:

Esto es imposible en la práctica. Nosotros NO PODEMOS falsear la firma de Apple. Para ello deberíamos de obtener el certificado privado (la clave privada) de certificación de Apple, y quien me lea y lo he dicho en otras entradas, esto es imposible a día de hoy. De seguro Apple esta la tiene a buen recaudo.

2º. El método tradicional de parcheo:

Editar la aplicación en IDA por ejemplo, un desemsamblado, tener conocimientos profundos de ARM y ser capaces de inyectar código en la aplicación para que sea capaz de saltarse la protección DRM. Esto es más que posible, pero es complejo y requere a veces de una habilidad bastante grande y un conocimiento profindo de ensamblador. La primera aplicacion del Store en ser crakeada fue el MonkeyBall, y se hizo por este método. En la prácitca este método es tedioso y poco práctico para nuestro caso. Una aplicación que otra si, pero con todas las aplicaciones del Store...

3º. Eliminar DRM.

Eludir cualquier sistema DRM es cuanto menos complicado. Siempre que nos enfrentemos cara a cara con sistemas usando RSA, certificados digitales... hay siempre que temblar un poco. Estos sistemas no son para reir. Cualquier sistema de protección basado en claves publicas (cifrado asimétrico) es casi inespugnable. Pero podemos hacer trampa. No podemos romperlo... o así?

Atacar el sistema es imposible. Pero pensemos... Si yo compro la aplicación legalmete yo puedo usarla sin problema. Para que una aplicación o lo que sea se ejecute antes tiene que estar en memoria, esto es informática básica.

Sabemos igualmente que la aplicación se encuentra encriptada y protegida por DRM de modo que toda la aplicación es una caja negra y la única llave para abrir esa aplicación la tiene su comprador. Y que la misma aplicación comprada por dos personas diferentes tendrá cerraduras diferentes. Pero en realidad no está protegida toda la aplicaicón!! los archivos de ella no están protegidos, tan solo el ejecutable, por asi decirlo. Él si está encriptado.

Cuando la aplicación se ejecuta se carga el ejecutable en memoria, encriptado. Hay una parte no encriptada que realiza las operaciones de DRM. Cuando se validan, el ejecutable se desencripta completamente en memoria para poder ser ejecutado. Ahí es donde atacamos nosotors. No podemos desencriptarla, pero su sueño si! cuando su dueño la ejecuta legítimamente, la parte encriptada de la aplicación es desencriptada en memoria. Con un debugger es posible cazar esta parte ya desencriptada si sabemos en que posición se encuentra y que bloque buscamos. Una vez nos hacemos con dicho bloque, tan solo tenemos que sustiturir la parte encriptada por la desencriptada.

Con su ejecutable completamente funciona ahora, tan solo quedaría el problema de la firma. La firma se usa para evitar que la aplicación sea modificada, entre otras cosas. Pero esto ya no es problema, gracias al DevTEam y su JB. Al hacer JB a la version 2.0 se anula en el kernel la verificación de Apple de firma, pero aun así es necesario que la aplicación esté firmada. No por Apple ya, sino por cualquiera.

Así que tan solo nos queda autofirmar la aplicación por nosotros mismos y problema resuelto.

Al acabar, el dueño tendrá su propia aplicacion modificada. Esta aplicación podría por tanto ser usada en cualquier otro dispositivo, ya que la protección DRM habría simplemente desaparecido.

En españa tenemos leyes que amparan el derecho a copia de seguridad, en otros paises no. Esto quiere decir que tenemos derecho a tener copias de seguridad de nuestras aplicaciones. Esto significa, que con la ley por delante, podemos parchear nuestras propias aplicaciones por seguridad. Evidentemente no repartirlas a los demas.

---------------------


Llegados a este punto, vamos a ponernos manos a la obra, recordar que TODO el proceso se hará dentro de nuestro mismo dispositivo.

Material a necesitar:

1º. Una aplicación legítima comprada en el Store
2º. Otool: Es una pequeña utilidad que nos proporciona información residente en la cabezara de los ejecutables de Apple
3º. Gdb: El debugger que usaremos

Tanto Otool como gdb lo podemos encontrar en Cydia. gdb está bajo el nombre de GNU Debugger y Otool está dentro del paquete "iPHone 2.0 Toolchain"

Una vez instaladas las dos aplicaciones entraremos por putty por ejemplo (SSH) y nos pondremos manos a la obra:

Primero usaremos la utilidad Otool para saber si la aplicación está encriptada o no, y en el caso de estarlo saber que parte de la aplicación... que bloque de ella lo está. Que es la información que necesitamos:

otool -l [rutadel ejecutable]

Esto nos sacará en pantalla la información visible en la cabecera de la aplicacion, algo así:

Load command 9
cmd LC_ENCRYPTION_INFO
cmdsize 20
cryptoff 4096
cryptsize 666555
cryptid 1
Load command 10

Es simple leer esto. Cryptoff son los datos no encriptados, CrypSize el tamaño del bloque encriptado y Crypid nos dice si la aplicación está "encriptada = 1" "no encriptada = 0"

El valor importante aquí sería 666555, que es el tamaño del bloque encriptado y por el podemos deducir el offset de la memoria dnd se encontrará.


Una vez realizado esto ejecutaremos la aplicación normal y corriente desde el board, pero no cerraremos SSH. Una vez la aplicación se esté ejecutando necesitaremos saber su id de proceso, lo que se conoce como PID. Este es el ID que internamente usan los PCs tb para reconocer el proceso en cuestion. Para saber esto tan solo tenemos que teclear en SSH:

ps ax

Esto nos devolverá algo como:

...
313 ?? s 0:00.00 /usr/libexec/ptpd -t usb
321 ?? 0:00.00 /usr/sbin/sshd -i
354 ?? s 0:00.00 /var/mobile/Applications/01602982-F3B9-4EC6-99DB-FE990B0AF724/iMmo.app/iMmo

En nuestro caso, nuestro PID sería 354, puesto que es el que corresponde a nuestra aplicación.


Una vez tengamos tambien este dato, tan solo queda la parte "complicada". Ejecutar el debugger a una aplicación lanzada. Asi que tan solo tendremos que teclear:

gdb -p (en nuestro caso ejemplo: gdb -p 354)

Una vez realizado estaremos dentro de gdb, con nuestra aplicación genuina bajo él.

Como hemos dicho la aplicación ya se estará ejecutando de manera no encriptada. Tan solo tenemos que capturar dicha parte y nos podemos ir a casa. Pero esto tambien es algo muy simple. Nosotros necesitamos el bloque que inicia en el offset 0x2000 y finaliza en el offset que nos daba la parte encriptada. En nuestro ejemplo hemos dicho que el tamaño de la parte encriptada era 666555. Este tamaño está en bytes, tan solo lo tenemos que pasar a hexadecimal para saber en memoria que offset sería este. Si al resultado le sumamos los 0x2000 bytes del inicio... tendremos el inicio y el fin del bloque encriptado. Pero lo podemos ver mejor en nuestro ejemplo:

tamaño del bloque: 666555bytes -> 0xA2BBBBytes
Pero como tenemos que empezar desde el offset 0x2000, tan solo se lo debemos de sumar (recordar que estamos sumando en hexadecimal:

0x2000 + 0xA2BBB = 0xA4BBB

Luego nuestro bloque buscado sería: 0x2000 - 0xA4BBB

En realidad es simple, no hay que hacer mucho.

Como tenemos ya el bloque buscado (tan solo es una simple suma y conversión hexadecimal-decimal)

Tan solo tenemos que capturar dicho bloque. Dentro del mismo Debugger teclearemos en nuestro ejemplo lo siguiente:

dump memory volcado.bin 0x2000 0xA4BBB

la sintaxis es simple, dump memory seguido del archivo donde guardaremos el fragmento y la dirección de inicio y fin.

Una vez realizado el proceso tendremos un archivo llamado volcado.bin que contendrá todo el contenido encriptado desencriptado :)

Que hacer ahora? es de cajón.

Salimos del debugger y lo más facil es realizar el siguiente paso en Windows con un editor exadecimal. Por un lado abrimos el archivo ejecutable y por otro el volcado.bin. Tan solo tenemos que sustituir el contenido encriptado por el contenido no encriptado. Para realizar esto copiamos todo el contenido de volcado.bin reemplazamos el contenido que existe en el ejecutable original, comenzando en el offset 0x1000 del original. Porque comenzar desde este offset? Recordemos el resultado que nos dio la utilidad otool:

cryptoff 4096
cryptsize 666555
cryptid 1

dijimos que Cryptoff era la parte no encriptada verdad? la cabecera en realidad del archivo, y a partir de ella, 666555bytes más ya encriptados:

4096 = 0x1000 es decir, 4096 es decimal, en hexadecimal equivale a 0x1000.

Luego tenemos que sustituir el contenido del original apartir del offset 0x1000 que es donde en el original comienza el contenido encriptado. Sustituimos todo el contenido encriptado por el no encriptado, que es lo que contiene volcado.bin.

El resultasdo final es un ejecutable completamente desencriptado!! pero no podemos acabar aquí. Queda un pequeño detalle:

cryptid 1

recordemos que eso siginificaba que nuestra aplicación estaba encriptada... pero ahora no lo está. Si lo dejamos así nuestro dispositivo intentará desencriptarla... debemos ponerla a 0. Para ello desde el mismo editor hexadecimal usado podemos ponerla a cero. normalmente dicho valor se encuentra en el offset 0x800 (evidentemente dentro de los 0x1000 primeros)

Una vez realizado todo esto tenemos el ejecutable terminado. Tan solo queda firmar la aplicación para saltarnos la última verificación y barrera de Apple. Para ello sustituiremos el ejecutable original de nuestro dispositivo por el creado ahora mismo.

Una vez sustituido, por SSH teclearemos:

ldid -S [rutadelaaplicación]

FIN

Llegado a este punto la aplicación estará completamente abierta para todos. Usada maliciosamente el dueño de la aplicación podría sin problema alguno copiar la carpeta de la aplicacion.app, sacarla por SSH y darsela a quien fuera. Esa persona podría ahora sí meterla en su dispositivo por SSH, establecer permisos a 755 por ejemplo, reiniciar el board y usarla perfectamente.


Comprendo que esto puede no ser entendido por algunos, pero si alguien quiere intentarlo con fines didácticos tan solo evidentemente puede ponerse en contacto conmigo y le echo una mano en lo que necesite.

Un saludo.