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
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
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/skripte/ikf_skript_duplex_SS06.pdf
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.
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
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 ;)
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
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
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
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?
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
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.
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
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
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.
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.
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.
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ß
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
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...
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?
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.
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 ;-)
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
> 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.
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.
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ß
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?
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?
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?
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
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)?
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.
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...
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.
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!?
(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.
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.
(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
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.
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 :)
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.
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!
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.
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. :-)
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
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.
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
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
@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
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
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
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.
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
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 !
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.
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.
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?
Thread beobachten
Seitenaufteilung abschalten