CRC / Prüfsumme knacken

[Ingo F. (ingof)]

Hallo,

ich habe mir für viel Geld einen SMI-Controller und die dazugehöhrigen 
Schaltaktoren gekauft.

Die Einheit hat 600 Euro gekostet. Scheint aber für den Hersteller wohl 
zuwenig zu sein. Support gibt es jedenfalls keinen. Versuche schon seit 
zwei Jahren das Sommerzeitproblem zu lösen. Statt nur zu sagen Jetzt ist 
Sommerzeit muss ich auch noch alle Schaltzeiten und die Uhrzeit ändern.

Es heisst immer dass ich bald eine Antwort bekomme.. Aber nach 
mehrfachen Nachfragen sollte es doch nach etwa 1,5 Jahren doch zumindest 
irgendeine Antwort geben!

Da ich also kein Support bekomme will ich das Teil entsorgen und nur 
noch die Schaltaktoren verwenden. Alternativee wäre alle Rollokästen 
wieder zu öffnen und eigene Aktoren zu basteln. Das gäb aber zuviel 
Sauerrei. AUßerdem sind die Kästen beim renovieren noch mal überstrichen 
worden und wollte jetzt nicht schon wieder von vorne anfangen.

Nur scheint es an der Prüfsumme zu scheitern.
Ich vermute eine eine CRC16 komme aber auf keinen grünen Zweig.

Im internet habe ich einen Test gefunden der bei mir nicht so ganz 
funktioniert:
http://code.google.com/p/intelligent-level-editor/wiki/CRCReverseEngineering

Mein Check an drei aufgeschnappten Telegramme funktionierte nicht.
Habe mal den Versuch in der PDF angehangen.

Unter "Punkt 3. CRC?" der Test funktioniert nicht Wenn es ja keine 
"echte" CRC wäre müssten doch zumindest die XOR-Test der Daten gleich 
positiv sein. Vermute dass ich dort irgendwas falsch verstanden habe.

Kann mir irgendjemand eine Tipp geben was da falsch läuft?

Oder wie bekomme ich raus ob es eine CRC ist oder nicht?

[Wegstaben V. (wegstabenverbuchsler)]

um welchen Hersteller bzw. um welches Produkt handelt es sich denn?

[Ingo F. (ingof)]

Wegstaben Verbuchsler schrieb:
> um welchen Hersteller bzw. um welches Produkt handelt es sich
> denn?

Keine Ahnung ob ich den Hersteller nennen darf. Außerdem ist dieser 
SMI-Controller für mich zu unflexible. Und auf die Dauer muss das "Ding" 
sowieso raus.

Ist mir nur unvertändlich warum ich einfach keinen Support bekomme.

[Tüftleer (Gast)]

Ingo F. schrieb:
> Wegstaben Verbuchsler schrieb:
>> um welchen Hersteller bzw. um welches Produkt handelt es sich
>> denn?
>
> Keine Ahnung ob ich den Hersteller nennen darf. Außerdem ist dieser
> SMI-Controller für mich zu unflexible. Und auf die Dauer muss das "Ding"
> sowieso raus.
>
> Ist mir nur unvertändlich warum ich einfach keinen Support bekomme.

Doch, darfst du!

Ohne den Hersteller und den Typ des Moduls kann dir keiner helfen!
Dein Problem haben mehrere und ich vermute es gibt ne lösung!

[Wegstaben V. (wegstabenverbuchsler)]

Ingo F. schrieb:
> Keine Ahnung ob ich den Hersteller nennen darf.

Wer sollte das dir verweigern, und aus welchem vermuteten Grund?

> Außerdem ist dieser SMI-Controller für mich zu unflexible.

weil er nicht gescheit Sommerzeit berücksichtigt?

> Und auf die Dauer muss das "Ding" sowieso raus.

weil er nicht gescheit Sommerzeit berücksichtigt?

> Ist mir nur unvertändlich warum ich einfach keinen Support bekomme.

vielleicht kannst du dein Problem nicht geeignet adressieren beim 
Hersteller ....



wg. deinem CRC-Problem: Ich dachte, die Komponenten sind untereinander 
kompatibel ... gibt es denn keine technische Spezifikation des 
Protokolls, an dem sich alle Herstelelr halten (müssen)?

[Ingo F. (ingof)]

Wegstaben Verbuchsler schrieb:
>> Außerdem ist dieser SMI-Controller für mich zu unflexible.
> weil er nicht gescheit Sommerzeit berücksichtigt?
>
>> Und auf die Dauer muss das "Ding" sowieso raus.
> weil er nicht gescheit Sommerzeit berücksichtigt?

Bei der SMI-Control Unit kann man nur eine Sperrzeit für das öffnen und 
schließen der Rolladen angeben.

Außerdem habe ich die Idee meinen Rolladen den Sonnenstand zu folgen.
Wenn also die Sonne von Norden scheint. Warum sollen dann die Rolladen 
im Süden auf verdunnkeln.

Ganz nett wäre es auch einige bestimmte Rolladen erst mal leicht zu 
öffnen und dann alle paar Minuten etwas weiter zu öffnen. Also nicht von 
komplett dunkel auf Tag hell innerhalb von wenigen Sekunden.

Andere Spielereien wie z.B. Beim offnen eines Fensters auf Kipp geht das 
Rollo soweit los dass die Schlitze nur zu sehen sind. Wenn man es ganz 
aufmacht soll es ganz losgehen. Ohne noch erst zum Schalter zu gehen.

Das ganze Geraffel mit Fenster öffnen ist kein Problem und die Hardware 
wurde auch schon eingebaut.

Wegstaben Verbuchsler schrieb:
> vielleicht kannst du dein Problem nicht geeignet adressieren beim
> Hersteller ....

Wie meinst Du das?

Ich habe bei der Technikabteilung angerufen habe mein Problem 
geschildert. Denke das war auch verständlich für den Ansprechpartner. 
Selbst wenn er es nicht verstanden hat könnte man ja noch nachfragen. 
Habe es auch vorher über das Kontaktformular der Webseite probiert. 
Hatte aber auch nichts gebracht.

Meiner Einschätzung nach ist ein Endkunde der etwa 3000€ augegeben hat 
kein Grund mal irgendwie zu antworten. Bin wohl nicht die Zielgruppe. 
Eine andere Erklärung habe ich im Moment nicht.

[Ingo F. (ingof)]

Wegstaben Verbuchsler schrieb:
> weil er nicht gescheit Sommerzeit berücksichtigt?

Ja, das auch.

Es gibt eine Automatik für Sommer/Winterzeit die bei mir nicht 
funktioniert.

Wenn ich die Manuell auf Sommerezit oder Winterzeit umschalte 
funktioniert es auch nicht. Die Uhrzeit umstellen klappt wohl. Dann 
stimmen aber die Zeitschalten und oder die Berechnung des Sonnenaufgangs 
oder des Sonnenuntergangs nicht mehr.

Es gibt ja auch Probleme dass Aktoren nachträglich nicht angelernt 
werden können. Wenn ich z.B. mal einen Schalter unbenutzt lasse ist er 
aus der Control Unit heraus und ich muss noch mal komplett mit dem 
Wizard anfangen. Allso ALLE Schalter wieder zu jedem einzelnen Rollo 
zuordnen.

Es gibt zwar einen Menüpunkt dafür, aber der Funktioniert nicht richtig. 
Oder besser gesagt garnicht..

Also eigentlich viel Geld für keinen Support und einige Bugs.

[NaNa_JaJa (Gast)]

>>Wenn also die Sonne von Norden scheint. Warum sollen dann die Rolladen
im Süden auf verdunnkeln.<<

Wo wohnst du denn ?
Bei mir geht die Sonne  im Osten auf,steht Mittags im Süden und geht im 
Westen unter.

[IngoF (Gast)]

NaNa_JaJa schrieb:
> Wo wohnst du denn ?
> Bei mir geht die Sonne  im Osten auf,steht Mittags im Süden und geht im
> Westen unter

Ups...
War für meinen Wohnort wohl falsch. ...Wohne auch auf der Nordhalbkugel 
;-)

Also:
Wenn also die Sonne von Süden scheint. Warum sollen dann die Rolladen
im Norden auch verdunkeln.


Aber eigentlich bin ich jetzt von meinen CRC-knacken Problem wohl etwas 
zu weit abgeschweift...

[Werner M. (Gast)]

IngoF schrieb:
> Aber eigentlich bin ich jetzt von meinen CRC-knacken Problem wohl etwas
> zu weit abgeschweift...

... und hast dabei ganz vergessen, dass du noch Hersteller und 
Produktbezeichnung kund tun wolltest, um mit dem eigentlichen Problem 
weiter zu kommen.

[Ingo F. (ingof)]

Werner M. schrieb:
> ... und hast dabei ganz vergessen

Nein, nicht vergessen...
Nur beim "umbauen" der Antwort irgendwie wohl wieder verschwunden.

Es ist die "SMI-Control Unit" mit Massenhaft "SMI-Switch-Bus Connector" 
und entsprechenden SMI-Antrieben.
Alles von SELVE

Wegstaben Verbuchsler schrieb:
> wg. deinem CRC-Problem: Ich dachte, die Komponenten sind untereinander
> kompatibel ... gibt es denn keine technische Spezifikation des
> Protokolls, an dem sich alle Herstelelr halten (müssen)?

Wenn das nicht sogar bei einem Hersteller kompatibel ist, wo dann.

Der SMI-Bus ist ja durch die SMI-Group dokumentiert, Aber auch nur für 
"Mitglieder" zugänglich. Aber darum geht es mir nicht.
Mir geht es um die Switch-Bus-Connectoren.. Irgendwie ist dort nur noch 
die Prüfsumme für mich rätselhaft. Der Rest ist schon so gut wie klar.

Die Switch-Bus-Connectoren sind eine Eigenentwicklung von SELVE. 
Natürlich werden die mir wohl nicht das Protokoll verraten...

[Konrad S. (maybee)]

Ingo F. schrieb:
> Das ganze Geraffel mit Fenster öffnen ist kein Problem und die Hardware
> wurde auch schon eingebaut.

Nicht dass es zum Thema passen würde oder gar dir ;-) weiterhelfen 
würde, aber mich interessiert, wie deine Lösung dafür aussieht. Magst du 
etwas dazu sagen?

[Thomas (kosmos)]

werden da immer 3 Nachrichten übertragen? Kannst du 2 mal die gleichen 
Daten übertragen um zu sehen ob die Prüfsumme gleich bleibt, könnte sein 
das sich das Polynom ändert welches du eh nicht kennst.

[IngoF (Gast)]

Konrad S. schrieb:
> Ingo F. schrieb:
>> Das ganze Geraffel mit Fenster öffnen ist kein Problem und die Hardware
>> wurde auch schon eingebaut.
>
> Nicht dass es zum Thema passen würde oder gar dir ;-) weiterhelfen
> würde, aber mich interessiert, wie deine Lösung dafür aussieht. Magst du
> etwas dazu sagen?

Eine Platine mit einem PIC18F2680.

Mit:

24V/5V Wandler   (für Switchbus und Stromversorgung
5V-Ausgang        (zur Versorgung evtl. anderer Baugruppen wie z.B. Switchbus Connector)
RS485             (für Switchbus)
CAN (isoliert)    (für die Kommunikation mit Server)
"230V-Schalter"   (für PWM (Heizkörper Thermostat)
1-Wire            (für 18B20)
4 Fensterkontakte (zwei Fenster mit Auf-/Kipperkennung)
Lochrasterteil    (für Erweiterung)

Sicher könnte ich damit die Switchbus-Connectoren ganz erzestzen...

Hat aber den Nachteil dass ich wieder an die Rolladenkästen müsste...

Gruß
IngoF

[IngoF (Gast)]

IngoF schrieb:
> Mit:

S=-Bus     (für Stromzähler)

noch vergessen...

[IngoF (Gast)]

IngoF schrieb:
> IngoF schrieb:
>> Mit:S=-Bus     (für Stromzähler)
> noch vergessen...

... Sollte S0-Bus heissen

[c-hater (Gast)]

Ingo F. schrieb:

> Wenn also die Sonne von Norden scheint.

Das tut sie nur an einem einzigen Punkt der Erde, und zwar am Südpol, 
soviel ist mal sicher. Ist aber auch dort kein Problem, denn an dieser 
Singulariät zeigt auch jede Wand des notwendigerweise infinitiv kleinen 
Hauses nach Norden und außerdem scheint die Sonne, wenn sie denn 
scheint, dort auch immer von Norden...

Das liegt allerdings nur daran, daß es dort eben nur eine Richtung gibt. 
An jedem anderen Punkt der Erde hingegen scheint die Sonne niemals von 
Norden.

[IngoF (Gast)]

Thomas O. schrieb:
> werden da immer 3 Nachrichten übertragen? Kannst du 2 mal die gleichen
> Daten übertragen um zu sehen ob die Prüfsumme gleich bleibt

Nein, die drei Telegramme sind nur Beispiele um zu erkennen ob es eine 
"echte" CRC ist. Aber die Methode scheint bei meinem Beispiel nicht zu 
klappen.

Die Methode habe ich aus dem dort angegebenen Link.

Es wird immer ein Telegramm übertragen und vom Master beantwortet.
Die Prüfsumme bleibt immer gleich.

Habe mal alle Telegramm mitgeschnitten und die doppelten Einträge 
rausgeschmissen.

Hänge ich einfach mal an..

[Werner M. (Gast)]

Ingo F. schrieb:
> Natürlich werden die mir wohl nicht das Protokoll verraten...

Bist du dir mit der Interpretation des Datenstromes sicher.
Hier sieht das etwas anders aus
Beitrag "Re: Gibt es irgendwo brauchbare Infos zu SMI ?"
Und dort läuft es auf eine Prüfsumme mit Byteaddition hinaus.

[IngoF (Gast)]

c-hater schrieb:
> Das tut sie nur an einem einzigen Punkt der Erde,

gut dann eben aus "Richtung" Norden :-P

Aber darum geht es hier eigentlich.

Und die möglichkeit dass von allen Seiten gleich viel Licht 
hereinstrahlt (starker Nebel) möchte ich auch mal vernachlässigen. Dann 
benötigt man eh keine Verdunklung).

Es sei denn ich hau mich aufs Ohr...

[IngoF (Gast)]

IngoF schrieb:
> Aber darum geht es hier eigentlich. NICHT

[Thomas (kosmos)]

ich würde deine Nachrichten mal durch ein paar Online CRC Rechner jagen, 
mit etwas Glück verwenden die ein gängiges Polynom und machen keine 
Bitmanipulationen bevor es in den CRC Rechner geht.

[Georg G. (df2au)]

c-hater schrieb:
>> Wenn also die Sonne von Norden scheint.
>
> Das tut sie nur an einem einzigen Punkt der Erde

Kriech mal aus deinem Keller. Nördlich des Polarkreises scheint die 
Sonne im Sommer auch aus Norden.

[Konrad S. (maybee)]

IngoF schrieb:
> Eine Platine mit ...

Danke!

[Mike (Gast)]

c-hater schrieb:
> Das tut sie nur an einem einzigen Punkt der Erde, und zwar am Südpol,
> soviel ist mal sicher.

Und auf der Nordhalbkugel (bis auf den Pol) scheint sie nie aus dem 
Süden?

Halte es doch einfach mal mit Dieter Nuhr ...

[Carsten S. (dg3ycs)]

Hi,

mal als kurzen Einwurf zwischendurch:
Wenn ich das richtig verstanden habe hast du zu jedem Telegramm eine 
feste Prüfsumme die immer gleich bleibt.

Wenn du also mit der vorhandenen Steuerung an den Aktor des 
Küchenfensterrolos den Befehls zum öffnen incl. Prüfsumme mitschneidest 
und dann die Steuerung abklemmst und das komplette mitgeschnittene 
Telegramm samt mitgeloggter Prüfsumme durch einen eigenen Controller 
sendest würde ebenfalls eine Öffnung erfolgen?

Natürlich ist es schöner wenn man die Prüfsumme selbst erzeugen kann da 
damit die beliebige Generierung des Telegramms möglich wird was Speicher 
spart und die Programmierung erleichtert.

Wenn es aber so wie von mir vermutet ist wäre es aber, sofern die 
Ermittlung des algorythmus nicht gelingt, einmal sämtliche Benötigten 
Telegramme auszugeben und diese in einer Tabelle abzulegen.
Ist natürlich in gewisser weise eine Strafarbeit, aber möglich. So viele 
genutzte Schalter und Aktionscodes wird man in einem EFH normalerweise 
ja auch nicht haben. (Oder geht es um ein Firmengebäude?)

Nur mal als Alternativvorschlag -PLAN B- falls du nicht dahinter kommst 
wie die Prüfsumme generiert wird. Allerdings würde ich auch erst einmal 
dem Versuch diese selbst zu generieren auf jeden Fall vorrang einräumen.
(Dazu fällt mir gerade aus dem Stehgreif leider auch nichts ein.)

Gruß
Carsten

[Edi R. (edi_r)]

Georg G. schrieb:
> Kriech mal aus deinem Keller. Nördlich des Polarkreises scheint die
> Sonne im Sommer auch aus Norden.

Kühne Behauptung...

[Thomas (kosmos)]

wäre es nicht besser die Telegramme die du ja hast inkl. Checksumme 
selber auf Reise zu den Aktoren zu schicken und den Master 
rauszuschmeißen?

[Georg G. (df2au)]

Edi R. schrieb:
> Kühne Behauptung...

Inwiefern? Ich war dort schon des öfteren. Im Juni, nachts um 24:00 
steht in Kirkenes die Sonne im Norden. Dafür ist es im Dezember 24 
Stunden am Tag duster. Fahr mal hin, ist eine interessante Gegend.

Noch ein Tipp: https://de.wikipedia.org/wiki/Mitternachtssonne

[Stefan W. (dl6dx)]

Ingo F. schrieb:
> Nur scheint es an der Prüfsumme zu scheitern.
> Ich vermute eine eine CRC16 komme aber auf keinen grünen Zweig.

Beitrag "Re: Gibt es irgendwo brauchbare Infos zu SMI ?"

hat du schon gelesen?

Grüße

Stefan

[und nun (Gast)]

Einen solchen CRC zu Knacken kann je nachdem einfach sein. Ich hatte 
auch kuerzlich so ein Problem. Die Menge an verschiedenen Meldungen, die 
ich brauchte war bescheiden. Und, wichtig ... eine Meldung mit falschem 
CRC bewirkte nichts. Ein CRC16 sind also nur 65k Moeglichkeiten. Mit 
einem Computer sind die schnell durchgelassen. Bis eben wieder eine 
Antwort kommt.

[IngoF (Gast)]

Werner M. schrieb:
> Bist du dir mit der Interpretation des Datenstromes sicher.
> Hier sieht das etwas anders aus

Ja, Da habe ich auch fleissig mitgeschrieben...

Da geht es aber um den SMI-Bus. hier geht es um den Switch-Bus der auch 
an der SMI-Control-Unit hängt

Carsten Sch. schrieb:
> Wenn ich das richtig verstanden habe hast du zu jedem Telegramm eine
> feste Prüfsumme die immer gleich bleibt.

Ja, ich könnte wirklich alle mitschneiden. Allerdings sind noch nicht 
alle verbaut. Wäre aber möglich.

Wenn ich das aber so machen würde hätte ich das Problem dass ich 
eventuell nachträglich keine mehr anschließen könnte (Erweiterung)

Notfalls alle rausschmeissen und meine Platine die Arbeit übernehmen 
lassen..

Würde heissen alle frisch gestrichenen Rolladenkästen wieder aufmachen..

Gruß
IngoF

[Stefan W. (dl6dx)]

Stefan Wagner schrieb:
> Beitrag "Re: Gibt es irgendwo brauchbare Infos zu SMI ?"

Du hättest doch mal hineinschauen sollen.

Der Autor gibt nämlich an, er habe das Verfahren bereits als eine 
einfache Prüfsumme identifiziert, nämlich als das Zweierkomplement der 
8-bit breiten Summe der Bytewerte.

Prüf das doch mal anhand deiner Daten.

Grüße

Stefan

[Ingo F. (ingof)]

Stefan Wagner schrieb:
> Der Autor gibt nämlich an, er habe das Verfahren bereits als eine
> einfache Prüfsumme identifiziert

JAIN,

Die Prüfsumme funktioniert auch für den "SMI-Bus".
Hier geht es aber um den "Switch-Bus"

Der SMI-Bus ist nur für die Steuerung der Rolladenantriebe geeignet.
Das geht auch alles über die SMI-Control-Unit.

Das hat nichts mit den Schaltern zu tun. Man kann also nur nach Programm 
die Rolladen fahren lassen. Um Schalter anzuschließen ist bei der 
SMI-Control-Unit ein RS485-Bus vorgesehen. Dort werden über 
Switch-Bus-Connectoren die Schalter angeschlossen.

Diese haben 4 Schalter (Hoch, Runter, Stop, Automatik). Diese 
"Switch-Bus-Connectoren" haben ein eigenes Protokoll mit anderer 
Prüfsumme.

Und um diese geht es hier. Der SMI-Bus ist für mich schon erledigt.



Ich habe jetzt gerade noch mal einen Online-CRC-Calculator getestet. 
Aber irgendwie scheint der nicht zu funktionieren.

Bei einer CRC-Berechnung werden bei einer 16Bit CRC erst 16 "0"-Bits 
angehangen und die CRC-berechnet. Dann werden diese "Platzhalter" durch 
die CRC ersetzt. Wenn man dann eine CRC über die Daten incl. der 
errechneten CRC berechnet sollte 0 herauskommen.

Bei dem CRC-Calculator klappt das aber nicht. Habe auch den HEX-Knopf 
unten gesehen. Bringt aber keine Besserung.

Ist der Calculator buggy oder habe ich da was falsch verstanden?

Um den geht es hier:
http://www.lammertbies.nl/comm/info/crc-calculation.html

Habe zwei verschiedene Telegramme ausprobiert und auch keine ähnliche 
Prüfsumme herausbekommen...

Gruß
IngoF

[Stefan W. (dl6dx)]

Ingo F. schrieb:
> Hier geht es aber um den "Switch-Bus"

Ok, das war mir entgangen.

Bist du denn sicher, dass es ein CRC sein muss? Ich habe über die Jahre 
die unterschiedlichsten Verfahren gesehen.
Was du z.B. prüfen könntest:

LRC:
Checksummenberechnung: Alle Bytes der Nachricht werden XOR-verknüpft und 
angehängt.
Checksummenprüfung: Alle Bytes der empfangenen Nachricht werden 
XOR-verknüpft, das Ergebnis muss 0 (0x00) sein.

Das habe ich schon an verschiedenen Stellen so gefunden.

Beim NMEA-Protokoll wird dieses Verfahren auch eingesetzt, jedoch wird 
der Wert als "ASCII-HEX" übertragen.

Die einfache 8-Bit-Checksumme hatte ich ja schon genannt.

Dann habe ich beim Stöbern in alten Sourcen noch diesen Exoten gefunden:

/*==========================================================================*/
/*                              append_checksum                             */
/*==========================================================================*/
/* Haengt an ein Telegramm der Laenge 'length' eine Checksumme an. Dies ist */
/* eine 1-Byte Checksumme, die aber als 2-Byte Hexadezimaldarstellung an    */
/* den String angehaengt wird, d.h. wenn die Checksumme 31 (dezimal) waere, */
/* werden die beiden Bytes '1F' (=31) angehaengt.                           */

Kannst du nicht mal ein paar Beispieltelegramme bereit stellen?

Grüße

Stefan

[Stefan W. (dl6dx)]

Ingo F. schrieb:
> Bei einer CRC-Berechnung werden bei einer 16Bit CRC erst 16 "0"-Bits
> angehangen und die CRC-berechnet. Dann werden diese "Platzhalter" durch
> die CRC ersetzt. Wenn man dann eine CRC über die Daten incl. der
> errechneten CRC berechnet sollte 0 herauskommen.

Nein, das muss nicht so sein. Siehe z.B. den CCITT-CRC (HDLC):

/* ------------------------------------------------------------------------
  CCITT-CRC berechnen.
  Der Initialwert von crc ist 0xFFFF, für jedes Byte der Nachricht wird
  der CRC weitergerechnet. Der über alle Bytes der Nachricht berechnete
  CRC wird invertiert (Einerkomplement!) und in der Reihenfolge low byte,
  high byte übertragen.
  Der Empfänger berechnet den CRC über alle empfangenen Zeichen ein-
  schliesslich der beiden übertragenen CRC-Bytes, das Ergebnis der
  Berechnung muss 0xF0B8 sein.
   ------------------------------------------------------------------------  */

Wie man sieht, kommt es neben dem Generatorpolynom auch auf den 
Startwert und die Übertragung des CRC (MSB/LSB, invertiert/nicht 
invertiert) an.

Grüße

Stefan

[(prx) A. K. (prx)]

Es gibt auch CRCs, die bitreversed übertragen werden.

[Konrad S. (maybee)]

Weder Initialwert 0 oder 0xffff, noch bitreversed bringt ein brauchbares 
Ergebnis. Es gibt auch kein Generator-Polynom, das für die Beispiele 
hier Beitrag "Re: CRC / Prüfsumme knacken" 
funktionieren würde.

[Ingo F. (ingof)]

Stefan Wagner schrieb:
> Bist du denn sicher, dass es ein CRC sein muss?

Nein, ich habe keine Ahnung was das ist.. Aber wenn sich auch nur ein 
einziges Bit ändert ändert sich in der Prüfsumme gleich mehrere Bits.

Habe es jetzt gerade mal probiert:

F0 23 36 81 14 (89 69)
F0 23 36 81 15 (00 78)

F0 23 44 81 14 (E9 5C)
F0 23 44 81 15 (60 4D)

F0 23 44 81 04 (68 4C)
F0 23 44 81 05 (E1 5D)

Bei den drei Telegrammenpaaren ändert sich nur das niedrigste Bit im 
letzten Datenbyte.

Bei allen Telegrammenpärchen ändert sich aber in der Prüfsumme gleich 5 
Bits.

Seltsamerweise toggelt aber jedesmal genau die selben Bits:

10001001 00010001 (89 11)

Bei Bit4 von Byte3 zwei ändern sich gleich 7 Bits:

F0 23 44 81 03 (D7 38)
F0 23 54 81 03 (42 BD)

F0 23 44 81 00 (4C 0A)
F0 23 54 81 00 (D9 8F)

F0 23 44 01 02 (92 A5)
F0 23 54 01 02 (07 20)

auch jedesmal die selben Bits in der Prüfsumme:

10010101 10000101 (95 85)

Dann dürfte es ja eigentlich keine richtige CRC sein, oder. Durch die 
anderen Bytes müsste ja bei einer "echten" CRC eine ganz andere Bitfolge 
herauskommen. Und zwar eine die bei unterschiedlichen Telegrammen nicht 
die selben Bits ändert, oder?

Also wohl eine vermutlich für jedes Byte eine eigenes Bitmuster das 
irgendwie ja nach Position berechnet wird.
Oder sogar für jedes Bit.

Stefan Wagner schrieb:
> Nein, das muss nicht so sein. Siehe z.B. den CCITT-CRC (HDLC):

ist klar. Aber wenn ich eine Beliebige Bitfolge nehme und die Prüfsumme 
berechnen lasse. Z.B. mit dem von mir verlinkten CRC-Generator.
Dann muss sich die CRC auch mit den selben Seinstellungen überprüfen 
lassen können
 Also z.B.
(F023540102) bekomme ich die CRC xxxx wenn ich diese anhänge
(F023540102xxxx) sollte die Prüfsumme 00 sein oder zumindest falls noch 
mal ein XOR kommt zumindest den selben Wert.

Habe das auch mal mit F0235401020000 probiert und die 0000 durch die 
Prüfsumme xxxx ersetzte. Also F023540102xxxx aber da kommt immer wieder 
was ganz anderes heraus.

Oder liege ich da falsch?


Aber nach meinen vorherigen Beispiel kann es ja dann wohl keine "echte" 
CRC sein.


Den Abschnitt 3 aus meinem ersten Link kann ich wohl nur verwenden wenn 
ich vorher drei Telegramme erzeuge die jeweils nur drei 
aufeinanderfolgende Bits ändere. Also die vorgeschlagenen Buchstaben 
einfüge und dann noch den Schritt 2 durchgeführt habe.

Dummerweise kann ich das leider nicht hinbekommen.

Gruß
IngoF

[Sebastian (Gast)]

Ich denke, die zwei Prüfbytes müssen nicht unbedingt ein Hinweis auf ein 
CRC-Verfahren sein. Man kann Prüfsummen auch anders bilden, siehe LRC 
(Wikipedia): http://en.wikipedia.org/wiki/Longitudinal_redundancy_check 
und BCC: http://automationwiki.com/index.php?title=BCC

[oha (Gast)]

Auch wenn das CRC Polynom vorgegeben ist, kann man's noch verschieden 
machen. zB die beiden Bytes vertauschen. Oder nach links anstelle von 
nach rechts schieben. Und dann gibt's noch Leute, die ver-XOR-en das 
Resultat auf beiden Seiten, um auf der "geheimen" Seite zu bleiben.

[IngoF (Gast)]

Bin noch nicht viel weiter gekommen.

Bin mir aber jetzt sicher dass es keine "richtige" CRC ist.

Ich habe alle 185 Telegramme die ich gefunden habe miteinander 
vergleichen lassen.

Wenn sich im Telegramm ein einziges Bit verändert ändern sich in der 
Prüfsumme immer die selben Bits.

Mal als PDF-Beispiel alle Telegrammpärchen indem sich nur im Byte 5 das 
Bit 0 ändert.

Denke damit ist schon mal ziemlich sicher das es keine "richtige" CRC 
sein kann, oder?

[Nosnibor (Gast)]

Aber Linearität ist doch eine typische Eigenschaft von CRCs.
Also CRC(x exor y) = CRC(x) exor CRC(y)
Man kann also z.B. eine Tabelle bauen (z.B. aus beobachteten 
Beispielnachrichten rekonstruieren), die für jedes mögliche Bit der 
Nachricht den entsprechenden CRC-Code enthält. Und mit der Tabelle kann 
man dann zu jeder beliebigen Nachricht den richtigen CRC-Wert bestimmen.

[Stefan (Gast)]

Hallo,

die Berechnung deiner CRC ist eine ganz gewöhnliche "reverse" Berechnung 
mit dem Polynom CRC-16-CCITT wie man sie auch bei HDLC benutzt.

siehe hier: http://en.wikipedia.org/wiki/Cyclic_redundancy_check
(auf der englischen Seite sind mehr Polynome aufgeführt!)


zunächst wird die CRC mit 0xffff vorbelegt, dann ganz normal reverse 
durchgerechnet und dann zum Schluss das Komplement der CRC an die Msg 
angehängt.
Um zu sehen wie das genau geht habe ich dir ein Beispielprgramm für die 
drei Beispiel Msg's angeängt!


Gruss

[Simplizissimus (Gast)]

Wie war das Leben damals komfortabel, als man den Rolladen per Gurt noch 
präzise unter seiner Kontrolle hatte. :-D

[:-) (Gast)]

Simplizissimus schrieb:
> Wie war das Leben damals komfortabel, als man den Rolladen per Gurt noch
> präzise unter seiner Kontrolle hatte. :-D

Und wenn mal ein Gurt gerissen ist, konnte man noch einen echten 
Hardware-Hack anwenden! Knoten im Gurt und irgendwo einhängen damit der 
Rolladen offen blieb :-)

[Ingo F. (ingof)]

Nosnibor schrieb:
> Aber Linearität ist doch eine typische Eigenschaft von CRCs.

Hatte es gestern abend auch noch mal testweise mit einem CRC-Generator 
getestet. Es kamen zwar andere Prüfsummen heruas. Aber das Verhalten war 
das selbe. Hatte irgendwie im Hinterkopf dass bei ändern eines 
bestimmten Bits die CRC sich nicht immer gleich verändert.

Ist aber wohl falsch...

Stefan schrieb:
> die Berechnung deiner CRC ist eine ganz gewöhnliche "reverse" Berechnung
> mit dem Polynom CRC-16-CCITT

Na dann habe ich schon mal die Erklärung warum die beiden Online-CRC 
Berechnungstools nicht funktioniert haben.

Der eine kann keine reversed CRC. Und der andere hat einen Bug bei genau 
dieser CRC mti dem Polynom 0x8408.

DANKE....

Konnte mir nicht mehr erträumen.. Die richtige CRC-Berechnung und schon 
fertigen C-Code den ich schon fast per Copy&Paste übernehmen kann.

Habe es jetzt noch nicht testen können. Werde wohl erst am Wochende dazu 
kommen...

Simplizissimus schrieb:
> Wie war das Leben damals komfortabel, als man den Rolladen per Gurt noch
> präzise unter seiner Kontrolle hatte.

Noch habe ich das. Allerdings war ich abends immer zu faul jede Rolladen 
am Abend herunterzulassen. Im Winter könnte das vorteilhaft für die 
Heizkostenrechnung sein.

Hat natürlich einen Nachteil bei Stromausfall...

[Johannes S. (demofreak)]

Ingo F. schrieb:
> Hat natürlich einen Nachteil bei Stromausfall...

Nicht, wenn die Gurte als Fallback dran bleiben.

[Ingo F. (ingof)]

Stefan schrieb:
> habe ich dir ein Beispielprgramm

DANKE!
Copy&Paste mit kleinen Anpassungen hat perfekt funktioniert.

Wie hast Du das den herausbekommen? Einfach ausprobiert? Womit hast Du 
die denn berechnen lassen?

Johannes S. schrieb:
> Nicht, wenn die Gurte als Fallback dran bleiben.

Theoretisch mag das möglich sein....

Man müsste die Sperrfunktion vom Gurtabwickler ausbauen damit sich der 
Gurt mitdrehen könnte.

Soweit ich weiss bleibt nur noch das Problem dass man die Motoren nicht 
so einfach, z.B. über den Gurt, drehen kann. Auch nicht im stromlosen 
Zustand...

Habe jetzt keinen Motor zur Hand mit dem ich das so auf die Schnelle 
testen könnte.

[D. V. (mazze69)]

Der moderne Schei* fördert nur den Muskelschwund und die Hersteller 
dieser bequemen Gimmicks zahlen auch nicht mehr in die Kassen,als 
üblich, die den oberfaulen Gurtmuffeln später die Reha finanzieren.

[Stefan (Gast)]

Hallo,

Ingo F. schrieb:
> Wie hast Du das den herausbekommen? Einfach ausprobiert? Womit hast Du
> die denn berechnen lassen?

Ich hab mich vor sehr langer Zeit einmal sehr intensiv mit CRC-Routinen 
beschäftigt und hab daher noch einige selbstgechriebene Testroutinen. In 
deinem Fall hat die 7. (glaube ich) die ich ausprobiert habe ein 
Ergebnis gebracht. Das hat gerade mal 10 Minuten gedauert. Ich hätte 
noch weitere 10 bis 15 Polynome und Methoden ausprobiert und hätte dann 
keine gepasst hättest du es nie erfahren.

Zur Erinnerung: Jeder Funkamateur der sich mal mit "Packerl Radio" 
(AX.25) beschäftigt hat kennt genau dieses CRC16-CCITT Polynom und die 
Art und Weise wie man es benützt und die errechnete CRC an die Msg 
anfügt.

Du musst dich allerdings jetzt mit der Bedeutung der einzelnen 
Telegramme noch auseinandersetzen.

viel Spass
Stefan

[ich (Gast)]

D. V. schrieb:
> die den oberfaulen Gurtmuffeln später die Reha finanzieren.

Hallo, klopf klopf. Aufwachen! Es geht bei den Gurten um Rolläden. :-))

[IngoF (Gast)]

Stefan schrieb:
> und hätte dann
> keine gepasst hättest du es nie erfahren.

Naja, notfalls hätte ich es mit BruteForce probiert.
Hatte das damals bei einer anderen "CRC" probiert. Dummerweise war das 
dann keine CRC.

Überlege schon seit zwei Tagen wie das Programm hieß. War irgendeins für 
die CommandLine von Windows.

Stefan schrieb:
> Du musst dich allerdings jetzt mit der Bedeutung der einzelnen
> Telegramme noch auseinandersetzen

Brauch ich nicht mehr...

1. Byte immer 0xF0
2. Byte Adresse High
3. Byte Adresse Low
4. Byte immer abwechselnd 0x01 oder 0x81. Bei der Antwort wird das Bit7 
immer invertiert.
5. Byte AktionsCode:
6. Byte CRC High
7. Byte CRC Low

Hoch: 0x03, 0x04, 0x005
Runter: 0x013, 0x014, 0x015
Stop:  0x023
Automatik EIN/AUS: 0x37, 0x36

Das Low-Nibble hat bei hoch und runter folgende Bedeutung:

3: Kurzer Tastendruck
4: Langer Tastendruck
5: Doppelter kurzer Tastendruck.

Wird mit 19200 8N1 über RS485 übertragen
Der Master wiederholt die Telegramme immer mit Aktionscode 0x00

Beim Tastendruck wird erst einmal 0x02 für Hoch und 0x12 für Runter 
gesendet. nach etwa 250ms kommt dann das Byte mit dem "Aktionscode"

Nur die Tastercheck vom Master hat noch ein Byte mehr. Aber das scheint 
keine große Bedeutung haben.

Also eigentlich recht einfach aufgebaut...

Gruß
Ingo

[D. V. (mazze69)]

ich schrieb:
> Hallo, klopf klopf. Aufwachen! Es geht bei den Gurten um Rolläden. :-))

Du hast den Gag nicht inhaliert.
Der Standard-Sack sitzt auf dem Sofa und macht per Knopfdruck die 
Rouladen zu und wundert sich, warum er keinen mehr hoch bekommt...

[ich (Gast)]

D. V. schrieb:
> ich schrieb:
>> Hallo, klopf klopf. Aufwachen! Es geht bei den Gurten um Rolläden. :-))
>
> Du hast den Gag nicht inhaliert.
> Der Standard-Sack sitzt auf dem Sofa und macht per Knopfdruck die
> Rouladen zu und wundert sich, warum er keinen mehr hoch bekommt...

Okay. Und ich dachte, wenn du von Kassen, Gurtmuffeln und Reha sprichst, 
meinst du die Gurte im Auto. Deswegen mein Kommentar.

Nichts für ungut... :-)

[IngoF (Gast)]

D. V. schrieb:
> Der Standard-Sack sitzt auf dem Sofa und macht per Knopfdruck die
> Rouladen zu und wundert sich, warum er keinen mehr hoch bekommt...

Naja, wer den Gurt benutzen muss um körperlich Fit zu bleiben hat auch 
noch ganz andere Probleme :-P

[IngoF (Gast)]

Ingo F. schrieb:
> Und der andere hat einen Bug bei genau
> dieser CRC mti dem Polynom 0x8408

Vielleicht ist der "Fehler" ja bald nicht mehr in dem Online-Tool für 
die CRC Berechnung... Habe gerade erst mal den Code weitergeleitet...

DANKE noch mal für den Hinweis und den Quelltext.

[IngoF (Gast)]

IngoF schrieb:
> Habe gerade erst mal den Code weitergeleitet...

Das war wohl nichts.. Die Mail existiert nicht mehr...

[Konrad S. (maybee)]

Durch Stefans Informationen habe ich jetzt auch die richtigen Parameter 
für die CRC-Berechnung in Perl herausgefunden.

use Digest::CRC qw( crc );
my $input = "\xf0\x23\x36\x01\x00";
my $crc = crc( $input, 16, 0xffff, 0xffff, 1, 0x1021, 1 );
printf "%02x %02x\n", $crc & 0xff, $crc >> 8;

Vielen Dank dafür!