Frage:
Dekodieren Sie Datum und Uhrzeit in einer Folge von Binärdaten
nimiq
2013-05-26 21:20:27 UTC
view on stackexchange narkive permalink

INTRO

Ich versuche, eine Binärdatendatei mit SMS-Nachrichten zurückzuentwickeln.
Die Datei heißt ems.idx4 und wurde mit einer Software namens erstellt LG PhoneManager vor ungefähr 5 Jahren als Backup-Archiv von SMS-Nachrichten für ein LG-Handy.
Ich weiß nicht, in welcher Sprache LG PhoneManager geschrieben wurde, aber in der Binärdatei habe ich Zeichenfolgen wie "CObTree", "CFolder" gelesen "," CMessage ": Vielleicht bedeutet dieser Hinweis nichts, vielleicht deutet er darauf hin, dass Cobol / .net / welche Sprache auch immer verwendet wurde.

PROBLEM

Ich habe die gesamte Struktur der Binärdatei dekodiert, was ziemlich einfach ist.
Der einzige Teil, den ich nicht dekodieren konnte, ist Datum und Uhrzeit einzelner Nachrichten.
Ich habe den Binärteil identifiziert, in dem Datum und Uhrzeit codiert sind und ich habe ein paar dekodierte Beispiele erhalten (dank des Inhalts der Nachricht).
Binärdaten in hex: 

  [0x10] D0 74 C4 FE 3F 42 E3 40 F1 64 [0x7] 2 [0x13] 1 [0x6] 6C [0x2] ist 25.12.2007 einige Zeit nach 23:58 GMT + 1 [0x10] 2B 25 CA 19 2 F 43 E3 40 F1 64 [0x7] 2 [0x13] 1 [0x6] 6C [0x2] ist 2008/01/02 einige Zeit nach 10:48 GMT + 1 [0x10] AA C0 2C 6E 35 43 E3 40 F1 64 [ 0x7] 2 [0x13] 1 [0x6] 6C [0x2] ist 2008/01/02 einige Zeit nach 16:03 GMT + 1 [0x10] EE 04 71 F2 B6 43 E3 40 F1 64 [0x7] 2 [0x13] 1 [0x6] 6C [0x2] ist 2008/01/06 einige Zeit nach 14:31 GMT + 1 [0x10] 60 2C F9 45 4E 4F E3 40 F1 64 [0x7] 2 [0x13] 1 [0x6] 6C [0x2] ist 2008/04/08 einige Zeit nach 10:32 GMT + 1 [0x10] 5D 84 01 14 74 64 E3 40 F1 64 [0x7] 2 [0x13] 1 [0x6] 6C [0x2] ist 2008/11/11 einige Zeit nach 14:53 GMT + 1

wobei [0xN] eine Folge von N Nullen bedeutet.

Irgendeine Idee?

UPDATE

Mit diesem Tool: http://www.digital-detective.co.uk/freetools/decode.asp
Ich habe festgestellt, dass es sich um Windows handelt 64-Bit-OLE-Datums- / Zeitformat.
Laut diesem Tool: 

  D0 74 C4 FE 3F 42 E3 40 bedeutet genau 26/12/2007 00:59

Irgendeine Idee, was die Mathematik hinter diesem Windows 64-Bit-OLE-Datums- / Zeitformat ist?

Zu Ihrer Information, das Präfix "C" wird normalerweise in MFC-Programmen verwendet.
Ich versuche genau das Gleiche mit Samsung PCStudio 3 zu tun. Haben Sie mit dem Format der Datei etwas erreicht, weil es ziemlich ähnlich aussieht?
Zwei antworten:
0xea
2013-05-26 22:17:19 UTC
view on stackexchange narkive permalink

Anscheinend basiert OLE datetime auf doppelten Werten, wobei der gesamte Teil die Anzahl der Tage seit der Epoche und der Bruchteil der Bruchteil des Tages ist. Einige Informationen finden Sie unter Zeitformatkonvertierung leicht gemacht im treffend benannten Abschnitt Die besondere Unangenehmkeit von OLE-Daten.

OLE-Daten ( VT_DATE) hätte großartig sein können: Sie geben Tage seit der Epoche (30. Dezember 1899) an, wobei der Bruchteil den Bruchteil des Tages angibt (z. B. 0,5 für Mittag). Der Gleitkomma ermöglicht den Handel mit Auflösung nahe der Epoche für Langzeitberechnungen.

Negative Werte müssen in ganzzahlige und gebrochene Teile aufgeteilt werden: z. -2,5 bedeutet zwei Tage zurück und einen halben Tag vorwärts von der Epoche (d. H. Das Vorzeichen wird auf den ganzzahligen Teil angewendet, nicht jedoch auf den gebrochenen Teil). Dies macht numerische Fehler besonders problematisch. -2 bedeutet "zwei Tage zurück von der Epoche" und endet am 28. Dezember 1899. -1.9999999 bedeutet, dass Sie einen Tag zurückgehen und fast einen ganzen Tag vorwärts gehen und kurz vor Dezember enden 30, 1899 - fast zwei Tage auseinander.

Die Epoche wurde ausgewählt, um Excel mit einem Fehler in Lotus 1-2-3 kompatibel zu machen, was zu einigen ungenauen Konvertierungen im Januar und Februar 1900 führte. Weitere Informationen finden Sie unter Linkliste unten.

Ich wusste das nicht, danke für ein bisschen Lulz :)

Ja Danke! Ich denke, ich habe meinen Weg gefunden, werde die Lösung veröffentlichen, sobald sie fertig ist. Übrigens sind OLE-Daten so ein Durcheinander!
nimiq
2013-05-27 00:04:39 UTC
view on stackexchange narkive permalink

Ok, ich habe meinen Weg gefunden!
Die ersten 8 Bytes nach [0x10] sind ein OLE-Datum in Little Endian Hex.
Ich habe sie in Python in eine reguläre Datumszeit konvertiert mit: 

  import datetimeimport mathfrom struct import unpackdef ole_date_bin_to_datetime (ole_date_bin): "" Konvertiert ein OLE-Datum von einer binären 8-Byte-Little-Endian-Hex-Form in ein Datum / Uhrzeit-Format : Tage ab Epoche (1899/12/30 00:00) # - Dezimalteil: Prozentsatz des Tages, an dem 0,5 Mittag ist date_float = entpacken ('<d', ole_date_bin) [0] date_decimal, date_integer = math.modf (date_float) date_decimal = abs (date_decimal) date_integer = int (date_integer) #Berechnen Sie das Ergebnis res = datetime.datetime (1899, 12, 30) + datetime.timedelta (Tage = date_integer) # Hinzufügen von Tagen zur Epoche res = res + datetime .timedelta (Sekunden = 86400 * date_decimal) # Hinzufügen eines Prozentsatzes des Tages return resif __name__ == "__main__": print ole_date_bin_to_dateti me ('\ xd0 \ x74 \ xc4 \ xfe \ x3f \ x42 \ xe3 \ x40')
Sind Sie sicher, den Prozentsatz hinzuzufügen? Es sollte für positive Werte in Ordnung sein, aber nicht sicher für negative (angesichts dieser Bemerkung negativer Werte, die ich in meiner Antwort erwähnt habe). In Ihrem Fall müssen Sie sich wahrscheinlich nicht mit SMS-Nachrichten befassen, die älter als 1899 sind: D.
Du liegst absolut richtig. Gerade bearbeitet und hinzugefügt: date_decimal = abs (date_decimal)


ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...