Las wallets hardware como TREZOR ONE están diseñadas para proteger las claves incluso si alguien obtiene acceso físico al dispositivo. Aun así, en escenarios legítimos (pérdida de PIN, herencias digitales, peritajes o auditorías) es habitual preguntarse qué ocurre “por dentro” y por qué la recuperación del acceso es un proceso complejo.

Tratamos estos casos con un enfoque forense y legal, documentando cadena de custodia y valorando la viabilidad caso por caso, sin promesas irreales.

Montaje experimental

Mostramos un ejemplo del banco de pruebas utilizado en investigaciones de seguridad sobre TREZOR ONE:

• Un multiplexor analógico para provocar variaciones de señal.
• Un zócalo LQFP64 para el microcontrolador STM32.
• Un adaptador USB‑UART FT232H para comunicación con el cargador interno.
• Una placa FPGA Digilent Arty A7 utilizada para generar señales temporizadas.

Este tipo de instrumental no está al alcance del usuario medio y requiere formación en electrónica, microcontroladores y análisis de fallos físicos.

Niveles de protección (RDP) y Funcionamiento de la Memoria

El microcontrolador utilizado en TREZOR One implementa un sistema de seguridad basado en Readout Protection (RDP), un mecanismo diseñado para impedir la lectura directa de la memoria interna cuando el dispositivo cae en manos no autorizadas.

Este sistema se divide en tres niveles:

• RDP nivel 2 (por defecto en TREZOR)
  Es el estado más restrictivo. En este modo no se permite leer ni la SRAM ni la memoria FLASH mediante interfaces de depuración o programación. Está pensado para proteger completamente los secretos criptográficos del dispositivo frente a ataques físicos.
• RDP nivel 1
  En este nivel intermedio se autoriza el acceso a la memoria SRAM, pero la FLASH —donde se almacenan los datos críticos— continúa protegida.
• RDP nivel 0
  Es el modo sin protección: permite leer tanto la SRAM como la FLASH desde interfaces de depuración como JTAG, SWD o UART.

Desde el punto de vista forense, esta jerarquía es fundamental porque las claves que permiten reconstruir el acceso al monedero se encuentran almacenadas en la FLASH, la única memoria no volátil del dispositivo.

Esto significa que, mientras el chip permanezca en RDP 2 o incluso en RDP 1, la información más sensible sigue inaccesible por métodos convencionales. Cualquier intento de recuperación avanzada pasa necesariamente por comprender cómo se comporta el microcontrolador durante el arranque y cómo aplica estos niveles de protección.

Esta arquitectura es precisamente lo que convierte a las hardware wallets en dispositivos muy resistentes frente a accesos no autorizados… y también lo que hace que los procesos de recuperación legítima sean extraordinariamente complejos y reservados a laboratorios especializados.

Secuencia de arranque: tres fases críticas

Para comprender por qué un dispositivo como TREZOR resulta tan difícil de analizar físicamente, es imprescindible entender su cadena de arranque (boot chain). Cada fase se ejecuta de forma estrictamente controlada y activa distintos mecanismos de seguridad.

1️⃣ BootROM: el primer código que se ejecuta

Nada más aplicar alimentación al dispositivo, el microcontrolador ejecuta el BootROM, un código almacenado en memoria ROM interna e inalterable.

Sus funciones principales son:

• inicializar componentes básicos del chip,
• leer los parámetros de configuración de seguridad,
• aplicar los niveles de protección configurados,
• y verificar la integridad del sistema antes de permitir que continúe la ejecución.

Esta etapa es crítica porque es aquí donde se evalúan opciones como el nivel RDP y otros bits de protección grabados en áreas especiales de la FLASH.

2️⃣ BootLoader: decisión entre firmware o modo de depuración

Si el arranque continúa sin errores, el siguiente bloque en ejecutarse es el BootLoader.

Este componente decide si:

• cargar el firmware principal desde la FLASH,
• o entrar en un modo especial de depuración a la espera de órdenes externas desde un host.

Sin embargo, en condiciones normales este modo de depuración está bloqueado cuando el dispositivo se encuentra en RDP nivel 2, que es la configuración por defecto en TREZOR.

Por ello, el flujo habitual consiste en:

• comprobar nuevamente la integridad del sistema,
• y, si todo es correcto, arrancar directamente el firmware de usuario desde la memoria FLASH.

3️⃣ Firmware: la aplicación del usuario

La última fase del arranque es la ejecución del firmware residente en la FLASH.

Se trata del software visible para el usuario final:

• la interfaz gráfica,
• la gestión del PIN,
• las operaciones de firma de transacciones,
• y la interacción con el ordenador o el móvil.

Es precisamente en esta capa donde se aplican las protecciones frente a intentos repetidos de acceso, borrados automáticos y demás mecanismos de defensa diseñados para evitar ataques por fuerza bruta desde el exterior.

Esta cadena de arranque escalonada es uno de los pilares de la seguridad de TREZOR: cada fase hereda las restricciones de la anterior y solo permite avanzar si las comprobaciones se superan correctamente.

El papel crítico del BootROM y la investigación mediante fault injection

Dentro de la cadena de arranque del TREZOR One, el BootROM es la fase más sensible desde el punto de vista de la seguridad… y también la más interesante para investigadores y laboratorios forenses.

Durante su ejecución inicial, este código inmutable:

• lee los parámetros de configuración de seguridad del microcontrolador,
• consulta una región especial de la FLASH conocida como Option Bytes,
• y aplica las políticas de protección establecidas antes de permitir que continúe el arranque.

Entre esos parámetros, el más relevante es el Readout Protection (RDP).

En los dispositivos TREZOR este valor se encuentra configurado por defecto en nivel 2, el estado más restrictivo. Una vez fijado oficialmente en ese nivel, el fabricante del microcontrolador no contempla mecanismos estándar para reducirlo a RDP 1 o RDP 0, lo que impide el acceso normal a interfaces de depuración y a la memoria interna.

Sin embargo, desde el ámbito académico y de investigación en hardware security se ha demostrado que, bajo condiciones muy concretas de laboratorio, es posible intentar alterar momentáneamente la lectura de estos parámetros durante el arranque mediante técnicas conocidas como fault injection.

Interfaces de depuración y comandos utilizados en laboratorio

Cuando, en un entorno controlado, se consigue que el microcontrolador arranque temporalmente en un nivel de protección inferior al previsto, el BootLoader habilita determinadas interfaces de servicio como UART, JTAG o SWD.

Estas interfaces están pensadas originalmente para fabricación y diagnóstico, pero en investigación de seguridad permiten interactuar con el chip a bajo nivel.

En el caso analizado, la comunicación se establece habitualmente por UART, ya que ofrece una sincronización suficientemente precisa para coordinar perturbaciones temporales durante la ejecución del firmware interno.

Lectura de memoria y control dinámico del RDP

Entre los comandos disponibles en ese modo restringido destaca uno destinado a lectura de memoria, conocido internamente como Read Memory.

Este comando verifica en cada invocación el nivel actual de protección RDP antes de permitir el acceso a una región concreta del mapa de memoria.

Aquí entra en juego un segundo momento crítico: mediante una nueva perturbación temporal durante esa comprobación, algunos estudios han demostrado que es posible inducir al sistema a comportarse como si se encontrara en un nivel inferior de protección, permitiendo así la lectura de regiones normalmente inaccesibles, como la memoria FLASH.

Si la perturbación no se produce en el instante adecuado, el sistema responde con un mensaje de error (NACK), indicando que la operación no está autorizada.
Cuando la sincronización es correcta, el comando devuelve una confirmación (ACK) y entrega el bloque solicitado.

Desde un punto de vista forense, uno de los mayores retos consiste precisamente en calcular y repetir de forma fiable ese intervalo temporal, midiendo cuánto tarda el microcontrolador en responder ante un intento fallido y ajustando la inyección de fallos hasta encontrar la ventana válida.

Volcado progresivo de la memoria FLASH

Las lecturas se realizan en bloques pequeños —habitualmente del orden de cientos de bytes—, por lo que el proceso completo implica repetir el ciclo miles de veces hasta reconstruir todo el contenido de la FLASH.

En términos conceptuales, el flujo de trabajo en laboratorio consiste en:

• inducir el estado de protección reducido durante el arranque,
• solicitar la lectura de una dirección concreta,
• provocar la perturbación en la comprobación del nivel RDP,
• almacenar el bloque recuperado,
• avanzar a la siguiente región de memoria,
• y reiniciar el proceso si alguna de las fases falla.

Dada la complejidad y la necesidad de precisión en microsegundos, este tipo de tareas suele apoyarse en automatización mediante scripts y hardware externo especializado, capaces de reiniciar el dispositivo, disparar los pulsos eléctricos y coordinar las lecturas de forma repetitiva.

Esta etapa es una de las más delicadas de todo el proceso: cualquier desviación en la temporización hace que el microcontrolador vuelva a su estado protegido y obligue a comenzar de nuevo.Es importante destacar que este script de automatización no es público: suele ser una herramienta interna del laboratorio, ajustada a su instrumentación, a su metodología de pruebas y a sus controles de trazabilidad. En un contexto pericial, además, forma parte del know-how y de la cadena de custodia del proceso.

Lectura de OTP y obtención del hardware salt

Además del volcado de la memoria no volátil principal, el análisis requiere extraer y procesar también la región OTP (One-Time Programmable) del microcontrolador. Esta zona contiene valores únicos grabados en fábrica y es donde se encuentra el material necesario para reconstruir el hardware salt, que actúa como componente esencial en la derivación de claves internas.

En términos técnicos:

• La hardware salt ocupa 44 bytes.
• Normalmente se localiza dentro de los primeros 64 bytes del área OTP.
• El tamaño total de OTP puede alcanzar hasta 528 bytes, dependiendo del microcontrolador y su configuración.

Una vez extraído el contenido OTP, el laboratorio calcula un hash criptográfico (por ejemplo, SHA-256) y lo combina con el salt dinámico recuperado desde la FLASH para construir el salt ensamblado, que se utiliza en las fases posteriores de verificación criptográfica.

Como se realiza el proceso de Fuerza Bruta Controlada.

El trezor internamente usa una combinación de llaves y claves, que aplicando distintos algoritmos de cifrado se descifran entre si  y ese resultado final comprueba si el PIN introducido es el correcto.

Trezor organiza su almacenamiento en “entries”, la entrie en la FLASH que guarda lo que necesitamos se encuentra con el “app-value” de 0 y el “key-value” de 2. Se puede localizar esta entrada ya que siempre comienza con los bytes “02 00 3C 00”. Esa entrada en total son 64 bytes. La idea es ir recorriendo todo el dumpeo de la flash hasta encontrar esa entrada comparando si los bytes son “02 00 3C 00”.

Una vez hemos localizado esa entrada, en su interior se encuentra:
-Salt (aleatoria cada booteo), primeros 4 bytes.
-EDEK (Encrypted Data Encrypted KEY) + ESAK (Encrypted Storage Authentication Key), siguientes 48 bytes.
-PVC (PIN Verification Code), últimos 8 bytes.

El siguiente paso es obtener la hardware salt real, eso se consigue aplicándole SHA256 a los bytes OTP que hemos leído anteriormente.

Para obtener la Assembled salt, que es la que usaremos para derivar las demás claves, le sumamos la Hardware Salt a la salt de la Flash.

Assembled salt = Hardware salt (SHA256(OTP)) + salt (FLASH).

A partir de ahora cada vez que me refiera a la salt, en realidad me refiero a la Assembled salt.

Lo siguiente sería añadirle un prefijo de “1” al PIN para hacerlo little endian, por ejemplo si el PIN es “7408” le añadimos un prefijo de “1” → “17408”, a este PIN lo llamaremos PIN-bytes.

Después obtenemos la DK, para ello aplicamos el algoritmo pbkdf2_hmac, con SHA256, a los PIN-Bytes y la salt.

Ahora tenemos que obtener el KEK y el KEIV.
El KEK son los primero 32 bytes de dk y el KEIV son los siguientes 12 bytes a partir de esos 32.

Solo faltaría obtener el DEK, para ello tenemos que descifrar el EDEK usando el KEK y el KEIV.
Aplicamos el algoritmo ChaCha20_Poly1305 al EDEK usando la key KEK y el nonce KEIV.

Por último comprobamos si todos los bytes del PVC está en orden en los bytes del TAG, de ser así, el pin que hemos probado sería correcto:

Una vez entendido el flujo de verificación, el enfoque en laboratorio consiste en probar de forma sistemática todas las combinaciones posibles dentro del espacio de búsqueda definido. Por ejemplo, si el PIN es numérico de 4 dígitos, el conjunto potencial abarca desde 0000 hasta 9999.

Para cada candidato, se reproduce offline la misma cadena criptográfica (derivación de claves + comprobación del valor de verificación) y se marca como válido únicamente aquel que supera la verificación interna. De esta forma, la comprobación se realiza sobre los datos extraídos, sin interactuar con el dispositivo en modo usuario y sin depender de límites de intentos del firmware.

Esto significa que la verificación del PIN se basa en procesos criptográficos, no en una comparación simple tipo “PIN correcto/incorrecto” guardado en memoria.

Fuerza bruta: el mito del “PIN de 4 dígitos”

Aunque un PIN parezca “corto”, el sistema está diseñado para que probarlo de forma masiva no sea inmediato, porque:

• hay pasos de derivación que consumen recursos,
• intervienen valores internos ligados al dispositivo,
• y la validación final depende de verificaciones criptográficas.

Por eso, incluso con acceso a ciertos datos, hablar de “probar 0000–9999” como si fuese trivial suele ser una simplificación que no refleja la realidad de laboratorio.

Expectativas realistas y recomendaciones

• ✅ La frase semilla (seed phrase) sigue siendo el mecanismo estándar y recomendado para recuperar fondos.
• ❌ No existe un método universal, rápido y garantizado para “sacar el PIN” de una TREZOR.
• ⚠️ La manipulación física avanzada implica riesgo real de pérdida total del dispositivo.

¿Has perdido el acceso a una wallet TREZOR?

Realizamos evaluaciones de viabilidad con enfoque forense:

• autorización y documentación,
• análisis técnico realista,
• confidencialidad y trazabilidad.

👉 Solicita una evaluación inicial y te diremos qué opciones existen en tu caso concreto.

La entrada Recuperación de acceso en wallets TREZOR: Análisis Forense Profesional se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Dos de las más relevantes son CMR (Conventional Magnetic Recording) y SMR (Shingled Magnetic Recording). En este artículo vamos a explicar qué significa cada una, cuáles son sus ventajas y desventajas, y en qué casos conviene elegir una sobre la otra.

¿Qué es la tecnología CMR (Conventional Magnetic Recording)?

La tecnología CMR es la forma tradicional de grabación magnética en discos duros. Las pistas de datos se escriben de forma paralela, sin solaparse, lo que garantiza un acceso rápido y constante tanto en lecturas como en escrituras.

✅ Ventajas del CMR

• Rendimiento consistente en lecturas y escrituras.
• Excelente manejo de escrituras aleatorias.
• Total compatibilidad con RAID y sistemas NAS.
• Ideal para entornos de trabajo intensivo.

❌ Desventajas del CMR

• Menor densidad de almacenamiento por plato.
• Precio por terabyte más elevado comparado con SMR.

🔧 Usos recomendados del CMR

• Servidores de bases de datos.
• Sistemas NAS de uso profesional y doméstico intensivo.
• Estaciones de trabajo con aplicaciones críticas.

¿Qué es la tecnología SMR (Shingled Magnetic Recording)?

El SMR organiza los datos de forma solapada, similar a como se colocan las tejas en un tejado. Esto permite aumentar la capacidad de almacenamiento en el mismo espacio físico.

✅ Ventajas del SMR

• Mayor densidad → discos de alta capacidad.
• Precio por terabyte más bajo.
• Muy buen rendimiento en lecturas secuenciales (ejemplo: copia de archivos grandes).

❌ Desventajas del SMR

• Escrituras aleatorias más lentas, porque requieren reescribir varias pistas.
• No recomendado para configuraciones RAID dinámicas.
• Rendimiento inconsistente en cargas intensivas.

🔧 Usos recomendados del SMR

• Almacenamiento de copias de seguridad (backups).
• Bibliotecas de archivos multimedia (fotos, vídeos, música).
• Almacenamiento de datos fríos (poco acceso, solo lectura).

Comparativa: SMR vs CMR

SMR vs CMR: ¿Cuál elegir para tu proyecto?

La elección entre SMR y CMR depende de las necesidades concretas de cada usuario:

• Si buscas rendimiento estable, velocidad constante y compatibilidad total, elige CMR.
• Si lo que necesitas es gran capacidad de almacenamiento a menor costo y tu carga de trabajo es mayormente de lectura, entonces SMR es la opción ideal.

En resumen:

• CMR = estabilidad, fiabilidad y rendimiento.
• SMR = capacidad y ahorro para almacenar más datos con menos inversión.

Preguntas frecuentes sobre SMR y CMR

¿Cómo saber si mi disco duro es SMR o CMR?

Los fabricantes como Western Digital, Seagate o Toshiba suelen especificarlo en sus fichas técnicas. También existen bases de datos online que permiten verificar el modelo exacto.

¿Puedo usar discos SMR en un NAS?

Sí, pero no es recomendable si el NAS estará sometido a escritura intensiva o configuraciones RAID. En ese caso, CMR es más adecuado.

¿Qué tecnología es mejor para copias de seguridad?

El SMR es ideal para backups gracias a su alta capacidad y bajo coste por TB, siempre que las escrituras no sean constantes.

La batalla SMR vs CMR no tiene un ganador absoluto: todo depende del uso que vayas a dar al disco duro.

• CMR es perfecto para profesionales, servidores, NAS y aplicaciones exigentes, donde la estabilidad del rendimiento es clave.
• SMR es la mejor opción para quienes necesitan grandes volúmenes de almacenamiento a bajo costo, especialmente para archivos multimedia y datos que rara vez se modifican.

Con esta comparativa ya puedes elegir la opción que más se adapta a tus necesidades, evitando sorpresas y asegurando que tu inversión en almacenamiento sea la correcta.

La entrada SMR vs CMR: Diferencias, ventajas y desventajas de cada tecnología de disco duro se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Entonces, ¿qué es eso y cómo funciona?

TRIM es un comando SSD de hardware interno que funciona en pareja con el Sistema Operativo. Por defecto, TRIM se integró completamente en todo el sistema operativo a partir de Windows Vista SP1, Windows 7 y MacOS X 10.6 (aproximadamente de 2009-2010).

Sabemos que el chip de memoria NAND puede escribir y leer información extremadamente rápido. Pero REESCRIBIR va a ser extremadamente lento porque la memoria NAND tiene que:

1. Encuentra el lugar donde escribir nuevos datos;
2. Borrar los datos antiguos (llene las células NAND por ceros);
3. Haz una operación de escritura.

Para evitar este procesamiento lento, los desarrolladores de SSD deciden añadir un comando TRIM (un colector de basura) que en el fondo borra todos los datos que se marcó como eliminados. Ayuda a ahorrar tiempo en el futuro, cuando el usuario decide escribir nuevos datos en el lugar que ya era TRIMed y limpiado. Cómo el SSD sabe qué datos deben ser TRIMed? Bueno, el Sistema Operativo le dice a la unidad qué datos fueron marcados como «BORRADOS», y SSD simplemente borra los bloques que pertenecen a esas áreas eliminadas.

Esta Imagen muestra que todos los ficheros recuperados después del borrado están corruptos y ha Cero después del TRIMed.

A veces el SSD puede hacer una cosa aún más fácil en caso de formato rápido, la SSD simplemente borra el microprograma principal del traductor que cambia el sectores físicos a lo lógico.

Como resultado, el SSD devuelve sólo CEROS al intentar leer cualquier dato de ella (el traductor de la parte lógica no sabe nada de datos físicos anteriores, por lo que se lee sólo ceros).

Lo mismo ocurre con las cámaras digitales con las tarjetas mSD, SD y CF cuando las formatea a través de Digital Camera por error. Y en la recuperación de RAW no se puede encontrar nada porque el traductor ha sido borrado, y la nueva versión de traductor no se preocupa de leer ningún dato antiguo.

Con nuestros métodos para leer la memoria NAND de mSD/SD, USB y reconstruir la imagen. Entonces sería posible ver los datos en RAW y a veces incluso construir una imagen con estructura completa o parcial de carpeta.

Pero para SSDs chip-off no funciona porque todas las SSD modernas contienen cifrado de hardware completo o XOR adaptativo con la compresión de datos, por lo que no veremos ningún dato dentro del NAND antes de la descifrado.

¿Recuerdas los viejos buenos días cuando el cliente te trae un disco duro con formateado y pide recuperación? Desafortunadamente, estos días se han terminado, porque incluso los discos duros clásicos basados en la tecnología Shingle Magnetic Record (SMR) también están utilizando el TRIM. Como resultado, después de un formato rápido, el traductor se borra, y obtendrá sólo ceros en lugar de datos reales. Por eso nosotros disponemos de alta tecnología para poder recuperar estos datos afectados por el TRIM.

Así que imaginemos que se hizo un formateo de un SSD por error, y ahora queremos recuperar datos. ¿Será posible hacerlo? Depende de cosas como: capacidad de conducción, número de datos escritos en la unidad, etc. Por lo general, se tarda entre 10 minutos y 24 horas antes de que la unidad afectada quede totalmente borrara y sea irrecuperable.

Los controladores SSD modernos tienen una estructura multicore, que les permite hacer algunas cosas al mismo tiempo. Por ejemplo, cuando estés tratando de escanear la unidad y encontrar al menos algo en RAW , otro núcleo de CPU continuará el proceso de fondo y todos los datos seguirán borrándose.

Lo principal que debe recordar es TRIMing the data, afecta incluso si simplemente se enchufó a una fuente de alimentación la unidad SSD. no vasta con desconectar el cable SATA, hay que dejarlo sin alimentación.

La inicialización y el procesamiento de la unidad de conducción por defecto

La única manera de evitar que el TRIM es deshabilitando el acceso desde CPU a chips NAND. ¿Cómo podemos hacer eso? La única manera es poner la unidad en SAFE MODE – nos ayudará a desactivar cualquier acceso a los chips NAND y mantendrá la unidad para operar en modo CPU-RAM solamente. Por lo tanto, podríamos escribir algo en RAM o leer información del chip de memoria RAM, pero sería imposible influir en los chips NAND.

Ejemplo de SAFE MODE en la unidad HP EX900 M.2 NVMe

Esquema de MODE SAFE sobre cualquier SSD

Ahora, necesitamos un carro de un pequeño firmware especificado y optimizado que fue hecho por los desarrolladores de ACELab. Es algo así como un pequeño firmware compatible con el controlador de destino, donde los desarrolladores de ACELab apagaron completamente todas las actividades de fondo y desbloquearon algunas características adicionales que previamente habían sido bloqueadas. Si tenemos una Utilidad compatible, podemos tratar de cargar la cargadora en la memoria RAM de la unidad, y tener acceso al Modo Techno de la SSD actual. A continuación, trate de reconstruir el traductor usando una copia antigua de ella, y subirla en la memoria RAM de la unidad. Después de eso, podríamos tratar de acceder a los datos en Data Extractor usando un cargador personalizado que hicimos antes. En este caso, la unidad funcionará en modo de un solo canal lentamente, pero sin actividad de fondo.

Esquema de Modo Techno tras la subida de la cargadora

Ahora vamos a resumir la información:

1. TRIM funciona muy rápido. Si algo fue borrado o la unidad fue formateada, usted solo dispone de unos minutos a unas pocas horas antes de que los datos se hayan ido para siempre.
2. No enchufe la unidad a una fuente de alimentación. Cualquier conexión de accionamiento para más investigación (a través de SATA, M.2, USB, etc.) será una causa de la funcionalidad TRIM en CPU SSD.

Estamos comprobando el contenido de esta unidad, y está lleno de datos de los usuarios. Algunos videos, fotos, documentos, todo lo que un cliente al azar está usando diariamente.

Ahora, vamos a tratar de formatear esta unidad con un botón de formato rápido en Windows;

En la Utilidad Universal y en el Extractor de datos sólo veremos ceros, porque está utilizando el traductor de la unidad nativa y es uno nuevo que se hizo después de un formato de unidad rápida.

Cero en lugar de datos en Universal Utilidad en LBA 1 232 134

Partición vacía después del formato de unidad

RAW no tiene ningún dato antiguo. Sólo un nuevo NTFS registros después de la partición formatear

No tenemos mucho tiempo ahora, porque cuanto más escaneemos la unidad, más bloques serán borradas en el fondo. Tenemos que tener prisa para poner la unidad en un MODE DE SAFE. Este truco nos ayudará a desactivar las fichas NAND de la CPU.

El SSD tiene que estar en un MODE SAFE todo el tiempo.

Usamos la Utilidad compatible para SM2259XT y subir el cargador para activar las funciones extra de la unidad.

A veces necesitamos seleccionar el cargador compatible manualmente

Cuando la unidad complete la inicialización, será posible iniciar el proceso de construcción del traductor. La unidad escaneará el Área de Servicio, tomará algunos módulos SA importantes que contienen información sobre sectores reasignado, eliminado, malo y bueno, y hará un nuevo traductor en modo automático.

El traductores está listo. Adelante para la extraccion de datos.

Cuando todo esté listo, antes de hacer una imagen de la unidad, vamos a comprobar primero el LBA 1 232 134 que fue llenado por ceros después del formato de unidad. Ahora, contiene datos.

Después de la creación del nuevo traductor, LBA 1 232 134 contiene datos, no hay ceros.

Y por supuesto, tenemos que usar la recuperación RAW para ver los archivos. Si conseguimos algunos empezamos con la imagen completa.

Ahora, en RAW vemos muchos datos justo después de 1 000 000 LBA .

Como puede ver, RAW está lleno de datos. Desafortunadamente, a veces la Estructura de carpetas no es posible por el daño de la estructura y el Zero Block que incluye información sobre los sectores del Master Boot y BOOT. Sin esta información El sistema de archivos estará ausente.

Resultado después de sólo el 10% de la escaneo RAW, un montón de archivos todavía están en la SSD

TRIM. Resumamos la información más crítica una vez más:

• TRIM se cambia por defecto en cada sistema operativo y en cada SSD desde 2010.
• Los datos se convierten en TRIMed de 1 minuto a 24 horas (dependiendo de la capacidad de conducción y la cantidad de datos eliminados).
• Incluso un formato rápido causará el borrado de un traductor. Todos los datos se mostrarán como CEROS al extraer datos.
• La única manera de evitar TRIM – apagar la unidad de la fuente de energía o mantenerla en SAFE MODE permanentemente.
• Todavía es posible recuperar datos después de su eliminación o formatear SSD, Contactanos.

La entrada Recuperación de Datos en SSD Después del un Borrado Accidental o Formateo se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

• Qualcomm Snapdragon 710;
• Qualcomm Snapdragon 845;
• Mediatek MT6789 (Helio G99) (OUKITEL) (B52B1D46);
• Mediatek MT6789 (Helio G99) (TECNO) (BE13371A);
• Mediatek Dimensity 8100/8050 (MT6895) (for Infinix);
• Mediatek Dimensity 9000/9000+;
• Unisoc T618 Memory Type 2;
• Unisoc T603;
• Unisoc T615;

Lista de nuevos teléfonos Soportados:

• ALLDOCUBE iPlay 50 Pro (MediaTek Helio G99);
• BlackView Oscal C80 (Unisoc Tiger 606);
• Cubot P40 (MediaTek MT6761 A22);
• HISENCE/AGM A9 (Qualcomm Snapdragon 450);
• HTC Desire 10 Pro (MediaTek Helio P10);
• Huawei Y6 Prime (2018) (ATU-L42) (Qualcomm Snapdragon 425);
• Huawei Y6s (JAT-LX1) (MTK Helio P35);
• IIIF150 B2 Pro (MediaTek Helio G99);
• Infinix HOT 11s NFS (x6812B) (MediaTek Helio G88);
• Infinix HOT 20 (x6826B) (MTK Helio G85);
• Infinix Hot 40 (x6836) (MediaTek Helio G88);
• Infinix Hot 40i (x6528B) (Unisoc T606);
• Infinix Note 12 G88 (x663D) (MediaTek Helio G88);
• Infinix Note 30i (x6716) (MediaTek Helio G85);
• Lenovo Pad M8 Gen 4 (TB300FU) (MediaTek MT6761 A22);
• Neffos C7 Lite (TP7041A) (MTK MT6739);
• Nokia 2.4 (TA-1270) (MediaTek Helio P22);
• Nokia 5 TA-1024/TA-1053 (Qualcomm Snapdragon 430 MSM8937);
• Nokia C20 (TA-1339) (Unisoc SC9863A);
• Nokia G21 (TA-1418) (Unisoc T606);
• ONE PLUS 6 (Qualcomm Snapdragon 845);
• Oppo A31 (MediaTek MT6765);
• OPPO A38 (CPH2579) (MediaTek Helio G85);
• OPPO A73 5G (CPH2161) (Dimensity 720);
• OPPO K10 China ( MTK Dimensity 8100);
• Oukitel RT1 (MediaTek Helio P22);
• Oukitel RT5 (MT6771);
• Oukitel RT7 (MediaTek MT6771);
• Oukitel Titan RT7 (MediaTek MT6771);
• Pixus Titan (MediaTek Helio G99);
• Realme 6i (RMX2040) (MediaTek Helio G80);
• Realme C25 (RMX3191) (MediaTek Helio G70);
• Realme C25Y (RMX3269) (Unison T610);
• Realme C30 (RMX3581/RMX3623) (Unisoc T612);
• Realme C61 (RMX3930) (Unisoc T612);
• Redmi 6 (M1804C3DG) (MTK Helio P35);
• Redmi A3x (24048RN6CG)(Unisoc T603);
• Redmi K40 Gaiming (M2012K10C, M2012K10I) (MTK Dimensity 1200);
• Samsung Galaxy A05 (SM-A055F) (MediaTek Helio G85);
• Sony Xperia XA1 (G3412) (MediaTek Helio P20);
• Necno SPARK Go 1 (KL1) (Unisoc T615);
• TECNO Camon 19 Neo (CH6i) (MediaTek Helio G85);
• Tecno Pova 2 (MediaTek Helio G85);
• Tecno SPARK 20 (KJ5n) (MediaTek Helio G85);
• Tecno Spark 7P (MediaTek MT6761/MT6761D);
• Tecno Spark Go 2024 (BG6) (Unisoc T606);
• Ulefon Armor 8 Pro (MediaTek Helio P60 MT6771);
• Umidigi Bison GT2 5G (MediaTek MT6877);
• VIVO V17 Neo V1907/VIVO S1 (MTK MT6768);
• VIVO V7 Plus (Qualcomm Snapdragon 450);
• VIVO X80 (PD2183F) (Dimensity 9000/9000+);
• VIVO Y17 (Test Point) (MediaTek Helio P35);
• VIVO Y17 (MediaTek Helio P35);
• VIVO Y19 (MediaTek MT6768);
• Xiaomi Mi 9 Lite (Qualcomm Snapdragon 710);
• Xiaomi Redmi 13 (24040RNB64Y) (MTK Helio G91);
• Xiaomi Redmi 9A (M2006C3LG) Test Point (MediaTek Helio G25);
• Xiaomi Redmi Note 11 Pro Global (2201116TG) (MediaTek MT6781 Helio G96);
• ZTE Blade A3 2020 (SPREADTRUM SC9832E);
• ZTE Blade A31 Lite RU (UNISOC SC9832E);
• ZTE blade A51 Lite (SPREADTRUM SC9863A);
• ZTE Blade V2020 (8010RU) (Spreadtrum SC9863A);

La entrada Nuevos teléfonos soportados por nuestro laboratorio para la recuperación de datos con extraccion de cifrado se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

La entrada Nuevos teléfonos soportados por nuestro laboratorio para la recuperación de datos con extraccion de cifrado se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

La entrada Nuevos teléfonos soportados por nuestro laboratorio para la recuperación de datos con extraccion de cifrado se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

• MT6895 (Dimensity 8100/8050) (Infinix phones)
• Unisoc Tiger T618 (Memory Type 2)
• Qualcomm Snapdragon SDM 710

Lista de teléfonos añadidos:

• Xiaomi Mi 9 Lite (Qualcomm Snapdragon 710)
• Huawei Y6 Prime (2018) (ATU-L42) (Qualcomm Snapdragon 425)
• HTC Desire 10 Pro (MediaTek Helio P10)
• Realme 6i (RMX2040) (MediaTek Helio G80)
• Lenovo Pad M8 Gen 4 (TB300FU) (MediaTek MT6761 A22)
• Cubot P40 (MediaTek MT6761 A22)
• Xiaomi Redmi Note 11 Pro Global (2201116TG) (MediaTek MT6781 Helio G96)
• ZTE Blade A3 2020 (SPREADTRUM SC9832E)
• Xiaomi Redmi 9A (M2006C3LG) Test Point (MediaTek Helio G25)
• Oppo A31 (MediaTek MT6765)
• BlackView Oscal C80 (Unisoc Tiger 606)
• TECNO Camon 19 Neo (CH6i) (MediaTek Helio G85)
• OPPO A38 (CPH2579) (MediaTek Helio G85)
• Infinix Note 12 G88 (x663D) (MediaTek Helio G88)
• VIVO Y19 (MediaTek MT6768)

La entrada Nuevos teléfonos soportados por nuestro laboratorio para la recuperación de datos con extraccion de cifrado se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Nos complace anunciar una actualización de Visual NAND Reconstructor 9.0, que incorpora nuevas funciones que mejoran enormemente la precisión y la eficiencia de la recuperación de datos NAND.

A continuación, se incluye la lista completa de nuevas funciones:

Soporte de pseudo-SLC block

La nueva función SLC mejora significativamente la reconstrucción de imágenes lógicas (¡especialmente para los controladores Sandisk!) y, sin la opción de relectura de SLC, muchos casos complejos requerirían técnicas de ensamblador o recuperador de archivos en lugar de depender de la estructura del sistema de archivos.

Esta actualización presenta compatibilidad total con la relectura de bloques pSLC (celda pseudo de un solo nivel), lo que mejora significativamente la precisión del ensamblaje del sistema de archivos al releer completamente los bloques SLC, que contienen datos del sistema de archivos y en caché.

Además, hemos reestructurado la forma en que se procesan los volcados y los bloques, mejorando el rendimiento y la eficiencia. El software ahora separa automáticamente los volcados completos en bloques de datos y SLC, lo que agiliza el proceso. Los bloques pSLC se convierten en bloques normales, al tiempo que se conserva su tipo para operaciones XOR posteriores y otras operaciones.

Tenga en cuenta que, por ahora, el usuario debe cambiar manualmente el protocolo al modo SLC para volver a leer el chip de memoria. Este paso manual es necesario para aprovechar al máximo las capacidades mejoradas de relectura de SLC.

En muchos casos, los controladores utilizan una clave XOR diferente para los bloques SLC, por lo que se requiere un elemento XOR independiente. Ahora es posible ajustar el alcance de los bloques en el elemento de clave XOR.

Nuevo AI DM XOR para descifrado automático de datos

Nos complace presentar la nueva función AI DM XOR, que mejora nuestro conjunto de herramientas de recuperación de datos al permitir la descodificación automática de datos de los controladores flash DM. Este nuevo elemento funciona de manera similar a los componentes SM y FC AI XOR existentes, lo que agiliza el proceso de reconstrucción de datos.

Con DM AI XOR, los usuarios ahora pueden decodificar automáticamente los datos codificados, lo que mejora la eficiencia y la precisión de la recuperación. Esta incorporación refuerza nuestro compromiso de proporcionar soluciones avanzadas y fáciles de usar para tareas complejas de recuperación de datos.

Nuevos NAND chips

• 453E9803766C0816
• 45489803766C0816
• 45489AB37E6B081E
• 45B796A5EE
• 89D40C32AA_replace
• 983C98B376720806
• 983E99B37AE30816
• 983EA8037AE4081E
• AD7E280B00C00000
• EC5C98AF84CD
• EC5E98BF84CBEC5E

Nuevos XOR keys

• A608865.5(8832b_256p_ecc54_xoredSA) A683F9
• AU6998SNH83(16k_1728p)_988EE1
• AU_monolith(16k_86p)_988EE1
• AUmonolith(18048b_256p_SAxor_ecc102b)_988EE1
• CBM2099(12k_512p)_C32EA6
• CBM2199(16k_1152p)_C1E5B2
• CBM2199(16k_256p)_v2_EEBB0C
• CBM_blob(8k_86p)_7421FC
• CBMmonolith(4k_64p)_C32EA6
• ITE_monolith(17664b_256p_556_548_xoredECC)_988EE1
• PS2251-70-25(16k_1344p)_FA9E80
• PS2251-70-25(16k_448p)_FA9E80
• PS5005(17664b_256p)_FA9E80
• SM_monolith(16k_258p)_E8018F
• SM_unknown(18336_1152p)_XoredSA_5385E9
• TC58(18432b_576p_1218_xoredECC)_80809E_15

Nuevos ECC/BCH

• AU6998SN_18592(ecc126b)_16
• AU_monolith_18048(ecc102b)_16_X
• CBM2099-00121-1_2304(ecc12b)_4
• CBM2099_18256(ecc116b)_12
• CBMmonolith_4352_4.bch
• DM_unknown_18311_16.bch
• FC1178_18048(ecc102b)_16
• FC8508_4303(ecc24b)_8
• ITE_monolith_17664(ecc36)_32_X
• PS2251-70-25_18336(ecc106b)_16
• PS2251-70-25_18336(ecc116b)_16
• SM3265P_18592(ecc134+21SA)_17
• SM_MicroSD_18336(ecc945bits)_17
• SM_blob_17920(ecc85b)16+1
• SM_monolith_18432(ecc92b_SAecc21b)_32+1
• SMinside_20-82-00549_17664(ecc78b+ SAecc8b)_17
• US3281(PS_inside)_9220(ecc105)_8

Nuevos pinouts añadidos

Corrección de errores y otros cambios

• Corregido el error de plano único en BCR
• Corregido el error del analizador Ext FS
• Corregido el error del analizador ExFAT FS

La entrada Visual NAND Reconstructor 9.0 Nueva Actualización se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Cualquier consulta o recogida, pueden ponerse en contacto con nosotros en el correo laboratorio@dprrecovery.com o en el whatsapp 616599089 de 9:00 a 14:00

La entrada Permaneceremos cerrados por vacaciones del 14 a 28 de agosto, volvemos el Jueves 29 y continuaremos con los casos pendientes informando lo antes posible se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

La entrada Nuevos teléfonos soportados por nuestro laboratorio para la recuperación de datos con extraccion de cifrado se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Realme 8 5G (RMX3241) (MediaTek Dimensity 700/800 OPPO/Realme)
Realme 9 Pro Plus (RMX3393) (MediaTek Dimensity 920)

Realme GT NEO 2T (RMX3357) (MediaTek Dimensity 1200)
Oppo A18 (MediaTek MT6769 Helio G85)
CoolPad COOL1 (C103) (Qualcomm Snapdragon 652)
Lenovo K5 Play (Qualcomm Snapdragon 430)

OUKITEL WP22 (MediaTek Helio P90)

Galaxy A04/A04e (M-A042M) (MediaTek MT6765)
Armor 20 WT (MediaTek Helio G99)
Bison 2 Pro (MediaTek Helop P90)
Redmi 10A (MediaTek Helio G25)
POCO M3 PRO 5G (M2103K19PG) (MediaTek Dimensity 700)
POCO M5s (2207117BPG) (Mediatek MT6785V/CD Helio G95)
OnePlus Nord 3 5G (MediaTek Dimensity 9000 / 9000+)

La entrada Nuevos teléfonos soportados por nuestro laboratorio para la recuperación de datos con extraccion de cifrado se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Android proporciona una serie de mecanismos para proteger los datos de los usuarios.

Los datos casi siempre se cifran en reposo mediante esquemas como el cifrado de disco completo o basado en archivos. Funciones como las pantallas de bloqueo de usuarios y la zona de pruebas de aplicaciones también sirven para proteger los datos de los usuarios contenidos en las aplicaciones contra el acceso o la extracción no autorizados. Sin embargo, todas estas protecciones pueden anularse en determinadas circunstancias y los desarrolladores de aplicaciones pueden optar por agregar una capa de seguridad en la capa de la aplicación.

Desafíos del cifrado de Android

Un ejemplo de esto es cuando los desarrolladores optan por implementar el cifrado de los datos de sus aplicaciones. Este cifrado puede proteger una variedad de tipos de datos almacenados en el dispositivo, como mensajes, medios u otros datos confidenciales, como credenciales. El desafío para los desarrolladores es cómo implementar esta capa adicional de cifrado.

La implementación de un esquema de cifrado que almacena claves de cifrado en el sistema de archivos de Android, utiliza valores codificados para derivar claves o incluso derivar claves a partir de la entrada del usuario sigue siendo algo inseguro:

• Si las claves o los valores utilizados para derivarlas se pueden extraer del sistema de archivos de Android, entonces es trivial realizar ingeniería inversa en la aplicación y usar estos valores para descifrar los datos.
• Incluso si las claves se derivan de una entrada del usuario, como una contraseña o un código PIN, los esquemas siguen siendo vulnerables a métodos de recuperación de contraseñas como diccionario o ataques de fuerza bruta.

Para resolver este problema, Android pone a disposición una API que permite a los desarrolladores de aplicaciones almacenar claves de cifrado en un área segura que no forma parte del sistema de archivos de Android y no es accesible para Android incluso si el sistema operativo Android está comprometido. Esto ofrece un grado de protección similar al que el cifrado a nivel de dispositivo Android utilizado para proteger la partición de datos del usuario puede estar «respaldado por hardware» si el dispositivo lo admite; que hacen la mayoría de los dispositivos modernos. El subsistema de Android utilizado para esto se llama Keystore y lo utilizan varias aplicaciones populares como Briar, Wickr, Signal y la aplicación Element, por nombrar algunas.

Finding Keystore keys

Las claves del almacén de claves se almacenan en la partición de datos del usuario en la siguiente ubicación: /misc/keystore/ pero normalmente se almacenan en un formato cifrado.

• Hasta Android 11, cada usuario de Android en el dispositivo tiene un subdirectorio separado y las entradas del almacén de claves se almacenan en un archivo dedicado por entrada, junto con un archivo asociado que contiene solo las «características» (metadatos asociados) de la entrada del almacén de claves.
• En Android 12 y versiones posteriores, las entradas del almacén de claves y los metadatos asociados para todos los usuarios se almacenan en una base de datos SQLite ubicada en: /misc/keystore/persistent.sql

Clave de cifrado de clave (KEK)

Aunque las aplicaciones pueden solicitar el uso de sus claves asociadas a través del subsistema Keystore y recibir los resultados, Android impide su acceso directo. Para evitar que un atacante que ha comprometido el sistema operativo Android extraiga estas claves, las propias claves suelen cifrarse con una clave de cifrado de clave (KEK) adicional.

Este KEK generalmente está respaldado por hardware; es decir, se deriva de algunos valores fijos mantenidos en hardware seguro. Android no debería tener acceso a estos valores seguros retenidos por el hardware y, una vez que se inicia un dispositivo, solo debería ser accesible para un sistema operativo confiable (TOS) que se ejecute en paralelo a Android. Es el TOS el que utiliza los valores guardados en hardware seguro para derivar en cada arranque la KEK utilizada para descifrar las entradas del almacén de claves.

Es importante tener en cuenta que los TOS son un sistema operativo autónomo y Android no tiene acceso a las claves descifradas del almacén de claves, que solo las descifran los TOS dentro de un «mundo seguro». Aunque existe efectivamente un «cortafuegos» entre el mundo seguro y el mundo normal (en el que se ejecuta Android), existen mecanismos de comunicación que permiten a Android solicitar operaciones criptográficas utilizando claves de almacén de claves realizadas por los TOS y luego recibir los resultados de esas operaciones.

Uso común por parte de los desarrolladores del almacén de claves de Android

Una forma común en que los desarrolladores de aplicaciones utilizan el almacén de claves de Android no es necesariamente para cifrar/descifrar directamente los datos de su aplicación, sino para proteger otras claves generadas dentro de la propia aplicación y almacenadas en el sistema de archivos de Android, generalmente en el directorio de datos dedicado de las aplicaciones. A continuación se muestra un diagrama simplificado de este tipo de implementación:

Extracción de almacén de claves

Puede extraer claves del almacén de claves en forma descifrada utilizando una de dos metodologías. El primero es a través de los métodos físicos Android Debug Bridge (ADB), Full File System Extraction (FFS) o ADB y es específico para aplicaciones particulares para las cuales admitimos la extracción de Keystore. En realidad, este método no extrae las claves descifradas del almacén de claves, sino que solicita a través del sistema operativo Android que los TOS utilicen esas claves para descifrar las claves específicas de la aplicación utilizadas para cosas como el cifrado de bases de datos. Una vez descifradas, estas son las claves que extraemos usando este método para descifrar los datos de la aplicación.

Segundo método de extracción de almacén de claves

El segundo método consiste en realizar el descifrado sin conexión de las claves del almacén de claves y es posible mediante los métodos MTK, Unisoc, Qualcomm, Huawei Qualcomm y Huawei Kirin.

Este enfoque es posible porque a través de estos métodos podemos extraer los valores almacenados en hardware seguro y usarlos para descifrar esas claves «sin procesar» del almacén de claves.

Una ventaja de usar este método es que todas las claves del almacén de claves deben descifrarse y podemos usarlas para descifrar datos de aplicaciones que aún no son compatibles específicamente con nuestro software, o aquellas que pueden ser compatibles en el futuro sin necesidad de realizar otra operación. extracción.

Ventaja: descifra y analiza aplicaciones automáticamente

Para aquellas aplicaciones que son explícitamente compatibles, como Wickr, Signal y Briar (por nombrar algunas), Se encargará del descifrado y el análisis automáticamente.

Una ventaja adicional es que algunas aplicaciones pueden proteger aún más el uso de las claves del almacén de claves agregando un paso de autenticación biométrico o basado en PIN/contraseña antes de que la aplicación pueda hacer uso de las claves (su eliminación puede invalidar las claves permanentemente).

Este proceso no está directamente relacionado con el cifrado y el descifrado fuera de línea pasa por alto este mecanismo de seguridad, lo que puede presentar un problema si se extraen las claves del almacén de claves a nivel del sistema operativo mediante un método «en vivo».

Algunas aplicaciones, como Briar, pueden optar por implementar su propia pantalla de ingreso de contraseña, lo que les permite vincular el descifrado de los datos de la aplicación a una contraseña de usuario, así como a la clave del almacén de claves, pero estas aplicaciones parecen ser una minoría. La recuperación de contraseña para Briar mediante métodos como fuerza bruta o ataques de diccionario es posible.

Cómo realizar una extracción de almacén de claves

La versión de Android de la aplicación Element es una que no admitimos (todavía, pero observe este espacio) para el análisis, aunque actualmente sí admitimos las versiones de escritorio. Con acceso a las claves del almacén de claves, es posible descifrarlas manualmente.

Element es una aplicación de mensajería de código abierto centrada en la seguridad. Almacena datos en el dispositivo, como mensajes, en una base de datos cifrada de Realm. Utiliza un modelo bastante estándar para almacenar y proteger la clave de cifrado de la base de datos con una clave Keystore, y es el mismo modelo que se muestra en el diagrama anterior de esta publicación.

• La clave de cifrado de la base de datos se almacena en un archivo XML llamado «im.vector.matrix.android.keys.xml» ubicado en el directorio de preferencias compartidas de la aplicación (/data/data/im.vector.app/shared_prefs) y está cifrado con una clave de almacén de claves.
• La base de datos también se almacena en el directorio de datos de las aplicaciones y se llama «disk_store.realm«. Esta aplicación es de código abierto, por lo que podemos leer más fácilmente las partes relevantes del código fuente para comprender cómo se implementó el esquema de cifrado; Los detalles son los siguientes:
• vector.matrix.android.keys.xml contiene más de una clave, pero la relevante comenzará con «REALM_ENCRYPTED_KEY_session_db«. Está codificado en Base64 y cuando se decodifica y se convierte a hexadecimal, sigue el siguiente formato:
• Byte 0: versión de formato utilizada para determinar el tipo de cifrado
• Byte 1 – Longitud IV (vector de inicialización)
• Bytes [2 – longitud IV] – IV
• Bytes desde el final del IV hasta el inicio de la etiqueta GCM: clave de base de datos cifrada, codificada en Base64
• 16 bytes finales: etiqueta GCM

El visor de archivos de Oxygen Forensic® Detective incluye una serie de visores útiles para poder ver formatos de datos como XML en una vista deserializada. La herramienta de conversión de datos incorporada también es extremadamente conveniente para la conversión automática de datos seleccionados desde formatos como la codificación Base64.

En este ejemplo, la versión del formato (resaltada en amarillo) es 0; esto rige el tipo de clave del almacén de claves generada y el cifrado utilizado cuando se instala la aplicación por primera vez.

Se decide según la versión de Android.

• La longitud del IV (resaltada en violeta) es 0x0C, que es 0d12, por lo que el IV son los siguientes 12 bytes.
• Los últimos 16 bytes son la etiqueta GCM (resaltada en gris) y todo lo que se encuentra entre el IV y la etiqueta GCM es la clave de cifrado de la base de datos cifrada y codificada en Base64 (resaltada en verde).

Seleccionando de la llave correcta

A continuación, necesitamos la clave del almacén de claves correspondiente para descifrar la clave de cifrado de la base de datos. Las claves del almacén de claves, que se han descifrado sin conexión, están disponibles para ver en la sección «Almacén de claves» de la categoría de datos «Cuentas y contraseñas». Podemos seleccionar la clave correcta mirando la columna «Etiqueta» que se relaciona con el «alias» utilizado por la aplicación para acceder a las entradas del almacén de claves. El alias lo elige el desarrollador de la aplicación y puede tener cualquier valor. Para Element, la clave correcta tiene un alias que comienza con «session_db«.

Cómo resolver conflictos de nombres de alias

En caso de que haya un conflicto de nombres de alias entre aplicaciones, o varias instancias de la misma aplicación en un dispositivo, podemos asegurarnos de elegir la correcta prestando también atención a los campos «Cuenta» y «Servicio» en los detalles. cristal. Estos se relacionan con el ID de usuario de Android y el ID de usuario de la aplicación, respectivamente. Podemos encontrar el ID de usuario de la aplicación (10283 en este ejemplo) buscando dentro del archivo “packages.xml” ubicado en: /data/system el nombre del paquete im.vector.app y verificando que coincida con nuestra entrada de clave descifrada del almacén de claves.

Descifrando la clave de cifrado de la base de datos

Ahora que tenemos la clave del almacén de claves relevante y conocemos la estructura de la entrada de la clave de la base de datos almacenada en «im.vector.matrix.android.keys.xml», podemos usar una herramienta como Python o la siempre útil, gratuita y abierta. -Herramienta Cyberchef de origen (consulte: https://github.com/gchq/CyberChef para obtener más información) para intentar descifrar la clave de cifrado de la base de datos.

Para esta tarea utilicé Cyberchef. La primera etapa de la receta que utilicé es una operación de descifrado AES, completada con la clave del almacén de claves correspondiente, así como las etiquetas IV y GCM tomadas del archivo XML. Luego, la operación se ejecuta en el segmento de clave de cifrado de la base de datos cifrada (también tomado del archivo XML). Recuerde que esta clave también se almacena en formato Base64, por lo que después del descifrado ejecutamos una operación de decodificación de Base64. Finalmente, como las claves de cifrado de la base de datos de Realm están en formato hexadecimal, utilizamos una operación final para convertir la salida a hexadecimal.

La operación fue exitosa y ahora tenemos una cadena hexadecimal de 128 caracteres como resultado, lo cual es prometedor. Podemos usar esto para intentar descifrar la base de datos de Element dentro de la herramienta.

Después de aplicar la clave, podemos ver que la base de datos se ha descifrado y abierto correctamente en el visor de bases de datos nativo. Ahora podemos comenzar a investigarlo manualmente en busca de datos útiles.

Resumen de descifrado del almacén de claves

El descifrado del almacén de claves sin conexión es una capacidad extremadamente poderosa. En un mundo ideal, una herramienta forense digital permitiría el análisis de cada aplicación, pero en realidad este nunca será el caso y, en ocasiones, se requiere un análisis manual.

Aunque siempre damos la bienvenida a las solicitudes de soporte para nuevas aplicaciones y nos esforzamos por agregarlas, es posible que una investigación requiera demasiado tiempo para esperar. En estos casos, tener acceso a todas las claves del almacén de claves en forma descifrada garantiza que los examinadores siempre tendrán lo que necesitan para descifrar la mayor cantidad de datos posible, incluso si ya no tienen acceso al dispositivo físico.

La entrada Extracción del almacén de claves de Android se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

• Asus Zenfone 4 Selfie (ZD553KL/X00LD) (Qualcomm Snapdragon 430)
• Asus ZenPhone Live (L1) (ZA550KL) (Qualcomm Snapdragon 425)
• DEXP Urus D1 (Unisoc T618)
• Honor 60 SE (GIA-AN00) (MediaTek Dimensity 900)
• Motorola E5 Plus (XT1924-1) (Qualcomm Snapdragon 425)
• Motorola E22 (XT-2239) (MediaTek Helio G37)
• QUKITEL RT2 (MediaTek MT8788)
• QUKITEL WP20 (MediaTek Helio А22)
• QUKITEL WP20 PRO (MediaTek Helio А22)
• Realme C31 (RMX3501) (Unisoc T612)
• Realme 10 4G (RMX3630) (MediaTek Helio G99)
• Realme GT NEO 3 (RMX3561) (MediaTek MT6895 Dimensity 8100)
• RODA Enduro (Qualcomm Snapdragon 625)
• Sony XPeria L3 (l4312) (MediaTek Helio P22)
• Tecno Pova 4 (LG7n) (MediaTek Helio G99)
• Tecno Camon 20 (CK6n) (MediaTek Helio G85)
• TP-LINK Neffos x20 Pro (MediaTek Helio P22)
• Redmi 13C (MediaTek Helio G85)
• POCO C65 (MediaTek Helio G85)
• ZTE Blade A7 (MediaTek Helio P22)

La entrada Nuevos teléfonos soportados por nuestro laboratorio para la recuperación de datos con extraccion de cifrado se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

• Doogee S88 PRO (Mediatek MT6771T Helio P70)
• HONOR X5 (VNA-LX2) (Mediatek MT6762 Helio G25)
• Huawei Y6 (2019) (Mediatek MT6761 Helio A22)
• Huawei Y6p (MED-LX9N) (Mediatek Helio P22)
• Infinix HOT30i X669D (UMS9230 (Unisoc T606))
• Infinix HOT20i (x665E) (Mediatek Helio G35)
• Lenovo Tab M7 (Mediatek MT8321)
• Motorola E-13 (XT-2345-1) (UNISOC T606 )
• Motorola E-7 Power (XT-2097) (Mediatek MT6762G Helio G25)
• ONE PLUS NORD N20 (CPH2469) (Mediatek Helio G35)
• OnePlus Nord CE2 (IV2201) (Mediatek Dimensity 900)
• OPPO F5 ( Mediatek MT6763T)
• OPPO A91 (Mediatek Helio P70)
• OPPO Reno 5 Lite (Mediatek MT6771)
• OPPO A75 5G (CPH2495) (Mediatek Dimensity 700)
• OPPO A17k (CPH2471) (Mediatek Helio G35)
• POCO C55 (Mediatek Helio G85)
• POCO C50 (220733SPH) (Mediatek Helio A22)
• REALME 7 (RMX2151) (Mediatek Helio G95 MT6785)
• REALME 8 (RMX3085) (Mediatek MT6785V/CD Helio G95)
• REALME Narzo N53 (Unisoc T612)
• Samsung Galaxy A03 (SM-035F) (Unisoc T606)
• Samsung Galaxy A02 (SM-A022G) (Mediatek MT6739WW)
• Samsung Galaxy A10s (SM-A107F/DSCPU) (MediaTek MT6762V)
• Samsung Galaxy Tab A7 Lite (SM-T225) (MediaTek MT6765)
• Smart 7 x6515 (Mediatek Helio A22)
• TECNO Spark 10 KI5q (Mediatek MT6765 Helio G37)
• TECNO Spark 8C (Unisoc T606)
• TECNO Spark 2023 Go (Mediatek Helio A22)
• TECNO SPARK 8 Pro (Mediatek MT6768)
• TECNO Pop 6 Pro (Mediatek Helio A22)
• TECNO Spark 10 Pro KI7 (Mediatek Helio G88)
• TECNO Pova Neo 2 (Mediatek MT6768)
• TECNO Pova 3 (Mediatek Helio G88)
• Ulefone Armor X5 (Mediatek MT6763 helio P23)
• UMIDIGI BISON PRO (Mediatek MT6768)
• Xiaomi Redmi 7A (Qualcomm Snapdragon 439)
• Xiaomi Redmi A2 (23026RN54g) (Mediatek Helio G36)
• Xiaomi 11T 21081111RG (MediaTek MT6893 Dimensity 1200)
• Xiaomi Redmi A2+ (23028RNCAG) (Mediatek Helio G36)
• Xiaomi Redmi 6 Pro (Qualcomm Snapdragon 625 MSM8953)
• Xiaomi Redmi 12C (22120RN86I) (Mediatek Helio G85)
• Xiaomi Redmi Note 12C (Mediatek MT6769Z Helio G85)
• Xiaomi Redmi Note 12 Pro+ (22101316UG) (Mediatek Dimensity 900)

La entrada Nuevos teléfonos soportados por nuestro laboratorio para la recuperación de datos con extraccion de cifrado se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

La entrada Nuevo modelo PS2251 añadido a nuestra biblioteca se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Nuevo modelo añadido en nuestra biblioteca con controlador IS918M-FN02 con Nand Chip Micron ID: 2C C4 08 32 A6 00

La entrada Nuevo modelo añadido a nuestra biblioteca se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Sabemos lo frustrante que puede ser perder acceso a tu teléfono, ya sea por una contraseña olvidada o cualquier otro problema de seguridad. Nuestro equipo altamente capacitado utiliza las últimas técnicas y herramientas para ayudarte a recuperar el acceso a tu dispositivo de manera segura y confidencial.

En DPR Recovery Alicante, entendemos la importancia de la privacidad y la seguridad de tus datos personales. Puedes confiar en nosotros para tratar tu situación con la máxima discreción y profesionalismo.

No importa la marca o el modelo de tu dispositivo móvil, estamos aquí para ayudarte a recuperar el acceso perdido. ¡Contáctanos hoy mismo y deja que nuestros expertos en recuperación de contraseñas de móviles en DPR Recovery Alicante resuelvan tu problema rápidamente y sin complicaciones!

La entrada ¿Olvidaste la contraseña de tu móvil y necesitas acceder a tus datos urgentemente? se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Somos tu solución.

Envía tu dispositivo a nuestro laboratorio

Trabajamos con todo tipo de dispositivos

Pendrives – Tarjetas SD – MicroSD – Discos HDD – Discos Externos – Discos de Portatiles – Discos Sólidos SSD – Servidores – RAIDs

Tel: 966 231 768

WhatsApp: +34 616 59 90 89

C/ Arzobispo Loaces n17 local 1-2, 03003 Alicante

Nuestro laboratorio está a su disposición.

La entrada Nuevos adaptadores para discos duros WD que estabilizan las señales y de una calidad suprema. Para dar un mejor servicio a los clientes, siempre con la última tecnología disponible. se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Dejando la memoria totalmente sucia y con patillas dobladas.

Nosotros @dprrecovery_golden_phone en solo 3 horas pudimos recuperar todo el contenido del chip que ya llego manipulado

Recuperando toda la estructura de ficheros, ya dispone de las imágenes y vídeos más preciados.

Necesitas recuperar una memoria USB, una MicroSD? Podemos recuperarla

Somos tu solución.

Envía tu dispositivo a nuestro laboratorio

Trabajamos con todo tipo de dispositivos

Pendrives – Tarjetas SD – MicroSD – Discos HDD – Discos Externos – Discos de Portatiles – Discos Sólidos SSD – Servidores – RAIDs

Tel: 966 231 768

WhatsApp: +34 616 59 90 89

C/ Arzobispo Loaces n17 local 1-2, 03003 Alicante

Nuestro laboratorio está a su disposición.

#YoComproEnAlicante

#goldenphone

#goldenphoneinformatica

#recuperaciondatosespaña

#recuperacióndedatos

#recuperaciondedatosespaña

#recuperaciondatosalicante

#recuperaciondatos

#recoverydata

#recovery

#informatica

#dprinformatica

#dprrecovery

#moviles

#memorias

La entrada Un caso muy complejo para unos y más fácil para otros. se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Necesitas recuperar un disco duro o cualquier dispositivo?

Somos tu solución.

Envía tu dispositivo a nuestro laboratorio

Trabajamos con todo tipo de dispositivos

Pendrives – Tarjetas SD – MicroSD – Discos HDD – Discos Externos – Discos de Portatiles – Discos Sólidos SSD – Servidores – RAIDs

Tel: 966 231 768

WhatsApp: +34 616 59 90 89

C/ Arzobispo Loaces n17 local 1-2, 03003 Alicante

Nuestro laboratorio está a su disposición.

#YoComproEnAlicante

#goldenphone

#goldenphoneinformatica

#recuperaciondatosespaña

#recuperacióndedatos

#recuperaciondedatosespaña

#recuperaciondatosalicante

#recuperaciondatos

#recoverydata

#recovery

#informatica

#dprinformatica

#dprrecovery

#moviles

#seagate

La entrada Caso de éxito con un disco duro de 6Tb con un daño en la cabezas lectoras y degradación en la superficie. Tras analizar la estructura conseguimos leer todos los datos 5400Gb usados. se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.