Copy Link
Add to Bookmark
Report
SET 035 0x0A
-[ 0x0A ]--------------------------------------------------------------------
-[ John The Ripper "over MPI" ]----------------------------------------------
-[ by set-ezine ]----------------------------------------------------SET-35--
Hace apenas unos meses, en la revista @RROBA, hablamos de pasada sobre una
versión de"John The Ripper" distribuida bajo un "live CD" como tantas otras
versiones de linux. La característica de esta rama no oficial del famoso
cracker es su capacidad de utilizar la potencia total de una maquina multicore
o de poder distribuir de forma automática la tarea de crackear una hash por
fuerza bruta. Nos podríamos preguntar porque los creadores de JTR no han
soportado de forma activa esta rama de su criatura, razones puede que existan
muchas pero lo único cierto es que si queremos hacer algo especial tenemos que
andar sobre nuestras propias piernas. Hoy pretendemos contaros los problemas y
posibles soluciones cuando se pretenden hacer cosas distintas a lo que nos
tiene acostumbrada nuestra sociedad.
RESPUESTAS DE Solar Designer
En cualquier distribución de John The Ripper, existe en el directorio DOC un
archivo llamado FAQ, ahí el creador de JTR nos dice, aparentemente, con
claridad, porque no se soporta de forma activa una distribución de JTR hecha
para una maquina multiprocesor o para correr bajo un proceso distribuido. Según
sus propias palabras, simplemente no es necesario, ya que se puede fácilmente
planear la distribución de las tareas de forma manual. Una de las maneras es
lanzar john en diferentes sesiones atacando objetivos de longitud distinta.
Esto se puede hacer fácilmente con el modo "incremental" y jugando con la
configuración de los parámetros "MinLen" y "MaxLen". Aparentemente se pueden
lanzar varias sesiones de john y diferenciar el avance a través del parámetro
"--session"
No se a vosotros, pero a mi me ha dado dolor de cabeza solo imaginar la
complejidad de la operación. Mejor dicho, es fácilmente explotable, si lo
único que se desea es utilizar al máximo la potencia de una maquina multicore,
pero si lo que nos interesa es atacar una hash difícil, lanzar la tarea y
olvidarnos de la historia hasta que el objetivo haya sido alcanzado, no es
precisamente el consejo de Solar el que nos puede ayudar y estamos seguros que
nuestro amigo tiene la inteligencia suficiente para saberlo.
Es casi seguro que su problema reside en no verse involucrado en un ataque
masivo en donde se haya utilizado su criatura en forma distribuida, ya que este
tipo de cosas pueden acabar con una visita de la policía a tu casa, en el mejor
de los casos o al menos esta es nuestra opinión. Pero dado que no podemos
obtener respuestas fáciles y transparentes en ambientes públicos hay que
plantear las preguntas en otros entornos donde podamos obtener otras respuestas.
RESPUESTAS DE SET EZINE
Como no estamos dispuestos a confiar en la primera respuesta, ya que somos
escépticos profesionales, nos complace encontrar otras soluciones, lo que
ocurre es que se requiere algún incentivo para que decidamos movernos y
utilizar nuestras energías para conseguir un objetivo concreto, veamos como
empezó todo.
El caso es que en un anónimo despacho, dentro de un flamante edificio de vidrio
y cemento perteneciente a una de tantas corporaciones que velan por proveernos
de servicios o cosas, vitales o inútiles, sonó un teléfono con insistencia.
Nuestro viejo amigo Perico Viajero no tenia muchas prisas por responder, estaba
enfrascado en responder a un e-mail idiota sin que se notara demasiado su
opinión sobre el cretino que lo había escrito, cuando vió por el visor de donde
procedía la llamada y se decidió a contestar. "¿Si?", "Oye, tenemos tu nuevo
laptop", fue la rotunda respuesta. Era uno de los pocos dentro de la anónima
sociedad, que recibía, por motivos ignotos, un cierto trato personalizado del
departamento informático. "Vale, ya era hora. El que tengo empieza a tener
problemas de disco duro", contestó con soltura Viajero "Si no hicieras cosas
raras con tu maquina, estas serian mas longevas. En dos días lo tendrás listo".
La nueva maquina que recibió fue un "dual core" de esos de ultima generación.
Viajero se emocionó un poco al verlo, la posibilidad de utilizar la nueva
capacidad de calculo mientras haraganeaba en los vestíbulos de los aeropuertos
le despertó el apetito de volver a intentar nuevos ataques sobres hash que en
un pasado habían resistido a sus ataques. Lo primero que se le ocurrió fue
desenterrar una vieja hash de una maquina Win2000 que yacía en un despacho de
un país de habla germánica. La clave pertenecía a una clave LM, que como todo
el mundo debiera saber utiliza una clave de 14 byte, concatenada con ceros si
no tiene esta longitud, convierte en mayúsculas todas las letras alfabéticas y
dividida en dos mitades. Cada mitad es cifrada de forma separada mediante el
algoritmo DES sin aplicar ningún tipo de salto. Todo ello parece ser hecho para
facilitar la vida de los hackers mas tontos del mundo, pero los administradores,
menos inteligentes intentan complicarles la vida usando caracteres que no
existan en los teclados de tipo "QWERTY" de los mas normales o si simplemente
se tiene a disposición un teclado configurado para escribir en esa lengua, es
sumamente facil introducir un par de caracteres alemanes.
En el caso que nos ocupa la primera parte la clave indicaba que la password era
una derivación de la palabra "administrator", pero intercalando números y
caracteres especiales. Todo ello no es gran problema salvo si estos caracteres
especiales son un tanto raros, tal como lengua alemana u otra cosa mas exótica,
en este caso de poco sirven los múltiples diccionarios rainbow que existen en
la red, solo un ataque por fuerza bruta, pero aplicando algo de inteligencia
puede ser de alguna utilidad.
Viajero se planteó construir un ataque en base a "john" utilizando un modo
"external" especifico para atacar cinco o seis caracteres en forma bruta.
Calculaba que con los procesadores trabajando en paralelo podía atacar
fácilmente cinco caracteres y si la cosa se complicaba debería plantearse un
ataque conjunto con varias maquinas. Para ello pensó en utilizar la versión de
"john" adaptada para trabajar en redes neuronales tipo MPI.
Todo muy bonito pero, la versión de john en cuestión solo viene distribuida
bajo sus fuentes lo que significa que si se desea ejecutarlo hay que compilarlo
y enlazarlo. Si ademas deseamos hacerlo bajo Windows, todo hay que hacerlo bajo
este paraguas y tradicionalmente esto supone utilizar herramientas de pago. La
documentación disponible no era extraordinaria pero parecía claro que era
necesaria una versión de MPI instalada en la maquina donde se quería compilar.
Estudiando un poco mas la web http://bindshell.net/tools/johntheripper/ vio que
todas las pruebas habían sido hechas con la versión MPICH2-1.0.2 operando bajo
Linux o MacOSX. Como su intención era Windows el escenario era radicalmente
distinto, supuso que las cosas no iban a ser fáciles y el tiempo se encargó de
darle razón.
A veces es sumamente útil cuando se emprende algo que supones va a ser
complicado escribir sobre un papel cual es el objetivo. Después de reflexionar
un rato, Viajero anotó algo sobre un papel y después leyó complacido lo
siguiente. Compilar bajo cygwin "John The Ripper" versión MPI (MPICH2) para
poderlo ejecutarlo sobre Win2000 y WinXP.
INSTALACION DE MPICH2 BAJO CYGWIN
Lo primero que hizo fue bajarse de la web del departamento "Argonne National
Laboratory Group" de la Universidad de Chicago (www.mcs.anl.gov) el archivo
comprimido mpich2-1.0.6.tar.gz, lo descomprimió en un directorio temporal y
leyó en el README que le haría falta en un entorno linux, el compilador gcc,
gfortran o g77, el compilador g++, python 2.2 o superior y como opción el
compilador Fortran 90.
Después empezó con la laboriosa tarea de instalarse el cygwin con todos los
anteriores requisitos. No es difícil ya que basta con bajarse de www.cygwin.com
el ejecutable setup.exe, lo mejor es colocarlo en un directorio accesorio y
lanzarlo con una conexión a internet activa, ya que este pequeño programa lo
que hace es proponer una instalación standard y va buscando los paquetes que le
hemos indicado.
Es en la selección de los paquetes donde Viajero casi perdió la cabeza y los
nervios. La tarea de seleccionar uno a uno y comprobar las dependencias no es
de lo mas divertido del mundo, aunque cygwin presta una mano de forma activa.
También hay que saber que en caso de dificultad recalcitrante siempre puedes
elegir directamente los paquetes en www.cygwin.com/packages/
Una vez la primera parte de la tarea estaba terminada solo faltaba la segunda,
o sea instalarse MPICH2. Bastaba con seguir cautelosamente las instrucciones que
pudo leer en el archivo README que encontró al desempaquetar
mpich2-1.0.6.tar.gz. No fue difícil, tan solo laborioso. Desempaqueto sobre un
directorio de su elección "tar xfz mpich2.tar.gz" y se situó sobre el raíz "cd
mpich2-1.0.6". Creó un directorio donde situaría posteriormente el paquete
"mkdir /home/viajero/mpich2-install", después configuró el paquete
"./configure --prefix=/home/viajero/mpich2-install 2>&1 | tee c.txt"
La ultima parte de la instrucción es todo un detalle por parte de la
Universidad de Chicago, ya que, vaya todo bien o no, se crea un fichero "c.txt"
donde hay copia de la ejecución. En caso de problemas Viajero sabia que podía
enviarlo a "mpich2-maint@mcs.anl.gov" para ayudarle a desenredar la madeja.
Pero todo fue como una seda, lo cual es bastante raro, ya que como sabemos
Viajero se encontraba bajo un cygwin y no sobre una distribución real de linux.
Solo quedaba construir el paquete con "make |& tee m.txt" y tambien en este
caso se crea un fichero "m.txt" que se puede enviar a sus creadores en caso de
problemas. Finalmente se instalan los ejecutables y scripts en el directorio
bin "make install 2>&1 | tee mi.txt" y finalmente se actualiza el PATH para que
todos sepan donde están "PATH=/home/viajero/mpich2-install/bin:$PATH" , "export
PATH"
Viajero temía algún problema en el momento de comprobar la instalación, pero
tanto "which mpd" como "which mpiexec" dieron los resultados apetecidos. MPICH2
estaba funcionando correctamente bajo cygwin. Paso libre para compilar John The
Ripper, versión MPI.
Aunque ahora se encuentran en la versión
"http://bindshell.net/tools/johntheripper//john-1.7.2-bp17-mpi7.tar.gz" y fue
ésta la que utilizó Viajero para hacer sus pruebas. Descarga sobre un
directorio temporal dentro de cygwin y desempaquetado de forma standard da como
resultado tres directorios y un fichero README. Del README rápidamente se dio
cuenta que lo mejor era "pasar" de l. Se volvió hacia el directorio "src" e
intentó lo clásico con "John The Ripper", un simple
"make win32-cygwin-x86-sse2" debería rápidamente crear un ejecutable en el
directorio "run", sin embargo lo que cosechó fue un mensaje de error diciendo
que no se encontraba "mpicc", en concreto el mensaje era
"make[1]: mpicc: Command not found". "mpicc" es es solo una utilidad creada
especialmente para poder compilar en ambientes MPI. Una consulta rápida a la
mail list (john-mpi-subscribe@bindshell.net) recibió la sorprendente respuesta
de que lo mejor era que utilizara gcc en lugar de mpicc
Con un editor de lo mas normal, Viajero, substituyó en el fichero "Makefile"
todas las ocurrencias "mpicc" por "gcc" y las cosas marcharon un poco mejor,...
pero solo un poco. Ahora el mensaje fue
"bench.c:38:17: mpi.h: No such file or directory". El mensaje no podía ser mas
claro, "make" era incapaz de encontrar las librerías que pertenecen a la
distribución de MPI. Aparentemente el problema es fácil de resolver, basta con
añadir al PATH de cygwin la dirección donde se encuentran las fuentes que
deseamos utilizar. Viajero deseaba hacerlo de forma inteligente, o sea que no
tuviera que modificar PATH a cada arranque, y esto se consigue modificando el
fichero "cygwin.bat" que se encuentra en directorio raíz de cygwin. Con añadir
la linea "PATH=%PATH%:/dirección-deseada" al susodicho "bat" y a correr.
Digamos que correr no corrió mucho, ya que la siguiente compilación le dejo un
amargo sabor de boca con un esóterico mensaje sobre una linea de uno de los
includes. No era posible. Algo iba irremediablemente mal. Volvió a consultar la
lista de distribución de bindshell que le respondieron rápidamente. "Si quieres
compilar un programa basado en MPI bajo cygwin y que posteriormente corra bajo
Windows, tienes que borrar la instalación de MPICH2 bajo cygwin e instalar la
versión para Windows". Se dice mas pronto de lo que se hace y a Viajero le dio
dolor de cabeza nada mas pensar en lo que se le venia encima, pero nada se
termina si no se empieza, así que lo mejor en estos casos es dejarse de
lamentarse y ponerse manos a la obra.
INSTALACION DE MPICH2 BAJO WinXP
Viajero empezó por el principio, o sea buscar las herramientas adecuadas en
este caso el instalador. Está en
"http://www.mcs.anl.gov/research/projects/mpich2/downloads/index.php?s=downloads"
, elegir el fichero correcto, "mpich2-1.0.7-win32-ia32.msi" y en este caso
copiarlo en un sitio que después se debe recordar y lanzarlo con derechos de
administrador. El directorio por defecto donde se instala es
"C:\Program Files\MPICH2" y bajo l se encuentran "include", "lib", donde se
encuentran "headers" y librerias y tambien el directorio "bin" donde están los
ejecutables. Durante la instalación se le pidió una palabra de paso que en
teoría después se debe reutilizar sobre el resto de maquinas donde se quiera
monta el anillo de CPUs, pero de eso hablaremos mas tarde. Viajero se limitó a
crear un password que no tuviera nada que ver con l ni con sus andanzas mas
habituales y anotarla cuidadosamente.
Terminado esto, tuvo que desinstalar laboriosamente todo lo que se encontraba
bajo cygwin para evitar interferencias entre las dos instalaciones sin
olvidarse de todos los PATH habidos y por haber, que en esto, todo el entorno
de Windows es sumamente quisquilloso y tiene una memoria prodigiosa e
inoportuna que fastidia cuando menos te lo esperas. Finalmente todo quedó listo
para la siguiente etapa. La compilación.
LA COMPILACION
Contento como niño con zapatos nuevos, Viajero volvió a probar con
"make win32-cygwin-x86-sse2", con desesperación recibió de nuevo una catarata
de mensajes que se podían reducir a que seguían sin encontrarse las librerías.
Y sin embargo Viajero había modificado convenientemente el PATH de cygwin para
que buscara los programas en donde habían sido instalados automáticamente por
MPICH2 o sea en "C:/Program Files/MPICH2/include" ¿Que había podido fallar? Le
costó bastante darse cuenta que estaba cometiendo un error de principiante.
"make" no va a buscar las librerias y headers en función del contenido de las
variables de entorno, hay que indicarse lo de forma explicita en el propio
"Makefile". La razón no la conocía, pero bien pudiera ser que los programadores
de esta utilidad se quisieran asegurar que las cosas estaban donde el
programador desea y no donde le parece al Sistema Operativo el mejor sitio.
Esto los utilizadores de Windows puede que no lo entiendan, pero los de
Unix/Linux lo comprenden perfectamente.
Viajero modificó levemente el Makefile para que encontrara la joya de la corona.
En este caso ademas había que acordarse que se estaba compilando bajo cygwin y
por tanto las cosas están en sitios que aparentemente no son los mas evidentes.
En este caso tuvo que cambiar la linea
"CFLAGS = -c -Wall -O3 -fomit-frame-pointer" por
"CFLAGS = -c -Wall -O3 -fomit-frame-pointer
-I/cygdrive/c/Progra~1/MPICH2/include"
Véase con atención que los includes apuntan a
"/cygdrive/c/Progra~1/MPICH2/include" y no a
"Progra~1/MPICH2/include" ya que cygwin mapea todo lo que se encuentra bajo el
disco principal a un dispositivo virtual llamado "/cygwin/c/". Es una de las
características y gracias de este simulador. A Viajero le salieron algunas
canas hasta que no se dio cuenta de lo que pasaba.
Quien piense que hasta aquí llegaron las desventuras de Viajero, intuirá que
nada mas lejos de la realidad, aunque solo sea porque el articulo le falta un
buen trozo para terminar. El siguiente problema fue que "make" se lamentaba con
amargura que no encontraba algunos componentes de las librerías. Vuelta a
consultar a la lista de distribución para descubrir que las librerías no son
las mismas si se quiere compilar desde cygwin utilizando una distribución
MPICH2 instalada bajo cygwin que si esta instalada en Windows. Afortunadamente
fue rápida la solución ya que le informaron de exactamente cuales eran las
librerías a copiar en "/MPICH2/lib" y substituir la linea en Makefile que decía
"LDFLAGS = -s -lm" por otra donde ponía
"LDFLAGS = -s -lm -L/cygdrive/c/Progra~1/MPICH2/lib -lmpicxx -lfmpich2 -lmpi"
Aquí hay un pequeño detalle, mpicxx.h es un header y no una librería, pero el
caso es que las quejas sobre las librerías inexistentes desaparecieron, solo
para que aparecieran nuevos problemas.
El mensaje era siempre parecido
"john.o:john.c:(.text+0x33): undefined reference to `_MPI_Init'", o sea que
había un procedimiento, variable o parámetro que se no encontraba en ninguna
parte. Fueron duros días los que tuvo que sufrir Viajero, ya que _MP_Init esta
claramente definido en "mpi.h" y sin embargo parecía ser ignorada durante la
operación de enlazado. Fueron de nuevo los chicos que desarrollan MPICH2 que le
identificaron el problema y le indicaron la solución. Es algo no ciertamente
intuitivo y forma parte de la filosofía que siguen los enlazadores a la hora de
unir todas las piezas precompiladas. Hay que acordarse que en el momento de
enlazar, si el archivo "a.o" utiliza símbolos definidos en el archivo "b.o",
hay que especificar "a.o" antes que "b.o". Si, definitivamente no es intuitivo,
pero el caso es que cuando Viajero cambio la linea
"$(LD) $(JOHN_OBJS) -lkernel32 -o ../run/john.exe"
por la linea
"$(LD) $(JOHN_OBJS) -lkernel32 $(LDFLAGS) -o ../run/john.exe"
se acabaron sus problemas y encontró un magnifico fichero llamado john.exe bajo
el directorio "run". Ya tenia el ejecutable, ahora no había mas que utilizarlo.
MPICH2, JOHN, DUAL CORE.
La instalación de MPICH2 bajo Windows no solo crea una serie de librerías y
headers, también instala un servicio llamado "smpd" y un ejecutable llamado
"mpiexec.exe" que sirve para lanzar el programa "MPIzado". De todas formas
Viajero era la primera vez que utilizaba estos entornos y siempre los comienzos
son difíciles, así que hechó mano de un par de utilidades que vienen con la
distribución. "wmpiregister" sirve para configurar un anillo y como el primer
paso de Viajero era solo aprovechar los dos procesadores de un "DUAL CORE"
supuso que podía pasar de sus servicios. Después esta "wmpiregister" muy util
para registrar un nombre y su password en el registro de Windows. De utilidad
dudosa si eres el administrador de la maquina. El que tiene muchas mas
posibilidades es "wmpiexec". Es simplemente un "front end" que hecha una mano.
Viajero tuvo que especificar donde estaba el "john" que quería lanzar y las
diversas opciones. Lo mas importante era tener presente que solo deseaba lanzar
su programa en una sola maquina, para hacerlo tuvo que checkear "more options"
y en la opción "host" poner "localonly".
Al lanzar el "john" mediante "execute" aparentemente todo funcionó
correctamente, al comprobar mediante "Task Manager" la situacion de las dos
CPUs, comprobó que ambas estaban al 100%. Pensó que ya habia encontrado la
solución definitiva hasta que se le ocurrió parar el ataque, lo intentó, pero
no lo consiguió, un extraño bug en el programa se lo impedía. Tuvo que pararlo
con el "Task Manager" y rearrancarlo, después con la opción "shown" vio
exactamente cuales eran las opciones y comandos que utilizaba MPI, después
abrió una sesión "cmd" y desde allí recopió lo que había observado. Y desde
allí si que podia pararlo, el problema es que no podía utilizar prácticamente
la maquina ya que ésta consumía todos los recursos para "john-mpi". Viajero lo
que deseaba era que su maquina consumiera todos los tiempos muertos, no que lo
matara con esperas desesperantes para abrir una vulgar hoja "excel".
La solución se encontraba en una de las múltiples opciones que tiene "mpiexec"
y que consiste en fijar la prioridad de la sesión. Finalmente lanzo una sesión
con la instrucción
"mpiexec.exe -hosts 1 localonly 2 -localonly -priority 1
-noprompt john.exe -session=pims -e=prepend-pims hash-pims.txt",
ya que tenia una serie de hash interesantes en el fichero hash-pims.txt y había
creado un modo especial extendido con el nombre de "prepens-pims", para poder
recuperar la sesión la había denominado "pims".
El resultado fue bastante agradable, ambos procesadores marcaban al 100%, pero
cuando quería trabajar para su empresa, la carga se reducía automáticamente,
con el único peaje de una ligera espera cuando cambiaba de tareas. Todo parecía
funcionar correctamente y Viajero muy contento, interrumpió la sesión y
construyó un fichero "bat" que contenía la siguiente instrucción
"mpiexec.exe -hosts 1 localonly 2 -localonly -priority 1 -noprompt john.exe
-restore=pims"
y que copió en su directorio "...\Programs\Startup". Seguro de su éxito no hizo
mas pruebas.
A la mañana siguiente, cuando llego a su trabajo, después de hacer los falsos
saludos de todos los días, conectó y encendió su ordenador, que después de
hacer todas las comprobaciones y rutinas que Windows nos tiene acostumbrado,
lanzó su especialmente construido fichero "bat",.... que en unos segundos se
detuvo. Según el mensaje en pantalla no existían ni "john_rec.rec.0" ni tampoco
"john_rec.rec.1". Evidentemente hay un bug en el programa. John crea por
defecto un fichero "john.rec" donde se guardan los datos necesarios para
recuperar una sesión interrumpida. En caso de que se especifique una sesión con
un nombre en concreto, por ejemplo "pims", se crea un fichero llamado
"pims.rec". Como en este caso había que recuperar dos sesiones, una para cada
procesador, john había creado dos ficheros distintos denominados "pims.rec.o" y
"pims.rec.1", pero después hacia caso de la opción "restore=pims" y seguía
buscando sus amados "john.rec".
A Viajero le dolía la cabeza ya que mientras estaba buscando el problema una
amable secretaria de esas que parecen puestas en este mundo solo para ser lo
mas inoportunas e inútiles, le había estado dando la lata sobre un documento,
evidentemente anodino, que debía ser firmado con urgencia. Por tanto ni se le
ocurrió buscar el bug en los fuentes, simplemente cambio los nombres de los
ficheros para que john los encontrara, este los descubrió a la primera. El
contento y Viajero mas.
Solar Designer, al que hemos mencionada al principio del articulo podrá decir
lo que quiera, pero lo cierto que un john "MPIzado" de esta forma se comió un
par de hash en apenas dos días , cuando la experiencia de Viajero le decía que
le hubiera costado el doble con el método clásico y todo ello sin tener que
preocuparse ni de repartir tareas ni de hacer cálculos. Dos únicos
inconvenientes. Probablemente debido a otro bug en el programa no se puede ver
el avance del ataque y el otro es que la maquina funciona a plena potencia
desde el momento en que se enciende y esto, en opinión de Viajero, no puede ser
bueno par la salud del laptop ni para su longevidad. De todas formas la
password alemana que fue el motivo de toda esta carrera contra los elementos
cayó en cosa de una semana.
MPICH2, JOHN, EN RED
Perico Viajero tampoco deseaba freír la maquina que habían depositado a su
cuidado. Puede que a otros no les guste que la inversión de sus escuálidos
ahorros desaparezca en una nube de humo, poco virtual y bastante maloliente.
Viajero pensó que otra opción era organizar un anillo de maquinas. Según la
documentación de MPI esto es posible hacerlo si somos administradores del
DOMAIN de la red, pues es ella la encargada de permitir la entrada en cada una
de las maquinas que la componen, en la practica esto no es cierto, basta con
tener el mismo usuario registrado en las maquinas que deseamos utilizar para
que estas se pongan a trabajar obedientemente. Viajero hizo la prueba con éxito
con dos maquinas fijas, una con Windows 2000 y otra con WinXP. A continuación
añadió un viejo laptop que ni siquiera tenia SSE2. Como anécdota, esta vieja
reliquia se negaba a hacer su parte y Viajero tuvo que recompilar john con la
option "any" y esta vez el viejo laptop se agregó obedientemente al anillo
aportando su granito de potencia.
Por falta de espacio no podemos detallar los entresijos de la operación, que
tampoco es sencilla, pero si demuestra que es posible infectar varias maquinas
en una red y conseguir que se pongan a trabajar en tu honor para fines honestos
o deshonestos.
2008 SET, Saqueadores Ediciones Técnicas. Información libre para gente libre
www.set-ezine.org
web@set-ezine.org
*EOF*
