Dieser Artikel befasst sich mit der Untersuchung der Dateistruktur der Festplatte eines Achtkanal-Videorecorders zum Zweck der Massenextraktion von Videodateien. Am Ende des Artikels steht die Implementierung des entsprechenden Programms in C.
Videorecorder (abgekürzt DVR) QCM-08DL wird in Videoüberwachungssystemen verwendet und ermöglicht Video- und Audioaufnahmen mit acht Kanälen. Dieses Modell ist meiner Meinung nach eines der billigsten und gleichzeitig zuverlässigsten im Betrieb. Das Videokomprimierungsformat ist das beliebte H264-Format. Für Audio ist das Komprimierungsformat ADPCM. Video und Audio werden auf einer im DVR installierten SATA-Festplatte (HDD) eines Standardcomputers aufgezeichnet. Mit dem DVR selbst können Sie Aufnahmen anzeigen, indem Sie sie nach Datum und Uhrzeit durchsuchen. Es ist auch möglich, Daten in eine Datei auf einem externen Medium zu extrahieren. Erstens an ein USB-Laufwerk, das an die USB-Schnittstelle des DVR angeschlossen wird. Zweitens - über die WEB-Schnittstelle des DVR zum Computer. Der Name der resultierenden Datei ist lang und enthält das Aufnahmedatum, die Start- und Endzeit, den Aufnahmekanal und andere zusätzliche Informationen. Die Dateierweiterung lautet ".264". Eine Prüfung des Inhalts einer solchen Datei hat mir klar gemacht, dass der Mediencontainer, in den Audio- und Videostreams gepackt sind, weit vom Standard entfernt ist. Eine solche Datei kann mit dem mit dem DVR gelieferten Player geöffnet werden. Der Spieler fühlt sich sehr unwohl. Sie können aber auch das Repacker-Programm für den AVI-Container verwenden, der ebenfalls enthalten ist. Dieses Programm packt den Videostream neu und belässt ihn im H264-Format. Der Soundstrom wird von ADMCM in PCM konvertiert und um das Vierfache vergrößert. Das Ergebnis ist eine .avi-Datei, die von jedem Standard-Player abgespielt werden kann. Ich stelle sofort fest, dass dieses Umpackprogramm sehr unpraktisch ist. Sie können damit nur Operationen für eine Datei ausführen. Um eine Reihe von Dateien neu zu packen, müssen Sie sie nacheinander öffnen.
Die folgenden Aufgaben wurden festgelegt.
- Erhalten Sie Zugriff auf alle .264-Dateien von der Festplatte des DVR, indem Sie die Festplatte an den Computer anschließen.
- Um den Algorithmus zu untersuchen, mit dem das Standardprogramm 264-avi repacker funktioniert, und dasselbe Programm zu erstellen, das dieselben Operationen ausführt, jedoch nicht mit einem, sondern mit einer ganzen Gruppe von Dateien mit einem Klick.
Die erste Aufgabe mag auf den ersten Blick sehr einfach erscheinen: Sie müssen nur die Festplatte an den Computer anschließen und die Partitionen im Explorer öffnen. Es gibt jedoch Fallstricke. Dieser Artikel ist der ersten Aufgabe gewidmet.
Ich wusste bereits im Voraus, dass die Software-Shell des DVR-Mikrocontrollers auf einem Linux-ähnlichen Betriebssystem basiert. Daher wird die Partitionierung der Festplatte höchstwahrscheinlich auch Linux-ähnlich sein. Daher benötigen Sie einen Linux-Computer. In meinem Fall beträgt die Kapazität der Festplatte 1 TB, ein Computer mit OS Xubuntu. Nachdem ich die Festplatte an den Computer angeschlossen hatte, konnte ich nur eine Partition pro mehrere Gigabyte sehen. Dies ist eindeutig nicht das, was Sie brauchen. Innerhalb des Abschnitts befinden sich viele Ordner im Namensformat „JJJJ-MM-TT“, die den Daten der Datensätze entsprechen. In jedem Ordner befinden sich viele Dateien, die den Einträgen entsprechen. Dateien mit demselben Namen wie beim Extrahieren aus dem DVR. Ihre Größe ist jedoch um ein Vielfaches kleiner und die Erweiterung ist nicht .264, sondern .nvr. Es sollte angenommen werden, dass dieselben NVR-Dateien Schlüssel für die entsprechenden 264 Dateien (oder deren Medienströme) sind, deren Inhalt sich auf dem Hauptfestplattenspeicher befindet. Ich habe die Daten aus dem Dateiordner zur weiteren Recherche auf ein separates Medium kopiert.
Ich habe viele Software-Tools für die Recherche verwendet: einen Disk-Editor (es ist auch ein Binärdatei-Editor) DiskExplorer (ich habe später WinHex verwendet), MS Excel für Hilfsberechnungen und Korrekturergebnisse, Dev-C ++ - Programmierumgebung zum Schreiben von Hilfs- und Endkonsolenprogrammen usw. In diesem Artikel werde ich versuchen, über dieses Verfahren zu sprechen.
Schauen Sie sich zunächst den ersten Sektor der Festplatte an (ein Sektor (1 LBA) benötigt 512 Byte). Dieser Sektor enthält in der Regel eine MBR-Struktur. Es enthält einen Bootloader und ein grundlegendes Inhaltsverzeichnis. Die Struktur dieses Sektors sowie die Struktur der Abschnittsbeschreibung sind unten angegeben (entnommen aus Wikipedia).
Im Fall der untersuchten Festplatte haben wir Folgendes. Wenn wir uns die Abbildung unten ansehen und den obigen Tabellen folgen, sehen wir, dass der Bootloader fehlt. Wir interessieren uns aber mehr für die Partitionstabelle. Es wird in einem roten Rahmen hervorgehoben. Die letzten zwei Bytes (blaue Füllung) - MBR-Signatur. Sie können der Partitionstabelle entnehmen, dass die Festplatte in zwei Abschnitte unterteilt ist. Der Code für den Typ des ersten Abschnitts (gelbe Füllung) lautet 0x0B. Dies ist eine FAT32-Partition. Der Code für den Typ der Sekunde (orange Füllung) ist 0x83. Dies ist eine der Linux-Partitionen (im Sinne von EXT). Partitionstyp-Codebytes sind blau eingekreist.
Eine vollständige Entschlüsselung des MBR-Sektors mit einer Tabelle von Abschnitten und ihren Parametern ist unten angegeben.
Unter Berücksichtigung der Größe der Partitionen (einschließlich der Anzahl der Sektoren in Gigabyte) ist es leicht zu erraten, dass es sich bei dem Computer mit dem Betriebssystem Xubuntu um die erste Partition handelte, die einen kleinen Teil des Speicherplatzes einnahm. Übrigens wurde in Windows XP nur die erste Partition angezeigt, die jedoch nicht über den Explorer geöffnet wurde. Und warum erschien dann die zweite Linux-Partition nicht auf dem Xubuntu-Betriebssystem?
Nachdem ich zuvor die Struktur und Organisation des Linux-Dateisystems am Beispiel von EXT2 untersucht hatte, begann ich, den zweiten Abschnitt zu studieren.
Wie Sie der Abschnittstabelle entnehmen können, beginnt der zweite Abschnitt mit dem Sektor 16016805. Das Handbuch zum EXT2-Dateisystem zeigt das Vorhandensein des sogenannten Superblocks an, der sich 1024 Byte vom Anfang des Abschnitts entfernt befindet (dh zwei Sektoren vom Anfang). Der Sektor 16016805 + 2 = 16016807 war jedoch leer. Der erste Sektor 16016805 in seiner Struktur ähnelte jedoch einem Superblock. Der Inhalt entsprach jedoch nicht vollständig der Beschreibung des Inhalts des Superblocks aus dem Handbuch. Der Superblock ist der Hauptblock, der eine Art Tabelle mit verschiedenen Konstanten und Parametern für die Funktionsweise des Dateisystems enthält: Adressen von Positionen und Größen anderer erforderlicher Blöcke, insbesondere Header von Dateidatensätzen und Verzeichnissen. Weitere Untersuchungen in diesem Abschnitt führten mich nur zu einer Schlussfolgerung: Der DVR verwendet ein eigenes einzigartiges Dateisystem.
In Zukunft habe ich beschlossen, den ersten Sektor des ersten Abschnitts (Sektor 63) zu betrachten und nach unten zu scrollen. Es wurde auf dem Inhalt von Sektor 65 (zwei Sektoren unten) gefunden, der dem Inhalt des FS EXT2-Superblocks, der im Handbuch beschrieben wird, völlig ähnlich ist. Weitere Untersuchungen führten zu dem Schluss, dass die erste Partition des HDD-DVR die EXT2-Partition ist, die auf dem Xubuntu-Betriebssystem angezeigt wurde, unabhängig von der Markierung 0x08 (nicht EXT) im Inhaltsverzeichnis! Daher ist die erste Partition der Festplatte des DVR die EXT2-Partition, auf der NVR-Dateien aufgezeichnet werden. Dies sind die Schlüssel für die erforderlichen Videoaufnahmen.
Ich werde kurz über die Struktur von .264-Dateien schreiben, die ich zuvor ebenfalls untersucht habe. Diese Informationen werden in Zukunft benötigt, um den zweiten Abschnitt der Festplatte zu untersuchen. Wie in jedem Mediencontainer gibt es in „264“ einen Header mit Serviceinformationen und Medien-Tags sowie Audio- und Videostreams, die in kleinen Blöcken nacheinander folgen. Bei einem Versatz von 0 x 84 Byte vom Dateianfang wird das Schlüsselwort "MDVR96NT_2_R" registriert. Vor diesem Wort stehen Bytes, die sich auf Datum und Uhrzeit der Aufzeichnung beziehen. Diese Informationen sind jedoch im Dateinamen enthalten und verdienen daher hier keine besondere Aufmerksamkeit. Danach kommen viele Bytes von Nullen. Die Hauptinformationen mit Audio- und Videostreams stammen aus einem Offset von 65.536 Bytes. Videostream-Blöcke beginnen mit einem 8-Byte-Header „01dcH264“ (auch „00dcH264“). Die folgenden 4 Bytes beschreiben die Größe des aktuellen Blocks des Videostreams in Bytes. Nach 4 Bytes von Nullen (00 00 00 00) beginnt der Videostreamblock selbst. Die Audio-Stream-Blöcke haben den Titel "03wb" (obwohl nach meinen Beobachtungen das erste Zeichen des Headers in einigen Fällen nicht unbedingt "0" war). Nach - 12 Bytes an Informationen, die ich noch nicht herausgefunden habe. Und beginnend mit dem 17. Byte - einem Audiostream mit einer festen Länge von 160 Bytes. Am Ende der Datei befinden sich keine Tags.
Wir untersuchen die Struktur von Dateien und Verzeichnissen auf der ersten Partition der Festplatte. Wie oben erwähnt, wurde der Inhalt des Abschnitts über einen regulären Explorer im Xununtu-Betriebssystem auf ein separates Medium kopiert. In jedem Verzeichnis (Verzeichnis) gibt es zusätzlich zu den NVR-Dateien eine Binärdatei mit dem Namen "file_list". Nach dem Namen zu urteilen, enthält es Informationen über die Liste der Dateien im aktuellen Verzeichnis. Öffnen Sie diese Datei im Binäreditor (siehe Abbildung unten). Ich habe die Struktur dieser Datei untersucht, und hier gibt es im Grunde nichts Interessantes. Die Datei enthält keine Informationen zum Speicherort der gewünschten Medienströme. Trotzdem werde ich kurz über diese Struktur schreiben. Die ersten 32 Bytes sind ein Header mit einigen Konstanten. Die nächsten 16 Bytes beziehen sich auf Datum und Uhrzeit sowie die Anzahl der Dateien im aktuellen Verzeichnis. Darauf folgen 48 Byte Konstanten. Weiter - 8 Byte Konstanten, die den Beginn des Dateidatensatzes angeben. Als nächstes 96 Bytes, die den vollständigen Pfad zur NVR-Datei einschließlich ihres Namens angeben. Weiter - 24 Bytes in Bezug auf die Zeit (die Anzahl der Sekunden, die seit Beginn des Tages, dem Beginn und dem Ende des Videos vergangen sind) und andere Attribute des Videos. Und so weiter analog für alle NVR-Dateien im aktuellen Verzeichnis. Ihre Anzahl entspricht der Anzahl der Videos für den aktuellen Tag, angegeben durch den Namen des aktuellen Verzeichnisses. Wofür ist diese Datei? Anscheinend, um die Suche nach Videos innerhalb der DVR-Schnittstelle zu beschleunigen.
Lassen Sie uns nun die Struktur der NVR-Dateien selbst untersuchen. Das Erscheinungsbild einer solchen Datei in einem Binäreditor (genauer gesagt in einem Hexadezimaleditor) ist in der folgenden Abbildung dargestellt. Ohne auf die Beschreibung der Inhaltsstruktur einzugehen (von der mir ein Teil ein Rätsel blieb), habe ich die grundlegendsten Parameter hervorgehoben, die der Schlüssel sind, der gefunden werden kann. Dies sind 32-Bit-Werte (4 Byte), die sich alle 32 Byte ab Byte bei Offset 40 befinden. In der Abbildung sind sie rot hervorgehoben. In Zukunft war ich überzeugt, dass dies für den Schlüssel zu den Videos völlig ausreicht. Ich erinnere Sie daran, dass sich 4 Bytes des Werts dieses Schlüsselparameters vom niedrigsten zum höchsten befinden, aber nicht umgekehrt! Diese Notation ist auf die Architektur des PC-Prozessors zurückzuführen. Das Beispiel in der Abbildung zeigt die erste NVR-Datei des ersten Verzeichnisses. Dies entspricht der ersten Videoaufnahme des DVR. Offensichtlich bilden die Werte der Parameter, die ich im obigen Beispiel als Schlüssel bezeichnet habe, eine Folge von ganzen Zahlen, beginnend bei Null und in aufsteigender Reihenfolge. Bei der Untersuchung anderer NVR-Dateien und der genauen Betrachtung dieser angegebenen Bytes wurden auch Ganzzahlen in aufsteigender Reihenfolge angezeigt. Aber diese Sequenz begann natürlich nicht mehr von vorne, und in einigen Fällen wurden stellenweise Lücken in einer oder zwei Zahlen beobachtet. Zum Beispiel (Nummern vom Bulldozer): 435, 436, 438, 439, 442, ... (oder hexadezimal: B3010000, B4010000, B6010000, B7010000, BA010000, ...).
Eine solche Sequenz mit Auslassungen trat bei NVR-Dateien auf, die den Videos entsprachen, die der DVR gleichzeitig von zwei oder mehr Kanälen aufzeichnete. Das heißt, wenn sich beispielsweise die Sequenz "435, 436, 438, 439, 442, ..." auf Video von einem Kanal bezieht, beziehen sich die fehlenden Werte (437, 440, 441) auf Video von einem anderen Kanal, das im selben Kanal ausgeführt wurde Zeitpunkt. Ich selbst war davon überzeugt, indem ich die entsprechenden NVR-Dateien anhand ihres Namens angesehen und verglichen habe. Es besteht kein Zweifel, dass die obigen Zahlen die Nummern einiger Teile bilden, die sich auf die Videos beziehen. Es bleibt nur die Beziehung zwischen diesen Zahlen und den Koordinaten des Speicherplatzes zu entschlüsseln, auf dem sich die Daten befinden.
Außerdem sollte genau herausgefunden werden, welche Daten in die oben nummerierten Segmente unterteilt sind. Die erste Annahme - die Daten sind Audio- und Videoströme, die in dem Behälter 264 durch kurze Blöcke dargestellt werden, und wie gesagt wurde, haben die Blöcke des Videostreams unterschiedliche Größen. Gleichzeitig sammelt der DVR diese Ströme und packt sie in einen Container 264 beim Extrahieren von Videoaufzeichnungen auf externe Medien. Die zweite Annahme ist, dass der DVR zu Beginn und während der Videoaufnahme Streams von Audio und Video in einen Container 264 packt. Gleichzeitig werden bereits generierte .264-Dateidaten auf die Festplatte geschrieben, was sich aufgrund der Extraktion auf ein externes Medium herausgestellt hätte. Beim Durchsuchen des Festplattenspeichers in der Mitte des zweiten Abschnitts sowie der Bytes von Audio- und Videostreams und ihrer Header des gleichen Typs wie in Container 264 stieß ich auch auf die Header des Containers selbst: MDVR96NT_2_R. Nach diesem Header gab es auch viele Bytes von Nullen. Im Allgemeinen hat die Studie gezeigt, dass es eine zweite Option der beiden oben genannten gibt. Um die gewünschte .264-Datei zu erhalten, müssen Sie höchstwahrscheinlich nur alle Segmente miteinander verbinden, deren Nummern in der entsprechenden nvr-Datei enthalten sind.
Beginnen wir mit der Suche nach der Beziehung zwischen der Segmentnummer und den Koordinaten auf der Festplatte.
Der Anfang der Daten des Containers 264 entspricht der allerersten Videoaufzeichnung (wobei die Nummerierung der Segmente bei Null beginnt) mit Suchwerkzeugen, die ich im Sektor 16046629 gefunden habe (29824 Sektoren vom Anfang des Abschnitts). Wir können eine Annahme über den sogenannten Parameter machen anfängliche Verzerrung, die an der Formel teilnimmt, die die gewünschte Abhängigkeit beschreibt.
Nehmen wir zwei NVR-Dateien, die Videos von verschiedenen Kanälen entsprechen, die der DVR gleichzeitig aufgenommen hat. Schauen Sie sich dazu die Dateinamen an. Beispielsweise wurden die Videos, auf die in den Dateien "ch00000000000001-150330-160937-161035-02p101000000.nvr" und "ch00000000000004-150330-160000-163000-00p004000000.nvr" verwiesen wird, gleichzeitig aufgezeichnet. Die erste Aufnahme ist die Aufnahme vom 1. Kanal von 16:09:37 bis 16:10:35 Uhr. Die zweite Aufzeichnung ist eine Aufzeichnung vom 4. Kanal von 16:00:00 bis 16:30:00 Uhr. Beide Einträge wurden am 30. März 2015 vorgenommen. Auf der Zeitachse ist das Zeitintervall des ersten Datensatzes offensichtlich eine Teilmenge des Zeitintervalls des zweiten Datensatzes. Ich berücksichtige auch die Tatsache, dass der DVR in einem kürzeren Zeitintervall (im Schnittpunkt zweier Intervalle) keine Videoaufnahme von einem der anderen 6 Kanäle durchgeführt hat. Durchsuchen Sie den Inhalt dieser NVR-Dateien. Wir werden sicherstellen, dass die fehlenden Zahlen (Segmentnummern) in der zweiten langen Datei notwendigerweise vollständig und vollständig in der ersten kurzen Datei vorhanden sind. Wenn Sie den DVR wie gewohnt verwenden, müssen Sie im Voraus mindestens eine der .264-Dateien extrahieren, auf die in den untersuchten nvr-Dateien verwiesen wird. Angenommen, "ch00000000000001-150330-160937-161035-02p101000000.264" wurde extrahiert. Öffnen Sie es im Binäreditor. Wie bereits erwähnt, befinden sich am Anfang dieser Datei vor dem Schlüsselwort "MDVR96NT_2_R" eindeutige Bytes, die dem Datum und der Uhrzeit der in dieser Datei enthaltenen Videoaufzeichnung entsprechen. Wir schreiben alle diese Bytes ab, beginnend mit ungleich Null und endend mit dem Header (je kürzer die für diese Videoaufnahme eindeutige Bytekette ist, desto besser). Schreiben Sie auch den Offset dieser Bytefolge vom Anfang der Datei. Es ist zu beachten, dass am Anfang der extrahierten .264-Datei zusätzliche 4 Byte Nullen stehen. Dies wurde durch den Vergleich der ersten 512 Bytes der .264-Datei und des Speicherplatzsektors, von dem aus der Inhalt einer der .264-Dateien beginnt, deutlich (eine Datei fast jedes Dateisystems beginnt immer am Anfang des Sektors, außerdem ein Cluster). Das heißt, die Informationen in der .264-Datei werden im Voraus um 4 Byte nach rechts verschoben. Die Größe (in Bytes) einer .264-Datei ist erst dann ein Vielfaches von 512, wenn zuerst die Zahl 4 von der Größe abgezogen wurde. Beginnen wir mit der Suche nach dem Sektor, von dem aus die untersuchte .264-Datei beginnt. Starten Sie im Festplatteneditor die Suchfunktion. Geben Sie im Feld des gewünschten Werts eine eindeutige Zeichenfolge von Bytes ein, die im Voraus abgeschrieben wurden. Um die Suche zu beschleunigen, geben Sie den Versatzwert in das Feld "Suche nach Versatz" ein und subtrahieren Sie zuvor 4. Starten Sie die Suche. Einige Stunden später war die Suche erfolgreich. Wir notieren die Nummer des Sektors, in dem sich der eindeutige Titel befindet. Sei dies der Wert von s. Wir schauen uns den Inhalt der NVR-Datei für dieses Video an. Wir schreiben die Nummer des ersten Segments ab (4 Bytes bei Offset 40). Sei dies der Wert von b. Insgesamt kennen wir zwar die Plattensektornummer (16046629) für die Nullsegmentnummer (in der allerersten Videoaufzeichnung) und die Nummer des gefundenen Sektors der Platte s für die gerade abgeschriebene Segmentnummer b. Sie können die geschätzte Segmentgröße berechnen: (s-16046629) / (b-0). Nach der Berechnung habe ich den Wert 128 erhalten. Somit entspricht die Segmentgröße 128 Plattensektoren (LBA) oder 128 * 512 = 65536 Bytes!
Ich führte ein weiteres interessantes Experiment durch, um endlich alle Zweifel auszuräumen. Es wird unten beschrieben.
Ab dem Beginn der Sektoren wählen wir einen Bereich auf der Festplatte mit einer Größe aus, die mit der Größe einer .264-Datei vergleichbar ist, die mit diesem Sektor beginnt. Wenn meine Vermutungen richtig sind, fallen Segmente einer anderen .264-Datei, die gleichzeitig mit der ersten auf der Festplatte aufgenommen wurde, in den ausgewählten Bereich. Speichern Sie diesen Bereich in einer Datei (erstellen Sie ein Bild). Schneiden Sie das resultierende Bild in Dateien mit 65.536 Byte (Segmentgröße). Dies kann mit der Funktion „Datei teilen“ in Total Commander erfolgen. Lassen Sie es Stücke M1, M2, M3, .... sein. In ähnlicher Weise schneiden wir die untersuchte .264-Datei (die auf benutzerfreundliche Weise aus dem DVR extrahiert wurde), entfernen jedoch zuerst 4 Byte Nullen. Lassen Sie es Stücke K1, K2, K3, .... sein. Mit der Funktion "Nach Inhalt vergleichen" in Total Commander vergleichen wir nacheinander die Teile des Bildes und die Teile aus der .264-Datei. (M1 mit K1, M2 mit K2 usw.), geleitet von den Segmentnummern aus der entsprechenden NVR-Datei. Das Ergebnis ist das Folgende.
Angenommen (Zahlen vom Bulldozer), die Zahlenkette in nvr ist wie folgt: 435, 436, 438, 439, 442, ... In dieser Situation ist M1 = K1, M2 = K2, M4 = K3, M5 = K4, M8 = K5, .... Das heißt, die Teile, in die die Bilddatei und die .264-Datei unterteilt wurden, sind gleich, wobei der entsprechende Fortschritt in der Anzahl der Teile der Bilddatei entsprechend den Auslassungen in der Sequenz berücksichtigt wird. So ist das!Insgesamt haben wir die geschätzte Abhängigkeit erhalten: S = 16046629 + 128 * d, wobei d die Segmentnummer in der nvr-Datei und S die Sektornummer auf der Festplatte ist, beginnend am Anfang der Platte, von der aus der Inhalt des Segments beginnt. Segmentgröße - 128 Sektoren. Die obige Formel berücksichtigt nicht die Existenz des zweiten Abschnitts. Die Abhängigkeit wird nur für ein bestimmtes Beispiel von HDD bis 1 TB gefunden. Wenn Sie der DVR-Festplatte eine andere Kapazität hinzufügen, sehen die Konstanten möglicherweise anders aus.Um die Gültigkeit der Formel zu überprüfen, berechnen wir die Position des ersten Segments einer anderen beliebigen .264-Datei, die von der entsprechenden nvr-Datei geleitet wird. Vergleichen Sie das Datum und die Uhrzeit im Dateinamen und vergleichen Sie sie mit den ersten Bytes im .264-Header des berechneten Sektors. Bytes, die die Anzahl, den Monat, das Jahr, die Stunden, die Minuten und die Sekunden einzeln codieren, entsprechen temporären Daten im Dateinamen. Deshalb "den Nagel treffen"! Wir berechnen in der nvr-Datei, die der im Voraus extrahierten .264-Datei entspricht, die Anzahl der cs-Segmente. Im Allgemeinen ist ihre Anzahl cs = sf / 32-1, wobei sf die Größe der nvr-Datei ist. Wenn die .264-Datei aus cs-Segmenten besteht, sollte ihre Größe gleich cs * 65536 + 4 sein (die Anzahl der Segmente multipliziert mit der Segmentgröße in Bytes plus 4 derselben Bytes von Nullen). Und das ist es wirklich!Versuchen Sie dennoch, den zweiten Abschnitt zu erkunden. Wie bereits erwähnt, befindet sich etwas Ähnliches wie ein Superblock direkt im ersten Sektor des Abschnitts (16016805). Und seine genaue Kopie wurde von sieben Sektoren unten entdeckt (16016812). Offensichtlich befinden sich grundlegende Informationen ungleich Null im ersten Sektor des Superblocks. Das Erscheinungsbild im Festplatteneditor ist in der folgenden Abbildung dargestellt.
Ich habe es geschafft, einen Teil der 4-Byte-Parameter zu entschlüsseln. Datum und Uhrzeit der Montage der Partition sind blau hervorgehoben. Datum und Uhrzeit werden in einer speziellen Notation „Unix-Zeit“ dargestellt (die Anzahl der Sekunden, die seit Mitternacht am 1. Januar 1970 vergangen sind). Im obigen Beispiel entspricht „03 7E 74 54“ (Dezimalwert 1416920579) „Di, 25. November 2014, 13:02:59 GMT“. Um die Werte zu übersetzen, habe ich einen speziellen Online-Rechner verwendet. Der Wert 65536 ist im violetten Rahmen eingekreist. Es ist möglich, dass der Dateisysteminterpreter im DVR-Programm beim Lesen der Blockgröße auf diese Position des Superblocks verweist (im vorherigen Kontext habe ich Blocksegmente genannt). Die Werte 1 werden im grünen Rahmen hervorgehoben. Einer von ihnen gibt wahrscheinlich die Position des sogenannten Anfangs an Bitmap (in der Anzahl der Blöcke vom Anfang des Abschnitts). In der TatIm Voraus wurde der Anfang der Informationen gefunden, ähnlich einer Bitmap für den Sektor 16016933 (16016805 + 128 * 1). Der Wert 233 wird im roten Rahmen hervorgehoben. Dies ist genau die Position des Beginns dieser .264-Videoaufnahmen vom Anfang des Abschnitts: 16016805 + 128 * 233 = 16046629.Das heißt, der zweite Abschnitt kann als abgeschnittener und leicht modifizierter Abschnitt von EXT2 bezeichnet werden. Es hat einen Superblock, eine Kopie davon, eine Bitmap. Es gibt aber keine sogenannten. Informationsknoten, die Dateidatensätzen entsprechen. Der Abschnitt enthält Daten von .264-Dateien (Audio- und Videostreams), aber die Informationsknoten (sagen wir mal) für diese Daten befinden sich in NVR-Dateien im ersten Abschnitt. Vielleicht gibt es eine kompetentere Formulierung? Das ist mir aber nicht so wichtig.Schreiben wir ein einfaches Programm zur Massenextraktion von .264-Dateien. Ich muss sofort sagen, dass ich nicht viel Erfahrung in der Programmierung unter Windows habe. Das Programm scannt alle NVR-Dateien, die vorab in den 1-TB-Bereich der neuen Festplatte kopiert wurden. Durch die Analyse erstellt das Programm eine .264-Datei mit demselben Namen im selben Verzeichnis und verwendet dabei den Zugriff auf die Sektoren der ursprünglichen Festplatte. Zuvor wurde in einem leeren Bereich der neuen Festplatte ein Ordner mit dem Namen „DVR“ erstellt, in dem Ordner nach Datum abgelegt werden, die unter Linux auf die „übliche Weise“ kopiert werden. Es war möglich, einen Algorithmus für die Arbeit mit der ersten Linux-Partition in dieses Programm aufzunehmen, um auf NVR-Dateien zuzugreifen, damit diese nicht vorab kopiert werden müssen. Und Sie könnten andere praktische Funktionen hinzufügen. Ja, das war möglich, aber in diesem Moment wollte ich alles so schnell wie möglich erledigen.Ich habe keine Rekursion zum Scannen von Verzeichnissen verwendet, da das Format der Verzeichnisse festgelegt ist und zwei Anhangsebenen aufweist. Dementsprechend habe ich zwei Zyklen angewendet: Durchlaufen der Ordner bis zum Ende und Durchlaufen der Dateien in jedem Ordner mit derselben Bedingung. Zum Lesen von Dateien habe ich die Funktion fopen verwendet. Für die Arbeit mit Festplattensektoren habe ich die WinAPI-Funktionalität verwendet, die der Arbeit mit Dateien ähnelt. Fahren wir mit dem Programmcode fort.Bibliotheken brauchen solche.#include <windows.h> #include <stdio.h> #include <string.h>
Und ich habe diese Funktionen komplett aus einem Forum kopiert.
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);
Die Kopierfunktion enthält eine lineare Abhängigkeitsformel, die in der obigen Theorie enthalten ist.
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); }
Die Hauptfunktion ist auch recht einfach.
int main(){ HANDLE hdd = openDevice(1);
Auf einem alten Computer mit einem Pentium 4-Prozessor und einem PCI-SATA-Controller übertrug das Programm erfolgreich eine Vollfestplatte mit mehreren tausend .264-Dateien in durchschnittlich 7 Stunden. Auf einem neuen Computer - dreimal schneller. Wie bereits erwähnt, ist das Programm nicht universell, alle Konstanten und Variablen werden von HDD bis 1 TB an meinen speziellen Fall angepasst. Sie können jedoch etwas mehr arbeiten und es universell machen, indem Sie eine grafische Oberfläche dazu zeichnen.
Im zweiten Teil des Artikels werde ich schreiben, wie man es selbst macht, um vom Container "264" in den Standardcontainer "avi" umzupacken.