www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Etwas für die ganz Schlauen.


Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hoffe ich bin hier im richtigen Unterforum und hätte da eine Aufgabe 
für die Codefreaks, an der ich schon seit Wochen verzweifel :)

Es werden über die serielle Schnittstelle zwischen einem Server und 
einer Steuerung Daten übertragen. Abgesichert werden die Daten durch 
eine Checksumme. Bisher habe ich aufsummieren, alle Werte miteinander 
mit XOR behandeln und sonstige abstruse Kombinationen probiert, aber 
keine Lösung gefunden.

Hier ein paar Datensätze:

(02 fd d0 e0 00 00)(05)(7e 52 49 44 3b)70
(02 fd d0 e0 01 00)(00)(7e 53 50 2c 4e 52 3d 38 33 2c 56 41 4c 3d 34 30 
3b) 70
(02 fd d0 e0 01 00)(00)(7e 53 50 2c 4e 52 3d 36 39 2c 56 41 4c 3d 31 39 
3b) 68
(02 fd d0 e0 01 00)(00)(7e 53 50 2c 4e 52 3d 37 36 2c 56 41 4c 3d 31 37 
3b) 68
(02 fd d0 e0 00 00)(0b)(7e 53 50 2c 4e 52 3d 31 37 31 3b) c8

Die Daten bedeuten folgendes:
02 fd d0 e0 00 00 sind Steuerungsdaten, damit die Anlage weiß was sie 
machen soll. Steht eine e0 00 00 da, bedeutet es lesen. Danach kommt die 
Anzahl der Datenbytes und die letzte Zahl ist die Checksumme.
Bei e0 01 00(schreiben) wird die Anzahl der Datenbytes nicht gesetzt.

Ich habe mal die Zahlenreihen mit gleichen Checksummen hier 
reingeschrieben, damit man vielleicht was vergleichen kann.

Hat jemand eine Ahnung, wie diese Checksumme berechnet sein könnte ? Ich 
weiß, es gibt bestimmt zig Möglichkeiten, die sich ein Programmierer 
ausdenken könnte, aber vielleicht sehe ich den Wald vor lauter Bäumen 
nicht und es ist doch ganz einfach.

Im Internet habe ich schon viele Seiten mit Onlinerechnern zu 
Checksummen, CRC's, Hash usw. durchprobiert, aber leider war nichts 
richtiges dabei, daß genau die Werte ergeben hätte.

Viele Grüße

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sabine,

hast Du die Möglichkeit, dass Programm der Steuerung zu analysieren ?

Gruss Otto

Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Otto,

leider nicht. Ich will nicht die Gewährleistung riskieren, falls etwas 
kaputt geht an der Steuerung. Ich weiß, da drin steckt alles was man 
wissen muß und man müßte nur rankommen :)

Gruss Sabine

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was ist es für eine Steuerung ?

Otto

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du noch ein paar mehr Beispiele posten?

Autor: Wirus! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ohne eine nähere Information über das Bus-System wird es schwierig.
Kennst Du den hersteller? meist sind Hersteller einem bestimten 
Bus-System verhaftet oder haben ein eigenes entworfen - die protokolle 
gibt es oft auf Anfrage beim technischen Support.

Schau Dir mal unter 
http://www.ifr.ing.tu-bs.de/lehre/downloads/skript... 
an, was es so alles gibt ... und das ist nur eine kleine Auswahl der 
bekannteren Protokolle.

Die Kapitel 2.5.2-2.5.3.3 gehen allgeimein auf Sicherungsverfahren ein, 
vieleicht ist da was dabei.

Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Otto,

wegen der Steuerung will ich nichts weiter sagen, nicht daß noch der 
Hersteller hier dem Forumsbetreiber Ärger macht, wegen 'Reverse 
Engineering'. Es soll welche geben, die das nicht so mögen.
Beispiele hätte ich noch genügend, aber ich finde, die interessanten 
sind hier schon gepostet, wo die Checksumme z.B. gleich ist, obwohl die 
Daten sehr unterschiedlich sind.

Viele Grüße

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Beispiele hätte ich noch genügend, aber ich finde, die interessanten
> sind hier schon gepostet

Wenn du meinst ... ;-)

Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zu später Stunde,

die Steuerung wurde soviel ich erfahren habe von der Firma Abatec in 
Österreich entwickelt. Vielleicht hilft es was.

@Otto, nicht böse sein, wegen weiteren Beispielen. Ich bin da 
mittlerweile vorsichtig, weil mit der Firma nicht zu spaßen ist. 
Deswegen will ich nicht zuviel im Internet posten und vor allem will ich 
keinem Admin zuviel Arbeit machen, sich mit diesem Laden 
auseinandersetzen zu müssen ;)

Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Wirus,

danke für den Tipp mit dem pdf. Werde ich mal durchlesen, ob da was 
steht.

Soviel ich bisher auch rausgefunden habe ist, daß die keine 
Fehlerkorrektor machen. Stimmt bei einem Befehl die Checksumme nicht zu 
den Daten, kommt einfach nur ein Error.
Das andere was ich noch weiß, daß in der Steuerung von einem MBUS oder 
ModBus die Rede ist. Vielleicht hilft das ja etwas.

Viele Grüße

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://de.wikipedia.org/wiki/Modbus

MBus ist übrigens etwas anderes (für Stromzähler u.ä, in der 
Gebäudeautomation)

Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sebastian,

danke für den Link. Ich glaube aber eher es müßte schon ein M-Bus sein, 
weil eine der Meldungen in der Steuerung heißt zumindest so - MBUS init. 
Aber mal sehen, jetzt weiß ich zumindest in welche Richtung ich schauen 
muß.

Vielleicht hat ja jemand doch Zeit und Muße, ob er die 
Checksummenberechnung rausbekommt :)

Viele Grüße,
Sabine

Autor: Stefan H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich glaube nicht, dass das letzte Byte eine Prüfziffer ist. Das muss 
irgendeine andere Bedeutung haben.
Sollte es aber doch eine Prüfziffer sein, dann ist die Berechung dieser 
Ziffer  extrem laienhaft. Das ist daran zu erkennen, dass in den 
Beispielframes 3 und 4 die Ziffer die Gleiche ist obwohl der 
Datenbereich ja unterschiedlich ist. Gleiches bei den Frames 1 und 2.
Deshalb kann es sich nicht um etwas komplizierteres wie ein CRC oder 
sowas ähnliches handeln.

Gibt es den zu diesem Protokoll keine Doku? Wie sieht denn ein Block als 
Antwort aus, wenn du ein fehlerhaftes Kommando schickst?

Gruß
Stefan

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der MBus, den Wikipedia anbietet scheint es nicht zu sein, der ist viel 
zu schnell und nicht über RS232: http://de.wikipedia.org/wiki/MBus

Der oben genannte ModBus hat eine 16 Bit Prüfsumme, das ist es auch 
nicht, außerdem fangen dort ASCII-Nachrichten mit Doppelpunkt an.

Das hier scheint auch ASCII zu sein: "~SP,NR=171;"

Ist es wirklich keine ganz simple EXOR-Prüfsumme? Über alle Zeichen, 
oder das erste oder letzte weggelassen?

Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke für Eure Hinweise.

Hier meine Kommentare: es handelt sich um eine Heizungssteuerung und das 
ganze läuft (anscheinend) mittels MBUS, zumindest ist im Fehlerlog immer 
wieder die Nachricht 'MBUS reinit'. Wärmemengenzähler usw. lassen sich 
auch extern anschließen UND über die serielle Schnittstelle kann man mit 
dieser Steuerung kommunizieren.
Was ich momentan mache ist einfach alle 255 Werte durchzuprobieren, bis 
die Steuerung Daten zurückschickt, ansonsten kommt immer nur als 
Fehlermeldung 'Checksum Error'.

Viele Grüße
Sabine

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan H. schrieb:
> Sollte es aber doch eine Prüfziffer sein, dann ist die Berechung
> dieser Ziffer  extrem laienhaft. Das ist daran zu erkennen, dass in
> den Beispielframes 3 und 4 die Ziffer die Gleiche ist obwohl der
> Datenbereich ja unterschiedlich ist.

Das kann man so nicht sagen. Es muss sogar immer mehrere
unterschiedliche Datensätze mit der gleichen Prüfsumme geben, da der
Informationsgehalt der aus mehreren Bytes bestehenden Datensatzes
höher als derjenige des Prüfbytes ist. Laienhaft wäre die
Prüfsummenberechnung allenfalls dann, wenn sich das Prüfbyte bei einer
kleinen Änderung des Datensatzes (also eines einzelnen Bits oder
Bytes) nicht ändert, denn genau diese Fehler treten am häufigsten auf
und sollten deswegen durch die Prüfung auf jeden Fall aufgedeckt
werden.

Zum Thema MBus und Modbus:

MBusse bzw. M-Busse scheint es mehrere zu geben. Neben demjenigen von
Sun zur Kommunikation zwischen Hardwaremodulen innerhalb eines
Computers gibt es auch welche, die ein Übertragungsprotokoll über
asynchrone Datenverbindungen definieren. Zu den oben geposteten Daten
scheint aber keines so richtig zu passen.

Dann gibt es eben noch den Modbus der Fa. Modicon für SPSen, die somit
ganz gut zu einer Heizungssteuerung passen würde. Die Kurzbezeichnung
eines frühen Spezifikationsdokuments heißt PI-MBUS-300, was darauf
hindeutet, dass der Modbus intern auch mit MBus abgekürzt wurde, was
wiederum das "MBUS init" erklären könnte. Aber auch dieses Protokoll
entspricht nicht den geposteten Daten, hat aber zumindest entfernte
Ähnlichkeiten im Aufbau der Telegramme.

Möglicherweise hat eines der obigen Protokolle als geistige Stütze bei
der Entwicklung eines neuen Protokolls gedient, und der ursprüngliche
Name blieb in den Köpfen der Entwickler (habe so etwas ähnliches schon
bei einer anderen Firma erlebt). Als Prüsumme verwendet der Modbus
entweder eine 16-Bit-CRC oder eine 8-Bit-LRC, die einfach die
Datenbytes aufsummiert und als zwei Hex-Zeichen dargestellt wird.
Beide passen aber nicht, auch nicht dann, wenn man die LRC als
Binärbyte darstellt und ein oder mehrere Bytes am Anfang oder Ende des
Telegramms bei der Berechnung nicht berücksichtigt. Andere
(M-Bus-)Protokolle verwenden eine XOR-Prüfsumme.

Die XOR-Prüfsumme passt immerhin schon so gut, dass bei allen
geposteten Datensätzen das untere Halbbyte stimmt. Das kann natürlich
Zufall sein, aber immerhin ist die Wahrscheinlichkeit, dass ein von
dem XOR-Verfahren völlig unabhängiges Verfahren diese Eigenschaft hat,
1/2^20, d.h. etwa 1/1000000. Möglicherweise wurde der XOR-Prüfsumme
irgendeine andere Berechnung überlagert, die sich nur auf das obere
Halbbyte auswirkt. Das wäre zwar etwas bizzar, aber vielleicht sollte
der Prüfsummenalgorithmus verschleiert werden, mit der Firma sei ja
"nicht zu spaßen" (Zitat Sabine).

Wie auch immer: Um eine Gesetzmäßigkeit in dem oberen Halbbyte
erkennen zu können, ist zu wenig Information (um genau zu sein 5*4=20
Bits) verfügbar, weswegen ich in meinem ersten Post um weitere
Beispiele gebeten hatte. Interessant wäre natürlich zunächst auch zu
wissen, ob sich die Vermutung mit dem unteren Halbbyte bei anderen
Telegrammen bestätigt.

Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo yalu,

vielen herzlichen Dank für Deine Ausführungen :) Es scheint so, daß Du 
davon viel Ahnung hast bzw. Dich zumindest in die 'Gehirnwindungen' des 
Programmierers reindenken kannst. Find ich echt super.
Ich hoffe nur, diese Firma kommt hier nicht auf ins Forum, aber ich 
poste mal noch ein paar Beispieldatensätze, die ich auf der seriellen 
Leitung empfangen habe.

02 fd d0 e0 00 00 06 7e 4c 49 4e 2c 3b 3d
02 fd d0 e0 00 00 0a 7e 53 50 2c 4e 52 3d 31 33 3b 94
02 fd d0 e0 00 00 0a 7e 53 50 2c 4e 52 3d 36 39 3b 83
02 fd d0 e0 00 00 0a 7e 53 50 2c 4e 52 3d 37 32 3b 9d
02 fd d0 e0 00 00 0a 7e 53 50 2c 4e 52 3d 37 36 3b 91
02 fd d0 e0 00 00 0a 7e 53 50 2c 4e 52 3d 38 33 3b 8f  ´

(Die hier sind auch interessant, weil sich ASCII mäßig nur eine Zahl 
ändert - geht von Nr 171 - Nr 174 und die Checksumme sich auch nicht 
'viel' ändert).
02 fd d0 e0 00 00 0b 7e 53 50 2c 4e 52 3d 31 37 31 3b c8
02 fd d0 e0 00 00 0b 7e 53 50 2c 4e 52 3d 31 37 32 3b cd
02 fd d0 e0 00 00 0b 7e 53 50 2c 4e 52 3d 31 37 33 3b ce
02 fd d0 e0 00 00 0b 7e 53 50 2c 4e 52 3d 31 37 34 3b c7


Viele herzliche Grüße,
Sabine

Autor: Alexander Liebhold (lippi2000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Sabine,

ich glaube ja eher das mit M-Bus der "Meter-Bus" gemeint ist.

Siehe: http://www.m-bus.de/mbus.shtml

Auszug aus Wiki über M-Bus: "Sämtliche Hersteller von M-Bus-Zählern 
bieten den Download der Spezifikationen der M-Bus-Protokolle ihrer 
Zähler an"

Gruß Alexander

Autor: TOM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier steht u.a. folgendes:

http://www.m-bus.com/mbusdoc/md5.html


Short Frame

This format with a fixed length begins with the start character 10h, and 
besides the C and A fields includes the check sum (this is made up from 
the two last mentioned characters), and the stop character 16h.

Long Frame

... After the user data inputs, the check sum is transmitted, which is 
built up over the same area as the length field, and in conclusion the 
stop character 16h is transmitted.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe jetzt noch einmal ein paar Dinge ausprobiert, allerdings
mit wenig Erfolg:

Deine neuen Beispiele widerlegen meine obige Vermutung, dass die
letzten 4 Bits der Prüfsumme die XOR-Verknüpfung aller vorangegangen
Bytes sind.

Da die Prüfsummen in deinen letzten 4 Beispielen sich nicht linear mit
dem einzigen variablen Datenbyte ändern, habe ich untersucht, ob es
nicht doch ein 8-Bit-CRC sein könnte.

Dazu habe ich unter Zuhilfenahme der Algorithmen in pycrc von Thomas
Pircher alle Beispiele mit verschiedenen CRC-Varianten untersucht und
dabei folgende Parameter variiert:

  Polynom:                   0x01 bis 0xff
  Startwert:                 0x00 bis 0xff
  Spiegelung der Datenbytes: aus und an

Eine XOR-Verknüpfung am Ende der CRC-Berechnung wurde jeweils so
angepasst, dass beim ersten untersuchten Beispiel 0x00 als
Gesamtergebnis herauskommt. Bei den richtigen Parametern müssten dann
alle anderen Beispiele ebenfalls 0x00 liefern.

Zusätzlich habe ich noch den Fall untersucht, dass das CRC-Byte nicht
gespiegelt ist obwohl die Datenbytes gespiegelt werden und der
ungekehrte Fall. Dies ist dann zwar keine definitionsgemäße
CRC-Berechnung, der Fall könnte aber einreten, wenn jemand blind einen
Algorithmus aus dem Netz verwendet hat, ohne ihn verstanden zu haben.

Das macht also zusammen 261120 sinnvolle und weniger sinnvolle
CRC-Varianten und bei 14 Beispielen (zwei der insgesamt 15 sind
identisch) 3655680 CRC-Berechnungen.

Leider führte keine der durchgerechneten Varianten zu einem positiven
Ergebnis. Die besten Kandidaten waren:

           Polynom  Startwert  Spiegelung  XOR
             0x69      0x06        nein    0xd8
             0x7b      0xdd        nein    0x9a

Diese Varianten passten jeweils für immerhin 6 der 14 Beispiele,
darunter die 4 letzten, die sich nur in einem Datenbyte unterscheiden.

Da das Ganze also nicht zum Erfolg geführt hat, scheiden für das
Prüsummenverfahren mittlerweile einfache Addition, XOR und CRC
(zumindest die untersuchten Varianten, die eigentlich fast alle
Möglichkeiten abdecken sollten) aus. Entweder wird ein ganz anderes
Verfahren verwendet, oder der CRC-Algorithmus ist fehlerhaft
implementiert. Es wäre aber sehr aufwändig, alle diese Fälle zu
untersuchen.

Vielleicht waren aber auch nur meine Tests fehlerhaft. Ich habe
allerdings, um Fehler weitgehend auszuschließen, den Test auch mit
Datensätzen, die bekanntermaßen CRC-gesichert sind, verifiziert.

Ein paar andere Dinge, die mich jetzt natürlich interessieren würden:

Wozu brauchst du das Ganze überhaupt? Möchtest du die Heizungsteuerung
mit eigenen Komponenten verbinden? Hat der Hersteller etwas dagegen?
Sonst könnte er ja mit dem Protokoll herausrücken. So viel Wertvolles
kann ja nicht drin stecken, zumal die Daten ja sogar im Klartext
übertragen werden.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yalu wrote:

> Wozu brauchst du das Ganze überhaupt? Möchtest du die Heizungsteuerung
> mit eigenen Komponenten verbinden? Hat der Hersteller etwas dagegen?
> Sonst könnte er ja mit dem Protokoll herausrücken. So viel Wertvolles
> kann ja nicht drin stecken, zumal die Daten ja sogar im Klartext
> übertragen werden.

Sucht man etwas im Netz, erfährt man an zig Stellen, dass der Hersteller 
was dagegen hat und das Protokoll nicht herausrückt. "Sabine" und andere 
befassen sich schon einige Zeit mit dem Thema.

Das Wertvolle ist, dass der Hersteller über seinen Server von sehr 
vielen Geräte deren Prozessdaten bekommt und diese dann weiterverwerten 
kann.

Weiterverwertung ist z.B. der Rücktransport aufbereiteter Daten zum 
Anwender zwecks Logging / grafischer Darstellung wie gut/schlecht die 
Anlage arbeitet. Eine solche Möglichkeit ist u.a. ein Verkaufsargument 
für eine Anlage, das die Mitbewerber vielleicht nicht haben.

Weiterverwertungen sind auch z.B. die Fernwartung der Anlage zwecks 
Einstellung besserer Regelkurven oder die Entdeckung und Behebung von 
Fehlern. Hiervon könnte auch das Servicepersonal im Distributionsgebiet 
profitieren.

Es ist für mich sehr nachvollziehbar und seitens des Herstellers höchst 
legitim, diesen Datenbestand und die Kommunikation Server <-> Anlage vor 
wissentlicher oder unwissentlicher Kompromitierung zu schützen.

Es ist für mich auch nachvollziehbar, dass der Hersteller die 
Entwicklungskosten und Betriebskosten dieses Systems decken muss. Es 
scheint so, dass der Paketpreis für die Verbindungslösung ("Modem" + 
Software) einen Teil zur Finanzierung beiträgt.

Das "Modem" ist anscheinend ein marktübliches "Modem" für diese 
Kommunikationstechnik, bei dem der "Modem"-Hersteller in Zusammenarbeit 
mit dem Hersteller eine modifizierte Firmware eingebaut hat. Ich schätze 
die Anpassung besteht darin, dass das Modem ebenfalls die Checksumme 
prüfen kann.

Lange Rede kurzer Sinn:

Die technische Herausforderung "den Code zu knacken" könnte für mich 
interessant sein, überwiegt bei mir aber nicht die Interessen des 
Herstellers.

Oder noch kürzer:

Leben und leben lassen.

Oder noch kürzer:

Be no evil.

Autor: Björn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also die checksumme müsste sich durch das aufsummieren der einzelnen 
Werte ergeben. bei 0xFF (also bei 8-bit-Werten) geschieht bei einem 
plötzlich größerem Wert ein Überlauf.
Und NUR dieser Überlauf ist dann die Checksumme!


Beispiel:

Man hat zwei Werte:    0x7F 0x81      (dez: 127 und 129).

Checksum ergibt sich dann wie folgt:   (0x7F + 0x81) - 0xFF  = 0x01


gruß

Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen herzlichen Dank für Euren wertvollen Input bisher :)

@Stefan: ich glaube Du weißt mittlerweile welcher Hersteller das 
seinkönnte ;) Es stimmt auch, daß eigentlich momentan nur der Hersteller 
von diesen Daten profitiert, indem er die Trenddaten der Anlage 
'abgreift' und für seine Berechnung der Jahrarbeitszahl benutzen kann. 
Der Vorteil für den Kunden ist, daß seine Anlage optimaler konfiguriert 
werden kann. Daß natürlich der Hersteller was dagegen hat, daß jemand 
sein geistiges Eigentum für seine eigenen Zwecke 'mißbraucht' kann ich 
auch nachvollziehen. Allerdings sehe ich es aus Kundensicht - die Anlage 
gehört mir und somit greife ich darauf zu, wie oft und wann ich will. 
Logischerweise verliere ich natürlich u.U. meine Gewährleistung, falls 
er es merkt.

Ich kann momentan sogar damit leben, daß ich alle 255 möglichen Werte 
einfach durchprobiere, weil die Anlage eh nichts dagegen hat, wenn man 
ihr sooft hintereinander einfach den Befehl schickt, bis es endlich 
passt.

Ich wollte das ganze eigentlich nur 'elegant' gelöst haben, indem es 
doch möglich sein muß, auf diese Berechnung zu kommen.
Wenigstens bin ich beruhigt, daß alle hier, die bestimmt schlauer sind 
als ich, auch nicht bisher darauf kommen, wie die berechnet wird - 
puuuhh.

Ich bin mir sicher, daß jemand bestimmt an Hand der bisherigen 
Datensätze noch drauf kommt, wie das berechnet wird :)

Viele Grüße,
Sabine

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst Du noch ein paar Lese-Anfragen generieren, möglichst kurz, so 
wie:

(02 fd d0 e0 00 00)(05)(7e 52 49 44 3b)70

und möglichst nur ein Byte geändert.

Desweiteren wäre der Prozessor interessant: 8 oder 16 Bit, Byteorder...

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es für den Hersteller tatsächlich wichtig, dass niemand in
Eigenregie mit der Steuerung kommuniziert, wundert es mich etwas,
warum er nicht einfach den gesamten Datenstrom verschlüsselt. Selbst
bei einem relativ primitiven Verschlüsselungsverfahren hat der
Interessierte kaum einen Anhaltspunkt, wo er mit der Suche anfangen
soll und wird es deswegen gar nicht erst versuchen.

Ist jedoch nur die Berechnung eines einzelnen Bytes, nämlich der
Prüfsumme, im Verborgenen, ist es doch bei entsprechend großem
Interesse nur eine Frage der Zeit, bis der "Code" geknackt ist. Zumal
man, wenn ich das richtig verstanden habe, zu jedem beliebigen
Datensatz innerhalb kurzer Zeit durch maximal 256 Versuche die
richtige Prüfsumme ermitteln und so gezielt Informationen über das
Verfahren gewinnen kann.

Ok, derzeit hat es wohl noch keiner geknackt, oder zumindest nicht
veröffentlicht. Das liegt aber wohl hauptsächlich daran, dass es zu
wenig Anwender mit entsprechendem Bedarf, den nötigen mathematischen
Grundkenntnissen und genügend Freizeit gibt :)

> Ich kann momentan sogar damit leben, daß ich alle 255 möglichen
> Werte einfach durchprobiere, weil die Anlage eh nichts dagegen hat,
> wenn man ihr sooft hintereinander einfach den Befehl schickt, bis es
> endlich passt.

Was machst du eigentlich, wenn die Steuerung ein internes
Fehlerprotokoll anlegt, in dem zu Diagnosezwecken u.a. auch
Kommunikationsfehler gespeichert werden? Könnte es da nicht passieren,
dass ein Service-Techniker beim Abruf dieses Protokolls etwas größere
Augen bekommt?

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yalu wrote:
> Ist es für den Hersteller tatsächlich wichtig, dass niemand in
> Eigenregie mit der Steuerung kommuniziert, wundert es mich etwas,
> warum er nicht einfach den gesamten Datenstrom verschlüsselt. Selbst
> bei einem relativ primitiven Verschlüsselungsverfahren hat der
> Interessierte kaum einen Anhaltspunkt, wo er mit der Suche anfangen
> soll und wird es deswegen gar nicht erst versuchen.

Eine den Namen werte Verschlüsselung... deren Benefit hat man "damals" 
vielleicht noch nicht Geld wert befunden. Ebensowenig wie man an 
weltweites Datenlogging und Fernwartung über Internet gedacht hat, 
geschweige denn an allzu neugierige Gerätebesitzer ;-) Oder 
nichtherstellergeschulte DIY-Servicetechniker ("Pimp your ...!"), wer 
weiss, was passiert, wenn die Büchse erst mal offen ist?

IMHO wurden auf bestehende Anlagen mit einer vorhandenen lokalen 
Schnittstelle und deren minimaler Absicherung einfach ein 
Ferndatentransfer mit genauso rudimentärer Absicherung aufgepfropft, 
statt in alle zuvernetzten Anlagen ein Kryptomodul einzubauen.

Allerdings um ein Kryptomodul hacksicher einzubauen, ist es ja nicht 
damit getan, etwas zwischen Hauptplatine und serielle Schnittstelle 
einzuschleifen. Sondern es bedeutet Redesign der kompletten 
Steuerplatine. Und ob die 99.9999% der nichthackenen Kunden diese Lösung 
mitfinanziert hätten?

Klar, bei Anfragen wie in diesem Thread oder in den anderen Foren, 
brennt dem Hersteller die damalige Entscheidung wahrscheinlich unter den 
Nägeln.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sabine wrote:
> @Stefan: ...
> Allerdings sehe ich es aus Kundensicht - die Anlage
> gehört mir und somit greife ich darauf zu, wie oft und wann ich will.

Jein.

Damals als du die ersten Prospekte gelesen hast, hast du die 
Möglichkeiten gesehen und darauf hin irgendwann die Anlage gekauft.

Wenn dir jetzt eine neue Nutzung (Selbstauswerten der Daten oder 
Manipulation der Anlage mit eigenen Programmen) überlegt hast, die 
damals nicht zugesichert wurde... dann kannst du nicht darauf bestehen.

> Ich kann momentan sogar damit leben, daß ich alle 255 möglichen Werte
> einfach durchprobiere, weil die Anlage eh nichts dagegen hat, wenn man
> ihr sooft hintereinander einfach den Befehl schickt, bis es endlich
> passt.

Damit kann ich auch leben ;-)

Autor: Stefan H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sabine wrote:
>
> Ich kann momentan sogar damit leben, daß ich alle 255 möglichen Werte
> einfach durchprobiere, weil die Anlage eh nichts dagegen hat, wenn man
> ihr sooft hintereinander einfach den Befehl schickt, bis es endlich
> passt.
>

Da es offensichtlich, dass das untere Nibble der Prüfziffer eine XOR 
Verknüpfung aller vorhergehende Halbbytes ist, kannst du die berechnen 
und dann nur das obere Halbbyte von 0-F durchlaufen. Das spart dann auch 
Kommunikationszeit.

Gruß
Stefan

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Da es offensichtlich, dass das untere Nibble der Prüfziffer eine XOR
> Verknüpfung aller vorhergehende Halbbytes ist,

Das ist bereits durch den zweiten Schwung von Beispielen widerlegt.

Autor: Herbert A. (onlineuser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

versuchst du auch die serielle Verbindung zur WP nachzubauen?

Schau mal hier: Beitrag "one byte checksum"

Komme bei der Checksum-Generierung nicht weiter!

hier noch mal ein paar Beispiele:

~RID;p    02 fd d0 e0 00 00 05 7e 52 49 44 3b 70

(70 ist checksum) (Nutzdaten sind 7e 52 49 44 3b)

~LIN,;=    02 fd d0 e0 00 00 06 7e 4c 49 4e 2c 3b 3d

(3d ist checksum) (Nutzdaten sind 7e 4c 49 4e 2c 3b)

~LOUT;.    02 fd d0 e0 00 00 06 7e 4c 4f 55 54 3b 92

(92 ist checksum) (Nutzdaten sind 7e 4c 4f 55 54 3b)

Liebe Grüsse.

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch einige Pakete :)

02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 31 32 3B 2A    12;*
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 31 31 3B 2F    11;/
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 31 33 3B 29    13;)
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 31 34 3B 20     14; (space)
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 31 35 3B 23     15;#


02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 32 30 3B 29     20;)
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 32 31 3B 2A     21;*

Wird ja endlich mal Zeit, dass dieser "Algorithmus" gecheckt wird! ;) Wo 
sind die Mathematiker bzw. theoretischen Informatiker unter uns?

Viele Grüsse

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manchmal wird das errechnete "checksummen" byte einfach negiert!
Als Algo. simples aufaddieren oder XOR.
Es kann auch sein, dass einige Bytes am Anfang gar nicht in die 
Berechnung eingehen, da eh immer gleich!

Hat das schon jemand durchgerechnet? Habe gerade keine Zeit dafür.

Gruß

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es eine richtige Check"summe" (Checkdividend) ist dann ist es 
wahrscheinlich ein CRC-Algorithmus.

http://de.wikipedia.org/wiki/Zyklische_Redundanzpr%C3%BCfung

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, vermute auch, dass es was mit CRC zu tun hat, weil die "einfacheren" 
Methoden ja nicht gegriffen haben. Aber die Firma, die die Software 
seinerzeit programmiert hat, ist recht klein und daher werden die wohl 
einen Standard-Algorithmus verwendet haben!?

Für einen Mathematiker sollte diese Berechnung doch kein Problem sein, 
oder?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das Problem ist nur dass man auch bei CRC das Generatorpolynom 
aendern kann und dennoch nicht den Standard verletzt, von der Groesse 
abgesehen. Ich halte so ein reverse engineering eigentlich fuer relativ 
sinnlos, da man von einzelnen Samples nie auf das gesamte Protokoll 
schliessen kann. Was ist eigentlich der Hintergrund?

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, wir wollen mit der Maschine kommunizieren und meine Absicht ist 
es, die Daten, die aus der Maschine kommen (Temperaturwerte usw) lokal 
im Netz zu speichern und nicht dem Hersteller zur Verfügung zu stellen. 
Und da muss ich dann auf die diversen Anfragen gültige Prüfsummen 
generieren können.

Gibts kein CRC Reverse Tool, das einfach alle möglichen Fälle 
durchprobiert?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuche es hiermit:

http://www.cs.waikato.ac.nz/~312/crc.txt

CRC rechnet ueber einem endlichen Koerper der Charakteristik 2. Im 
Prinzip wird eine Polynomdivision (modulo) durchgefuehrt mit einem 
Divisor (dem Generatorpolynom), was man festgelegt hat. Der entstehende 
Rest ist Deine Pruef"summe". Der zu pruefende Wert ist natuerlich der 
Dividend. Die Koeffizienten des Polynoms entsprechen den Bitwerten des 
Pruefwerts, somit laesst sich das Ergebnis wieder bequem als Bitvektor 
darstellen.

Es gibt ein paar "uebliche" Generatorpolynome, das kann man im RFC usw. 
nachlesen. Damit wuerde ich beginnen. Es gibt keinen grossen Grund, 
davon abzuweichen, da die ja nicht ohne Grund gewaehlt wurden.

Michael

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin bisher immer davon ausgegangen, dass die "Checksumme" von den 
Nutzdaten berechnet wird. Meint ihr, dass das so ist oder dass auch 
andere Bytes mit einfließen (wie z.B.: Anzahl der Nutzbytes)?

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Meint ihr, dass das so ist oder dass auch andere Bytes mit einfließen (wie > 
z.B.: Anzahl der Nutzbytes)?

Wie der Programmierer gerade lustig war.

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, aber mal anders. Die originale Software wurde in Visual C 
geschrieben, welche fertigen Methoden zur Checksummengenerierung gibt es 
dort?

Hinweis: Bei längeren Anfragen kommen auch wirklich alle 256 ASCII 
Zeichen als Checksumme vor.


hier noch einige Beispiele:

(               ) () (                     ) ()

02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 30 3B 2F    00;/
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 31 31 3B 2F    11;/
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 5C 5C 3B 2F    \\;/
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 31 3B 2C    01;,
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 32 3B 29    02;)
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 31 33 3B 29    13;)
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 32 30 3B 29     20;)
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 33 3B 2A    03;*
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 31 32 3B 2A    12;*
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 32 31 3B 2A     21;*
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 34 3B 23    04;#
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 31 35 3B 23     15;#
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 35 3B 20    05; (space)
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 31 34 3B 20     14; (space)
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 32 37 3B 20    27; (space)
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 36 3B 25    06;%
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 37 3B 26    07;&
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 38 3B 37    08;7
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 39 3B 34    09;4
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 39 30 3B 34    90;4
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 31 38 3B 34    18;4

02 FD D0 E0 00 00 0E 7E 4C 49 4E 2C 30 30 30 30 39 39 39 39 3B 25 
00009999;%
02 FD D0 E0 00 00 0E 7E 4C 49 4E 2C 61 61 61 61 7A 7A 7A 7A 3B 25 
aaaazzzz;%
02 FD D0 E0 00 00 0C 7E 4C 49 4E 2C 61 61 61 7A 7A 7A 3B 0E 
aaazzz;.
02 FD D0 E0 00 00 0C 7E 4C 49 4E 2C 7A 7A 7A 61 61 61 3B 0E 
zzzaaa;.
02 FD D0 E0 00 00 0C 7E 4C 49 4E 2C 7A 7A 61 61 61 61 3B 23 
zzaaaa;#
02 FD D0 E0 00 00 0C 7E 4C 49 4E 2C 61 61 61 61 7A 7A 3B 23 
aaaazz;#
02 FD D0 E0 00 00 0C 7E 4C 49 4E 2C 7A 7A 7A 7A 61 61 3B 23 
zzzzaa;#

Das muss ja zu schaffen sein, oder? :-(

Autor: Herbert A. (onlineuser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi alle miteinander,

wow! Da sind ja schon sehr viele Musterbefehle mit den dazupassenden 
Checksummen. Ich blicke da leider immer noch nicht so ganz durch.

Für einen Mathe-Freak ist das sicher keine große Sache!

Hab heute die Hamming Prüfsumme mal genauer studiert, aber diese 
scheidet als Kandidat auch eher aus.

Liebe Grüsse.

Autor: Herbert A. (onlineuser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achja etwas ist mir noch aufgefallen. Einige Anfragen können sehr lange 
sein, deshalb muss irgendetwas mit MOD drinnen sein!?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noch_ein_neuer Gast wrote:

> Hinweis: Bei längeren Anfragen kommen auch wirklich alle 256 ASCII
> Zeichen als Checksumme vor.

Das will heissen Du vermutest, dass das letzte Byte der Pruefwert ist?

> hier noch einige Beispiele:
>
> (               ) () (                     ) ()
>
> 02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 30 3B 2F    00;/
> 02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 31 3B 2C    01;,
> 02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 32 3B 29    02;)

Dann kann ich Dir zumindest sagen dass es auf keinen Fall CRC ist. Was 
man hier beobachten kann ist ein kleiner Hamming-Abstand zwschen den 
drei Bitvektoren und einen ebenfalls kleinen in der Pruefsumme -> das 
ist ein extrem schlechter Pruefcode und somit auf keinen Fall CRC. Es 
ist also ein primitives Verfahren. Hier kannst Du weiter machen.

Was soll das ueberhaupt fuer eine Codierung sein bittesehr? Welche Basis 
wird hier angenommen? Ueblicherweise macht man sowas hexadezimal...

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 36 3B 25    06;%
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 37 3B 26    07;&

Hier: Hamming-Abstand 2 in den beiden Datenvektoren (wie auch immer die 
jetzt codiert sind), Abstand 1 im Pruefwert. Da draengt sich der 
Verdacht auf, dass hier tatsaechlich nur ueber einen Restklassenring 
aufsummiert wurde. Wenn man jetzt noch die Codierung wuesste, koennte 
man noch raten, um welchen Restklassenring es sich hier handelt.

02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 36 3B 25    06;%
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 37 3B 26    07;&
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 38 3B 37    08;7
02 FD D0 E0 00 00 08 7E 4C 49 4E 2C 30 39 3B 34    09;4

Vermutung: Das letzte Tupel wird nicht in die Pruefsumme mit einbezogen.

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, das "01;," usw soll nur bedeuten, dass der ASCII Input "01" war. 
Also die Nutzdaten lauteten: "~LIN,01;" usw. Und die Checksumme 
entspricht dann einem ",". War nur für die Dokumentation :)

CRC schließe ich mittlerweile auch eher aus. Also "Hamming" ist ein 
guter Ansatz!?

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also das 3B wird nicht mit einbezogen?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst Du Dich mal klar ausdruecken? Wie sind diese Daten codiert und 
wie baut sich der Datensatz auf.

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(02 FD D0 E0 00 00) (08) (7E 4C 49 4E 2C 30 36 3B) (25)

so, die erste () beinhaltet Steuerzeichen, die zweite () die Länge der 
Nutzdaten (eigentlicher Befehl), die dritte () dann die Nutzdaten und 
das letzte Byte ist diese Art Checksum.

Codiert sind sie garnicht. Gehen unverschlüsselt über die Leitung.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK ich geb's auf... ciao.

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was genau wolltest du denn wissen?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ich wissen wollte steht oben:

Kannst Du Dich mal klar ausdruecken? Wie sind diese Daten codiert und
wie baut sich der Datensatz auf.

Und dass die Codierung eines Datums mit kryptographischer 
Verschluesselung garnichts zu tun hat hast ja offenbar schon selber 
festgestellt. Wenn Du hier schon so nen Zeug postest dann geb zumindest 
die noetigen Informationen, wenn andere schon ihre Zeit damit 
verschwenden. Oder lass es bleiben und geh spielen.

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(02 FD D0 E0 00 00) (08) (7E 4C 49 4E 2C 30 36 3B) (25)

Codiert natürlich hexadezimal. Die Nutzdaten besagen folgenden Befehl:

das hexadezimale auf dezimal umgerechnet ergibt die ASCII Codes der 
Befehle (ist es das, was du wissen wolltest)?

~LIN,06;       dieser Befehl verlangt vom Client dann ein Kennwort

Autor: Wolfgang Mües (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#include <stdio.h>

unsigned char crc;

void crcbyte(unsigned char x)
{
  int i;
  for (i = 0; i < 8; i++) {
    if (x & 0x01)
      crc ^= 0x03;
    if (crc & 0x01)
      crc = (crc >> 1) | 0x80;
    else
      crc = crc >> 1;
    x >>= 1;
  }
}

void crcstring(unsigned char *p, int len)
{
  crc = 0x01;
  for (;len;len--)
    crcbyte(*p++);
}

unsigned char test [] = 
{ 0x02, 0xFD, 0xD0, 0xE0, 0x00, 0x00, 0x0E, 0x7E, 
  0x4C, 0x49, 0x4E, 0x2C, 0x30, 0x30, 0x30, 0x30,
  0x39, 0x39, 0x39, 0x39, 0x3B
};

int main(void)
{
  crcstring(test, sizeof(test));
  printf("CRC = %02X\n", (int) crc); 
  return 0;
}

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ist das der Algorithmus?

Autor: Wolfgang Mües (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Denke ich doch. War ziemlich einfach.

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cool, funzt echt! habs grad mit 2 Eingaben probiert! Wie bist du da 
drauf gekommen? Bist ein Genie!

Autor: Wolfgang Mües (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zuerst habe ich mir zwei Meldungen herausgesucht, die nur um ein 
einziges bit differieren, und geschaut, wie sich die CRC ändert. Dadurch 
wusste ich, das es ein XOR mit 0x03 war.

Wenn man sich verschiedene Beispiele raussucht, bei denen das bit an 
anderen bitpositionen ist, dann sieht man, dass die CRC rotiert.

Dann habe ich gesehen, dass die Byteposition völlig irrelevant ist, d.h. 
0x30 0x31 erzeugt dieselbe Summe wie 0x31 0x30. Daraus kann man 
schließen, dass die CRC mit einem 8bit wort gebildet wird.

Dann fehlt nur noch der Startwert. Den bekommt man raus, wenn man in 
einer Schleife alle 256 Möglichkeiten ausprobiert.

Fertig.

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du bist echt genial! RESPEKT!!!

Autor: Johannes Slotta (johanness)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
argl Höchstens eine Stunde und ich hätte es auch raus gehabt (hatte 
bisher erst ein Bit untersucht, daher noch nicht die Rotation, wollte 
mich gerade dem zweiten Bit zuwenden)...

Aber der schnellere hat gewonnen, herzlichen Glückwunsch :)

Autor: Wolfgang Mües (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die CRC-Berechnung geht noch einfacher...
void crcbyte(unsigned char x)
{
  // crc mit dem byte XORen
  crc ^= x;
  // byte 1 bit nach links rotieren
  if (x & 0x80)
    x = (x << 1) | 1;
  else
    x = x << 1;
  // crc nochmal mit dem rotierten byte XORen
  crc ^= x;
}

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK dann war's doch nen CRC. Mit nem schlechten Generatorpolynom, so 
schlecht dass im Prinzip der ganze Algorithmus unsinnig is. Aber naja 
dann is das ja geloest hier.

Autor: Herbert A. (onlineuser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

dachte mir grad, ich schau noch mal vorm Schlafen-Gehen hier rein und 
siehe da, es ist gelöst! Werde morgen dann mal an meinem Programm 
weiterarbeiten! :)

Wolfgang, du bist echt gut!!! Wohin soll ich den Kasten Bier schicken? 
:)

Bin mit der C-Syntax (Pointer) nicht so vertraut, aber denke, dass ich 
mir daraus ein Blockdiagramm und einen Java-Code basteln kann. :)

Gute Nacht!

Autor: Johannes Slotta (johanness)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C:
void crcstring(unsigned char *p, int len)
{
  crc = 0x01;
  for (;len;len--)
    crcbyte(*p++);
}

Java:
void crcstring(String p) {
    crc = 1;
    for (int i=0;i<p.length();i++)
        crcbyte(p.charAt(i));
}

Der Rest ist weitgehend identisch und enthält kein Pointergefrickel.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Werde morgen dann mal an meinem Programm weiterarbeiten! :)

Mach es OpenSource.

Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

komme mit dem unsigned-char nicht zurecht. Das gibt es ja nur in C!?

Herbert, könntest du bitte dein Java Fragment posten!?

Viele Grüße

Autor: *.* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
byte

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

noch ein kleines Problem:

Die Checksumme bei lesenden Anforderungen passt mit dem Algorithmus, 
jedoch die schreibenden Anforderungen werden anscheinend anders 
berechnet!?

Muster von Sabine:
(02 fd d0 e0 01 00)(00)(7e 53 50 2c 4e 52 3d 38 33 2c 56 41 4c 3d 34 30 
3b) 70
(02 fd d0 e0 01 00)(00)(7e 53 50 2c 4e 52 3d 36 39 2c 56 41 4c 3d 31 39 
3b) 68
(02 fd d0 e0 01 00)(00)(7e 53 50 2c 4e 52 3d 37 36 2c 56 41 4c 3d 31 37 
3b) 68

Komisch ist hier auch, dass die Länge der Nutzdaten nicht angegeben 
werden (7. Bytepaar).

Werde noch mal ein paar schreibende Befehle sniffen, jedoch auf den 
ersten Blick steckt hier ein anderer Algorithmus dahinter!?

Liebe Grüsse.

Autor: Martin Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerne wird an Stelle der CRC_Prüfbytes 0x00 angenommen und auch mit 
eingerechnet - hast du das mal geprüft?

Ahoi, Martin

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nein noch nicht,

bin grad am Sniffen schreibender Anfragen, weil vielleicht haben die 
Muster von Sabine nicht gestimmt (wovon ich aber nicht ausgehe).

Werde das dann gleich mal prüfen. :-)

Autor: Wolfgang Mües (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, wenn ich mir die von Dir geposteten 3 Pakete ansehe, dann
unterscheidet sich die CRC nicht wesentlich von der anderen.

Du berechnest einfach die CRC so wie vorher, und dann machst Du noch ein
crc ^= 0x30;

dahinter.

Autor: Daniel der Drüsendieb (druesendieb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine einfache Möglichkeit, eine simple XOR-Prüfsumme zu verschleiern, 
wäre nachträglich die Bits zu verwürfeln.

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du meinst so?
void crcbyte(unsigned char x)
{
  crc ^= x;
  if (x & 0x80)
    x = (x << 1) | 1;
  else
    x = x << 1;
  crc ^= x;
  crc ^= 0x30;
}

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ah, nur zum Schluss vor der Ausgabe noch ein XOR mit 0x30!?

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thx! Funzt einwandfrei! :-)

Aber schon komisch, dass bei schreibenden Befehlen keine Nutzdatenlänge 
angegeben wird. Das verhindert ja eine zusätzliche Kontrolle darüber, 
wann ein Befehl zu Ende ist oder nicht. Da liest er dann wirklich 
solange bis ein Strichpunkt kommt und danach noch die Checksum. Ist 
nicht gerade gut implementiert! ;)

Noch etwas: Es gibt Befehle, die länger als 255 Zeichen sind 
(Nutzdatenlänge geht aber nur bis 0xFF)!? Ob da dann die CRC-berechnung 
auch noch so arbeitet, wie sie soll!? Werde ich mal testen.

Autor: wpnutzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe Genies :)

Als Threadersteller hätte ich ja nie gedacht, daß da noch jemand drauf 
kommt. Die Firma, die die Firmware für die Wärmepumpe implementiert hat, 
ist auch wirklich nicht grad die hellste.
Kleines Beispiel:
angefangen habe ich mit Firmware 1.32W nach ca. einen 3/4 Jahr war ich 
dann bei 2.04K, mittlerweile kenne ich jemand, der die 2.06B hat.
Von Firmware zu Firmware werden auch noch die Positionen, an denen 
Parameter gespeichert werden entweder
a) anderweitig verwendet oder
b) sind gar nicht mehr vorhanden

Die Software, die die Handwerksbetriebe haben, möchte ich mal sehen. Die 
müssen immer auf dem aktuellen Stand sein, um mit der Firmware 
kompatibel zu sein bzw. die überhaupt korrekt auslesen zu können.
Wer sowas programmiert, gehört meiner Meinung nach eh erschossen oder es 
ist einfach Absicht, damit die Betriebe immer die aktuellste Software 
umsonst oder per Update kaufen/haben müssen. Have fun :)

Zu den Gästen hier:

Hat jemand zufällig die Befehle, wie man die Zeitprogramme auslesen kann 
bzw. welche Kommandos das sind ? Ich mein dabei Wochentag sowieso hat 
von 7:00 bis 8:00 Aufheizen, danach Normal-Betrieb, dann Absenken, alles 
was man über das Display so einstellen kann. Weiß sicher jeder um welche 
WP es sich handelt ;)

Darüber würde ich mich sehr freuen, weil mir das in meinem Programm noch 
abgeht. Auslesen kann ich bisher (fast) alles, schreiben auch und jetzt 
mit der Pseudo-Checksum Routine ist alles perfekt.

Vielen Dank für eine Antwort

Autor: Herbert A. (onlineuser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi wpnutzer,

~PRL; antwortet mit Summe der Zeitprogramme
~PRD0; WW Zeiten
~PRD1; Zirke Zeiten
~PRD2; Heiz Zeiten

Bist du der wpnutzer aus dem HT-Forum!? Wenn ja, kontaktiere mich mal 
per Mail (ist bei meinem Profil hier hinterlegt). Hätte da auch einige 
Fragen an dich. Aber besser, wir diskutieren nicht hier darüber! Wer 
weiss, wer da nicht alles mitliest.

Nächtliche Grüsse, Herbert

Autor: MaXXX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael G. :
Wieso ist es den unsinnig? Wetten dass es einen sinn hat. Es werden 
nähmlich  die fehler, die bei der übertragung entstanden, gefunden. CRC 
verfahren ist ja auch nicht für verschlüsselung gedacht.

MFG MaXXX

Autor: Hugo Balder (wpnutzer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle,

die CHK beim schreiben(!) bzw. senden der Daten funktioniert bei mir 
leider nicht ganz so wie hier beschrieben, also mit dem xor 0x30 am 
Ende.
---------------
Du meinst so?

void crcbyte(unsigned char x)
{
  crc ^= x;
  if (x & 0x80)
    x = (x << 1) | 1;
  else
    x = x << 1;
  crc ^= x;
}
crc ^= 0x30;
-------------

Bei den Schreibbefehlen mit einer 02 fd d0 e0 01 vorne
(02 fd d0 e0 01 00)(00)(7e 53 50 2c ...
geht es mit 0x30
Um bei mir allerdings einen anderen Wert zu ändern, muß vorne eine 02 
stehen, sprich:
(02 fd d0 e0 02 00)(00)(7e 53 50 2c ...
Da muß ich dann xor 0x33 machen, damit die Steuerung den Befehl als 
gültig akzeptiert.

Was mache ich denn verkehrt bei der CHK Berechnung beim Schreiben ???

Die Berechnung erfolgt doch über den ganzen Befehl, oder ?

Viele Grüße
wpnutzer

Autor: noch_ein_neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

also bei mir funzt es.

Algorithmus genau gleich ausführen und nur zum Schluss dann (also Vor 
der Ausgabe des CRC noch mal mit 0x30 XORen. Habs mit einigen 
schreibenden Befehlen probiert! Funzt!

Viele Grüsse

Autor: Wolfgang Mües (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das XOR 30H wird natürlich nicht für jedes einzelne Byte gemacht, 
sondern nur einmal am Ende der Berechnung.

Ob das so richtig ist? Und ob die Prüfsumme wirklich so berechnet wird?

Keine Ahnung! Der Algorithmus ist das Ergebnis einer Analyse der zur 
Verfügung gestellten Daten. Er kann nicht besser sein als diese Daten.

Ob das erste Byte z.B. in die Prüfsumme eingeht, kann man erst 
beantworten, wenn man einige Pakete hat, die sich nur im ersten Byte 
unterscheiden...

Wir können den Algorithmus nur so genau nachbauen, wie wir ihn anhand 
der Daten identifizieren können.

Autor: Herbert A. (onlineuser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also bei mir funzt das mit xor 0x30 ganz zum Schluß! Allerdings gibts 
bei meinem Protokoll nur 00 für lesende und 01 für schreibende Befehle! 
Vielleicht ist das bei deiner FW anders!?

@wpnutzer: du hast Post! :)

Viele Grüsse

Autor: Hannes C. (hannesc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute ! Ich weiss der letzte Beitrag ist schon länger her, aber 
wenn Ihr noch da seid (Herbert A., wpnutzer) würde mich eure SW 
interessieren, habe auch was zum tauschen !

Autor: Herbert A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab heute wieder mal reingeschaut. :-)

Bin auch dafür, daß wir uns untereinander austauschen. Ich arbeite zur 
Zeit gerade an einem Logserver, der die Trenddaten automatisch ausliest 
(wenn der Speicher des Reglers voll ist, probiert dieser die Daten an 
die Server IP zu schicken) und in eine Datenbank schreibt bzw. dieselben 
XML-Files generiert, wie die originale Software.

Wir sollten uns eine permanente Kontaktmöglichkeit überlegen!

ICQ, Skype oder IRC.

Autor: 4jahreSpäter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meinen vollen Respekt,
oh Mann, 4 Jahre später ist nun dieses Thema für mich interessant. Und 
ja, vielen Dank. Echt der Hammer, wie ihr auf diesen CRC-Check gekommen 
seid. Hab ihn grad in einem Test laufen und .... WOOOOOW!!!
Unglaublich. Auch von mir DANKE.

Autor: prüfer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt mal euer Checksummen-Programm überprüft und bin auch 
erstaunt wie ihr da dahintergekommen seid.

Ich habe jedoch festgestellt, dass es noch immer einen Haken an der 
sache gibt: Die Checksumme stimmt bei den hereinkommenden 
Wärmepumpen-Datensätzen meistens, aber nicht immer. Es ist immer wieder 
eine Differenz von +1 oder -1 zwischen den berechneten und den 
empfangenen Datensätzen zu beobachten.

Kann sich dazu vielleicht einer von den "ganz schlauen" einen Reim 
machen woher das kommt?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.