Esta optimización permite agilizar el tratamiento de memorias NAND compatibles y mejorar el proceso de reconstrucción de datos. Debido a las mejoras incorporadas y a la corrección de errores conocidos, recomendamos actualizar el software a esta versión.

Principales novedades

1. Nuevo algoritmo LDPC para PS2251-06

Se incorpora el algoritmo de comprobación LDPC para el controlador Phison PS2251-06, junto con el proceso completo de reconstrucción.

Esta mejora permite optimizar la verificación, corrección y reconstrucción de los datos en dispositivos compatibles con este controlador.

2. Corrección de errores

Se han solucionado diferentes errores detectados en versiones anteriores, mejorando la estabilidad y el funcionamiento general del software.

3. Nuevos modelos compatibles

Se añaden los siguientes modelos:

• Sandisk_454CA8A27651_1x1_by fxc
• Sandisk_454899B37A6B_1x1_by pys
• unknow-TFv2_AD7E285302B0_1x1_by Csava
• PS2251-06_983C98B37671_1x1_dump blk=768real blk=576
• PS2251-06_983C98B37672_2x1
• IS918_2CA40832A100_1x1_by cjz

4. Nuevas configuraciones de disposición —layouts—

También se incorporan nuevos layouts para trabajar con diferentes controladores y estructuras de memoria:

• Monolith unknow-TFv2: 1150x15+1158
• JMicron (JM) JmSD: 1152x16
• Phison (PS) LDPC PS2251-06: 1146x16
• Silicon Motion (SM) Test LDPC SM2258XT: 1148x16+52

Recomendación de actualización

Recomendamos instalar esta versión para aprovechar la mejora de rendimiento en los procesos LDPC, la ampliación de modelos compatibles y las nuevas configuraciones de reconstrucción disponibles.

En DPR Recovery trabajamos continuamente con herramientas profesionales y tecnologías especializadas para afrontar recuperaciones de datos complejas en memorias USB, tarjetas SD, dispositivos monolíticos y otros soportes basados en memoria NAND.

New Update: Improved LDPC Speed and Data Reconstruction

A new update is now available, significantly improving the speed of LDPC error-checking and correction processes.

These optimisations accelerate the processing of compatible NAND flash memory and improve the overall data reconstruction process. Due to the performance enhancements and fixes included in this release, we recommend updating the software to the latest version.

Main New Features

1. New LDPC Algorithm for PS2251-06

A new LDPC checking algorithm has been added for the Phison PS2251-06 controller, together with the complete reconstruction process.

This improvement optimises data verification, error correction and reconstruction on devices using this compatible controller.

2. Bug Fixes

Several known issues found in previous versions have been resolved, improving the software’s overall stability and performance.

3. Newly Supported Models

The following models have been added:

• Sandisk_454CA8A27651_1x1_by fxc
• Sandisk_454899B37A6B_1x1_by pys
• unknow-TFv2_AD7E285302B0_1x1_by Csava
• PS2251-06_983C98B37671_1x1_dump blk=768real blk=576
• PS2251-06_983C98B37672_2x1
• IS918_2CA40832A100_1x1_by cjz

4. New Layout Configurations

New layouts have also been added for working with different controllers and memory structures:

• Monolith unknow-TFv2: 1150x15+1158
• JMicron (JM) JmSD: 1152x16
• Phison (PS) LDPC PS2251-06: 1146x16
• Silicon Motion (SM) Test LDPC SM2258XT: 1148x16+52

Update Recommendation

We recommend installing this version to benefit from the improved LDPC processing performance, the expanded list of supported models and the new reconstruction layouts.

At DPR Recovery, we continuously work with professional tools and specialised technologies to handle complex data recovery cases involving USB flash drives, SD cards, monolithic devices and other NAND-based storage media.

La entrada Nueva Update NFT mejora considerablemente la velocidad de verificación y corrección LDPC se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Nuevo AI-XOR for PS2251-70-25

Ya está disponible el nuevo elemento AI-XOR para el controlador Phison PS2251-70-25. Este controlador se utiliza habitualmente en unidades flash USB.

El flujo de trabajo de recuperación es sencillo: una vez detectado el ECC, se ajusta la disposición de la página y se inicia el análisis XOR. Dependiendo del caso y de la estructura de datos de la memoria NAND, el análisis suele durar entre 3 y 10 minutos.

Este nuevo elemento simplifica la recuperación de dispositivos basados ​​en Phison, reduciendo el tiempo de análisis y agilizando y facilitando el procesamiento de estos casos.

Nuevas funciones y velocidad de recuperación de claves mejorada para el elemento SM AI-XOR

Algunos casos de recuperación de memorias NAND no siguen el comportamiento habitual de XOR de los controladores SM.

Por lo general, los controladores SM desplazan la secuencia XOR en función de las posiciones de las columnas defectuosas. Esto difiere del funcionamiento de controladores como Phison, Toshiba o Alcor Micro.

Sin embargo, en algunos casos excepcionales, el método estándar de SM no funciona, incluso cuando la configuración parece correcta.

Para estos casos, hemos añadido una nueva opción llamada «Ignore BCR» (Ignorar BCR) al elemento SM AI-XOR.

Al activarla, la secuencia XOR se genera sin tener en cuenta las posiciones de las columnas defectuosas. Esto puede resolver aquellos casos en los que falla el método XOR estándar de SM.

Las capturas de pantalla muestran el resultado sin la opción «Ignore BCR», con dicha opción activada y el sistema de archivos recuperado.

Elementos AI-XOR para FC y FC33 más rápidos y mejorados

Los nuevos algoritmos de generación de claves AI-XOR para FC y FC33 reducen significativamente el tiempo de análisis y mejoran la recuperación de fragmentos faltantes de la clave XOR.
En el caso de FC XOR, el algoritmo anterior permitía recuperar partes faltantes de la clave, pero el proceso a veces requería 50 minutos o más.

La nueva versión suele completar esta misma etapa en menos de 10 minutos, recuperando a menudo los fragmentos faltantes durante la primera pasada.

La mejora más significativa se observa en FC33 XOR. Anteriormente, el análisis XOR solía tardar entre 30 y 60 minutos y no siempre generaba una clave completa. El nuevo algoritmo puede generar una clave XOR al 100 % en solo 1 a 3 minutos, utilizando únicamente unos pocos bloques de datos.

NAND chips

• 453A949376
• 45489AB3FE6B081E
• 45DE949376510F04
• 983E98B3F6E3081E
• 98DEA1327A
• EC1E98AF84CD

Algunas de las configuraciones se han actualizado.

Nuevos (XOR keys)

• CBM2199E(18432_1344p_ecc99)_C1E5B2.xor
• CBM2199ESS(16k_256p)_CF7ED4.xor
• SSS6131(18336b_384p_1140_xoredSA_ECC)_809E9C.xor
• SSS6131(18432b_384p_1140_xoredSA_ECC)_809E9C.xor

Algunas de las claves XOR han sido actualizadas.

Nuevos ECC/BCH

• Black_blob_18336(ecc98_30_X.bch
• CBM2199ESS_18048(ecc87b)_16.bch
• CBM2199ESS_18048(ecc88b)_16.bch
• monoUFD_18432(ecc98)_16_X.bch
• SM3259 AB_18432(ecc88b)_30+1.bch

Algunos de los códigos ECC se han actualizado.

La actualización está disponible en el Centro de descargas para todos los usuarios con una suscripción de soporte activa.

Para consultar el estado de su suscripción, renovarla u obtener el ID del producto, por favor envíe una solicitud a laboratorio@dprrecovery.com / sales@rusolut.com.

El equipo de Rusolut & Dpr Recovery

La entrada Rusolut Nueva Actualización 11.2 se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Después de unos días de descanso, en DPR Recovery retomamos nuestra actividad con energía renovada, nuevos proyectos y muchas novedades que iremos compartiendo próximamente.

Volvemos preparados para continuar ayudando a particulares, empresas y profesionales a recuperar su información más importante. Nuestro laboratorio vuelve a estar plenamente operativo para atender casos de recuperación de datos en discos duros, SSD, memorias USB, tarjetas, teléfonos móviles, servidores, sistemas NAS y configuraciones RAID.

También seguimos trabajando en nuestros servicios de informática forense, peritaciones judiciales, análisis de dispositivos electrónicos y recuperación avanzada de datos mediante las herramientas y tecnologías más especializadas del sector.

Regresamos con la misma ilusión de siempre y con un compromiso aún mayor: ofrecer un servicio profesional, cercano y transparente en cada caso.

Queremos agradecer a todos nuestros clientes la confianza, la paciencia y el apoyo que nos demuestran cada día.

¡Ya estamos de vuelta y preparados para seguir recuperando tu vida digital!

DPR Recovery
Datos · Protección · Recuperación

La entrada ¡Ya hemos vuelto con las pilas cargadas y muchas novedades! se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

Después de muchos meses recuperando datos, resolviendo casos complejos y ayudando a nuestros clientes, ha llegado el momento de tomar un pequeño descanso.

📅 DPR Recovery permanecerá cerrado del 23 de julio al 5 de agosto, ambos inclusive.

🔹 Volveremos el 6 de agosto con las pilas cargadas y con la misma ilusión de siempre para seguir recuperando aquello que más valor tiene: vuestros datos.

📧 Durante estos días podéis seguir contactándonos por correo electrónico o por WhatsApp. Aunque estaremos de vacaciones, responderemos en la mayor brevedad posible.

🙏 Queremos aprovechar para dar las gracias a todos nuestros clientes y colaboradores por la confianza depositada en nosotros durante todo el año.

🌊 ¡Os deseamos un feliz verano y unas excelentes vacaciones!

Nos vemos el 6 de agosto. 💙

Equipo DPR Recovery
«Recuperamos tu vida digital.»

La entrada 🌴 ¡Nos vamos a recargar energías! ☀️ se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

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.

Fuente Blog Ace Lab

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.

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.

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.

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.

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

🌐 https://dprrecovery.com

👏Nuestro laboratorio a su disposición.👏

YoComproEnAlicante

goldenphone

goldenphoneinformatica

recuperaciondatosespaña

recuperacióndedatos

recuperaciondedatosespaña

recuperaciondatosalicante

recuperaciondatos

recoverydata

recovery

informatica

dprinformatica

dprrecovery

La entrada Recuperación disco duro 3tb Seagate se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

No lo des por perdido, hacemos todo lo impensable para poder extraer tus datos sea como sea.

Siempre con la mejor tecnología

Soportamos la gran mayoría de Samsung, Xiaomi, Huawei, LG, iPhone y muchos más…

🔹 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

🌐 https://dprrecovery.com

👏 Nuestro laboratorio está a su disposición.👏

La entrada Recuperación Huawei Nova 5T muy mojado. se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

La entrada Recuperación de memoria USB Sandisk 16gb se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.

El cliente ya dispone de acceso normal a su teléfono.

Siempre con la mejor tecnología

Soportamos la gran mayoría de Samsung, Xiaomi, Huawei, LG, iPhone y muchos más…

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

Solicita Presupuesto

Nuestro laboratorio a su disposición.

La entrada Teléfono Samsung A50 con Android 11 que nos envían desde Vigo con patrón al inicio, necesitan los datos que hay en el teléfono y no lo recuerdan. se publicó primero en DPR Recovery Laboratorio de Recuperacion de Datos.