Mostrando entradas con la etiqueta java. Mostrar todas las entradas
Mostrando entradas con la etiqueta java. Mostrar todas las entradas

martes, 5 de febrero de 2013

Utilidad para cifrar/descifrar RxBot


Hace un par de días, un amigo me pidió ayuda para descifrar una cadena de texto, con fines que desconozco. Generalmente no me suelo meter en temas de cifrado y seguridad de contraseñas, porque es algo que me aborrece enormemente y sobre lo que no estoy muy al corriente. En éste caso, tras una breve búsqueda en google, fui a parar a un foro en el que un fulano explicaba más o menos la teoría del asunto. Después traté de encontrar una herramienta al uso para solucionar el problema y lo que me encontré un montón de páginas y foros que las proporcionaban, pero requerían registro previo. 

Sin entrar en los intereses que puede tener un foro o página por mis datos personales, preferí no registrarme y como el algoritmo es de risa, traté de hacer un pequeño programa en Java. Un consejo, cuando tengáis que operar a nivel de bit, y realizar operaciones de transformación entre bytes, caracteres y cadenas, huid de este lenguaje.

Tras conseguir una versión cuasi-funcional en java que no me terminaba de convencer, me di por vencido y abrí DevC++. Fue una hermosa regresión al universo de los punteros y los arrays de caracteres que desembocó en las herramientas que más abajo comparto con vosotros.

El algoritmo

Me da mucha pereza explicar en profundidad el algoritmo. No obstante, y para que no penséis que me dediqué al copy-pasting resumo lo importante:

El algoritmo se basa en una tabla de 256 hexadecimales de 8 bits constante. Es (o debería ser) la misma para todas las cadenas cifradas con éste tipo de cifrado. 

Todo lo que hace el algoritmo es coger el primer carácter a cifrar, y hacer un XOR binario con el primer carácter de la tabla maestra, y así sucesivamente. Como todos sabremos, en el sistema de representación de caracteres ASCII a cada letra le corresponde un valor entre 0 y 255, si hablamos de numeración de 8 bits sin signo. A partir del XOR obtenemos ese byte, que representaremos como entero con signo.

De ésta manera, la cadena:
Wirelearn Rulz
Tras el cifrado queda representada como:
{115,69,-120,65,23,-121,-74,35,-13,44,44,-33,66,126,0}

Conclusiones

Lo bueno de utilizar un XOR es que es una operación reversible. Así, si dos personas tienen la misma tabla, la persona A puede escribir y cifrar un mensaje y enviarlo. Y la segunda persona puede descifrarlo de la misma manera. Así si el mensaje es interceptado, al menos llevará un buen rato reventarlo.

Como podréis imaginaros ESTE SISTEMA NO ES SEGURO ya que para empezar, la tabla es pública. Aún cambiando la tabla maestra por una aleatoria es bastante fácil de resolver con tiempo y una caña. Sin embargo, podría servir para que vuestras conversaciones privadas no fuesen escuchadas a primera vista en caso de que alguien esté escuchando la red.

Descarga

Sin ir más lejos, aquí tenéis el paquete descargable para windows

Un saludo.

sábado, 12 de enero de 2013

Un poco de estilo (JAVA)

Imagen tomada de www.xprogramming.com

Supongamos que tenemos una lista de números enteros, y queremos separarlos en dos grupos: Aquellos que cumplen una condición (C) y otros que no cumplen dicha condición (!C). Por ejemplo discriminar de entre todos los numeros de nuestra lista, aquellos que son pares. Lo más inmediato y rápido sin duda sería codificar "a fuego" un algoritmo que recorra la lista y compruebe para cada uno si la condición de la que hablamos se cumple. Éso está bien. Al fin y al cabo, funciona, lo hemos probado muchas veces.

if (numero % 2 == 0)
      imprime("El numero " + numero + " es par);
else
      imprime("El numero " + numero + " no es par);

Pero... ¿Qué pasaría si mañana nos vemos en la obligación de cambiar ese filtro? Imaginemos que mañana no nos interesan los pares sino todos los positivos. Efectivamente, nos vemos obligados a acceder a las tripas del algoritmo, y cambiar un par de cosas para adaptar nuestro código a los requerimientos externos. (Bastante sencillo en éste caso, pero podría no serlo).

Ya de mano, debería preocuparnos el hecho de deshacernos de ése código pero el verdadero problema no está ahí. El supuesto mortal es ¿Y si necesitara filtrar esos números en función de lo que esta pasando?¿Y si necesitara cambiar ese filtro en tiempo de ejecución? A éstas alturas, ya deberíamos saber que es de todo término inviable cambiar el código en tiempo de ejecución.

Además ¿Y si hubiera veinte posibles condiciones?¿Tendríamos veinte bloques IF anidados?¿O un switch enorme? Esa lógica condicional es veneno puro para el mantenimiento y para el rendimiento.

Es en éste punto concreto donde debería saltarnos una alarma dentro, que nos diga "Estoy borrando algo perfectamente funcional, pero hoy ya no me sirve por requerimientos externos". Estamos tirando horas de trabajo a la basura. Es aquí donde deberíamos pensar en la palabra "Delegación".

¿Qué es la delegación?

Delegar es dejar cierta "responsabilidad" en manos de "otro". No es inmediato darse cuenta de cómo encaja la delegación en nuestro proyecto pero ahora veremos una manera mucho mas potente de lidiar con ésta clase de temas.

¿Como encaja eso aquí?

Pongamos algún concepto más avanzado sobre la mesa. ¿Qué tienen en común todos nuestros cambios en el código? Pues que consisten en alterar la condición de filtrado. ¿Que tienen en común todas nuestras condiciones de filtrado? Que evalúan un entero, y que son de carácter booleano. ¿Podríamos decir entonces que una condición en general es algo que tiene un método booleano y un entero de entrada? Pues sí. A eso se le llama TIPO en términos de orientación a objetos, y una de las maneras más potentes de representarlo es mediante Herencia. Pero no cualquier tipo de herencia.

Crearemos una Interfaz llamada "Condicion", que tendra un método

public interface Condicion {
public boolean validar(int numero);
}

Así definimos nuestro tipo <>. Y delegamos en sus hijos la decisión de si un numero nos sirve o no¿Que pasa ahora? Una interfaz por si sola no tiene implementación alguna de cómo validar. Pero permite a nuestro código sustituir nuestra condición grabada a fuego:

for (Integer numero : numeros){
      if (numero % 2 == 0)
            imprime("El numero " + numero + " es par);
      else
            imprime("El numero " + numero + " no es par);
}

Por algo como ésto:

Condicion condicion = .........................;

for (Integer numero : numeros){
      if (condicion.validar(numero))
            imprime("El numero " + numero + " es par);
      else
            imprime("El numero " + numero + " no es par);
}


¿Que?¿No parece haber cambiado mucho no? Además ¿Donde especificamos nuestra condición? Esto es una M...

Demos el último paso. Para filtrar los números de la lista, crearemos dos implementaciones de nuestra condición abstracta que se llamarán por ejemplo "CondicionPositivo", y  "CondicionPar":

public class CondicionPositivo implements Condicion {}

y

public class CondicionPar implements Condicion {}


En seguida el compilador nos obligará a punta de pistola a implementar nuestro método "public boolean validar(int)" en nuestras recién creadas implementaciones. Ahí pondremos nuestras dos formas de filtrar.

Volviendo al código anterior, vemos unos puntos suspensivos que parecen "susceptibles de no compilar bien". Ahí es donde debemos crear una instancia de nuestra clase CondicionPositivo.

Condicion condicion = new CondicionPositivo();

Nuestro código ya funciona. Ahora, ¿qué tendríamos que hacer si mañana nos interesan los números pares en lugar de los positivos? Simplemente tendremos que cambiar la linea anterior a nuestro antojo. Así, el hecho de sustituir una por otra, no es destructiva, y con el tiempo vamos alimentando nuestros recursos de código. Es decir, nuestro árbol de Condiciones crece, y podría sernos útil más adelante.

Ésto esta muy bien, pero dónde está el verdadero potencial de lo que acabamos de construir? 

Sencillo. En nuestro nuevo código nada nos impide sustituir la condición en tiempo de ejecución. Es más, podríamos dejar que la condición dependiera de las acciones del usuario, y en función de qué tecla pulse, la condición varíe. Además, aún teniendo un alto número de condiciones, nuestro código permanecería impecable. Nada de lógica condicional.

Dicho todo ésto, 


¿Sabrías crear un filtro para múltiplos de un numero dado (p.ej: múltiplos de 3)?

Descargate el proyecto de eclipse aquí 

Un saludo!