HDD untuk Mac atau casing run-of-the-mill untuk lab pemulihan data

Kami menerima hard disk Seagate ST4000DM000 dari keluarga Lombard untuk diagnosis. Dari kata-kata klien, dimungkinkan untuk memahami bahwa drive digunakan pada komputer Apple Macintosh dan diformat di atasnya, dan lebih dari sekali, selama seluruh operasinya. Pertanyaan tentang kesehatan drive atau jenis sistem file tetap tidak terjawab. Klien hanya memberikan penjelasan yang tidak konsisten bahwa file harus dikembalikan dengan struktur direktori asli. Klien juga menjelaskan bahwa salah satu layanan menerima file tanpa nama asli menggunakan beberapa jenis program pemulihan data, tetapi dia tidak puas dengan hasil ini.







Sebelum memulai diagnostik, langkah pertama adalah menilai status drive. Karena ini adalah Seagate, kami perlu melihat log terminal sejak daya diterapkan, SMART , dan mengevaluasi kemampuan membaca head di zona dengan kepadatan berbeda. Biasanya, tes singkat seperti itu akan mengungkapkan banyak kesalahan.



Kami terhubung, memasok daya. Di terminal, drive secara singkat melaporkan bahwa prosedur start berhasil, dan dengan register DRD dan DSC menunjukkan kesiapannya untuk menerima perintah.





Angka: 2 Log mulai terminal Seagate ST4000DM000 HDD



Selanjutnya, Anda perlu memeriksa bacaan SMART ( apa itu SMART dan apa yang harus dicari di dalamnya telah saya jelaskan dalam catatan saya).





Angka: 3 Pembacaan SMART



Hal pertama yang kita lihat adalah waktu operasi (atribut 0x09), karena jika ternyata mendekati nol, maka tidak masuk akal untuk memperhatikan pembacaan SMART , karena akan ada kemungkinan besar bahwa statistik adalah seseorang reset dengan perintah teknologi, dan pembacaan saat ini tidak menampilkan semua kejadian yang direkam selama pengoperasian drive. Dalam kasus kami, waktu pengoperasian adalah 3.696 jam, yang menunjukkan bahwa kemungkinan besar tidak ada gangguan dalam pembacaan SMART .



Selanjutnya perhatikan pembacaan atribut 0x05, 0xC5 (197), 0xC6 (196) pada kolom RAW. Nilai nol menunjukkan bahwa selama pengoperasian drive, tidak ada masalah serius dengan pembacaan dari permukaan yang terekam dan tidak ada pemetaan ulang yang dilakukan.

Membaca atribut 0xC7 (199) mengisyaratkan kemungkinan masalah dengan transfer data dalam mode kecepatan tinggi. Memperhatikan fakta bahwa jumlah kesalahan kecil, untuk saat ini kami tidak akan membuat kesimpulan yang terlalu dini.



Karena ini bukan Tiled Recorder (SMR), maka kemampuan membaca semua head di zona dengan kepadatan berbeda mudah dinilai. Untuk melakukan ini, cukup mengetahui jumlah kepala, perkiraan ukuran miniband dan urutan pergantiannya dalam membangun ruang logis drive. Kami akan menggunakan Data Extractor untuk demonstrasi. Mari buat peta minisone.





Angka: 4 Peta minispaces di ruang logis Seagate ST4000DM000



Daftar menunjukkan urutan penggunaan minispaces untuk membangun ruang logis:

0, 1, 2, 3, 4, 5, 6, 7, 7, 6, 5, 4, 3, 2, 1, 0 dan kemudian pengulangan siklik. Berdasarkan ukuran satu zona mini untuk drive tertentu, jelas bahwa itu cukup untuk membaca beberapa bagian ruang logis (biasanya awal, tengah, dan akhir rentang logis) dengan panjang sekitar 500.000 sektor untuk memastikan bahwa drive tidak membeku dan kecepatan pemindaian tidak turun drastis. salah satu permukaan.



Itu membaca dari permukaan yang digunakan, dan bukan verifikasi, untuk memeriksa pada saat yang sama apakah kesalahan akan terjadi selama transfer data. Dalam kasus ini, tidak ditemukan kesalahan membaca. Rangkaian tindakan ini memungkinkan Anda untuk menganggap hard disk sehat secara kondisional dan mulai menganalisis struktur sistem file.



Awalnya, kami akan menilai apakah ada partisi yang saat ini ada di disk dan sistem file apa yang digunakan di sana.



Saya ingin menarik perhatian Anda pada fakta bahwa pada disk yang jumlah sektornya lebih dari 4.294.967.296 sektor, Anda harus menggunakan GPTuntuk menggunakan kapasitas penuh, karena tabel partisi klasik menggunakan nilai 32-bit yang tidak cukup lebar. Dalam kasus kami, ST4000DM000 adalah drive 4TB, di mana rentang logis terdiri dari 7.814.037.168 sektor 512 byte.



Mari kita mulai dengan melihat konten di LBA 0.





Angka: 5 Tabel partisi yang menjelaskan keberadaan GPT .



Di sini kami menemukan tabel partisi klasik, dengan deskripsi satu volume. Pada offset 0x1C2, tipe partisi 0xEE ditunjukkan dengan offset sektor 0x00000001 dari awal disk dan ukuran 0x3A3817D5.



Tujuan entri ini adalah untuk menunjukkan bahwa semua konten disk yang tersedia untuk tabel partisi klasik ditempati sehingga berbagai utilitas disk lama yang tidak mengetahui GPT tidak dapat membuat partisi. Namun dalam kasus disk yang jumlah sektornya lebih dari 4.294.967.296, kawasan lindung harus 0xFFFFFFF, bukan 0x3A3817D5.



Harap dicatat bahwa nilai 0x3A3817D5 (976754 645) kira-kira 8 kali kurang dari 7 814 037 168 - jumlah total sektor pada disk. Hal ini memungkinkan kami untuk membuat asumsi bahwa kemungkinan besar disk digunakan sebagai perangkat dengan ukuran sektor 4096 byte, dan bukan 512 byte. Mari kita periksa asumsinya dan coba cari persamaan reguler 0x45 0x46 0x49 0x20 0x50 0x41 0x52 0x54 (BAGIAN EFI). Jika di sektor 1 maka asumsi salah, jika di sektor 8 maka asumsi akan terkonfirmasi.





Angka: 6 Header GPT Mari



juga periksa apakah ada volume yang dijelaskan dalam GPT ini , yang kita lihat di sektor 16





Angka: 7 Bagian yang dijelaskan dalam GPT



Dua entri ditemukan di sini.



Rekor pertama adalah volume sektor 76.800 (614.400) menggunakan sistem file FAT32. Volume ini dicadangkan untuk kebutuhan EFI.



Rekor kedua adalah volume sektor 976644858 (7 813 158864) menggunakan sistem file HFS +.



Karena versi dengan fakta bahwa disk digunakan sebagai perangkat dengan ukuran sektor 4096 byte dikonfirmasi, langkah selanjutnya adalah melanjutkan analisis menggunakan Data Extractor.



Setelah membuat tugas, ubah parameter ukuran sektor dari 512 menjadi 4096 dan dapatkan gambar berikut.





Angka: 8 Parameter HFS +



Kami melihat dua volume pada disk dengan sistem file yang benar. Volume pertama, berdasarkan peran dan ukurannya, tidak menarik bagi kami. Tapi jilid kedua sudah menarik.



Dari stempel waktu, kami dapat menyimpulkan bahwa volume ini dibuat pada tanggal 19 Oktober 2020, yang merupakan tanggal yang relatif dekat dengan waktu disk tiba kepada kami.



Memindai CatalogFile + Journal (HFS + structure) menunjukkan bahwa disk 99,9% kosong dan tidak ada tanda-tanda data pengguna yang dijelaskan oleh sistem file ini.



Sekarang perlu untuk memeriksa asumsi bahwa, mungkin, pada disk ini ada volume dan sistem file lain, dan tidak hanya yang disajikan sekarang. Untuk melakukan ini, kita akan menggunakan alat pencarian untuk berbagai ekspresi reguler yang dikhususkan untuk berbagai struktur sistem file dan file.





Angka: 9 Hasil pencarian ekspresi reguler.



Analisis area sekitar 2 GB, yang berlangsung kurang dari 2 menit, menunjukkan kepada kita bahwa selain FAT32 dan HFS + yang sudah ada, terdapat tanda-tanda adanya volume dengan sistem file ExFAT. Hal pertama yang kami minati adalah melihat Direktori Root ExFAT volume.





Angka: 10 Direktori Root ExFAT



Label volume "Transcend" sangat mencolok. Yang aneh adalah drive eksternal dari pabrikan ini tersebar luas dalam faktor bentuk 2,5 inci, bukan 3,5. Dan sangat tidak mungkin bahwa pengguna sendiri pernah memutuskan untuk memasang label volume yang serupa.



Mari tuliskan nama-nama direktori yang dijelaskan di direktori root dan ajukan pertanyaan kepada klien tentang apakah itu informasi yang diperlukan.



Jadi, setelah lebih dari 10 menit berlalu, kami melanjutkan percakapan dengan klien, di mana ternyata dia bukan pemilik informasi dan tidak dapat menjelaskan data apa yang ada di disk, dan bahwa dia perlu menelepon manajer untuk mengklarifikasi tugas. ...



Selama dialog, dapat diasumsikan bahwa klien adalah kurir dari organisasi perantara di pasar layanan pemulihan data. Negosiasi lebih lanjut mengkonfirmasi versi ini, karena setelah klien mengumumkan informasi, jeda mengikuti untuk manajernya. Rupanya pengelola juga tidak mengetahui apa sebenarnya yang harus ada di dalam harddisk tersebut. Tetapi setelah sekitar 15 menit, klien menerima panggilan yang menginformasikan bahwa ini adalah data yang perlu diekstraksi, dan volumenya harus sekitar 2TB. Kami juga diberitahu bahwa kami telah disediakan untuk analisis dengan salinan sektor demi sektor dari media asli yang dibuat menggunakan WinHex.



Akhirnya, tugas menjadi jelas dan kita berada di jalur yang benar. Anda dapat berkendara lagi dari pelanggan dan melanjutkan untuk melanjutkan aktivitas diagnostik. Tentu saja, jika kita memiliki semua informasi ini sejak awal, prosedur diagnostik kilat akan jauh lebih singkat.



Untuk merekonstruksi ExFAT, kita perlu mengetahui berapa ukuran cluster untuk sistem file ini, dan menentukan posisi cluster nol (titik referensi). Selanjutnya, cari sisa tabel alokasi file dan bitmap ruang yang ditempati (Bitmap).



Sebuah kata tidak menyenangkan yang terpisah perlu dikatakan tentang pengembang ExFAT. Demi kinerja sistem file, diputuskan bahwa tabel hanya berisi informasi tentang rantai yang terfragmentasi. Data sebaris tidak muncul di tabel dengan cara apa pun. Membuat sistem file ini pada disk yang tidak kosong tidak menghapus tabel lokasi file dan mungkin berisi data sampah. Sayangnya, ideologi ini tidak mempengaruhi kerumitan pemulihan data.



Saat menganalisis 2GB pertama, bagian dari direktori ExFAT ditemukan. Setelah memperkirakan ukuran struktur ini dan selanjutnya mengisi dengan nol sebelum dimulainya data lain, mudah untuk menetapkan ukuran cluster. Setelah menjelajahi beberapa direktori, kami melihat interval yang diucapkan dari 256 (2048) sektor. Ini memungkinkan kami untuk mengasumsikan bahwa ukuran cluster adalah 1.048.576 (0x100000) byte atau 1 MB.



Untuk menentukan titik awal, mari kita lihat posisi direktori terdekat. Mengacu kembali ke Gambar 10. Secara khusus, kami tertarik pada direktori $ RECYCLE.BIN, karena letaknya hampir di awal. Nomor clusternya ditunjukkan pada offset 0x94 dan merupakan kata ganda (DW), yang di dalamnya tertulis nilai 0x00000005, yaitu direktori terletak di cluster 5. Perhatikan juga direktori "Xxxxxxxxxx Xxxx.photoslibrary", yang sesuai dengan nilai yang tertera pada offset 0xF4 , terletak di cluster 7. Direktori ini bagus karena ada kemungkinan besar bahwa ada sekumpulan direktori atau file yang dapat diprediksi.



Lebih jauh dari direktori root dengan langkah 0x100000 byte atau 256 (2048) sektor, gulir maju di ruang alamat.





Angka: 11 Direktori ExFAT, kemungkinan $ RECYCLE.BIN Kontennya



mirip dengan folder sampah kosong, di mana tidak ada yang dijelaskan kecuali untuk file "desktop.ini". Lokasi file di offset 0x34 menunjukkan cluster 6 dan ukuran 0x81 (129) byte. Mari maju 1 cluster lagi





Angka: 12 Isi dari file desktop.ini Isinya



sangat mirip dengan apa yang biasanya terlihat pada file "desktop.ini" dan berukuran 0x81 (129) byte. Ada alasan untuk percaya bahwa pada Gambar 11, folder $ RECYCLE.BIN, dan pada Gambar 11. 12 file dijelaskan di dalamnya. Jika asumsinya benar, maka di cluster berikutnya kita akan melihat direktori, dan isinya mungkin terlihat seperti folder perpustakaan foto khas untuk MacOS di Apple Macintosh.





Angka: 13 Direktori ExFAT, kemungkinan Xxxxxxxxxxxxxxx.photoslibrary



Seperti yang Anda lihat, asumsi tersebut ternyata benar, dan kami melihat nama-nama direktori yang diharapkan. Jumlah kecocokan di area ini dapat dianggap cukup dan menghitung titik nol dan posisi direktori root dari volume yang pernah ada.

Direktori root berada di cluster 4. Karena mendahului direktori $ RECYCLE.BIN yang nomor clusternya adalah 5.



Titik nol relatif terhadap $ RECYCLE.BIN harus berada pada jarak minus 5 cluster. Posisi $ RECYCLE.BIN 37888 (303 104) sektor. 5 cluster adalah 1280 (10 240) sektor. Dengan melakukan pengurangan sederhana, kita mendapatkan posisi yang diinginkan: 37.888 (303104) - 1.280 (10240) = 36.608 (292864) atau offset dari awal ruang logis dalam byte adalah 292.864 * 512 = 149.946.368 (0x8F00000).



Selanjutnya, dengan memiliki titik awal referensi, ukuran cluster, dan posisi direktori root, kami akan mencoba mengonfirmasi kebenaran asumsi kami dengan jumlah pemeriksaan yang jauh lebih besar.



Menggunakan alat Data Extractor, tidak begitu cepat melakukan ini untuk partisi ExFAT, jadi kami memasang disk di OS (dengan nonaktifkan tulis).





Angka: 14 Menu untuk memasang disk di OS di PC3000 Win 7 Utilitas disk Kami



menggunakan Image Explorer gratis dari pusat perangkat lunak, di mana, dengan membuka disk, kami dapat dengan cepat menulis parameter sistem file virtual dan mengevaluasi kebenaran asumsi.





ara. 15 Pohon direktori ExFAT yang Diperluas



Seperti yang Anda lihat pada tangkapan layar, direktori dan file ada di tempatnya, yang memungkinkan kita untuk menyimpulkan bahwa parameter sistem file ditentukan dengan benar.



Pada titik ini, aktivitas diagnostik dapat dihentikan dan kemudian daftar pekerjaan berikut dapat disepakati dengan klien:



1. Cari ekspresi reguler dalam seluruh ruang logika untuk menetapkan kemungkinan lokasi berbagai jenis data.



2. Setidaknya rekonstruksi satu bagian ExFAT.



3. Analisis persimpangan dengan data baru yang ditimpa.



4.Membangun peta terbalik dalam kaitannya dengan data yang ada pada sistem file yang direkonstruksi di dalam persimpangan dengan Bitmap dan mencari data pengguna di area ini, diikuti dengan menyortir yang ditemukan.



Dalam kasus perusahaan perantara, seperti biasa, panggilan dimulai, dan hanya setelah persetujuan dari pemilik akhir (yang hampir tidak menduga bahwa datanya akan dipulihkan di laboratorium kami) adalah persetujuan yang diberikan untuk melaksanakan pekerjaan tersebut.



Pekerjaan apa pun, bahkan dengan disk yang dapat diservis, masih dimulai dengan membuat salinan sektor demi sektor ke drive lain. Tindakan ini diperlukan agar drive klien tetap tidak berubah dan tidak ada inisiatif OS yang menyebabkan kerusakan data yang tidak dapat dibatalkan. Untuk disk 4TB, menyalin melalui port PC3000Express akan memakan waktu sekitar 10-12 jam.



Setelah membuat salinan, kami mulai mencari berbagai ekspresi reguler untuk mendapatkan gambaran tentang distribusi data dalam ruang logis, dan juga untuk melihat apakah ada tanda-tanda partisi dan sistem file lain pada disk ini.





Angka: 16 Hasil pencarian ekspresi reguler dalam seluruh drive



Hasil pemindaian mengungkapkan bahwa data pengguna pada disk jelas jauh lebih kecil daripada 2TB yang dideklarasikan oleh klien. Regex terakhir terletak di sektor 539 877 376 dan hingga akhir disk tidak ada yang lebih mirip dengan data pengguna yang ditemukan, kecuali untuk penanda akhir dari HFS + yang baru dibuat, meskipun disk tidak semuanya nol hingga bagian paling akhir. Kemungkinan drive berisi volume terenkripsi sebelum partisi ExFAT dibuat pada disk. Tidak ada lagi yang menjelaskan keberadaan hanya data yang "berisik".



Dalam kasus seperti itu, penting untuk mencocokkan hasil pencarian regex dengan bitmap.





Angka: 17 Fragmen sektor direktori root ExFAT



Pada offset 0x34, nomor cluster ditunjukkan 2 - ini adalah posisi bitmap di bagian ExFAT. Offset 0x38 menunjukkan ukuran struktur 0x0746F1 (476.913 byte atau 3.815.304 bit). Saat menganalisis struktur ini, ditemukan bahwa bit yang muncul di kartu hanya untuk 270GB pertama, dan kemudian, menurut kartu, bagian tersebut kosong. Artinya, bitmap cocok dengan hasil pencarian ekspresi reguler, tetapi keduanya bertentangan dengan kata-kata klien.



Tentu saja, jika ditemukan ketidakkonsistenan yang begitu serius, pekerjaan ditangguhkan dan Anda harus menghubungi klien perantara lagi dan mencoba mendapatkan jawaban atas pertanyaan:



1. Apakah mereka benar-benar membuat salinan lengkap sektor per sektor yang mereka berikan kepada kami untuk dianalisis?



2.Apakah pemilik benar-benar yakin bahwa disk ini berisi data 2TB?



3. Dan jika Anda yakin, apakah Anda setuju untuk melanjutkan pekerjaan pemulihan data karena mengetahui bahwa data di atas 270GB tidak dapat diterima di disk ini?



Kami mendapat jawaban untuk pertanyaan pertama melalui akses jarak jauh ke disk asli. Dan di editor disk, setelah menggulirnya dengan beberapa langkah besar, mereka membandingkannya dengan salinan yang kami miliki. Ternyata salinannya sudah lengkap.



Jawaban untuk pertanyaan kedua adalah bahwa pemilik informasi percaya bahwa dia melihat dengan pasti bahwa disk tersebut penuh dengan 2TB, tetapi tidak lagi yakin akan hal ini.



Tetapi dengan semua kepercayaan klien bahwa ada lebih banyak data, masih ada persetujuan yang diberikan untuk melanjutkan pekerjaan.



Sebelum membangun kembali sistem berkas, disarankan untuk mengetahui berapa banyak direktori yang terfragmentasi. Untuk melakukan ini, ambil hasil analisis kasar dan lihat ukuran direktori yang ditemukan. Jika ada direktori dengan ukuran record yang sama dengan ukuran cluster, maka kemungkinan besar terjadi fragmentasi, jika ukuran record lebih kecil dari ukuran cluster, maka kita dapat mengasumsikan bahwa tugas sangat disederhanakan dan tidak diperlukan penyambungan manual dari fragmen direktori.





Angka: 18 Daftar direktori ExFAT yang ditemukan



Dalam kasus ini, tidak ada komplikasi tambahan yang ditemukan, ukuran maksimum entri dalam direktori adalah 629.984 byte, yang secara nyata lebih kecil dari ukuran cluster.



Anda juga perlu menandai semua area yang ditempati oleh struktur file yang baru dibuat. Untuk melakukan ini, kami akan membangun peta lokasi semua struktur dan file pada partisi FAT32 dan HFS +.





Angka: 19 Peta struktur dan data pada volume HFS +



Mari kita isi tempat-tempat ini pada salinan dengan pola yang akan mudah dibedakan dari data pengguna mana pun, dan juga dalam tugas penyalinan untuk area ini kita akan mengubah legenda dari berhasil membaca menjadi membaca dengan kesalahan. Ini akan diperlukan untuk deteksi lebih lanjut dari file yang rusak oleh penimpaan.



Untuk penggunaan lebih lanjut yang lebih nyaman dari alat analitik Ekstraktor Data, penting untuk menjelaskan bagian dalam tabel partisi dan membuat sektor boot untuk partisi ExFAT.





Angka: 20 Tabel partisi dengan volume ExFAT terdaftar



Pada offset 0x1D2, masukkan jenis volume 0x07. Jenis ini digunakan untuk NTFS dan ExFAT.

Pada offset 0x1D6, penunjuk ke awal volume ExFAT. Biarlah 32 sektor (0x20).

Pada offset 0x1DA, tulis ukuran volume maksimum yang diizinkan untuk tabel partisi klasik (meskipun nilai ini kurang dari ukuran volume sebenarnya, tetapi dalam hal ini dapat diterima, karena kami tidak berencana untuk memasang volume yang rusak ini di OS mana pun, dan kami memerlukan nilai bukan nol hanya untuk pengoperasian normal alat Data Extractor).





Angka: 21 Sektor boot ExFAT



Karena Ekstraktor Data sangat sensitif terhadap konten sektor boot ExFAT, mengisi hanya bidang penting seringkali tidak cukup (yang tidak terlalu logis), dan sangat mudah untuk menampilkan bagian tersebut di penjelajah internal, seperti dalam diagnostik di Penjelajah Gambar, bukan bekerja. Oleh karena itu, dalam kasus sektor boot ExFAT, lebih baik mengambil templat standar dan memasukkan nilai yang benar ke dalamnya.



Demi kenyamanan kami, kami akan menulis sektor boot dalam bentuk jika drive digunakan sebagai perangkat dengan sektor 512 byte. Ini akan memberi kita pengoperasian yang benar dari semua alat kompleks tanpa membangun kembali peta yang tidak perlu.



Isi kolom:

Bytes Per Block- jumlah byte di sektor ini. ExFAT menentukan kekuatan yang harus dinaikkan 2 untuk mendapatkan ukuran.

Block per Cluster - jumlah sektor dalam cluster. Ini juga menunjukkan sejauh mana Anda perlu menaikkan 2 untuk mendapatkan kuantitas.

Total Cluster Jumlah cluster yang tersedia pada volume. Kami memasukkan nilai 3 815 304. Ini diperoleh dengan mengalikan ukuran bitmap dengan 8.

Total Blok - jumlah sektor. Nilai diperoleh dengan mengalikan Total Cluster dengan ukuran cluster (yang pada gilirannya diperoleh dengan mengalikan Bytes per Block dengan Blocks per Cluster)

FAT offset- offset dari sektor boot ke tabel alokasi file. Mari buat struktur kosong dan letakkan dari sektor 64. Tambahkan judul standar padanya.

Block Per FAT - jumlah sektor yang ditempati tabel FAT. Ukurannya mudah dihitung berdasarkan jumlah cluster. Block Per FAT = Total Clusters / (Bytes per Block / 4) dengan pembulatan lebih lanjut ke bilangan bulat terdekat. 3815304 / (512/4) = 29807, 0625 = 29808.

(Tidak peduli seberapa keras beberapa sumber mencoba memanggil ExFAT sebagai sistem file 64-bit, tabel alokasi file adalah 32-bit, tetapi, tidak seperti FAT32, untuk 32 bit digunakan untuk pengalamatan, bukan 28.)

Jumlah FAT - jumlah salinan tabel. Sayangnya, saat membuat partisi, biasanya menggunakan 1.

Cluster Heap Offset- menunjukkan offset ke bitmap di sektor.

Root Dir Cluster - nomor cluster dari direktori root.



Setelah bagian tersebut tersedia di penjelajah Data Extractor, kita akan membuat peta ruang yang ditempati menggunakan bitmap.





Angka: 22 Peta ruang yang ditempati oleh struktur ExFAT dan data pengguna menurut bitmap.



Kami juga akan membuat peta lokasi file berdasarkan catatan file yang ada, mengurutkan berdasarkan urutan lokasi file di disk, dan membandingkan dengan data bitmap.





Angka: 23 Fragmen peta lokasi file yang tersedia pada volume ExFAT Berdasarkan



hasil pembuatan peta lokasi file, kami mengamati "lubang" yang agak luas pada rentang logis dari 718 528 hingga 57 131 008. Pada bitmap terlihat jelas bahwa area ini ditempati oleh data pengguna. Juga, saat mencari ekspresi reguler di seluruh disk, tanda data ditemukan di area ini.



Dalam hal ini, fakta kerusakan pada sistem file ini dan kebutuhan untuk tindakan analitis lebih lanjut dikonfirmasi.



Balikkan peta lokasi file untuk mendapatkan daftar rantai ruang yang tidak dijelaskan oleh catatan file yang ada. Kami menghapus semua rantai, yang ukurannya kurang dari ukuran cluster, karena ini akan menjadi fragmen gratis dari cluster yang tidak sepenuhnya ditempati oleh data pengguna yang ditulis kepadanya. Kami memetakan ke bitmap dan hanya menyisakan string yang tumpang tindih dari rentang ini.



Hasil yang tersisa akan dianalisis lebih lanjut - mencari direktori ExFAT. Mari buat direktori di mana kita akan membentuk entri - penunjuk ke direktori yang ditemukan, serta memasukkan entri dari fragmen direktori yang ditemukan. Direktori yang ditemukan harus diperiksa untuk konten entri yang bersinggungan dengan direktori yang tersedia, menetapkan hubungannya, dan juga memeriksa korespondensi dari header file yang ditunjukkan oleh entri dalam direktori ini dan menyaring direktori yang tidak relevan. Hilangnya direktori dapat disebabkan oleh kesalahan dalam sistem file selama eksploitasi disk, atau oleh tumpang tindih sebagian data baru yang ditulis ke disk.





Angka: 24 Direktori dengan pointer ke struktur yang ditemukan yang tidak memiliki objek induk.



Selanjutnya, setelah melengkapi peta lokasi file dengan objek yang ditemukan di direktori yang hilang, kami akan melanjutkan untuk mengulangi prosedur dengan pembuatan peta terbalik dengan mempertimbangkan persimpangan dengan bitmap. Dalam rantai yang diperoleh dengan cara ini, ekspresi reguler perlu dicari untuk berbagai jenis file pengguna.



Ini adalah tahap akhir dari pekerjaan analitis, yang hasilnya adalah sisa data pengguna, yang tidak memiliki elemen sistem file yang menjelaskan lokasinya. Harap dicatat bahwa langkah-langkah ini membantu kami untuk tidak memasukkan berbagai sampah dari data yang sebelumnya dapat dihapus sebelumnya oleh pengguna sendiri dalam hasil akhir.



Setelah menyelesaikan operasi ini, Anda dapat mulai menyalin data yang ditemukan, dengan mempertimbangkan keberadaan di peta lokasi sektor file "membaca dengan kesalahan" dan dengan demikian menyingkirkan file yang secara unik ditimpa dengan data baru. Kami membuat tanda "baca dengan kesalahan" setelah membuat peta fitur FAT32 dan HFS +.



Ini menyelesaikan pekerjaan. Hasil maksimum yang mungkin dari file yang tidak terfragmentasi diperoleh dengan tetap mempertahankan hierarki direktori asli, dan hampir semua kemungkinan file yang hilang ditemukan tanpa menyertakan hasil ini berbagai data sampah yang khas untuk program pemulihan otomatis.



Posting sebelumnya: Diagnostik mandiri hard drive dan pemulihan data



All Articles