El mito de los comandos asesinos II. Peticiones del oyente

Hace nada publicaba un artículo llamado “El mito de los comandos asesinos” y lo finalizaba invitando a los lectores a que compartieran sus experiencias al respecto.

Afortunadamente, casi nadie me comentaba grandes daños en sus ordenadores por alguno de estos comandos, pero si sugerían probar alguno. Así pues, al estilo de “las peticiones del oyente” en la radio, vamos a probar alguna nueva forma de perder nuestros datos sugerida por los lectores.

La primera sugerencia, fue utilizar dd. No había incluido a dd en el artículo original puesto que no se trata de un mito, se trata de un comando capaz de borrar datos definitivamente, tal como ya habíamos comentado en este artículo “Eliminar datos "de verdad" de un disco”

Pero no por eso vamos a dejar de probarlo. Dicho y hecho, puse mi máquina virtual a trabajar y como ya esperaba, pasó a mejor vida con todos sus datos. Solo puntualizar que dd hay que ejecutarlo con permisos de superusuario o con sudo para que funcione.

La siguiente sugerencia fue una bomba lógica. Lo siento Otto Jimenez, por más que busqué y rebusque, no logre ni que se ejecutara, y eso que probé diferentes versiones que encontré en la red. Este es el triste resultado.

Raúl Rodrigo nos sugirió utilizar rm de manera distinta. Añadiendo un sencillo * al final del comando rm -Rf /. Ejecutado como usuario normal, ocurrió poca cosa.

Pero al usarlo como administrador, aunque obtuve mensajes de ficheros que no se pudieron borrar, mi máquina virtual se fue de excursión al paraíso de los bits perdidos.

Alguien por Twitter (lo siento, no encuentro el mensaje y no puedo decir quien) me sugirió mkfs. Este comando sirve para dar formato a un disco, así que era de esperar que tuviera buenos resultados, pero...

Y por último, pero no menos importante, Jnuserful sugeria un par de usos interesantes de chmod. Concretamente "chmod -R 777 /" y "chmod -R 000 /". Lo cierto es que en ambos casos, y haciendo uso de sudo, la máquina virtual quedo bastante perjudicada, pero los datos no desaparecieron, así que en caso de emergencia, podrían haber sido “rescatados”.

No quiero dejar sin mencionar a un amigo anónimo que “se cargo” su Archbang por un uso inadecuado de pacman (concretamente sudo pacman -Rsn pacman) pero como no he usado nunca Archbang, no puedo opinar.