Imaginemos la siguiente situación: Usted tiene la intención de realizar un ataque de fuerza bruta sobre una contraseña aplicando un algoritmo dado. Entonces debe de tomar algunas decisiones importantes que influirán en el rendimiento y el tiempo de ejecución que su programa de crackeo tardará en completar el proceso. A pesar de que puede escribir su aplicación ayudado por las facilidades de algún lenguaje interpretado (como Perl o Python), se da cuenta de que escribir el código en C y obtener un binario compilado puede brindarle algunas mejoras significativas en lo que a performance se refiere.
Finalmente, y antes de correr el programa, cierra todas las aplicaciones y procesos que pudiesen estar consumiendo recursos del sistema: el navegador web, el procesador de textos y quizás hasta su preciado antivirus. Ahora ya puede dejar que su ordenador haga todo el trabajo y sentarse en el sofá a la espera de resultados, al fin y al cabo su procesador se encuentra ocupado únicamente con el algoritmo de bruteforce, ¿verdad?
La cruda realidad no muestra una cara tan bonita, por desgracia. Puede regresar a su equipo y abrir el monitor de procesos/administrador de tareas, tranquilamente otros 20 procesos podrían estar ejecutándose además del suyo, y algunos de ellos ni siquiera pueden “matarse” sin cargarse el sistema. Pero esto no es más que la punta del iceberg, su SO está gestionando por detrás múltiples hilos de kernel, interrupciones, mecanismos de entrada/salida (I/O), y si todavía no se ha desconectado de Internet, atendiendo a todos los paquetes que entran y salen por la interfaz de red.
Y hay más, muchísimo más, su querido sistema multitarea realiza controles de colas, intercambio de stacks entre procesos, IPC, y está haciendo verdaderas virguerías con la paginación y gestión de memoria virtual ayudado por el hardware subyacente. Digamos que cada 100ms una interrupción se genera en el procesador (ticks de reloj) y el núcleo del sistema retoma el control e invoca el scheduler para comprobar cuál es el próximo proceso que merece su tiempo (slice). Desde luego, esto es lo que hace un sistema operativo moderno, y otra infinidad de tareas que de forma intencionada nos dejamos en el tintero, pero usted solo quería crackear una contraseña, todo lo demás es “tiempo perdido”.
Bajo esta premisa decidí realizar la siguiente demostración. Cree un pequeño programa que aplicara la conjectura de Collatz para los primeros cincuenta millones de números. Al igual que un algoritmo de bruteforce, esto proporciona alimento suficiente para el procesador. El cálculo es sencillo, se selecciona un número, si es par se divide entre 2 y si es impar se multiplica por 3 y se suma 1, y se vuelve a aplicar el mismo proceso sobre el resultado. La conjetura dice que para todos los números naturales la secuencia siempre termina en 1. Observe el siguiente programa:
Finalmente, y antes de correr el programa, cierra todas las aplicaciones y procesos que pudiesen estar consumiendo recursos del sistema: el navegador web, el procesador de textos y quizás hasta su preciado antivirus. Ahora ya puede dejar que su ordenador haga todo el trabajo y sentarse en el sofá a la espera de resultados, al fin y al cabo su procesador se encuentra ocupado únicamente con el algoritmo de bruteforce, ¿verdad?
La cruda realidad no muestra una cara tan bonita, por desgracia. Puede regresar a su equipo y abrir el monitor de procesos/administrador de tareas, tranquilamente otros 20 procesos podrían estar ejecutándose además del suyo, y algunos de ellos ni siquiera pueden “matarse” sin cargarse el sistema. Pero esto no es más que la punta del iceberg, su SO está gestionando por detrás múltiples hilos de kernel, interrupciones, mecanismos de entrada/salida (I/O), y si todavía no se ha desconectado de Internet, atendiendo a todos los paquetes que entran y salen por la interfaz de red.
Y hay más, muchísimo más, su querido sistema multitarea realiza controles de colas, intercambio de stacks entre procesos, IPC, y está haciendo verdaderas virguerías con la paginación y gestión de memoria virtual ayudado por el hardware subyacente. Digamos que cada 100ms una interrupción se genera en el procesador (ticks de reloj) y el núcleo del sistema retoma el control e invoca el scheduler para comprobar cuál es el próximo proceso que merece su tiempo (slice). Desde luego, esto es lo que hace un sistema operativo moderno, y otra infinidad de tareas que de forma intencionada nos dejamos en el tintero, pero usted solo quería crackear una contraseña, todo lo demás es “tiempo perdido”.
Bajo esta premisa decidí realizar la siguiente demostración. Cree un pequeño programa que aplicara la conjectura de Collatz para los primeros cincuenta millones de números. Al igual que un algoritmo de bruteforce, esto proporciona alimento suficiente para el procesador. El cálculo es sencillo, se selecciona un número, si es par se divide entre 2 y si es impar se multiplica por 3 y se suma 1, y se vuelve a aplicar el mismo proceso sobre el resultado. La conjetura dice que para todos los números naturales la secuencia siempre termina en 1. Observe el siguiente programa:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
void print_time(void)
{char buff[32];}
time_t now;
memset(buff, 0, 32);
now = time(0);
strftime (buff, 32, "%H:%M:%S", localtime(&now));
printf("%s\n", buff);
int main(int argc, char *argv[])
{unsigned int i, n;}
print_time();
for ( i = 1; i < 50000000; i++ ) {n = i;}
while ( n != 1 ) {
if ( n % 2 == 0 )n = n / 2;elsen = n * 3 + 1;}
print_time();
return 0;
Luego lo ejecutamos en una distribución Ubuntu 12.04 (3.5.0-40) sobre un procesador Intel(R) Core(tm)2 Duo T8300 2.40 GHz con 3GB de memoria RAM. La imagen muestra el resultado.
 | |
| Figura 1: Tiempo de ejecucion del programa de ejemplo |
El cálculo se ha prolongado por 50 segundos del reloj. Y ahora viene la pregunta clave, ¿qué ocurriría si pudiésemos hace que el procesador dedicase todo su tiempo a nuestro algoritmo? La solución pasaba por crear un bootloader en el primer sector de un disquete o USB que simplemente crease una GDT básica para pasar del modo real al modo protegido (facilitando así la posibilidad de ejecutar código C) y luego aplicar el mismo algoritmo.
No tenemos la intención de mostrar aquí el código completo, solo lo suficiente para que comprenda la explicación. He aquí la primera parte del proceso de boot en ensamblador. En lo que nos concierne, no hace falta que lo comprenda, digamos que simplemente pasa al modo protegido y luego llama a una función bootmain().
.code16Y ahora la función bootmain() en C que finalmente ejecuta la Conjetura de Collatz e imprime el rango de tiempo:
.globl start
start:cliclear_scr:
xorw %ax,%ax
movw %ax,%ds
movw %ax,%es
movw %ax,%ssmovb $0x06,%ahseta20.1:
movb $0x07,%bh
xorw %cx,%cx
movb $24,%dh
movb $79,%dl
int $0x10inb $0x64,%al # Wait for not busyseta20.2:
testb $0x2,%al
jnz seta20.1
movb $0xd1,%al # 0xd1 -> port 0x64
outb %al,$0x64inb $0x64,%al # Wait for not busy.code32
testb $0x2,%al
jnz seta20.2
movb $0xdf,%al # 0xdf -> port 0x60
outb %al,$0x60
lgdt gdtdesc
movl %cr0, %eax
orl $CR0_PE, %eax
movl %eax, %cr0
ljmp $(SEG_KCODE<<3), $start32
start32:movw $(SEG_KDATA<<3), %ax # Our data segment selectorspin:
movw %ax, %ds # -> DS: Data Segment
movw %ax, %es # -> ES: Extra Segment
movw %ax, %ss # -> SS: Stack Segment
movw $0, %ax # Zero segments not ready for use
movw %ax, %fs # -> FS
movw %ax, %gs # -> GS
movl $start, %esp
call bootmainjmp spin.p2align 2
gdt:SEG_NULLASM # null seggdtdesc:
SEG_ASM(STA_X|STA_R, 0x0, 0xffffffff) # code seg
SEG_ASM(STA_W, 0x0, 0xffffffff) # data seg.word (gdtdesc - gdt - 1) # sizeof(gdt) - 1
.long gdt # address gdt
#include "types.h"En el centro de este código observamos el mismo bucle for() que en el programa original que ejecutamos en Linux, todo lo demás son las virguerías que hay que hacer para interactuar con los puertos y obtener la hora de la máquina. Recuerde que lo que estamos haciendo en realidad es programar un “mini sistema operativo” que únicamente ejecuta nuestro algoritmo y luego entra en un bucle infinito. Una vez que compilamos todo el tinglado y lo insertamos en un disquete (obviamos este proceso en el artículo), accedemos a la BIOS para indicarle que arranque desde el floppy. En la imágen el resultado:
static ushort *crt = (ushort*)0xb8000; // CGA memory
void
bootmain(void)
{unsigned int n, i;}
unsigned short segundos = 0x00, minutos = 0x00, horas = 0x00;
asm volatile ("xorb %%al,%%al;"
"out %%al, $0x70;"
"in $0x71, %%al": "=a"(segundos));
asm volatile ("movb $0x02,%%al;"
"out %%al, $0x70;"
"in $0x71, %%al": "=a"(minutos));
asm volatile ("movb $0x04,%%al;"
"out %%al, $0x70;"
"in $0x71, %%al": "=a"(horas));
crt[160] = ((horas >> 4) + '0') | 0x0a00;
crt[161] = ((horas & 0x0f) + '0') | 0x0a00;
crt[162] = ':' | 0x0a00;
crt[163] = ((minutos >> 4) + '0') | 0x0a00;
crt[164] = ((minutos & 0x0f) + '0') | 0x0a00;
crt[165] = ':' | 0x0a00;
crt[166] = ((segundos >> 4) + '0') | 0x0a00;
crt[167] = ((segundos & 0x0f) + '0') | 0x0a00;
for ( i = 1; i < 50000000; i++ ) {n = i;}
while ( n != 1 ) {if ( n % 2 == 0 )}
n = n / 2;
else
n = n * 3 + 1;
asm volatile ("xorb %%al,%%al;"
"out %%al, $0x70;"
"in $0x71, %%al": "=a"(segundos));
asm volatile ("movb $0x02,%%al;"
"out %%al, $0x70;"
"in $0x71, %%al": "=a"(minutos));
asm volatile ("movb $0x04,%%al;"
"out %%al, $0x70;"
"in $0x71, %%al": "=a"(horas));
crt[240] = ((horas >> 4) + '0') | 0x0a00;
crt[241] = ((horas & 0x0f) + '0') | 0x0a00;
crt[242] = ':' | 0x0a00;
crt[243] = ((minutos >> 4) + '0') | 0x0a00;
crt[244] = ((minutos & 0x0f) + '0') | 0x0a00;
crt[245] = ':' | 0x0a00;
crt[246] = ((segundos >> 4) + '0') | 0x0a00;
crt[247] = ((segundos & 0x0f) + '0') | 0x0a00;
return;
 |
| Figura 2: Resultado obtenido prescindiendo del sistema operativo |
El proceso ha durado tan solo 30 segundos frente a los 50 invertidos por el sistema operativo. Sorprendentemente hemos realizado la misma tarea en un 60% del tiempo inicial, lo cual quiere decir, de forma aproximada, que un ataque de bruteforce que se prolongase por 24 horas, podría realizarse en unas 14 horas “si prescindimos del sistema operativo”.
Otra prueba sobre Windows XP con un procesador AMD Athlon(tm) 64 3000+ 1.81GHz y 512 MB de RAM, proporcionó un resultado de 46 segundos frente a los 68 que tardaba la aplicación en la shell del sistema operativo.
¿Qué es un sistema operativo? Pues esos 22 segundos “fantasmas” de diferencia que usted no sabía que podía ahorrarse.
Obviamente, esta demostración y el artículo que está leyendo no son más que una demostración curiosa. Usted necesita un sistema operativo para trabajar y créame que hoy en día estos invierten ese tiempo fantasma de una forma más económica y elegante que hace algunos años.
Las pruebas se han realizado sobre sistemas operativos de 32 bits, con un procesador x86_64 y un Windows 7 de 64 bits (por poner un ejemplo), seguramente habría que trabajar sobre long mode para poder realizar comparativas fiables...
Entienda que estamos programando la máquina desde cero, y no disponemos de ninguna de las facilidades que un sistema operativo le ofrece al programador, no existen librerías del sistema y todo debe hacerse a bajo nivel, pero no sería descabellado crear un sencillo framework con un bootloader básico que cargase un kernel mínimo en el que usted pueda insertar su algoritmo. Funciones de manejo de cadenas y otras de salida por pantalla pueden ser creadas de antemano sin mucho esfuerzo y proporcionadas por anticipado. No es más que una idea... interactuar directamente con la GPU de la tarjeta gráfica siempre parece más atractivo.
Toda esta teoría también podría aplicarse a un dispositivo Raspberry Pi si usted es capaz de crear un bootloader para ARM, prescindiendo así de la distribución Raspbian de Linux. Estos aparatos pueden realizar algunas tareas costosas si se combinan en un potente cluster, pero si usted no es un gurú o un ninja de la programación, será realmente complicado comunicar entre sí todos los dispositivos y realizar cualquier tipo de procesamiento paralelo.
Por lo demás… Happy Hacking!
by blackngel (blackngel@blackbycode.com)
No hay comentarios:
Publicar un comentario