Tengo una PC con Windows 10 y uno de mis discos duros se rompió por completo (no lo reconoce el BIOS, hace ruidos extraños y no se puede usar). No era el disco del sistema, pero contenía en su mayoría datos privados. No recuerdo exactamente qué había en el disco y ese es el problema. Para evaluar la pérdida (y evaluar si los procedimientos adicionales de recuperación de datos en el disco duro valen el precio) me gustaría obtener todas las pistas posibles sobre lo que había en el disco (los nombres de los archivos, posiblemente con los nombres de las carpetas serían suficientes).
Pensé que tal vez la búsqueda de Windows con toda su indexación de archivos podría tener alguna información sobre lo que había en el disco almacenado en algún lugar y esa información, aunque fuera parcial, podría recuperarse de alguna manera.
¿Es posible acceder a la base de datos de búsqueda de Windows y recuperar una lista de archivos con rutas del disco perdido y, de ser así, cómo?
Tenga en cuenta que esta pregunta no trata sobre la recuperación de datos del disco duro roto, sino sobre qué información guarda Windows sobre los archivos que estaban en los discos duros (pero que no lo están en este momento). El índice de búsqueda de archivos de Windows parece un lugar potencial donde se podría almacenar dicha información.
Respuesta1
Con la ayuda de un comentario deDr. Moishe PippikLogré acceder a la base de datos de búsqueda de Windows.
El contenido de la búsqueda se almacena de forma predeterminada en
C:\ProgramData\Microsoft\Search\Data\Aplicaciones\Windows\Windows.edb
Es un archivo bastante grande (1 GB en mi caso) y normalmente no se puede copiar en ningún otro lugar porque lo utiliza la búsqueda de Windows. Simplemente abra el administrador de tareas, busque "Indizador de búsqueda de Microsoft Windows" y finalice el proceso de "búsqueda de Windows". Luego copie el archivo Windows.edb en un lugar seguro.
La información sobre el formato de archivo de la base de datos de búsqueda se encuentra, por ejemplo, en este documento porHoward Chiver, quien usa elwdstallarsoftware, que no parece estar disponible para descargar. También hayesteyEste artículoPor Joaquín Metz. Joachim Metz también parece ser el principal contribuyente alibesedben Github, que sin embargo no tiene versiones binarias para Windows y está marcado como experimental.
En resumen, la base de datos de búsqueda de Windows parece estar basada en el formato de archivo de base de datos (EDB) del motor de almacenamiento extensible (ESE), un formato de archivo no documentado propiedad de Windows con partes adicionales de ofuscación y compresión.
Finalmente encontré un proyecto deJeonghyeon Kimdesde 2018 llamadoAnalizador WinSearchDB, confuentes(dependencia adicionalWinforms) en Github. Según el blog, es gratuito (de uso), hay archivos binarios para Windows disponibles y, además, con la edición Visual Studio Community de Microsoft, podría crear fácilmente el programa yo mismo.
El uso es sencillo, se puede seleccionar una ubicación de archivo Windows.edb y luego verificar algunas marcas para saber qué buscar. Luego tomó un tiempo (~5 minutos) y luego presentó alrededor de 100.000 entradas en una tabla. Ordenar por ubicación de archivo es simple y para cada archivo se presentan metadatos.
Sin embargo, volviendo a mi intención original, la cantidad de archivos en el disco duro perdido que aún estaban presentes en la base de datos de búsqueda de Windows fue decepcionantemente pequeña. De cientos de miles de archivos en ese disco duro sólo al máximo. Estaba contenido 1/10 o menos (en realidad, las cosas que todavía recuerdo), por lo que al final fue mucho menos útil de lo que pensaba. Aún así, es una forma viable de acceder al menos a cierta metainformación sobre el contenido de los discos duros que ya no están presentes ni son accesibles.
Respuesta2
Esta respuesta se relaciona con la respuesta de Trilarion a su propia pregunta.
El interesante documento vinculado por el Dr. Moishe Pippik describe el alcance de la indexación. Eso podría explicar el bajo porcentaje de archivos indexados.
Además, puede probar qué sucede si presenta un archivo con contenido aleatorio al indexador. ¿Este archivo aparecerá en la base de datos o no?
El indexador no puede leer un formato de archivo desconocido. Hasta donde yo sé, en versiones anteriores de Windows, el indexador podría ampliarse proporcionando código compilado que permitiera al indexador leer el formato de archivo que se creó.
Puede suceder que aquellos archivos que técnicamente no se pueden indexar no aparezcan en el índice.
Respuesta3
Lo primero es ser muy preciso y detallista. Dijiste "como si no fuera accesible en absoluto". ¿Es esa gramática inglesa normal? Lo siguiente es que "no accesible en absoluto" no es preciso. Muchos dirían que una vez que la letra de la unidad sigue ahí y el contenido está marcado como sin formato, su unidad "no es accesible en absoluto".
Mi definición sería que si la unidad se enciende sin anomalías pero falla cualquier intento de lectura realizada por la computadora en la unidad, debe considerarse "no accesible en absoluto".
Esta es una comprensión totalmente diferente de la misma expresión.
Las primeras cosas que puedes hacer son muy sencillas. Utilizando preferiblemente una máquina Linux, conectaría la unidad y verificaría su presencia con el comando lsblk. Luego generaría un archivo de registro usando smartmontools y lo analizaría. Lo siguiente sería, si el contenido del archivo de registro no lo objeta, intentar duplicar la unidad usando ddrescue y su función de archivo de registro. Eso le proporcionará un duplicado, con suerte, casi completo en una unidad en buen estado y una lista de áreas faltantes que no se copiaron.
Siendo paranoico, rápidamente duplicarías el duplicado y trabajarías en la segunda copia. Dependiendo de su presupuesto, ejecutará diferentes productos de recuperación en la segunda copia. Un programa especializado en huellas dactilares gratuito y de código abierto como Photorec produciría resultados sin metadatos como estructuras de directorios y archivos, pero la salida utilizable de Photorec devolvería a su memoria lo que había almacenado en él.
Este análisis también se puede realizar sin daños en una máquina con Windows utilizando su segunda copia. Si la información recopilada no es suficiente, comenzará su trabajo.
Primero debe aprender cómo funcionan los esquemas de partición más utilizados, como el antiguo Intel/MBR, y aprender también GPT. El software gratuito y de código abierto Testdisk es una buena herramienta para ayudarle.
Conociendo el sistema de archivos utilizado al formatear la unidad, necesitará aprender el formato del sistema de archivos en cuestión, por ejemplo NTFS. Como NTFS es un poco difícil para empezar, preferirías practicar con sistemas de archivos FAT. Una vez que se familiarice, puede intentarlo sobrescribiendo una parte o la FAT completa (tabla(s) de asignación de archivos) de un sistema de archivos FAT. Entonces se necesitaría un poco de programación para buscar sus restos. Luego deberías aprender cómo la desfragmentación afecta tu éxito.
Después de comprender una implementación simple de un sistema de archivos, llegará (presumiblemente) a NTFS. Su única ventaja frente a un programa de recuperación es que puede utilizar la memoria restante del contenido de su unidad a su favor.
Esto puede resultar en un éxito, pero no hay garantía.
En 2001 examiné una unidad de sistema XP fallida que todavía utilizaba un sistema de archivos FAT. Lo único que recuperé (que importaba) fue la lista de invitaciones (archivo xls) de su matrimonio con las invitaciones ya enviadas. No había forma de reconstruir automáticamente el archivo; tuve que mirar los diferentes grupos siguientes. Como era un archivo xls, no estaba comprimido. Simplemente vi el segundo grupo del archivo y no era el siguiente de forma lineal. Hoy nunca hubiera logrado esa tarea en cuanto a la compresión que se utiliza en los archivos tipo xlsx de Excel.