Notes

JAKARTA:

El truco está en la instrucción 45cc. Esta instrucción hace la resta sub r11, r14 que significa restar source from destiny y guardarlo en destiny. Es decir, r14 = r14 - r11. Justo en la instrucción anterior, la 45c8, se hace un mov 0x1f, r14. Es decir, en el momento de la resta, r14 vale 0x1f.

r11 tiene la longitud del username.

Este comportamiento sirve para restar al valor de r14 (0x1f) la longitud del username, que puede ser hasta 0x20.

En la instrucción 45ae se hace un cmp.b 0x21, r11 y para pasar el test no debe haber acarreo. Es decir, el buffer de usuarname debe tener 0x20 bytes como máximo. Esto son 32 bytes insertados. Puesto que la longitud puede legalmente llegar a ser 32 bytes (0x20), la resta anteriormente mencionada supone un integer underflow. Es decir, si username vale todo lo ue puede vale, 0x20 y es restado a 0x1f (0x1f - 0x20), r14 pasará a valer 1 negativo. Esto en hexadecimal es 0xffff

Acto seguido se hace un AND a r14 (0xffff) con 0x1ff. El resultado de este AND es 0x1ff que, estando en el registro r14 antes de la llamada a getsn, supone el número máximo de bytes que puede valer la contraseña.

ESTO ES UN ERROR DE OFF-BY-ONE QUE DESENCADENA UN UNDERFLOW EN LA INSTRUCCIÓN 45cc. Si el username valiese cualquier otra cosa, por ejemplo 0x10. La resta sería 0x1f-0x10 = 0x0f indicando así a getsn que puede copiar hasta 15 bytes. Aún así, 0x10 (16) + 0xf(15) = 31. No son lso 32 bytes prometidos.

La solución consiste en insertar un username de exactamente 32 bytes para llevar a cabo el underflow y después preparar la password para sobreescribir la dirección de retorno de login a la función unlock.

Finalmente, hay que tener en cuenta que, para poder llevar el flujo de ejecución donde nos interesa, hay que pasar con éxito la comprobación de la instr 4600 cmp.b #0x21, r15. Lo que está haciendo, básicamente, es 0x21 - r15. En r15 se encuentra la longitud de la contraseña que decidamos meter MÁS la longitud del username. Puesto que en este momento ya habremos introducido 0x20 bytes en el username, y teniendo en cuenta que la contraseña será mayor que 0 pues queremos sobreescribir @ret, hay que jugar con la instrucción cmp.b. Está comparando un byte exclusivamente y no un word, esto significa que sólo tendrá en cuenta la parte baja del registro r15, el primer byte. Teniendo en cuenta que ahora mismo r15 = 0x20, si introducimos una contraseña de 0xE0 (0x100-0x20=0xE0) bytes long, por ejemplo (la única limitación es el 0x1ff del getsn), r15 pasará a ser 0x100, donde su parte baja será 0x00. Al hacer 0x21-0x00 no habrá acarreo posible y pasaremos la prueba. No hay que olvidarse, además, que la dirección @ret de login que queremos sobreescribir está en un offset +4 desde donde se escribe la pass. Es decir, la pass se escribe en 4012 y @ret empieza en 4016, 4bytes + dirección (esto son 6 bytes) + 0xDA restantes. (0xE0-0x6=0xDA)

La dirección de <unlock_door>_: es 444c

USERNAME: 41*32
4141414141414141414141414141414141414141414141414141414141414141

PASSWORD: 42*4 + 4c44 + 42*(0xDA) == "42"*4 +"4c44" + "42"*218
424242424c44424242424242424242424242424242424242424242424242424242424242424242424242424242424242
424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242
424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242
424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242424242
4242424242424242424242424242424242424242424242424242424242424242