Port-Knocking

Cuando nosotros tenemos un servicio en un servidor, éste, escucha en uno o varios puertos las peticiones externas. Este puerto deberá estar abierto en el firewall para que se puedan efectuar estas conexiones. La idea del Port Knocking es que el puerto del servicio permanece cerrado y sólo se abrirá bajo una petición externa basada en un paquete o grupo de paquetes específicos, previamente conocidos por el cliente, que serán enviados al servidor. Es decir, yo tendría mi servidor ssh con el puerto 22 cerrado y cuando un cliente envíe un paquete con ciertas características a otro puerto entonces el puerto 22 se abriría temporalmente para ese cliente. De este modo permanecería escondido antes escaneos de puertos e intentos automatizados de fuerza bruta, por ejemplo. Este sistema se podría ir mejorando:

• que tenga que ser una secuencia de puertos y no uno sólo
• que además tengan que ser unos puertos de origen específicos
• combinarlo con otras herramientas: Portsentry, denyhost, fail2ban (destaco la primera herramienta  ya que es una forma fácil de banear intentos de escaneos sin el uso de un IDS completo ni cortafuegos)
• jugar con las FLAGs TCP y opciones poco comunes de los paquetes
• abrir el puerto sólo para la IP llamante, no todas
• <paranoic>requerir una temporización determinada (algo elástica, claro está) entre en el envío de los paquetes</paranoic>
• y mil cosas que se nos puedan ocurrir

Para estos menesteres existen varias herramientas pero todo suelen terminar siendo scripts que escuchan los puertos y van cambiando reglas del cortafuegos y los servicios. Pero no todo es bonito e ideal, imaginad que no tienes una puerta trasera, ¿qué ocurre si cae el servicio encargado de escuchar el portknocking? Te quedas tú sin poder acceder. Deberías dejarte una IP blanca por ejemplo, que siempre tuviera acceso al puerto sin mayor barrera. O tener otro servicio que compruebe si el primer servicio está online y haga de watchdog xD.

Pero ¿cuál es la debilidad clave un sistema así? Replay Attack. Me explico, si mi máquina está en una subred y otra máquina de esa subred ha sido comprometida, ésta podría estar usando un sniffer (tcpdump, wireshark) y capturar la secuencia usada para la apertura de puertos. Y aquí es donde entra lo que he venido a contar.

Crypt-Port-Knocking

Vamos a cortar por lo sano esa debilidad: Single Packet Authentication. Esta manera de proceder difiere en que vamos a llamar a un puerto aleatorio cada vez y la conexión con el servicio también se hará en un puerto aleatorio cada vez pero lo que es más importante añadiremos información cifrada en el paquete gracias a OpenSSL con lo que se quiera hacer (en este caso usando 256-bit AES-cbc, se podría mejorar para ultraparanoicos™  usando un cifrado asimétrico con GPG, por ejemplo). Podríamos pensar que para evitar ataques replay en la información cifrada se podría incluir datos variantes en el tiempo, cambios preacordados de la clave de cifrado, usar iteraciones en una función de hashing pero se complica el tema cuando hay muchos usuarios. Para ello, es mejor opción aprovechar que podemos tener 16bytes de datos aleatorios en el paquete que luego podemos identificar gracias a un hash del mismo e ignorar todos los paquetes duplicados. Para crear los paquetes a medida podremos usar hping.

Para hacer uso de las características del Single Packet Authentication el autor del post, BoneKracker, ha creado una serie de scripts en bash, formados por un cliente y un servidor de una forma bastante clara y transparente. Echadle un vistazo que ahí está todo el código y con una explicación más extensa.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Para los amantes de XKCD llega…
• Cuestión de optimización
• Crackeador de hashes MD5 en C y OpenSSL

Para quien no lo conozca, las Arduino son una plataforma de desarrollo electrónico enfocada al prototipado rápido cuyas especificaciones son totalmente libres. Existen varios modelos de placas para los diseños con características más o menos avanzadas y podremos trabajar con ellas tanto en Windows, Mac OS X ó GNU/Linux, sin tener que usar compiladores y/o herramientas de desarrollo de pago.

La mía es una Arduino MEGA, que es una mejora de la Duemilanove y la Diecimila gracias a su mayor I/O y capacidad de memoria, entre otras cosas. Las specs principales son:

• Microcontrolador Atmel AVR 8-bit MEGA1280 @16MHz
• 128kB FLASH MEM (4kB usados por el bootloader incluído, usado para poder cargar cógido directamente)
• 8kB SRAM
• 4kB EEPROM
• 54 pines digitales (soportan hasta 40mA): I/O, comunicación serie, interrupciones, 8-bit PWM, SPI, I2C, …
• 16 pines de entrada analógica con una resolución de 10bits, útil para todo tipo de sensores.

Lo primero que tenemos que hacer para empezar a jugar es instalar las herramientas necesarias. En el árbol de paquete de Gentoo hay bastante para microcontroladores AVR ($ eix -S avr ) pero si además queremos afinar e ir a por el kit completo para Arduino tampoco tendremos problemas.

Necesitaremos una versión de Java (yo uso sun-jdk-1.6) además de los siguiente paquetes:

# emerge crossdev jikes uisp rxtx

Yo, de antes, ya tenía instalado avra (AVR Assembler) y avrdude (para subir y bajar código a las microcontroladoras) que había usado para trastear con las AVR Tiny2313, ATmega32 y ATmega64 aunque en realidad casi siempre usé el IDE que te proporciona ATMEL de forma gratuita para Windows y alguna vez Bascom-AVR.

Una vez tengamos los paquetes básicos instalados necesitamos generar el toolchain con el que vamos a trabajar para generar código compatible con la arquitectura AVR. Para ello nos ayudaremos de la herramienta crossdev:

# crossdev -t avr -s4 --without-headers

Tardará un ratillo pero una vez termine ya dispondremos de nuestro flamante compilador avr-gcc. Ahora nos bajamos el IDE que nos proporciona Arduino en http://www.arduino.cc/en/Main/Software, lo descomprimimos y lo dejamos por ahora ahí. Dependiendo de versiones puede que algunos tengan que hacer un enlace (por supuesto respetando paths y versiones de tu sistema):

$ ln -s /usr/lib/binutils/avr/2.19.1/ldscripts/ ~/programs/arduino-0017/ldscripts

Dependiendo de distribuciones o la configuración será necesario estar en los grupos tty y uucp, pero para ahorrarte problemas añade el usuario a esos grupos.

Mmmm ¿qué mas necesitamos? Arduino se conecta por USB a nuestro ordenador y el kernel de linux nos proporciona el driver, yo ya lo tenía instalado pero si no:

Device Drivers -> USB support -> USB Serial Converter support -> USB FTDI Single Port Serial Driver (EXPERIMENTAL)

Lo ponemos como módulo, compilamos y lo cargamos:

# make && make modules_install
# modprobe ftdi_sio

Conectamos la Arduino y podremos ver si todo funciona:

# dmesg
usb 4-2: new full speed USB device using uhci_hcd and address 5
usb 4-2: configuration #1 chosen from 1 choice
ftdi_sio 4-2:1.0: FTDI USB Serial Device converter detected
usb 4-2: Detected FT232RL
usb 4-2: FTDI USB Serial Device converter now attached to ttyUSB0

OK!

Volvemos al IDE que ya tenemos descomprimido y lo ejectuamos

$ ./arduino
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Ahora sólo nos faltará elegir en la configuración que queremos el /dev/ttyUSB0 y que estamos usando una placa Arduino MEGA, et voilà!

Para probar el funcionamiento haremos un “Hello Word” al estilo electrónica, es decir, hacer parpadear un LED

Hay ejemplos por ahí pero el código sería:

const int ledPin =  13;    // LED connected to digital pin 13
 
void setup()
{
	pinMode(ledPin, OUTPUT); // set pin 13 as output
}
 
void loop()
{
	digitalWrite(ledPin, HIGH);   // set the LED on
	delay(1000);                  // wait for a second
	digitalWrite(ledPin, LOW);    // set the LED off
	delay(1000);                  // wait for a second
}

A ver si busco ratos y hago algo interesante con mi nuevo juguete, ya no hay excusa. Si quieres saber por donde empezar acude a http://arduino.cc

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] La implemetación del driver
• [HOW TO] Cómo recuperar GRUB
• [Fprint] Mejoras en el driver y algunos extras

Primero de todo vamos a hacer un programa que nos permita calcular el hash md5 de un string que se le pase y luego ya pasaremos al crackeador.

Sería más fácil hacer un script en bash o perl gracias a la utilidad CLI de OpenSSL, a la hora de calcular un solo hash no importa mucho la velocidad pero si luego queremos hacer un pequeño crackeador no podemos partir de algo que ya sabemos que va a ser mucho más lento. Así que lo que vamos a usar es C y la librería de OpenSSL.

Si no sabemos por donde empezar un extracto del man:

$ man md5
...
SYNOPSIS
 
#include <openssl/md2.h>
 
        unsigned char *MD5(const unsigned char *d, unsigned long n,
                         unsigned char *md);
 
        int MD5_Init(MD5_CTX *c);
        int MD5_Update(MD5_CTX *c, const void *data,
                         unsigned long len);
        int MD5_Final(unsigned char *md, MD5_CTX *c);
...
DESCRIPTION
...
Applications should use the higher level functions EVP_DigestInit(3) etc. instead of calling the hash functions directly.
...

Vemos que podríamos añadir esa librería y usar las funciones MD5_Init(), MD5_Update y MD5_Final pero ya nos avisan que deberíamos usar unas funciones de más alto nivel así que: EVP_DigestInit

$ man EVP_DigestInit
...
SYNOPSIS
        #include <openssl/evp.h>
 
        void EVP_MD_CTX_init(EVP_MD_CTX *ctx);
        EVP_MD_CTX *EVP_MD_CTX_create(void);
 
        int EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl);
        int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *d, size_t cnt);
        int EVP_DigestFinal_ex(EVP_MD_CTX *ctx, unsigned char *md,
               unsigned int *s);

De paso, aprovecho para desaconsejar el uso de MD5 a día de hoy y como mínimo usar SHA1 o incluso dejarte de monsergas y pasar a SHA256, SHA512.

He intentado que el programa sea bastante fácil de entender y seguir, ahí va:

#include <stdio.h>
#include <string.h>
 
#include <openssl/evp.h>
 
#ifdef DEBUG
#define DBG 1
#else
#define DBG 0
#endif
 
#define MAX_SIZE_WORD 200
 
unsigned char *simple_digest(char *algth, char *buffer, unsigned int len, int *olen){
 
	EVP_MD *m;
	EVP_MD_CTX ctx;
	unsigned char *ret;
 
	OpenSSL_add_all_digests ();
	if (!(m = (EVP_MD*) EVP_get_digestbyname(algth)))
		return NULL;
 
	if (!(ret = (unsigned char *) malloc(EVP_MAX_MD_SIZE)))
		return NULL;
 
	EVP_DigestInit(&ctx, m);
	EVP_DigestUpdate(&ctx, buffer, len);
	EVP_DigestFinal(&ctx, ret, olen);
 
	return ret;
}
 
void hex_print(unsigned char *buff,int len){
	int i;
	for(i=0;i<len;i++)
		printf("%02x",(unsigned char)(buff[i]&0xFF));	
}
 
int main(int argc, char **argv){
 
	unsigned char buff[MAX_SIZE_WORD];
	int olen;
	char *out;
 
	if(!argv[1]) {
	        printf("Usage: mymd5 word\n");
        	exit(1);
	}
 
	// copy arg string into a buffer
	if (strlen(argv[1]) < MAX_SIZE_WORD ){
 
		strncpy(buff, argv[1], strlen(argv[1]));
 
		// calculate string's md5 hash
		out = simple_digest("md5",buff,strlen(argv[1]),&olen);
 
		// print results	
		if (DBG){
			printf("Word: %s\n",argv[1]);
			printf("Hash: ");
		}
		hex_print(out,olen);
		printf("\n");
 
		return 0;
	}
 
	printf("\nNot computing hash\n");
	printf("\nI can feel your dark side... ;)\n");
 
	return -1;
}

Compilamos y probamos:

$ gcc mymd5.c -o mymd5 -l ssl
$ ./mymd5 passworddeelite
5b4f50aa173b977e4cd0850cf7c52bd0

Podemos comprobar su correcto funcionamiento comparando con webs online que ofrecen utilidades para calcular hashes MD5 [1], [2].

Y ahora a por el crackeador. No vamos a intentar buscar colisiones sino a partir de un diccionario sacar la clave. Le pasaremos como parámetros un fichero con el hash y un diccionario con una palabra por línea.

#include <stdio.h>
#include <string.h>
 
#include <openssl/evp.h>
 
#ifdef DEBUG
#define DBG 1
#else
#define DBG 0
#endif
 
#define MAX_SIZE_BUFF 200
 
unsigned char *simple_digest(char *algth, char *buffer, unsigned int len, int *olen){
 
	EVP_MD *m;
	EVP_MD_CTX ctx;
	unsigned char *ret;
 
	OpenSSL_add_all_digests ();
	if (!(m = (EVP_MD*) EVP_get_digestbyname(algth)))
		return NULL;
 
	if (!(ret = (unsigned char *) malloc(EVP_MAX_MD_SIZE)))
		return NULL;
 
	EVP_DigestInit(&ctx, m);
	EVP_DigestUpdate(&ctx, buffer, len);
	EVP_DigestFinal(&ctx, ret, olen);
 
	return ret;
}
 
void hex_print(unsigned char *buff,int len){
	int i;
	for(i=0;i<len;i++)
		printf("%02x",(unsigned char)(buff[i]&0xFF));	
}
 
void strtohex(unsigned char *in, unsigned char *out,int len){
	int i;
	char tmp[3];
	tmp[2]=0;
	for(i=0;i<len/2;i++){
		tmp[0]=in[2*i];
		tmp[1]=in[2*i+1];
		out[i]=strtol(tmp,NULL,16);
	}
}
 
int main(int argc, char **argv){
 
	int tries=0;
	unsigned char buff_words[MAX_SIZE_BUFF];
	unsigned char hash[16];
	unsigned char *line=NULL;
	int len=100,read;
	int olen;
	char *out;
 
	if(argc<3) {
	        printf("Usage: mymd5crack /path/to/hashfile /path/to/dictfile\n");
        	exit(1);
	}
 
	FILE *hashfile;
	hashfile = fopen(argv[1],"r");
	if(!hashfile){
		perror(argv[1]);
	return -1;
	}
 
 
	FILE *dictfile;
	dictfile = fopen(argv[2],"r");
	if(!dictfile){
		perror(argv[2]);
	return -1;
	}
 
	read = getline(&line, &len, hashfile);
	if(strlen(line)!=33){
		fprintf(stderr,"ERROR: Invalid hash length %d\n",strlen(line));
		return -1;
	}	
 
	strtohex(line,hash,32);
 
	if(DBG){
			printf("Input hash: %s\n", line);
			printf("Input buffer from hash: ");
			hex_print(hash,16);
			printf("\n\n");
	}
 
	//Read words in a loop
	while((read = getline(&line, &len, dictfile)) != -1){
		if( strlen(line) < 200){
			tries++;	
 
			//Copy word into buffer
			strcpy(buff_words,line);
 
			if(DBG)
				printf("Input buffer from dict: %s \n",buff_words);
			// compute md5
			out = simple_digest("md5",buff_words,strlen(line)-1,&olen);
 
			if(DBG){	
				printf("For password %s MD5 is: ",line);
				hex_print(out,olen);
				printf("\n\n");	
			}
 
			//Compare computed md5 with hash
			if(memcmp(out,hash,16) == 0){
 
				printf("PASSWORD FOUND!! in %d tries: %s\n",tries,line);
 
				fclose(hashfile);
				fclose(dictfile);
				free(out);
				if(line)
					free(line);
 
				return 0;	
			}
			free(out);
		}else{
			printf("\nWords from dict too long... cough*, cough*...\n");
		}
	}
 
	printf("Password not found in %d tries!\n",tries);
 
	if(line)
		free(line);
 
	fclose(hashfile);
	fclose(dictfile);
 
	return 0;
}

Y comprobamos su funcionamiento metiendo en /tmp/hash el hash obtenido anteriormente:

$ gcc mymd5cracker.c -o mymd5cracker -l ssl
$ ./mymd5cracker /tmp/hash /tmp/dict
PASSWORD FOUND!! in 6 tries: passworddeelite

Premio! Podéis ir en paz.

Para descargar mymd5.c y mymd5cracker.c

Gracias a TuXeD que siempre está ahí para echar una mano.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Descifrando un reto del FBI
• Soluciones del reto de criptografía – Parte 2
• Port-Knocking y Crypt-Port-Knocking

A día de hoy contamos con ordenadores chorrecientas veces más rápidos que hace pocos años y cuando se programa haces pruebas con sistemas de 3GHz, varios MB de cache y 2GB de RAM mínimo y todo tira para adelante. Bueno, todo tira hasta cierto punto, tus programas luego se van a estar ejecutando juntos con otras decenas de programas o simplemente se van a estar ejecutando constantemente y vas a perder un gran porcentaje de la capacidad de proceso de cómo lo podrías estar haciendo.

Bueno, y es normal, cosas de la comodidad, yo el primero. Ahora te quedas tranquilo con que funcione, en los 80 tenía que funcionar y caber en 64kB de RAM. No digo que se programe peor (seguramente sí xD) pero ya no nos fijamos en muchos detalles que antes eran totalmente necesarios (la de trucos que usaba la gente para poder aprovechar el 100% del hardware del Commodore64) y ahora desperdiciamos por todos lados y al final sí que pasa factura. La gente que programe sistemas embebidos lo tiene muy claro aunque casi se va a acabar el asunto también ahí porque ya los procesadores de los móviles/PDAs/cosas_pequeñas tirán mucho.

Me he encontrado con programas que están al 100% de CPU en idle, con programas que daban su salida en unos 12~15 minutos cuando otro para el mismo propósito lo hacía en aproximadamente 1 segundo (no daré nombres xD), programas en los que notas el ‘refresco’ de los elementos cuando lo usas cuando te sobra CPU para hacerlo bien, etc. Hay que intentar evitar marañas de bucles for anidados!

Al final todo pasa por conocer muy bien el lenguaje que usas, haber pasado horas y horas, pensar las cosas antes de hacerlas, incluso un poquito de sentido común, cosa que creo que es difícil de abstraer a veces cuando se programa.

Por ejemplo, en matlab es muy importante reservar el espacio para las variables antes y crear los vectores del tamaño que van a ser al final de las operaciones porque si aumentamos el tamaño de un vector[n], internamente lo que siempre hace es crear un nuevo vector[n+1] y copiar los datos del antiguo.

Hace unos meses me comentó un amigo que en el trabajo tenían un método númerico que disminuyó su tiempo de ejecución en más de un 20% (siendo su tiempo varias horas) al sustituir un resultado de una operación que siempre era el mismo por el valor guardado en una variable! Es de cajón pero hay que caer.

Y ahora vienen algunos ejemplos, por no meterme en un lenguaje tipo C en el que hay muchas posibilidades de hacer las cosas y hay que currarse más los ejemplo iré a algo más sencillo como es hacer scripts cerdos para administrar un máquinas o similares.

Un ejemplo sería un uso poco adecuado de las órdenes cat, grep, ls, awk y similares. Cuando manipulamos algo pequeño no pasa nada pero cuando se trata de varios ficheros logs y son decenas de MB pues la cosa empieza a tomar importancia.

Respecto a grep cuando una persona empieza y se plantea buscar una cadena lo primero que piensa es ‘muestro el archivo y luego saco las líneas coincidentes’:

# cat tinyproxy.log | grep remote
real    0m55.071s
user    0m24.477s
sys     0m0.727s

Luego descubres que en realidad lo puedes hacer ‘todo en uno’ y es bastantes más rápido:

# grep remote tinyproxy.log
real    0m36.024s
user    0m22.550s
sys     0m0.527s

Luego, sin querer, entras en el man y te das cuenta de que existen varios tipos: grep, egrep (similar pero no idéntico a grep -E ) y  fgrep (idéntico a grep -F). Así que pruebas:

# egrep remote tinyproxy.log
real    0m55.122s
user    0m25.029s
sys     0m0.659s

Joder, vuelve a ser lento a pesar de no hacer un cat. ¿Por qué? Porque es una función más compleja.

• grep: soporta expresiones regulares básicas.
• fgrep: no soporta expresiones regulares => el más rápido.
• egrep: soporta expresiones regulares avanzadas => el más lento.

Para los curiosos, el nombre grep viene de g/re/p y significa lo que hace tal cual, buscar una expresión regular y hacer print de las coincidencias. En realidad a una escala grande ni siquiera deberíamos usar grep sino sed que es más rápido.

Lo mucha gente desconoce es que hay otra manera de evitar el cat de antes y ganar tiempo, y es que en realidad las concatenaciones siempre están ahí… así que lo podríamos hacer del siguiente modo:

# <tinyproxy.log grep remote
real    0m43.931s
user    0m22.338s
sys     0m0.578s

Del mismo modo estos conceptos se puede usar en otras órdenes

# cat tinyproxy.log | wc -l
104265

real    0m0.088s
user    0m0.021s
sys     0m0.053s

# wc -l tinyproxy.log
104265 tinyproxy.log

real    0m0.021s
user    0m0.013s
sys     0m0.006s

Y del mismo modo:

# cat tinyproxy.log | tail -n 200
real    0m0.121s
user    0m0.026s
sys     0m0.056s

# tail -n 200 tinyproxy.log
real    0m0.010s
user    0m0.000s
sys     0m0.003s

Cambiando de tercio también solemos usar echo más veces de las que toca. Por ejemplo si tenemos :

var="valor_o_resultado_de_una_evaluacion"
command -options `echo $var`

en la mayoría de los casos podremos sustituirlo por:

var="valor_o_resultado_de_una_evaluacion"
command -options $var

Y así mil chorradas. Por cierto, el que sólo se conozca la opción de awk para coger columnas le recomiendo que se mire manules que termina siendo muy útil.

Creo que este post lleva más de 6 meses en drafts y no he añadido nada (de hecho tampoco tengo ganas), así que aunque es un tema que da mucho de sí ha quedado bastante descafeinado técnicamente, pero ajo y agua!

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Descodificar tonos DTMF usando Matlab
• Port-Knocking y Crypt-Port-Knocking
• Para los amantes de XKCD llega…

Muchas gracias a todos los que acudísteis a pesar de ser el último día y ser por la mañana, que el sueño hace mella…

PDF:Sistemas de Detección de Intrusos CP2k9

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Campus Party 09] Planning
• [Campus Party 09] Las crónicas
• [Campus Party 08] Diario de a bordo – Parte 2

¿Qué son las CFLAGS/CXXFLAGS?

Son unas variables de entorno o unas variables en un Makefile que se le pasan al compilador para que compile el software aplicando un serie de optimizaciones. Herramientas como autoconf las cogerían del entorno para añadirlas a la sentencia que se usa al compilar. Las CFLAGS se usarían en C, y las CXXFLAGS en C++.

Según usemos un set distinto de CFLAGS los binarios de salida que nos dé el compilador podrán ser distintos partiendo de un mismo código fuente. Gracias a ellas podremos adecuar o intentar mejorar características de los binarios, ya sea para que sean más pequeños, más rápidos en ciertas arquitecturas u otras opciones. Para ello se podrán usar instrucciones específicas disponibles un procesador, podremos especificar por ejemplo que se “desenrrollen” bucles, etc.

Un ejemplo del primer caso sería usar instrucciones SSE3 disponibles en procesadores actuales pero no disponibles en un Pentium IV de primera generación. Para ello le pasaremos -msse3

Un ejemplo del segundo caso sería, yo tengo un bucle que se ejecuta 1000 veces. Cogeríamos y, en ensamblador, tenemos un registro que se va decrementando, comprueba si lo ha hecho 1000 veces y si no, hace un salto para ejecutar el bucle de nuevo. Pues vamos a cambiar eso por “pegar” consecutivamente el código de dentro del bucle 1000 veces. Con eso nos ahorramos recodificaciones de punteros y cosas similares pero tendremos como inconvenientes que el binario será más grande. ¿Qué se ejecuta más rápido? ¿El código optimizado por no hacer esas recodificaciones o el código inicial porque se tarda menos en cargarlo al ser más pequeño? Eterna pregunta… pues depende, a veces uno, a veces el otro.

Por comodidad, para que no tener que pasarle 8 lineas de optimizaciones, de las cuales más de una no sabremos lo que hace y que algunas implican o excluyen otras, existen sets de optimizaciones: -O, -O1, -O2, -O3, -Os, etc. Eso es la letro “o” mayúscula seguida de un número, más allá del 3 no existe, se usaría -O3.

Por otro lado, a las arquitecturas existentes se les pone un nombre, para que cuando digamos qué arquitectura tiene nuestra máquina el compilador le aplique automáticamente lo que toca: -march=athlon64, -march=pentium2, -march=pentium4, -march=prescott, -march=core2, … Esta opción dependerá mucho de la versión de GCC que tengamos instalada, ya que dependiendo de lo nueva que sea tendrá soporte para nuevas arquitecturas o no, e incluso para una misma arquitectura dependiendo de si instalas un sistema de 32 o 64bits el nombre cambiará. Además está opción está íntimamente ligada con la variable CHOST que será del estilo: i586-pc-linux-gnu, i686-pc-linux-gnu, x86_64-pc-linux-gnu, etc.

La mayoría de las distribuciones que se usan son precompiladas, Debian/Ubuntu, RedHat, Mandriva, … y esto no es algo de lo que preocuparse pero esto cobra especialmente sentido en distros como Gentoo y LFS donde todo el código es compilado desde cero con las optimizaciones y opciones que se quieran, ajustadas al tipo de máquina que va a ejecutar el código.

Pero ya se sabe, la gente funciona del modo “a ver quien la tiene más larga”. Cuando Gentoo empezó a ganar terreno y adeptos con la versión 1.4  y la 2004 la gente se cascaba unas pedazos de CFLAGS que no tenían ni pies ni cabeza, ¡cuantas más le pase más guay!, ¡más rápido irá! ¡más todo! Estilo pajillero, el foro estaba lleno de hilos de discusión sobre las CFLAGS y que no sé quien se había puesto tales y podía viajar atrás en el tiempo con ellas. En realidad lo único que se consigue es tener como salida un código inestable, que puede funcionar mal y más lento. Por ejemplo, la opción -ffast-math además de no cumplir con el estándar hace que las raices negativas no existan en lugar de devolver números complejos. ¿y si compilamos octave/algo_tipo_matlab con -ffast-math? => fiesta del confeti.

Generalmente se recomienda usar -O2 -pipe -fomit-frame-pointer y poco más. La opción -O3 se considera un poco insegura que ya de uvas a peras puede dar problemas. La opción -pipe en realidad no cambia el código de salida, sólo provoca que el compilador use tuberías entre las distintas etapas de una compilación en lugar de usar ficheros temporales, esto aumenta la velocidad de compilación pero puede provocar que en algunos sistemas donde el código ensamblador no pueda recibir de una tubería falle, algo poco común en realidad. La opción -fomit-frame-pointer reduce el tamaño del código bastante pero provoca que la depuración de código sea infinitamente más complicada, además, para gran parte de las arquitecturas, viene activada en el set -O2 así que no necesitaríamos ni ponerla xD

Por poner algunos ejemplos en las máquinas que tengo a mano uso:

AMD Ahtlon 3200+ (2GHz)
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=athlon64 -pipe -fomit-frame-pointer -msse3"

Intel Core Duo T2500 (2GHz)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -msse3"

Intel Pentium4 (3.2GHz)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -msse3"

Intel Pentium4 Celeron (2GHz)
CHOST="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -pipe -fomit-frame-pointer"


Vamos, más simple y pobre imposible jejeje. Y ahora viene el tema, resulta que en el Athlon 3200+ de 64bits tenía -O3… yo ni me acordaba.

Quien no tenga ni amigos ni cosas que hacer que acuda al man gcc y se las estudie todas.

El problema con libgcrypt

Para la prueba 12, creé en mi portátil una par de pares de claves GPG para cifrar con clave asimétrica un mensaje, el objetivo de la prueba era recuperar la clave privada y la passphrase y a continuación descifrarlo. Al principio pensé hacerla más larga y que luego no estuviese enviado por quien decía ser y hubiera que encontrar más cosas pero bueno, lo deje en el primer stage, así que la clave pública del emisor ya no era ni necesaria.

Una vez creadas las clave y cifrado el mensaje procedí a probar que funcionaba…claro. Así que exporté las claves y las importé en el sobremesa (el Athlon). Procedo a descifrar y:
...
AES-128 test encryption failed.
...

Premio, ¿qué habré hecho mal? Venga a probar a importar de nuevo, crear de nuevo las claves, … Resulta que tenía versiones distintas de GnuPG en cada máquina, ¿afectará? O_o, no debería en absoluto pero bueno, compilo la misma versión, sigue fallando, creo otra vez la claves, me empiezo a desesperar, busco por internet, no encuentro nada, me bajo el código fuente donde sale esa cadena para ser mostrada, me lo empiezo a mirar para ver cuando y por qué sale. No veo nada raro, cambio a otra versión de libgcrypt, recompilo, más de lo mismo, sólo puede ser una cosa, que el algoritmo de AES no esté haciendo lo que toca, pero ¡el mismo código funciona en otra máquina!

Ya desesperadísimo a falta de 20 minutos para que demos comienzo el reto, la prueba 12 no funciona xD, genial. Asumiendo que el código es correcto sin bugs me meto en el make.conf y veo “-O3“, uhm, no me jodas, lo cambio por “-O2” y recompilo libgcrypt, que es el paquete que contiene la función con dicho código tocapelotas, y recompilo GnuPG, pruebo a descifrar, a la primera ¬¬

De normal cuando un paquete es propenso a funcionar mal por estas razones en el proceso de compilación te avisan de que no uses alguna optimización, éste no era el caso aunque después de lo visto quizá deberían avisarlo. O cambiarlo por -O2 sin decir nada.

Así que ya sabéis, KISS (efe eeeeeeeeeeeeeeeeeeeeeeeeemeeeeeeee), Keep It Simple, Stupid!

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• The Machines
• Dejar bonito un server SSH – Parte 1
• Arduino MEGA y módulo XBee – Instalación en gentoo

El asunto es que NTFS almacena todo en streams (flujos), cada fichero tiene un stream sin nombre pero puede tener muchos con nombre. El tamaño del fichero será sin embargo el tamaño del stream sin nombre, el principal. Se podría resumir diciendo que ADS son ficheros dentro de ficheros.

Prácticamente ya todo el mundo usa NTFS-3G para acceder desde linux a sus particiones en este sistema de fichero pero por defecto NTFS-3G sólo lee y escribe los flujos de datos sin nombre.

Si queremos acceder a los flujos secundarios tendremos que montar el sistema de ficheros con la opción streams_interface=windows. De este modo podremos acceder a esos datos del modo:

cat file.dat:label1

y de este modo tratarlo como otro fichero más, pudiendo usar directamente el resto de utilidades GNU. Para listar todos los streams que contiene un fichero tendremos que comprobar el contenido del atributo ntfs.streams.list.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] La implemetación del driver
• [Fprint] Lectores de huellas en linux
• Dejar bonito un server SSH – Parte 1

Una pequeña recopilación de juguetes para escalar privilegios a root desde local. Aprovechan fallos distintos y de distintos tipos. Algunos no tienen por qué funcionar siempre, debido a su idiosincrasia y en realidad los posteo aquí para tenerlos más a mano y recopilados xD

2.6.29 ptrace_attach – shoryuken.c

2.6.x ptrace_attach – xploit_2.6.x.c

<2.6.29 exit_notify – xploit_till2.6.29_exit_notify.sh

2.6.23 ~ 2.6.24 vmsplice – xploit_2.6.23~24_vmsplice

2.6.17 ~ 2.6.24.1 vmsplice – xploit_2.6.17~24_vmsplice

2.6.13 ~ 2.6.17.4 prctl (made in Spain) – xploit_2.6.13~17_prctl.c

2.6.13 ~ 2.6.17.4 prctl & logrotate – raptor_prctl2.c

2.6.13 ~ 2.6.17.4 prctl – raptor_prctl.c

<2.6.17.4 proc – h00lyshit.c

Un poco más de prctl aquí, aquí y aquí, más de lo mismo.

<2.6.11 CPL 0 – k-rad3.c

¡Qué post más scriptkiddie! ¿no?

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• [Fprint] Los dispositivos
• HP Mobile Data Protection System 3D
• SD Card TI Reader en los portátiles HP bajo linux

Los videos venían de una cámara JVC que los grababa a 1920×1080 (lo que viene siendo FullHD). JVC usa un formato propio, el TOD, para codificar los vídeos (por lo menos en las cámaras de la serie Everio) y no todos los programas de edición lo importan/abren, así que el primer paso sería convertirlo a algo más común.

ffmpeg -i original_video.tod -acodec copy -vcodec copy video.avi

Como mi ordenador tiene bastante años y no necesitaba editarlo con calidad FullHD lo hice más pequeño pero sin perder calidad. Se podrían especificar todos los parámetros del audio/video:

• bitrate: -ab para el audio, -vb para el video, por defecto -b se refiere al video
• tamaño: -s widthxheight
• frames: -r num
• etc

para mí lo más cómodo fue usar la opción -sameq :

ffmpeg -i video.avi -s 1024×600 -sameq -acodec copy video_small.avi

Si quisiéramos tener un formato PAL podríamos especificar -s 720×576 -r 25 y un bitrate pero es más sencillo pasarle -tvstd pal

Convertir un wav a un mp3 sería tan sencillo como:

ffmpeg -i audio.wav -acodec mp3 -ab 192k audio.mp3

Ripear el audio de un video:

ffmpeg -i video.avi -vn -acodec mp3 audio.mp3

Si fuera un video cuyo audio ya estuviera en mp3 se podría haberle pasado -acodec copy directamente.

Si quisiéramos hacer una captura en video de lo que hacemos en el escritorio podríamos usar herramientas tipo xvidcap, recordmydesktop, etc pero esta es bien rápida y cómoda:

ffmpeg -f x11grab -s 1280×1024 -i :0.0 mydesktop.avi

La suite completa de ffmpeg ofrece:

• ffmpeg:  la herramienta CLI para convertir a diferentes formato ficheros multimedia.
• ffserve: un servidor de streaming para hacer broadcast.
• ffplay: un reproductor simple basado en SDL y las librerías de ffmpeg.
• libavcodec: la libería que contiene decodificadores y codificadores para los codecs de audio y video.
• libavformat: la librería que contiene multiplexores y demultiplexores para los formatos tipo contenedor de los ficheros multimedia.

He encontrado este estupendo tutorial de como crear un editor de video gracias a ffmpeg en menos de 1000 líneas de código.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

None Found

Os pongo una lista de conferencias que más me llaman del Fahrplan que hay:

- Solar-powering your Geek Gear: Alternative and mobile power for your all you little toys.

- FAIFA: A first open source PLC tool: PowerLineCommunication has now their open source tool.

- Security Failures in Smart Card Payment Systems: Tampering the Tamper-Proof. Esta para TuXeD

- Chip Reverse Engineering

- Cracking the MSP430 BSL

- Advanced memory forensics: The Cold Boot Attacks: Recovering keys and other secrets after power off.

- Locating Mobile Phones using SS7

- coreboot: Beyond The Final Frontier: Open source BIOS replacement with a radical approach to boot.

- Messing Around with Garage Doors: Breaking Remote Keyless Entry Systems with Power Analysis.

- Algorithmic Music in a Box: Doing music with microcontrollers.

- Anatomy of smartphone hardware: Dissecting contemporary cellphone hardware.

- Scalable Swarm Robotics: Formica: a cheap, open research platform.

- Console Hacking 2008: Wii Fail: Is implementation the enemy of design? Que gran pregunta.

- The Ultimate Commodore 64 Talk: Everything about the C64 in 64 Minutes. Brutal, enlace a su blog http://www.pagetable.com/?p=53

- Predictable RNG in the vulnerable Debian OpenSSL package: the What and the How. Aunque ya esté muy visto… para echarse unas risas.

Me ha llamado la atención lo que han denominado como Lightning Talks, rondas de 10 presentaciones de 4 minutos donde puedes exponer tu idea más descabellada, presentar tu proyecto, enseñar un cacho de hardware que te emocione, etc y así ganar adeptos para colaborar o simplemente echarte unas risas.

Y por supuesto, además de todo lo anterior, workshops sobre microcontroladores, el quadrocopter, etc.

En fin, otro año será, siempre me quedará youtube.com para ver las charlas.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Para los amantes de XKCD llega…
• [Fprint] La implemetación del driver
• SD Card TI Reader en los portátiles HP bajo linux