-[ 0x08 ]--------------------------------------------------------------------
-[ SX1-Segunda parte ]-------------------------------------------------------
-[ by FCA00000 ]-----------------------------------------------------SET-32--

28/09 *********** Mircoles ***********
El parche de aumentar el tiempo de infrarrojos no ha tenido tanto xito. Al 
parecer la gente usa BlueTooth para transferir sus ficheros hacia el mvil, o 
los mete en la tarjeta MMC usando un PC.
En fin, no me extraa, pero yo no tengo ninguna de esas posibilidades. Bastante 
contento estoy con que mi ordenador tenga infrarrojos...

Hoy voy a un cursillo de cata de vinos. Carpe Diem !

29/09 *********** Jueves ***********
Un usuario de www.siemens-mobile.org ha pedido que alguien publique un parche 
especial: El SX1 es Series60v1.2 (Symbian 6.1), mientras que algunos de los 
juegos necesitan Series60v2.0 (Symbian 7.0), el cual se encuentra, por ejemplo,
en el Nokia 7310 . El parche debera engaar al instalador para que, al menos,
se puedan instalar, aunque posteriormente no funcionen porque haga falta algn 
dispositivo especial.

Dentro del sistema de archivos existen 4 llamados Series*.sis :
Series60v0.9.sis
Series60v1.0.sis
Series60v1.1.sis
Series60v1.2.sis

La razn es que para instalar un programa, necesitas tener exactamente esa 
versin, que puede que no sea compatible con las anteriores. Por ejemplo, si 
no tienes Series60v1.1.sis , puedes instalar una aplicacin para 1.2 , o para 
1.0 , pero no para 1.1

El truco para permitir instalar aplicaciones para Series60v2.0 es tomar 
Series60v2.0.sis desde un Nokia 7310 y usarlo en vez de, por ejemplo, 
Series60v1.0.sis. Esto hace que no se puedan instalar las aplicaciones 
especficas para v1.0 pero creo que hay pocas que necesiten exactamente esta 
versin.

Cuando compilas tu propia aplicacin, necesitas un fichero *.pkg en el que 
indicas la versin mnima que necesitas de sistema operativo.
Por ejemplo
(0x101F6F88), 0, 0, 0, {"Series60ProductID"}

dice que necesitas que previamente est instalado el fichero con UID 0x101F6F88
Este UID son los primeros 4 bytes presentes en el fichero Series60v0.9.sis
Si los cambio, la aplicacin anterior no se podr instalar.
Por ejemplo, una aplicacin puede necesitar que una DLL en particular est 
instalada, o que slo funcione en un modelo de mvil.
El fichero
SiemensSX1.SIS
comienza con los bytes 0x101F9071
As, si quisiera hacer una aplicacin que slo funcione en el SX1, debera 
incluir en el *.pkg esta lnea:
(0x101F9071), 0, 0, 0, {"Series60ProductID"}

Pero para hacer que el SX1 parezca como Series60v2.0 no slo hay que cambiar 
el nombre del fichero Series60v1.0.sis por Series60v2.0.sis ; sino que tambin 
hay que cambiar el contenido.

Por tanto, busco en toda la flash la cadena
"Series60v1.0.sis" y la cambio por "Series60v2.0.sis"
y tambin 0x101F6F88 (UID del Series60v1.0.sis) por 0x101F7960 (UID del 
Series60v2.0.sis) 

Tras aplicar los cambios en mi mvil pruebo a instalar una aplicacin 
especfica para Nokia 7310 , y veo con deleite que se deja instalar. Si 
funciona o no, eso es otro asunto.

Lo meto en un fichero, le pongo una explicacin indicando su peligrosidad, y 
ya est listo para publicar.

Maana ser otro da.

30/09 *********** Viernes ***********
En vista de que puedo hacer parches, recibo unas cuantas sugerencias para 
desarrollarlas. Lamentablemente no tengo todos los conocimientos que 
necesitara, adems de la falta de tiempo.
Por eso, ni siquiera investigo las peticiones que slo vienen de 1 persona. 
Tambin rechazo algunas que s que son imposibles.
Por ejemplo, hay gente empeada en instalar Symbian 8.0 en el SX1. Eso es 
totalmente imposible. El hardware necesario no est dentro del SX1, por no 
mencionar que necesitara mas potencia, y ms memoria.
Esto me recuerda cuando la gente del Commodore queran crear un emulador del 
Amstrad.

Tambien recibo un par de ofrecimientos para ayudarme a hacer parches. Les 
indico las herramientas y conocimientos que necesitan, y se ponen en marcha. 
Espero que sea fructfero.

Algunas de las peticiones son para eliminar ms mensajes intiles. Adems de 
los de la instalacin, y los de cambiar la tarjeta MMC, quieren que elimine el 
que aparece cuando bloqueas el teclado.
Estoy de acuerdo; es bastante molesto.
Hay otro que me gustara eliminar: cuando la batera se llena de nuevo, el 
telfono se enciende y emite un pitido breve.
Como sto suele suceder de noche, me despierta, lo cual me irrita mucho.
Pero este segundo parche es mas difcil de probar, ya que cuando la batera 
est rellena, hay que descargarla un poco antes de que se recargue de nuevo.

Como ya he dicho, la solucin sera encontrar dnde est el texto que aparece 
dentro del mensaje, y eliminar la llamada a la rutina que muestra el mensaje. 
Pero hasta ahora no he encontrado estos textos.

As que voy con el primero, para eliminar el mensaje cuando bloqueas el teclado pulsando la tecla "#" durante ms de 1 segundo.
Lo primero que encuentro es que hay un fichero llamado AknNotify.Std.h
que incluye una enumeracin TKeyLockNotifierReason
con los valores:
ELockEnabled
ELockDisabled
EAllowNotifications
EStopNotifications
EInquire
EOfferKeylock
ECancelAllNotifications

stos son los valores 0-6

Despues estn
struct SAknSoftNoteNotifierParams
{
TInt iNoteResource;
TInt iNoteCbaResource;
TInt iResponse;
};

struct SAknKeyLockNotifierParams
{
TKeyLockNotifierReason iReason;
TBool iEnabled;
};

Lo cual me lleva a hurgar en los ficheros
AknNotify.dll y AknNotifyPlugin.dll 
Un poco de investigacin me lleva a la conclusin de que AknNotifyPlugin.dll 
acaba llamando a CAknNoteDialog 
Elimino la llamada, pero entonces pierdo todas las notificaciones. Demasiado.

Pero no me cuesta mucho encontrar una subrutina que hace uso de una estructura 
de 3 int , lo cual podra ser SAknSoftNoteNotifierParams.

En realidad es ms fcil: el mensaje de que el teclado est bloqueado aparece, 
y al cabo de 1 segundo y medio desaparece automticamente.
Como 1 segundo y medio son 1.500.000 microsegundos, es decir, 0x0016E360 , 
busco este dato, el cual aparece 6 veces.
Lo cambio cada ocurrencia por un valor distinto, desde 3 segundos hasta 9.
Meto el firmware modificado, bloqueo el teclado, y veo que tarda 4 segundos en 
desaparecer.
Ya s cual es la rutina involucrada.

As que en la rutina original
LDR     R1, =0x16E360
MOV     R2, #0
BL      CAknSleepingNote::ShowNote_CAknNoteDialog(TTimeout CAknNoteDialog,TTone)

elimino la llamada al dilogo. Tambin podra reducir el tiempo a 0.001 
segundos, pero sto no me parece tanelegante.

Como veis, siempre hay ms de una manera de atacar al problema.
Estoy asombrado de m mismo: he hecho 4 parches en 4 das.

31/09 *********** Sbado ***********
Septiembre solo tiene 30 das, hombre !

01/10 *********** Sbado ***********
Otro de los parches ms solicitados es el de borrar la lnea horizontal.
En el SX1, si no ests en ninguna aplicacin, vuelve a la aplicacin llamada 
Phone.app que muestra la pantalla en 4 trozos:
1) el superior, con el indicador de potencia de red, carga de batera, mensajes
   pendientes, infrarrojos activado, ... ocupa 14 pixels.
2) el segundo, donde muestra un reloj, el proveedor de red, y la fecha. Se
   puede poner un dibujo de fondo. Ocupa 54 pixels.
3) el tercero, con un dibujo de fondo a eleccin del usuario. Ocupa 120 pixels
   de altura, ms o menos.
4) el de abajo, con el texto de OK y el de NO. ES posible cambiarlos para que
   arranquen cualquier aplicacin. Ocupa 16 pixels.

As que es posible hacer un dibujo de fondo de 54+120 dividido en 2 trozos. Lo 
malo es que entre ambos se dibuja una lnea horizontal de 1 pixel de grosor, 
que destroza el efecto visual e impide poner bonitos dibujos de fondo.
Lo que han conseguido otros antes que yo es cambiarle el color.

La pantalla ocupa 172 pixels de ancho.

En Symbian estan soportados varios modelos de pantalla: monocromo, 4-bits por 
pixel, 8-bits, 12-bits, o 24-bits.
La mayora de los dispositivos Symbian tienen como mnimo 12-bits, lo cual 
permite 4096 colores. El SX1 soporta 65536.
Es posible definir tu propio color, o usar una paleta de 256 colores. Esto 
permite tener distintos "esquemas" para el escritorio.
Por defecto existen 4 esquemas, pero hay un parche para usar 6.
Esta paleta define colores para el borde de las ventanas, el texto, el texto 
de un control, el texto de una advertencia, el texto de un error, el ttulo de 
la aplicacin, el ttulo de un dilogo, el men, ... y as hasta 60 colores 
distintos. El resto, hasta 256, estn libres.

Todo sto definido en gulcolor.h 
Uno de estos colores es el que se usa para dibujar la lnea horizontal, en 
concreto la entrada 0xF4 de la paleta.
As que empiezo a buscar ese dato en la aplicacin desensamblada Phone.app 
Aparece muchas veces, as que tengo que refinar la bsqueda para que est cerca
de algo que dibuje una lnea.

Imagino que la rutina ser algo parecido a:
SetColor(0xF4);
DrwaLine(0,54,172,54);

As que refino ms todavia la bsqueda para que una de las coordenadas sea 54, 
o bien 54+14

Encuentro la rutina adecuada, veo que tiene sentido, y decido que no llame a 
la rutina de dibujar la linea.
Efectivamente no dibuja la lnea, sino que en la coordenada y=54+14 deja el 
dibujo que estuviera anteriormente.
Ahora tengo que conseguir que la imagen 2) ocupe 54+1 pixel, o bien que la 
imagen 3) se dibuje un pixel ms arriba.

Lamentablemente no encuentro dnde se hace, y tras aproximadamente 15 pruebas, 
decido dejarlo para otro momento.
Esto es frustrante. Pierdo un montn de tiempo, y no obtengo nada.
Pero por otra parte es normal. ?Dnde encuentras las llaves que has perdido? 
En el ltimo sitio en el que buscas. Claro; porque una vez encontradas, dejas 
de buscar.

Si hubiera encontado pronto la solucin no habra perdido tanto tiempo.

A pesar de todo decido publicar un parche, por si alguien quiere seguir mis 
investigaciones.
Tambin sera posible hacer una aplicacin que cada 5 segundos mire si 
Phone.app est en primer plano, y en ese caso tomar el control, dibujar la 
lnea horizontal que quiera el usuario, y devuelva el control, sabiendo que 
Phone.app no la sobre-escribir. Pero sera un programa extra, que usara la 
batera intilmente.

02/10 *********** Domingo ***********
Hoy toca cambiar los muebles. Me niego a poner cosas de IKEA. Aunque compres 
un nico mueble, ya toda la casa parece hecha en IKEA. Es como un virus. Pero 
sto es lo nico en que yo no transijo. Lo dems, me suele parecer bien lo que 
mi chica disponga. Eso s, el cuadro de Modigliani no hay que ponerlo cerca del
de Munch.

Acabamos cansados, pero la casa parece otra. Lista para el invierno. Un 
consejo: si cubres el techo con telas, parece ms bajo y mas acogedor. Pero 
tambin ms oscuro.

03/10 *********** Lunes ***********
Los parches siguen creando expectacin. Lo que me sorprende es que no haya ms 
gente que los haya hecho. Para otros modelos de Siemens hay un montn de 
desarrolladores. Claro que el sistema de estos otros es distinto, y no es muy 
difcil adaptar un parche de un modelo inferior hacia otro superior. Pero el 
SX1 pertenece a otra familia conceptualmente distinta.

Cada vez me voy dando ms cuenta de que necesito una herramienta que me permita
saber por dnde se va ejecutando un programa.
Para el modelo S45 hice un emulador que me result realmente til (e 
interesante) as que pienso en hacer lo mismo para el SX1.
Busco por la red algn debugger para Symbian o para ARM, pero no encuentro nada
que se adapte a mis necesidades.
Un emulador de las instrucciones de ARM es sencillo, ya que apenas hay 20 
instrucciones y son fciles de codificar.
El sistema de memoria tampoco es complicado, excepto cuando accede a los 
puertos, la pantalla, el SIM o la MMC.
Pero no necesito tanto: simplemente hacer un volcado de la memoria del programa
en ejecucin, incluyendo la pila, y luego emular el programa en el PC.
En Symbian cada programa se ejecuta en un entorno protegido, y siempre parece 
que est en la direccin 0x00400000. Puede llamar a otras rutinas a travs de 
referencias (stubs), pero no puede leer memoria que no le pertenece.
La excepcin a sto es el kernel, ubicado en ekern.exe , que puede leer y 
escribir cualquier direccin, ya que se ejecuta en modo supervisor.
Para que una aplicacin pueda saltar ms alla' de sus lmites, debe pasar por 
las funciones de la librera User, que llamarn al kernel.
Otra posibilidad es usar un PDD (Physical Device Driver) o un LDD (Logical 
Device Driver), que tienen acceso a cualquier direccin de memoria.
Un tercer modo es llamar directamente a una interrupcin, que llamar al kernel
directamente.

Voy a explicar la tercera opcin:
La instruccin
SWI interrupt_number
hace que el kernel salte a
0x5000B0D8 ArmVectorSwi
que salta a la direccin 0x5000AD24 + 4*interrupt_number

Por ejemplo,
SWI 0xCD
mirar el dato de 0x5000AD24 + 4*0xCD=0x5000B058
que vale 0x5001B8D4

y el cdigo cdigo ubicado en esta direccin hace algo muy simple:
MVN R0, #4
RET

lo que indica que no ha sido procesado satisfactoriamente, con lo que la 
aplicacin que ha invocado esta interrupcin posiblemente ser terminada.
Pero puedo cambiar ese trozo de cdigo para que haga mas cosas, por ejemplo:
org 0x5001B8D4:
 MOV R12, [R12]
 MVN R0, #0 ; todo ha ido satisfactorio
 RET

Posiblemente no entiendas el sentido de la primera instruccin, as que te dir
cmo voy a llamarlo:

---- prueba.c --
....
int valor=0x50000000;
asm volatile ("MOV r12, %0" : : "r"(valor) : "r12" );
asm volatile ("SWI 0xCD" : : : );
asm volatile ("STR r12, %0" : "=m"(valor) );

paso a paso:
-la primera lnea indica la direccin de memoria que quiero leer, por ejemplo
 0x50000000
-la segunda pone ese valor en R12
-la tercera llama a la interrupcin, que acabar llamando a 0x5001B8D4
-en 5001B8D4, r12 tomar el valor de la direccin 0x50000000, por ejemplo
 0xEA000086
-al retornar, la tercera lnea lo pondr de nuevo en la variable   "valor"  ,
 con lo que la puedo mostrar en la pantalla de mi aplicacin

Esto parece una manera complicada de leer la direccin 0x50000000, pero es que 
se necesita pasar a modo supervisor.

He usado el registro R12 por una razn: los registros R0, R1, R2, R3 son 
comnmente usados en las rutinas, y si alguna otra interrupcin sucede mientras
la ma se esta procesando, casi seguro que machacarn estos registros.
En cambio R12 apenas se usa a lo largo del cdigo. Parece ser que los 
desarrolladores andaban sobrados de registros, y no lo necesitaban.

Con esto aprovecho para hacer volcados de varios trozos de memoria.
Hay un grave inconveniente: si leo una direccin que no est definida, el 
mvil se resetea.

Por ejemplo, la direccin en 0x60000000 no existe fsicamente, por lo que al 
intentar leerla, peta el mvil.

No me queda mucho tiempo para probarlo, pero es un gran paso.

04/10 *********** Martes ***********
Hoy he hecho volcados de:
0x50000000-16Mg = cdigo de los programas
0x50F00000-512 Kb = tabla de rutinas exportadas
0x58000000-32 Kb = pantalla?
0x5800A000-4 Kb = tabla de interrupciones hardware?
0x80000000-32 Kb = programa en ejecucin?
0x80400000-32 Kb = stack de otros programas en ejecucin?
0x81500000-32 Kb = pila de otros programas en ejecucin?
0x80400000-32 Kb = otros programas en ejecucin?
0xFF800000-4 Kb = memoria DMA de dispositivos?

Pero tendr que analizar con ms detalle todos estos volcados, porque no estoy 
seguro de su significado.
Lo que estoy convencido es que acabar encontrando un modo de volcarlos todos, 
y hacer una copia exacta de la memoria.
Mientras tanto, tengo que seguir buscando un emulador de ARM, con su cdigo 
fuente. A ser posible, que sea sencillo de entender.


05/10 *********** Mircoles ***********
Parcheando uno de los programas del mvil (Calculator, con UID=0x10005902) con 
el truco de llamar a SWI, he conseguido una imagen, tal como se estaba 
ejecutando. Lo he seguido a mano, con la ayuda del cdigo desensamblado (no 
tengo un debugger) y creo que la copia es bastante buena.
De paso he encontrado otros bloques de memoria que a los que accede el programa,
y que tambin he tenido que volcar.

El tema del debugger se podra solucionar con un JTAG, que es un protocolo 
usado para debuggear dispositivos ARM. Se conecta el dispositivo con el PC, se 
arranca el programa, se pone el mvil en modo "debug", y a partir de ese 
momento se puede tracear exactamente lo que est pasando paso a paso. Se 
pueden poner breakpoints, condiciones complejas, mirar la memoria, modificarla.
Pero necesito un cacharro de hardware para eso, y los que hay son un poco caros.
Hay un proyecto en sourceforge para hacerlo, pero como yo no tengo ni idea de 
electrnica, tendr que pedirle a alguien que lo construya para m.

06/10 *********** Jueves ***********
Hoy hemos sacado unos billetes para irnos a Croacia, a ver si nos da un poco el
sol. Salimos por la tarde y no volveremos hasta el Lunes. Creo que no me las 
merezco, pero sin duda me sentarn bien.
Me da el tiempo justo para publicar el parche que elimina el mensaje de bloqueo
de teclado, pues me doy cuenta de que se me haba olvidado anunciarlo.

07/10 *********** Viernes ***********
08/10 *********** Sbado ***********
09/10 *********** Domingo ***********
10/10 *********** Lunes ***********
11/10 *********** Martes ***********
La gente est bastante entusiasmada con los parches. En la web SMO apenas llevo
10 mensajes, y ya tengo 20 puntos de karma.
Es para estar orgulloso, ?no crees? Incluso gente que manda 3/4 mensajes por 
da no tienen ms de 15 puntos de karma, y los ms antiguos tienen 30 , excepto
los administradores y el mega-jefe, que tienen 70 . O todos los que quieran 
darse, claro.

Y en la web de CS se habla de hacerme Maestro, ttulo para el que normalmente 
se necesitan ms de 100 mensajes y mnimo 6 meses de antiguedad.

Esto demuestra varias cosas:
-cada esfuerzo tiene su recompensa
-la gente es agradecida
-las reglas estn para saltrselas
-la suma de los ngulos de un tringulo suman PI

Tengo un poco de tiempo para revisar las peticiones de parches. Uno de los mas
tiles parece ser uno para reducir la intensidad de la luz.

12/10 *********** Mircoles ***********
El Sx1 tiene 2 zonas de iluminacin: la pantalla y el teclado. Estas luces se 
encienden cuando pulsas cualquier tecla o cuando el mvil muestra un mensaje, y
se apagan al cabo de 20 segundos de inactividad. Lamentablemente no existe un 
programa para apagarlas antes, ni siquiera para reducir la intensidad de la luz.
Esto est incluido en los otros modelos de Siemens, as que supongo que la 
pantalla del SX1 es distinta y no permite graduar la luminosidad, o bien 
Symbian no tiene rutinas para hacer esto.
Pensando un poco veo que no puede ser lo primero, ya que cuando la pantalla se 
va a apagar, no lo hace de golpe, sino gradualmente. Esto quiere decir que la 
pantalla s que soporta distintos niveles de intensidad.
Y tambin Symbian lo permite, ya que es posible hacerlo en los Nokia.
Entonces, la nica razn es que los ingenieros del SX1 decidieron no incluir el
programa.
Es una pena, porque si se consiguiera bajar la intensidad, seguro que la 
batera durara ms.

Investigando el cdigo desensamblado del kernel veo que hay unas rutinas que 
ponen datos en 0x5800E000.
Esta direccin la he visto en U-boot, que es un intento de instalar Linux en 
dispositivos ARM, el cual espero investigar con detalle.
En particular, 0x58000000 contiene un montn de punteros a datos DMA 
compartidos entre la pantalla y la memoria, segn dice el manual del DMA.
En el kernel symbian, la zona a partir de esta direccin se usa en una rutina 
que obtiene el dato de algo llamado Sofia.
Buscando por la red he descubierto que Sofia es un chip que se encarga de 
proporcionar acceso a dispositivos externos, para procesadores de bajo consumo,
por ejemplo ARM. Parece que voy por el buen camino. Al menos tiene sentido 
lo que estoy averiguando.

El funcionamiento es sencillo: se pone un dato en una cierta direccin de 
memoria, y Sofia se lo manda al dispositivo.
O sea, que 0x58000000 es una zona de memoria de intercambio, y 0x5800E000 es 
la parte referente a la pantalla.
Ahora bien, ?cual es el dato? ?y cual es la direccin de memoria que almacena 
la intensidad?
Hago un volcado de 4Kb a partir de 5800E000 cuando la pantalla est apagada.
Hago otra copia cuando la pantalla est encendida, y anoto las diferencias.
Repito la prueba varias veces.

La diferencia es que hay 2 datos seguidos con valor #0x2B, en la direccin 
[5800E000+#0x2A] y [5800E000+#0x2B]. Notar que el valor #0x2B no tiene nada 
que ver con que sea la direccin [5800E000+#0x2B]. Es pura coincidencia.

El cdigo que lo inicia hace algo as:
....
LDR     R4, =0x5800E000
....
MOV     R3, #0x2B
STRB    R3, [R4,#0x2A]
STRB    R3, [R4,#0x2B]
....
BL      TSofiaSX1::WriteReq
....


El equivalente en lenguage C sera algo as:

int *p=0x5800E000, i=0x2B;
p[0x2A]=i;
p[0x2B]=i;
TSofiaSX1::WriteReq(p);


Ya s que es muy peligroso cambiar un valor sin estar seguro de lo que hace, 
pero tras mucho estudio me arriesgo y cambio
MOV     R3, #0x2B
por
MOV     R3, #0x10

Inicio el mvil, y veo que ahora la pantalla apenas se ilumina. Y tampoco el 
teclado.
Deduzco que [0x5800E000+#0x2A] guarda la intensidad de la pantalla, y 
[0x5800E000+#0x2B] la del teclado.
As que para poner la pantalla al 70% uso el valor 0x2B * 0.7 = 0x1E
Y para dejar el teclado al 20% de intensidad uso 0x2B * 0.2 = 0x8
La rutina queda
MOV     R3, #0x1E
STRB    R3, [R4,#0x2A]
MOV     R3, #0x08
STRB    R3, [R4,#0x2B]

Otro parche listo para ser publicado. Me gustara ver si de verdad se nota el 
ahorro de batera, pero esto necesitara varios dias de pruebas, y prefiero 
compartirlo, para que otros usuarios tambin opinen.
Lo que me sera perfecto es hacer un parche para poder cambiarlo dinmicamente,
pero por ahora me vale que se pueda meter en la flash permanentemente.

13/10 *********** Jueves ***********
He encontrado que hay un driver llamado edosyin.ldd que incluye una llamada a 
la rutina anterior, por lo que quizs podra cargarlo y llamar a una de sus 
rutinas para que haga todo el trabajo por m.
Recordar que no puedo llamar directamente a la rutina de poner la intensidad 
debido a que hay que inicializar unas variables privadas, y necesitara hacerlo
desde modo supervisor.

En cambio un driver de tipo ldd (Logical Device Driver) funciona de la 
siguiente manera:
-se define el nombre del driver, sin extensin
 #define LDD_NAME_WRITE _L("edosyin")

-se carga
 TInt r = User::LoadLogicalDevice (LDD_NAME_WRITE);
 puede devolver un error, pero si tiene xito devuelve valor 0

-declarar un objeto
 RDevice dev_write;

-averiguar el nombre lgico del driver
 En mi caso es "DosPlugInLdd" . Lo he averiguado mirando el fichero edosyin.ldd

-abrir el RDevice
 r=dev_write.Open(_L("DosPlugInLdd"),EOwnerProcess);

-instanciar un canal lgico 
 chan_write=dev_write.GetLogicalChannel();

-llamar a la funcin DoRequest
 chan_write.DoRequest( numero_servicio, datos_entrada, datos_salida)

Todo esto est explicado en
http://www.symbian.com/developer/techlib/v70docs/SDL_v7.0/doc_source/
en el apartado "Base Porting Guide and Reference->Device drivers->model"
pero es la tpica explicacin que sirve slo despus de que has resuelto el 
problema.

Ahora la gracia est en encontrar los valores de estos parmetros
Desensamblando edosyin.ldd he visto que cuando numero_servicio=2 entonces llama 
a la rutina de cambiar la intensidad.
El valor de datos_entrada es un descriptor con un entero que contiene el valor 
de la intensidad de la luminosidad.

Esto merece una explicacin: en symbian, como en casi cualquier otro sistema 
operativo, existe una zona de datos privada a cada programa. Para que este dato
pueda ser ledo por otro programa (en particular, el kernel) hay que ponerlo en
una zona compartida. Esto se hace reservando memoria en la pila, y obteniendo 
un puntero a la direccin del dato.

Pero hay ms: lo que reservamos es un objeto. Un objeto se compone de 2 partes:
-un dato que indica el tipo: String, TInt, Class, Exception, RFile, RDevice, ...
-otra parte con los datos en s

HBufC* data=HBufC::New(40); // reserva un objeto, consistente en 40 bytes
TPtr ptr=data->Des(); // puntero a los datos
strcpy(ptr, "+++++" );

Ahora ya puedo llamar a
chan_write.DoRequest( 2, data, data);

He usado el mismo puntero para los datos de entrada y de salida porque s que 
no se modifican.

Como he dicho, el valor de data depende del servicio. En particular el servicio
2 incrementa la luz en 1 unidad por cada vez que aparece el signo "+" en 
datos_entrada.
Si escribo "+++++" entonces la intensidad sube en 5 unidades.

Lo que ms difcil me est resultando de Symbian es la verificacin de tipos.
Si defino una variable como
char data[]="+++++";
el compilador no me deja usarla en chan_write.DoRequest() porque necesita 
exactamente un puntero a un descriptor.
Yo s que es lo mismo, pero como los tipos no coinciden, el compilador se queja.
A decir verdad, pierdo ms tiempo buscando los tipos correctas, que probando mi
programa.
Pero al final consigo que funcione.
El documento clarificador es "Descriptors" escrito por Tim Band, Technical 
Architect for Text and Internationalization, de Symbian.

Lamentablemente compruebo que aunque los datos se ponen correctamente, al cabo 
de 5 segundos se resetean al valor por defecto, as que esto no me vale para 
establecer dinmicamente el valor de la intensidad. Tendr que buscar otro 
mtodo.

Hoy hay otra vez cursillo sobre vinos. Iremos a una enoteca. A ver si somos 
capaces de volver por nuestro propio pie.

14/10 *********** Viernes ***********
Existe otro driver etestserver_ldd.ldd que es mucho ms atractivo, pues invoca 
a funciones tales como leer/escribir los puertos serie/infrarrojos/USB/Giga/
Pantalla/Flash/SIM
Pero nada ms cargar el driver, el telfono se resetea. !Ni siquiera he podido 
cargar el canal lgico !

Encuentro otro programa TestSvr.exe que promete bastante, pues tambin llama a 
funciones interesantes para verificar la cmara, Bluetooth, Radio, teclado, IPC
y Pantalla.
Pero cuando lo ejecuto no presenta un interface grfico.

En symbian existen 2 tipos de programa:
-exe, sin interface grfico. Se suelen arrancar cuando se enciende el telfono,
 y nunca se cierran. Sirven como servidores. Por ejemplo: wimcertsrv.exe ,
 LogServ.exe, EDbsrv.exe
-app, con elementos grficos. Suelen ser iniciados manualmente por el usuario.
 Usan los servicios ofrecidos por el servidor. Por ejemplo: ClockApp.app,
 SmsEditor.app, Calendar.app

En ambos casos un programa slo puede estar ejecutndose una vez. Cuando lo 
inicias de nuevo, en lugar de iniciarlo, muestra la otra instancia que se est 
ejecutando.
Esto tiene sentido para un exe, porque slo hay un servidor que crea una cola 
para atender las peticiones, y no puede procesar una hasta que no ha acabado 
con la anterior.

Pero para un app, esto impide que puedas tener la misma aplicacin abierta 2 
veces. Estoy de acuerdo que la pantalla es pequea, pero me gustara tener 2 
veces la agenda por si quiero saber lo que tengo que hacer hoy y tambin 
maana.

La manera de evitar 2 instancias del mismo programa es a travs del UID.
Cada fichero (de tipo app y exe) tiene una cabecera, uno de cuyos datos es un 
identificador nico.
Cuando se pretende iniciar una aplicacin, el kernel mira en su lista de 
procesos para ver si ya est ejecutndose uno con el mismo UID. Si no es as, 
continua la carga.

El UID tambin sirve para reinstalar una aplicacin, en vez de instalarla 2 
veces.
Cuando se pretende instalar una aplicacion, el kernel mira en su lista de 
"aplicaciones instaladas" para ver si ya est instalada una con el mismo UID. 
Si no es as, continua la instalacin.

Otro sitio donde se usa es en el men. Esto es una aplicacin con los iconos de todas las aplicaciones instaladas en
c:\system\apps\
y
e:\system\apps\
Tambin incluye algunas aplicaciones que estn en
Z:\system\apps\

Cuando programas una nueva aplicacin hay que darle un UID nico. Si hay otra 
aplicacin con el mismo UID, el men (y el instalador) puede confundirlas.
No se puede instalar en C: una aplicacin con el mismo UID de otra de Z: 

15/10 *********** Sbado ***********
Sigo intentando cargar drivers, pues creo que me abrirn la puerta al kernel.
Hay uno llamado PowerMeasLdd que llama a funciones tales como:
THelen::ReadReg - para leer un registro del coprocesador (usado, entre otros, 
                  para la red GSM)
ImpHal::GetIbootChunk - para leer la memoria usada durante la inicializacin
                        del mvil
THelen::SetCLKMReg - para definir el reloj interno
THelen::ModifyMmcReg - para acceder a la tarjeta MMC

El driver se carga correctamente, pero el significado de los datos es un 
misterio para m.
Las pruebas con GetIbootChunk funcionan, pero lo nico que consigo leer son 
datos que ya conoca porque anteriormente he volcado toda la memoria Flash.
Al usar ReadReg leo algunos valores, pero desconozco su significado. En este 
sentido la documentacin de ARM no me sirve, y necesitara la del fabricante 
de los dispositivos. Intentar encontrar algo en Internet.

Algunas de las pruebas resetean el mvil, y me entra un poco de miedo de romper
el mvil. Al principio he dicho que tengo 7 mviles iguales, as que no me 
importa romper 1  2. Pero prefiero andar sobre seguro antes de hacer pruebas a 
lo loco.

Este inters por el kernel obedece al hecho de que quiero entender el modelo de 
memoria para hacer una copia exacta de la memoria en tiempo de ejecucin. 
Recordaris que en un artculo anterior hice un emulador para el mvil S45 que 
me permita ejecutar exactamente los mismos programas que el mvil real, y 
debugearlo desde el PC. Pretendo hacer lo mismo para el SX1.

El objetivo no es slo ste mvil Siemens, sino que he ledo que Symbian est 
instalado en el 40% de los mviles Nokia, y Nokia tiene el 25% de cuota de 
mercado.
Por consiguiente cualquier averiguacin se aplicar sobre los Nokia, incluida 
la N-Gage.
Otros modelos incluyen el P800 de Ericsson y Sendo.

Al parecer el mercado de sistemas operativos para mviles se reparte entre 
Symbian (25%), Microsoft (20%) y el resto son sistemas propietarios de cada 
fabricante.
Algunos incluyen Linux, pero slo la parte grfica. El mdulo de comunicaciones 
GSM y control de dispositivos es privado y secreto.


16/10 *********** Domingo ***********
Hoy he tenido que ir a trabajar.
Tengo que actualizar una aplicacin en todos los ordenadores de la empresa, y 
no quiero que nadie me moleste.
La instalacin es automatizada, pero debo encender todos los ordenadores. Y 
apagarlos al final del da.
Podra pasarme el da navegando porque nadie me vigila, pero lo nico que hago 
es publicar el parche de reducir la luminosidad.

Al cabo de 5 horas el trabajo est terminado, as que me queda tiempo para ver 
lo que la gente opina del parche para reducir la luminosidad que publiqu hace 
un rato .

Al parecer ha sido un xito.
En todos los foros ha tenido gran aceptacin. En CS van a juntar todos los 
parches y sacar una versin especial de la flash. Tambien incluir nuevos 
iconos hechos por gente del foro.

Esto tardar al menos un mes, as que espero que me d tiempo para hacer otros 
parches.

Por lo pronto, hoy invitamos a unos amigos y les sometemos a una sesin de 
visionado de fotos de vacaciones. Como contraprestacin les damos los regalos 
que les hemos comprado.

17/10 *********** Lunes ***********
He recibido una peticin para hacer un parche concreto. En el mvil viene 
incluida una aplicacin para grabar sonido. Es bastante til para grabar notas 
de voz. Otro uso que tiene es grabar la conversacin mientras hablas por 
telefono. As se pueden evitar esas discusiones de tipo "pero t me dijiste 
que..."
Lo malo es que slo permite 2 minutos, y cuando grabas una conversacin emite 
un pitido inicial que se oye al otro lado, con lo que tu interlocutor sabe que 
le estas grabando.

Aprovecho para decir que en Espaa esta prohibido grabar conversaciones sin 
permiso. Incluso las tuyas propias.

Aunque no tenga que ver, me gustara comentar algo que vi en un captulo 
antiguo de la serie de televisin CSI. Encuentran un mvil de la vctima, con 
la batera gastada. Lo llevan al laboratorio y reproducen la ltima 
conversacin. No slo so, sino que eliminan la conversacin y se quedan con el
ruido de fondo. Aplican un filtro y averiguan que es el sonido del motor de un 
coche. Deducen el modelo de coche.

Cuando lo v, me parta de risa.

Primero: la conversacin transmitida por GSM se realiza a unos 22Kbits/segundo.
         Una conversacin de 1 minuto ocupara aproximadamente 100 Kb. Pocos 
         mviles en 2001 tienen una memoria capaz de almacenar tanto.
Segundo: en GSM la voz se codifica y se divide en paquetes, los cuales se 
         mandan por la red. Una vez que un paquete se ha recibido al otro lado,
         no tiene sentido guardarlo. En todo caso, sera la red quien lo podra
         almacenar (por orden judicial previa a la conversacin).
Tercero: los datos van cifrados. Este cifrado cambia con el tiempo, y es de 
         clave simtrica. Para descifrarlos hay que tener la clave de ambos 
         mviles y de la red, los cuales son desconocidos para un mvil en 
         solitario.
Cuarto:  cuando al mvil se le acaba la batera, se apaga. La nica manera de 
         guardar los datos es en una memoria esttica. Pero recordar que la 
         batera se ha acabado, as que no hay manera de hacer nada ms que el 
         procedimiento de emergencia: un pitido, y poco ms.
Quinto:  un mvil tiene un filtro por hardware para oir slo sonidos 
         pronunciables por un humano. Los sonidos demasiado graves o muy agudos
         no los capta. Y el ruido de un motor es bastante grave.
Sexto:   el micrfono de un mvil esta diseado para oir sonidos cercanos, a 
         unos 10 centmetros del auricular. El ruido de fondo ni siquiera es 
         detectado.
Sptimo: la voz se digitaliza, eliminando los picos de sonido. Esto produce una
         muestra homognea. Luego se digitaliza incluyendo los parmetros 
         usados para el filtrado. La reproduccin efectuada al otro extremo 
         tiene una calidad entre el 70% y el 90%. Si tuviera ms, indicara que
         el filtro no es eficaz, pues no ha sido capaz de comprimir los datos.

En resumen, que los mviles nunca graban las conversaciones, y es imposible 
escuchar un motor como ruido de fondo.
A menos, por supuesto, que cuentes con la magia de la televisin.


18/10 *********** Martes ***********
El parche de la luminosidad tiene un lugar destacado en el foro de oslik. Ya 
hay quien est intentando modificarlo para que se pueda hacer dinmicamente. 
Yo ya no lo voy a intentar hasta que entienda un poco ms.

En cambio trabajo en el parche de aumentar la duracin de la grabacin de voz.
El tiempo es de 2 minutos, as que son 2*60=120 segundos, es decir, 120.000.000 
microsegundos.
Pasado a hexadecimal, es 0x7270E00
Convertido a little-indian, resulta 000E2707
Busco este dato y lo encuentro en

Z:/System/Libs/bt.prt
Z:/System/Libs/satcli.dll
Z:/System/Libs/sdp.exe
Z:/System/Libs/VOICERECORDERRECVIEW.DLL
Z:/System/Programs/SplashScreen.exe

A ver, ?cul eligiras tu? Claro, VOICERECORDERRECVIEW.DLL
El nuevo valor ser 000E2747 que significa 0x47270E00, o sea, 1.193.741.824 , 
unos 20 minutos.
Parcheo la flash, reemplazando 000E2707 por 000E2747, pruebo a grabar, y me 
deja 20 minutos, ms que suficiente.

Analizando esta misma aplicacin veo que hay algo llamado
PlaySoundIfCallActive
que invoca a otra rutina externa de nombre
PlaySound.

El parmetro R1 es 0x45 . Lo cambio y compruebo que efectivamente cambia el 
tono del pitido inicial.
Verifico que slo se llama desde este punto, y con mucho cuidado anulo sta 
llamada.

Meto el parche, grabo una conversacin, y ya no se oye el pitido.
Otro parche para la coleccin.


19/10 *********** Mircoles ***********
Hoy he recibido la grata noticia de que los chicos de oslik estan intentando 
meter Linux en el SX1.
Me han pedido colaborar con ellos. Yo no s mucho del hardware fsico del mvil
ni los dispositivos, pero supongo que podra espiar el cdigo de Symbian, y 
traducirlo a Linux.

Lo primero que me han informado es que van a usar algo llamado U-boot. Esto es 
un cargador de Linux para procesadores ARM.
Inicialmente basado en el proyecto PPCboot, la parte especfica para ARM se ha 
pasado a llamar ARMboot.

Simplemente es un cargador que inicializa el sistema de memoria, los puertos y 
las interrupciones.
Lo que pase despus de esto es independiente del SX1, y slo tiene que ver con 
el kernel de Linux, que en este caso sabe bastante poco de modelos de memoria y
de puertos.
Y para otros dispositivos hay que crear mdulos.

Como ellos ya tienen algo funcionando, lo instalo en el mvil para ver si 
funciona.
Pero como quiero estar seguro de lo que hago, me tengo que leer unos cuantos 
manuales antes de empezar a trastear.

20/10 *********** Jueves ***********
Antes de instalar Linux en el SX1 tengo que meterlo en mi ordenador. La ltima 
vez que me actualic Linux tena el kernel 2.4 pero necesito el 2.6
As que decido instalarlo desde cero. Esto llevar tiempo.

21/10 *********** Viernes ***********
Sigo instalando.

22/10 *********** Sabado ***********
Ya he instalado todo. Una de las cosas que necesito es el compilador cruzado 
para ARM.
Bsicamente, permite compilar en el PC aplicaciones que se ejecutarn en otro 
procesador.
Pero hay que definir muy exactamente cul es el otro procesador. Se empea en 
usar PPC, no ARM.
se ve que PPC es la configuracin por defecto.

No es fcil de hacerlo funcionar, pero ms o menos lo he conseguido.
Ha sido imprescindible la ayuda del documento 
"Embedded Linux on OMAP1710 SDP (H3 board)"
hecha por Magnus Aman, de Texas Instruments.

Ahora hay que construir un kernel 2.6.13 para OMAP0310, con procesador 
ARM925Tid (ARMv4T)

23/10 *********** Domingo ***********
Construir el kernel para otro procesador cuesta un rato. Adems da un montn 
de fallos que no s si son importantes o no.

El documento bsico es:
U-Boot for the OMAP16xx GSM/GPRS Software Development Platform

Luego, el proceso tpico de comprimir el kernel, mkimage, y por ltimo 
transferirlo.
Para esto hay que entrar en el SX1 en modo "meter nueva flash", que espera a 
que se le manden los datos por USB.
Yo uso kermit para transferirlo.
Una vez terminada la carga, hay que iniciarlo con bootm.
Tras unos cuantos intentos, por fin arranca ! Casi me caigo de la silla cuando 
lo veo!

Cuando inicia, se ve algo as:

Linux version 2.6.13.4-omap1

 (root@linux) (gcc version 3.4.2) #70 Sun Oct 23 21:04:26 MSK 2005 
<4>CPU: ARM925Tid(wb) [54029252] revision 2 (ARMv4T) 
<4>Machine: OMAP310 based Siemens SX1 
<4>Memory policy: ECC disabled, Data cache writeback 
<4>OMAP0310 revision 2 handled as 15xx id: 65858c1d22451c1c 
<6>SRAM size: 0x30000 
<4>Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x3a33 ARM_CKCTL: 0x010d 
<6>Clocking rate (xtal/DPLL1/MPU): 12.0/120.0/120.0 MHz 
<7>On node 0 totalpages: 4096 
<7>  DMA zone: 4096 pages, LIFO batch:1 
<7>  Normal zone: 0 pages, LIFO batch:1 
<7>  HighMem zone: 0 pages, LIFO batch:1 
<4>CPU0: D VIVT write-back cache 
<4>CPU0: I cache: 16384 bytes, associativity 2, 16 byte lines, 512 sets 
<4>CPU0: D cache: 8192 bytes, associativity 2, 16 byte lines, 256 sets
<4>Built 1 zonelists 
<5>Kernel command line: mem=16M console=ttyS0,115200n8 root=/dev/mtdblock3 rw 
<4>Total of 64 interrupts in 2 interrupt banks 
<6>OMAP1510 GPIO hardware 
<4>PID hash table entries: 128 (order: 7, 2048 bytes) 
<4>Console: colour dummy device 80x30 
<4>Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) 
<4>Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) 
<6>Memory: 16MB = 16MB total 
<5>Memory: 14672KB available (1111K code, 301K data, 72K init) 
<7>Calibrating delay loop... 59.80 BogoMIPS (lpj=299008) 
<4>Mount-cache hash table entries: 512 
<6>CPU: Testing write buffer coherency: ok 
<6>Linux NoNET1.0 for Linux 2.6
<6>DMA support for OMAP15xx initialized 
<4>Initializing OMAP McBSP system 
<4>MUX: initialized W4_USB_PUEN 
<3>no usb0 alt pin config on 15xx 
<4>USB: hmc 0, usb0 3 wires (dev) 
<6>i2c_omap: rev1.0 at 100 KHz 
<7>i2c_adapter i2c-0: registered as adapter #0 
<6>omapfb: configured for panel SX1 
<6>OMAP LCD controller initialized. 
<4>Sofia write: 7 10 
<7>i2c_adapter i2c-0: master_xfer[0] W, addr=0x32, len=2 
<4>Console: switching to colour frame buffer device 44x36 
<6>OMAP framebuffer initialized vram=131072 
<6>omap_rtc: RTC power up reset detected. 
<6>omap_rtc: Enabling RTC.
<6>io scheduler noop registered
<6>io scheduler cfq registered
<6>i2c /dev entries driver
<7>i2c-core: driver dev_driver registered.
<7>i2c_adapter i2c-0: Registered as minor 0
<6>udc: OMAP UDC driver, version: 4 October 2004 (iso) (dma)
<6>udc: OMAP UDC rev 2.7
<6>udc: hmc mode 0, (unknown) transceiver
<6>udc: fifo mode 3, 648 bytes not used
<6>gs_bind: Gadget Serial v2.0 bound
<6>gs_module_init: Gadget Serial v2.0 loaded
<6>mice: PS/2 mouse device common for all mice
<6>OMAP Keypad Driver
<4>VFS: No root yet, retrying to mount root on mtdblock3 (unknown-block(0,0))
<4>omap-keypad: Spurious key event 0-3 
<4>omap-keypad: Spurious key event 1-3 
<4>omap-keypad: Spurious key event 2-3 
<4>omap-keypad: Spurious key event 3-3 
<4>omap-keypad: Spurious key event 4-3 
<4>omap-keypad: Spurious key event 5-3 
<4>omap-keypad: Spurious key event 6-3 
<4>omap-keypad: Spurious key event 7-3 
<4>omap-keypad: Spurious key event 0-3 
<4>omap-keypad: Spurious key event 1-3 
<4>omap-keypad: Spurious key event 2-3 
<4>omap-keypad: Spurious key event 3-3 
<4>omap-keypad: Spurious key event 4-3 
<4>omap-keypad: Spurious key event 5-3 
<4>omap-keypad: Spurious key event 6-3 
<4>omap-keypad: Spurious key event 7-3 
<4>VFS: No root yet, retrying to mount root on mtdblock3 (unknown-block(0,0)) 


Y esto es todo. Luego da un fallo y se queda colgado. Recordar que U-boot es un
proyecto en estado alpha, y las adaptaciones para el SX1 todava estan en 
paales.

Bueno, hay muchos detalles que se pueden extraer de este listado, pero sern 
objetivo de otro artculo.

Debo decir que yo apenas he desarrollado nada para Linux-SX1, y mi tarea es 
analizar las rutinas y registros que se ponen en el sistema operativo Symbian, 
y traducirlas al ARMboot. En particular, tengo que sacar tramas del protocolo 
usado con la pantalla LCD, la tarjeta de memoria MMC, el teclado, y el chip de 
sonido.
Esto lo hago sniffeando lo que pasa a travs de la aplicacin "Sofia", en 
particular la funcin TSofiaSX1::WriteReq

A m me interesa ms la parte de GSM, pero sto me dicen que llegar ms tarde. Primero tenemos que conseguir un shell en el SX1.
Notar que una vez que el kernel ha arrancado satisfactoriamente ser posible 
ejecutar cualquier programa de Linux. Incluidas aplicaciones grficas.

Y tambin podremos empezar a cargar mdulos para atacar a otros dispositivos, 
tales como infrarrojos, Bluetooth, DSP, o el E-Gold, responsable del interface 
GSM.

El tema es apasionante, pero requiere ms tiempo y esfuerzo del que tengo.

He mirado otros mviles que funcionan con Linux, pero me ha sido imposible 
localizar el cdigo fuente que usan. 
Me parece entender que el kernel es el estndar 2.6.13 pero el bootloader es 
especfico para cada arquitectura de telfono.
Como entorno grfico usan las libreras QT de Trolltech.

24/10 *********** Lunes ***********
Entre unas cosas y otras he aprendido cmo funcionan las interrupciones de 
usuario en ARM. Lo explico porque es el corazn del sistema operativo.

Existen varios modos de ejecucin.
El mas comn es el modo de usuario. Las aplicaciones no pueden acceder a la 
memoria de otras, ni a recursos hardware. Si necesitan rebasar los lmites 
tienen que llamar a las libreras User.
Esta librera prepara los datos y llama al kernel haciendo uso de la 
instrucin SWI.
Existen 3 niveles de SWIs:
-bajo, con un nmero entre 0x0 y 0xFE, por ejemplo   SWI 0x4D
-alto, con un nmero entre 0x800000 y 0x8000FE, por ejemplo   SWI 0x80004E
-ultra-alto, con un nmero entre 0xC00000 y 0xC000FE, por ejemplo   
 SWI 0xC0006E

Cuando se encuentra una de estas instrucciones, el procesador toma el dato de 
la memoria en la direccin 0x00000008 y salta a donde indique.
En mi firmware sto es 0x5000B0D8
Aqu hay una rutina llamada ArmVectorSwi que averigua cul es la interrupcin 
solicitada.
A partir de la direccin 0x5000AD24 hay una tabla de direcciones de rutinas. 
Toma el valor, y salta a la rutina correspondiente.

Vamos con un ejemplo:
Creamos un objeto de tipo TChar
TChar michar;

lo convertimos a minsculas:
michar=User::LowerCase('B');

Observar que hemos llamado a una rutina de la librera User, por lo que 
generar una interrupcion.

TChar User::LowerCase(uint)
{
asm("SWI 0x51");
}

Ahora saltar al gestor de interrupciones en 0x5000B0D8, donde calcula:
0x5000AD24+4*0x51 vale 0x5000AE68
y en la direccin 0x5000AE68 est el valor 0x5001A340, equivalente a  
ExecHandler::LowerCase(uint)

As que salta a 0x5001A340, que simplemente usa una tabla para convertir 'B' 
en 'b'.
Recordar que ahora estamos procesando una interrupcin, por lo que estamos en 
modo supervisor, con control total sobre la memoria.

Aqu me surge una duda: ?por qu Symbian hace e'sto con interrupciones, cuando 
lo poda hacer ms simple sin ellas? Pues no lo s. Quizs sea porque sea mas 
fcil que usar las libreras tpicas stdio y string.

Lo importante es que puedo parchear esta rutina para hacer lo que yo quiera, 
en modo supervisor.
Por ejemplo, suponer que quiero leer la memoria 0x40000000 (que est protegida).

Modifico la rutina

org 0x5001A340:

ExecHandler::LowerCase(uint)
{
if(R9==0x69)
	R9=*(0x40000000);
Call ExecHandler::LowerCase_original(uint)
}

Y la invocacion sera:
asm("Mov R9, 0x69");
michar=User::LowerCase('B');
asm volatile ("STR r9, %0" : "=m"(valor) );


Notar que confo en el hecho que R9 no se modifique entre medias.
Si otra rutina intermedia (por ejemplo, el gestor de interrupciones 
ArmVectorSwi ) modifica R9, esto no funcionara.

En mis pruebas he visto que efectivamente nadie lo modifica, y sirve 
perfectamente para mis propsitos.

Una modificacion similar en la rutina ExecHandler::UpperCase(uint) me permite 
escribir cualquier direccin de memoria.

25/10 *********** Martes ***********
Ms util es parchear la rutina ArmVectorSwi.
Si recordis los detalles de mi debugger para el S45, pona una variable en una
zona fija de memoria. Cada rutina tena una cabecera que miraba esta variable. 
Si estaba puesta a un valor determinado, empezaba a debugear la informacin 
relevante: registros, pila, y flags.

Ahora pretendo hacer lo mismo:

org 0x5000B0D8:

void ArmVectorSwi()
{
#define dir_hay_que_debugear 0x40000000
int dir_datos_debugeados 0x40000000+0x10
R9=*(dir_hay_que_debugear);
if(R9==0x69)
 {
 *(dir_datos_debugeados+4*0)=R0;
 *(dir_datos_debugeados+4*1)=R1;
 ...
 *(dir_datos_debugeados+4*14)=R14;
 *(dir_datos_debugeados+4*15)=R15;
 *(dir_datos_debugeados+4*16)=*(SP);
 *(dir_datos_debugeados+4*17)=*(SP+4);
 dir_datos_debugeados+= 4*(16+2);

 }
call ArmVectorSwi_original();
}


Espero que est claro.
-Mantengo un dato que me dice dnde he guardado el ltimo dato.
-Guardo los 16 registros, y las 2 ltimas entradas en la pila.
-Luego incremento el contador de datos guardados.
Recordar que en ARM cada dato ocupa 4 bytes.


26/10 *********** Mircoles ***********
Ahora se abren muchas ms posibilidades. Puedo poner un breakpoint en cualquier 
rutina, volcar su memoria, modificarla, y seguir el proceso. Esto me permite 
averiguar exactamente lo que hace un programa, por lo que espero hacer muchos 
ms parches.

27/10 *********** Jueves ***********
Despus de 2 meses de trabajo creo que le he sacado bastante partido a mis 
mviles. He conseguido cerrar algunas puertas, pero muchas ms se me han 
abierto por el camino.

Entre los proyectos que me gustara explorar estn:
-Linux en el SX1
-Analizador de protocolos GSM en el propio mvil
-Instalar Symbian7 o superior
-Rutinas de procesado de MMS. Estoy convencido de que hay un buffer-overflow 
 usable. ?Captas las implicaciones?
-Bluetooth. Virus y antivirus
-Anlisis de modelos Nokia
-Crakeo de programas Shareware protegidos

En fin, ha sido largo pero satisfactorio. Espero que te haya picado el 
gusanillo y ahora seas t el que investigue sobre este tema tan apasionante.

Yo ahora vuelvo a mis quehaceres familiares.

*EOF*