Artikel ini ditujukan untuk mempelajari struktur file hard disk dari perekam video delapan saluran untuk tujuan ekstraksi massal file video. Pada akhir artikel adalah implementasi program yang sesuai dalam C.
Perekam video (disingkat DVR) QCM-08DL digunakan dalam sistem pengawasan video dan memungkinkan perekaman video dan audio delapan saluran. Model ini, menurut saya, adalah salah satu yang termurah dan sekaligus dapat diandalkan dalam pengoperasian. Format kompresi video adalah format H264 yang populer. Untuk audio, format kompresi adalah ADPCM. Video dan audio direkam pada hard drive SATA (HDD) komputer standar yang dipasang di dalam DVR. Dengan menggunakan DVR itu sendiri, dimungkinkan untuk melihat rekaman dengan mencari berdasarkan tanggal dan waktu. Juga, dimungkinkan untuk mengekstraksi data ke file pada media eksternal. Pertama, ke drive USB yang terhubung ke antarmuka USB DVR. Kedua - ke komputer melalui antarmuka WEB dari DVR. Nama file yang dihasilkan panjang, dan termasuk tanggal perekaman, waktu mulai dan waktu selesai, saluran rekaman dan informasi tambahan lainnya. Ekstensi file adalah ".264". Pemeriksaan terhadap isi file semacam itu menjelaskan kepada saya bahwa wadah media di mana stream audio dan video dikemas jauh dari standar. File seperti itu dapat dibuka menggunakan pemutar yang disertakan dengan DVR. Pemain itu sangat tidak nyaman. Tetapi juga, Anda dapat menggunakan program repacker ke wadah AVI, yang juga disertakan. Program ini mengemas ulang aliran video, meninggalkannya dalam format H264. Dan aliran suara mengkonversi dari ADMCM ke PCM, meningkatkannya 4 kali ukurannya. Hasilnya adalah file .avi yang dapat dimainkan oleh pemain standar mana pun. Saya segera mencatat bahwa program pengemasan ulang ini sangat merepotkan. Ini memungkinkan Anda untuk melakukan operasi hanya pada satu file. Untuk mengemas ulang satu set file, Anda harus membukanya secara bergantian.
Tugas-tugas berikut telah ditetapkan.
- Dapatkan akses ke semua file .264 dari hard disk DVR dengan menghubungkan hard disk ke komputer.
- Untuk mempelajari algoritma di mana program repacker standar 264-avi bekerja dan membuat program yang sama yang akan melakukan operasi yang sama, tetapi tidak pada satu, tetapi pada seluruh kelompok file, dengan satu klik.
Sekilas, tugas pertama mungkin tampak sangat sederhana: Anda hanya perlu menghubungkan HDD ke komputer dan membuka partisi di Explorer. Namun, ada jebakan. Artikel ini dikhususkan untuk tugas pertama.
Saya sudah tahu sebelumnya bahwa shell perangkat lunak dari mikrokontroler DVR didasarkan pada sistem operasi yang mirip dengan Linux. Oleh karena itu, partisi hard disk kemungkinan besar juga akan seperti Linux. Karena itu, Anda memerlukan komputer Linux. Dalam kasus saya, kapasitas HDD adalah 1TB, komputer dengan OS Xubuntu. Setelah menghubungkan HDD ke komputer, saya hanya dapat melihat satu partisi per beberapa gigabytes. Ini jelas bukan yang Anda butuhkan. Di dalam bagian itu ada banyak folder dengan format nama "YYYY-MM-DD" yang sesuai dengan tanggal catatan. Di dalam setiap folder ada banyak file yang sesuai dengan entri. File dengan nama yang sama dengan yang diperoleh saat mengekstraksi dari DVR. Namun, ukurannya berkali-kali lebih kecil dan ekstensi tidak .264, tetapi .nvr. Harus diasumsikan bahwa file nvr yang sama ini adalah kunci untuk 264 file yang sesuai (atau stream medianya), yang isinya terletak di ruang HDD utama. Saya menyalin data dari folder file ke media terpisah untuk penelitian lebih lanjut.
Saya menggunakan banyak alat perangkat lunak untuk penelitian: disk editor (ini juga merupakan file editor biner) DiskExplorer (saya menggunakan WinHex nanti), MS Excel untuk perhitungan tambahan dan memperbaiki hasil, lingkungan pemrograman Dev-C ++ untuk menulis program konsol tambahan dan final, dll. Pada artikel ini saya akan mencoba membahas tentang prosedur ini.
Pertama, lihat sektor HDD pertama (satu sektor (1 LBA) membutuhkan 512 Bytes). Sektor ini, sebagai suatu peraturan, mengandung struktur MBR. Ini termasuk bootloader dan daftar isi dasar tabel. Struktur sektor ini, serta struktur deskripsi bagian, diberikan di bawah ini (diambil dari Wikipedia).
Dalam kasus HDD yang diselidiki, kami memiliki yang berikut ini. Melihat gambar di bawah dan mengikuti tabel di atas, kita melihat bahwa bootloader tidak ada. Tapi kami lebih tertarik pada tabel partisi. Itu disorot dalam bingkai merah. Dua byte terakhir (isi biru) - tanda tangan MBR. Anda dapat melihat dari tabel partisi bahwa disk dibagi menjadi dua bagian. Kode untuk jenis bagian pertama (isian kuning) adalah 0x0B. Ini adalah partisi FAT32. Kode untuk tipe yang kedua (isian oranye) adalah 0x83. Ini adalah salah satu partisi Linux (dalam arti EXT). Byte kode jenis partisi dilingkari dengan warna biru.
Dekripsi lengkap sektor MBR dengan tabel bagian dan parameternya diberikan di bawah ini.
Memperhatikan ukuran partisi (menghitung jumlah sektor dalam gigabytes), mudah ditebak bahwa pada komputer dengan OS Xubuntu itu adalah partisi pertama yang menempati sebagian kecil ruang disk. Ngomong-ngomong, di Windows XP hanya partisi pertama juga ditampilkan, tetapi tidak terbuka dari explorer. Dan mengapa, kemudian, partisi Linux kedua tidak muncul di OS Xubuntu?
Setelah sebelumnya mempelajari struktur dan organisasi sistem file Linux menggunakan EXT2 sebagai contoh, saya mulai mempelajari bagian kedua.
Seperti yang dapat Anda lihat dari tabel bagian, bagian kedua dimulai dengan sektor 16016805. Manual sistem file EXT2 menunjukkan keberadaan yang disebut superblock, yang terletak di 1024 byte dari awal bagian (yaitu, dua sektor dari awal). Namun, sektor 16016805 + 2 = 16016807 kosong. Tetapi sektor pertama 16016805 dalam strukturnya menyerupai superblok. Tetapi isinya tidak sepenuhnya sesuai dengan deskripsi isi superblok dari manual. Superblock adalah blok utama, yang berisi semacam tabel berbagai konstanta dan parameter untuk fungsi sistem file: alamat posisi dan ukuran blok lain yang diperlukan, khususnya, header catatan file dan direktori. Penelitian lebih lanjut dalam bagian ini hanya mengarahkan saya pada satu kesimpulan: DVR menggunakan sistem file uniknya sendiri.
Di masa depan, saya memutuskan untuk melihat sektor pertama dari bagian pertama (sektor 63) dan gulir ke bawah. Itu ditemukan pada sektor 65 (dua sektor di bawah) konten yang benar-benar mirip dengan isi superblok FS EXT2, yang dijelaskan dalam manual. Penelitian lebih lanjut mengarah pada kesimpulan bahwa partisi HDD DVR pertama adalah partisi EXT2, yang ditampilkan pada OS Xubuntu, terlepas dari tanda 0x08 (bukan EXT) dalam daftar isi! Dengan demikian, partisi pertama hard drive DVR adalah partisi EXT2, di mana file nvr direkam, yang merupakan kunci untuk rekaman video yang diperlukan.
Saya akan menulis secara singkat tentang struktur file .264, yang juga saya periksa sebelumnya. Informasi ini akan diperlukan di masa depan untuk mempelajari bagian kedua HDD. Seperti dalam wadah media apa pun, dalam “264” ada header dengan informasi layanan dan tag media, serta aliran audio dan video yang mengikuti blok kecil satu demi satu. Pada offset 0x84 byte dari awal file, kata kunci "MDVR96NT_2_R" terdaftar. Sebelum kata ini adalah byte yang terkait dengan tanggal dan waktu perekaman. Tetapi informasi ini terkandung dalam nama file, oleh karena itu, tidak pantas mendapat perhatian khusus di sini. Setelah itu muncul banyak byte nol. Informasi utama dengan stream audio dan video berasal dari offset 65.536 byte. Blok aliran video dimulai dengan header 8 byte "01dcH264" (juga ditemukan "00dcH264"). 4 byte berikut ini menjelaskan ukuran blok saat ini dari aliran video dalam byte. Setelah 4 byte nol (00 00 00 00), blok aliran video itu sendiri dimulai. Blok stream audio memiliki judul "03wb" (meskipun, menurut pengamatan saya, karakter pertama dari header dalam beberapa kasus belum tentu "0"). Setelah - 12 byte informasi yang saya belum tahu. Dan dimulai dengan byte ke-17 - aliran audio dengan panjang tetap 160 byte. Tidak ada tag di akhir file.
Kami melanjutkan untuk mempelajari struktur file dan direktori yang terletak di partisi pertama HDD. Seperti disebutkan di atas, isi bagian disalin ke media yang terpisah melalui penjelajah biasa di OS Xununtu. Di setiap direktori (direktori), selain file nvr, ada satu file biner bernama "file_list". Dilihat dari namanya, ini berisi informasi tentang daftar file dalam direktori saat ini. Buka file ini di editor biner (lihat gambar di bawah). Saya menyelidiki struktur file ini, dan pada dasarnya tidak ada yang menarik di sini. File tidak memiliki informasi mengenai lokasi stream media yang diinginkan. Meskipun demikian, saya akan menulis secara singkat tentang struktur ini. 32 byte pertama adalah header dengan beberapa konstanta. 16 byte berikutnya terkait dengan tanggal dan waktu dan jumlah file dalam direktori saat ini. Ini diikuti oleh 48 byte konstanta. Berikutnya - 8 byte konstanta, yang menunjukkan awal catatan file. Selanjutnya, 96 byte yang menunjukkan path lengkap ke file nvr, termasuk namanya. Berikutnya - 24 byte yang terkait dengan waktu (jumlah detik berlalu dari awal hari, awal dan akhir video) dan atribut lain dari video. Dan seterusnya, dengan analogi, untuk semua file nvr di direktori saat ini. Jumlahnya sama dengan jumlah video untuk hari ini, ditunjukkan dengan nama direktori saat ini. Untuk apa file ini? Rupanya, untuk mempercepat pencarian video dalam antarmuka DVR.
Mari kita lanjutkan mempelajari struktur file nvr sendiri. Tampilan satu file seperti itu dalam editor biner (lebih tepatnya, dalam heksadesimal) ditunjukkan pada gambar di bawah ini. Tanpa merinci deskripsi struktur konten (bagian yang tetap menjadi misteri bagi saya), saya menyoroti parameter paling dasar, yang merupakan kunci untuk ditemukan. Ini adalah nilai 32-bit (4-byte), yang terletak setiap 32 byte, mulai dari byte pada offset 40. Pada gambar tersebut disorot dalam warna merah. Di masa depan, saya menjadi yakin bahwa ini cukup untuk kunci video. Saya mengingatkan Anda bahwa 4 byte dari nilai parameter kunci ini terletak dari yang terendah ke yang tertinggi, tetapi tidak sebaliknya! Notasi ini disebabkan oleh arsitektur prosesor PC. Contoh pada gambar menunjukkan file nvr pertama dari direktori pertama. Ini sesuai dengan rekaman video pertama yang dibuat oleh DVR. Jelas, nilai-nilai parameter, yang saya sebut kunci, dalam contoh di atas membentuk urutan bilangan bulat, mulai dari nol dan berjalan dalam urutan menaik. Memeriksa file nvr lainnya, dan melihat dengan tepat byte yang ditentukan di dalamnya, bilangan bulat juga terlihat, naik. Tetapi urutan ini secara alami mulai bukan dari awal lagi, dan dalam beberapa kasus kesenjangan dalam satu atau dua angka diamati di beberapa tempat. Misalnya (angka dari bulldozer): 435, 436, 438, 439, 442, ... (atau dalam heksadesimal: B3010000, B4010000, B6010000, B7010000, B010000, BA010000, ...).
Urutan dengan kelalaian tersebut terjadi pada file nvr yang sesuai dengan video yang direkam oleh DVR secara bersamaan dari dua atau lebih saluran. Misalnya, jika urutan "435, 436, 438, 439, 442, ..." mengacu pada video dari satu saluran, maka nilai yang hilang (437, 440, 441) akan terkait dengan video dari saluran lain, yang dilakukan dalam titik waktu. Saya sendiri yakin akan hal ini dengan melihat dan membandingkan file nvr yang sesuai, berdasarkan nama mereka. Tidak ada keraguan bahwa angka-angka di atas membentuk angka dari beberapa bagian yang terkait dengan video. Tetap hanya untuk mengungkap hubungan antara angka-angka ini dan koordinat ruang disk tempat data berada.
Juga, itu untuk mencari tahu data apa yang dibagi ke dalam segmen bernomor di atas? Asumsi pertama - data aliran audio dan video, yang dalam wadah 264 diwakili oleh blok pendek, dan, seperti telah dikatakan, blok aliran video memiliki ukuran yang berbeda. Pada saat yang sama, DVR mengumpulkan aliran ini dan mengemasnya ke dalam wadah 264 pada tahap mengekstraksi rekaman video ke media eksternal. Asumsi kedua adalah bahwa paket DVR memasukkan aliran audio dan video ke dalam wadah 264 di awal dan selama pengambilan video. Dan pada saat yang sama, data file .264 yang sudah dihasilkan ditulis ke HDD, yang akan berubah sebagai hasil ekstraksi ke media eksternal. Menjelajahi ruang HDD di suatu tempat di tengah bagian kedua, bersama dengan byte stream audio dan video dan header mereka dari jenis yang sama seperti dalam wadah 264, saya juga menemukan header dari wadah itu sendiri: MDVR96NT_2_R. Setelah tajuk ini, ada juga banyak byte nol. Secara umum, penelitian menunjukkan bahwa ada opsi kedua dari dua di atas. Oleh karena itu, untuk mendapatkan file .264 yang diinginkan, kemungkinan besar, Anda hanya perlu menghubungkan semua segmen yang jumlahnya terkandung dalam file nvr yang sesuai.
Mari kita mulai mencari hubungan antara nomor segmen dan koordinat pada HDD.
Awal data kontainer 264 yang sesuai dengan rekaman video pertama (di mana penomoran segmen dimulai dari nol) dengan alat pencarian yang saya temukan di sektor 16046629 (29.824 sektor dari awal bagian). Kita dapat membuat asumsi tentang apa yang disebut parameter bias awal, yang akan berpartisipasi dalam formula yang menggambarkan ketergantungan yang diinginkan.
Mari kita ambil dua file nvr yang sesuai dengan video dari saluran berbeda yang ditangkap oleh DVR pada saat yang bersamaan. Untuk melakukan ini, lihat nama file. Misalnya, video yang ditunjukkan oleh file "ch00000000000001-150330-160937-161035-02p101000000.nvr" dan "ch00000000000004-150330-160000-163000-00p004000000.nvr" direkam secara bersamaan. Rekaman pertama adalah rekaman dari saluran pertama dari 16:09:37 hingga 16:10:35 waktu. Rekor kedua adalah catatan dari saluran ke-4 dari pukul 16:00 sampai 16:30 waktu. Kedua entri dibuat pada 30 Maret 2015. Pada timeline, jelas, interval waktu dari catatan pertama adalah subset dari interval waktu dari catatan kedua. Saya juga memperhitungkan fakta bahwa dalam interval waktu yang lebih pendek (di persimpangan dua interval) DVR tidak melakukan pengambilan video dari salah satu dari 6 saluran lainnya. Jelajahi isi file nvr ini. Kami akan memastikan bahwa nomor yang hilang (nomor segmen) dalam file panjang kedua harus ada dalam file pendek pertama, secara lengkap dan lengkap. Menggunakan DVR dengan cara biasa, Anda perlu mengekstrak setidaknya satu dari .264 file yang dirujuk oleh file nvr yang diinvestigasi sebelumnya. Katakanlah “ch00000000000001-150330-160937-161035-02p101000000.264” diekstraksi. Buka di editor biner. Seperti yang telah disebutkan, di awal file ini, sebelum kata kunci “MDVR96NT_2_R” ada byte unik yang sesuai dengan tanggal dan waktu rekaman video yang terkandung dalam file ini. Kami menghapus semua byte ini, mulai dari nol dan diakhiri dengan header (semakin pendek rantai byte ke rekaman video ini, semakin baik). Juga, tulis offset string byte ini dari awal file. Perlu dicatat bahwa pada awal file .264 yang diekstraksi ada tambahan 4 byte nol. Ini menjadi terlihat dengan membandingkan 512 byte pertama dari file .264 dan sektor ruang disk darimana isi dari salah satu file .264 dimulai (file dari hampir semua sistem file selalu dimulai pada awal sektor, apalagi, sebuah cluster). Artinya, informasi dalam file .264 digeser di muka oleh 4 byte ke kanan. Ukuran (dalam byte) dari file .264 mana pun adalah kelipatan 512 hanya setelah terlebih dahulu mengurangi angka 4 dari ukuran. Mari kita mulai mencari sektor dari mana file .264 yang diinvestigasi dimulai. Di editor disk, mulai fungsi pencarian. Di bidang nilai yang diinginkan, masukkan string byte unik yang dihapus sebelumnya. Untuk mempercepat pencarian, masukkan nilai offset di bidang “search by offset”, yang sebelumnya dikurangi 4. Mulai pencarian. Beberapa jam kemudian, pencarian berhasil. Kami menuliskan jumlah sektor di mana judul unik ditemukan. Biarkan ini menjadi nilai s. Kami melihat isi file nvr untuk video ini. Kami menghapus nomor segmen pertama (4 byte pada offset 40). Biarkan ini menjadi nilai b. Secara total, sementara kita tahu nomor sektor disk (16046629) untuk nomor segmen nol (dalam perekaman video pertama) dan jumlah sektor yang ditemukan dari disk untuk nomor segmen b baru saja dihapuskan. Anda dapat menghitung taksiran ukuran segmen: (s-16046629) / (b-0). Setelah menghitung, saya mendapat nilai 128. Jadi, ukuran segmen sama dengan 128 sektor disk (LBA), atau 128 * 512 = 65536 byte!
Saya melakukan percobaan menarik lainnya untuk akhirnya menghilangkan semua keraguan. Dijelaskan di bawah ini.
Dari awal sektor, kami memilih area pada disk dengan ukuran yang sebanding dengan ukuran file .264 yang dimulai dengan sektor ini. Jika tebakan saya benar, maka segmen file .264 lainnya, yang ditangkap pada HDD bersamaan dengan yang pertama, akan jatuh ke area yang dipilih. Simpan area ini ke file (buat gambar). Potong gambar yang dihasilkan menjadi file 65.536 byte (ukuran segmen). Ini dapat dilakukan dengan menggunakan fungsi "file terpisah" di Total Commander. Biarkan menjadi potongan M1, M2, M3, .... Demikian pula, kami memotong file .264 yang dipelajari (yang diekstraksi dengan cara yang ramah pengguna dari DVR), tetapi pertama-tama menghapus 4 byte nol terlebih dahulu. Biarkan menjadi potongan K1, K2, K3, .... Menggunakan fungsi "Bandingkan dengan Konten" di Total Commander, kami membandingkan potongan gambar dan potongan dari file .264. (M1 dengan K1, M2 dengan K2, dll.), Dipandu oleh nomor segmen dari file nvr yang sesuai. Hasilnya adalah sebagai berikut.
Misalkan (angka dari bulldozer), rantai angka dalam nvr adalah sebagai berikut: 435, 436, 438, 439, 442, ... Dalam situasi ini, M1 = K1, M2 = K2, M4 = K3, M5 = K3, M5 = K4, M8 = K5, .... Yaitu, potongan-potongan di mana file gambar dipecah dan file .264 berubah menjadi sama satu sama lain, dengan mempertimbangkan kemajuan yang sesuai dalam jumlah potongan file gambar, sesuai dengan kelalaian dalam urutan. Ini dia!Secara total, kami mendapatkan ketergantungan yang diperkirakan: S = 16046629 + 128 * d, di mana d adalah nomor segmen dalam file nvr, dan S adalah nomor sektor pada HDD, dimulai dari awal disk tempat isi segmen dimulai. Ukuran segmen - 128 sektor. Formula di atas tidak memperhitungkan keberadaan bagian kedua. Ketergantungan hanya ditemukan untuk contoh spesifik dari HDD ke 1TB. Mungkin jika Anda menempatkan kapasitas yang berbeda dalam DVR HDD, konstanta akan mengambil tampilan yang berbeda.Untuk memverifikasi validitas rumus, kami menghitung posisi segmen pertama dari beberapa file .264 sewenang-wenang, dipandu oleh file nvr yang sesuai. Memperhatikan tanggal dan waktu dalam nama file, bandingkan dengan byte pertama di header .264 yang terletak di sektor terhitung. Byte yang menyandikan secara individual nomor, bulan, tahun, jam, menit, detik, sesuai dengan data sementara dalam nama file. Karena itu, "pukul kuku"! Kami menghitung dalam file nvr yang sesuai dengan file .264 yang diekstraksi terlebih dahulu, jumlah segmen cs. Secara umum, jumlah mereka adalah cs = sf / 32-1, di mana sf adalah ukuran file nvr. Jika file .264 terdiri dari segmen cs, maka ukurannya harus sama dengan cs * 65536 + 4 (jumlah segmen dikalikan dengan ukuran segmen dalam byte, ditambah 4 byte yang sama dengan nol). Dan memang benar!Tetap saja, coba jelajahi bagian kedua. Seperti disebutkan sebelumnya, sesuatu yang mirip dengan superblock terletak langsung di sektor pertama bagian (16016805). Dan salinan persisnya ditemukan oleh tujuh sektor di bawah ini (16016812). Jelas, informasi dasar non-nol ada di sektor pertama superblok. Penampilannya di editor disk ditunjukkan pada gambar di bawah ini.
Saya berhasil mendekripsi bagian dari parameter 4-byte. Tanggal dan waktu pemasangan partisi disorot dengan warna biru. Tanggal dan waktu disajikan dalam notasi khusus "Waktu Unix" (jumlah detik berlalu sejak tengah malam pada 1 Januari 1970). Dalam contoh di atas, "03 7E 74 54" (nilai desimal 1416920579) sesuai dengan "Sel, 25 Nov 2014 13:02:59 GMT". Untuk menerjemahkan nilainya, saya menggunakan kalkulator online khusus. Nilai 65536 dilingkari dalam bingkai ungu. Ada kemungkinan bahwa penafsir sistem file di dalam program DVR mengacu pada posisi superblok ini ketika ukuran blok dibaca (dalam konteks sebelumnya, saya menyebut segmen blok). Nilai-nilai 1 disorot dalam bingkai hijau. Salah satunya mungkin menunjukkan posisi awal yang disebut. bitmap (dalam jumlah blok dari awal bagian). Memangsebelumnya, informasi awal ditemukan, sesuatu yang mirip dengan bitmap pada sektor 16016933 (16016805 + 128 * 1). Nilai 233 disorot dalam bingkai merah. Inilah posisi awal rekaman video .264 ini dari awal bagian: 16016805 + 128 * 233 = 16046629.Yaitu, bagian kedua dapat disebut bagian EXT2 yang terpotong dan sedikit dimodifikasi. Memiliki superblock, salinannya, bitmap. Tapi tidak ada yang disebut. node informasi yang berkaitan dengan catatan file. Bagian ini berisi data file .264 (stream audio dan video), tetapi node informasi (katakanlah demikian) untuk data ini terletak di file nvr pada bagian pertama. Mungkin ada kata-kata yang lebih kompeten? Tapi ini tidak begitu penting bagiku.Mari kita menulis program sederhana untuk ekstraksi massal file .264. Saya harus segera mengatakan bahwa saya tidak memiliki banyak pengalaman dalam pemrograman pada Windows. Program memindai semua file nvr yang disalin terlebih dahulu ke bagian 1TB dari HDD baru. Dengan menganalisisnya, program membuat file .264 dengan nama yang sama di direktori yang sama, menggunakan akses ke sektor-sektor HDD asli. Sebelumnya, folder dengan nama "DVR" dibuat di bagian kosong HDD baru, di mana folder berdasarkan tanggal ditempatkan, yang disalin dengan "cara biasa" di Linux. Dimungkinkan untuk memasukkan dalam program ini suatu algoritma untuk bekerja dengan partisi Linux pertama untuk mengakses file nvr sehingga tidak harus menyalinnya terlebih dahulu. Dan Anda dapat menambahkan fitur nyaman lainnya. Ya, itu mungkin, tetapi pada saat itu saya ingin melakukan segalanya secepat mungkin.Saya tidak menggunakan rekursi untuk memindai direktori, mengingat format direktori sudah diperbaiki dan memiliki dua tingkat lampiran. Oleh karena itu, saya menerapkan dua siklus: jalankan melalui folder sampai berakhir, dan jalankan melalui file di setiap folder dengan kondisi yang sama. Untuk membaca file, saya menggunakan fungsi fopen. Untuk bekerja dengan sektor HDD, saya menggunakan fungsionalitas WinAPI mirip dengan bekerja dengan file. Mari kita beralih ke kode program.Perpustakaan membutuhkannya.#include <windows.h> #include <stdio.h> #include <string.h>
Dan saya benar-benar menyalin fungsi-fungsi ini dari beberapa forum.
HANDLE openDevice(int device) { HANDLE handle = INVALID_HANDLE_VALUE; if (device <0 || device >99) return INVALID_HANDLE_VALUE; char _devicename[20]; sprintf(_devicename, "\\\\.\\PhysicalDrive%d", device);
Fungsi salin berisi rumus ketergantungan linear, yang muncul dalam teori di atas.
void copy(HANDLE device, HANDLE file, unsigned long int s){ LONG HPos; LONG LPos; __int64 sector; sector = 16046629+128*s; HPos = (sector*512)>>32; LPos = (sector*512); SetFilePointer (device, LPos, &HPos, FILE_BEGIN); DWORD dwBytesRead; DWORD dwBytesWritten; unsigned char buf[65536]; ReadFile(device, buf, 65536, &dwBytesRead, NULL); WriteFile(file, buf, dwBytesRead, &dwBytesWritten, NULL); }
Fungsi utamanya juga cukup sederhana.
int main(){ HANDLE hdd = openDevice(1);
Pada komputer lama dengan prosesor Pentium 4 dan pengontrol PCI SATA, program tersebut berhasil mentransfer ke HDD penuh dengan beberapa ribu .264 file dalam rata-rata 7 jam. Di komputer baru - tiga kali lebih cepat. Seperti yang sudah saya catat, program ini tidak universal, semua konstanta dan variabel disesuaikan dengan kasus spesifik saya dari HDD ke 1TB. Namun, Anda dapat bekerja sedikit lebih banyak dan membuatnya universal, menggambar antarmuka grafis untuk itu.
Pada bagian kedua artikel ini saya akan menulis bagaimana "melakukannya sendiri" untuk mengemas kembali dari wadah "264" ke wadah "avi" standar.