El clonado ya no se lleva. Parte 1/3

Si alguna vez habéis asistido a una de mis charlas sobre tratamiento de evidencias digitales, posiblemente me habréis escuchado decir que los clonados de discos duros ya no se llevan. Algunos se extrañan al oírme decir tal afirmación, más si cabe, si la persona que lo escucha, no conoce otra palabra en el ámbito del análisis forense que no sea la del “clonado” y “volcado”. Pero en realidad esto no es cosa de modas: es un tema de eficiencia y eficacia. Clonar un disco duro implica copiar bit a bit toda la información que este contiene, es decir, copiar todos los bits (0 y 1) de un disco duro original sobre otro disco copia. Como seguro que ya os imaginaréis, por cada disco duro (físico) original, se necesitará un disco duro (físico) copia, no vale con lo de «si tengo varios discos duros originales pequeñitos, clonarlos todos a uno más grande y ya está«. No, no es así. Un clonado siempre implica que, por cada disco duro origen, se necesite otro disco duro físico de destino, y no solo eso, no servirá cualquier disco duro. El disco duro que se utilizará para realizar la copia deberá ser de las mismas características que el disco duro original: tipo, tamaño, sectores… Además de tener que estar completamente wipeado, esto no es otra cosa que “poner” previamente todos los bits del disco destino a 0, para así evitar que se «contamine» con los datos que ya pudieran estar grabados en el disco de destino.

Fig.1 MorterueloCON 2017

 

Por otra parte, si lo que tenemos que hacer es clonar un par de discos duros al mes, nos dará igual este extremo. El problema surge cuando es necesario adquirir  (capturar) mediante clonado cientos de discos duros al mes, cada uno de ellos con un tamaño distinto, un fabricante distinto, un tipo distinto… Además, como ya comenté, el disco de destino tiene que estar wipeado. En este caso, tampoco vale la excusa de decir que «el disco de destino está a estrenar, y que lo acabo de sacar del embalaje del fabricante«, hoy en día aún hay técnicos que afirman que es necesario desprecintar el disco duro de destino al momento de realizar el clonado para garantizar que no tiene otros datos anteriores grabados. El problema es que un disco duro, nuevo, a estrenar, recién sacado de su caja original, que huele a nuevo, no tiene porque venir de fábrica con todos los bits a cero, es más, algunos de ellos ya vienen con formato asignado y un par de ficheros PDF informativos y publicitarios en su interior, por no hablar de los discos reacondicionados. Así que para hacer clonados forenses de discos, los discos copia o destino tienen que estar previamente wipeados si o si, este proceso si será el que garantice la validez del disco duro destino, y no el sacarlo de una caja con una pegatina de plástico que ha puesto ahí el fabricante.

Fig.2 Disco duro en una bolsa electro estática.

 

Para solucionar estos problemas y otros que conllevan el clonado de discos duros, ya hace muchos años que se “inventaron” las imágenes forenses de discos duros, pero ¡OJO!, una imagen forense de un disco duro no es fotocopiar un disco duro por las dos caras y luego compulsar la fotocopia. (verídico 😉 )

Fig.3 Imagen «casi-forense» de un disco duro

 

Realizar una imagen forense del contenido de un disco duro, implica tomar todos esos ceros y unos que están grabados en el disco duro origen, y en vez de grabarlos directamente sobre la superficie de otro disco (esto sería un clonado), los «empaquetamos» en un fichero contenedor, como puede ser los ficheros Ex, DD, ISO, RAW. De este modo, podremos copiar, mover, analizar estar imágenes forenses, sin necesidad de trabajar con un disco duro (físico) copia. Es decir, en vez de custodiar un elemento físico como es un disco duro, custodiamos y operamos con ficheros digitales que se pueden mover de un lado al otro, y que en todo momento podremos garantizar su integridad mediante el uso de sistemas de firmado digital HASH.

Ahora que ya os he convencido (o no) sobre la conveniencia de realizar imágenes forenses en vez de clonados para la adquisición de dispositivos de almacenamiento, vamos a ver como poder realizar esas imágenes forenses. Lógicamente, el método más sencillo, es coger una mal llamada «clonadora» forense, conectarle dos discos, origen y destino, pulsar sobre el botón de “Realizar Imagen” y ya solo nos queda esperar a que termine. Pero explicar el funcionamiento de estos dispositivos en este blog no tendría mucho sentido.

Fig.4 ImageMASster SoloIV G3 Plus

 

Así que explicaré como poder «jugar» con los sistemas de creación de imagen forense, para en cierto modo perder el miedo que todavía hoy en día existe sobre ellos.

Aunque normalmente no me gusta hablar de sistemas o marcas de software concretos, para desarrollar lo que explicaré a continuación utilizaré el sistema operativo forense Deft de Linux (o Deft Zero, que es la versión «reducida»), con las siguientes herramientas: Guymager, sha1deep, sha1sum, dhash, fdisk y cat. Además también utilizaré el software comercial Encase desarrollado por Guidance, para comprobar que los resultados obtenidos son exactamente los mismos.

Ya sea a través del sistema Deft de Linux o mediante un Windows, tendremos que prestar especial atención al modo de montaje de los dispositivos a analizar, tanto el original como el de destino. En Deft, por defecto los dispositivos de almacenamiento no se montan al inicio, los hay que montar de forma manual, seleccionando si los montamos en modo solo lectura (protegido) o en modo lectura/escritura (habitual).

Fig.4 bis Puntos de montaje en Deft

 

Sin embargo, en Windows, todos los dispositivos de almacenamiento se montan automáticamente y además, por defecto se montan en modo lectura/escritura, para evitar que ocurra esto podremos utilizar un bloqueador por Hardware.

Fig.5 Distintos modelos de bloqueadoras Tableau

 

En sistemas Windows también podremos modificar la siguiente clave de registro, para que todos los dispositivos USB de almacenamiento que se monten, lo hagan en solo lectura. Especial atención si lo hacemos así, ya que por ejemplo si conectamos un disco duro SATA a través de una base USB normal, Windows puede interpretar que es un disco duro normal y no lo bloquee contra escritura, con todo lo que esto puede implicar.

Fig.6 Modificación de la clave de registro en Windows

 

Lógicamente pondremos en modo escritura el disco duro destinado a guardar la adquisición, ya que si no, difícilmente podremos guardar ningún tipo dato en el mismo. Aunque esto parezca un punto sin importancia, la podemos «liar parda» si nos confundimos en este apartado, ya que si en vez de poner en modo escritura el disco que vamos a utilizar para guardar los datos, ponemos en modo escritura el disco original o evidencia ya tenemos un problema, más si cabe, si aún encima, continuamos con el proceso pensando que el disco original es el que está en modo solo lectura y el disco de almacenamiento es el que está en modo escritura, si en esas condiciones se nos ocurre pulsar el botón “Start”, estaremos realizando un precioso wipeado (destrucción de la información) de nuestra disco origen o evidencia. Es decir, hemos destruido, sin posibilidad de recuperación una evidencia digital máster. Por eso, que aunque este tipo de sistemas suelen ser muy intuitivos, estamos operando son sistemas especializados, en los que el operador tiene que ser plenamente consciente de lo que está haciendo, ya que cualquier tipo de error, por muy pequeño que parezca, puede llevar a la destrucción completa de una evidencia digital.

Si hemos completado todos los pasos de forma correcta, ahora solo nos queda seleccionar el modo de adquisición, el cual podrá ser en modo “clonado” o “imagen forense”, normalmente si lo que queremos realizar es una imagen, podremos seleccionar entre imagen DD o RAW y Ex (expert witness).

El primer tipo son imágenes en bruto tipo DD, es decir, un disco de un Terabyte de capacidad, se almacenará en una imagen que ocupará un Terabyte de información. Pero ¡OJO!, no se puede hacer una imagen DD o Ex sin comprimir, sobre un volumen lógico de un disco con el mismo tamaño que el de origen, ya que la tabla de particiones de destino ocupa un espacio, que reducirá el espacio disponible de dicho disco.

Luego están las imágenes Ex, por decirlo así, estas son imágenes “avanzadas” ya que disponen de una serie de características, que las dotan de mejoras técnicas, como la posibilidad de compresión de la imagen y recuperación ante fallo. El ejemplo más claro nos lo encontramos por ejemplo con un disco duro de un Terabyte de capacidad, que solamente tiene grabados datos distintos de 0 por tamaño de 100Gb, (espacio asignado, unallocated y espacio sin asignar), el resto de bits de ese disco duro (900Gb) están a cero, en esas condiciones si realizamos un clonado del disco o una imagen forense tipo RAW, copiaremos en destino esos 900Gb de ceros, lo que no se antoja muy eficiente: ni por el tiempo que se tarda en la escritura de esos 900Gb en destino, ni por el espacio que nos hará falta para almacenar esa imagen. Por regla general, los discos duros de ordenadores personales, no suelen estar llenos de datos, incluso aunque exista mucho espacio “alocado” , este no suele ocupar el 100% del espacio disponible del disco, por lo que normalmente, un disco duro personal dispondrá de un buen “trozo” de ceros, este es el ejemplo más bizarro, pero los sistemas de compresión de imágenes forenses, también toman otras medidas que además permiten comprimir la parte de datos, lo que reduce aún más el espacio que ocupará la imagen forense.

Pero claro, ya os veo venir, algunos ya estáis pensando que si es una imagen forense, esta tiene que ser integra de todo el disco duro y no solo de las partes que a mí me interesen. Cierto es, lo que ocurre es que los que han diseñado el sistema Ex, son gente inteligente, que ya tuvieron en cuenta este pequeño detalle. Realmente las operaciones de compresión que os conté en el párrafo anterior funcionan a nivel interno del sistema de empaquetado, a ojos de cualquier mortal, el contenido de una imagen DD o Ex es exactamente el mismo, pero como seguro que aún así, seguís sin creerme (y hacéis bien), a continuación vamos a un jugar un poco con estos formatos, para que podáis ver con vuestros propios ojos todo lo que os estoy contando:

Tomaremos como fuente de Evidencia 1, un Pendrive marca KINGSTON, modelo DataTraveler DT1, con 1Gb de capacidad, color blanco y número de serie: 05317-5478CN.

Fig.7 Pendrive DataTraveler de Kingston

 

Iniciamos nuestro sistema operativo Deft Linux, y conectaremos nuestra Evidencia 1, en modo solo lectura al sistema. En este caso, la adquisición se hará sobre un disco duro interno del sistema, en caso contrario, conectaremos nuestro disco destino y lo montaremos en modo Lectura/Escritura. Por suerte Deft dispone de un aviso para manazas en el que nos alerta de lo que vamos a hacer.

Fig.8 Aviso para manazas en Deft Linux

 

Con el comando «fdisk -l», comprobamos el punto de montaje de nuestro dispositivo «Evidencia 1«, en este caso, será «/dev/sdf«.

Fig.9 Comando fdisk de Linux

 

Si todavía nos cuesta un poco tocar la consola de comandos de Linux, también podemos utilizar la herramienta «Discos«, esta herramienta dispone de un entorno gráfico que nos permitirá localizar el punto de montaje de nuestra Evidencia 1, en este caso: /dev/sdb Como ya dije antes, es muy importante no confundirnos a la hora de seleccionar el origen y destino de nuestra adquisición, ya que las consecuencias serian fatales.

Fig.10 Herramienta «Discos» de Linux

 

Una vez que ya sabemos cuál es el punto de montaje de la Evidencia 1, comenzaremos a realizar las distintas operaciones de clonado y creación de imágenes, para así comprobar si obtenemos los mismos resultados o no.

 

1.) Creación de una imagen EXX, comprimida y sin trocear.

Abrimos Guymager, seleccionamos el formato de imagen EXX. En la opción «split» ponemos un número superior al total del tamaño de la evidencia y así no nos la troceará y obtendremos un fichero único. Finalmente marcamos la opción de calcular una firma digital SHA1

Fig.11 Herramienta Guymager

 

Cuando termine el proceso, abrimos el fichero de log, y veremos el hash del resultado, así como el resultado del resto de operaciones.

Fig.12 Hash SHA1 de la adquisición

 

Con esta operación hemos obtenido una imagen EXX comprimida de 655Mb de tamaño sobre los 1024Mb del disco original (nos hemos ahorrado mas de 300Mb de espacio), sin haber troceado la imagen, el hash obtenido del resultado es: A5D016A5D3B9FA02E7FA871AF938BD372436D827.

 

2.) Creación de una imagen EXX, comprimida y troceada.

En este caso operamos de igual modo que el punto anterior, con la salvedad, que en el apartado «split» indicamos que nos trocee la imagen en partes de 100Mb

Fig.13 Guymager creando una imagen EXX troceada.

 

De nuevo al terminar, abrimos el fichero log y comprobamos el resultado del proceso.

Fig.14 Hash SHA1 de la adquisición

 

También podemos acceder al directorio de almacenamiento de la imagen para así comprobar el resultado de este tipo de adquisición y como efectivamente quedó troceada. En imágenes tan pequeñas como esta, apenas tiene sentido el troceado, este sistema está pensado para adquirir por ejemplo un disco de 2Tb y poder guardar la imagen o bien en dos o tres discos mas pequeños, o por ejemplo, para evitar los problemas de tamaño máximo por fichero de 4Gb de algunos sistemas antiguos :

Fig.14bis Resultado de imagen troceada

 

Con esta operación hemos obtenido una imagen EXX comprimida de 655Mb de tamaño sobre los 1024Mb del disco original, troceada en 6 fragmentos de 100Mb y uno de 55Mb, el hash obtenido del resultado es: A5D016A5D3B9FA02E7FA871AF938BD372436D827.

 

3.) Creación de una imagen DD, sin comprimir y troceada.

De nuevo con Guymager, seleccionamos el formato de imagen DD RAW. En la opción «split» ponemos el valor de 100Mb para que nos la trocee en fragmentos de ese tamaño. Al terminar, abrimos el fichero log y comprobamos el resultado del proceso para obtener el hash.

Fig.15 Ficheros de una imagen tipo RAW troceada.

 

Si no confiáis en el hash que os arroja Guymager, pensando que este puede ser el hash del disco origen y no el de las imágenes creadas (por eso siempre sale el mismo), existen varios métodos para comprobar el hash de una imagen troceada en formato DD, en este caso, utilizará el método más bestia que se me ha ocurrido, pero es la forma de demostrar, que da igual los procesos que se hagan con una imagen forense, mientras se hagan todos los pasos correctamente, no afectará en nada.

Para calcular el hash de las imágenes troceadas, utilizaré la herramienta «cat» de Linux, sí, esa herramienta que todos utilizamos para abrir ficheros de texto, pues resulta que «cat» realmente no abre un fichero, lo que hace es concatenar su contenido con otro fichero, pero claro, si solo le pasamos un único fichero como variable, nos los mostrará por pantalla. En este caso, con la herramienta cat, concatenaré los 7 trozos de la imagen forense DD en un nuevo fichero llamado «ImagenDDCompletaConcatenada.dd»

Fig.16 Proceso de concatenado de la imagen troceada

 

Ahora calculo el hash SHA1 del fichero ImagenDDCompletaConcatenada.dd obteniendo el siguiente resultado:

Fig.17 hash del fichero concatenado

 

Con esta operación hemos creado una imagen forense tipo DD troceada en 7 fragmentos, luego con la herramienta «cat» los hemos «unido» para posteriormente calcular la firma digital del fichero resultante, arrojando el valor hash: A5D016A5D3B9FA02E7FA871AF938BD372436D827.

 

4.) Creación de una imagen DD, sin comprimir y sin trocear:

Ya me he aburrido de utilizar Guymager, así que me pasaré al lado oscuro, a la linea de comandos.  Utilizaré una herramienta de consola que también nos permite crear imágenes forenses tipo RAW (entre otras cosas) la herramienta se llama «dd«. Su uso es muy sencillo if=ORIGEN of=DESTINO. En este caso tomaremos de origen nuestra Evidencia 1 y de destino, un fichero almacenado dentro un disco duro local. ¡OJO! Si de destino le pasamos el punto de montaje de un disco, nos hará un clonado del origen destruyendo todo lo que teníamos en el disco de destino.

Fig.18 herramienta «dd»

 

Como en este caso no hemos utilizado el operador «pv» para saber cómo evoluciona el proceso de creación de imagen, un pequeño truco es ir a la carpeta de destino, e ir refrescando la carpeta para comprobar cómo el tamaño del fichero de destino va aumentando poco a poco.

Fig.19 Imagen con un tamaño de 973Mb

Fig.20 Imagen con una tamaño de 983Mb

 

Una vez termina el proceso de creación de imagen, con la herramienta sha1sum calculamos la firma digital del fichero creado, obteniendo el siguiente resultado:

Fig.21 Herramienta sha1sum

En este caso hemos creado con la herramienta «dd» una imagen forense tipo RAW sin trocear, el cálculo de la firma digital tipo SHA1 de este fichero nos arrojó un valor hash: A5D016A5D3B9FA02E7FA871AF938BD372436D827.

 

5.) Creación de una imagen EXX, sin comprimir y troceada.

Ahora ya me pongo en modo Pro, salgo del lado oscuro de la linea de comandos, recojo un poco la mesa, me visto la bata blanca 😉 y cambio el software libre por la herramienta comercial Encase de Guidance. Conecto la Evidencia 1 al host Windows en modo solo lectura, mediante un bloqueador físico y monto el disco a través de Encase.

Fig.22 Montaje de un dispositivo mediante Encase

 

Una vez montado, desde las opciones de adquisición que nos ofrece Encase, selecciono la opción de «imagen», desmarco la opción de compresión de la imagen, y compruebo que la adquisición se realizará desde el sector 0 hasta el último sector del disco físico, en este caso el sector 15730687. Por ejemplo, si en Encase hubiéramos seleccionado la primera partición o volumen lógico, en vez del disco físico, el primer sector de captura no sería el 0, si no que sería uno mayor.

Fig.23 Proceso de adquisición mediante Encase

 

Una vez termina la tarea de creación de imagen, en vez de confiar en el hash que nos arroja en ese momento Encase, cerramos el programa y vamos a la carpeta de destino de imagen, comprobamos como efectivamente tenemos dos archivos de imagen, uno de 655Mb y otro de 351Mb, la suma de ambos es de 1Gb, la prueba de que esta imagen no está comprimida.

Fig.24 Tamaño completo del fichero de imagen.

 

Ahora montamos de nuevo con Encase la imagen creada, y a través del menú correspondiente calculamos el hash SHA1 de la misma, obteniendo el siguiente resultado:

Fig.25 Hash del fichero de imagen sin compresión

 

En esta última prueba, hemos realizado la adquisición a través de un sistema Windows y el software comercial Encase, imagen que se realizó en formato EX sin comprimir. Posteriormente montamos la imagen creada, y calculamos la firma digital SHA1 obteniendo el resultado de: A5D016A5D3B9FA02E7FA871AF938BD372436D827.

 

6.) Restauración de una imagen troceada a un dispositivo físico.

Si no habéis tenido suficiente con todas estas pruebas que he hecho para comprobar lo manejables que son las imágenes forenses en contra de un clonado tradicional, os propongo una última demostración. Si bien puede ser cierto, que para un caso muy concreto nos puede interesar disponer de un clonado de disco, en vez de una imagen forense, por ejemplo para virtualizar mas fácilmente el sistema operativo capturado, no quiero decir con esto que una imagen no se pueda virtualizar, al contrario, se puede hacer perfectamente y es muy recomendable para ciertos análisis. Pero pongámonos en el caso de que necesitamos un clonado de un disco concreto y por ir de modernos solamente hemos hecho una imagen y ahora no tenemos el clonado. ¿Qué hacemos?, pues tan fácil como volcar el contenido de la imagen forense en un disco duro, el resultado será como si hubiéramos hecho un clonado desde el primer momento. ¿Seguro?, vamos a verlo:

Ya que he recogido la mesa y tengo encendido el equipo con Windows, vamos a realizar esta operación con Encase, de nuevo montamos la imagen forense en Encase, y a través del menú «restore» procedemos a realizar esta tarea.

En primer lugar seleccionamos el dispositivo de destino, es decir, el dispositivo en el que clonaremos nuestra Evidencia 1 en formato de imagen. ¡OJO! No nos vayamos a equivocar en este punto seleccionando otra unidad de disco, la evidencia original no la podemos dañar ya que es una imagen, pero sí que nos podemos zumbar tranquilamente nuestro sistema operativo o cualquier otro disco que tengamos conectado al sistema, así que hay que prestar especial atención a la hora de realizar la selección.

Fig.26 Selección de objetivo de destino en Encase

 

Nos puede ocurrir, que el disco duro sobre el que hemos realizado la imagen que vamos a restaurar, sea menor que nuestro disco de destino, por lo tanto nos quedarían una serie de bits al final del disco de destino sin escribir, lo que podría dar lugar a una contaminación, Encase evita este problema permitiéndonos wipear ese espacio de relleno, con el valor que nosotros deseemos, en este caso, todo ceros.

Fig.27 Wipeado del espacio sobrante

 

Seleccionaremos los sectores para que nos calcule el hash del clonado, como ya dije antes, hay que marcar el espacio correctamente, por ejemplo en la siguiente imagen he marcado incorrectamente los sectores, ya que comienza en el sector 2048, lo que viene siendo un volumen lógico y el hash tiene que ser de todo el disco, por lo tanto, cambiamos el 2048 por el 0.

Fig.28 Selección incorrecta del espacio para calcular el hash.

Fig.29 Selección correcta del espacio para calcular el hash

 

Encase, al igual que Guymager tiene un aviso para manazas, en el que nos avisa de lo que estamos a punto de hacer y nos pide que confirmemos si estamos seguros.

Fig.30 Aviso para manazas de Encase

 

Una vez termina el proceso, cerramos Encase y lo volvemos abrir para montar el dispositivo clonado, es decir, el disco al que hemos volcado la imagen, lógicamente este dispositivo lo hay que conectar al equipo bloqueado contra escritura. Como podéis ver en la siguiente imagen, el contenido del dispositivo se puede visualizar perfectamente.

Fig.30bis Dispositivo clonado, montado en solo lectura

 

Por ejemplo, si vamos al editor hexadecimal de Encase, seleccionamos el encabezado del disco, podemos comprobar cómo efectivamente está formateado en un sistema FAT32. Esta explicación aquí realmente no pinta nada, la pongo simplemente por postureo, es que no me digáis que una pantalla con mucho texto en hexadecimal y letras raras no le da un mayor empaque al artículo. 😉

Fig.31 Encabezado de un volumen lógico

 

Ahora, para enrevesar todavía más la práctica, nos vamos de nuevo a nuestro Deft Linux, conectamos en modo solo lectura el dispositivo al que hemos volcado la imagen forense, y con la herramienta sha1deep o dhash, calculamos la firma digital del contenido de este dispositivo.

Fig.32 Herramienta dhash

 

Como seguro que ya os imagináis, el resultado que nos arroja el cálculo del hash SHA1 del dispositivo en el que hemos volcado una imagen forense EX, que hemos obtenido de un otra imagen que había sido concatenada, que procedía de otra imagen que había sido troceada y comprimida, es el HASH SHA1: A5D016A5D3B9FA02E7FA871AF938BD372436D827. Por si no os fijasteis, este el mismo hash que nos ha estado dando en todas las operaciones que hemos realizado anteriormente, por lo tanto, no ha habido ningún tipo de alteración sobre la integridad de la evidencia.

Como veis, es indiferente el sistema utilizado para crear una imagen forense de un dispositivo, incluso, podemos utilizar las opciones de compresión sin miedo a alterar la firma digital de dicho fichero, podemos convertir esa imagen en un clonado, luego ese clonado lo podemos cambiar a otro tipo de imagen, podemos trocear la imagen, podemos volver a unir la imagen, la podemos copiar y pegar en todos los discos que queramos, la podemos montar con un software comercial y exportar a un software libre, que siempre, siempre, siempre, si no la hemos liado, la firma digital de la Evidencia será la misma.

Salu2

 

Continúa leyendo la Segunda parte de: El clonado ya no se lleva 2. PULSANDO AQUÍ.

 

¿Te ha gustado este artículo? Si quieres, puedes ayudarme a escribir el siguiente artículo de GLIDER invitándonme a un rico café.

 

Pulsa Aquí para invitarme a un café con hielo.

  Salu2.

Manuel Guerra

Mi nombre es Manuel Guerra. Investigador especializado en: [eCrime] | [Forensic] && [Hacking]. Editor de GLIDER.es

Navegación de la entrada


Comentarios

  • Raul

    Muy interesante. Gran trabajo. Muy currado Manu. Salu2

  • Sergio R.-Solís

    Un artículo genial, como de costumbre.
    Una preguntita: ¿Si se vuelca una imagen de tamaño X a un disco de tamaño Y (Y>X), cómo calculas el hash del disco para verificar que es igual que el de X? ¿Porque al calcular el resumen del disco se incluyen los 0’s, no?
    Entiendo que EnCase permite limitar a qué bytes se limita el cálculo del hash y así discriminar los 0’s del final, pero no se si es así con otras herramientas.
    Gracias

    • Manuel Guerra

      Hola Sergio!, creo que entiendo lo que me dices. Te refieres a que ocurre cuando clonamos (no hacer imagen) un disco duro en otro de mayor capacidad, si ese espacio de ceros que quedaría al final del todo influye al calcular el hash completo del disco de destino. Si es así, me alegra decirte que en la Parte II del articulo hablaré de ese tema 😉

      Un saludo.

      • Sergio R.-Solís

        En efecto. Me refería a clonar el disco A en un disco B de más tamaño que A. O más concretamente al caso que planteas de pasar una imagen de un tamaño determinado a un disco en el que le sobre espacio y comolete con 0s.
        En el fomdo es lo mismo. El origen puede ser disco o imagen, pero qué pasa cuando en el destino sobran sectores a la hora de calcular el hash. Como lo vas a comentar en “El Clonado ya no se lleva. El Retorno”, estaré pendiente 😉
        Gracias y un abrazo

  • Pedro

    Muy buen articulo!!!
    Enhorabuena.

  • Jimmy Olano

    Muy buen tema, ¡temazo!. Pues enhorabuena, y la segunda parte viene con UEFI como confirmásteis por Twitter, je je je ¡con «spoiler» y todo! ?

  • https://www.viagrapascherfr.com/viagra-et-diabete2/

    Excellent goods from you, man. I have understand your stuff previous to
    and you are just too magnificent. I really like what you have acquired here, certainly like what you are stating and
    the way in which you say it. You make it enjoyable and you still take care
    of to keep it smart. I can not wait to read far more from you.
    This is actually a terrific site.

  • estradiol 2mg

    Hello, I enjoy reading all of your article post. I like to write a little
    comment to support you.

  • Quique

    Buenos días Manuel.

    Respecto al bloqueador de escritura, ¿qué recomiendas para clonados «esporádicos»? He estado mirando precios y los bloqueadores tipo HW son bastante caros (la versión de Tableau para USB 3.0 son 450$ aprox), aunque luego hay otros más «asequibles».

    ¿Vale la pena HW o mejor preparar el sistema operativo que haga el clonado para que por defecto monte los discos en modo lectura?

    Un saludo y gracias por tu ayuda

    • Manuel Guerra

      Buenos días Quique. En teoría el bloqueo por SW es suficiente y válido, pero es mas propicio a que ocurra cualquier tipo de problema en su ejecución y no se bloquee adecuadamente, por eso siempre es recomendable los bloqueadores físicos, ya que bloquean siempre si o si. Si lo que necesitas es realizar adquisiciones muy esporádicas, lo puedes intentar por SW.

      Saludos

  • Pedro Martinez

    Soy perito informático , entonces …A fecha de hoy , para realizar un informe pericial judicial o de parte para el que se que se tenga que extraer toda la información del disco duro ¿ no es es obligatorio el clonado a un disco físico? Tenia entendido que siempre se debe hacer un clonado a un disco físico exactamente igual a través de clonadora hardware y a parte de una imagen.
    Pero leyendo esto llego a la conclusión de que tan solo con una imagen completa del disco seria suficiente.

    ¿Podría decir adios a mi clonadora hardware?

    • Manuel Guerra

      Buenas Pedro.

      En realidad una imagen o un clonado, a nivel judicial son exactamente igual. La diferencia es que a nivel técnico una imagen es mas eficiente ya que además de permitir comprimir los datos, permite trazar los datos, protección frente a errores, no se puede modificar fácilmente, y al ser un fichero, se puede guardar mas de una imagen en un mismo dispositivo de almacenamiento.

      Un saludo

Responder a Manuel Guerra ×

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puede usar las siguientes etiquetas y atributos HTML:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>