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:
#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;
else
n = 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().
.code16
.globl start
start:
cli
xorw %ax,%ax
movw %ax,%ds
movw %ax,%es
movw %ax,%ss
clear_scr:
movb $0x06,%ah
movb $0x07,%bh
xorw %cx,%cx
movb $24,%dh
movb $79,%dl
int $0x10
seta20.1:
inb $0x64,%al # Wait for not busy
testb $0x2,%al
jnz seta20.1
movb $0xd1,%al # 0xd1 -> port 0x64
outb %al,$0x64
seta20.2:
inb $0x64,%al # Wait for not busy
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
.code32
start32:
movw $(SEG_KDATA<<3), %ax # Our data segment selector
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 bootmain
spin:
jmp spin
.p2align 2
gdt:
SEG_NULLASM # null seg
SEG_ASM(STA_X|STA_R, 0x0, 0xffffffff) # code seg
SEG_ASM(STA_W, 0x0, 0xffffffff) # data seg
gdtdesc:
.word (gdtdesc - gdt - 1) # sizeof(gdt) - 1
.long gdt # address gdt
Y ahora la función
bootmain() en
C que finalmente ejecuta la
Conjetura de Collatz e imprime el rango de tiempo:
#include "types.h"
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;
}
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:
 |
| 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)
