Der Funktionscode (FC) im Telegrammkopf identifiziert den Telegrammtyp, z. B. Anforderungstelegramm (Request oder Send/Request) und Bestätigungs- oder Antworttelegramm (Acknowledgement Frame, Response Frame). Darüber hinaus enthält der Funktionscode die eigentliche Übertragungsfunktion und Steuerinformationen, die den Verlust und die Duplizierung von Nachrichten verhindern, oder den Stationstyp mit FDL-Status.

7	6	5	4	3	2	1	0	FC: Funktionscode-Anfrage
	1							Telegramm anfordern
			X					FCV = Alternierendes Bit eingeschaltet
		X						href=“http://profibus.felser.ch/de/funktionscode.htm#aufruffolgebit“>FCB = Alternierendes Bit (aus Frame Count)
1				0 (0x0)				CV = Taktwert()
1				andere				Reserviert
0				0 (0x0)				TE = Time Event (Uhrsynchronisation)
0				3 (0x3)				SDA_LOW = Sendedaten bestätigt – niedrige Priorität
0				4 (0x4)				SDN_LOW = Daten senden nicht bestätigt – niedrige Priorität
0				5 (0x5)				SDA_HIGH = Sendedaten bestätigt – hohe Priorität
0				6 (0x6)				SDN_HIGH = Daten senden nicht bestätigt
0				7 (0x7)				MSRD = Anforderungsdaten mit Multicast-Antwort senden
0				9 (0x9)				Fordern Sie den FDL-Status an
0				12(0xC)				SRD niedrig = Daten senden und anfordern
0				13(0xD)				SRD hoch = Daten senden und anfordern
0				14(0xE)				Ident mit Antwort anfordern
0				15 (0xF)				LSAP-Status mit Antwort anfordern 1)
0				andere				Reserviert

1) Dieser Wert ist in der letzten Version von der Standard nicht definiert, sondern nur noch reserviert

7	6	5	4	3	2	1	0	FC: Funktionscode-Antwort
	0							Antworttelegramm
0								Reserviert
		0	0					Sklave
		0	1					Meister nicht bereit
		1	0					Master bereit, ohne Token
		1	1					Master bereit, im Token-Ring
				0 (0x0)				OK
				1 (0x1)				UE = Benutzerfehler
				2 (0x2)				RR = Keine Ressourcen
				3 (0x3)				RS = SAP nicht aktiviert
				8 (0x8)				DL = Data Low (Normalfall bei DP)
				9 (0x9)				NR = Keine Antwortdaten bereit
				10(0xA)				DH = Daten hoch (DP-Diagnose ausstehend)
				12(0xC)				RDL = Daten nicht empfangen und Daten niedrig
				13(0xD)				RDH = Daten nicht empfangen und Daten hoch
				andere				Reserviert

Frame Count Bit Das Frame Count Bit FCB (b5) verhindert die Duplizierung von Nachrichten durch die bestätigende oder antwortende Station (Responder) und jeglichen Verlust durch die rufende Station (Initiator). Ausgenommen hiervon sind Anfragen ohne Bestätigung (SDN) sowie FDL-Status-, Ident- und LSAP-Statusanfragen.

Für die Sicherheitssequenz muss der Initiator für jeden Responder einen FCB mit sich führen. Wenn ein Request-Telegramm (Request oder Send/Request) zum ersten Mal an einen Responder gesendet wird oder wenn es erneut an einen Responder gesendet wird, der derzeit als nicht betriebsbereit markiert ist, muss der FCB wie im Responder definiert eingestellt werden. Dies erreicht der Initiator in einem Request-Telegramm mit FCV=0 und FCB=1. Der Responder muss ein solches Telegramm als ersten Nachrichtenzyklus bewerten und den FCB=1 zusammen mit der Adresse des Initiators (SA) speichern (siehe folgende Tabelle). Dieser Nachrichtenzyklus wird vom Initiator nicht wiederholt. Bei nachfolgenden Request-Telegrammen an denselben Responder muss der Initiator mit jedem neuen Request-Telegramm FCV=1 setzen und den FCB wechseln. Jeder Responder, der ein an ihn adressiertes Request-Telegramm mit FCV=1 empfängt, muss den FCB auswerten. Wenn sich der FCB im Vergleich zum letzten Request-Telegramm desselben Initiators (gleicher SA) geändert hat, ist dies eine gültige Bestätigung, dass der vorangegangene Nachrichtenzyklus ordnungsgemäß abgeschlossen wurde. Stammt das Request-Telegramm von einem anderen Initiator (anderer SA), ist eine Auswertung des FCB nicht mehr notwendig. In beiden Fällen muss der Responder den FCB mit der Quell-SA speichern, bis er ein neues, an ihn adressiertes Telegramm erhält. Im Falle eines verlorenen oder beeinträchtigten Bestätigungs- oder Antworttelegramms darf der FCB vom Initiator im Anforderungswiederholungsversuch nicht geändert werden: Dies zeigt an, dass der vorherige Nachrichtenzyklus fehlerhaft war. Wenn der Responder ein Request-Telegramm mit FCV=1 und demselben FCB wie das letzte Request-Telegramm vom selben Initiator (dem gleichen SA) empfängt, deutet dies auf einen erneuten Request-Versuch hin. Der Antwortende muss seinerseits das bereitgehaltene Bestätigungs- bzw. Antworttelegramm erneut senden. Bis zur oben genannten Bestätigung bzw. zum Empfang eines nicht quittierten Telegramms mit einer anderen Adresse (SA oder DA) (Send Data with No Acknowledge, SDN) muss der Responder das letzte Acknowledgement bzw. Antworttelegramm für einen eventuellen Wiederholungsversuch der Anfrage bereithalten . Bei nicht quittierten Request-Telegrammen und mit Request FDL Status, Ident und LSAP Status ist FCV=0 und FCB=0; Eine Auswertung durch den Responder ist nicht mehr erforderlich.

b5	b4	Bitposition
FCB	FCV	Zustand	Bedeutung	Aktion
0	0	DA = TS/127	Anfrage ohne Bestätigung Fordern Sie den FDL-Status/Ident/LSAP-Status an	Letzte Bestätigung löschen
0/1	0/1	DA#TS	Anfrage an einen anderen Antwortenden
1	0	DA = TS	Erste Anfrage	FCBM:= 1 SAM:=SA Letzte Bestätigung/Antwort löschen
0/1	1	DA = TS SA = SAM FCB#FCBM	Neue Anfrage	Letzte Bestätigung/Antwort löschen FCBM:=FCB Halten Sie die Bestätigung/Antwort für einen erneuten Versuch bereit
0/1	1	DA = TS SA = SAM FCB = FCBM	Wiederholungsanforderung	FCBM:=FCB Quittierung/Antwort wiederholen und weiter in Bereitschaft halten
0/1	1	DA = TS SA#SAM	Neuer Initiator	FCBM:=FCB SAM:= SA Bestätigung/Antwort in Bereitschaft für einen erneuten Versuch halten

FCBM hat FCB im Speicher gespeichert. SAM hat SA im Speicher gespeichert

Die Suche beim Scannen von Dateien bekannter Typen (oder, wie oft gesagt wird, die Suche nach Dateien anhand der Signatur) ist eine der effektivsten Methoden, die im R-Studio-Dienstprogramm zur Datenwiederherstellung verwendet werden. Mithilfe einer bestimmten Signatur können Sie Dateien eines bestimmten Typs wiederherstellen, falls Informationen zur Verzeichnisstruktur und zu Dateinamen teilweise oder vollständig fehlen (beschädigt) sind.

Normalerweise wird die Festplattenpartitionstabelle verwendet, um den Speicherort von Dateien zu bestimmen. Wenn Sie eine Diskette mit einem Buch vergleichen, ähnelt die Partitionstabelle dem Inhaltsverzeichnis. Beim Scannen sucht R-Studio anhand bestimmter angegebener Signaturen nach bekannten Dateitypen in der Festplattenpartitionstabelle. Dies wird dadurch ermöglicht, dass praktisch jeder Dateityp eine einzigartige Signatur oder ein einzigartiges Datenmuster aufweist. Dateisignaturen befinden sich an einer bestimmten Stelle am Anfang der Datei und in vielen Fällen auch am Ende der Datei. Beim Scannen gleicht R-Studio die gefundenen Daten mit Signaturen bekannter Dateitypen ab, wodurch diese identifiziert und ihre Daten wiederhergestellt werden können.

Mithilfe der Technologie zum Scannen bekannter Dateitypen ermöglicht R-Studio die Wiederherstellung von Daten von Festplatten, die neu formatiert wurden und deren Partitionstabellen überschrieben wurden. Wenn außerdem eine Festplattenpartition überschrieben, beschädigt oder gelöscht wird, ist das Scannen bekannter Dateitypen die einzige Option.

Aber fast alles hat seine Nachteile und die bekannten Dateitypen, die in R-Studio verwendet werden, bilden da keine Ausnahme. Wenn Sie also bekannte Dateitypen scannen, können Sie mit R-Studio nur unfragmentierte Dateien wiederherstellen. Wie bereits erwähnt, ist dies jedoch in den meisten Fällen die neueste mögliche Methode.

R-Studio enthält bereits Signaturen der gängigsten Dateitypen (siehe vollständige Liste Dateien bekannter Typen finden Sie im Abschnitt „R-Studio Online-Hilfe“.)

Bei Bedarf kann der Benutzer neue Dateitypen zu R-Studio hinzufügen. Wenn Sie beispielsweise Dateien eines eindeutigen Typs oder solche, die nach dem Datum der letzten Veröffentlichung von R-Studio entwickelt wurden, suchen müssen, können Sie den Dateien bekannter Typen Ihre eigenen Signaturen hinzufügen. Dieser Prozess wird als nächstes besprochen.

Benutzerdefinierte Dateien bekannter Typen
Benutzerdefinierte Signaturen für bekannte Dateitypen werden in der im Dialogfeld „Einstellungen“ angegebenen XML-Datei gespeichert. Das Hinzufügen einer Signatur besteht aus zwei Teilen:

1. Ermittlung der Dateisignatur, die sich am Anfang der Datei und, falls vorhanden, am Ende der Datei befindet.
2. Generieren Sie eine XML-Datei mit einer Dateisignatur und anderen Informationen zum Dateityp.

All dies kann mit R-Studio erfolgen. Gleichzeitig müssen Sie kein Experte auf dem Gebiet der Erstellung (Bearbeitung) von XML-Dokumenten oder auf dem Gebiet der hexadezimalen Bearbeitung sein – in diesem Leitfaden (Artikel), der sich an den Benutzer selbst richtet Einstiegsniveau Alle Phasen dieses Prozesses werden im Detail besprochen.

Beispiel: Hinzufügen einer Signatur für eine MP4-Datei (XDCam-EX-Codec)
Sehen wir uns das Hinzufügen einer Dateisignatur am Beispiel einer mit erstellten .MP4-Datei an mit Sony XDCAM-EX. Sie können es beispielsweise bei einer Beschädigung der SD-Karte für Dateien verwenden, die Sie noch nicht auf der Festplatte Ihres Computers speichern konnten.

Erster Schritt: Bestimmen der Dateisignatur
Um die Dateisignatur zu bestimmen, betrachten Sie Beispiele für Dateien desselben Formats.

Dies seien vier Videodateien von Sony XDCAM-EX:
ZRV-3364_01.MP4
ZRV-3365_01.MP4
ZRV-3366_01.MP4
ZRV-3367_01.MP4

Der Einfachheit halber sollten es sich hierbei um kleine Dateien handeln. Größere Dateien sind im Hexadezimalformat schwieriger anzuzeigen.

1. Öffnen Sie die Dateien in R-Studio. Klicken Sie dazu mit der rechten Maustaste auf jede Datei und wählen Sie im Kontextmenü „Anzeigen/Bearbeiten“.

2. Vergleichen wir die Dateien. Wir werden nach dem gleichen Muster suchen, das in allen vier Dateien zu finden ist. Er wird erscheinen Dateisignatur. Typischerweise befinden sich Dateisignaturen am Anfang der Datei, manchmal jedoch auch am Ende.

3. Definieren Sie die Dateisignatur am Anfang der Datei. In unserem Beispiel befindet es sich ganz am Anfang der Datei. Beachten Sie, dass dies nicht immer der Fall ist – oft steht die Dateisignatur am Anfang der Datei, aber nicht in der ersten Zeile (Offset).

Aus den Bildern unten geht hervor, dass der Inhalt aller vier Dateien unterschiedlich ist, sie jedoch alle mit derselben Dateisignatur beginnen.


Klicken Sie auf das Bild, um es zu vergrößern

Klicken Sie auf das Bild, um es zu vergrößern

Klicken Sie auf das Bild, um es zu vergrößern

Klicken Sie auf das Bild, um es zu vergrößern

Der hervorgehobene Bereich in den Bildern ist die Dateisignatur dieses Dateityps. Es wird sowohl im Text- als auch im Hexadezimalformat dargestellt.

In Textform sieht die Dateisignatur so aus:
....ftypmp42....mp42........kostenlos

Punkte („.“) kennzeichnen Zeichen, die nicht in Textform dargestellt werden können. Daher ist es auch notwendig, die hexadezimale Form der Dateisignatur anzugeben:
00 00 00 18 66 74 79 6D 70 34 32 00 00 00 00 6D 70 34 32 00 00 00 00 00 00 00 08 66 72 65 65

4. Auf die gleiche Weise definieren wir die Dateisignatur, jedoch ganz am Ende der Datei. Es kann sich um eine andere Dateisignatur oder eine andere Länge handeln.

Die folgenden Bilder heben die Dateisignatur am Ende der Datei hervor:


Klicken Sie auf das Bild, um es zu vergrößern

Klicken Sie auf das Bild, um es zu vergrößern

Klicken Sie auf das Bild, um es zu vergrößern

Klicken Sie auf das Bild, um es zu vergrößern

Bitte beachten Sie, dass die Daten vor dem ausgewählten Bereich (Dateisignatur) in allen vier Dateien gleich sind. Hierbei handelt es sich um technische Informationen, die keine Dateisignatur darstellen, sondern darauf hinweisen, dass alle vier Bilder (Dateien) mit derselben Kamera und denselben Parametern aufgenommen wurden. In der Regel ist es möglich, übereinstimmende Muster mit technischen Informationen aus einer Dateisignatur zu unterscheiden. In unserem Beispiel sehen wir in der letzten Zeile vor dem Beginn der Dateisignatur den Text „RecordingMode type=“normal““, der deutlich darauf hinweist, dass es sich um eine Art Dateiparameter und nicht um eine Signatur handelt. Achten Sie immer besonders auf diese Zeile, um sie nicht versehentlich einzufügen technische Informationen Teil der Dateisignatur.

In unserem Fall ist die Dateisignatur der folgende Text:
...
Wir möchten Sie daran erinnern, dass Punkte auf Zeichen hinweisen, die nicht in Textform dargestellt werden können.

Im Hexadezimalformat sieht die Dateisignatur so aus:
3N 2F 4E 6F 6E 52 65 61 6N 54 69 6A 65 4A 65 74 61 3E 0D 0A 00
Bitte beachten Sie: Die Signatur befindet sich nicht immer am Ende der Datei.

Zweite Stufe: Erstellen einer XML-Datei, die einen bekannten Dateityp beschreibt
Nachdem Sie nun die Dateisignatur definiert haben, können Sie eine XML-Datei erstellen und den entsprechenden Dateityp in R-Studio einbinden. Dies kann auf zwei Arten erfolgen:

2.1 Integrierte Verwendung Grafikeditor Dateisignaturen:
Wählen Sie im Menü „Extras“ den Eintrag „Einstellungen“ aus, klicken Sie im sich öffnenden Dialogfeld „Einstellungen“ auf die Registerkarte „Bekannte Dateitypen“ und dann auf die Schaltfläche „Dateitypen des Benutzers bearbeiten“.

Klicken Sie auf das Bild, um es zu vergrößern

Klicken Sie im Dialogfeld „Dateitypen des Benutzers bearbeiten“ auf die Schaltfläche „Dateityp erstellen“.
Legen Sie die folgenden Optionen fest:

• Id – eine eindeutige digitale Kennung. Diese Zahl wird zufällig ausgewählt; Das Einzige ist, dass es nicht mit der digitalen Kennung eines anderen Dateityps übereinstimmen sollte.
• Gruppenbeschreibung – die Gruppe, in der sich die gefundenen Dateien in R-Studio befinden. Sie können entweder eine neue Gruppe einrichten oder eine der bereits vorhandenen auswählen. Für uns wird dies die Gruppe „Multimedia Video (Multimedia: Video)“ sein.
• Beschreibung - kurze Beschreibung Dateityp. In unserem Beispiel können Sie beispielsweise „Sony Cam Video, XDCam-EX“ verwenden.
• Erweiterung – Erweiterung von Dateien dieses Typs. In unserem Fall - mp4.

Der Parameter Features ist optional, in unserem Fall müssen wir ihn nicht verwenden.

Klicken Sie auf das Bild, um es zu vergrößern

Als nächstes müssen Sie die Start- und Endsignatur der Datei eingeben. Wählen Sie dazu „Begin“ und dann „in“. Kontextmenü den Befehl „Signatur hinzufügen“.

Klicken Sie auf das Bild, um es zu vergrößern

Anschließend doppelklicken Sie auf das Feld<пустая сигнатура> () und geben Sie den entsprechenden Text ein.

Klicken Sie auf das Bild, um es zu vergrößern

Erstellen Sie dann die endgültige Dateisignatur. Geben Sie unbedingt 21 in das Feld „Von-Spalte“ ein.

Klicken Sie auf das Bild, um es zu vergrößern

Sie haben erfolgreich Ihre eigene Signatur für bekannte Dateitypen erstellt.

Jetzt müssen Sie es speichern. Es gibt zwei Möglichkeiten: Sie können es entweder in der Standarddatei speichern, die auf der Registerkarte „Haupt“ des Dialogfelds „Einstellungen“ angegeben ist, indem Sie auf die Schaltfläche „Speichern“ klicken. Oder klicken Sie auf die Schaltfläche Speichern unter... und speichern Sie die Signatur in einer anderen Datei.

2.2 Manuelles Erstellen einer XML-Datei, die einen bekannten Dateityp beschreibt:
Zu erschaffen diese Datei Lassen Sie uns XML Version 1.0 und UTF-8-Kodierung verwenden. Verzweifeln Sie nicht, wenn Sie nicht wissen, was es ist – öffnen Sie einfach eines Texteditor(z. B. Notepad.exe) und geben Sie in der ersten Zeile den folgenden Text ein:

Als nächstes erstellen wir ein XML-Tag, das den Dateityp (FileType) definiert. Unter Berücksichtigung der zuvor beschriebenen XML-Attribute sieht das Tag folgendermaßen aus:

Fügen wir es gleich danach ein

Als nächstes definieren wir die Dateisignatur (tag ). Die ursprüngliche Signatur (am Anfang der Datei) befindet sich im Tag ohne Attribute. Wir verwenden den Texttyp der Signatur, ersetzen ihn aber gleichzeitig durch hexadezimale Zeichen, die nicht in Textform dargestellt werden können. Vor jedem Hexadezimalzeichen fügen wir „\x“ ein. Somit das Tag mit einer Dateisignatur sieht so aus:

Falls vorhanden, müssen Sie auch die Endsignatur (am Ende der Datei) definieren. Dabei wird das gleiche Tag verwendet, jedoch mit einem „from“-Element und einem „end“-Attribut. Es wird so aussehen:

Denken Sie daran, dass die endgültige Dateisignatur keine Nicht-Textzeichen, sondern Schrägstriche und dreieckige Klammern enthielt. Um Verwirrung und Fehler in der XML-Syntax zu vermeiden, ersetzen wir die Zeichen „/“, „ in der Signatur<" и ">" ihre hexadezimalen Werte.

Am Ende, nach den Dateisignaturen, müssen die schließenden Tags FileType und FileTypeList stehen:

Die gesamte Datei sollte also so aussehen:


\x00\x00\x00\x18ftypmp42\x00\x00\x00\x00mp42\x00\x00\x00\x00\x00\x00\x00\x08kostenlos
\x3C\x2FNonRealTimeMeta\x3E\x0D\x0A\x00

Denken Sie daran: Bei der XML-Syntax wird die Groß-/Kleinschreibung beachtet, daher wäre das richtige Tag , nicht .

Speichern wir die Datei im Textformat mit der Erweiterung .xml. Beispiel: SonyCam.xml.

Wir haben erfolgreich unsere eigene Signatur für bekannte Dateitypen erstellt. Dieses Beispiel reicht völlig aus, um die Grundprinzipien der Erstellung eines benutzerdefinierten Dateityps zu verstehen. Erfahrenere Benutzer können XML Version 2.0 verwenden. Weitere Informationen hierzu finden Sie im Abschnitt „Online-Hilfe“ von R-Studio.

Schritt 3: Überprüfen und Hinzufügen einer Datei, die einen bekannten Dateityp beschreibt
Der nächste Schritt besteht darin, Ihre XML-Datei zu R-Studio hinzuzufügen (hochzuladen). In diesem Fall wird dies automatisch überprüft.

Laden wir die im vorherigen Schritt erstellte XML-Datei in R-Studio. Wählen Sie dazu im Menü Extras den Punkt Einstellungen. Fügen Sie im Bereich „Benutzerdateitypen“ der Registerkarte „Haupt“ des Dialogfelds „Einstellungen“ die von uns erstellte XML-Datei (SonyCam.xml) hinzu. Klicken Sie auf die Schaltfläche „Übernehmen“.

Klicken Sie auf das Bild, um es zu vergrößern

2. Beantworten Sie die Anfrage zum Herunterladen eines neuen Dateityps mit „Ja“.

Klicken Sie auf das Bild, um es zu vergrößern

3. Um zu überprüfen, ob der Dateityp erfolgreich geladen wurde, klicken Sie im Dialogfeld „Einstellungen“ auf die Registerkarte „Bekannte Dateitypen“. Denken Sie daran, dass wir den Dateityp zur Gruppe „Multimedia-Video“ hinzugefügt haben. Nachdem wir diese Gruppe (Ordner) erweitert haben, sollten wir ein Element mit der Beschreibung sehen, die wir beim Erstellen der XML-Datei angegeben haben: Sony Cam Video, XDCam-EX (.mp4).

Klicken Sie auf das Bild, um es zu vergrößern

Klicken Sie auf das Bild, um es zu vergrößern

Bei Fehlern in der Dateisyntax erhalten Sie eine entsprechende Meldung:

Klicken Sie auf das Bild, um es zu vergrößern

Überprüfen Sie in diesem Fall Ihre XML-Datei erneut auf Fehler. Denken Sie daran: Bei der XML-Syntax wird die Groß-/Kleinschreibung beachtet und jedes Tag muss am Ende ein schließendes Tag haben.

Schritt 4: Testen der Datei unter Beschreibung eines bekannten Dateityps
Um die Richtigkeit des von uns erstellten benutzerdefinierten Dateityps zu überprüfen, versuchen wir, unsere .mp4-Dateien auf einem austauschbaren USB-Flash-Laufwerk zu finden.

1. Führen Sie unter Windows Vista oder Windows 7 eine vollständige (nicht schnelle) Formatierung der Festplatte durch oder verwenden Sie ein Dienstprogramm zur Speicherplatzbereinigung (z. B. R-Wipe & Clean). vollständige Entfernung alle auf der Festplatte verfügbaren Daten. Lassen USB-Festplatte in FAT32 formatiert (die Größe der gesuchten Dateien überschreitet nicht 2 GB).

2. Kopieren Sie die Testdateien auf die Festplatte und starten Sie den Computer neu, damit der Inhalt des Cache-Speichers auf der Festplatte gespeichert wird. Sie können es auch deaktivieren externes Laufwerk und dann wieder anschließen.

3. Im Betriebssystem wird das Laufwerk beispielsweise als logisches Laufwerk F:\ definiert.

4. Starten wir R-Studio. Wählen Sie unser Laufwerk (F:\) aus und klicken Sie auf die Schaltfläche Scannen

Klicken Sie auf das Bild, um es zu vergrößern

5. Klicken Sie im Dialogfeld „Scannen“ im Bereich (Dateisystem) auf die Schaltfläche „Ändern...“ und deaktivieren Sie alle Kontrollkästchen. Auf diese Weise deaktivieren wir die Suche nach Dateisystemen und Dateien mithilfe der Partitionstabelle.
Klicken Sie auf das Bild, um es zu vergrößern

6. Aktivieren Sie das Kontrollkästchen Zusätzliche Suche nach bekannten Dateitypen. Dadurch kann R-Studio beim Scannen nach bekannten Dateitypen suchen.

7. Um den Scanvorgang zu starten, klicken Sie auf die Schaltfläche „Scannen“.

8. Warten wir, während R-Studio die Festplatte scannt. Auf der Registerkarte Scan-Informationen wird der Scan-Fortschritt (Fortschritt) angezeigt.


Klicken Sie auf das Bild, um es zu vergrößern

9. Wählen Sie nach Abschluss des Scanvorgangs das Element „Extra Found Files“ aus und doppelklicken Sie darauf.


Klicken Sie auf das Bild, um es zu vergrößern

10. Unsere Testdateien befinden sich im Sony-Cam-Video-Ordner XDCam-EX (oder in einem Ordner mit einem anderen Namen, der der in der zweiten Stufe angegebenen Dateitypbeschreibung entspricht).


Klicken Sie auf das Bild, um es zu vergrößern

Sie sehen, dass die Dateinamen, Daten und Speicherorte (Ordner) nicht wiederhergestellt wurden, weil diese Informationen im Dateisystem gespeichert. Daher zeigt R-Studio jede Datei automatisch mit einem neuen Namen an.

Es ist jedoch klar, dass der Inhalt der Dateien nicht beschädigt ist. Um dies zu überprüfen, öffnen wir sie im entsprechenden Programm, zum Beispiel im VLC Media Player.


Klicken Sie auf das Bild, um es zu vergrößern

Abschluss
Dank der Fähigkeit von R-Studio, nach bekannten Dateitypen zu suchen, können Sie Daten sogar von einer Festplatte wiederherstellen, deren Dateisysteme entweder überschrieben wurden. Mithilfe ihrer Signaturen können Sie sehr effektiv nach Dateien suchen. Dies ist besonders nützlich, wenn Sie wie in unserem Beispiel genau wissen, welche Art von Dateien wiederhergestellt werden sollen. Durch die Möglichkeit, benutzerdefinierte Dateitypen zu erstellen, können Sie jede Datei mit einer bestimmten Dateisignatur zur Liste bekannter Dateitypen hinzufügen.

Viele haben vielleicht schon von Dateien wie rarjpeg gehört. Hierbei handelt es sich um einen speziellen Dateityp, bei dem es sich um ein eng zusammengeklebtes JPEG-Bild handelt. Es ist ein hervorragender Container, um die Tatsache zu verbergen, dass Informationen übertragen werden die folgenden Befehle:

UNIX: Katze image1.jpg archive.rar > image2.jpg
WINDOWS: Kopieren Sie /b image1.jpg+archive.rar image2.jpg

Oder wenn Sie einen Hex-Editor haben.

Um die Tatsache der Übermittlung von Informationen zu verbergen, können Sie natürlich nicht nur das JPEG-Format, sondern auch viele andere verwenden. Jedes Format hat seine eigenen Eigenschaften, aufgrund derer es für die Rolle eines Containers geeignet sein kann oder auch nicht. Ich beschreibe, wie Sie eingefügte Dateien in den gängigsten Formaten finden oder auf die Tatsache des Klebens hinweisen können.

Methoden zur Erkennung zusammengeführter Dateien können in drei Gruppen unterteilt werden:

1. Methode zur Überprüfung des Bereichs nach der EOF-Markierung. Viele gängige Dateiformate verfügen über einen sogenannten Dateiende-Marker, der für die Anzeige der gewünschten Daten zuständig ist. Fotobetrachter lesen beispielsweise alle Bytes bis zu dieser Markierung, der Bereich danach wird jedoch ignoriert. Diese Methode ist ideal für die folgenden Formate: JPEG, PNG, GIF, ZIP, RAR, PDF.
2. Methode zur Überprüfung der Dateigröße. Die Struktur einiger Formate (Audio- und Videocontainer) ermöglicht es Ihnen, die tatsächliche Dateigröße zu berechnen und mit der Originalgröße zu vergleichen. Formate: AVI, WAV, MP4, MOV.
3. Methode zur Überprüfung von CFB-Dateien. CFB oder Compound File Binary Format ist ein von Microsoft entwickeltes Dokumentformat, das einen eigenen Container darstellt Dateisystem. Diese Methode basiert auf der Erkennung von Anomalien in einer Datei.

Gibt es ein Leben nach dem Ende einer Datei?

JPEG

Um die Antwort auf diese Frage zu finden, ist es notwendig, sich mit den Spezifikationen des Formats, dem „Vorfahren“ der zusammengeführten Dateien, auseinanderzusetzen und seine Struktur zu verstehen. Jedes JPEG beginnt mit der Signatur 0xFF 0xD8.

Nach dieser Signatur gibt es Serviceinformationen, optional ein Bildsymbol und schließlich das komprimiertes Bild. In diesem Format wird das Ende des Bildes mit einer Zwei-Byte-Signatur 0xFF 0xD9 markiert.

PNG

Die ersten acht Bytes der PNG-Datei werden von der folgenden Signatur belegt: 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A. Endsignatur, die den Datenstrom beendet: 0x49, 0x45, 0x4E, 0x44, 0xAE, 0x42, 0x60, 0x82.

RAR

Gemeinsame Signatur für alle RAR-Archive: 0x52 0x61 0x72 0x21 (Rar!). Danach folgen Informationen über die Archivversion und andere zugehörige Daten. Es wurde experimentell festgestellt, dass das Archiv mit der Signatur 0x0A, 0x25, 0x25, 0x45, 0x4F, 0x46 endet.

Tabelle der Formate und ihrer Signaturen:
Der Algorithmus zur Prüfung auf Kleben in diesen Formaten ist äußerst einfach:

1. Finden Sie die ursprüngliche Unterschrift.
2. Finden Sie die endgültige Unterschrift;
3. Wenn nach der endgültigen Signatur keine Daten vorhanden sind, ist Ihre Datei sauber und enthält keine Anhänge! Andernfalls muss nach der endgültigen Signatur nach anderen Formaten gesucht werden.

GIF und PDF

Ein PDF-Dokument kann mehr als eine EOF-Markierung haben, beispielsweise aufgrund einer fehlerhaften Dokumentgenerierung. Die Anzahl der endgültigen Signaturen in einer GIF-Datei entspricht der Anzahl der darin enthaltenen Frames. Basierend auf den Eigenschaften dieser Formate ist es möglich, den Algorithmus zur Prüfung des Vorhandenseins angehängter Dateien zu verbessern.

1. Punkt 1 wird vom vorherigen Algorithmus wiederholt.
2. Punkt 2 wird vom vorherigen Algorithmus wiederholt.
3. Wenn Sie die endgültige Signatur gefunden haben, merken Sie sich deren Position und suchen Sie weiter.
4. Erreicht man auf diese Weise die letzte EOF-Markierung, ist die Datei sauber.
5. Wenn die Datei nicht mit einer Endsignatur endet, ist goto der Speicherort der letzten gefundenen Endsignatur.

Ein großer Unterschied zwischen der Dateigröße und der Position nach der letzten Endsignatur weist auf das Vorhandensein eines Sticky-Anhangs hin. Der Unterschied kann mehr als zehn Byte betragen, es sind jedoch auch andere Werte einstellbar.

REISSVERSCHLUSS

Die Besonderheit von ZIP-Archiven ist das Vorhandensein von drei verschiedenen Signaturen: Der Aufbau des Archivs ist wie folgt:

Lokaler Dateiheader 1

Dateidaten 1

Datendeskriptor 1

Lokaler Dateiheader 2

Dateidaten 2

Datendeskriptor 2

...

Lokaler Dateiheader

Dateidaten n

Datendeskriptor n

Archiv-Entschlüsselungsheader

Zusätzlichen Datensatz archivieren

Zentrales Verzeichnis

Am interessantesten ist das zentrale Verzeichnis, das Metadaten zu den Dateien im Archiv enthält. Das zentrale Verzeichnis beginnt immer mit der Signatur 0x50 0x4b 0x01 0x02 und endet mit der Signatur 0x50 0x4b 0x05 0x06, gefolgt von 18 Byte Metadaten. Interessanterweise bestehen leere Archive nur aus der Endsignatur und 18 Nullbytes. Nach 18 Byte kommt der Archivkommentarbereich, der ein idealer Container zum Ausblenden der Datei ist.

Um ein ZIP-Archiv zu überprüfen, müssen Sie die Endsignatur des zentralen Verzeichnisses finden, 18 Bytes überspringen und im Kommentarbereich nach Signaturen bekannter Formate suchen. Große Größe Der Kommentar weist auch auf die Tatsache des Klebens hin.

Auf die Größe kommt es an

AVI

Der Aufbau einer AVI-Datei ist wie folgt: Jede Datei beginnt mit einer RIFF-Signatur (0x52 0x49 0x46 0x46). Auf Byte 8 befindet sich eine AVI-Signatur, die das Format angibt (0x41 0x56 0x49 0x20). Der Block am Offset 4, bestehend aus 4 Bytes, enthält die Anfangsgröße des Datenblocks (Bytereihenfolge – Little Endian). Um die Blocknummer herauszufinden, die die nächste Größe enthält, müssen Sie die Header-Größe (8 Byte) und die im 4-8-Byte-Block erhaltene Größe addieren. Dadurch wird die Gesamtdateigröße berechnet. Es ist akzeptabel, dass die berechnete Größe kleiner als die tatsächliche Dateigröße ist. Nach der berechneten Größe enthält die Datei nur noch null Bytes (notwendig, um die 1-KB-Grenze auszurichten).

Beispiel zur Größenberechnung:

WAV

Wie AVI beginnt eine WAV-Datei mit einer RIFF-Signatur, diese Datei hat jedoch eine Signatur ab Byte 8 – WAVE (0x57 0x41 0x56 0x45). Die Dateigröße wird auf die gleiche Weise wie bei AVI berechnet. Tatsächliche Größe muss genau mit der Berechnung übereinstimmen.

MP4

MP4 oder MPEG-4 ist ein Mediencontainerformat, das zum Speichern von Video- und Audiostreams verwendet wird und auch die Speicherung von Untertiteln und Bildern ermöglicht.
Bei Offset 4 Bytes gibt es Signaturen: Dateityp ftyp (66 74 79 70) (QuickTime Container File Type) und Dateiuntertyp mmp4 (6D 6D 70 34). Zur Anerkennung versteckte Dateien, wir sind an der Möglichkeit interessiert, die Dateigröße zu berechnen.

Schauen wir uns ein Beispiel an. Die Größe des ersten Blocks liegt bei Offset Null und beträgt 28 (00 00 00 1C, Big-Endian-Bytereihenfolge); Es gibt auch den Offset an, an dem sich die Größe des zweiten Datenblocks befindet. Bei Offset 28 finden wir die nächste Blockgröße gleich 8 (00 00 00 08). Um die nächste Blockgröße zu ermitteln, müssen Sie die Größen der zuvor gefundenen Blöcke addieren. Somit wird die Dateigröße berechnet:

MOV

Dieses weit verbreitete Format ist auch ein MPEG-4-Container. MOV verwendet einen proprietären Datenkomprimierungsalgorithmus, hat eine ähnliche Struktur wie MP4 und wird für die gleichen Zwecke verwendet – zum Speichern von Audio- und Videodaten sowie zugehörigen Materialien.
Wie MP4 hat jede mov-Datei eine 4-Byte-ftyp-Signatur bei Offset 4, die nächste Signatur hat jedoch den Wert qt__ (71 74 20 20). Die Regel zur Berechnung der Dateigröße hat sich nicht geändert: Beginnend mit dem Anfang der Datei berechnen wir die Größe des nächsten Blocks und addieren sie.

Die Methode zur Überprüfung dieser Formatgruppe auf das Vorhandensein von „Sticky“-Dateien besteht darin, die Größe gemäß den oben angegebenen Regeln zu berechnen und sie mit der Größe der überprüften Datei zu vergleichen. Wenn die aktuelle Dateigröße viel kleiner ist als die berechnete, deutet dies auf eine Verklebung hin. Bei der Überprüfung von AVI-Dateien wird in Kauf genommen, dass die berechnete Größe möglicherweise kleiner als die Dateigröße ist, da zum Ausrichten des Rahmens hinzugefügte Nullen vorhanden sind. In diesem Fall muss nach der berechneten Dateigröße nach Nullen gesucht werden.

Überprüfen des Binärformats der zusammengesetzten Datei

Dieses von Microsoft entwickelte Dateiformat ist auch als OLE (Object Linking and Embedding) oder COM (Component Object Model) bekannt. DOC-Dateien, XLS, PPT gehören zur Gruppe der CFB-Formate.

Eine CFB-Datei besteht aus einem 512-Byte-Header und Sektoren gleicher Länge, in denen Datenströme oder Dienstinformationen gespeichert sind. Jeder Sektor hat seine eigene nicht negative Zahl, mit Ausnahme von Sondernummern: „-1“ – nummeriert den freien Sektor, „-2“ – nummeriert den Sektor, der die Kette schließt. Alle Sektorketten sind in der FAT-Tabelle definiert.

Nehmen wir an, dass ein Angreifer eine bestimmte DOC-Datei geändert und am Ende eine weitere Datei eingefügt hat. Es gibt mehrere auf verschiedene Weise es erkennen oder auf eine Anomalie im Dokument hinweisen.

Ungewöhnliche Dateigröße

Wie oben erwähnt, besteht jede CFB-Datei aus einem Header und gleich langen Sektoren. Um die Sektorgröße herauszufinden, müssen Sie eine Zwei-Byte-Zahl bei Offset 30 vom Anfang der Datei lesen und diese Zahl mit 2 potenzieren. Diese Zahl muss entweder 9 (0x0009) oder 12 (0x000C) sein, die Dateisektorgröße beträgt 512 oder 4096 Byte. Nachdem Sie den Sektor gefunden haben, müssen Sie die folgende Gleichheit überprüfen:

(FileSize - 512) mod SectorSize = 0

Wenn diese Gleichheit nicht erfüllt ist, können Sie auf die Tatsache hinweisen, dass die Dateien verklebt sind. Diese Methode hat jedoch einen erheblichen Nachteil. Wenn ein Angreifer die Sektorgröße kennt, muss er nur seine Datei und weitere n Bytes einfügen, sodass die Größe der eingefügten Daten ein Vielfaches der Sektorgröße beträgt.

Unbekannter Sektortyp

Wenn einem Angreifer eine Methode zur Umgehung der vorherigen Prüfung bekannt ist, kann diese Methode das Vorhandensein von Sektoren mit undefinierten Typen erkennen.

Definieren wir Gleichheit:

FileSize = 512 + CountReal * SectorSize, wobei FileSize die Dateigröße, SectorSize die Sektorgröße und CountReal die Anzahl der Sektoren ist.

Wir definieren außerdem die folgenden Variablen:

1. CountFat – Anzahl der FAT-Sektoren. Befindet sich bei Offset 44 vom Anfang der Datei (4 Bytes);
2. CountMiniFAT – Anzahl der MiniFAT-Sektoren. Befindet sich bei Offset 64 vom Anfang der Datei (4 Bytes);
3. CountDIFAT – Anzahl der DIFAT-Sektoren. Befindet sich am Offset 72 vom Anfang der Datei (4 Bytes);
4. CountDE – Anzahl der Verzeichniseintragssektoren. Um diese Variable zu finden, müssen Sie den ersten Sektor DE finden, der sich bei Offset 48 befindet. Dann ist es notwendig, eine vollständige Darstellung von DE aus FAT zu erhalten und die Anzahl der DE-Sektoren zu zählen;
5. CountStreams – Anzahl der Sektoren mit Datenströmen;
6. CountFree – Anzahl der freien Sektoren;
7. CountClassified – Anzahl der Sektoren mit einem bestimmten Typ;

CountClassified = CountFAT + CountMiniFAT + CountDIFAT + CountDE + CountStreams + CountFree

Wenn CountClassified und CountReal ungleich sind, können wir natürlich daraus schließen, dass Dateien möglicherweise zusammengeführt werden.

Mein Chef hat mir eine ziemlich interessante Aufgabe gegeben. Schreiben Sie in kurzer Zeit einen Analysator für ausführbare Dateien, der anhand von Signaturen Virenkörper finden und den verwendeten Packer/Kryptor bestimmen kann. Der fertige Prototyp erschien innerhalb weniger Stunden.

Wort des Autors

Signaturanalyse

Jedes Antivirenprogramm kann mithilfe von Signaturen nach einem schädlichen Objekt suchen. Im Allgemeinen ist eine Signatur eine formalisierte Beschreibung bestimmter Merkmale, anhand derer festgestellt werden kann, dass es sich bei der gescannten Datei um einen Virus und einen genau definierten Virus handelt.

Hier gibt es verschiedene Techniken. Eine Alternative besteht darin, eine Signatur zu verwenden, die aus N Bytes eines bösartigen Objekts besteht. In diesem Fall können Sie keinen dummen Vergleich durchführen, sondern einen Vergleich unter Verwendung einer Maske (wie die Suche nach Bytes EB ?? ?? CD 13). Oder legen Sie zusätzliche Bedingungen fest, z. B. „Diese und jene Bytes müssen sich am Einstiegspunkt des Programms befinden“ und so weiter. Eine besondere Angelegenheit ist die Signatur der Schadsoftware.

Ebenso werden einige Anzeichen beschrieben, anhand derer man feststellen kann, dass die ausführbare Datei mit dem einen oder anderen Kryptor oder Packer (zum Beispiel dem alltäglichen ASPack) gepackt ist. Wenn Sie unser Magazin sorgfältig lesen, dann haben Sie bestimmt schon von einem Tool wie PEiD gehört, das in der Lage ist, die am häufigsten verwendeten Packer, Kryptor und Compiler (die Datenbank verfügt über eine große Anzahl von Signaturen) für die darauf übertragene PE-Datei zu identifizieren . Leider wurden seit langem keine neuen Versionen des Programms veröffentlicht, und kürzlich erschien auf der offiziellen Website eine Meldung, dass das Projekt nicht weiterentwickelt wird. Schade, denn die Möglichkeiten von PEiD (vor allem im Hinblick auf das Plugin-System) könnten für mich durchaus nützlich sein. Nach einer kurzen Analyse wurde klar, dass dies keine Option war. Aber nachdem ich mich durch englischsprachige Blogs gekümmert hatte, fand ich schnell das, was zu mir passte. YARA-Projekt (code.google.com/p/yara-project).

Was ist YARA?

Von Anfang an war ich davon überzeugt, dass es irgendwo im Internet bereits eine Open-Source-Entwicklung gibt, die die Aufgabe übernehmen würde, die Übereinstimmung zwischen einer bestimmten Signatur und der zu untersuchenden Datei festzustellen. Wenn ich ein solches Projekt finden könnte, könnte es einfach in die Schienen einer Webanwendung gestellt werden, dort verschiedene Signaturen hinzufügen und das bekommen, was von mir verlangt wurde. Der Plan schien noch realistischer, als ich die Beschreibung des YARA-Projekts las.

Die Entwickler selbst positionieren es als Werkzeug, das Malware-Forschern dabei hilft, bösartige Proben zu identifizieren und zu klassifizieren. Der Forscher kann Beschreibungen erstellen für verschiedene Typen Malware, die Text- oder Binärmuster verwendet, die die formalisierten Merkmale von Malware beschreiben. So werden Unterschriften eingeholt. Tatsächlich besteht jede Beschreibung aus einer Reihe von Zeilen und einem logischen Ausdruck, auf deren Grundlage die Auslöselogik des Analysators bestimmt wird.

Wenn die Bedingungen einer der Regeln für die untersuchte Datei erfüllt sind, wird sie entsprechend ermittelt (z. B. dieser oder jener Wurm). Ein einfaches Beispiel einer Regel, um zu verstehen, wovon wir sprechen:

Regel silence_banker: Bankier
{
Meta:
Beschreibung = „Dies ist nur ein Beispiel“
thread_level = 3
in_the_wild = true
Saiten:
$a = (6A 40 68 00 30 00 00 6A 14 8D 91)
$b = (8D 4D B0 2B C1 83 C0 27 99 6A 4E 59 F7 F9)
$c = "UVODFRYSIHLNWPEJXQZAKCBGMT"
Zustand:
$a oder $b oder $c
}

In dieser Regel teilen wir YARA mit, dass jede Datei, die mindestens eine der in den Variablen $a, $b, $c beschriebenen Beispielzeichenfolgen enthält, als Silent_banker-Trojaner klassifiziert werden sollte. Und das ist eine sehr einfache Regel. In Wirklichkeit können Regeln viel komplexer sein (wir werden weiter unten darüber sprechen).
Sogar die Liste der Projekte, die es verwenden, spricht für die Autorität des YARA-Projekts, und zwar:

• VirusTotal Malware Intelligence Services (vt-mis.com);
• jsunpack-n (jsunpack.jeek.org);
• Wir überwachen Ihre Website (wewatchyourwebsite.com).

Der gesamte Code ist in Python geschrieben und dem Benutzer wird sowohl das Modul selbst zur Verwendung in seiner Entwicklung als auch lediglich eine ausführbare Datei zur Verwendung von YARA als eigenständige Anwendung angeboten. Im Rahmen meiner Arbeit habe ich mich für die erste Option entschieden, aber der Einfachheit halber verwenden wir in diesem Artikel den Analysator einfach als Konsolenanwendung.

Nach einigem Suchen habe ich schnell herausgefunden, wie man Regeln für YARA schreibt und wie man Virensignaturen der Freeware und Packer von PEiD daran anhängt. Aber wir beginnen mit der Installation.

Installation

Wie ich bereits sagte, ist das Projekt in Python geschrieben, sodass es problemlos auf Linux, Windows und Mac installiert werden kann. Zunächst können Sie einfach die Binärdatei verwenden. Wenn wir die Anwendung in der Konsole aufrufen, erhalten wir die Regeln für den Start.

$yara
Verwendung: yara ... ... DATEI | PID

Das heißt, das Format zum Aufrufen des Programms ist wie folgt: Zuerst steht der Name des Programms, dann eine Liste mit Optionen, danach wird die Datei mit den Regeln angezeigt und ganz am Ende der Name der Datei untersucht (oder das Verzeichnis, das die Dateien enthält) oder die Prozesskennung. Nun möchte ich gut erklären, wie genau diese Regeln erstellt werden, aber ich möchte Sie nicht gleich mit trockener Theorie belasten. Deshalb werden wir es anders machen und die Signaturen anderer Leute ausleihen, damit YARA eine unserer gestellten Aufgaben erfüllen kann – eine vollständige Erkennung von Viren anhand von Signaturen.

Ihr eigenes Antivirenprogramm

Die wichtigste Frage: Woher bekommt man die Signaturdatenbank? bekannte Viren? Antiviren-Unternehmen teilen solche Datenbanken aktiv untereinander (einige großzügiger, andere weniger). Ehrlich gesagt habe ich zunächst sogar daran gezweifelt, dass irgendwo im Internet jemand solche Dinge offen posten würde. Aber wie sich herausstellte, gibt es gute Leute. Eine passende Datenbank des beliebten Antivirenprogramms ClamAV steht jedem zur Verfügung (clamav.net/lang/en). Im Abschnitt „Neueste stabile Version“ finden Sie einen Link dazu neueste Version Antivirenprodukt sowie Links zum Herunterladen der ClamAV-Virendatenbanken. Wir werden uns hauptsächlich für die Dateien main.cvd (db.local.clamav.net/main.cvd) und daily.cvd (db.local.clamav.net/daily.cvd) interessieren.

Die erste enthält die Hauptdatenbank der Signaturen, die zweite enthält die vollständigste Datenbank im Moment Basis mit verschiedenen Ergänzungen. Daily.cvd, das mehr als 100.000 Malware-Impressionen enthält, reicht hierfür völlig aus. Da es sich bei der ClamAV-Datenbank jedoch nicht um eine YARA-Datenbank handelt, müssen wir sie in das gewünschte Format konvertieren. Aber wie? Schließlich wissen wir weder über das ClamAV-Format noch über das Yara-Format etwas. Dieses Problem wurde bereits vor uns gelöst, indem ein kleines Skript erstellt wurde, das die Signaturdatenbank des ClamAV-Virus in einen Satz YARA-Regeln umwandelt. Das Skript heißt clamav_to_yara.py und wurde von Matthew Richard (bit.ly/ij5HVs) geschrieben. Laden Sie das Skript herunter und konvertieren Sie die Datenbanken:

$ python clamav_to_yara.py -f daily.cvd -o clamav.yara

Als Ergebnis erhalten wir in der Datei clamav.yara eine sofort einsatzbereite Signaturdatenbank. Probieren wir nun die Kombination von YARA und der ClamAV-Datenbank in Aktion aus. Das Scannen eines Ordners mithilfe einer Signatur erfolgt mit einem einzigen Befehl:

$ yara -r clamav.yara /pentest/msf3/data

Die Option -r gibt an, dass der Scan rekursiv in allen Unterordnern des aktuellen Ordners durchgeführt werden soll. Wenn sich im Ordner /pentest/msf3/data Virenkörper befinden (zumindest diejenigen, die sich in der ClamAV-Datenbank befinden), wird YARA dies sofort melden. Im Prinzip handelt es sich hierbei um einen fertigen Signaturscanner. Der Einfachheit halber habe ich ein einfaches Skript geschrieben, das die Aktualisierungen der ClamAV-Datenbank überprüft, neue Signaturen herunterlädt und sie in das YARA-Format konvertiert. Aber das sind schon Details. Ein Teil der Aufgabe ist abgeschlossen, jetzt können Sie mit der Erstellung von Regeln zur Identifizierung von Packern/Kryptern beginnen. Aber dazu musste ich mich ein wenig mit ihnen auseinandersetzen.

Spielen Sie nach den Regeln

Eine Regel ist also der Hauptmechanismus eines Programms, der es Ihnen ermöglicht, eine bestimmte Datei einer bestimmten Kategorie zuzuordnen. Die Regeln werden in einer separaten Datei (oder Dateien) beschrieben und ähneln im Aussehen stark der struct()-Konstruktion aus der Sprache C/C++.

Regel BadBoy
{
Saiten:
$a = „win.exe“
$b = "http://foo.com/badfi le1.exe"
$c = "http://bar.com/badfi le2.exe"
Zustand:
$a und ($b oder $c)
}

Grundsätzlich ist das Schreiben von Regeln nichts Kompliziertes. In diesem Artikel habe ich nur die Hauptpunkte angesprochen, die Einzelheiten finden Sie im Handbuch. Vorerst die zehn wichtigsten Punkte:

1. Jede Regel beginnt mit dem Schlüsselwort „regel“, gefolgt von der Regelkennung. Bezeichner können dieselben Namen haben wie Variablen in C/C++, das heißt, sie können aus Buchstaben und Zahlen bestehen und das erste Zeichen darf keine Zahl sein. Die maximale Länge eines Bezeichnernamens beträgt 128 Zeichen.

2. Normalerweise bestehen Regeln aus zwei Abschnitten: einem Definitionsabschnitt (Strings) und einem Bedingungsabschnitt (Bedingung). Der Abschnitt „Strings“ gibt Daten an, auf deren Grundlage der Abschnitt „Bedingung“ entscheidet, ob eine bestimmte Datei bestimmte Bedingungen erfüllt.

3. Jede Zeile im Strings-Abschnitt hat einen eigenen Bezeichner, der mit dem $-Zeichen beginnt – im Allgemeinen wie eine Variablendeklaration in PHP. YARA unterstützt reguläre Zeichenfolgen, die in eingeschlossen sind doppelte Anführungszeichen("") und hexadezimale Zeichenfolgen in geschweiften Klammern (()) sowie reguläre Ausdrücke:

$my_text_string = "Text hier"
$my_hex_string = ( E2 34 A1 C8 23 FB )

4. Der Bedingungsabschnitt enthält die gesamte Logik der Regel. Dieser Abschnitt muss einen booleschen Ausdruck enthalten, der bestimmt, wann eine Datei oder ein Prozess mit der Regel übereinstimmt. Normalerweise bezieht sich dieser Abschnitt auf zuvor deklarierte Zeilen. Und die Zeichenfolgenkennung wird als boolesche Variable behandelt, die „true“ zurückgibt, wenn die Zeichenfolge in der Datei oder im Prozessspeicher gefunden wurde, andernfalls „false“. Die obige Regel gibt an, dass Dateien und Prozesse, die die Zeichenfolge win.exe und eine der beiden URLs enthalten, als BadBoy kategorisiert werden sollen (anhand des Regelnamens).

5. Hexadezimale Zeichenfolgen ermöglichen drei Konstrukte, die sie flexibler machen: Platzhalter, Sprünge und Alternativen. Ersetzungen sind unbekannte Stellen in einer Zeichenfolge, die durch einen beliebigen Wert ersetzt werden können. Sie sind mit dem Symbol „?“ gekennzeichnet:

$hex_string = ( E2 34 ?? C8 A? FB )

Dieser Ansatz ist sehr praktisch, wenn Sie Zeichenfolgen angeben, deren Länge bekannt ist, deren Inhalt jedoch variieren kann. Wenn Teile einer Zeichenfolge unterschiedliche Längen haben können, ist es praktisch, Bereiche zu verwenden:

$hex_string = ( F4 23 62 B4 )

Dieser Eintrag bedeutet, dass in der Mitte der Zeile 4 bis 6 verschiedene Bytes stehen können. Sie können auch eine alternative Auswahl implementieren:

$hex_string = ( F4 23 (62 B4 | 56) 45 )

Das bedeutet, dass anstelle des dritten Bytes 62 B4 oder 56 stehen können, ein solcher Eintrag entspricht den Zeilen F42362B445 oder F4235645.

6. Um zu überprüfen, was gegebene Zeile Wenn es sich an einem bestimmten Offset im Adressraum der Datei oder des Prozesses befindet, wird der Operator „at“ verwendet:

$a bei 100 und $b bei 200

Wenn die Zeichenfolge innerhalb eines bestimmten Adressbereichs liegen kann, wird der in-Operator verwendet:

$a in (0..100) und $b in (100..Dateigröße)

Manchmal treten Situationen auf, in denen Sie angeben müssen, dass eine Datei eine bestimmte Nummer aus einem bestimmten Satz enthalten soll. Dies geschieht mit dem of-Operator:

Regel vonBeispiel1
{
Saiten:
$foo1 = „dummy1“
$foo2 = „dummy2“
$foo3 = „dummy3“
Zustand:
2 von ($foo1,$foo2,$foo3)
}

Die obige Regel erfordert, dass die Datei zwei beliebige Zeilen aus der Menge ($foo1,$foo2,$foo3) enthält. Anstatt eine bestimmte Anzahl von Zeilen in der Datei anzugeben, können Sie die Variablen „any“ (mindestens eine Zeile aus einem bestimmten Satz) und „all“ (alle Zeilen aus einem bestimmten Satz) verwenden.

7. Nun, die letzte interessante Möglichkeit, die in Betracht gezogen werden muss, ist die Anwendung einer Bedingung auf viele Zeilen. Diese Funktion ist dem of-Operator sehr ähnlich, nur ist der for..of-Operator leistungsfähiger:

für Ausdruck von string_set: (boolescher_Ausdruck)

Dieser Eintrag sollte wie folgt gelesen werden: Von den im string_set angegebenen Zeichenfolgen müssen mindestens die Ausdrucksteile die boolesche_Ausdrucksbedingung erfüllen. Oder mit anderen Worten: Der boolesche_Ausdruck wird für jede Zeichenfolge im string_set ausgewertet, und die Ausdrücke daraus müssen True zurückgeben. Als nächstes betrachten wir diese Konstruktion anhand eines konkreten Beispiels.

PEiD erstellen

Wenn also mit den Regeln alles mehr oder weniger klar ist, können wir mit der Implementierung eines Detektors für Packer und Kryptor in unserem Projekt beginnen. Als Ausgangsmaterial habe ich mir zunächst die Unterschriften bekannter Packer des gleichen PEiD ausgeliehen. Im Plugins-Ordner gibt es eine Datei userdb.txt, die alles enthält, was wir brauchen. In meiner Datenbank befanden sich 1850 Unterschriften.

Ziemlich viele. Um sie vollständig zu importieren, empfehle ich Ihnen, eine Art Skript zu schreiben. Das Format dieser Datenbank ist einfach – es wird das übliche verwendet Textdatei, das Datensätze speichert wie:

Signatur = 50 E8 ?? ?? ?? ?? 58 25 ?? F0 FF FF 8B C8 83 C1 60 51 83 C0 40 83 EA 06 52 FF 20 9D C3
ep_only = true

Die erste Zeile gibt den Namen des Packers an, der in PEiD angezeigt wird, für uns ist er jedoch die Regelkennung. Das zweite ist die Signatur selbst. Das dritte ist das Flag ep_only, das angibt, ob nach einer bestimmten Zeile nur an der Einstiegspunktadresse oder in der gesamten Datei gesucht werden soll.

Versuchen wir nun, beispielsweise eine Regel für ASPack zu erstellen. Wie sich herausstellt, ist daran nichts Kompliziertes. Erstellen wir zunächst eine Datei zum Speichern der Regeln und nennen sie beispielsweise packers.yara. Anschließend durchsuchen wir die PEiD-Datenbank nach allen Signaturen, die ASPack in ihrem Namen enthalten, und übertragen diese in die Regel:

Regel ASPack
{
Saiten:
$ = ( 60 E8 ?? ?? ?? ?? 5D 81 ED ?? ?? (43 | 44) ?? B8 ?? ?? (43 | 44) ?? 03 C5 )
$ = ( 60 EB ?? 5D EB ?? FF ?? ?? ?? ?? ?? E9 )
[.. schneiden..]
$ = ( 60 E8 03 00 00 00 E9 EB 04 5D 45 55 C3 E8 01 )
Zustand:
für jeden von ihnen: ($at enterpoint)
}

Bei allen gefundenen Datensätzen ist das Flag ep_only auf true gesetzt, d. h. diese Zeilen müssen sich an der Einstiegspunktadresse befinden. Daher schreiben wir die folgende Bedingung: „für jeden von ihnen: ($at Entrypoint)“.

Das Vorhandensein mindestens einer der angegebenen Zeilen an der Einstiegspunktadresse bedeutet also, dass die Datei mit ASPack gepackt ist. Bitte beachten Sie auch, dass in diese Regel Alle Zeichenfolgen werden einfach mit dem $-Zeichen ohne Bezeichner angegeben. Dies ist möglich, weil wir im Bedingungsabschnitt nicht auf bestimmte Bedingungen zugreifen, sondern den gesamten Satz verwenden.

Um die Funktionalität des resultierenden Systems zu überprüfen, führen Sie einfach den Befehl in der Konsole aus:

$ yara -r packers.yara somefile.exe

Nachdem ich dort ein paar mit ASPack gepackte Anwendungen gefüttert hatte, war ich überzeugt, dass alles funktionierte!

Fertiger Prototyp

YARA erwies sich als äußerst klares und transparentes Tool. Es war für mich nicht schwierig, einen Webadmin dafür zu schreiben und es als Webdienst einzurichten. Mit etwas Kreativität werden die trockenen Ergebnisse des Analysers bereits in verschiedenen Farben eingefärbt, die den Grad der Gefährlichkeit der erkannten Schadsoftware anzeigen. Ein kleines Update der Datenbank, und für viele der Kryptor ist eine Kurzbeschreibung und teilweise sogar eine Entpackanleitung verfügbar. Der Prototyp wurde erstellt und funktioniert perfekt, und die Bosse tanzen vor Freude!

Das Konzept „ Magische Zahl„in der Programmierung hat drei Bedeutungen:

• Datensignatur
• Ausgewählte eindeutige Werte, die nicht mit anderen Werten (z. B. UUID) identisch sein sollten.
• Schlechte Programmierpraxis.

Datensignatur

Magische Zahl, oder Unterschrift, – eine Ganzzahl oder Textkonstante, die zur eindeutigen Identifizierung einer Ressource oder von Daten verwendet wird. Eine solche Zahl an sich hat keine Bedeutung und kann Verwirrung stiften, wenn sie im Programmcode ohne den entsprechenden Kontext oder Kommentar erscheint, während der Versuch, sie in eine andere zu ändern, auch wenn sie einen ähnlichen Wert hat, zu völlig unvorhersehbaren Folgen führen kann. Aus diesem Grund wurden solche Zahlen ironischerweise magische Zahlen genannt. Derzeit ist dieser Name als Begriff fest etabliert. Beispielsweise beginnt jede kompilierte Java-Sprachklasse mit der hexadezimalen „magischen Zahl“ 0xCAFEBABE. Das zweite weithin bekannte Beispiel ist eine beliebige ausführbare Datei des Betriebssystems Microsoft Windows mit der Erweiterung .exe beginnt mit der Bytefolge 0x4D5A (entspricht den ASCII-Zeichen MZ – den Initialen von Mark Zbikowski, einem der Erfinder von MS-DOS). Ein weniger bekanntes Beispiel ist der nicht initialisierte Zeiger in Microsoft Visual C++ (seit 2005). Microsoft-Versionen Visual Studio), das im Debug-Modus die Adresse 0xDEADBEEF hat.

Im UNIX-Stil Betriebssysteme Der Dateityp wird normalerweise durch die Dateisignatur bestimmt, unabhängig von der Erweiterung ihres Namens. Sie bieten ein Standard-Dateidienstprogramm zur Interpretation der Dateisignatur.

Schlechte Programmierpraxis

Auch „magische Zahlen“ genannt, ist eine schlechte Programmierpraxis, wenn ein numerischer Wert im Quelltext vorkommt und nicht offensichtlich ist, was er bedeutet. Ein in Java geschriebener Ausschnitt wie dieser wäre beispielsweise schlecht:

drawSprite(53, 320, 240);

final int SCREEN_WIDTH = 640 ;

final int SCREEN_HEIGHT = 480 ;

final int SCREEN_X_CENTER = SCREEN_WIDTH / 2 ;

• final int SCREEN_Y_CENTER = SCREEN_HEIGHT / 2 ;
• final int SPRITE_CROSSHAIR = 53 ;
• ... drawSprite(SPRITE_CROSSHAIR, SCREEN_X_CENTER, SCREEN_Y_CENTER);
• Jetzt ist es klar: Diese Zeile zeigt ein Sprite – das Fadenkreuz des Visiers – in der Mitte des Bildschirms an. In den meisten Programmiersprachen werden alle für solche Konstanten verwendeten Werte zur Kompilierungszeit berechnet und an den Stellen eingesetzt, an denen die Werte verwendet werden. Daher beeinträchtigt eine solche Änderung des Quelltextes nicht die Leistung des Programms.

Darüber hinaus stellen magische Zahlen eine potenzielle Fehlerquelle in einem Programm dar:

Manchmal schaden magische Zahlen dem plattformübergreifenden Code. Tatsache ist, dass in C auf 32- und 64-Bit-Betriebssystemen die Größe der Typen char , short und long long garantiert ist, während sich die Größe von int , long , size_t und ptrdiff_t ändern kann (für die ersten beiden abhängig von den Vorlieben der Compiler-Entwickler, für die letzten beiden – abhängig von der Bitkapazität des Zielsystems). In altem oder schlecht geschriebenem Code kann es „magische Zahlen“ geben, die die Größe eines Typs angeben – beim Wechsel zu Maschinen mit einer anderen Bitkapazität können sie zu subtilen Fehlern führen.

Zum Beispiel:

const size_t NUMBER_OF_ELEMENTS = 10 ; long a[NUMBER_OF_ELEMENTS]; memset(a, 0, 10 * 4); // falsch – long wird mit 4 Bytes angenommen, es wird eine magische Anzahl von Elementen verwendet memset(a, 0, NUMBER_OF_ELEMENTS * 4); // falsch – long wird mit 4 Bytes angenommen memset(a, 0, NUMBER_OF_ELEMENTS * sizeof(long)); // nicht ganz korrekt - Duplizierung des Typnamens (wenn sich der Typ ändert, müssen Sie ihn auch hier ändern) memset (a, 0, NUMBER_OF_ELEMENTS * sizeof (a [0])); // richtig, optimal für dynamische Arrays mit einer Größe ungleich Null

memset(a, 0, sizeof(a));

// richtig, optimal für statische Arrays