Hallo Forum,
ich bin gerade dabei, eine WLAN-Steuerung für meinen Rasenmäh-Roboter zu
entwickeln, der sich standardmäßig nur per Bluetooth und einer App
ansteuern lässt. Da der BT-Empfänger zum Glück seine Daten über eine
serielle Schnittstelle an das Mainboard des Roboters überträgt, konnte
ich mich mit einem seriellen Snifferkabel dazwischen hängen und die
übertragenen Daten mitschneiden.
Bei der Entschlüsselung der einzelnen Datenfelder bin ich auch schon
relativ weit gekommen, jedoch fehlt mir für das Rückspielen die
Berechnungsgrundlage der Prüfsumme. Ein direktes Rückspielen der Befehle
geht nicht, weil immer auch ein Counter für die Zuordnung von Anfrage
und Antwort mitgesendet wird, der dann natürlich auch die Prüfsumme
ändert.
Hier ein kleiner Mitschnitt, bei dem sich jeweils nur ein Byte verändert
hat, aber die Prüfsumme trotzdem sehr stark variiert:
1
02 1c 83 00 00 00 00 00 00 00 00 21 03
2
02 1d 83 00 00 00 00 00 00 00 00 ef 03
3
02 1e 83 00 00 00 00 00 00 00 00 a4 03
4
02 1f 83 00 00 00 00 00 00 00 00 6a 03
5
02 20 83 00 00 00 00 00 00 00 00 c0 03
6
02 21 83 00 00 00 00 00 00 00 00 0e 03
7
02 22 83 00 00 00 00 00 00 00 00 45 03
8
02 23 83 00 00 00 00 00 00 00 00 8b 03
9
10
02 04 83 ff d1 03
11
02 05 83 ff 7a 03
12
02 06 83 ff 9e 03
13
02 07 83 ff 35 03
14
02 08 83 ff 6a 03
15
02 09 83 ff c1 03
16
02 0a 83 ff 25 03
17
02 0c 83 ff f4 03
18
02 0d 83 ff 5f 03
19
02 0e 83 ff bb 03
20
02 0f 83 ff 10 03
21
02 10 83 ff 05 03
22
02 11 83 ff ae 03
23
02 12 83 ff 4a 03
24
02 13 83 ff e1 03
25
02 14 83 ff 9b 03
26
02 15 83 ff 30 03
Kurze Erläuterung der Felder:
1. Byte: Startflag, ist immer 02
2. Byte: Counter, jeweils bei einer Anfrage und Antwort immer gleich
3.-vorletztes Byte: Daten
vorletztes Byte: Prüfsumme, bei gleichen Datenpaketen bleibt diese
gleich, also kein Timecode o.ä. mit integriert
letztes Byte: Endflag, immer 03
Folgendes habe ich schon ausprobiert (jeweils mit und ohne Start-, End-
und Prüfsummenbyte):
- Aufsummieren (inkl. modulo 256)
- XOR
Für CRC8 fehlt mir der Ansatzpunkt, weil Polynomdivision bei mir über 20
Jahre her ist und die diversen Wikipedia-Seiten dazu sind mir leider zu
hoch. Wenn also einer von Euch mir da einen Tipp geben kann oder
vielleicht auf den ersten Blick sieht, welcher Algorhythmus dahinter
steckt, gibt es vielleicht eine Implementation, die ich nutzen kann.
Ansonsten wäre es schade um das Projekt, weil ich ohne
Prüfsummenberechnung nicht weiterkomme...
Danke Euch schon mal im Voraus und viele Grüße
F.
--
mit den [ pre ] [ /pre ] - Tags wirds lesbarer.
-rufus
Guten Morgen,
wenn du bei einem CRC-8 Online Rechner
http://www.sunshine2k.de/coding/javascript/crc/crc_js.html
als Eingabe
0x1C 0x83 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
mit den Parametern CRC8_MAXIM eingibst, dann kommt korrekt 0x21 heraus,
mit 0x1D kommt korrekt 0xEF usw.
Das war ein schönes Rätsel für den Sonntagmorgen :-)
@Bernhard: Respekt! Guter Fund.
Noch nebenbei bemerkt, das 0x02 wirklich das STX (Start of Transmission)
und 0x03 das ETX (End of Transmission) Zeichen in ASCII ist. Die Jungs
haben das recht verständlich programmiert.
...und mir fällt gerade auf, dass der Hinweis von Matthias eine weitere
Frage gleich mit erklärt: Der Counter in Byte 2 wird nämlich zu 1b 22
bzw. 1b 23, wenn es eigentlich eine 0x02 oder 0x03 wäre, werden also
ESCaped (seltsam nur, dass der Wert dann um 0x20 erhöht wird). Das wäre
mir sonst wohl durchgerutscht...
Gruß,
F.
P.S.: Danke für's formatieren, Rufus
Frederik H. schrieb:> (seltsam nur, dass der Wert dann um 0x20 erhöht wird)
0x20 = 32(dez)
Die ASCII-Zeichen 0 bis 31 sind Steuerzeichen.
Bei Zeichen 32 gehts dann erst los (32 ist Space).
Wurde wohl gemacht, um Problemen vorzubeugen.
Ja, das mit den Steuerzeichen sit klar, ich dachte nur, dass dafür dann
ja das ESCapen gemacht wird. Andere Werte unter 0x20 werden ja auch ohne
Transformation übertragen. Ich hätte dann ja gleich 0x30 addiert, damit
man wenigstens die ASCII-Repräsentation von 2 bzw. 3 im Hinterkopf hat
;)...
Eine iOS-App reverse engineeren? Habe ich noch nie gemacht, aber
ich muss ja gar nicht raten - einmal alle Funktionen auf der App
aufgerufen, Daten mitgeschnitten, fertig. Das einzige, wo ich "raten"
musste, war der CRC. Aber dank der Hilfe hier hat sich das ja auch
schnell klären lassen.
Warum gibt es für sowas keinen Onlinerechner?
Mit https://github.com/d-bahr/CRCpp war es kein Problem ein Bruteforce
Programm für CRC zu schreiben.
Fehlen noch alle anderen Checksumalgorithmen..
Frederik H. schrieb:> Der Counter in Byte 2 wird nämlich zu 1b 22> bzw. 1b 23, wenn es eigentlich eine 0x02 oder 0x03 wäre, werden also> ESCaped (seltsam nur, dass der Wert dann um 0x20 erhöht wird).
Und was ist, wenn der Counter 1b wird? Oder die Checksum 03 oder
vielleicht auch sogar 02?
Frederik H. schrieb:> Checksumme 02 bzw. 03 wird auch mit 1b 22/23 ESCaped. Counter 1b wird zu> 1b 3b (seltsam, dass hier dann nicht analog auch 2b genommen wird).
0x1B hat in ASCII die Bedeutung ESCape, also "jetzt kommt ein anderer
Code".
Und dieser ist in dem Fall imm genau ein Zeichen lang und ergibt sich
durch Addition von 0x20. Nur STX/ETX/ESC (0x02/0x03/0x1B) müssen so
behandelt werden. Alles wohlgeordnet. Obwohl, man hätte die Zeichen nach
dem ESC auch einfach unverändert senden können.
Interessant, diese Erhöhung um 0x20 ist also Standard? Aber warum erhöht
man, wenn schon 1b davor steht? Denn alleine würde man z.B. eine 0x22 ja
nicht als escapte 0x02 oder als reguläre 0x22 erkennen können. Aber
zumindest ist die Anwendung hier konsequent, und ich kann immer 0x20
abziehen.
EDIT: Für die Programmierung ist es natürlich einfach(er) zu wissen,
dass eine 0x02 immer Start und 0x03 immer Ende einer Übertragung ist,
ohne schauen zu müssen, ob vorher eine Escape-Sequenz stand. So kann man
erst einmal einfach das Telegramm als Ganzes abgrenzen und dann die
Escape-Sequenzen behandeln...
Frederik H. schrieb:> Interessant, diese Erhöhung um 0x20 ist also Standard? Aber warum erhöht> man, wenn schon 1b davor steht? Denn alleine würde man z.B. eine 0x22 ja> nicht als escapte 0x02 oder als reguläre 0x22 erkennen können. Aber> zumindest ist die Anwendung hier konsequent, und ich kann immer 0x20> abziehen.
Es ist kein "Standard", es ist nur so implementiert.
Es ist aber auch kein Rätsel, warum 0x1B zu 0x3B wird.
Und als Grund dafür klingt plausibel:
> EDIT: Für die Programmierung ist es natürlich einfach(er) zu wissen,> dass eine 0x02 immer Start und 0x03 immer Ende einer Übertragung ist,> ohne schauen zu müssen, ob vorher eine Escape-Sequenz stand. So kann man> erst einmal einfach das Telegramm als Ganzes abgrenzen und dann die> Escape-Sequenzen behandeln...
Bingo!
Nun ist nur noch interessant, ob die Prüfsumme vor oder nach dem ESCapen
der Daten gebildet wird. Vermutlich bevor, denn dann implementiert man
1. Telegramm ist 0x02...0x03
2. ESC folgt tatsächliches Zeichen + 0x20
3. CRC wird über Rohdaten gebildet/geprüft
Da du offenbar Telegramme für alle Möglichen Fälle hast, kannst das ja
einfach nachprüfen.
Ja, die Prüfsumme wird über die Rohdaten (also vor dem ESCapen) gebildet
(auch noch mal ein guter Hinweis für die Implementation meines
Sketches). Auch die Prüfsumme der Rohdaten wird dann entsprechend noch
mal ESCaped, wenn nötig und diese 02, 03 oder 1b enthält.
