0x41haz - TryHackMe
SUMMARY
En este caso debemos analizar un archivo binario ejecutable ELF y obtener el passwod que nos solicitan al momento de que lo ejecutamos. Pero antes nos damos cuenta de que si utilizamos el comando file sobre el archivo con el fin de saber el tipo y formato del archivo, nos toparemos con un mensaje de error, y esto es debido a que el sexto byte ha sido alterado. Además, este sexto byte va a definir la endianidad del archivo ELF de 64 bits. Una vez corregido el byte, podremos utilizar Ghidra para poder observar y analizar el código fuente del archivo binario, logrando saber que la contraseña solicitada debe tener 13 caracteres. Además, logramos saber que el programa realiza una comparación de los caracteres ingresados en la contraseña con otros caracteres de otras variables predefinidas en el programa, pero debemos tener en cuenta que los bytes de las variables predefinida se almacenan en la memoria en el formato little-endian. Para comprobar esto podemos utilizar el marco radaere2 en su modo depuración.
DESARROLLO
En este caso debemos analizar el binario que nos proveen en el enunciado del laboratorio, y descubrir la contraseña.
Podemos observar que el archivo binario viene a tener una extension bastante inusual. Por esta razon es que utilizamos el comando file sobre el, con el fin de determinar el tipo y formato del archivo. Logrando saber que viene a ser un archivo binario ejectuable ELF con una arquitectura de 64 bits aunque aparece un mensaje de error de unknown arch 0x3e00.
Ahora buscaremos en el motor de busqueda de Google informacion sobre este error.
En el segundo resultado que nos arroja el motor de busqueda de Google, encontramos un articulo que nos explica el origen del mensaje de error que obtuvimos en nuestro archivo binario ejecutable. Este articulo explica que es posible alterar el sexto byte del contenido de un archivo binario ejecutable ELF sin alterar la ejecucion del archivo. Ademas, nos indica que el sexto byte define la endianidad LSB(01) o MSB(01).
Ahora observaremos el contenido en formato hexadecimal de nuestro archivo binario ejecutable para comprobar si el sexto byte ha sido alterado.
Podemos comprobar que el sexto byte ha sido alterado a un valor de 02. Luego, corregimos su valor a 01, y volvemos a utilizar el comando file sobre el, logrando resolver el mensaje de error que obteniamos anteriormente.
Ahora ejecutaremos el archivo binario ejecutable.
Podemos observar que nos topamos con un mecanismo de autenticacion que nos solicita un password. Ademas, si utilizamos el comando strings sobre el archivo binario, obtendemos strings que son legibles para los seres humanos, pero no obtenemos ningun pista sobre el password.
Ahora utilizaremos la herramienta Ghidra con el fin de observar el codigo fuente del archivo binario.
Podemos observar que el password que nos solicita ingresar el programa va ser almacenado en la variable local_48, luego se determina el numero de caracteres ingresado y ese valor pasa por un condicional if, y si tiene un valor diferente a 13( cuya equivalencia en hexadecimal es 0xd), nos aparecera el mensaje Is it correct, I don’t think so y se finalizara la ejecucion del programa. Pero si el numero de caracteres es igual a 13, nos toparemos otro condicional if donde se realizara un recorrido sobre los bytes de la variable local_48 con el fin de compararlo con cada byte de la variable local_1e( que viene a ser un string fg$52@@2 cuya representacion hexadecimal es 0x6667243532404032). Ademas, en el caso de que los bytes no coincidan, el bucle while se rompera, y nos aparecera el mensaje Nope.
Hasta ahora podemos deducir que el password que debemos ingreser debe tener un numero de caracteres igual a 13, y los primeros caracteres deben ser igual al string fg$52@@2, pero esto son solo 8 caracteres, por lo que deduzco que el segundo condincional tomara valores almacenados en memorias adyacentes a la memoria donde se almaceno la variable local_1e. Ademas, me imagino que estas memorias adyacantes van a estar ocupados por los valores de las otras dos variables que se definieron al inicio del programa, es decir, local_16 y local_12. Ademas, el numero de caracteres que suman ambas variables son 5 por lo que mis conjeturas tendrian bastante sentido.
Podemos observar que mis conjenturas fallaron, pero luego de investigar, averigue que los bytes tienden almacenarse en memoria en dos formatos, en litte-endian y big-endian, la diferencia en ambos formatos, radica en que el primer formato, la cadena hexadecimal se almacenaran en memoria en el mismo orden, caso contrario sucede con el otro formato, que se almacenaran en orden inverso.
Ahora probaremos la conjetura, de que los bytes de las variables del programa se almacenaran en el formato little-endian, para ello nuestro password que ingresaremos tendra la forma 2@@25$gfsT&@L.
De esta manera logramos encontrar el password correcto. Otra manera que pudimos haber sabido que el almacenamiento de los bytes en memoria se da en formato litte-endian es analizando el archivo binario con el framework radare2 en su modo de depuracion con el fin de analizar el flujo de ejecucion del programa.
Podemos observar en el analisis del flujo de ejecucion del programa, que los bytes se almacenan en la memoria en formato little-endian. De esta manera logramos demostrar el uso de este formato.