
Abogado que me lee — probablemente por primera vez, probablemente porque tu socio te mandó a investigar cómo cuestionar un peritaje informático que presentó la contraparte: lo que sigue en este artículo es el script que te va a hacer sonar como si llevaras diez años litigando con evidencia digital. No porque vayas a mentir sobre tu experiencia. Porque vas a hacer las preguntas correctas. Y las preguntas correctas, en un peritaje informático, son más devastadoras que cualquier alegato.
Voy a darte la pregunta exacta que destruye un peritaje. La vas a poder usar mañana en audiencia. Y el perito de la contraparte — si cometió el error que la mayoría comete — no va a tener respuesta. La pregunta es esta:
«Perito, antes de encender el dispositivo y comenzar su análisis, ¿calculó usted un valor hash del medio de almacenamiento original? Si es así, ¿qué algoritmo utilizó, cuál fue el valor obtenido y en qué momento de su procedimiento lo calculó?»
Si la respuesta es «no,» el peritaje es impugnable. Si la respuesta es «usé MD5,» el peritaje es cuestionable. Si la respuesta es vaga, evasiva o técnica sin sustancia, el peritaje tiene un problema.
Y te voy a explicar por qué. Con la precisión que necesitas para entenderlo, argumentarlo y ganarlo.
Llevo 17 años haciendo informática forense. He formado a más de 1,300 peritos en 10 países. He escrito 6 libros con ISBN sobre el tema. He participado como perito en más juicios de los que puedo contar. Y les soy franco: la cantidad de peritajes informáticos que llegan a los tribunales mexicanos sin un hash SHA-256 debidamente calculado es alarmante. No porque los peritos sean malos profesionales en todos los casos. Sino porque en México solo hay 14 peritos en las listas oficiales de toda la República — catorce –, y la mayoría de los dictámenes que se presentan en juicio los elaboran profesionales que no siguen los protocolos internacionales de forensia digital.
Objetar las pruebas es el tema más fino. Y este artículo te va a enseñar exactamente cómo hacerlo.
Qué es un hash y por qué es el fundamento de toda la cadena de custodia digital
Antes de decirte cómo destruir un peritaje, necesito que entiendas por qué el hash es tan importante. Porque si no entiendes el por qué, el argumento se convierte en un truco. Y un truco funciona una vez. Un argumento fundamentado funciona siempre.
Un valor hash es un número único que se genera matemáticamente a partir de un conjunto de datos. Es como una huella dactilar digital. Igual que no existen dos personas con la misma huella dactilar, no existen dos conjuntos de datos diferentes que generen el mismo hash. Si cambias un solo bit — un solo cero por un uno en la cadena de millones de bits que componen un disco duro –, el hash resultante es completamente diferente.
Voy a ponerte la analogía más simple que uso en mis cursos: el hash es el número de serie irrepetible de una pieza de evidencia digital. Cuando un perito llega a analizar un disco duro, lo primero que debe hacer — antes de abrir un solo archivo, antes de encender la computadora, antes de conectar nada — es calcular el hash del disco duro original. Ese hash es el número de serie que dice: «este disco duro, con este contenido exacto, en este momento, genera este valor.» Si más adelante alguien cuestiona si el perito alteró los datos, si agregó algo, si borró algo, si modificó la evidencia, el perito saca el hash original y el hash actual. Si son idénticos, los datos no fueron alterados. Si son diferentes, algo cambió. Punto. No hay discusión. No hay interpretación. Es matemática.
Eso es un hash. Y sin ese hash, la cadena de custodia digital no existe.
Abogado Jr. que está tomando notas: grábate esto. La cadena de custodia en evidencia física funciona con sellos, firmas, actas y testigos. La cadena de custodia en evidencia digital funciona con hashes. Un disco duro no se puede sellar con una firma como un sobre de evidencia. Se «sella» con un hash. Y si ese sello no existe desde el primer momento, cualquier cosa que se haga después con esos datos es cuestionable. Porque nadie puede demostrar que los datos que el perito analizó son los mismos datos que estaban en el dispositivo original.
SHA-256 vs MD5 vs SHA-1: no todos los hashes son iguales
Aquí es donde el argumento se afila. Porque no basta con que el perito haya calculado un hash. Importa qué algoritmo usó. Y la diferencia entre algoritmos no es académica — es la diferencia entre un peritaje blindado y uno que se puede tumbar.
MD5: el algoritmo que ya no sirve
MD5 fue el estándar durante años. Genera un hash de 128 bits. Fue creado en 1991 y durante mucho tiempo fue suficiente. Pero en 2004, un equipo de investigadores demostró que MD5 tiene colisiones: es posible crear dos archivos diferentes que generen el mismo hash MD5. No es trivial, no es algo que se haga por accidente, pero es posible. Y esa posibilidad, por sí sola, invalida a MD5 como garantía de integridad para fines forenses.
Lo que significa para tu caso: si el perito de la contraparte calculó un hash MD5, tu argumento es este — «El algoritmo MD5 ha sido demostrado vulnerable a colisiones desde 2004. Esto significa que dos conjuntos de datos diferentes pueden generar el mismo hash MD5, lo que impide garantizar con certeza que los datos analizados no fueron alterados. Los estándares internacionales de forensia digital recomiendan SHA-256 como mínimo. El perito utilizó un algoritmo que la comunidad científica internacional ha declarado insuficiente para garantizar la integridad de evidencia digital.»
No necesitas ser experto en criptografía para decir eso. Solo necesitas entenderlo. Y ahora lo entiendes.
SHA-1: mejor que MD5, pero también obsoleto
SHA-1 genera un hash de 160 bits. Es más robusto que MD5, pero en 2017, Google y el CWI de Amsterdam demostraron la primera colisión práctica de SHA-1. El proyecto se llamó SHAttered. Crearon dos archivos PDF diferentes con el mismo hash SHA-1. La vulnerabilidad es real, está documentada, y descalificó a SHA-1 como algoritmo de integridad para cualquier aplicación seria.
Si el perito usó SHA-1, el argumento es el mismo que con MD5, actualizado con la referencia a SHAttered y al año 2017.
SHA-256: el estándar actual
SHA-256 genera un hash de 256 bits. A la fecha no se ha demostrado ninguna colisión. No se ha encontrado ninguna vulnerabilidad práctica. Es el algoritmo recomendado por el NIST (National Institute of Standards and Technology) de Estados Unidos, por la ISO 27037 para manejo de evidencia digital, por la RFC 6234, y por prácticamente todos los organismos internacionales que emiten estándares de forensia digital.
Si el perito de la contraparte usó SHA-256 y lo calculó correctamente, ese aspecto del peritaje está blindado. Vas a tener que buscar los errores en otro lado. Pero — y esto es lo que veo con más frecuencia — la mayoría no usa SHA-256. La mayoría usa MD5 porque es lo que aprendieron, porque es más rápido de calcular, o porque simplemente no saben que MD5 ya no es suficiente.
Fiscal que presenta un dictamen con MD5: esto es exactamente lo que la defensa va a argumentar. Y va a tener razón. No porque el dictamen sea falso. Sino porque la integridad de la evidencia no se puede garantizar con un algoritmo vulnerable a colisiones. Es como presentar una prueba física con una cadena de custodia donde falta la firma de uno de los custodios. Quizás nadie alteró la evidencia. Pero no se puede demostrar.

Encender el dispositivo sin hash previo: cadena de custodia rota
Este es el error más grave y el más común. Y es, al mismo tiempo, el más fácil de detectar y el más difícil de justificar.
Cuando un perito recibe un dispositivo para análisis forense — un disco duro, una laptop, un celular, una USB –, el protocolo internacional es inequívoco:
Paso 1: Documentar el estado del dispositivo tal como se recibió. Fotografiar. Registrar marca, modelo, número de serie, estado físico.
Paso 2: Conectar el medio de almacenamiento a un bloqueador de escritura. Este es un dispositivo — hardware o software — que permite leer los datos del disco duro pero impide que se escriba absolutamente nada en él. Ni un bit. Ni un byte. Ni un log. Nada. El disco duro se queda exactamente como está.
Paso 3: Calcular el hash SHA-256 del medio de almacenamiento completo con el bloqueador de escritura conectado. Este hash se registra con fecha, hora, testigos si es posible, y se documenta en el dictamen.
Paso 4: Crear una imagen forense — una copia bit a bit del disco duro completo.
Paso 5: Calcular el hash SHA-256 de la imagen forense. Este hash debe ser idéntico al del disco original. Si coincide, la copia es perfecta. Si no coincide, la copia tiene un error y debe repetirse.
Paso 6: Trabajar exclusivamente sobre la imagen forense. Nunca sobre el original.
Ahora. Lo que debería pasar en el paso 2 — conectar un bloqueador de escritura antes de hacer cualquier cosa — es lo que no pasa en la mayoría de los peritajes que llegan a los tribunales mexicanos.
Lo que pasa en la realidad es esto: el perito recibe el dispositivo, lo enciende directamente, lo conecta a su computadora sin bloqueador de escritura, navega por los archivos, abre documentos, ejecuta programas, y después — si calcula un hash, que muchos no lo hacen — calcula el hash sobre un dispositivo que ya fue modificado por el simple acto de encenderlo.
Porque — y esto es clave para tu argumento — encender una computadora modifica el disco duro. Windows, al iniciar, escribe logs, actualiza archivos temporales, modifica registros del sistema, cambia marcas de tiempo. Cada una de esas operaciones altera los datos del disco. Y una vez que los datos se alteraron, el hash que calcules ya no corresponde al estado original de la evidencia. Corresponde al estado posterior a la intervención del perito.
Eso es cadena de custodia digital rota. Así de simple.
La pregunta que destruye: «Perito, ¿calculó usted el hash antes de encender el dispositivo? ¿Utilizó un bloqueador de escritura al momento de conectar el medio de almacenamiento?» Si la respuesta a cualquiera de las dos es no, tu siguiente argumento es: «Entonces no puede garantizar que los datos que analizó son los mismos datos que estaban en el dispositivo antes de su intervención. Su análisis se realizó sobre datos potencialmente alterados por la propia operación de encendido y conexión. La cadena de custodia digital está rota.»
Perito novato que lee esto y que ha estado haciendo exactamente lo que acabo de describir: no te estoy señalando para humillarte. Te estoy señalando para que corrijas. Porque si sigues presentando dictámenes sin hash SHA-256 previo al análisis, sin bloqueador de escritura, sin imagen forense verificada, vas a perder tu credibilidad profesional la primera vez que enfrentes a un abogado que sepa hacer las preguntas correctas. Y este artículo lo van a leer abogados.
Bloqueador de escritura: hardware vs software
El bloqueador de escritura merece una explicación propia porque es otro punto donde los peritajes fallan.
Hardware write blocker
Es un dispositivo físico — una caja que se conecta entre el disco duro y la computadora del perito. Funciona a nivel electrónico: permite que los datos fluyan del disco hacia la computadora pero bloquea físicamente cualquier señal que vaya en sentido contrario. Es como una válvula de un solo sentido. Los datos salen, pero nada entra.
La ventaja del bloqueador hardware es que su funcionamiento es independiente del software. No importa qué sistema operativo uses, no importa qué programa abras — el bloqueador hardware impide la escritura a nivel de señal eléctrica. Es la opción más confiable y la que los estándares internacionales recomiendan como primera opción.
Software write blocker
Es un programa que configura el sistema operativo para montar el disco duro en modo de solo lectura. Funciona, pero depende del software. Si el programa tiene un error, si el sistema operativo hace una excepción, si alguna configuración interfiere, existe la posibilidad — remota pero real — de que se escriba en el disco.
Para un peritaje que va a ser presentado en juicio, la recomendación es clara: bloqueador hardware. El software es aceptable en situaciones donde el hardware no está disponible, pero debe documentarse y justificarse.
Tu argumento como abogado: «Perito, ¿utilizó un bloqueador de escritura para garantizar la integridad del medio de almacenamiento original? ¿Era un bloqueador de hardware o de software? ¿Qué marca y modelo? ¿Cuál es la fecha de su última calibración o verificación?»
Si el perito no usó bloqueador, la cadena de custodia está comprometida. Si usó un bloqueador de software, puedes cuestionar su confiabilidad. Si no sabe qué marca o modelo, o si no puede documentar su uso, tienes un argumento procesal sólido.
Los 14 peritos y la realidad del peritaje en México
Hay un dato que necesitas saber para dimensionar el problema. En toda la República Mexicana, las listas oficiales de peritos en informática forense — las listas que los tribunales consultan para designar peritos — contienen aproximadamente 14 nombres. Catorce. En un país de 130 millones de personas, con un sistema de justicia que cada día depende más de la evidencia digital, hay 14 peritos registrados.
Eso no significa que solo haya 14 personas capaces de hacer informática forense en México. Significa que solo 14 están en las listas oficiales. El resto de los «peritos» que presentan dictámenes en los tribunales son ingenieros de sistemas, técnicos de cómputo, consultores de TI, académicos, o profesionales de otras áreas que se ofrecen como peritos en materia de informática sin necesariamente tener la formación, las herramientas, los protocolos ni la experiencia de campo que exige la forensia digital.
Y la mayoría de ellos no sigue los protocolos internacionales.
No calculan hash SHA-256 antes del análisis. No usan bloqueador de escritura. No crean imágenes forenses bit a bit. No documentan su metodología paso a paso. No preservan la cadena de custodia digital. Presentan dictámenes basados en capturas de pantalla, en lo que vieron al abrir archivos directamente en el dispositivo original, en conclusiones que no tienen sustento reproducible.
Digo, no es que sean charlatanes en todos los casos. Algunos son profesionales competentes en su área — sistemas, redes, programación. Pero la informática forense es una disciplina distinta. Así como un médico general no es un cirujano cardiovascular aunque ambos sean médicos, un ingeniero de sistemas no es un perito forense informático aunque ambos trabajen con computadoras.
Abogado Sr. que nunca ha cuestionado un peritaje informático: esto no es tu culpa. Es una laguna de conocimiento que comparte la inmensa mayoría de los abogados en México. Pero ahora que lo sabes, tienes la obligación profesional de cuestionar cada peritaje informático que llegue a tu escritorio. No aceptarlo como verdad porque «el perito es el experto.» El perito es el experto cuando sigue los protocolos. Cuando no los sigue, es un profesional que emitió un documento cuestionable.

El script completo: las preguntas que destruyen un peritaje mal hecho
Aquí está la secuencia completa de preguntas que, como abogado, puedes hacerle al perito de la contraparte en audiencia. Cada pregunta tiene un propósito específico. Las ordeno de la más suave a la más letal.
Pregunta 1 — Metodología general:
«Perito, ¿podría describir paso a paso la metodología que siguió para realizar su análisis?»
Propósito: obligar al perito a documentar su proceso. Si no tiene metodología sistemática, se va a notar. Si la tiene, te da el mapa de dónde buscar los errores.
Pregunta 2 — Hash previo al análisis:
«Antes de iniciar su análisis, ¿calculó usted un valor hash del medio de almacenamiento original? ¿Qué algoritmo utilizó? ¿Cuál fue el valor obtenido?»
Propósito: verificar si el perito garantizó la integridad de la evidencia antes de tocarla. Si no calculó hash, la cadena de custodia digital está rota.
Pregunta 3 — Algoritmo de hash:
«El algoritmo que utilizó, ¿ha sido declarado vulnerable a colisiones por la comunidad científica internacional?»
Propósito: si usó MD5 o SHA-1, la respuesta es sí. Y eso debilita la garantía de integridad.
Pregunta 4 — Bloqueador de escritura:
«¿Utilizó usted un bloqueador de escritura al conectar el medio de almacenamiento a su equipo de análisis? ¿Era hardware o software? ¿Qué marca y modelo?»
Propósito: verificar si el perito protegió el original contra alteraciones. Si no usó bloqueador, el solo acto de conectar el disco pudo haber modificado datos.
Pregunta 5 — Encendido del dispositivo:
«¿Encendió usted el dispositivo original antes de calcular el hash? Si es así, ¿es usted consciente de que el sistema operativo modifica archivos y registros al iniciar, lo cual altera el contenido del medio de almacenamiento?»
Propósito: esta es la estocada. Si encendió el dispositivo antes del hash, la evidencia fue alterada por la propia intervención del perito. El hash posterior no refleja el estado original.
Pregunta 6 — Imagen forense:
«¿Trabajó usted directamente sobre el dispositivo original o sobre una imagen forense? Si trabajó sobre una imagen, ¿el hash de la imagen coincide con el hash del original?»
Propósito: si trabajó sobre el original, cada operación de análisis modificó la evidencia. Si trabajó sobre una imagen pero los hashes no coinciden, la imagen no es fiel.
Pregunta 7 — Reproducibilidad:
«Si otro perito replicara su procedimiento con los mismos datos, ¿llegaría a las mismas conclusiones? ¿Puede garantizar que su análisis es reproducible?»
Propósito: la ciencia forense se basa en reproducibilidad. Si el procedimiento del perito no es reproducible — porque no documentó su metodología, porque no preservó los datos originales, porque trabajó directamente sobre el dispositivo –, su dictamen es una opinión, no un resultado científico.
Abogado Jr., memoriza estas siete preguntas. No todas van a aplicar en todos los casos. Pero cuando apliquen — y aplican con más frecuencia de la que imaginas –, van a hacer que tu socio Senior te mire diferente. Porque estas preguntas no se enseñan en la facultad de derecho. Se aprenden en la trinchera de los juicios donde la evidencia digital es decisiva.
Cuando el peritaje SÍ está bien hecho
Reitero: no todos los peritajes son malos. No todos los peritos cometen estos errores. Cuando un peritaje está bien hecho — hash SHA-256 calculado antes del análisis, bloqueador de escritura documentado, imagen forense con hash verificado, metodología paso a paso, conclusiones sustentadas en datos reproducibles –, ese peritaje es sólido.
Y si te enfrentas a un peritaje sólido, no intentes destruirlo con las preguntas que te di. Porque el perito va a responder correctamente a cada una, y tú vas a quedar como alguien que hizo las preguntas sin entender las respuestas. Las preguntas funcionan cuando el peritaje tiene errores. Cuando no los tiene, la estrategia es otra: cuestionar las conclusiones, no la metodología.
La diferencia entre un abogado que sabe usar estas preguntas y uno que no es la diferencia entre un abogado que entiende la evidencia digital y uno que le teme. Y un abogado que le teme a la evidencia digital en 2026 está en desventaja en la mayoría de los juicios que va a litigar.
Qué hacer ahora según quién seas
Abogado Jr. que quiere lucirse ante su socio: ya tienes las siete preguntas. Ahora necesitas saber cuándo usarlas. Revisas el dictamen pericial de la contraparte. Buscas tres cosas: mención de hash (con algoritmo específico), mención de bloqueador de escritura, y descripción de la metodología paso a paso. Si falta cualquiera de las tres, tienes un ángulo de impugnación. Se lo presentas a tu socio con la fundamentación que leíste aquí. Tu socio no va a saber esto. Tú sí.
Abogado Sr. que nunca cuestionó un peritaje informático: ahora sabes qué cuestionar. No necesitas ser experto en tecnología. Necesitas hacer las preguntas correctas. Y si el peritaje de la contraparte no resiste esas preguntas, necesitas un perito propio que presente un contrapericial hecho con los protocolos correctos.
Perito novato que no sigue estos protocolos: corrige. No mañana. Hoy. Porque la próxima vez que presentes un dictamen sin hash SHA-256, sin bloqueador de escritura, sin imagen forense, vas a encontrarte con un abogado que leyó este artículo. Y no va a ser agradable.
Fiscal que presenta dictamen con MD5: actualiza tu protocolo. MD5 fue suficiente en 2003. En 2026, ya no lo es. Y la defensa lo sabe.
Objetar las pruebas es el tema más fino de todo el litigio con evidencia digital. No es el más vistoso. No es el que gana titulares. Pero es el que gana juicios. Porque un peritaje informático puede decir lo que quiera — puede decir que el acusado es culpable, que el empleado robó información, que el socio defraudó, que la evidencia es contundente. Pero si ese peritaje no tiene hash SHA-256, si no usó bloqueador de escritura, si encendió el dispositivo antes de preservar la evidencia, todo lo que dice está construido sobre una base cuestionable.
Y una base cuestionable, en derecho, es una base impugnable. Y una prueba impugnable, en las manos de un abogado que sabe lo que está haciendo, es una prueba que se cae.
En Duriva, cada dictamen que emitimos lleva hash SHA-256 calculado antes del primer contacto con los datos. Lleva documentación del bloqueador de escritura utilizado. Lleva la verificación de la imagen forense contra el original. Lleva la metodología paso a paso que cualquier otro perito puede replicar para llegar a las mismas conclusiones. Porque un dictamen pericial no es una opinión con membrete. Es un documento científico que debe resistir el escrutinio más agresivo que un abogado pueda montarle.
Y si estás buscando a alguien que te ayude a destruir un peritaje mal hecho — o a construir uno que nadie pueda destruir –, esa es exactamente la asesoría técnico-jurídica que proporcionamos. Trata de buscar eso en internet. No hay. No hay porque la intersección entre quien sabe de forensia digital, quien sabe de derecho procesal y quien ha estado en suficientes audiencias para saber qué preguntas hacen la diferencia es extraordinariamente pequeña.
Catorce peritos en las listas oficiales de toda la República. Y la mayoría no sigue los protocolos internacionales. El diablo está en los detalles. Y los detalles, en un peritaje informático, son la diferencia entre una prueba que sostiene un caso y una prueba que se derrumba en audiencia.