-[ 0x04 ]--------------------------------------------------------------------
-[ Hack Symbian ]------------------------------------------------------------
-[ by FCA00000 ]  ---------------------------------------------------SET-35--


  ^^                           
  ||                           
 _||_________                  
|            | En un nmero anterior cont cmo hacer un escalado de permisos 
|- FCA00000 -| en telfonos Symbian. Aquello era vlido para algunos modelos 
|  ________  | que usaban la versin S60v1, que eran mayora en aquella poca. 
| |        | | Pero hace unos 2-3 aos ha habido una nueva versin llamada 
| |HACK    | | S60v3, tambin conocida como Symbian 9.
| | SYMBIAN| |
| |________| | Los que desconozcan cmo funciona, pensarn que no es un gran 
|            | cambio. Nada ms lejos de la realidad: en S60v3 se implementa
| <_>    <_> | un mecanismo de seguridad apropiado para telfonos mviles.
|            | Es como cuando Windows 3.1 evolucion hacia Windows NT para
| <_><__><_> | permitir permisos en el sistema de ficheros NTFS. Anteriormente,
| <_><__><_> | cualquier programa poda escribir en cualquier directorio y 
| <_><__><_> | fastidiar sus datos. Es cierto que la memoria del kernel estaba
| <_><__><_> | protegida, pero era lo nico.
|____________| 

Ahora, cada programa tiene una serie de permisos, organizados en 4 capas: 

   1 -> Comn
   2 -> Restringida
   3 -> Sensible
   4 -> Crtica.

Para que un programa pueda usar una funcionalidad, debe estar firmado con un
certificado otorgado por Nokia o Symbian.

Por tanto existen 4 tipos de certificados:

   -> El de tipo 'comn' se distribuye gratuitamente. No da acceso
      a mucha funcionalidad, pero es gratis.

   -> El de tipo 'restringido' se les da a algunas empresas. No es
      difcil conseguirlo, pero hay que pagar unos 200 euros, y otros
      200 por programa.

   -> El de tipo sensible se les da a pocas compaias. Cuesta mucho
      dinero y esfuerzo.

   -> El crtico no se le da a nadie. Slo lo tiene Nokia, Motorola, 
      SonyEricsson, y alguna empresa ms. Ni que decir tiene que es
      el ms potente.

Esto hace que los programadores vulgares tienen el certificado 'comn' y no
puedan hacer programas que pongan en riesgo el sistema. La idea est bien:
si tienes un certificado, tu aplicacin tiene unas ciertas garantas, y
puedes acceder a funcionalidad crtica.

Sin embargo esto conlleva que los usuarios no tienen control total sobre
sus mviles. En particular no pueden ver todos los archivos.

Esto supone un obstculo para la piratera de juegos. Voy a explicar
porqu. Un juego incluye uno o ms ficheros. stos se agrupan en un fichero
de instalacin, que se firma en la fbrica, y el usuario debe instalar.
Supongamos que el fichero principal es "c:\sys\bin\juego.exe". Entonces
slo el programa de instalacin puede escribir ficheros en el directorio
"c:\sys\bin". Esto es importante.
Supongamos que cualquiera puede leer estos ficheros. Es ms o menos cierto,
pero no es necesario dar ms detalles. As que un cracker puede extraer
estos ficheros y hacer un crack. Con ms o menos esfuerzo, tiene
"c:\sys\bin\juego_crk.exe"

Pero la pregunta es: Cmo se puede meter de nuevo? La respuesta es, en
general, NO. La nica manera es usar un instalador.

No es del todo cierto: si el juego tiene nicamente permisos de la capa
'comn', el cracker s puede hacer un mini-instalador, usando su certificado
'comn'. Pero si el juego original usa permisos de la capa restringida, entonces
el cracker no tiene un certificado lo suficientemente potente para incluir
"c:\sys\bin\juego_crk.exe".

Si bien es cierto que la mayora de los juegos no necesitan permisos ms all
de la capa 'comn', los fabricantes se han dado cuenta de que usando permisos,
pueden detener la piratera. Y parece funcionar bien.

Hasta ahora :-)

He descubierto una debilidad en este sistema!

Aunque he sido yo quien la ha descubierto y usado, he tenido ayuda de varias
personas, as que esta es mi manera de agradecrselo a todos: voy a explicarlo
como si fuera una conversacin, que empiezar al publicar un mensaje en un foro
sobre telfonos mviles:

|-----------------------------------------------------------------------------|

   FCA00000: Hola. He visto que S60v3 est protegido. Yo tengo experiencia en
             mviles. Alguien se anima a romperlo?

   Vovan888: uff, el tema est complicado. El problema es que no podemos leer
             los archivos, as que no sabemos cmo funciona la proteccin.

   FCA00000: bueno, mi SX1 usaba S60v1 y resulta que todos los programas estaban
             en una zona de memoria que empieza en 0x50000000.

   Vovan888: Cmo llegaste a esa conclusin? Quizs el mismo razonamiento sea
             vlido.

   FCA00000: en arquitecturas ARM, hay un registro llamado PC que te dice qu
             direccin de memoria se est ejecutando. Para llamar a rutinas del
             sistema, se pone PC=0x50000000+yyyyyyy , donde yyyyyyy es un valor
             distinto para cada rutina. Se poda volcar esa memoria en un
             fichero y analizarla.

   Vovan888: mis pruebas indican que los programas de usuario se ejecutan en la
             direccin 0xF5000000+tttttt.
 
   FCA00000: acabo de hacer un programa en mi S60v3 que vuelca 16 Kb a partir
             0xF5000000 y efectivamente se asemeja al cdigo binario de un
             programa. Parece ser que S60v3 llama a rutinas a partir de:
             0xF8000000+zzzzz.

   atzplzw: Toma, aqu tienes un programa que vuelca a partir de 0xF8000000.
            Yo lo he probado y he desensamblado el resultado. Son 16 Mg, y
            ciertamente parece cdigo para procesadores ARM. De hecho hay algo
            que parecen ser nombres de ficheros.

   FCA00000: correcto. Al principo de la memoria hay una lista de ficheros,
             con las direcciones en las que se almacenan. Es como un disco duro
             con acceso lineal: cada archivo est en una direccin de memoria.
             He logrado extraer cada fichero. Hay unos 1.500.

   atzplzw: en el SDK de Symbian, que es gratis, hay un documento que explica
            cmo es la cabecera de cada fichero. Se llama RomHeader.

   FCA00000: no slo eso; la herramienta llamada  petran  permite mostrar dicha
             cabecera. El fichero ms interesante se llama ekern.exe , que es el
             kernel.

   Hex: yo lo he desensamblado y le he dado nombre a algunas de sus rutinas. En
        particular hay una que se llama -> Kern::DoCurrentThreadHasCapability.

   FCA00000: en el SDK incluye un emulador. No es exactamente lo mismo poque
             funciona con cdigo x86 en lugar de ARM, pero tambin existe
             "ekern.exe" y tambin incluye esa rutina.

   Hex: ya entiendo cmo funciona: Un programa tiene 'capacidades', que se le
        definen cuando se compila, y se guardan en la cabecera del programa. Al
        hacer el instalador se verifica que tu certificado te permite incluir
        programas con esas capacidades. Si no, no puedes ni siquiera hacer un
        instalador.

   FCA00000: no tengo un certificado que me otorgue capacidades altas. Para ver
             qu sucede, he hecho un programa.exe que las necesita, aunque no
             las tiene otorgadas. Lo he podido instalar, pero falla a la hora
             de ejecutar la rutina. Lo bueno es que el programa se inicia
             correctamente; slo falla al ejecutar la rutina que carece de
             capacidades.

   Hex: Cual es el error que te da?

   FCA00000: devuelve el valor KErrNoPermission. El error lo provoca el
             "ekern.exe". Lo he probado en el emulador poniendo un breakpoint,
             y he visto que las capacidades se extraen de la cabecera del
             fichero. Cuando el programa se carga en memoria antes de
             ejecutarlo, se inicializa una zona de memoria con esos mismos
             valores. Esta zona pertenece al kernel, no al programa.

   ZoRn: Quizs puedas usar la misma tcnica de tu artculo anteror, usando
         "ExecHandler::LockedInc".

   FCA00000: ya lo he probado. Pero los de Symbian/Nokia ha cerrado esa puerta
             de un modo elegante: antes de escribir un dato, verifican que
             pertenece a la zona de usuario o de kernel.

   ZoRn: puedes cambiar ese trozo de cdigo? Existe una debugger llamado
         MetroTRK que permite detener un programa para investigar.

   FCA00000: he conseguido instalarlo y ver la zona de memoria de usuario,
             tanto el cdigo de programa como los datos. Lamentablemente slo
             puedo debuguear mi propio programa, no ekern.exe

   ZoRn: eso es una limitacin del propio MetroTRK . Yo lo he desensamblado y
         he visto que no permite ver memoria de cdigo de otros programas.
         Como MetroTRK tiene capacidades crticas, estamos con el problema
         recursivo: si lo pudiramos parchear, podramos saltarnos las
         restricciones. Pero para parchear, estamos restringidos. Ojal
         pudiramos debuguear el mismo MetroTRK.

   FCA00000: Dices que MetroTRK slo limita la memoria de cdigo? Un programa
             tiene cdigo y datos. Y es posible ver los datos de otros programas
             ! Comprobado !

   ZoRn: entonces puedes modificar la memoria del ekern.exe ?

   FCA00000: dicho y hecho. Como ya sabes, ekern.exe mantiene en memoria una
             lista de los programas en ejecucin. Adems del nombre, tiempo de
             CPU, y memoria usada, se incluye las capacidades que tiene
             otorgadas. Inicialmente se sacan de la cabecera del fichero
             "programa.exe" pero el debuger MetroTRK me ha dejado modificarlas
             para ampliarlas. O sea que le he cambiado las capacidades, sobre
             la marcha. Ahora programa.exe es capaz de llamar a rutinas
             'crticas'!

|-----------------------------------------------------------------------------|

Para aquellos que les gustan los detalles tcnicos, extrados del modelo N80
con firmware 5.0719.02 - La memoria empieza en 0xF8000000 y ocupa 20 Mb.
Se pueden extraer los ficheros con la herramienta ROMTools hecha por m. Genera
unos 1.000 ficheros. La puedes encontrar en:

   - http://FCA00000.googlepages.com/romtools-v0.2.2.rar

El fichero "ekern.exe" ocupa unos 250 Kb y se puede analizar con el
desensamblador IDA. Genera unas 1.500 rutinas, que lamentablemente slo se
saben unos 400 nombres.

La rutina "Kern::DoCurrentThreadHasCapability" acaba llamando a
"DProcess::DoHasCapability" que est en la direccin 0xF8047330.

El "ekern.exe" almacena todos sus datos en la zona que empieza en 0x60000000
y ocupa un 200 Kb.

La lista de procesos se guarda en una zona de memoria indicada por 0x60000148,
por ejemplo 0x60004000.

Cada proceso tiene un nmero secuencial y usa una estructura de 0x40 datos.

Si programa.exe tiene nmero 0x123 entonces sus datos se almacenan en
0x60004000+0x40*0x123 = 0x600088C0. Las capacidades se encuentran en el
byte 0x4 , es decir, 0x600088C4. Esto es un dato de 4 bytes, lo cual almacena
32 bits. Slo hay 20 capacidades, por lo que se malgastan 12 bits.
Bueno, no es tanto. O sea, que cuando el programa no tiene capacidades,
0x600088C4 contiene el valor 0x00000000. Si el valor es 0xFFFFFFFF entonces
el programa tiene todas las capacidades y es todopoderoso. Slo hay que usar
el MetroTRK para cambiarlo.

En otros modelos y otras versiones, estos nmeros cambian.

Cuando pensabas que ya estbamos a punto de terminar, hay ms informacin que
necesito compartir. El emulador no slo sirve para probar aplicaciones, sino
que permite testear que se le han otorgado las capacidades que necesita.
Supongamos que haces un programa que usa la rutina RFs:SetSubst(). Esta rutina
necesita capacidades DiskAdmin que son de tipo sensible . Es decir, necesitas
un certificado potente para poder usarla. Si no, tu programa fallar en el
mvil.
Pero en el emulador es posible poner un parmetro para que simplemente avise,
en lugar de fallar. Por tanto, el programa funcionar en el emulador.

Ojo, que esto est controlado por el parmetro de configuracin llamado
"PlatSecDiagnostics". Si vale On , entonces se queja pero no falla.

Dnde esta la diferencia con el mvil?

Por si no lo he contado, el emulador est generado a partir del mismo cdigo
que se usa en los mviles, pero compilado para PC (procesador x86) en vez de
para mvil (arquitectura ARM).
O sea, que es ms o menos el mismo cdigo fuente, pero distinto cdigo binario.
As que descompilo ekern.exe para PC y pongo un breakpoint en
"DProcess::DoHasCapability". Cuando se dispara, lo analizo paso a paso y me
encuentro que, en funcin del valor de "PlatSecDiagnostics", salta a una rutina
que yo llamo "log_missing_capabilities".

   - Cuando PlatSecDiagnostics=On , despus de saltar, devuelve True
   - Cuando PlatSecDiagnostics=Off , no salta, y adems devuelve False

Ahora es cuando viene lo bueno: el msmo cdigo existe en el "ekern.exe"
de mi mvil. Slo que en este caso, PlatSecDiagnostics se almacena en la
direccin de memoria 0x64000148. Inicialmente vale 0x1E que es equivalente
a False. O sea, que si no hay capacidades, fallar. Lo que tengo que hacer
es transformarlo en True, que (avanzando acontecimientos) resulta ser el
valor 0x10.

As que arranco  programa.exe  que necesita capacidades de las que carece.
Luego lo debugueo para que MetroTRK me permita ver y modificar la memoria.
Voy a la direccin 0x64000148 y pongo 0x10 en vez de 0x1E .
Continuo la ejecucin de mi programa, y observo con satisfaccin que es capaz
de invocar a "RFs:SetSubst()" sin problemas.
No slo eso, sino que como es un parmetro global, cualquier programa adquiere
todas las capacidades.

Es hora de iniciar un explorador de archivos y verificar que tengo acceso a
"c:\sys\bin". Puedo leer y escribir con control total. Ahora ya puedo empezar
a crear versiones crackeadas de los juegos ! Si eres de los afortunados
posedores de un Nokia, seguro que has visto juegos crackeados por el grupo
"BiNPDA", por ejemplo los de N-Gage. Ellos han usado esta vulnerabilidad.

Como no todo el mundo puede usar el debugger MetroTRK , elaboro un programa
llamado hack_perms_s60v3 que hace exactamente lo mismo. Pero esto es tema para
otro artculo.

Ni que decir tiene que la gente de Nokia no estaban muy contentos con esto:
les cost mucho esfuerzo desarrollar un sistema de seguridad, y da rabia ver
que est roto simplemente porque se les olvid poner ms restricciones en su
propio debugger. 

Reitero el aviso:

   - Ten cuidado con lo que instalas en tu mvil.
     Puedes recibir sorpresas desagradables !!!!!


*EOF*