Algorithmus eines Hashcodes

EinUlmer

Newbie
Registriert
Jan. 2022
Beiträge
7
Hallo zusammen,

ich hoffe ich bin hier bei euch richtig hier mit meiner Frage zu einem Problem bei dem ich allein nicht mehr weiter komme. Ich habe die serielle Datenprotokolle meines Sensors mitgeschnitten, aber leider keine Information wie das Protokoll aufgebaut ist. Ein Teil des Codes habe ich selber herausbekommen, leider aber nicht wie der Hashcode am Protokollende generiert wird. Mein erster Verdacht war Prüfsumme durch einfaches XOR, das hat aber leider nur bei einem kleinem Teil meiner Daten funktioniert.
Leider gibt es ja aber wohl unendlich plus eins Möglichkeiten für so einen Algorithmus. Da ich aber sehr viele Werte habe, habe ich dennoch Hoffnung, vor allem da ich auch gewisse Muster in den Daten sehe.

Hätte hier jemand Lust auf sowas?
Dazu hier mal ein erster Testsatz mit Daten, in der ersten Zeile ergibt sich das letzte Nibble #6 als XOR aus Nibble 1-4. Ich glaube derzeit, dass Nibble5 den Paritätswert für Nibble3 darstellt, das passt auch für ale Werte die ich habe. Aber wie geht es für Nibble6 weiter?

Code:
000C54 0013AA 002C56 0033A8 004C50 0053AE 006C52 0073AC 008C5C 0093A2 00AC5E 00B3A0 00CC58 00D3A6 00EC5A 00F3A4
050C5E 0513A0 052C5D 0533A3 054C58 0553A6 056C5A 0573A4 058C54 0593AA 05AC56 05B3A8 05CC53 05D3AD 05EC50 05F3AE

Gruß,
Dieter
 
lol es ist binär.
und sowas sichtbar zu machen ist laut Hackerparagraf auch nicht erlaubt, mein Kenntnisstand.

Ich würde das immer mit einem Schlüssel-Bart vergleichen, dann ist die Struktur irrelevant.
 
"Binär" ist nicht synonym zu "verschlüsselt".
Solange nicht Kryptographie hinter den Binärdaten steckt, darf man sie natürlich entschlüsseln.

@TE: Was ist das für ein Sensor? Und wo Du gerade schon die Typenbeschreibung rauskramst:
Gib sie in einer Suchmaschine Deiner Wahl ein und lad die Spezifikation/Data Sheets runter und lern eben, wie das Protokoll lautet.
Wie sollen wir denn wissen, wie die Daten zu interpretieren sind?
 
  • Gefällt mir
Reaktionen: Myron, Dalek und rg88
Weshalb soll das nicht erlaubt sein? Wenn dem so wäre, hätte ich für meinen Außenwettersensor die Analyse auch selber machen müssen.
Restart001 schrieb:
Ich würde das immer mit einem Schlüssel-Bart vergleichen, dann ist die Struktur irrelevant.
Erklär mal bitte
Ergänzung ()

Phrasendreher schrieb:
@TE: Was ist das für ein Sensor? Und wo Du gerade schon die Typenbeschreibung rauskramst:
Gib sie in einer Suchmaschine Deiner Wahl ein und lad die Spezifikation/Data Sheets runter und lern eben, wie das Protokoll lautet.
Wie sollen wir denn wissen, wie die Daten zu interpretieren sind?
Erste Regel: immer das Internet abklopfen. Ist schon lange erledigt. Leider ohne Erfolg. Mehrfach. Das kannst du mir glauben. Wenn es so einfach wäre, wäre ich nicht den Weg gegangen und hätte mir mühsam einen Datensatz angelegt und betreibe damit nun reverse engineering.
Wie gesagt, einen Großteil der Interpretation habe ich ja tatsächlich geschafft - das glaube ich zumindest und habe noch noch keinen Wert gesehen, der dagegen spricht. Die Protokolle sind ja zumindest sehr kurz.
Aber der Hash ist ein Gefrickel bei dem mir zwischenzeitlich nun einfach die Ideen ausgegangen sind.
 
Zuletzt bearbeitet:
XOR passt schon. Deiner Nibble Zählweise folge ich nicht so ganz. Was fehlt dir denn noch?
 
EinUlmer schrieb:
Erste Regel: immer das Internet abklopfen. Ist schon lange erledigt. Leider ohne Erfolg. Mehrfach. Das kannst du mir glauben. Wenn es so einfach wäre, wäre ich nicht den Weg gegangen und hätte mir mühsam einen Datensatz angelegt und betreibe damit nun reverse engineering.
Erste Regel im Forum: Sinnvolle Daten mitliefern, spätestens auf Rückfragen, statt mehrer Sätze zu schreiben, die nichts zum Thema beitragen. ;)
 
  • Gefällt mir
Reaktionen: Raijin, Myron und Ranayna
Die ersten 12bit sehen jeweils nach einem Zähler aus. In den verbleibenden 12bit könnten alternierend 2 Werte geliefert werden. Wenn ich raten müsste, würde ich auf Luftdruck und Temperatur tippen. Eine Prüfsumme sehe ich da nicht.
 
kieleich schrieb:
XOR passt schon. Deiner Nibble Zählweise folge ich nicht so ganz. Was fehlt dir denn noch?
Sicher? Ich habe das für die 05... mehrfach probiert, aber im Gegensatz zu 00.. erhalte ich für die einzelnen Werte immer unterschiedliche XORs. Ich sehe da kein Zusammenhang.
Nibblezählweise deshalb, weil es für Bytes nicht gepasst hat.

Nolag schrieb:
Die ersten 12bit sehen jeweils nach einem Zähler aus. In den verbleibenden 12bit könnten alternierend 2 Werte geliefert werden. Wenn ich raten müsste, würde ich auf Luftdruck und Temperatur tippen. Eine Prüfsumme sehe ich da nicht.
Ja, die ersten 12Bit sind identifiziere ich als ID des Sensors. Der hat eine Lern- bzw. Teachfunktion die ich immer wieder angetriggert habe und dann danach dann sortiert hatte, deshalb sieht das wie ein Zähler aus. Die folgenden Bit zählen aber nicht mehr hoch, sondern geben ein Art Sensorzustand zurück. Aber immer alternierend gerade/ungerade, also nur 2 möglichen Werte. Nur das letzte Nibble zeigt wieder Werte 0-F. Deshalb die Vermutung "Hash". Zufällig ist der auch nicht, wenn beim wiederholten Empfang die ersten 12Bit übereinstimmen, dann auch die restlichen.
 
EinUlmer schrieb:

Daß es XOR ist hast du doch selbst geschrieben? Vielleicht reden wir irgend wie aneinander vorbei.

Code:
>>> 0x000C54 ^ 0x0013AA ^ 0x002C56 ^ 0x0033A8
0
>>> 0x004C50 ^ 0x0053AE ^ 0x006C52 ^ 0x0073AC
0
>>> 0x008C5C ^ 0x0093A2 ^ 0x00AC5E ^ 0x00B3A0
0
>>> 0x00CC58 ^ 0x00D3A6 ^ 0x00EC5A ^ 0x00F3A4
0
>>> 0x050C5E ^ 0x0513A0 ^ 0x052C5D ^ 0x0533A3
0
>>> 0x054C58 ^ 0x0553A6 ^ 0x056C5A ^ 0x0573A4
0
>>> 0x058C54 ^ 0x0593AA ^ 0x05AC56 ^ 0x05B3A8
0
>>> 0x05CC53 ^ 0x05D3AD ^ 0x05EC50 ^ 0x05F3AE
0
 
Jetzt verstehe ich was du meinst - das sind aber alles separate Werte die so nicht zusammengehören. Jeder einzelne mit 6 Nibbles.
Aber interessant ist das allemal.

Code:
000C54;0013AA;002C56;0033A8;004C50;0053AE;006C52;0073AC;008C5C;0093A2;00AC5E;00B3A0;00CC58;00D3A6;00EC5A;00F3A4
050C5E;0513A0;052C5D;0533A3;054C58;0553A6;056C5A;0573A4;058C54;0593AA;05AC56;05B3A8;05CC53;05D3AD;05EC50;05F3AE
 
Dachte auch daß du es vielleicht so meinst aber da bin ich aus deiner Beschreibung nicht schlau geworden.
Die Rechnung musst du mir mal zeigen.
 
XOR über Nibbles 1-4 und postuliertem Hash gibt für 00x immer ein Ergebnis "8", unten die ersten der Reihe. Für 05x ist das nicht der Fall, aber auch nicht zufällig.
Für die mit FFx erhalten ich das Ergebnis 8 (x=0..7) bzw F(x=8..F).

Deshalb vermute ich stark, dass es tatsächlich ein Hash ist, XOR mit eingeht, aber noch eine weitere Funktion zur Berechnung verwendet wird.

Code:
FF0C54    FF13AA    FF2C56    FF33A8    FF4C50    FF53AE    FF6C52    FF73AC    FF8C5B    FF93A5    FFAC59    FFB3A7    FFCC5C    FFD3A2    FFEC5F    FFF3A1

Code:
>>> 0x0 ^ 0x0 ^ 0x0 ^ 0xc ^ 0x4
8
>>> 0x0 ^ 0x0 ^ 0x1 ^ 0x3 ^ 0xA
8
>>> 0x0 ^ 0x0 ^ 0x2 ^ 0xc ^ 0x6
8


>>> 0x0 ^ 0x5 ^ 0x0 ^ 0xc ^ 0xE
7
>>> 0x0 ^ 0x5 ^ 0x1 ^ 0x3 ^ 0x0
7
>>> 0x0 ^ 0x5 ^ 0x2 ^ 0xc ^ 0xD
6
>>> 0x0 ^ 0x5 ^ 0x3 ^ 0x3 ^ 0x3
6
 
  • Gefällt mir
Reaktionen: kieleich
Sind das 2 Datenpakete ?
Die Bytes 1,4,7... (von 0 gezählt) sind in beiden Paketen immer identisch. Auch im letzten mit F3. Das spricht gegen CRC/Hash.
 
Zuletzt bearbeitet:
Code:
000C54
ist ein Paket und
Code:
0013AA
auch, und ebenso die anderen. Jedes hat tatsächlich nur 6 Nibbles, wovon der letzte ein Hash / Prüfsumme ist. Schleuse ich ein Paket mit geändertem Nibble ein, wird es nicht erkannt.
 
Ich habe da, leider auch keine Idee mehr zu - das xor war so schön wie kann es sein dass da kein Zusammenhang besteht?

Wenn du den Hash nicht kennst aber auch nur 16 Möglichkeiten dann schick es halt 16 mal ;=) ?
 
Zurück
Oben