Warning: This challenge is still active and therefore should not be resolved using this information.
Aviso: Este reto sigue en activo y por lo tanto no se debería resolver utilizando esta información.

Intro

This crackme is for the crack challenge 6 of canyouhack.it.

In this crackme the goal is to turn on all the lights. Note that a light off to the next, so if we interrupt this, we win.

Tools

Exeinfo (For crackme info)

Delphi Decompiler (For decompile)

 OllyDbg (For debug)

Decompiling

With Delphi Decompiler we can found easy the buttons and his offsets.
Go to the offset 401A64 in OllyDbg and analyze the code.
We view two jumps, one turn ON the light and the other Turn OFF the next light. Patching the call from offset 401A8B we get the serial.

Links


Intro Hoy tenemos aquí otro crackme sacado del baúl de los recuerdos. En este caso se trata de una protección
Warning: This challenge is still active and therefore should not be resolved using this information. Aviso: Este reto sigue en
AperiSolve es un conjunto de herramientas de análisis esteganográfico que nos ayuda a echar un primer vistazo cuando sospechamos que
Aviso: Este crackme forma parte de una serie de pruebas de Yoire.com que todavía está en activo. Lo ético si

Se nos entrega el siguiente ELF:

/* This file was generated by the Hex-Rays decompiler version 8.4.0.240320.
   Copyright (c) 2007-2021 Hex-Rays <info@hex-rays.com>

   Detected compiler: GNU C++
*/

#include <defs.h>


//-------------------------------------------------------------------------
// Function declarations

__int64 (**init_proc())(void);
void sub_1020();
// int printf(const char *format, ...);
// int getchar(void);
// int fflush(FILE *stream);
// __int64 __isoc99_scanf(const char *, ...); weak
// void __noreturn exit(int status);
// int __fastcall _cxa_finalize(void *);
void __fastcall __noreturn start(__int64 a1, __int64 a2, void (*a3)(void));
FILE **deregister_tm_clones();
__int64 register_tm_clones(); // weak
FILE **_do_global_dtors_aux();
__int64 __fastcall frame_dummy(_QWORD, _QWORD, _QWORD); // weak
int __fastcall main(int argc, const char **argv, const char **envp);
_BOOL8 __fastcall comprobacion(char a1, char a2, int a3);
void _libc_csu_fini(void); // idb
void term_proc();
// int __fastcall _libc_start_main(int (__fastcall *main)(int, char **, char **), int argc, char **ubp_av, void (*init)(void), void (*fini)(void), void (*rtld_fini)(void), void *stack_end);
// int __fastcall __cxa_finalize(void *);
// __int64 _gmon_start__(void); weak

//-------------------------------------------------------------------------
// Data declarations

_UNKNOWN _libc_csu_init;
__int64 (__fastcall *_frame_dummy_init_array_entry)() = &frame_dummy; // weak
__int64 (__fastcall *_do_global_dtors_aux_fini_array_entry)() = &_do_global_dtors_aux; // weak
void *_dso_handle = &_dso_handle; // idb
char *a = "MdfnJk"; // weak
char *b = "jYx}"; // weak
char *c = "gWmfk"; // weak
char *d = "mlvpc"; // weak
char *f = "neU++w"; // weak
FILE *_bss_start; // idb
char completed_0; // weak


//----- (0000000000001000) ----------------------------------------------------
__int64 (**init_proc())(void)
{
  __int64 (**result)(void); // rax

  result = &_gmon_start__;
  if ( &_gmon_start__ )
    return (__int64 (**)(void))_gmon_start__();
  return result;
}
// 40D0: using guessed type __int64 _gmon_start__(void);

//----- (0000000000001020) ----------------------------------------------------
void sub_1020()
{
  JUMPOUT(0LL);
}
// 1026: control flows out of bounds to 0

//----- (0000000000001090) ----------------------------------------------------
// positive sp value has been detected, the output may be wrong!
void __fastcall __noreturn start(__int64 a1, __int64 a2, void (*a3)(void))
{
  __int64 v3; // rax
  int v4; // esi
  __int64 v5; // [rsp-8h] [rbp-8h] BYREF
  char *retaddr; // [rsp+0h] [rbp+0h] BYREF

  v4 = v5;
  v5 = v3;
  _libc_start_main(
    (int (__fastcall *)(int, char **, char **))main,
    v4,
    &retaddr,
    (void (*)(void))_libc_csu_init,
    _libc_csu_fini,
    a3,
    &v5);
  __halt();
}
// 1096: positive sp value 8 has been found
// 109D: variable 'v3' is possibly undefined

//----- (00000000000010C0) ----------------------------------------------------
FILE **deregister_tm_clones()
{
  return &_bss_start;
}

//----- (00000000000010F0) ----------------------------------------------------
__int64 register_tm_clones()
{
  return 0LL;
}
// 10F0: using guessed type __int64 register_tm_clones();

//----- (0000000000001130) ----------------------------------------------------
FILE **_do_global_dtors_aux()
{
  FILE **result; // rax

  if ( !completed_0 )
  {
    if ( &__cxa_finalize )
      _cxa_finalize(_dso_handle);
    result = deregister_tm_clones();
    completed_0 = 1;
  }
  return result;
}
// 4080: using guessed type char completed_0;

//----- (0000000000001175) ----------------------------------------------------
int __fastcall main(int argc, const char **argv, const char **envp)
{
  char v4; // [rsp+7h] [rbp-9h] BYREF
  int v5; // [rsp+8h] [rbp-8h]
  bool v6; // [rsp+Fh] [rbp-1h]

  v6 = 1;
  v5 = 0;
  while ( v6 )
  {
    fflush(_bss_start);
    printf("\nIntroduce la letra correcta:\t");
    __isoc99_scanf("%c", &v4);
    getchar();
    if ( v5 > 5 )
    {
      if ( v5 > 9 )
      {
        if ( v5 > 14 )
        {
          if ( v5 > 19 )
            v6 = comprobacion(v4, f[v5 - 20], 10);
          else
            v6 = comprobacion(v4, d[v5 - 15], 2);
        }
        else
        {
          v6 = comprobacion(v4, c[v5 - 10], 8);
        }
      }
      else
      {
        v6 = comprobacion(v4, b[v5 - 6], 17);
      }
    }
    else
    {
      v6 = comprobacion(v4, a[v5], 5);
    }
    if ( !v6 )
    {
      printf("Incorrecta");
      exit(1);
    }
    printf("\n%c\n", (unsigned int)v4);
    if ( v5 == 25 )
    {
      printf("Ya tienes la flag!!");
      exit(1);
    }
    ++v5;
  }
  return 0;
}
// 1060: using guessed type __int64 __isoc99_scanf(const char *, ...);
// 4050: using guessed type char *a;
// 4058: using guessed type char *b;
// 4060: using guessed type char *c;
// 4068: using guessed type char *d;
// 4070: using guessed type char *f;

//----- (0000000000001352) ----------------------------------------------------
_BOOL8 __fastcall comprobacion(char a1, char a2, int a3)
{
  return a1 == (a3 ^ a2);
}

//----- (0000000000001390) ----------------------------------------------------
void __fastcall _libc_csu_init(unsigned int a1, __int64 a2, __int64 a3)
{
  signed __int64 v4; // rbp
  __int64 i; // rbx

  init_proc();
  v4 = &_do_global_dtors_aux_fini_array_entry - &_frame_dummy_init_array_entry;
  if ( v4 )
  {
    for ( i = 0LL; i != v4; ++i )
      ((void (__fastcall *)(_QWORD, __int64, __int64))*(&_frame_dummy_init_array_entry + i))(a1, a2, a3);
  }
}
// 1170: using guessed type __int64 __fastcall frame_dummy(_QWORD, _QWORD, _QWORD);
// 3DE8: using guessed type __int64 (__fastcall *_frame_dummy_init_array_entry)();
// 3DF0: using guessed type __int64 (__fastcall *_do_global_dtors_aux_fini_array_entry)();

//----- (00000000000013F4) ----------------------------------------------------
void term_proc()
{
  ;
}

Extracción de la Flag

Si nos fijamos en las líneas 41 a la 45 vemos las siguientes cadenas:

a = «MdfnJk»
b = «jYx}»
c = «gWmfk»
d = «mlvpc»
f = «neU++w»

Usaremos las cadenas y los valores XOR especificados para cada rango de v5 en el main (líneas 123 a 182) para determinar los caracteres correctos.

Para v5 de 0 a 5: v6 = comprobacion(v4, a[v5], 5);
Significa que: v4 debe ser igual a a[v5] ^ 5

Para v5 de 6 a 9: v6 = comprobacion(v4, b[v5 – 6], 17);
Significa que: v4 debe ser igual a b[v5 – 6] ^ 17

Para v5 de 10 a 14: v6 = comprobacion(v4, c[v5 – 10], 8);
Significa que: v4 debe ser igual a c[v5 – 10] ^ 8

Para v5 de 15 a 19: v6 = comprobacion(v4, d[v5 – 15], 2);
Significa que: v4 debe ser igual a d[v5 – 15] ^ 2

Para v5 de 20 a 25: v6 = comprobacion(v4, f[v5 – 20], 10);
Significa que: v4 debe ser igual a f[v5 – 20] ^ 10

Cálculo de los caracteres correctos:
Para v5 de 0 a 5:
a[0] = ‘M’, M ^ 5 = 0x4D ^ 0x05 = 0x48 -> ‘H’
a[1] = ‘d’, d ^ 5 = 0x64 ^ 0x05 = 0x61 -> ‘a’
a[2] = ‘f’, f ^ 5 = 0x66 ^ 0x05 = 0x63 -> ‘c’
a[3] = ‘n’, n ^ 5 = 0x6E ^ 0x05 = 0x6B -> ‘k’
a[4] = ‘J’, J ^ 5 = 0x4A ^ 0x05 = 0x4F -> ‘O’
a[5] = ‘k’, k ^ 5 = 0x6B ^ 0x05 = 0x6E -> ‘n’
Resulta en la cadena: HackOn

Para v5 de 6 a 9:
b[0] = ‘j’, j ^ 17 = 0x6A ^ 0x11 = 0x7B -> ‘{‘
b[1] = ‘Y’, Y ^ 17 = 0x59 ^ 0x11 = 0x48 -> ‘H’
b[2] = ‘x’, x ^ 17 = 0x78 ^ 0x11 = 0x69 -> ‘i’
b[3] = ‘}’, } ^ 17 = 0x7D ^ 0x11 = 0x6C -> ‘l’
Resulta en la cadena: {Hil

Para v5 de 10 a 14:
c[0] = ‘g’, g ^ 8 = 0x67 ^ 0x08 = 0x6F -> ‘o’
c[1] = ‘W’, W ^ 8 = 0x57 ^ 0x08 = 0x5F -> ‘_’
c[2] = ‘m’, m ^ 8 = 0x6D ^ 0x08 = 0x65 -> ‘e’
c[3] = ‘f’, f ^ 8 = 0x66 ^ 0x08 = 0x6E -> ‘n’
c[4] = ‘k’, k ^ 8 = 0x6B ^ 0x08 = 0x63 -> ‘c’
Resulta en la cadena: o_enc

Para v5 de 15 a 19:
d[0] = ‘m’, m ^ 2 = 0x6D ^ 0x02 = 0x6F -> ‘o’
d[1] = ‘l’, l ^ 2 = 0x6C ^ 0x02 = 0x6E -> ‘n’
d[2] = ‘v’, v ^ 2 = 0x76 ^ 0x02 = 0x74 -> ‘t’
d[3] = ‘p’, p ^ 2 = 0x70 ^ 0x02 = 0x72 -> ‘r’
d[4] = ‘c’, c ^ 2 = 0x63 ^ 0x02 = 0x61 -> ‘a’
Resulta en la cadena: ontra

Para v5 de 20 a 25:
f[0] = ‘n’, n ^ 10 = 0x6E ^ 0x0A = 0x64 -> ‘d’
f[1] = ‘e’, e ^ 10 = 0x65 ^ 0x0A = 0x6F -> ‘o’
f[2] = ‘U’, U ^ 10 = 0x55 ^ 0x0A = 0x5F -> ‘_
f[3] = ‘+’, + ^ 10 = 0x2B ^ 0x0A = 0x21 -> ‘!’
f[4] = ‘+’, + ^ 10 = 0x2B ^ 0x0A = 0x21 -> ‘!’
f[5] = ‘w’, w ^ 10 = 0x77 ^ 0x0A = 0x7D -> ‘}’
Resulta en la cadena: do_!!}

Uniendo todas las partes, obtenemos la flag completa: HackOn{Hilo_enc_ontrado_!!}

En Parque Jurásico (1993), la informática no es solo un elemento narrativo, es una pieza clave del suspense y del conflicto. A diferencia de otras películas donde las pantallas muestran interfaces ficticias o visualmente espectaculares pero irreales, Parque Jurásico opta por una aproximación sorprendentemente sobria y auténtica.

Durante bastantes escenas, se nos muestran terminales, ventanas de código y comandos que, lejos de ser decorativos, pertenecen a sistemas reales utilizados por programadores profesionales de principios de los años 90. Este detalle, que puede pasar desapercibido para el público general, resulta especialmente interesante desde un punto de vista técnico. En otras palabras, el trabajo de producción es excelente y destaca como una de las películas más respetuosas con la informática real de su época.

No es “código de película”: es software real

Uno de los puntos más interesantes es que el código que aparece en pantalla no fue escrito para la película. No hay pseudocódigo, ni pantallas diseñadas solo para quedar bonitas en cámara. Lo que se ve es software real, ejecutándose en el entorno Macintosh Programmer’s Workshop (MPW), el kit oficial de Apple para desarrolladores en aquellos años. El sistema operativo que se reconoce es un Macintosh clásico (System 7) corriendo sobre máquinas de la serie Quadra, auténticos pepinos para la época. Vamos, que cuando John Hammond decía aquello de «no hemos reparado en gastos», también iba en serio en lo informático.

«No hemos reparado en gastos»

En este punto no se le puede reprochar demasiado a la película. En líneas generales es bastante fiel a la novela, aunque la resolución del problema de seguridad se aborda de forma distinta. En el libro es el ingeniero Ray Arnold quien detecta el fallo y consigue reconducir la situación. En la película, sin embargo, el personaje desaparece cuando va a los barracones a restablecer la corriente del parque, con el resultado que todos conocemos.

Lo curioso es que muchos personajes sí cambian de forma notable con respecto al libro, el niño es mayor y más friki de los ordenadores, Ray Arnold no muere y acaba salvando la situación, o Gennaro es más atlético y bastante más valiente. Sin embargo, el gran disparate técnico permanece intacto.

En la novela se menciona de pasada a un equipo de informáticos de Cambridge que supuestamente colaboró en el diseño del software. Aun así, la puesta en marcha y la explotación del sistema recaen prácticamente en una sola persona, Dennis Nedry. Evidentemente, tanto al libro como al guion les viene de perlas que todo dependa de una única persona para que el desastre sea posible, pero cuesta aceptar que en un parque donde todo está duplicado, el control informático central dependa de una sola persona.

Curiosamente, en uno de los monitores de Nedry se puede ver una foto de Oppenheimer con la frase «Beginning of baby boom», de la que podemos sacar la conclusión de que Nedry es perfectamente consciente de que su trabajo puede tener consecuencias catastróficas e irreversibles. También es un maravilloso guiño del equipo de producción que nos está indicando exactamente donde se va originar el desastre.

Al final, Parque Jurásico no va de dinosaurios, ni siquiera de genética. Va de personas. Y, más concretamente, de personas con demasiado poder y muy pocos compañeros de equipo y poca supervisión.

Desde el punto de vista informático, la película es casi entrañable. Todo es serio, profesional y real… hasta que descubrimos que el sistema más complejo jamás construido depende, en la práctica, de un solo programador cabreado, mal pagado y con demasiadas líneas de código en la cabeza. Ningún comité de arquitectura, ninguna auditoría externa, ningún segundo par de ojos. Solo Dennis Nedry y su teclado. ¿Qué podía salir mal?

Lo curioso es que ni la película ni el libro se molestan en disimularlo demasiado. Te hablan de sistemas redundantes, de seguridad, de control absoluto… pero el corazón digital del parque es un castillo de naipes. Eso sí, un castillo de naipes programado en máquinas de primera, con software real y pantallas que hoy siguen pareciendo más creíbles que muchas producciones actuales.

Quizá por eso Parque Jurásico envejece tan bien. Porque, incluso cuando se equivoca, lo hace con honestidad. No intenta venderte magia disfrazada de tecnología. Te muestra ordenadores de verdad, código de verdad y errores muy humanos. Y al final, tanto en la novela como en la película, el mensaje es el mismo, puedes clonar dinosaurios, diseñar parques imposibles y rodearte de la mejor tecnología del mundo, que si todo depende de una sola persona, tarde o temprano, el sistema se vendrá abajo.

Y no, el problema no eran los dinosaurios, nunca lo fueron.

Primeras impresiones

El crackme es el típico de usuario y número de serie. Si no introduces un nombre te salta un messagebox indicándotelo y si introduces cualquier información sale un mensaje de error.
Si dejamos solamente el serial en blanco nos sale un mensaje de error muy interesante diciéndonos que introduzcamos un número entre 1 y 2^32. Por lo tanto ya sabemos que nuestro serial está entre 1 y 4294967296.
PEiD no arroja resultados pero una primera impresión con Ollydbg hace creer que está programado en ensamblador y que no está comprimido.

Al ataque con Ollydbg

Cargamos el crackme en Ollydbg y hacemos click derecho Search for > Names
Vemos dos referencias interesantes como son:
  •  &USER32.GetDlgItemInt
  •  &USER32.GetDlgItemTextA
Ponemos sendos breakpoints y damos al play.
Vemos que para en USER32.GetDlgItemTextAy que retorna al offset 4010E7
 
Vamos a 4010E7 y vemos que pasa.
 
Hace un Test eax,eax por si hemos introducido algún nombre y si no es así nos muestra la nag.
Continuamos con la ejecución y para en el siguiente breakpoint, esta vez el referente a USER32.GetDlgItemInt, vamos al offset 401108 a ver que nos espera.
 
Se puede ver claramente que carga en EAX nuestro número de serie en hexa, lo compara con ESI que vale 0 y si son iguales nag de error y si no continua a 401120 donde guarda en la pila nuestro nombre y serial y llama al offset 401000.
 
 Veamos que hay en el offset 401000.
 
Aquí vemos una primera parte con un bucle en el que interviene nuestro nombre y donde obtendremos el “HashName” y posteriormente una operaciones aritméticas en las que finalmente modifica el valor de EAX. Tengamos en cuenta que la comprobación final es un Test eax,eax o lo que es lo mismo, comprueba si EAX = 0 y si es 0 salta al mensaje de error como vemos en la imagen siguiente.
En resumen:
  • Obtenemos el HashName.
  • Realizamos unas operaciones a ese HashName (LOCAL.1) y al serial introducido (ARG.2).
  • Si EAX <> 0 entonces serial correcto.

Sacando el “HashName”

Veamos un ejemplo de obtención del hashname para el usuario “abc”. El bucle se repetirá tantas veces como letras tenga el nombre.

Entendiendo la comprobación del serial

 
En resumen:
  • Necesitamos que EAX <> 0.
  • Necesitamos que (HashName XOR Serial) = 0 ya que:
a.       La negación de 0 es 0 –>NEG(0) = 0
b.      La resta con acarreo de 0 – 0 = 0 –>SBB 0,0 = 0
 
Hay que tener en cuenta que la resta con acarreo (SBB) de cualquier número, dará como resultado en EAX = FFFFFFFF, que al incrementar en 1 quedará en 0.
Por lo tanto si cumplimos las condiciones anteriormente expuestas, al incrementar EAX con INC EAX, este quedará en 1 haciendo nuestro serial válido.

Generando el serial válido

 Las operaciones que se realizan sobre nuestro serial son NOT, SUB y XOR. Por suerte para nosotros son reversibles quedando nuestro serial así:
Serial válido = [NOT(HashName) + 0xBADC0DE5] XOR 0x1337C0DE
Para el nombre “abc” sería:
[(NOT(734111798) + 3134983653)] XOR 322420958 = 2620237168

 Keygen en ensamblador

Como no es propósito de este manual enseñar a hacer un keygen desde 0, muestro el código importante y adjunto los links del código fuente. Si quieres ver como se hace un keygen básico en ASM desde cero mira el tutorial del Keygen para el KeygenMe#01 de eBuC.

Enlaces

 Crackme + Keygen en ASM + WinASM studio 5.1.5 [31MB]

Introducción Hoy vamos a enfrentarnos a cuatro retos de esteganografía relativamente sencillos, y digo relativamente, debido a que hay tantas
Warning: This challenge is still active and therefore should not be resolved using this information. Aviso: Este reto sigue en
Introducción Hoy tenemos aquí un crackme de los que te hacen temblar las conexiones neuronales. Estamos acostumbrados al típico serial
Se nos entrega el siguiente ELF: Extracción de la Flag Si nos fijamos en las líneas 41 a la 45

Introducción

Hoy vamos a enfrentarnos a cuatro retos de esteganografía relativamente sencillos, y digo relativamente, debido a que hay tantas formas de esconder información en un archivo, ya sea imagen, vídeo o sonido, que afrontarlos suele ser desesperante. Las cuatro imágenes son aparentemente las mismas que la que se ve en portada.

Una buena práctica cuando te enfrentas a retos stego de tipo imagen es realizar una búsqueda inversa. Una búsqueda inversa consiste en buscar la imagen original mediante buscadores especializados como TinEye o Google. Si conseguimos la imagen original podemos resolver el reto simplemente comparando o nos puede dar una idea del tipo de modificación por su diferencia de tamaño, colores, degradados, etc.

Stego 1

Descargamos la imagen del reto. Se trata de una imagen JPEG de 526×263 y 76.6 KB (78445 bytes). Su hash SHA1 es «89aed5bbc3542bf5c60c4c318fe99cb1489f267a«

Realizamos una búsqueda inversa de la imagen y encontramos sin dificultad la imagen original mediante TinEye.

18-06-2016 07-27-02

Características de la imagen original:

  • Resolución: 526×263
  • Tamaño: 78447 bytes (76.6 KB)
  • Hash SHA1: 8924676317077fc07c252ddeec04bd2a0ecfdda4

Por lo que vemos ha cambiado el tamaño de 78447 bytes a 78445 bytes y su hash SHA1 tampoco coincide obviamente, lo que nos confirma que ha sufrido alguna modificación. Echando un vistazo con un editor hexadecimal te puedes volver loco por lo que vamos a realizar una comparación mediante la herramienta online DiffNow.

18-06-2016 07-40-51

Al realizar la comparación sale a relucir lo que buscamos. La clave es una simple cadena de texto.

Stego 2

Lo primero es realizar de nuevo la comparación.

ImagenTamañoSHA1
Original78447 bytes8924676317077fc07c252ddeec04bd2a0ecfdda4
imagen2.jpeg116386 bytes7641e3906f795c137269cefef29f30fcb9cb1b07

Como vemos, la imagen ha aumentado significativamente, de 76,6 KB a 113 KB. Cuando el aumento de tamaño llama la atención normalmente tenemos otro archivo insertado. Lo primero que suelo hacer yo es fijarme si ha sido modificado el final del archivo con un editor hexadecimal. Los bytes de cola de un archivo jpg/jpeg son FFD9 y en este caso no vemos modificación alguna al final del archivo. Si el archivo no está al final requiere realizar una búsqueda más exhaustiva. Para estos casos tengo una herramienta de creación propia que se llama Ancillary y que sirve para buscar cierto tipo de archivos dentro de otros como imágenes, documentos de Office, Open Office, pdf, etc. Ancillary encuentra otro jpg que es el que le daba el peso extra y que vemos a continuación. La clave es el título de la película (ojo a las mayúsculas/minúsculas).

image2_thumb

Stego 3

El tercer reto parece que tiene algún error debido a que el archivo coincide completamente con el original. Pienso que se ha subido la imagen original por error. Se lo he comunicado al admin del dominio y si algún día obtengo respuesta actualizaré la entrada.

ImagenTamañoSHA1
Original78447 bytes8924676317077fc07c252ddeec04bd2a0ecfdda4
imagen3.jpeg78447 bytes8924676317077fc07c252ddeec04bd2a0ecfdda4

Actualización 21/08/2016

Al parecer, la solución de este reto es llegar a la conclusión de que la imagen no está modificada. La respuesta del Administrador de la web así lo confirma.

desingsecurity [at] gmail [dot] com – Sorry about the delay, is precisely what is intended with that challenge, they can determine if the image is changed or not , the challenge was solved you . We’ll be equal way improving this point.

Greetings and Thanks

Stego 4

Lo primero es realizar de nuevo la comparación.

ImagenTamañoSHA1
Original78447 bytes8924676317077fc07c252ddeec04bd2a0ecfdda4
imagen4.jpeg93174 bytesa6329ea4562ef997e5afd067f3b53bdab4665851

Al igual que en el caso dos el tamaño ha aumentado significativamente de modo que miramos al final del archivo y esta vez si vemos que hay insertado unos bytes tras el final del jpg (recordemos FFD9)

18-06-2016 07-10-40

El archivo tiene pinta de ser una hoja de cálculo de Open Office o Libre Office según indica la palabra «spreadsheet«. Lo abrimos con Excel y tras analizar la maraña de datos enseguida vemos una clave que llama la atención.

  • Challengeland (El dominio ya no existe) [Archive]

Herramientas utilizadas

Warning: This challenge is still active and therefore should not be resolved using this information.
Aviso: Este reto sigue en activo y por lo tanto no se debería resolver utilizando esta información.

Table of Contents

Intro

This crackme is for the challenge Mobile 2 of canyouhack.it.
This time you need to understand how the crackme works over the web.

Decompiling

The crackme is given again at Google Play, so the first step is to install and recover the APK for decompiling. The latter, I leave to you.
Open the victim with APK Studio and view the content of Mobile2.java
First we view one link:
http://canyouhack.it/Content/Challenges/Mobile/2/index.php
 If we go to the link, we view one string like a hash: 68a571bcf7bc9f76d43bf931f413ab2c. Umm, it’s like MD5. Go to decrypt online and we get the pass: «canyouhack.it». But if we test this password in the crackme, surprise!, nothing happens. We need to continue analyzing the code. Later we view the next interesting link:
«http://canyouhack.it/Content/Challenges/Mobile/2/submit.php?Token=» + Mobile2.token + «&Attempts=»
The program submit one token and concatenate with the number of attempts. Ok but what is the token and what is the number of attempts?
In this point we have to try with the information we already have.
Testing with the link of bottom we get “Nice try!” message.
http://canyouhack.it/Content/Challenges/Mobile/2/submit.php?Token=68a571bcf7bc9f76d43bf931f413ab2c&&Attempts=0
Testing with the link of bottom we get “Very Good, the password is Top*****!” message.
http://canyouhack.it/Content/Challenges/Mobile/2/submit.php?Token=68a571bcf7bc9f76d43bf931f413ab2c&&Attempts=1

  Links