Para empezar el año de retos planteamos un pequeño reversing de un sencillo formulario/pantalla de login escrito en java. Apenas cuatro horas después ya nos llegó la primera solución desde México... y en una semana hemos recibido hasta ocho soluciones de distintos participantes. A todos ellos podéis verlos ya en nuestro eterno hall de la fama.
El reto original estaba basado en una entrada de Reverse Engineering Tips en la que se describe cómo extraer un jar empaquetado con Jar2Exe 2.1 en sus tres niveles de protección.
En nuestro caso tenía el segundo nivel de protección y el código llamaba a una sencilla función ROT13 para ofuscar un poco la contraseña del usuario. Esta sencillez hizo que alguno obtuviera la string ofuscada con Cheat Engine y por deducción obtuviera la contraseña en claro.
Otros se apoyaron en herramientas como e2j e incluso Process Hacker para extraer el jar y luego decompilarlo. Al final todo vale si el resultado final es la obtención de las credenciales correctas:
A todos los ganadores del reto y a todos aquellos que hayáis intentando resolverlo con mayor o menor éxito: ¡muchas gracias, nos vemos en el próximo!
Eso sí, os dejo con uno de los write-ups más completos recibidos, by l0ngin0s @amnesia:
[0x00] OEP
Es la primera vez que intento resolver un reto de los propuestos por el Te@m de Hackplayers y lo cierto es que ya tenía ganas.
Deseo que disfrutéis de su lectura, tanto como yo redactándola.
[0x01] TARGET
[0x02] ENVIRONMENT & TOOLS
• Oracle VirtualBox2 4.3.20.
• Microsoft Windows 7 Ultimate x64.
• Java3 SE Runtime Environment 7.
• CFF Explorer4 VII.
• OllyDbg5 2.00.01.
• HxD6 1.7.7.0.
• DJ Java Decompiler7 3.12.12.98.
[0x03] KNOWING THE ENEMY
Lo primero que llama la atención al ver el fichero descargado es que se trata de un .exe cuando en el enunciado del reto, hacen referencia a Java.
Si cargamos el binario en CFF Explorer, entenderemos el por qué de ello:
Se ha usado un wrapper (Jar2Exe) o envoltorio, para empaquetar el/los .jar que se generaron al construir el binario original.
Es evidente que el primer objetivo es obtener el .jar inicial, para posteriormente poder descompilar sus clases.
[0x04] EXTRACTING JAR FILE
Entre las muchas características que tiene Jar2Exe, hay una muy interesante:
De lo cual podemos inferir que por mucho análisis estático que hagamos al ejecutable, poco podremos sacar.
Descargándonos la versión demo de este producto y haciendo alguna que otra prueba de empaquetado y/o protección con algún .jar simple, llegaremos a la conclusión de que este, será cifrado y almacenado en la sección .rsrc (resource) como recurso RCDATA que suele ser un recurso típico de almacenamiento para algunas aplicaciones de cifrado/compresión de ficheros.
Basta con arrojar una mirada al recurso, para ver su contenido cifrado:
Por tanto, si a esa zona le ponemos un punto de ruptura, con total seguridad que se disparará en la rutina de descifrado de jar2exe.
Tan solo queda, situarnos al final del bucle, para ver en el registro EAX la dirección del .jar descifrado y en ECX su tamaño en bytes:
Copiamos esos 0x2240 bytes en el editor hexadecimal y lo guardamos en un fichero con extensión .jar:
[0x05] GET SOURCE CODE
Estamos en disposición de poder obtener el código fuente y ver en que clase y que método está el algoritmo que controla la acción de validar usuario/contraseña. Para ello utilizaremos una herramienta llamada DJ Java Decompiler y que nos permitirá extraer los ficheros .class:
Tan solo queda decompilar la clase Login.class y analizar su código:
Observamos como el nombre de usuario es Administrador y la contraseña debe ser el resultado de ejecutar el método mueve, argumentándole “qviregvq0”.
A partir de aquí ya solo quede analizar ese método o implementarlo en un proyecto a parte para obtener la contraseña. Esto es ya a gusto del consumidor:
De cualquier manera, el algoritmo es bastante sencillo de entender. Dependiendo de la pertenencia a un rango establecido, se sumará o restará a cada letra argumentada el valor ASCII del Carriage Return (CF) y cuyo valor es 0x0D:
[0x06] ENDING
No quiero despedirme sin antes agradecer al Te@m de Hack Players su excelente trabajo, a los lectores que hayan llegado hasta aquí y a mis compañeros de equipo por estar ahí siempre que los necesito:
{@NoxOner , @4r4nL , @javierprtd , @sanguinawer , @sergiollata ,
@ajgomezlopez , @alguien_tw }
@amn3s1a_team
A todos vosotros, GRACIAS!!
No temo a los ordenadores; lo que temo es quedarme sin ellos
-- Isaac Asimov ---
El reto original estaba basado en una entrada de Reverse Engineering Tips en la que se describe cómo extraer un jar empaquetado con Jar2Exe 2.1 en sus tres niveles de protección.
En nuestro caso tenía el segundo nivel de protección y el código llamaba a una sencilla función ROT13 para ofuscar un poco la contraseña del usuario. Esta sencillez hizo que alguno obtuviera la string ofuscada con Cheat Engine y por deducción obtuviera la contraseña en claro.
Otros se apoyaron en herramientas como e2j e incluso Process Hacker para extraer el jar y luego decompilarlo. Al final todo vale si el resultado final es la obtención de las credenciales correctas:
A todos los ganadores del reto y a todos aquellos que hayáis intentando resolverlo con mayor o menor éxito: ¡muchas gracias, nos vemos en el próximo!
Eso sí, os dejo con uno de los write-ups más completos recibidos, by l0ngin0s @amnesia:
Es la primera vez que intento resolver un reto de los propuestos por el Te@m de Hackplayers y lo cierto es que ya tenía ganas.
Deseo que disfrutéis de su lectura, tanto como yo redactándola.
[0x01] TARGET
[0x02] ENVIRONMENT & TOOLS
• Oracle VirtualBox2 4.3.20.
• Microsoft Windows 7 Ultimate x64.
• Java3 SE Runtime Environment 7.
• CFF Explorer4 VII.
• OllyDbg5 2.00.01.
• HxD6 1.7.7.0.
• DJ Java Decompiler7 3.12.12.98.
[0x03] KNOWING THE ENEMY
Lo primero que llama la atención al ver el fichero descargado es que se trata de un .exe cuando en el enunciado del reto, hacen referencia a Java.
Si cargamos el binario en CFF Explorer, entenderemos el por qué de ello:
Se ha usado un wrapper (Jar2Exe) o envoltorio, para empaquetar el/los .jar que se generaron al construir el binario original.
Es evidente que el primer objetivo es obtener el .jar inicial, para posteriormente poder descompilar sus clases.
[0x04] EXTRACTING JAR FILE
Entre las muchas características que tiene Jar2Exe, hay una muy interesante:
De lo cual podemos inferir que por mucho análisis estático que hagamos al ejecutable, poco podremos sacar.
Descargándonos la versión demo de este producto y haciendo alguna que otra prueba de empaquetado y/o protección con algún .jar simple, llegaremos a la conclusión de que este, será cifrado y almacenado en la sección .rsrc (resource) como recurso RCDATA que suele ser un recurso típico de almacenamiento para algunas aplicaciones de cifrado/compresión de ficheros.
Basta con arrojar una mirada al recurso, para ver su contenido cifrado:
Por tanto, si a esa zona le ponemos un punto de ruptura, con total seguridad que se disparará en la rutina de descifrado de jar2exe.
Tan solo queda, situarnos al final del bucle, para ver en el registro EAX la dirección del .jar descifrado y en ECX su tamaño en bytes:
Copiamos esos 0x2240 bytes en el editor hexadecimal y lo guardamos en un fichero con extensión .jar:
[0x05] GET SOURCE CODE
Estamos en disposición de poder obtener el código fuente y ver en que clase y que método está el algoritmo que controla la acción de validar usuario/contraseña. Para ello utilizaremos una herramienta llamada DJ Java Decompiler y que nos permitirá extraer los ficheros .class:
Tan solo queda decompilar la clase Login.class y analizar su código:
Observamos como el nombre de usuario es Administrador y la contraseña debe ser el resultado de ejecutar el método mueve, argumentándole “qviregvq0”.
A partir de aquí ya solo quede analizar ese método o implementarlo en un proyecto a parte para obtener la contraseña. Esto es ya a gusto del consumidor:
[0x06] ENDING
No quiero despedirme sin antes agradecer al Te@m de Hack Players su excelente trabajo, a los lectores que hayan llegado hasta aquí y a mis compañeros de equipo por estar ahí siempre que los necesito:
{@NoxOner , @4r4nL , @javierprtd , @sanguinawer , @sergiollata ,
@ajgomezlopez , @alguien_tw }
@amn3s1a_team
A todos vosotros, GRACIAS!!
No temo a los ordenadores; lo que temo es quedarme sin ellos
-- Isaac Asimov ---
Una gran enseñanza... Pero la pregunta del millón de dolares, en realidad hay alguna manera en como yo pueda crear código y esconderlo a tal grado que nadie pueda conocer mis fuentes?
ResponderEliminarCreo que seria si la respuesta es NO, ahí tenemos un nuevo reto.
Saludos a todos y espero la respuesta a mi consulta.
hay muchas maneras de ocultar el código haciendo más dificil la vida a los decompiladores: ofuscar el código mediante conversiones y funciones, añadir intrucciones basura, cifrar strings con DexGuard, etc. pero al final el código tendrá que reconvertirse para ser ejecutado por la VM... por lo tanto si tenemos control sobre la máquina podremos volcar la memoria, introducir hooks en la librería del sistema... y en definitiva obtener el código que se está ejecutando.
EliminarEntonces la respuesta es NO, no hay manera de esconder al 100% mi código, eso me lleva a una segunda pregunta.
EliminarEntonces cuando se obtiene un software java pagado, siempre hay forma de obtener y utilizar ese código fuente, sin pagar?
se me ocurre también por ejemplo requerir el acceso a un tercero para descargar partes de código según licencia y mediante validación con cifrado asimétrico, pero al final el código de igual manera se ejecutará en el dispositivo que podría estar preparado para analizarlo... por lo que seguiría siendo poner trabas y me temo que la respuesta, efectivamente, es "NO, no hay manera de esconder al 100% el código"...
Eliminary esto me lleva a tu segunda pregunta y a otra afirmación para mi correcta: "siempre hay forma de obtener y utilizar ese código fuente"... PERO OJO, cuando decompilar el código requiere mucho esfuerzo (porque se han tomado medidas para ofuscarlo o simplemente por la complejidad propia del programa) simplemente compensa pagar por usarlo o escribir tus propias líneas de código porque te llevará menos tiempo que hacer una ingeniería inversa...
moraleja: nunca estarás 100% seguro, pero si tomas todas las medidas de seguridad reducirás proporcionalmente el riesgo y la exposición de tu código
Como puedo espiar el facebook .whatsap.o la ubicación de mi pareja ?
ResponderEliminarbueno tuto y divertido, pero en Carriage Return (CF), es (CR)
ResponderEliminarNecesito contactar con un Hacker para que me ayude a entrar en mi cuenta de facebook y que elimine otra cuenta que tengo es urgente porfa ya lo he intentado todo para volver a ingresar y nada funciona
ResponderEliminar