Ir al contenido

Analisis/Desensamblado Arranque SOHO.BIN


Publicaciones recomendadas

A priori podemos desensamblarlo cutremente, si tenemos las binutils ARM instaladas (buscad por ahi como compilar las binutils para ARM, no tiene mucha mas historia que configurarlo con arm-elf como target) con estos comandos:

(reemplazar arm- con el prefijo que tengan vuestros ejecutables; yo creo symlinks a arm-* para que sea mas sencillo)


$ arm-objcopy -I binary -O arm-elf SOHO.BIN soho.o

$ arm-objdump -D -marmv4t soho.o > soho.txt

Esto nos crea soho.txt con el desensamblado. Yo estoy desensamblado el del firm de Ya.com pero como son mas o menos lo mismo dudo que haya cambio alguno en la estructura del arranque. A simple vista me encuentro con lo siguiente:

       0:	e3a00083 	mov	r0, #131	; 0x83

       4:	ef0000ff 	swi	0x000000ff

segun tengo entendido la swi (software interrupt, syscall en terminos mas comunes) 0xFF con el parametro 0x83 en r0 pone el procesador en modo SVC, para el bootloader del SMC (he visto un codigo similar para un SMC distinto con un bootloader similar, al que ya le han cargado el ucLinux. Pero el procesador era distinto asi que mas o menos ahi acaban las similtudes creo)

       8:	e3a08000 	mov	r8, #0	; 0x0

       c:	e28f900c 	add	r9, pc, #12	; 0xc

      10:	e8b900ff 	ldmia	r9!, {r0, r1, r2, r3, r4, r5, r6, r7}

      14:	e8a800ff 	stmia	r8!, {r0, r1, r2, r3, r4, r5, r6, r7}

      18:	e8b900ff 	ldmia	r9!, {r0, r1, r2, r3, r4, r5, r6, r7}

      1c:	e8a800ff 	stmia	r8!, {r0, r1, r2, r3, r4, r5, r6, r7}

      20:	e59ff018 	ldr	pc, [pc, #24]	; 40 <_binary_SOHO_BIN_start+0x40>

      24:	e59ff018 	ldr	pc, [pc, #24]	; 44 <_binary_SOHO_BIN_start+0x44>

      28:	e59ff018 	ldr	pc, [pc, #24]	; 48 <_binary_SOHO_BIN_start+0x48>

      2c:	e59ff018 	ldr	pc, [pc, #24]	; 4c <_binary_SOHO_BIN_start+0x4c>

      30:	e59ff018 	ldr	pc, [pc, #24]	; 50 <_binary_SOHO_BIN_start+0x50>

      34:	e1a00000 	nop			(mov r0,r0)

      38:	e59ff018 	ldr	pc, [pc, #24]	; 58 <_binary_SOHO_BIN_start+0x58>

      3c:	e59ff018 	ldr	pc, [pc, #24]	; 5c <_binary_SOHO_BIN_start+0x5c>

      40:	00010400 	andeq	r0, r1, r0, lsl #8

      44:	000100b0 	streqh	r0, [r1], -r0

      48:	00010110 	andeq	r0, r1, r0, lsl r1

      4c:	0001015c 	andeq	r0, r1, ip, asr r1

      50:	000101bc 	streqh	r0, [r1], -ip

      54:	00000000 	andeq	r0, r0, r0

      58:	00010224 	andeq	r0, r1, r4, lsr #4

      5c:	000103a0 	andeq	r0, r1, r0, lsr #7

Este codigo es curioso... carga en r8 la direccion de memoria 0x00000000 y luego carga en r9 pc+0x0c. Hay que recordar que en ARM el PC siempre es la direccion de la instruccion que esta dos posiciones mas alante que la actual, la 0x14 en este dump. mas 0x0c (cada instruccion son 4 bytes) son 3 instrucciones, asi que nos da la direccion de la que esta en 0x20. Despues ldmia y stmia se usan para copiar rapidamente 8*4 bytes (8 instrucciones) desde la posicion de r9 a r8, y luego otros 8*4 bytes mas. esto nos copia desde la instruccion 0x20 en este dump hasta la ultima en 0x5c a la direccion de memoria 0. Esto reemplaza los vectores de reset/syscall/interrupcion/error etc por unos propios del programa. Los vectores corresponden a las 8 primeras instrucciones que saltan a la direccion contenida 8 bytes despues de ellas (recordemos 8*4=32 menos las dos instrucciones que se adelanta el PC, que serian 2*4=8 nos da el offset 24) Asi que las direcciones que aparecen en 0x40-0x5c son las de los vectores (ignorar la instruccion desensamblada ya que son solo datos) La ejecucion de la rutina continua por 0x20 a 0x00010400 (la direccion almacenada en 0x40) que corresponderia al vector de reset (aunque si reseteamos el micro el la direccion 0x0 que actualmente es la RAM pasaria a ser la flash porque el bootloader activa el mapeo flash->0x80000000 y ram->0x0 si no me equivoco (bit 8 en SYSCFG) asi que se ejecutaria el bootloader de nuevo y no el SOHO.BIN) SOHO.BIN se ha cargado en 0x0010050 cuando lo cargamos via RAM (la default y parece ser la misma que para la carga deszipeando desde la flash) asi que 0x10400 corresponderia a 0x3B0 en este dump.

     3b0:	e59f025c 	ldr	r0, [pc, #604]	; 614 <_binary_SOHO_BIN_start+0x614>

     3b4:	e59f125c 	ldr	r1, [pc, #604]	; 618 <_binary_SOHO_BIN_start+0x618>

carga dos datos de sus posiciones:

     614:	8000007f 	andhi	r0, r0, pc, ror r0

     618:	f014000c 	andnvs	r0, r4, ip

y luego:

     3b8:	e5810000 	str	r0, [r1]

usease que coje el valor 0x8000007f y lo mete en 0xf014000c que se corresponde con EXTMASK (pagina 621 del manual del procesador) que es desactivar todas las interrupciones y ademas enmascarar las interrupciones externas 0-5 (todas). Ademas pone a 1 el bit 6 que no esta implementado, asi que este codigo tiene pinta de ser generico para mas procesadores porque este no tiene uso para ese bit.

Yo creo que hasta aqui es suficiente para conseguir que ucLinux rule mas o menos, exceptuando el tema de la interfaz serie que hay que ver como lo hace. Voy a ver si escribo algun cutre programa para que saque algo por la consola.

[Editado el 5/12/2004 por marcansoft]

Enlace al mensaje
Compartir en otros sitios web
Invitado
Este tema está cerrado a nuevas respuestas.
×
×
  • Crear nuevo...

Información importante

Términos de Uso Política de privacidad Hemos colocado cookies en su dispositivo para ayudar a mejorar este sitio web. Puedes ajustar la configuración de tus cookies ; de lo contrario, asumiremos que quieres continuar.