Cet article est consacré à l'étude de la structure des fichiers du disque dur d'un enregistreur vidéo à huit canaux à des fins d'extraction de masse de fichiers vidéo. À la fin de l'article se trouve la mise en œuvre du programme correspondant en C.
Enregistreur vidéo (DVR abrégé) QCM-08DL est utilisé dans les systèmes de vidéosurveillance et permet l'enregistrement vidéo et audio à huit canaux. Ce modèle, à mon avis, est l'un des moins chers et en même temps fiable en fonctionnement. Le format de compression vidéo est le format H264 populaire. Pour l'audio, le format de compression est ADPCM. La vidéo et l'audio sont enregistrés sur un disque dur SATA (HDD) d'ordinateur standard installé à l'intérieur du DVR. En utilisant le DVR lui-même, il est possible de visualiser les enregistrements en les recherchant par date et heure. Il est également possible d'extraire des données dans un fichier sur un support externe. Tout d'abord, sur un lecteur USB qui se connecte à l'interface USB du DVR. Deuxièmement - à l'ordinateur via l'interface WEB du DVR. Le nom du fichier résultant est long et comprend la date d'enregistrement, l'heure de début et de fin, le canal d'enregistrement et d'autres informations supplémentaires. L'extension de fichier est «.264». Un examen du contenu d'un tel fichier m'a montré clairement que le conteneur multimédia dans lequel les flux audio et vidéo sont emballés est loin d'être standard. Un tel fichier peut être ouvert à l'aide du lecteur fourni avec le DVR. Le joueur est très mal à l'aise. Mais vous pouvez également utiliser le programme de reconditionnement pour le conteneur AVI, qui est également inclus. Ce programme reconditionne le flux vidéo, le laissant au format H264. Et le flux sonore est converti d'ADMCM en PCM, ce qui augmente sa taille 4 fois. Le résultat est un fichier .avi qui peut être lu par n'importe quel lecteur standard. Je constate tout de suite que ce programme de reconditionnement est très gênant. Il vous permet d'effectuer des opérations sur un seul fichier. Pour remballer un ensemble de fichiers, vous devez les ouvrir à leur tour.
Les tâches suivantes ont été définies.
- Accédez à tous les fichiers .264 du disque dur du DVR en connectant le disque dur à l'ordinateur.
- Pour étudier l'algorithme par lequel le programme de reconditionnement 264-avi standard fonctionne et créer le même programme qui effectuerait les mêmes opérations, mais pas sur un, mais sur un groupe entier de fichiers, en un seul clic.
La première tâche, à première vue, peut sembler très simple: il vous suffit de connecter le disque dur à l'ordinateur et d'ouvrir les partitions dans l'Explorateur. Cependant, il y a des pièges. Cet article est consacré à la première tâche.
Je savais déjà à l'avance que le shell logiciel du microcontrôleur DVR est basé sur un système d'exploitation similaire à Linux. Par conséquent, le partitionnement du disque dur sera probablement similaire à Linux. Par conséquent, vous avez besoin d'un ordinateur Linux. Dans mon cas, la capacité du disque dur est de 1 To, un ordinateur avec OS Xubuntu. Après avoir connecté le disque dur à l'ordinateur, je n'ai pu voir qu'une seule partition pour plusieurs gigaoctets. Ce n'est clairement pas ce dont vous avez besoin. À l'intérieur de la section, il existe de nombreux dossiers au format de nom «AAAA-MM-JJ» correspondant aux dates des enregistrements. À l'intérieur de chaque dossier, il existe de nombreux fichiers correspondant aux entrées. Fichiers du même nom que ceux obtenus lors de l'extraction du DVR. Cependant, leur taille est plusieurs fois plus petite et l'extension n'est pas .264, mais .nvr. Il faut supposer que ces mêmes fichiers nvr sont des clés pour les 264 fichiers correspondants (ou leurs flux multimédias), dont le contenu se trouve sur l'espace disque dur principal. J'ai copié les données du dossier de fichiers sur un support séparé pour de plus amples recherches.
J'ai utilisé beaucoup d'outils logiciels pour la recherche: un éditeur de disque (c'est aussi un éditeur de fichiers binaires) DiskExplorer (j'ai utilisé WinHex plus tard), MS Excel pour les calculs auxiliaires et la fixation des résultats, environnement de programmation Dev-C ++ pour écrire les programmes de console auxiliaires et finaux, etc. Dans cet article, je vais essayer de parler de cette procédure.
Tout d'abord, regardez le tout premier secteur du disque dur (un secteur (1 LBA) prend 512 octets). Ce secteur, en règle générale, contient une structure MBR. Il comprend un chargeur de démarrage et une table des matières de base. La structure de ce secteur, ainsi que la structure de la description de la section, est donnée ci-dessous (tirée de Wikipedia).
Dans le cas du disque dur étudié, nous avons ce qui suit. En regardant la figure ci-dessous et en suivant les tableaux ci-dessus, nous voyons que le chargeur de démarrage est manquant. Mais nous sommes plus intéressés par la table de partition. Il est mis en évidence dans un cadre rouge. Les deux derniers octets (remplissage bleu) - signature MBR. Vous pouvez voir dans la table de partition que le disque est divisé en deux sections. Le code pour le type de la première section (remplissage jaune) est 0x0B. Il s'agit d'une partition FAT32. Le code pour le type du second (remplissage orange) est 0x83. Il s'agit de l'une des partitions Linux (au sens d'EXT). Les octets de code de type de partition sont entourés en bleu.
Un décryptage complet du secteur MBR avec un tableau des sections et leurs paramètres est donné ci-dessous.
En faisant attention à la taille des partitions (en comptant le nombre de secteurs en gigaoctets), il est facile de deviner que sur l'ordinateur avec le système d'exploitation Xubuntu, c'était la première partition qui occupait une petite partie de l'espace disque. Soit dit en passant, dans Windows XP, seule la première partition était également affichée, mais elle ne s'est pas ouverte à partir de l'explorateur. Et pourquoi, alors, la deuxième partition Linux n'apparaissait pas sur le système d'exploitation Xubuntu?
Ayant précédemment étudié la structure et l'organisation du système de fichiers Linux en utilisant EXT2 comme exemple, j'ai commencé à étudier la deuxième section.
Comme vous pouvez le voir dans le tableau des sections, la deuxième section commence par le secteur 16016805. Le manuel du système de fichiers EXT2 indique la présence du soi-disant superbloc, qui se trouve à 1024 octets depuis le début de la section (c'est-à-dire deux secteurs depuis le début). Cependant, le secteur 16016805 + 2 = 16016807 était vide. Mais le premier secteur 16016805 dans sa structure ressemblait à un superbloc. Mais son contenu ne correspondait pas entièrement à la description du contenu du superbloc du manuel. Le superbloc est le bloc principal, qui contient une sorte de tableau de diverses constantes et paramètres pour le fonctionnement du système de fichiers: adresses des positions et tailles des autres blocs nécessaires, en particulier, en-têtes des enregistrements de fichiers et des répertoires. Des recherches plus poussées dans cette section m'ont conduit à une seule conclusion: le DVR utilise son propre système de fichiers unique.
À l'avenir, j'ai décidé de regarder le premier secteur de la première section (secteur 63) et de faire défiler vers le bas. Il a été trouvé sur le contenu du secteur 65 (deux secteurs ci-dessous) qui est complètement similaire au contenu du superbloc FS EXT2, qui est décrit dans le manuel. Des recherches plus poussées ont permis de conclure que la première partition du HDD DVR est la partition EXT2, qui était affichée sur le système d'exploitation Xubuntu, indépendamment de la marque 0x08 (pas EXT) dans la table des matières! Ainsi, la première partition du disque dur du DVR est la partition EXT2, sur laquelle sont enregistrés les fichiers nvr, qui sont les clés des enregistrements vidéo requis.
J'écrirai brièvement sur la structure des fichiers .264, que j'ai également examinée précédemment. Ces informations seront nécessaires à l'avenir pour étudier la deuxième section du disque dur. Comme dans tout conteneur multimédia, dans «264», il y a un en-tête avec des informations de service et des balises multimédias, ainsi que des flux audio et vidéo qui se succèdent en petits blocs l'un après l'autre. À un décalage de 0x84 octets par rapport au début du fichier, le mot clé "MDVR96NT_2_R" est enregistré. Avant ce mot se trouvent des octets liés à la date et à l'heure d'enregistrement. Mais ces informations sont contenues dans le nom du fichier, par conséquent, elles ne méritent pas une attention particulière ici. Après cela vient beaucoup d'octets de zéros. Les informations principales concernant les flux audio et vidéo proviennent d'un décalage de 65 536 octets. Les blocs de flux vidéo commencent par un en-tête de 8 octets «01dcH264» (également trouvé «00dcH264»). Les 4 octets suivants décrivent la taille du bloc actuel du flux vidéo en octets. Après 4 octets de zéros (00 00 00 00), le bloc de flux vidéo commence lui-même. Les blocs de flux audio ont le titre "03wb" (bien que, selon mes observations, le premier caractère de l'en-tête dans certains cas n'était pas nécessairement "0"). Après - 12 octets d'informations que je n'ai pas encore compris. Et en commençant par le 17e octet - un flux audio d'une longueur fixe de 160 octets. Il n'y a pas de balises à la fin du fichier.
Nous procédons à l'étude de la structure des fichiers et répertoires situés sur la première partition du disque dur. Comme mentionné ci-dessus, le contenu de la section a été copié sur un support distinct via un explorateur normal dans le système d'exploitation Xununtu. Dans chaque répertoire (répertoire), en plus des fichiers nvr, il y a un fichier binaire nommé "file_list". A en juger par le nom, il contient des informations sur la liste des fichiers dans le répertoire courant. Ouvrez ce fichier dans l'éditeur binaire (voir la figure ci-dessous). J'ai étudié la structure de ce dossier, et il n'y a fondamentalement rien d'intéressant ici. Le fichier ne contient aucune information concernant l'emplacement des flux multimédias souhaités. Néanmoins, j'écrirai brièvement sur cette structure. Les 32 premiers octets sont un en-tête avec quelques constantes. Les 16 octets suivants sont liés à la date et l'heure et au nombre de fichiers dans le répertoire en cours. Ceci est suivi de 48 octets de constantes. Suivant - 8 octets de constantes, indiquant le début de l'enregistrement de fichier. Ensuite, 96 octets indiquant le chemin d'accès complet au fichier nvr, y compris son nom. Suivant - 24 octets liés au temps (le nombre de secondes écoulées depuis le début de la journée, le début et la fin de la vidéo) et d'autres attributs de la vidéo. Et ainsi de suite, par analogie, pour tous les fichiers nvr du répertoire courant. Leur nombre est égal au nombre de vidéos de la journée en cours, indiqué par le nom du répertoire en cours. À quoi sert ce fichier? Apparemment, pour accélérer la recherche de vidéo dans l'interface DVR.
Passons à l'étude de la structure des fichiers nvr eux-mêmes. L'aspect d'un tel fichier dans un éditeur binaire (plus précisément dans un éditeur hexadécimal) est illustré dans la figure ci-dessous. Sans entrer dans les détails de la description de la structure du contenu (dont une partie est restée un mystère pour moi), j'ai mis en évidence les paramètres les plus élémentaires, qui sont la clé à trouver. Il s'agit de valeurs 32 bits (4 octets), situées tous les 32 octets, à partir de l'octet à l'offset 40. Sur la figure, elles sont surlignées en rouge. À l'avenir, je suis devenu convaincu que cela suffit pour la clé des vidéos. Je vous rappelle que 4 octets de la valeur de ce paramètre clé sont situés du plus bas au plus haut, mais pas l'inverse! Cette notation est due à l'architecture du processeur PC. L'exemple de la figure montre le premier fichier nvr du premier répertoire. Il correspond au premier enregistrement vidéo réalisé par le DVR. De toute évidence, les valeurs des paramètres, que j'ai appelé clé, dans l'exemple ci-dessus forment une séquence d'entiers, commençant à zéro et allant dans l'ordre croissant. En examinant d'autres fichiers nvr et en regardant exactement ces octets spécifiés, des entiers ont également été vus, croissant. Mais cette séquence n'a naturellement plus commencé à partir de zéro, et dans certains cas, des lacunes dans un ou deux nombres ont été observées par endroits. Par exemple (numéros du bulldozer): 435, 436, 438, 439, 442, ... (ou en hexadécimal: B3010000, B4010000, B6010000, B7010000, BA010000, ...).
Une telle séquence avec omissions s'est produite sur des fichiers nvr correspondant aux vidéos que le DVR a enregistrées simultanément à partir de deux canaux ou plus. C'est-à-dire, par exemple, si la séquence "435, 436, 438, 439, 442, ..." se réfère à la vidéo d'un canal, alors les valeurs manquantes (437, 440, 441) se rapporteront à la vidéo d'un autre canal, qui a été effectuée dans le même point dans le temps. J'étais moi-même convaincu de cela en consultant et en comparant les fichiers NVR correspondants, en fonction de leur nom. Il ne fait aucun doute que les numéros ci-dessus forment les numéros de certaines parties liées aux vidéos. Il ne reste plus qu'à démêler la relation entre ces nombres et les coordonnées de l'espace disque sur lequel se trouvent les données.
En outre, c'était pour savoir exactement quelles données sont divisées en segments numérotés ci-dessus? Première hypothèse - les données sont des flux audio et vidéo qui, dans le conteneur 264, sont représentés par des blocs courts et, comme cela a été dit, les blocs du flux vidéo ont des tailles différentes. Dans le même temps, le DVR collecte ces flux et les place dans un conteneur 264 au stade de l'extraction des enregistrements vidéo vers des supports externes. La deuxième hypothèse est que le DVR emballe les flux audio et vidéo dans un conteneur 264 au début et pendant la capture vidéo. Et en même temps, des données de fichier .264 déjà générées sont écrites sur le disque dur, ce qui se serait avéré à la suite de leur extraction sur un support externe. En explorant l'espace disque dur quelque part au milieu de la deuxième section, avec les octets de flux audio et vidéo et leurs en-têtes du même type que dans le conteneur 264, je suis également tombé sur les en-têtes du conteneur lui-même: MDVR96NT_2_R. Après cet en-tête, il y avait également de nombreux octets de zéros. En général, l'étude a montré qu'il existe une deuxième option parmi les deux ci-dessus. Par conséquent, pour obtenir le fichier .264 souhaité, il vous suffit probablement de connecter tous les segments dont les numéros sont contenus dans le fichier nvr correspondant.
Commençons la recherche de la relation entre le numéro de segment et les coordonnées sur le disque dur.
Le début des données du conteneur 264 correspondant au tout premier enregistrement vidéo (où la numérotation des segments commence à zéro) avec des outils de recherche que j'ai trouvés sur le secteur 16046629 (29824 secteurs depuis le début de la section). Nous pouvons faire une hypothèse sur le soi-disant paramètre biais initial, qui participera à la formule décrivant la dépendance souhaitée.
Prenons deux fichiers nvr correspondant à des vidéos de différentes chaînes que le DVR a capturées en même temps. Pour ce faire, jetez un œil aux noms de fichiers. Par exemple, les vidéos pointées par les fichiers «ch00000000000001-150330-160937-161035-02p101000000.nvr» et «ch00000000000004-150330-160000-163000-00p004000000.nvr» ont été enregistrées simultanément. Le premier enregistrement est l'enregistrement de la 1ère chaîne de 16:09:37 à 16:10:35. Le deuxième record est un record de la 4ème chaîne de 16:00:00 à 16:30:00. Les deux entrées ont été faites le 30 mars 2015. Sur la chronologie, évidemment, l'intervalle de temps du premier enregistrement est un sous-ensemble de l'intervalle de temps du deuxième enregistrement. Je prends également en compte le fait que dans un intervalle de temps plus court (à l'intersection de deux intervalles) le DVR n'a effectué aucune capture vidéo à partir des 6 autres canaux. Parcourez le contenu de ces fichiers nvr. Nous allons nous assurer que les numéros manquants (numéros de segment) dans le deuxième fichier long sont nécessairement présents dans le premier fichier court, complètement et complètement. En utilisant le DVR de la manière habituelle, vous devez extraire au moins un des fichiers .264 référencés par les fichiers NVR étudiés à l'avance. Supposons que "ch00000000000001-150330-160937-161035-02p101000000.264" a été extrait. Ouvrez-le dans l'éditeur binaire. Comme déjà mentionné, au début de ce fichier, avant le mot-clé "MDVR96NT_2_R", il y a des octets uniques correspondant à la date et l'heure de l'enregistrement vidéo contenues dans ce fichier. Nous annulons tous ces octets, en commençant par une valeur non nulle et en terminant par l'en-tête (plus la chaîne d'octets est courte pour cet enregistrement vidéo, mieux c'est). Notez également le décalage de cette chaîne d'octets depuis le début du fichier. Il convient de noter qu'au début du fichier .264 extrait, il y a 4 octets supplémentaires de zéros. Cela est devenu perceptible en comparant les 512 premiers octets du fichier .264 et le secteur de l'espace disque à partir duquel le contenu de l'un des fichiers .264 commence (un fichier de presque n'importe quel système de fichiers commence toujours au début du secteur, en outre, un cluster). Autrement dit, les informations du fichier .264 sont décalées à l'avance de 4 octets vers la droite. La taille (en octets) de tout fichier .264 est un multiple de 512 uniquement après avoir soustrait le nombre 4 de la taille. Commençons la recherche du secteur à partir duquel le fichier .264 étudié commence. Dans l'éditeur de disque, lancez la fonction de recherche. Dans le champ de la valeur souhaitée, entrez une chaîne d'octets unique annulée à l'avance. Pour accélérer la recherche, entrez la valeur de décalage dans le champ «recherche par décalage», en soustrayant précédemment 4. Lancez la recherche. Quelques heures plus tard, la recherche a réussi. Nous notons le numéro du secteur dans lequel se trouve le titre unique. Que ce soit la valeur de s. Nous regardons le contenu du fichier nvr pour cette vidéo. Nous radions le numéro du premier segment (4 octets à l'offset 40). Que ce soit la valeur de b. Au total, alors que nous connaissons le numéro de secteur du disque (16046629) pour le numéro de segment zéro (dans le tout premier enregistrement vidéo) et le numéro du secteur trouvé du disque s pour le numéro de segment b qui vient d'être supprimé. Vous pouvez calculer la taille estimée du segment: (s-16046629) / (b-0). Après le calcul, j'ai obtenu la valeur 128. Ainsi, la taille du segment est égale à 128 secteurs de disque (LBA), soit 128 * 512 = 65536 octets!
J'ai mené une autre expérience intéressante supplémentaire pour enfin dissiper tous les doutes. Il est décrit ci-dessous.
Dès le début des secteurs, nous sélectionnons une zone sur le disque avec une taille comparable à la taille d'un fichier .264 qui commence par ce secteur. Si mes suppositions sont correctes, alors des segments d'un autre fichier .264, qui a été capturé sur le disque dur simultanément avec le premier, tomberont dans la zone sélectionnée. Enregistrez cette zone dans un fichier (créez une image). Coupez l'image résultante en fichiers de 65 536 octets (taille de segment). Cela peut être fait en utilisant la fonction «fichier divisé» dans Total Commander. Que ce soit des pièces M1, M2, M3, .... De même, nous avons coupé le fichier .264 étudié (qui a été extrait de manière conviviale du DVR), mais en supprimant d'abord 4 octets de zéros en premier. Que ce soit les pièces K1, K2, K3, .... En utilisant la fonction «Comparer par contenu» de Total Commander, nous comparons tour à tour les morceaux de l'image et les morceaux du fichier .264. (M1 avec K1, M2 avec K2, etc.), guidé par les numéros de segment du fichier nvr correspondant. Le résultat est le suivant.
Supposons (nombres du bulldozer), la chaîne de nombres en nvr est la suivante: 435, 436, 438, 439, 442, ... Dans cette situation, M1 = K1, M2 = K2, M4 = K3, M5 = K4, M8 = K5, .... C'est-à-dire que les morceaux dans lesquels le fichier image et le fichier .264 ont été divisés sont égaux, en tenant compte de l'avance correspondante du nombre de morceaux du fichier image, selon les omissions dans la séquence. Ça y est!Au total, nous avons obtenu la dépendance estimée: S = 16046629 + 128 * d, où d est le numéro de segment dans le fichier nvr, et S est le numéro de secteur sur le disque dur, à partir du tout début du disque à partir duquel commence le contenu du segment. Taille du segment - 128 secteurs. La formule ci-dessus ne prend pas en compte l'existence de la deuxième section. La dépendance se trouve uniquement pour un exemple spécifique du disque dur à 1 To. Peut-être que si vous mettez une capacité différente dans le disque dur du DVR, les constantes auront un aspect différent.Pour vérifier la validité de la formule, nous calculons la position du premier segment d'un autre fichier .264 arbitraire, guidé par le fichier nvr correspondant. En faisant attention à la date et à l'heure du nom de fichier, comparez-les avec les premiers octets de l'en-tête .264 situés sur le secteur calculé. Les octets codant individuellement le nombre, le mois, l'année, les heures, les minutes, les secondes correspondent à des données temporaires dans le nom du fichier. Par conséquent, "frappez le clou"! Nous calculons dans le fichier nvr correspondant au fichier .264 extrait à l'avance, le nombre de segments cs. En général, leur nombre est cs = sf / 32-1, où sf est la taille du fichier nvr. Si le fichier .264 se compose de segments cs, sa taille doit être égale à cs * 65536 + 4 (le nombre de segments multiplié par la taille du segment en octets, plus 4 des mêmes octets de zéros). Et ça l'est vraiment!Essayez tout de même d'explorer la deuxième section. Comme indiqué précédemment, quelque chose de similaire à un superbloc est situé directement dans le premier secteur de la section (16016805). Et sa copie exacte a été découverte par sept secteurs ci-dessous (16016812). De toute évidence, les informations de base non nulles se trouvent dans le premier secteur du superbloc. Son apparence dans l'éditeur de disque est illustrée dans la figure ci-dessous.
J'ai réussi à décrypter une partie des paramètres à 4 octets. La date et l'heure de montage de la partition sont surlignées en bleu. La date et l'heure sont présentées dans une notation spéciale "heure Unix" (le nombre de secondes écoulées depuis minuit le 1er janvier 1970). Dans l'exemple ci-dessus, «03 7E 74 54» (valeur décimale 1416920579) correspond à «Mar, 25 nov 2014 13:02:59 GMT». Pour traduire les valeurs, j'ai utilisé une calculatrice en ligne spéciale. La valeur 65536 est encerclée dans le cadre violet. Il est possible que l'interpréteur de système de fichiers à l'intérieur du programme DVR se réfère à cette position du superbloc lorsque la taille du bloc est lue (dans le contexte précédent, j'ai appelé les segments de blocs). Les valeurs 1 sont surlignées dans le cadre vert. L'une d'elles indique probablement la position du début de la soi-disant. bitmap (dans le nombre de blocs depuis le début de la section). En effetà l'avance, le début de l'information a été trouvé, quelque chose de similaire à un bitmap sur le secteur 16016933 (16016805 + 128 * 1). La valeur 233 est mise en évidence dans un cadre rouge. C'est précisément la position du début de ces enregistrements vidéo .264 depuis le début de la section: 16016805 + 128 * 233 = 16046629.Autrement dit, la deuxième section peut être appelée une section tronquée et légèrement modifiée d'EXT2. Il a un superbloc, une copie de celui-ci, un bitmap. Mais il n'y a pas de soi-disant. nœuds d'information correspondant aux enregistrements de fichiers. La section contient des données de fichiers .264 (flux audio et vidéo), mais les nœuds d'information (disons-le) pour ces données sont situés dans des fichiers nvr sur la première section. Peut-être existe-t-il une formulation plus compétente? Mais ce n'est pas si important pour moi.Écrivons un programme simple pour l'extraction en masse de fichiers .264. Je dois dire tout de suite que je n'ai pas beaucoup d'expérience en programmation sous Windows. Le programme analyse tous les fichiers nvr copiés à l'avance dans la section 1 To du nouveau disque dur. En les analysant, le programme crée un fichier .264 du même nom dans le même répertoire, en utilisant l'accès aux secteurs du disque dur d'origine. Auparavant, un dossier avec le nom «DVR» était créé dans une section vide du nouveau disque dur, dans lequel les dossiers par date sont placés, qui sont copiés de la «manière habituelle» sous Linux. Il a été possible d'inclure dans ce programme un algorithme pour travailler avec la première partition Linux pour accéder aux fichiers nvr afin de ne pas avoir à les pré-copier. Et vous pouvez ajouter d'autres fonctionnalités pratiques. Oui, c'était possible, mais à ce moment-là, je voulais tout faire le plus rapidement possible.Je n'ai pas utilisé la récursivité pour analyser les répertoires, étant donné que le format des répertoires est fixe et comporte deux niveaux de pièce jointe. En conséquence, j'ai appliqué deux cycles: parcourir les dossiers jusqu'à leur fin et parcourir les fichiers de chaque dossier avec la même condition. Pour lire des fichiers, j'ai utilisé la fonction fopen. Pour travailler avec les secteurs du disque dur, j'ai utilisé la fonctionnalité WinAPI similaire à l'utilisation de fichiers. Passons au code du programme.Les bibliothèques en ont besoin.#include <windows.h> #include <stdio.h> #include <string.h>
Et j'ai complètement copié ces fonctions à partir d'un 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);
La fonction de copie contient une formule de dépendance linéaire, qui est apparue dans la théorie ci-dessus.
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); }
La fonction principale est également assez simple.
int main(){ HANDLE hdd = openDevice(1);
Sur un vieil ordinateur équipé d'un processeur Pentium 4 et d'un contrôleur PCI SATA, le programme a réussi à transférer à terme un disque dur complet avec plusieurs milliers de fichiers .264 en 7 heures en moyenne. Sur un nouvel ordinateur - trois fois plus rapide. Comme je l'ai déjà noté, le programme n'est pas universel, toutes les constantes et variables sont ajustées à mon cas spécifique du disque dur à 1 To. Cependant, vous pouvez travailler un peu plus et le rendre universel, dessinez une interface graphique.
Dans la deuxième partie de l'article, j'écrirai comment «faire soi-même» pour reconditionner du conteneur «264» vers le conteneur «avi» standard.