Hallo zusammen, ich habe hier ein unbekanntes Protokoll, bei dem mir GPS Daten übermittelt werden. Leider fehlt mir der Algorythmus der beschreibt, wie die Werte kodiert wurden. Vielleicht hat ja jemand eine Idee. Hier mal zwei Datensätze und Inhalte, die übertragen werden: Satz1: 0x01 0xA8 0xD2 0x56 0x36 0x8F 0x66 0x66 0x2A 0xBE 0x25 0x64 0x0C 0xEA 0x3B 0x64 0x81 wird dekodiert zu: Azimuth: 278 Grad Trip: 851 m Date: 02.01.12 Satz2: 0x01 0xA8 0xD2 0x56 0xEA 0x53 0xA6 0xBA 0xF6 0x62 0xF9 0xB8 0xD0 0x36 0xE7 0xB8 0x43 wird dekodiert zu: Azimuth: 278 Grad Trip: 847 m Date: 02.01.12 Die ersten 4 Bytes sind eine Geräte ID, die sich wie folgt berechnet: 01 A8 D2 56 = 001 168 210 86 wird zu 001 + 168*256 : 210 + 86*256 = 43009:22226 ( kann ich so aus der Quelle lesen ) Nach der ID folgen die Daten. Ändere ich ein Bit, wird der gesamte Datensatz ungültig und im original Gerät nicht mehr dargestellt. Ändert sich in den übertragenen Werten ein Bit ( Trip: 851m zu 847m ... Differenz = 4 , das ist in einem Bit darstellbar - war Zufall, dass ich das protokollieren konnte ), ändern sich alle Bytes des Datenpakets. Hat jemand eine Idee, mit welchem Algorythmus die Messwerte in den Daten codiert wurden ?
Einen tollen Betreff haste da ja ausgesucht, und natürlich das ominöse Gerät auch nicht benannt. Es wär' ja auch viel zu einfach als Betreff zu nennen: " GPS Datenformat und Protokoll für Gerät XYZ gesucht "
1. Was ist denn das für ein streng geheimes Gerät, das du da auseinandernimmst? 2. bist du sicher, dass die Daten, die angezeigt werden, die sind die übertragen werden und in der Anzeige nicht noch intelligenz steckt? 3. Dass sich von einer Messung zur anderen alle Zeichen ändern spricht für mich für eine ernstzunehmende Verschlüsselung, da sehe ich mit den Daten die hier sind ziemlich schwarz. Anscheinend ist auch eine Prüfsumme mit drin, sonst würde das ding nicht sofort erkennen, dass die Daten ungültig sind. 4. Dass sich an den Daten genau ein Bit geändert hat, halte ich für eher unwahrscheinlich, denn vermutlich wird nicht das Datum sondern die komplette Zeit übertragen und "trip" (was auch immer das ist) nicht als Integer in Metern gespeichert.
Hallo, Ralf Horstmann schrieb: > Die ersten 4 Bytes sind eine Geräte ID ... Das 5. Byte scheint eine Zufallszahl zu sein ! eine XOR Verknüpfung aller weiteren Bytes eines Datensatzes mit jeweils diesem 5.Byte ergibt eine Bytefolge die für beide Datensätze gleich ist (bis auf den 1Bit Unterschied) Das letzte Byte scheint dann eine Prüfsumme über alle Bytes zu sein (ebenfalls mit XOR-Verknüpfungen zusammengebastelt) Gruss Stefan
Was ist das für eine CPU/µC, die das empfängt? Ich könnte mir gut vorstellen, daß bei den Daten jede Zahl als 16 Bit Integer gespeichert wird (wäre am einfachsten). Also auch das Datum in Tag, Monat und Jahr. Falls es ein spezielles Datumsformat ist, dann müßtest du da genauer nachschauen, wäre nämlich auch denkbar. Falls du die Daten, die übergeben werden, vor der Kodierung bestimmen kannst, dann würde ich mal für die Meter Angabe einmal 2^16-1 und ein anderes mal 2^16 eingeben und dann schauen was passiert und wo sich etwas ändert. Falls es dann zu einem Überlauf kommt, dann sind es auf jedenfall 16 Bit pro Zahl. Im übrigen gibt es nicht nur Verschlüsselungsverfahren, damit ein Datensatz sich komplett ändert. In manchen Fällen genügt schon eine entsprechende Komprimierung, daß sich alles ändert. Hier gibt's mehrere mögliche Komprimierungsverfahren. Das das letzte Byte eine Prüfsumme ist, würde ich auch sagen.
Danke Stefan, das war schon mal ein sehr guter Tipp. Das zieht sich tatsächlich durch die verschiedenen Datensätze. Das nach dem XOR nur ein Bit kippt wenn sich der Wert von 847 auf 851 ändert spricht erstmal dafür, dass der Wert digital und nicht als einzelne Ziffen übertragen wird, dann müssten sich ja zwei Stellen ändern. Jetzt brüte ich darüber, wie die Zahlen kodiert sind. Datensatz mit 851 = 0x03 0x53 Satz1: 0x36 0x8F 0x66 0x66 0x2A 0xBE 0x25 0x64 0x0C 0xEA 0x3B 0x64 0x81 xored: 0xB9 0x50 0x50 0x1C 0x88 0x13 0x52 0x3A 0xDC 0x0D 0x52 0xB7 Datensatz mit 847 = 0x03 0x4F Satz2: 0xEA 0x53 0xA6 0xBA 0xF6 0x62 0xF9 0xB8 0xD0 0x36 0xE7 0xB8 0x43 xored: 0xB9 0x4C 0x50 0x1C 0x88 0x13 0x52 0x3A 0xDC 0x0D 0x52 0xA9 Mir ist aufgefallen, dass die Stelle der Änderung mit dem dekodierten Highbyte des Messwertes XORed das LowByte ergibt, also z.B. 0x50 XOR 0x03 = 0x53 .. oder 0x4C XOR 0x03 = 0x4F .. das kann allerdings auch Zufall sein, ich versuche mal, das an anderen Datenreihen zu prüfen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.