En la mayoría de los CTF/Wargames en los que hemos participado hasta el momento, siempre tenemos que enfrentarnos con pruebas relacionadas con el tan conocido QR, hago apertura de este espacio para ir recopilando información de cultura general sobre los códigos QR y para adjuntar los diferentes Write-Up de las pruebas relacionadas con este. Datos de interés

• Los QR code son de dimensión n x n lo que implica que deben ser cuadrados.
• Los cuadros de la esquina definen la posición en que se encuentra el QR por lo tanto puede ser leído en cualquier angulo.
• Se debe respetar el borde blanco al rededor de los tres recuadros de las esquinas.
• Los cubos se encuentran “conectados” por una linea intermitente de pieles blancos y negros (iniciando siempre en negro) entre sus esquinas internas (está era la corrección del CTF-SdbI).
• Si el QR se lee desde un dispositivo móvil como PDA o iPod este puede estar en escala de grises o en varios colores, mientras su fondo sea blanco no se altera su lectura.

¿Qué es un hash?

En el mundo de la informática, hash es un término bastante usado y aunque ni lo te lo imagines hace parte de una gran cantidad de cosas que usas, por ejemplo es común observar que en muchas de las paginas antes de descargar un programa u archivo nos muestren la siguiente información:

File: Nombredelprograma.pdf
md5: 085f4e1cf27dcc1be119d713077bd28

La primera línea es de nuestro entendimiento sencillamente es el nombre del archivo, pero probablemente no comprendas para que se presenta la segunda línea, el objetivo es que las personas puedan descargar el programa y por medio de alguna herramienta (como MD5 context menu en Windows o md5sum en Linux) puedan generar su MD5 (hash) y si el programa descargado no ha sido modificado el MD5 debe ser idéntico al presentado por la página, pero si cambia esto se debe a que posiblemente el software fue manipulado con alguna intención que no siempre es buena o simplemente fue mal descargado. Por tomar otro ejemplo, en los sitios donde estás registrado encriptan datos sensibles como por ejemplo la contraseña, el resultado de esto es un hash, de esta manera si alguien accede a los datos a simple vista no podría saber tu contraseña. En terminos más tecnicos un hash es:

Se refiere a una función o método para generar claves o llaves que representen de manera casi unívoca a un documento, registro, archivo, etc. (Wikipedia).

Continuando con el anterior articulo sobre Buffers Overflow, en los programas que usan la memoria de la maquina (C, C++) un buffer no es otra cosa un puntero que tiene la posición del primer byte de una cadena y el final está representado por un byte NULL (\0). No hay manera de conocer o reservar el tamaño de un buffer exactamente pues esto depende de los caracteres que estén en el.

Esto genera un problema ya que no podemos controlar la cantidad de datos que metemos en un buffer pues podríamos llegar a meter menos y así dejar basura en el buffer, o agregar de más. Veamos un ejemplo. Recordemos que la memoria se guarda en formato LIFO. Un buffer que contenga abc se vería así “|\0|c|b|a|”, mientras que la memoria que contiene a los buffers abc y 12345 se verían así “|\0|5|4|3|2|1|-|-|\0|c|b|a|” donde |-| representa una zona vacía. Esto se debe a que la memoria ocupa bloques “words” de 4 bytes, por lo que para guardar información debemos usar una cantidad de bytes múltiplo de este número, en este caso 12.

Iniciando una serie de artículos sobre cifrados criptográficos vamos a empezar con uno muy famoso, César o Caesar, un cifrado que se usaba en la antigua roma (su nombre es en honor a Julio César) para cifrar los mensajes, es por sustitución simple y su funcionamiento es el siguiente:

Se ingresa un texto cualquiera y una semilla que en este caso será un número, ese número correrá la posición de la letra en cuestión n veces en el alfabeto común, ósea si se ingresa el texto “A” y la semilla 28 entonces se procede a hacer la suma, la letra A tiene la posición 0, viéndolo desde una maquina se toma cero como la primera posición; se suman 0 y la semilla en este caso 28 y el resultado como tiene que estar dentro del alfabeto entonces se modula o se divide el resultado de la suma sobre la longitud del alfabeto y se toma el residuo como indexo de la nueva letra en su estado cifrado, ósea:

28%26 = 2
Caesar("A")="C"

Para empezarme en el mundo de Javascript, decidí mudar un código mío que me gusta mucho por su simpleza pero que requiere casi todos los componentes de un lenguaje… El Snake. Bien, si nunca han jugado Snake juéguenlo ya, aunque es un clásico juego y dudo que nunca lo hayan jugado.  El juego se trata de una culebrita falocrática que quiere comer bolas y va creciendo haciendo difícil su movimiento ya que si se estrella con los bordes o con ella misma, muere.

Así que la idea es definir un movimiento temporalizado y ver como almacenar las posiciones [x,y] en los que se componen los segmentos de la culebra. Así mismo definir eventos (ratón y teclado) que hacen posible el movimiento de la culebra en el entorno. Entonces como hice bien, la verdad me da pereza hablar de los algoritmos de movimiento, ya que funcionan con congruencia de triángulos (mouse) y el teclado pues aumentando y modulando… nada raro. Así que el ¿cómo hago para generar los segmentos (círculos, cuadros) que componen la culebra?

Funcionamiento del Snake

Uso el Array de Javascript (en Java solía usar un vector) ya que es totalmente dinámica la cantidad de circulitos, aumenta en 2 cuando la culebra come algo. Así que lo que hago es llamar un arreglo intermedio e intercambio información con un ciclo. Lo siguiente es detectar que la culebra come o se ha estrellado, y eso lo hago con las funciones distancia, que no son más que la norma del vector distancia de los centros de los círculos. así que trato de que un punto de la comida este contenida en el espacio geométrico determinado por el segmento principal de la culebra.

El movimiento solo es posible con los eventos y con los temporizadores, los eventos son fáciles de usar, solo es llamar una función que se cargará cuando el navegador detecte movimiento de mouse o de teclado y se carga por ejemplo así:

document.onmousemove = MoverMouse;

La mayoría de los exploits basados en Buffer Overflow tratan de obtener una cuenta administrativa mediante la ejecución de código malicioso. El principio es muy simple: las instrucciones maliciosas se almacenan en un buffer, donde se desbordan alterando varias secciones de la memoria manipulando el proceso. Existen dos tipos de ataques: Stack Overflow y Heap Overflow. Primero veamos como se organiza la memoria:

Cuando un programa se ejecuta sus elementos se mapean en la memoria de cierta manera, la parte alta contiene los parámetros del proceso, luego siguen dos secciones, stack y heap, que se colocan durante el tiempo de ejecución. La stack o pila es donde se almacenan las variables y argumentos necesarios para llamar a una función, esta funciona con el sistema LIFO (Last In, First Out) y crece hacia la memoria baja. Las variables dinámicas se almacenan en heap o montículo. Generalmente son el resultado de funciones como malloc en C que nos devuelven un puntero a la dirección de memoria reservada. Las secciones .bss y .data están destinadas a las variables globales y se colocan durante la compilación. La sección .data contiene información estatica inicializada, mientras que la que no esta inicializada se encuentra en .bss. La ultima seccion es .text que contiene el código e incluso información de solo lectura.

Algunos ejemplos de como funciona:

char vacia;  // .bss
char valor = 'a';  // .data
int main (){
static int vacia2; // .bss
static int valor2 = 1; // .data
char *punt = malloc(3); // Heap
}