Copy Link
Add to Bookmark
Report
SET 033 0X05
-[ 0x05 ]--------------------------------------------------------------------
-[ Crack Symbian ]-----------------------------------------------------------
-[ by blackngel ]----------------------------------------------------SET-33--
Crack Symbian
--------------
Para seguir con el tema de symbian, voy a explicar como se pueden modificar
aplicaciones programadas en este sistema operativo.
Esto es valido para cualquier telefono Symbian, no solo el SX1.
Esto incluye n-gage, Sendo, y la mayoria de los Nokias de nueva generacion.
Oficialmente existen 10.000 aplicaciones disponibles, pero a decir verdad
yo no me creo esta cifra; si hay mas de 1.000, me daria por contento.
Las herramientas son:
-un movil Symbian
-una aplicacion que deseemos modificar.
-desensamblador IDA o similar.
-es bueno tener a mano el SDK de symbian. Al menos la documentacion.
Las aplicaciones generalmente se descargan desde la pagina web del
proveedor, y tienen extension *.sis
Hay otro tipo de aplicaciones hechas en java que se proporcionan como
un fichero *.jar y otro *.jad . Estos son programas en java, y no son
objetivo de este articulo, ya que los explique en un numero anterior de SET.
Lo primero es transferir la aplicacion hacia el movil:
-por el puerto infrarrojos. Esto es lo que yo uso.
-mediante BlueTooth.
-copiandola en la tarjeta MMC usando un lector/escritor en el PC
Este ultimo metodo no es confortable en los Nokia, porque la MMC esta debajo
de la bateria, y para sacarla hay que desmontar el movil. En el SX1 esta en
un lateral y se puede extraer incluso con el movil encendido.
A continuacion se inicia una aplicacion interna al movil llamada instalador.
Esta aplicacion se llama
Z:\System\Libs\InstEng.dll
que sigue las instrucciones que le dice el fichero *.sis
Para ver el contenido de este fichero podemos usar la aplicacion
SISTool by Alezz, del Z-Team.
Por ejemplo, vamos a analizar la aplicacion FExplorer1.15 , que creo que
todo el mundo la tiene, puesto que resulta extremadamente util.
Sirve para manejar ficheros: mover, renombrar, transmitir por BlueTooth, ...
Los ficheros incluidos en el instalador son:
1) License.txt
2) !:\system\apps\FExplorer\FExplorer.aif
3) !:\system\apps\FExplorer\FExplorer.app
4) !:\system\apps\FExplorer\FExplorer.rsc
5) !:\system\apps\FExplorer\FExplorer.mbm
6) !:\system\apps\FExplorer\EXETEST.EXE
7) !:\system\apps\FExplorer\keys.txt
Usando SISTool se ve que el primer fichero tiene un indicador que dice que
debe mostrarse durante la instalacion. Ademas presenta las opciones OK y NO
para seguir con la instalacion o cancelarla.
El programa instalador se encarga de la tarea de presentar este texto, hacer
la pregunta, y recoger la respuesta.
No es posible solicitar ningun numero de serie, ni nada que se le parezca.
Los otros ficheros que empiezan por !:\ indican que se le presentara al
usuario la posibilidad de instalarlo en distintas unidades de disco.
Esto suele ser:
E: para la tarjeta MMC, que es lo que yo voy a usar.
C: para la memoria interna no-volatil.
En nuestro ejemplo, no pide la unidad de destino 6 veces, sino que con la
primera vez le vale.
Existen otras posibilidades. Por ejemplo, una linea del tipo
C:\system\data\FExplorer.dat
siempre se guardara en la unidad C: . Esto es usado comunmente para ficheros
de configuracion, claves de autorizacion, y control de uso. Mas tarde
veremos un ejemplo, paciencia.
Asi que tras responder (3 veces !) a las confirmaciones de instalar la
aplicacion, la tenemos en
e:\system\apps\FExplorer\FExplorer.app
El fichero FExplorer.aif se puede abrir con la aplicacion SISTool by Alezz.
Vemos que contiene
AIF ID = 0x383A0010
App ID = 0xF17B1F10
1 string = "FExplorer"
2 iconos, con identificadores 000 (el dibujo) y 001 (la mascara)
Todo esto sirve para que el menu principal sea capaz de presentar un
icono, y el titulo de la aplicacion.
El fichero FExplorer.mbm se puede abrir con la aplicacion MBMTool by Alezz.
Vemos que contiene 22 dibujos, de los cuales la mitad son iconos, y la otra
mitad son las mascaras.
El fichero FExplorer.rsc se puede abrir con la aplicacion RSCTool by Alezz.
Si todavia no te has convencido de que este tipo es un maestro, no se a
que esperas.
Vemos que contiene 313 objetos, aglutinados en 92 grupos.
Los objetos son de 2 tipos:
-numeros enteros de 4 bytes.
-cadenas de caracteres, que van precedidas por un valor con su longitud.
Existen otros tipos, pero lo normal es encontrarse solo con estos dos.
Este fichero suele contener las palabras y frases que se usan en la
aplicacion.
Por ejemplo, si hay un menu con la palabra "Comprimir Memoria", es casi
seguro que esta en este fichero.
Es frecuente encontrarse que una aplicacion incluye varios
ficheros FExplorer.r01, FExplorer.r02, ... FExplorer.rXX
Cada fichero contiene las frases en un idioma distinto.
El fichero *.r01 se usa cuando instalas la aplicacion en Ingles.
El r02 sirve para Frances, r04 para espanyol, el r56 para Gujarati, del que
puedes obtener mas informacion en
http://en.wikipedia.org/wiki/Gujarati_language
Por tanto el fichero *.sis incluye muchos lenguajes, pero solo uno de ellos
se instala en el movil.
Lo bueno es que este fichero es facil de modificar. Hay gente que ha
traducido aplicaciones ajenas para adaptarlas a su propio idioma. Si bien
esto no se puede considerar como un acto de crackear el programa, lo cierto
es que es mejor pedirle permiso al autor. Quizas se alegre e incluya la
traduccion en la siguiente version.
Mas interesante es saber que la forma de acceder a uno de tales ficheros
desde un programa Symbian es usar la funcion RResourceFile::OpenL
Para leer los datos dentro de este fichero se usa la clase
TResourceReader::Read_xxx
Para acelerar la carga de menus, Symbian definio un fichero de
extension *.rss
que se compila y se mete en el *.rsc y se lee de un golpe usando la funcion
CEikEdwin::ConstructFromResourceL(menu_ID);
Cada opcion dentro del menu tiene un identificador unico.
Este es un ejemplo de FCA00000.rss
RESOURCE MENU_PANE r_FCA00000_menu
{
items =
{
MENU_ITEM {command = 0x0102; txt = "HacerAlgo";},
MENU_ITEM {command = 0x0103; txt = "OtraCosa";},
MENU_ITEM {command = 0x0104; txt = "MuchoMas";},
MENU_ITEM {command = EAknSoftkeyExit; txt = "Exit";}
};
}
Hay otro detalle digno de mencionar: cada aplicacion tambien tiene un
identificador unico. En teoria hay que solicitarselo a la companyia Symbian,
pero es mas comun inventarse uno propio. Si coincide con el de alguna otra
aplicacion, mala suerte.
En particular mi aplicacion tiene el identificador 0xFCA00000
Para obtener el identificador de cada menu simplemente hay que
combinar ambos:
0xFCA00000 + 0x0102 = 0xFCA00102
Por lo tanto en el fichero FCA00000.rsc aparecen los bytes
02 01 0A FC
que son la representacion en little-indian de 0xFCA00102
En el programa habra una intruccion del tipo:
if(menu_elegido==0xFCA00102)
{
......
}
Este sera un buen punto de inicio para empezar a seguir el flujo del
programa.
Los programas Symbian solo funcionan en procesadores ARM, que usan un
lenguaje ensamblador mas simple que el que encuentras en un ordenador PC.
Para desensamblar los programas, la mejor herramienta que yo conozco es el
IDA-Disassembler. Conoce las instrucciones ARM y saca un listado muy limpio.
Por ejemplo me sorprendio que la secuencia de instrucciones
MOV R0, 0x77
ADD R0, 0x100
la muestra como
MOV R0, 0x177
haciendo que el listado sea mas comprimido que lo que sacan otros
desensambladores. Por favor soporta a sus creadores y compralo: es una
herramiente magnifica.
Una cosa a recordar es que los programas siempre aparecen desensamblados
a partir de la direccion 0x10000000.
Cuando se cargan en memoria se ejecutaran en cualquier otra direccion
de memoria, normalmente 0xFFF?0000 para los primeros 16 programas
que se ejecuten.
Como creo haber dicho en otro articulo, symbian es un sistema operativo
en el que los programas completan el link en tiempo de carga.
Lo explico: cuando compilas el programa que llama a una rutina del sistema
operativo, no sabes a priori en que direccion de memoria esta dicha rutina.
Solo sabes el nombre.
Asi que el programa compilado contiene una referencia a un indicador fijo.
Cuando quieras ejecutar el programa, el sistema operativo lo carga en
memoria, y arranca un cargador (second-phase loader) que ajusta las
direcciones de las rutinas usadas.
Vamos a verlo con un ejemplo:
Este es un trozo de un program escrito en lenguage C/C++ para symbian:
RFile myFile;
myFile.Replace(fileSession, "c:\\myfile", EFileWrite);
se traduce en codigo ensamblador en algo asi:
LDR R1, [r0+X] ; en algun sitio existe una referencia a fileSession
LDR R2, =p_C_myFile ; puntero a un puntero al String "c:\\myfile"
MOV R3, #0x200 ; EFileWrite es una constante que vale 0x200
BL stub_RFile_Replace ; rutina que saltara a RFile::Replace, la cual
; necesita 3 argumentos: R1, R2, y R3
......
p_C_myFile DCD C_myFile ; puntero al String "c:\\myfile"
C_myFile DCA "c:\\myfile" ; String "c:\\myfile"
......
stub_RFile_Replace:
LDR R12, =p_Replace__5RFileR3RFsRC7TDesC16Ui ; direccion que apunta
; a la rutina destino
LDR R12, [R12] ; carga el dato de dicha direccion
BX R12 ; y salta
......
p_Replace__5RFileR3RFsRC7TDesC16Ui DCD Replace__5RFileR3RFsRC7TDesC16Ui
Replace__5RFileR3RFsRC7TDesC16Ui IMPORT Replace__5RFileR3RFsRC7TDesC16Ui
......
por pasos:
-primero se preparan los 3 argumentos necesarios para stub_RFile_Replace
-luego se llama al stub
-el stub lee en Replace__5RFileR3RFsRC7TDesC16Ui la rutina a la que
debe saltar
-este dato ha sido rellenado por el Sistema Operativo cuando ha
cargado en memoria el programa
Visto de otro modo, la rutina stub_RFile_Replace es equivalente a:
int (void *)lista_funciones[];
int R12 = lista_funciones[index_p_Replace__5RFileR3RFsRC7TDesC16Ui];
(void *)funcion = *(R12);
call funcion(R1, R2, R3);
Si no lo has entendido bien, te recomiendo que consultes algun otro
documento en el que explique la carga dinamica de programas; es una
tecnica muy comun en sistemas operativos de disco.
Por eso es posible saber a cuales funciones llama un programa. Esto lo
aprovecha IDA y muestra algo asi:
10003C40 MOV R0, R5
10003C44 BL stub_DriveAndPath__C10TParseBase ; TParseBase::stub_DriveAndPath(void)
10003C48 ADD R3, SP, #0x18
Aunque no sepamos lo que hace este programa en la rutina en 10003C40, sabemos
que llama a TParseBase::DriveAndPath(void), que es una funcion que retorna
la unidad y la ruta en la que esta instalado el programa.
A partir de aqui empieza la tarea de investigacion.
-----------------------------
Como ya es habitual, vamos a trabajar en un caso real.
En el movil SX1 de Siemens es posible actualizar uno mismo el firmware que
viene incluido de serie. No esta al alcance de cualquiera poder alterarlo
para que haga las cosas que uno quiere, pero hay un grupo llamado Z-TeAm
que ha hecho realmente muchos cambios.
En un telefono Symbian existe las unidades:
- Z: que contiene los programas. Es de solo lectura. Ocupa 16 Mb.
- E: que esta en la tarjeta MMC. Obviamente aqui se pueden copiar programas
- C: tambien es de lectura y escritura. Ocupa 4 Mb.
- A: que es de solo lectura. Teoricamente. Ocupa 4 Mb. Hay 1Mb libre
Aqui es donde esta lo bueno: el Z-TeAm ha conseguido que sea posible meter
programas en esta ultima unidad A: , aprovechando el espacio libre.
Pero no se puede escribir desde el propio telefono, sino desde un ordenador.
Basicamente uno tiene que crear una estructura de directorios similar a la
que quiere que vaya a A: , y convertirlo en un mega-fichero de 4 Mb.
Luego se mete en el movil.
La unidad A: contiene unos cuantos programas que no son imprescindibles.
Ademas se pueden meter en la memoria MMC.
Pero en A: queda espacio de sobra para instalar unos cuantos programas.
Uno de los programas mas utiles es el FExplorer 1.15 mencionado
anteriormente.
Asi que seria recomendable tenerlo en la unidad A para que siempre estuviera
accesible aunque cambie la tarjeta MMC.
El problema es que FExplorer se empenya en buscar el archivo de configuracion
en la misma unidad en la que esta instalado. Obviamente no le gusta que
este en A: porque no puede sobre-escribirlo.
La solucion es enganyarlo para que lo lea desde C: y no desde A: .
El archivo de configuracion se llama FEgen.ini
Cargamos FEXplorer.app en el desensamblador IDA y al cabo de 3 minutos
produce el codigo desensamblado.
La palabra "FEgen" la encuentro en:
100195B8 aFegen unicode 5, <FEgen>,0
y un poco mas abajo, encuentro
100195D0 a_ini unicode 4, <.ini>,0
busco referencias a estas direcciones:
10003C90 off_10003C90 DCD aFegen
que a su vez viene desde:
10003C74 ADD R4, R4, #8
10003C78 ADD R0, SP, #0x10
10003C7C LDR R1, =aFegen
10003C80 BL s__7TPtrC16PCUs ; TPtrC16::TPtrC16(ushort const *)
10003C84 MOV R0, R4
O sea, que llama a la funcion TPtrC16::TPtrC16 que segun el manual de
Symbian sirve para iniciar una cadena. No es de extranyar que esta rutina
tan comun se llame en 350 sitios distintos a lo largo del programa.
Un poco mas adelante hace:
10003CC0 LDR R1, =a_ini
10003CC4 BL s__7TPtrC16PCUs ; TPtrC16::TPtrC16(ushort const *)
10003CC8 MOV R0, R4
10003CCC MOV R1, SP
10003CD0 BL s_Append__6TDes16RC7TDesC16 ; TDes16::Append(TDesC16 const &)
que sirve para concatenar una cadena a otra. A mi me parece que vamos en
la direccion adecuada.
Ahora falta ver donde le ha antepuesto el nombre del directorio.
Para ello investigo el codigo antes de 10003C74 y me encuentro con:
10003C44 BL stub_DriveAndPath__C10TParseBase
....
10003C58 BL s_Copy__6TDes16RC7TDesC16
y la documentacion del API me confirma que TParseBase::DriveAndPath me
devuelve una cadena conteniendo la unidad y el directorio.
Por eso deduzco que el codigo original es algo asi:
String unidad_y_directorio;
String ruta_completa;
unidad_y_directorio = TParseBase::DriveAndPath();
ruta_completa.Copy(unidad_y_directorio);
ruta_completa.Append(String("FEgen");
ruta_completa.Append(String(".ini"));
Ahora, para conseguir eliminar la unidad de disco de la ruta, tengo que hacer
unidad_y_directorio = "C:\" + TParseBase::Path();
es decir, que no llame a TParseBase::DriveAndPath() ,
sino a TParseBase::Path();
lamentablemente no existe la rutina TParseBase::Path();
Pero la solucion mas rapida es hacer que no use en absoluto el nombre
del disco donde esta la aplicacion:
String unidad_y_directorio;
String ruta_completa;
unidad_y_directorio = TParseBase::DriveAndPath();
//ruta_completa.Copy(unidad_y_directorio); // <--comentar esta linea
ruta_completa.Append(String("c:\FE"); // el archivo es c:\FE en vez de FEgen
ruta_completa.Append(String(".ini"));
En otras palabras: no uso la ruta original de la aplicacion, sino que
el archivo al final sera
c:\FE.ini
?Porque no he usado c:\FEgen ? Pues porque "FEgen" ocupa 5 caracteres, y por
tanto "c:\FEgen" ocuparia 8, lo que me obligaria a hacer hueco en el programa.
Recordar que estoy modificando el archivo binario, no el codigo fuente.
Cuando se altera un binario, no es facil hacer hueco en medio del programa.
Los cambios son:
.....
10003C58 NOP ; inicialmente era BL s_Copy__6TDes16RC7TDesC16
.....
100195B8 aFegen unicode 5, <c:\FE>,0 ; inicialmente era <FEgen>
.....
Para los que esten interesados en codigo binario, la instruccion
BL s_Copy__6TDes16RC7TDesC16
tiene codigo
394800EB
y la instruccion
NOP
tiene codigo
0000A0E1
Para probarlo, modifico FExplorer.app y lo transfiero al movil. Inicio la
aplicacion y confirmo que ha creado el fichero c:\FE.ini
Y esta todo listo para meterlo en la unidad A: tal como queria conseguir.
Como veis, no es mucho mas distinto que desensamblar programas para PC.
------------------------------------
Al principio he comentado la estructura de un fichero .sis de instalacion.
Ahora me gustaria anyadir que hay algunas posibilidades mas complejas.
Una de ellas es que se pueden instalar distintos ficheros dependiendo de:
-fabricante: Ericsson, Motorola, Nokia, Panasonic, Psion, ...
-modelo
-velocidad de la CPU
-memoria
-numero de teclas
-numero de luces LED
-tamanyo de pantalla
-lenguajes disponibles
....
Otra funcionalidad es que se puede ejecutar la aplicacion tras la instalacion.
Esto es util cuando el programador desea:
-crear una serie de directorios
-verificar que existe un cierto fichero
-solicitar un codigo de proteccion o numero de serie
-conectarse a una pagina web para obtener algun otro dato
-enviar un SMS para informar al programador
.....
y en caso de que alguna condicion no sea correcta, se devuelve un codigo
de error al instalador, que automaticamente desinstala el programa.
La mayoria de los programas contienen unicamente:
-la aplicacion principal XXX.app
-el icono y nombre del programa en XXX.aif
-los dibujos que usa XXX.mbm
-los sonidos XXX.mid
-los mensajes en XXX.rsc , XXX.r01, XXX.r02 , ...
-archivo de configuracion XXX.ini o XXX.cfg
-ayuda o notas en XXX.hlp o XXX.txt
Algunos programas mas complejos incluyen:
-librerias XXX.dll
-programas servidores XXX.exe para tareas criticas
-reconocedores XXX.mdl
-bases de datos XXX.db o XXX.dat
Son particularmente utiles los ficheros XXX.mdl que se ejecutan cuando se
inicia el movil. Si estas pensando en crear un antivirus (o un virus) , un
protector de pantalla (o un sniffer de teclas), o algo que se parezca a
un LKM (Loadable Kernel Module) debes mirar en esta direccion.
------------------------------------
Dado que este articulo explica como modificar aplicaciones Symbian, voy a
explicar otra tecnica.
Por si no ha quedado claro lo repito otra vez: cada programa, tal como esta
en el disco (MMC o C:), contiene solo referencias a rutinas del sistema
operativo. Cuando se carga en memoria, esas referencias se convierten en
las direcciones especificas de las rutinas. Estas direcciones son distintas
segun el modelo de movil, e incluso segun la version del Sistema Operativo.
Por ejemplo, para el Siemens-SX1 existen mas de 20 versiones distintas de
sistema operativo, segun el idioma con que han sido fabricados: la
version 15 en Espanyol y la version 15 en Ruso tienen distintas direcciones
de rutinas.
Por cada rutina externa que es invocada desde el programa, debe de haber
un "lanzador" hacia ella. Eso se conoce como Stub.
Aqui hay un par de ejemplos:
....
;---------------------------------------------------------------------------
stub_CCoeControl::SizeChanged(void)
LDR R12, =SizeChanged__11CCoeControl
LDR R12, [R12]
BX R12
off_1001F674 DCD SizeChanged__11CCoeControl ; CCoeControl::SizeChanged(void)
;---------------------------------------------------------------------------
stub_CCoeControl::PositionChanged(void)
LDR R12, =PositionChanged__11CCoeControl
LDR R12, [R12]
BX R12
off_1001F684 DCD PositionChanged__11CCoeControl ; CCoeControl::PositionChanged(void)
;---------------------------------------------------------------------------
....
Si un programa llama a 200 rutinas externas (creeme, 200 es un
numero normal) entonces hay 200 stubs.
Vamos a analizar uno cualquiera de estos stubs.
-Siempre usa 3 instrucciones y 1 dato ; cada uno de estos elementos
ocupa 4 bytes, lo cual da 16 bytes
-todos hacen lo mismo; simplemente cambia la direccion desde la que obtienen
la direccion de la rutina de destino. (Si, es una direccion que apunta
a otra direccion)
-usan el registro R12, sin importarles lo que hubiera antes. Esto parece
indicar que R12 es realmente de usar y tirar.
Si recordais otro articulo anterior para el Siemens S45, yo contaba que
seria util hacer un traceador para saber cuales rutinas eran llamadas
por un programa. Vamos a ver si tambien lo puedo hacer para Symbian.
El objetivo es definir una rutina que se llame cada vez que pase algo
interesante, y que diga de donde viene, a donde va, y que datos usa.
?Como se define "sucede algo interesante"? Pues muy facil: cualquier
llamada al sistema operativo es interesante.
Puedo interceptar cada uno de los stubs: en lugar de
stub_XXX(void)
LDR R12, =XXX
LDR R12, [R12]
BX R12
off_XXX4 DCD XXX ; XXX
lo transformo en
stub_XXX(void)
LDR R12, =XXX
LDR R12, [R12]
B mi_debugger ; <---- esta es la linea que cambio
off_XXX4 DCD XXX ; XXX
Hay que tener cuidado en varios aspectos:
1-la rutina mi_debugger no puede cambiar ningun registro
2-debe finalizar con BX R12 , como en el original
3-el programa original debe modificarse para incluir esta rutina debugeadora.
Por tanto hay que buscar un hueco libre en algun lugar del programa; por
ejemplo un string que no se use.
4-debido a la arquitectura ARM, la rutina mi_debugger debe estar en el
mismo segmento de memoria que stub_XXX
La primera restriccion es facil de cumplir: solo hay que guardar
temporalmente en la pila los registros que necesitemos usar, y al
final hay que recuperar los valores originales.
Lo segundo es trivial.
La tercera condicion obliga a usar un debugger pequenyo. Pero hay un
truco: podemos saltar a cualquier otra rutina. Lo malo es que hay que
actuar manteniendo la cuarta regla.
Ahora, olvidate por un momento de que los programas se cargan en direcciones
de memoria virtuales: suponte que existe una direccion fija (llamada
mi_debugger_grande) y que cualquier programa puede saltar a ella.
(Aviso: el siguiente parrafo solo lo entenderas si sabes de arquitectura ARM)
Para saltar a esta rutina podemos usar la instruccion:
- B (branch) , pero solo permite saltar al mismo segmento de memoria, es
decir, esta limitado a saltos de maximo 0xFFFF bytes
- BL (branch location), que admite saltos largos pero modifica el
registro LR
- BX (branch extended), que necesita un registro, en la forma BX Rb
Usare este tercer modo. Ahora necesito un registro Rb que pueda corromper
sin alterar el programa, por ejemplo R11 porque no he visto ningun programa
que lo use. Es cierto que lo usa el kernel a veces, pero no interfiere.
Entonces queda:
mi_debugger:
LDR R11, =mi_debugger_grande
BX R11
off_XXX3 DCD mi_debugger_grande
Y ahora es cuando viene la sorpresa: de verdad existe tal direccion
de memoria ! De hecho existen muchas, por ejemplo 0x85740000.
La explicacion vendra en un parrafo posterior.
Por tanto queda (en pseudo-codigo)
org 0x85740000
mi_debugger_grande:
guarda_registros
dump_registros
dump_direccion_origen
dump_direccion_destino
restaura_registros
BX R12
Si te interesa de verdad este debugger, sigue leyendo.
Para guardar los registros usare la pila. Seguro que modificare los registros
R1, R2, ... R7 asi que los puedo almacenar todos con una unica instruccion
STMFD SP!, {R1-R7} ; equivalente a push R1, push R2, ... push R7
Decido que para almacenar los datos interesantes usare la direccion de
memoria 0x85750000 y siguientes:
LDR R7, =0x85750000
El primer dato de esta zona sera un contador que me dice cuantos datos he
guardado, y me sirve para saber donde meter el siguiente.
LDR R6, [R7]
Ahora debo incrementarlo. Cada vez que se invoca al debugger grabare 8 datos
de 4 bytes. Asi que el contador se incrementa en 32 cada vez.
En hexadecimal 32 vale 0x20
ADD R6, #0x20
y lo vuelvo a meter en 0x85750000
STR R6, [R7]
Ahora debo apuntar al primer byte que esta libre:
ADD R7, R6
y empiezo a meter los datos; primero los argumentos R1, R2, R3 enviados a
la rutina:
STR R1, [R7+#0x00]
STR R2, [R7+#0x04]
STR R3, [R7+#0x08]
El registro R0 tambien es util
STR R0, [R7+#0x0C]
Ahora la direccion origen. En Symbian, las rutinas se llaman con la
instruccion
BL stub_XXX
que hace que el registro LR almacene la direccion a la que se debe retornar.
Por eso lo puedo "dumpear" haciendo
STR LR, [R7+#0x10]
La direccion destino es justamente R12
STR R12, [R7+#0x14]
Y ahora me queda hueco para otros 2 registros: uno es la pila
SP (Stack pointer).
Pero para obtener el valor original debo substraer los 7 datos R1-R7 que he
metido al principio, que ocupan 4 bytes cada uno
MOV R1, SP
SUB R1, #0x07*4
STR R1, [R7+#0x18]
y el otro es el registro PC, que contiene los flags (N, Z, V, I).
El resto de los flags no interesan, pero aun asi los guardo tambien
STR PC, [R7+#0x1C]
recupero los registros de la pila:
LDMFD SP!, {R1-R7} ; equivalente a pop R7, pop R6, ... pop R2, pop R1
y salto a donde debo saltar
BX R12
Para poner todo el tinglado en marcha necesito varios programas:
-Uno en ensamblador ARM con las 20 instrucciones anteriores. Lo compilo
con GCC-ARM y me genera un mini-fichero de 20*4 bytes.
Al resultado lo llamo 0x85740000.bin
-Otro en el PC que transfiera este fichero al movil. Dado que tengo
infrarrojos en el movil y en el ordenador, uso el IrFtp de Windows.
-Otro en el movil que cargue 0x85740000.bin en la direccion 0x85740000 .
Este programa lo hago en Symbian. Lo explicare en un parrafo posterior
-El programa victima, adecuadamente parcheado
-para eso me hago un programa parcheador. Basicamente:
-busca
LDR R12, [R12] ; bytes 00C09CE5
BX R12 ; bytes 1CFF2FE1
-y los substituye por
LDR R12, [R12] ; bytes 00C09CE5
B mi_debugger ; bytes xyzt00EA ,donde xyzt depende de donde puedo
meter mi_debugger
-busca un hueco libre donde escribir el lanzador
mi_debugger:
LDR R11, =0x85740000
BX R11
off_XXX3 DCD 0x85740000
-como ocupa 3 instrucciones, necesito 3*4 bytes. Estos 12 bytes los localizo
yo a mano. Normalmente lo que hago es machacar una zona del programa que
me parezca que no se usa.
-Otro programa que vuelca la traza generada a partir de 0x85750000
-Para transferirlo al PC uso de nuevo el IrFTP
-Hago otro programa para visualizar estos datos. Las rutinas "destino" son
del sistema operativo, por lo que puedo darles nombre. Lo unico que
necesito es saber la direccion donde estan almacenadas cada una.
Las rutinas "origen" son del programa victima, y obviamente no puedo saber
sus nombres. En esto consiste el arte del desensamblado, ?no?
--------------------------------
Este es el programa Symbian que mete el fichero 0x85740000.bin en la
direccion 0x85740000
RFs fileSession;
TInt open_result, direccion, valor;
TBuf8<4> four_bytes;
_LIT(x85740000_bin,"c:\\0x85740000.bin");
fileSession.Connect(); // conecta con el servidor de archivos
open_result=filep.Open(fileSession, x85740000_bin, EFileRead);
// abre el fichero 0x85740000.bin
if(open_result==KErrNone) // si todo ha ido bien ...
{
direccion = 0x85740000;
for(i=0;i<20*4;i+=4) // bucle de 20 instrucciones
{
filep.Read(four_bytes); // cada instruccion ocupa 4 bytes, que
// meto en un array
valor=four_bytes[0]%256 // y lo meto en un TInt, que ocupa 4 bytes
+ (four_bytes[1]%256)*256
+ (four_bytes[2]%256)*256*256
+ (four_bytes[3]%256)*256*256*256 ;
Mem::Copy(&valor, direccion, sizeof(TInt)); // lo meto en memoria
direccion+=4; // y salto a la siguiente direccion
}
}
El programa inverso que mete las tramas en un fichero es similar, usando
como origen la direccion 0x85750000 .
-------------------------
Como ejemplo, voy a modificar el programa Spectrian V1.51 by White Cloud.
Esta aplicacion es un emulador de ZX-Spectrum para telefonos moviles.
Lo puedes obtener desde www.whitecloudsoftware.com
Se compone de varios ficheros, y el programa se llama Spectrian.app
Al ser un programa comercial, necesita un numero de serie, o de lo contrario
caduca a los 30 dias. Simplemente por diversion, voy a intentar eliminar esta
limitacion. Una vez mas te emplazo a pagar por el software que uses.
Primero hay que ver como actua el programa: lo arranco, y veo que si no esta
registrado, aparece un mensaje indicando el modo de registrarlo (pagando,
claro).
Este mensaje permanece durante 3 segundos, que se que hay que transformarlo
en milisegundos, dando la cifra 3000000 , o sea, 0x2DC6C0.
Desensamblo con IDA, y busco los sitios donde se usa el dato 0x2DC6C0.
Lo encuentro en la rutina 1000262C.
Cambio el valor a 1 segundo con mi editor hexadecimal, transfiero el programa
parcheado, y ahora efectivamente el mensaje aparece solo durante 1 segundo.
Pero con esto no consigo eliminarlo.
Asi que voy a usar mi debugger.
Esta aplicacion usa (10020EB8-1001EBB8)/4 = 0x8C0 stubs, desde
1001EBB8 ; CBase::newL(unsigned int)
1001EBB8 LDR R12, =newL__5CBaseUi
1001EBBC LDR R12, [R12]
1001EBC0 BX R12
1001EBC4 off_1001EBC4 DCD newL__5CBaseUi
.....
hasta
.....
10020EB8 ; PlpVariant::GetMachineIdL(TBuf<128> &)
10020EB8 LDR R12, =GetMachineIdL__10PlpVariantRt4TBuf1i128
10020EBC LDR R12, [R12]
10020EC0 BX R12
10020EC4 off_10020EC4 DCD GetMachineIdL__10PlpVariantRt4TBuf1i128
Parcheo estas 2240 rutinas haciendo que salten a la direccion
libre 0x10022550
org 0x10022550
mi_debugger:
LDR R11, =mi_debugger_grande
BX R11
off_XXX3 DCD mi_debugger_grande
mi_debugger_grande DCD 85740000
Y en la direccion 0x85740000 coloco mi debugger.
Pongo en marcha el programa victima, y una vez que ha salido el mensaje
diciendo que no esta registrado, vuelco la memoria a partir de 0x85750000,
que es donde mi debugger ha escrito la traza de las rutinas interceptadas.
Por ejemplo, una de tales trazas me dice
R0=00401628 R1=004037C4 R2=00000004 R3=80000368
R12=502801F0 R4=00000000 LR=FFFD3934 SP=00403844
?Como se interpreta esto?
Lo primero es el dato LR=FFFD3934 que indica la direccion del programa desde
el que se ha llamado a la rutina debugeada.
El desensamblador IDA cree que todos los programas se ejecutan a partir de
la direccion 0x10000000.
Esto no es del todo correcto, pues el cargador de Symbian se encarga de
buscar una direccion de memoria libre en el propio telefono. Debido al
sistema de memoria paginada, esto suele ser 0xFFF?0000 , en
nuestro caso 0xFFFD0000
Por tanto
LR=FFFD3934
equivale a la direccion 0x10003934 en el desensamblado.
Vamos a mirar el codigo en esa direccion:
10003928 MOV R2, #4
1000392C BL sub_1001EE78
10003930 ADD R0, SP, #0x148
10003934 BL sub_10020EB8 <---- aqui lo hemos interceptado
10003938 MOV R4, #0
1000393C ADD R5, SP, #0x40
Y tambien
10020EB8 ; PlpVariant::GetMachineIdL(TBuf<128> &)
10020EB8 LDR R12, =GetMachineIdL__10PlpVariantRt4TBuf1i128
10020EBC LDR R12, [R12]
10020EC0 BX R12
10020EC4 off_10020EC4 DCD GetMachineIdL__10PlpVariantRt4TBuf1i128
Combinando con
R12=502801F0
esto quiere decir que
la rutina
PlpVariant::GetMachineIdL(TBuf<128> &)
esta (en mi modelo de movil) en la direccion 0x502801F0 y Spectrian la
invoca desde 10003934 .
En otros modelos de moviles, estara en otra direccion.
Mas tarde explicare una consecuencia importante de esto.
Siguiendo con la explicacion de la traza, la rutina
PlpVariant::GetMachineIdL
necesita un argumento
TBuf<128> &
que combinado con
R1=004037C4
significa que la variable usada como argumento esta en la direccion
004037C4
Si tuviera un debugger en condiciones podria ver el valor de esta variable.
Lo importante es saber que el segmento
0x00400000
contiene los datos del programa en ejecucion, es decir, toda la zona de
variables completa.
Asimismo, R0=00401628 indica que la zona de variables locales a esta rutina
esta en la direccion 00401628.
El valor
R2=00000004
es consistente con la linea
10003928 MOV R2, #4
Por hacer un pequenyo resumen:
-valores de 0x0040???? indican variables del programa
-valores de 0x50?????? indican direcciones de rutinas del sistema operativo
-valores de 0xFFF????? rutinas del programa, equivalente a 0x100????? en IDA
Ya que tenemos las trampas preparadas, vamos a ver que atrapamos.
En el programa encuentro la palabra "RegCode2" que parece bastante sugestiva:
1002254C aRegcode2 unicode 8 , <RegCode2>,0
Esto es tipico de Symbian: cada palabra es en realidad una estructura
de datos:
-el primero (ocupa 4 bytes) es la longitud de la palabra
-el segundo es la palabra, donde cada letra ocupa 2 bytes en formato unicode
-el ultimo (2 bytes) es 00 00 , indicando el fin de cadena
A lo que iba: IDA me dice que esta palabra esta referenciada desde
10003384 LDR R1, =Regcode2
10003388 ADD R0, SP, #0x28
1000338C SUB R0, R0, #4
10003390 BL Compare__C7TDesC16RC7TDesC16 ; TDesC16::Compare(TDesC16 const &)
10003394 CMP R0, #0
10003398 BNE loc_100033B8
O sea, que en
[SP, #0x28]
hay un puntero, y se compara con la palabra "Regcode2"
Si no son iguales, salta a loc_100033B8
Si son iguales, se hace
...
100033AC BL Val__6TLex16Rl ; TLex16::Val(long &)
100033B0 LDR R3, [SP,#0x59C+var_59C]
que sirve para transformar una cadena del tipo "1234" en su valor
numerico 1234.
Bueno, parece que esta es una buena rutina para investigar.
Asi que busco en mis trazas donde se ha llamado a esta rutina
TLex16::Val(long &)
A partir de ahi, con el desensamblado en una ventana, y el traceado en otra,
me hago una idea de lo que hace el programa, y dispongo de la posibilidad de
analizarlo off-line.
Para completar este parrafo, dire que hay un fichero
Spectrian.prf
que contiene la cadena
Regcode2=xxxxxxx
y la rutina previamente analizada se encarga de leerla usando
TFileText::Read(TDes16 &)
Mas tarde, se llama a
PlpVariant::GetMachineIdL(TBuf<128>
para averiguar el numero de serie unico del movil.
Luego se calcula un codigo y se compara con xxxxxxx usando
TDesC16::Compare(TDesC16 const &)const
Si la comparacion no es correcta, entonces se hace:
10000A30 MOV R5, #0
mientras que si el programa esta satisfactoriamente registrado entonces
10000A24 MOV R5, #1
saltando en ambos casos a
sub_10003824
donde se verifica este valor.
Si es distinto de 0, entonces no aparece la pantalla de registro.
Resulta trivial parchear el programa para que evite esta ultima comparacion,
y siempre se piense que el progama esta registrado.
Ahora, a jugar al Saimazoom !
---------------------
Otro programa muy util para Symbian es TomTomCityMaps.
Contiene planos de varias ciudades del mundo. Existe otras versiones
TomTomMobile y TomTomNavigator pero ocupan mucha mas memoria.
El problema con CityMaps es que no funciona en el SX1.
Puedes iniciar el programa, pero se queda en la pantalla de inicio.
Cuando pulsas una tecla da un error, aunque no finaliza el programa.
No tengo ni idea de si podre arreglarlo, pero al menos lo intentare.
La estrategia es la misma: interceptar todas las rutinas para ver lo que
hacen.
Cuento con la ventaja de que el programa funciona en un movil Nokia, por lo
que puedo instalar el programa parcheado en ambos. Si una rutina devuelve un
resultado totalmente diferente (mas alla de lo razonable) entonces habra que
investigar en detalle dicha rutina.
El programa llama a (100624D0-1005F7D4)/4 = 0x0B3F rutinas del sistema
operativo, y hay 12 bytes libres en 100634A0, suficientes para poner
mi_debugger.
Arranco el programa, y en cuanto da el mensaje de error, vuelco la memoria a
partir de 0x85750000.
Una de las ultimas rutinas ejecutadas ha sido:
R0=0040F838 R1=00407304 R2=100059BE R3=80000368
R12=5015A6DC R4=00000000 LR=FFF548F0 SP=0040873C
O sea, que se llama desde FFF548F0 (equivalente en IDA a 100048F0)
a la rutina en 5015A6DC.
Segun IDA, la rutina es CListBoxData::Reserved_2(void)
Esto es un poco raro. El codigo desensamblado que precede a 100048D8 no
contiene llamadas a rutinas relacionadas con la clase CListBoxData , sino
que son llamadas a AVKON , por lo que me extranya que se llame a una rutina
que, ademas, tiene el extranyo nombre "Reserved_2".
El desensamblado es:
100048DC MOV R1, R0
100048E0 MOV R6, #0
100048E4 ADD R4, SP, #0x2C
100048E8 MOV R0, R4
100048EC LDR R2, =(loc_100059BC+2)
100048F0 BL sub_10060F34 ; CListBoxData::Reserved_2(void)
100048F4 MOV R0, R4
100048F8 BL sub_100617F4 ; TRect::Width
100048FC ADD R1, SP, #0x1C
10004900 STR R0, [SP,#0x98+var_7C]
10004904 STR R6, [R1,#4]
10004908 MOV R0, R5
1000490C BL sub_10061804 ; TSize::TSize
Tambien hay que fijarse en que justo antes de llamar la rutina en 100048F0
se establecen los argumentos R0, R1 y R2, lo cual no es consistente con que
CListBoxData::Reserved_2(void)
no acepte argumentos.
Esto me hace sospechar que IDA no ha desensamblado bien la rutina.
La manera de comprobarlo es mirar la rutina que hay en R12=5015A6DC
Lo he mencionado en otro articulo, pero merece la pena repetirlo: yo tengo un
listado completo de las direcciones de las rutinas del mi movil Siemens-SX1.
No tengo el codigo fuente de Symbian, pero se el nombre de cada rutina, y
con eso y un poco de imaginacion me hago una idea de su uso.
En particular miro R12=5015A6DC y descubro que es
CPeriodic::Start(TTimeIntervalMicroSeconds32, TTimeIntervalMicroSeconds32, TCallBack)
y no CListBoxData::Reserved_2(void) como IDA me habia dicho.
Esto tiene mejor pinta. Esta rutina admite 3 argumentos, y el tercero es la
direccion de una rutina que se llamara cuando transcurra el tiempo
establecido.
En mi caso esta rutina CallBack se define en
100048EC LDR R2, =(loc_100059BC+2)
El codigo
100059BC MVN R7, #0
100059C0 LDR R1, [R5,#0xA0]
100059C4 ADD R2, R4, R4,LSL#1
100059C8 RSB R2, R4, R2,LSL#3
parece ciertamente una rutina, pero hay algo intrigante:
?Porque se llama a loc_100059BC+2 ?
Esto significa saltar en medio de la instruccion
MVN R7, #0
y eso no es posible.
O bien salta a 100059BC, o a 100059C0. Nunca a 100059BC+2
En la arquitectura ARM, las instrucciones estan siempre en direcciones
multiplo de 4. Al menos eso es lo que dice el manual de ARM.
Lo que me extranya es que funcione en un Nokia. Tras posteriores
investigaciones concluyo que el Nokia siempre redondea las direcciones hacia
el multiplo de 4.
Pero el SX1 no lo hace.
Asi que el cambio es evidente: en 100048EC debe apuntar a loc_100059BC en
vez de loc_100059BC+2
Hago el cambio, y el programa ahora funciona ! Ya puedo ir a Valencia sin
temor a perderme por sus calles.
-------------
Como he dicho antes, cada modelo de movil tiene las rutinas del sistema
operativo en direcciones de memoria distintos. La carga dinamica de programas
convierte las direcciones indexadas en direcciones reales, y IDA es capaz de
interpretarlas, aunque a veces se equivoque.
Mi listado del SX1 incluye mas de 30.000 rutinas del sistema operativo,
aunque posiblemente menos del 80% son usadas por algun programa.
En el movil existe una tabla que contiene las direcciones de todas las
rutinas.
En el SX1 esta tabla esta en 0x50F00000 y llega hasta 0x50F25000 , haciendo
un total de 40.000 rutinas.
En el Nokia N70, van desde 0x500FF000 hasta 0x50130000, unas 50.000 rutinas.
Si cambiamos en la ROM la direccion de esta rutina, podemos hacer que salte a
una rutina propia. En los moviles Siemens es posible actualizar la memoria
uno mismo. En los Nokia supongo que tambien, aunque creo que hace falta un
cable especial.
Sea la funcion
CCoeControl::SetDimmed(int)
que en mi SX1 esta en la direccion 0x5065C93C, referenciada desde 0x50F16340
que sirve para ocultar(1) o mostrar(0) un menu.
Sin duda, se llamara haciendo
LDR R12, =SetDimmed__11CCoeControli
LDR R12, [R12]
BX R12
off_10000F1C DCD SetDimmed__11CCoeControli
Para saber donde esta ubicada esta rutina en el Nokia N70, hago un programa
en Symbian que oculta el menu. Lo parcheo con mi debugger e intercepto la
llamada a CCoeControl::SetDimmed(int)
Miro el registro R12, que contiene la direccion real de la rutina, y
averiguo que esta en 0x50787148
Supongamos que queremos que nunca se oculten los menus en ninguna aplicacion.
Obviamente puedo parchear la rutina 5065C93C (o 50787148 en el N70), pero es
mas flexible hacer:
-hacer que 0x50F16340 no apunte a 0x5065C93C, sino a 0x5071BE90
-buscar un espacio libre en la ROM, por ejemplo en 0x5071BE90
-desensamblar la rutina en 5065C93C
-modificarla a mi gusto, es decir, haciendo que no considere el primer
argumento, sino que siempre muestre el menu
-compilarla usando el GCC-ARM o el compilador Kiel
-meter el codigo generado en la direccion 0x5071BE90
Esto me permite modificar el sistema operativo a mi gusto, siempre que sea
capaz de entender lo que hace la rutina parcheada, claro.
---------------------------------------------
Uno de los problemas mencionados es que IDA no es siempre capaz de entender
correctamente las llamadas a rutinas externas.
Un programa Symbian de tipo APP contiene una cabecera llamada E32ImageHeader
o TRomImageHeader definido en el SDK en e32rom.h , definiendo los parametros
del programa, tales como version, fecha de construccion, tamanyo de la pila,
numero de librerias usadas, y nombres de tales librerias.
Por cada libreria hay una lista de las funciones usadas dentro de ella.
Por ejemplo, hago un programa prueba.app que llama a
TFindLogicalChannel::Next(TFullName& aResult)
que segun la documentacion del SDK, esta declarado en
e32std.h
y tengo que linkar con la libreria
euser.lib
que usara
euser.dll
Por eso IDA muestra:
; Segment type: Externs
....
; Imports from EUSER[100039e5].DLL
....
IMPORT Next__19TFindLogicalChannelRt4TBuf1i256
....
Vemos que incluye las palabras TFindLogicalChannel y Next pero ?que
son todos esos numeros?
Pues son los tipos de argumentos. Por ejemplo, una longitud de TBuf se
llama "i1".
Asi que empezando por el final:
TBuf1i256
quiere decir que el argumento recibido es
(TBuf<256> &)
que es lo mismo que
TFullName& aResult
Luego, Rt4 es un puntero a TBuf .
Despues, _19T significa que es un metodo publico de la
clase TFindLogicalChannel.
En realidad esto se puede deducir de los ficheros *.h del SDK.
Como IDA no es capaz de entender los argumentos ni los datos de salida,
presenta el nombre largo, y eres tu el que tiene que interpretarlos.
Ahora bien, la palabra "TFindLogicalChannel" no esta dentro de prueba.app ,
asi que la pregunta es ?de donde los saca IDA ?
Si miras el programa prueba.app en binario veras que
Next__19TFindLogicalChannelRt4TBuf1i256
esta representado por los bytes
0xFC020000
que pasados a little-indian son
0x000002FC
o sea 764 en decimal.
Ahora vas al directorio del SDK donde tengas
euser.lib
que en mi caso es
C:\Symbian\6.1\Siemens\SX1\bin\epoc32\release\armi\urel
y haces
ar -xv euser.lib ds00764.o
el cual extrae de la libreria euser.lib el fichero ds00764.o
Dentro de el encuentras la palabra
Next__19TFindLogicalChannelRt4TBuf1i256
como era de esperar.
Asi que IDA debe tener en algun sitio una lista que le dice que
la liberia euser.lib contiene la rutina 0x000002FC y se llama
Next__19TFindLogicalChannelRt4TBuf1i256
Y algunas de las rutinas no contienen el nombre correcto. Por eso se
confunde con alguna rutinas.
Lamentablemente no he encontrado esta lista en IDA, asi que supongo que
esta comprimido.
Pero lo que si puedo hacer es ayudarle:
1-dejo que desensamble el programa (quizas con algun error)
2-lo exporto a un fichero de texto
3-extraigo la zona de rutina importadas
4-miro las librerias, ej. user.dll
5-miro las funciones, ej. 0x000002FC
6-lo paso a decimal: 764
7-extraigo la funcion 764 de user.lib usando "ar"
8-saco el nombre de la rutina desde el fichero extraido ds00764.o
9-saco los nombres de los argumentos con la utilidad dumpbin
10-los meto en un fichero prueba.idc
11-le digo a IDA que re-lea los nombres de las rutinas desde prueba.idc
Para los pasos 7-9 sigo las instrucciones de Mika Raento en
www.cs.helsinki.fi/u/mraento/symbian/reverse.html
que basicamente explica como obtener los nombres de los argumentos (proceso
conocido como "demangling").
Tambien uso este procedimiento para analizar el listado producido
por mi_debugger. Recordar que
R12 vale la rutina Symbian que es invocada
LR es la rutina invocante
Mencionar que el SDK incluido en IDA 4.9 permite arreglar estos fallos y
regenerar el archivo que contiene la lista de funciones externas.
Pero esto lo dejo para otro articulo en el que contare cosas sobre IDA.
---------------------------------------------
?Que se puede hacer con esta metodologia?
Uno de los parches que mas me ha gustado hacer es cambiar la unidad Z: por C:
Me explico: las aplicaciones internas del movil estan en el disco Z:, que es
de solo lectura (se pueden cambiar en el SX1 usando un program especial y
re-escribiendo la flash, pero es un rollo hacer esto).
Estas aplicaciones usan ficheros con datos que estan tambien en Z:
Por ejemplo, la aplicacion del reloj (Clock.app) usa unos dibujos que
estan en
Z:\System\Data\Clock.mbm
Si no te gustan estos dibujos, no puedes poner otros.
Pero si consiguiera que busque
C:\System\Data\Clock.mbm
en vez de
Z:\System\Data\Clock.mbm
entonces podria cambiar los dibujos, ya que C: es de lectura y escritura.
?Como se sabe donde buscar?
En principio, la aplicacion Clock.app es la que decide donde estan los
dibujos que va a usar. Normalmente se calcula el directorio donde ella misma
esta instalada (Z:\System\Data\Clock.app) y los busca en su mismo directorio.
Otras veces, sin embargo, incluye la ruta completa, es decir, que
Z:\System\Data\Clock.app
contiene la palabra
Z:\System\Data\Clock.mbm
Es este caso solo hay que parchear la memoria flash usando la unidad C: , es
decir, en el fichero Z:\System\Data\Clock.app hay que reemplazar
Z:\System\Data\Clock.mbm
por
C:\System\Data\Clock.mbm
Esto es lo que hacen muchos de los parches. Lo malo es que sirve solo para
este programa Clock.app y este fichero Clock.mbm en concreto.
Seria mas flexible hacer un metodo generico.
La manera de abrir un archivo es llamando a la rutina
RFile::Open(RFs &, TDesC16 const &, unsigned int)
donde el segundo argumento es el nombre del fichero, incluyendo la unidad de
disco y el directorio.
Esta rutina esta en 0x50195C1C, referenciada desde 0x50F03C7C
Asi que solo tengo que parchear esta funcion:
-si el nombre del fichero comienza por "Z:" entonces:
-sustituyelo, poniendo C: al principio
-busca
-si no lo encuentra, busca el original (en Z: ) . Devuelve el resultado
-si lo encuentra, devuelve el resultado (exito)
-si no, llama a la rutina original sin cambiar nada
En lenguage C++/ASM :
org 0x50F03C7C
call mi_RFile::Open // el original hace call 0x50195C1C
mi_RFile::Open(RFs & mi_RFs, TDesC16 const & mi_archivo, unsigned int mi_flag)
{
TDesC16 & mi_archivo_en_C;
if(mi_archivo.StartsWith("Z:"))
{
mi_archivo_en_C=mi_archivo.Replace("Z:", "C:");
result = original_RFile::Open(mi_RFs, mi_archivo_en_C, mi_flag); // en 0x50195C1C
if(result<>KErrNone)
return original_RFile::Open(mi_RFs, mi_archivo, mi_flag);
else
return result;
}
else
{
return original_RFile::Open(mi_RFs, mi_archivo, mi_flag);
}
}
Obviamente esta idea no es nueva: cualquier rootkit de PC en Linux o Windows
hace esto.
No solo he aumentado la flexibilidad; ahora un monton de ficheros no se
obtienen desde Z: sino desde C: , lo cual libera espacio que puedo usar
para mis propias rutinas.
Es mas, puedo extender esta rutina para que me diga cuales son los ficheros
que se intentan abrir.
Cuando cualquier aplicacion abra un fichero, yo lo sabre. Un sniffer para
moviles similar a Filemon (www.sysinternals.com).
-------------
Hay una aplicacion de pago llamada SystemExplorer by Justek (www.justek.us)
que permite trabajar con ficheros. La diferencia con FExplorer es que puede
mostrar el contenido de ficheros con formato de base de datos.
Por ejemplo el fichero c:\system\data\cdbv2.dat es una base de datos.
Este fabuloso programa (ayuda a sus autores ! ) tiene una proteccion para que
solo se pueda usar durante 15 dias. Luego caduca.
Gracias al parche anterior averiguo que uno de los ficheros que abre es
C:\system\data\lm2004.dat
Desensamblo el programa SystemExplorer.app y veo que efectivamente hace algo
con este fichero.
Asi que cierro el programa, borro el fichero lm2004.dat , lo inicio de
nuevo, y veo con satisfaccion que me permite usarlo durante otros 15 dias. Ha
sido demasiado facil crackearlo.
-------------
Como hemos visto, modificar programas Symbian no es mas complicado que
modificar programas de Windows.
Por supuesto no hay tanta documentacion, pero la tecnica de interceptar
rutinas funciona bastante bien.
Mi agradecimiento a entusiastas como "18+2", Eric Bustarret, MacKam, Mika
Raento, y el Z-TeAm que han hecho accesibles estos conocimientos.
Y por supuesto, tantos y tantos programadores de Symbian repartidos por
todo el mundo. Ellos son los que hacen que cada dia sea mejor que el anterior.
*EOF*
