Voy a dejar aquí un apunte sobre cómo borrar de verdad y por completo el contenido de un disco duro, de forma que sea realmente imposible recuperar la información. Esto, que puede parecer una barbaridad innecesaria, podría ser conveniente en algunos casos. No sólo se destruye toda la información. En ocasiones se puede resucitar así un disco aparentemente muerto.

A la hora de vender o regalar un disco duro no parece que la gente se preocupe mucho de borrar su contenido. Esto a veces da lugar a historias como la del portátil de Amir Massoud Tofangsazan (vía mename.net).

A poco que se estudia un poco sobre sistemas de ficheros (y yo no sé casi nada) se aprende que para eliminar la información no es suficiente con borrar los ficheros, pues aunque se pierde la información de dónde están los ficheros, éstos siguen estando en el disco. Es tan fácil recuperarlos que hasta yo lo hice una vez.

Me temo que formatear el disco o la partición tampoco ayudaría mucho, pues el porcentaje de bloques que quedarían sobreescritos tiende a ser más bien bajo, dependiendo del sistema de ficheros (o eso creo). En cualquier caso, alguien con suficientes motivos para intentarlo podría recuperar buena parte de la información con mayor o menor esfuerzo.

Con estos escasos conocimientos llego a una conclusión bastante simple: una solución posible es llenar el disco de ceros, hacer que todos y cada uno de los bytes almacenables en el disco duro sea un cero redondo. Esta aproximación se me ha ocurrido gracias a la filosofía de que todo son ficheros, característica de UNIX.

De este modo, el borrado total e irreversible del disco duro se convierte en una operación extremadamente sencilla que en GNU/Linux se puede llevar a cabo con el comando dd if=/dev/zero of=/dev/hdd bs=8192

Aunque en principio este comando podría ejecutarlo cualquier usuario con permiso de escritura sobre el dispositivo del disco duro (en este caso /dev/hdd), yo prefiero dejar esta clase de trabajos para root.

El parámetro bs=8192 define un tamaño de bloques de 8K. Al principio utilizaba un tamaño de bloque de 512 bytes, que coincide con el tamaño de bloque de la mayoría de los discos duros. Esto funcionó con un disco de 4.3 GB en poco más de una hora, pero con uno de 40 GB el tiempo necesario era excesivo. Entonces cambié el tamaño de bloque a 8192 y tardó menos de media hora.

Al terminar la ejecución del comando dd que el disco está –supuestamente– lleno de ceros. Se me ocurren dos motivos para comprobar que esos ceros están ahí:

  • Comprobar que los ceros que se han escrito están ahí, por lo que la información eliminada ya no es accesible.
  • Comprobar que los ceros que se han escrito se pueden leer.

Esta comprobación tiene sus matices:

  • Existe la posibilidad de que no se haya podido escribir en algunos bytes, pero como éstos ya contenían ceros desde el principio no será posible detectar esto.
  • O peor aún, puede que al no poder leerse un byte el resultado de la lectura sera un cero, en cuyo caso no se puede saber qué dato contiene el disco.

En cualquier caso, me temo que un disco duro que pudiera ocasionar estos problemas no sería mucho más útil que un pisapapeles.

Me gustaría poder dar un comando sencillo de leyera un fichero y mostrara una estadística de la cantidad, porcentaje y rango de posición de los bytes no nulos contenidos en un fichero, pero me daba mucha pereza buscar algo tan específico y preferí escribirlo yo mismo: checkzero.c

Una última observación antes de pasar a ver un ejemplo práctico: vender un disco duro sin una tabla de particiones válida podría resultar molesto para el comprador, y resulta que una tabla de particiones llena de ceros no es válida. Según qué comprador, podría ser molesto venderlo sin ninguna partición.

En mi caso los he vendido con una tabla de particiones vacía, que es lo mínimo para que ningún programa de particionado se queje. Crear una tabla de particiones vacía en GNU/Linux es tan fácil como intentar acceder a la tabla de particiones del disco y dejar que fdisk se encargue de crear una tabla de particiones nueva. Esto puede hacerse de forma no interactiva con el comando echo -n “w\n” | fdisk /dev/hdd

En cuanto a recuperar un disco duro aparentemente muerto, sólo decir que un disco duro puede no querer funcionar por el mal estado de su sistema de ficheros –y dar la sensación de estar dañado– cuando en realidad se encuentra físicamente bien. Una limpieza a fondo como ésta podría resucitarlo, pero aún no lo he comprobado detalladamente.

Y ahora un ejemplo:

root@mort:~# time dd if=/dev/zero of=/dev/hdd bs=8192
dd: escribiendo «/dev/hdd»: No queda espacio en el dispositivo
4885336+0 records in
4885335+0 records out
40020664320 bytes (40 GB) copied, 1646,36 seconds, 24,3 MB/s

real    27m26.375s
user    0m1.204s
sys     1m26.058s
root@mort:~# echo -n "wn" | fdisk /dev/hdd
El dispositivo no contiene una tabla de particiones DOS válida ni una etiqueta de disco Sun o SGI o OSF
Se está creando una nueva etiqueta de disco DOS. Los cambios sólo
permanecerán en la memoria, hasta que decida escribirlos. Tras esa
operación, el contenido anterior no se podrá recuperar.

El número de cilindros para este disco está establecido en 77545.
No hay nada malo en ello, pero es mayor que 1024, y en algunos casos
podría causar problemas con:
1) software que funciona en el inicio (p.ej. versiones antiguas de LILO)
2) software de arranque o particionamiento de otros sistemas operativos
   (p.ej. FDISK de DOS, FDISK de OS/2)
Atención: el indicador 0x0000 inválido de la tabla de particiones 4 se corregirá mediante w(rite)

Orden (m para obtener ayuda): ¡Se ha modificado la tabla de particiones!

Llamando a ioctl() para volver a leer la tabla de particiones.
Se están sincronizando los discos.
root@mort:~# fdisk -l /dev/hdd

Disco /dev/hdd: 40.0 GB, 40020664320 bytes
16 cabezas, 63 sectores/pista, 77545 cilindros
Unidades = cilindros de 1008 * 512 = 516096 bytes

Disposit. Inicio    Comienzo      Fin      Bloques  Id  Sistema
root@mort:~# ./checkzero /dev/hdd
Analizando '/dev/hdd'...
Primer byte no nulo encontrado:             511
Fichero /dev/hdd leido sin problemas
Número de bytes analizados:     4.00207e+10
Número de bytes no nulos:                 2 (4.997418294e-09 %)
Primer byte no nulo:                    511
Último byte no nulo:                    512