www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CRC Prüfsumme rückwärts rechnen


Autor: Frank Hi (frank77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

wir stehen vor einem Rätsel. Weil wir keine Dokumentation haben, haben 
wir einen Sniffer zwischen einen PC mit einer RS485 Schnittstelle und 
einer Motoransteuerung eingebaut um den Telegrammverkehr zu sehen.

FF 1C00 0000 0000 0000 0000 0000 0000 0000 C8BF 8002
FF 0500 9E12 0000 0000 0000 0000 0000 0000 0000 C002
FF 0F00 0000 9DBF 0000 0000 0000 0000 0000 0000 A002

FF 2500 0000 0000 0000 98BF 0000 0000 0000 0000 B004
FF 2800 0000 0000 0000 98BF 0000 0000 0000 0000 A003

Hier ist ein Auszug von den Daten zu sehen. Wir wissen aufgrund von 
Tests auch was die einzelnen Stellen bedeuten. FF scheint die 
Startkennung zu sein und der letzte Block (z.B. 8002) muss eine 
Prüfsumme sein.
Nun ist die Frage wie wird diese Prüfsumme berechnet.

Mit einer Analysesoftware kann man den PC mit dieser Motorsteuerung über 
einen RS232 Port verbinden und Statistikdaten auslesen.

Manipuliert man jetzt so ein Datentelegramm kann man in der Statistik 
genau sehen dass der CRC-Errorcounter hochzählt und der Motor tut 
nichts. Sende ich die Telegramme unverändert dreht der Motor wie 
gewünscht.

Wie gesagt, wir haben null Dokumentation und Informationen, würden aber 
gerne die PC-Steuerung ablösen und durch eine SPS ersetzen.
Hat jemand eine Idee wie wir hier weiterkommen können?

Vielen Dank
Frank

: Verschoben durch Moderator
Autor: Chefingenieur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du möchtest den CRC-Code knacken. Soso.
-> http://www.copacobana.org/

Alternativ alle infrage kommenden (benötigten) Motorsteuersignale 
aufzeichen und von der PC Software einschließlich Prüfsumme abspielen.

Oder einen CRC Generator berechnen lassen:

Alle alle infrage kommenden (denkbaren) Signalkombis abspielen, 
aufzeichen und in eine Matrix eintragen und so für jedes CRC-Bit eine 
Gleichung entwickeln. Die dann der VHDL-Synthese übergeben.

Die baut Dir dann den CRC nach.

Anhand des RTL sollte man sogar die Gleichung erkennen können.

Autor: Frank Hi (frank77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielen Dank für die Info. Der Weblink funktioniert aber nicht.
Hätte mich interessiert, was ich dort finden kann.

viele Grüße
Frank

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Frank Hi (frank77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielen Dank für den Link.
Wirklich viel schlauer bin ich leider nicht geworden.

Hat denn jemand eine Idee wie diese Prüfsumme zustande kommt?
FF 1C00 0000 0000 0000 0000 0000 0000 0000 C8BF 8002

Bei allen Prüfsummen (hier 8002) sind in der Mitte immer zwei Nullen 
(00).
Wenn ich einen CRC-Rechner verwende habe ich das aber noch nie 
hinbekommen (http://zorc.breitbandkatze.de/crc.html)

viele Grüße
Frank

Autor: Wahhhhhhh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist es sicher dass es sich wirklich um CRC handelt? IIRC hat das 
benutzte Polynom genausoviele Bits wie die errechnete Prüfsumme, in 
diesem Fall also 32. Das gibt 2^32 Möglichkeiten, wobei das höchste Bit 
gesetzt sein muss, bleiben also 2^31. CRC ist ja relativ simpel, das 
sollte sich doch mit einem normalem PC per Brute-Force "knacken" 
lassen... ? (Alle Angaben ohne Gewähr)

Autor: Wahhhhhhh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo? Meldet sich Frank Hi nochmal?

Autor: Frank Hi (frank77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

tut mir leid. Hab mich tagelang ohne Essen und Trinken eingeschlossen 
und über die Prüfsumme gekrübelt - leider kein Erfolg. :-)

Wir haben keine Idee wie man auf die Formel kommen könnte.
Wir haben noch die Hoffnung dass andere Firmen mit den gleichen Modulen 
vielleicht die notwendige Info haben. Sonst müssen wir uns einen anderen 
Weg suchen...

Nochmal Danke für die Unterstützung.
viele Grüße
Frank

Autor: Wahhhhhhh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meinen Beitrag oben gelesen?

Wahhhhhhh schrieb:
> Ist es sicher dass es sich wirklich um CRC handelt? IIRC hat das
> benutzte Polynom genausoviele Bits wie die errechnete Prüfsumme, in
> diesem Fall also 32. Das gibt 2^32 Möglichkeiten, wobei das höchste Bit
> gesetzt sein muss, bleiben also 2^31. CRC ist ja relativ simpel, das
> sollte sich doch mit einem normalem PC per Brute-Force "knacken"
> lassen... ? (Alle Angaben ohne Gewähr)

Autor: BimmyandJimmy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Frank;
die beiden Nullen in der Mitte sind in der Tat sehr merkwürdig, da 
anscheinend ohne Sinn Raum für Informationen verschwendet wird.
Anstatt Dir den Kopf zu zerbrechen, welcher sonderbare Algorithmus
hier zum Einsatz kommt, solltest Du Dir lieber mal das Programm
vornehmen, das diese Daten erzeugt. Immerhin könnte es sich auch um
einen Programmierfehler handeln, ein eigenes (schrottiges) 
Schutzverfahren verwendet werden, ein Offset addiert werden, eine 
Byteumordnung stattfinden oder oder oder ....
Disassemblier doch einfach den relevanten Teil des PC Programms. Es wird 
vermutlich nur ein sehr kleiner Teil sein, den Du leicht durchschauen 
kannst (keine schwierigen Verzweigungsbäume), da sowas ja schnell sein 
soll.
Der Programmierer hat sicherlich eine eigene Funktion dafür geschrieben. 
Diese bekommt als Argumente vermutlich einen Zeiger auf den Datenblock, 
Länge des Datenblocks und vielleicht einen Zeiger, wo das Resultat 
abgelegt werden soll (oder es wird als Returnwert übergeben).
Sollte mit einem aktuellen Debugger schnell zu finden sein.
Falls Du nicht weiter kommst, kannst Du ja den Assemblercode der 
Funktion hier posten. Hier gibt hinreichend Leute, die das rauslesen 
können.

Viel Erfolg & viele Grüße
   BimmyandJimmy

Autor: Wahhhhhhh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>solltest Du Dir lieber mal das Programm vornehmen, das diese Daten erzeugt

Genau daran dachte ich als Plan B. Auch könnte es nützlich sein den Name 
der Steuerung anzugeben, vielleicht klingelt es ja bei Jemandem (der 
Doku o.ä. dazu hat)...

Autor: Wahhhhhhh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: Wenn es wirklich CRC ist könnte es sich doch um eine CRC16 mit 2 
eingefügten Nullen handeln (warum auch immer...)

Autor: Kilgore, Bill (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wir haben keine Idee wie man auf die Formel kommen könnte.
Du brauchst bloss die Bits einzeln durchzukippen. Dabei fängst du von 
hinten an. Du machst also bei jedem Datenstrom nur eine Veränderung von 
einem Bit. Dadurch kannst du die Polynomgleichung durch Regression 
berechnen. Es ist von der Crc-Komplexität abhängig, wie oft du das tun 
musst. Ein Mathematiker kann dir dabei helfen. (Ich bin keiner, es 
sollte aber nicht allzu schwer sein.) Du wirst vermutlich zwischen 10 
bis 40 Bit probieren müssen.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer sagt denn überhaupt daßßß es CRC sein muß?
Evtl. wird das Wetter oder irgendwas zur Prüfung kodiert?

Autor: Frank Hi (frank77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
genau das ist auch das Problem. Niemand weiß ob es sich um eine 
CRC-Prüfung handelt. Den einzigen Hinweis darauf habe ich in der 
Analysesoftware für die Motoransteuerung entnommen. Da ist die Rede von 
einem CRC-Errorcounter.
Das ganze läuft auf einem Echtzeit-Unix und dabei fällt mir gerade ein, 
dass ich in dem Code schon nachgeschaut habe aber noch nie nach "CRC" 
gesucht habe. Vielleicht gibt es einen Hinweis in den Kommentaren des 
Quellcodes.

Autor: Wahhhhhhh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ihr habt den Quellcode vom Steuerungsprogramm und versucht die Formel 
aus den gesnifften Daten rauszulesen???

Autor: Oliver Ju. (skriptkiddy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Hi schrieb:
> Vielleicht gibt es einen Hinweis in den Kommentaren des
> Quellcodes.

Würde mich mal interessieren, um welches Software es sich handelt. Wenn 
du die Quellen hast, könntest du sie uns doch zur Verfügung stellen oder 
wenigstens den Namen des Programms nennen. Dann können wir dir beim 
Suchen in den Sourcen helfen.

Gruß Skriptkiddy

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> genau das ist auch das Problem. Niemand weiß ob es sich um eine
> CRC-Prüfung handelt.

Das ist bestimmt keine CRC Pruefsumme. Dafuer ist der Informationsgehalt 
zu gering.

> Da ist die Rede von einem CRC-Errorcounter.

Das muss nicht viel heissen. Fuer viele Leute ist CRC so eine Art 
Synonym fuer Pruefsumme.

Streng lieber mal deinen Verstand an.

Hat der Micrcontroller ueberhaubt genug Rechenleistung/Flashrom fuer 
eine CRC oder etwas vergleichbares? Und ist das ueberhaubt noetig fuer 
so eine Popelaufgabe? Wahrscheinlich wurde da nur ein bisschen addiert, 
vielleicht noch ein shift oder XOR drauf.

Wenn man dich das naechstemal bei Wasser&Brot einschliesst solltest du 
dir mal die Zahlen in Binaerschreibweise anschauen. Und versuch mal 
Codesequenzen zu finden die sich moeglichst wenig unterscheiden. Damit 
koennte man weiterkommen.

Olaf

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ihr habt den Quellcode vom Steuerungsprogramm und versucht die Formel
>aus den gesnifften Daten rauszulesen???
Waaaaaahhh - Durch die Brust ins Auge, weils spannender ist  ....

Autor: Frank Hi (frank77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielen Dank für die Hinweise. Die Codesucherei bringt mich leider an der 
Stelle auch noch nicht weiter. Für mich sieht es Stand heute so aus, 
dass der Quellcode nur in Ansätzen vorhanden ist. D.h. es gibt jede 
Menge .h-, obj- und Binär-Dateien. Die .h-Dateien sind voll mit 
irgendwelchen Type-Definitionen aber der eigentliche Code liegt nicht 
vor. Aber ein compiliertes Programm mit dem ich die Motoren ansteuern 
kann habe ich gefunden. Vielleicht kann man über einen Dissasembler 
etwas erreichen. Das werde ich in den nächsten Tagen ausprobieren.

Gruß
Frank

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verstehe ich nicht. Wenn obj Dateien da sind, dann hat da mal irgend 
jemand compiliert. Falls nur Schnittstellen mitgegeben werden, reichen 
die Header.

Objects mitzugeben macht normalerweise keinen Sinn, wenn dann libs, 
Shared objects, SOs, etc. .

Sind keine .c oder .cpp verfügbar ?

Nichtsdestotrotz sind auch die h Dateien interessant, da es zumindest 
eine Struktur (typedef struct ...) geben sollte, die den Aufbau der PDUs 
beschreibt.

Nachdem ich Deine Daten mal angeschaut habe, bin ich auch dazu gekommen, 
daß die letzte Gruppe wg. der Nullen sicher kein üblicher CRC Code ist.

Interessant ist allerdings eine ähnliche Gruppe, nämlich die 9E12, 9DBF, 
98BF und vorne die C8BF.

Nachdem die immer an anderen Stellen vorkommt, andererseits die letzte 
Gruppe X00Y immer an einer festen Stelle sitzt, liegt nach erster 
Vermutung ein mindestens zweischichtiges Protokoll vor. Die untere 
Schicht ist für das FF ABCD () X00Y verantwortlich, und der Payload 
beinhaltet die zweite Gruppe.

Ich hoffe mal, daß Dein Sniffer hier nicht noch irgendwas im LOG stehen 
hat und es sich wirklich nur um den reinen Datenverkehr handelt!

Die Frage ist nun, auf welcher Ebene der Prüfwert berechnet wird. Der 
Protokollaufbau sollte aber aus den headern herauszulesen sein.

Weiterhin sollte die Ordnung des Generatorpolynoms sichtbar sein, u.U. 
sogar das Generatorpolynom selbst.

Autor: Frank Hi (frank77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich gehe mal davon aus, daß der Quellcode nicht vollständig zur 
Verfügung steht. Denn die .c* Dateien habe ich ja gesucht und nicht 
gefunden...

Autor: Andreas Lang (andi84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
typischerweise findet man prüfsummen und verschlüsselung, wenn man nach 
XOR operationen sucht ;).

Wenn es die Software in binär gibt, sollte das nicht so wild sein. 
Vielleicht sind sogar noch Symbole (Namen von Funktionen und sowas) 
drin, das hilft auch oft weiter.
Wenn Du unter Unix arbeitest, lass doch mal en Befehl "strings" drauf 
los.
Oder einfach mal "file", das vermag oft zu helfen.

Gruß
Andreas

Autor: Frank Hi (frank77)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hab mal die Datei angehängt mit der ich die Motoren von Hand ansteuern 
kann.
Vielleicht mag sich mal jemand daran versuchen darin etwas zu erkennen. 
Zu diesem Binärcode habe ich aber leider keinen Quellcode.

Autor: Andreas Lang (andi84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

was tut das Ding?
file Desktop/movecell.qnx 
Desktop/movecell.qnx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped
Das ist jedenfalls mal ne i386 Linux/Unix Executable, die leider 
"stripped"
ist, d.h. dass die Debugsymbole raus sind :(.

Ich hab jetz irenwie kein bock das ding auf mein system loszulassen, 
aber da ist wohl nen ASCII interface drin implementiert.
Wie greift das DIng auf deine Motoren zu?
Seriell?
der Text CRC scheint drinne nich vorzukommen.

Gruß
Andreas

Autor: Frank Hi (frank77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Andi,

das mit dem CRC habe ich auch schon geprüft.
Das Teil läuft auf einem QNX 6.2
Du startest es und dann werden die Infos auf eine RS422 rausgeschrieben.
So, viel mehr Anhaltspunkte habe ich leider nicht.
Nächste Woche werde ich nochmal einen Versuch unternehmen, wenn es die 
Zeit erlaubt...

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
IMHO wird im dem movecell binary "XOR" nur zum Nullen des EAX Registers
verwendet. Fuer eine CRC waere eine Verwendung eines XOR
in einer zweioperandenverarbeitenden Verwendung charakterisch.

objdump -d movecell.qnx |grep xor
 804acf7:       31 c0                   xor    %eax,%eax
 804afb6:       31 c0                   xor    %eax,%eax
 804b098:       31 c0                   xor    %eax,%eax
 804b16d:       31 c0                   xor    %eax,%eax
..... usw.

VG,
Hans

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur so als Hinweis, die Prüfsumme könnte auch am Anfang des Paketes 
stehen, und sie könnte auch nur 1 Byte Umfassen, ggf. wird einfach 
aufsummiert?

Interessant sind doch diese Beiden Zeilen:
FF 2500 0000 0000 0000 98BF 0000 0000 0000 0000 B004
FF 2800 0000 0000 0000 98BF 0000 0000 0000 0000 A003
 da sie sich nur wenig unterscheiden, solche würde ich mir aus dem Log 
fischen damit lässt sich dann schon was rausfinden (wenn auch mühsam)

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich nehme eher an, dass die 16Bit-Prüfsumme/CRC als Little Endian 
gesendet wird, wie das ja bei den meisten Prozessoren im Speicher auch 
üblich ist. Die gesnifften Prüfsummen sind also 0280,02C0,02A0,04B0 und 
03A0. Das erscheint mir auch viel plausibler. Nicht nur das, ich bin das 
eigentlich auch so gewöhnt, Multibyte-Zahlen rückwärts zu lesen.

Gruss Reinhard

Autor: Andreas Lang (andi84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich gehe eigentlich davon aus, dass das Programm oben eine externe 
Bibliothek nutzt. Vermutlich dürfte das Ding was mit "qnxobj" heißen.
Jedenfalls sieht es stark danach aus, dass das Ding einen tiefer 
liegenden Treiber / eine tiefer liegende Bibliothek nutzt, um die 
MessageObjects zu generieren.
Jedenfalls sehe ich in dem Programm keinen Code zur seriellen 
Kommunikation.
Das Zielsystem ist ja ein Unix/Linux auf 386 oder kompatibel,
da müssten Bibliotheken ja in /lib oder /usr/lib liegen. Bitte mal da 
nach was mit qnx oder mbx suchen. Da wird dann wohl auch der Zauber drin 
passieren und so Dinger haben dann typischerweise auch exportierte 
Symbolnamen, die einem was verraten können.

Gruß
Andreas

Autor: Frank Hi (frank77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend zusammen,

da sind doch schon wieder tolle Ansätze dabei. Werde morgen mich dem 
Thema Little Endian und qnxobj-Dateien annehmen. Vielleicht kann man da 
wirklich etwas finden.

Vielen Dank für die Unterstützung.
Ich werde entsprechendes Feedback geben.

Gruß Frank

Autor: Frank Hi (frank77)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

den Verweis auf die qnxobj habe ich mal näher verfolgt und bin nach 
längerer Suche auf .c und .h Dateien gestossen (gepackt in einem anderen 
Ordner).
Ich habe einen Teil mal im Anhang beigefügt.
Dabei habe ich auch den Quellcode zu movecell gefunden. Vielleicht 
kommen wir an dem Punkt weiter. Bin ich richtig, wenn ich vermute, die 
Funktionen set_move und send_mess aus den Dateien movecell.c und 
message.c könnten der Schlüssel zum Erfolg sein?


Gruß Frank

Autor: Frank Hi (frank77)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

weitere Erkenntnisse unserer Meinung nach sind:

movecell.c  - set_move(int n_cell) initiiert das Senden des Pakets über 
den Aufruf von 
celcmd_reservation(n_cell,direction,delay_move,profile,(USHORT)DEV_CHUTE 
)

utilsc.c  - Defintition von celcmd_reservation(), welche einen Aurfuf 
von SEND_MES(CELLACT,MS_CELLACT_SET,s_id_token_mbx_ccmgm.id) startet

xblib.h    - Hinweis auf Definition von SEND_MES() -> message.c

message.c  - Definition der Funktion send_mes(), ruft 
mbx_data_send(mbx,message, (USHORT)(sizeof(S_header_mes)+l_mes)) auf

qnxobj.c  - Defintion der Funktion mbx_data_send() mit anschließendem 
Absenden des Pakets

Vermutung: (USHORT)(sizeof(S_header_mes)+l_mes) bildet die gesuchte 
Summe

An dieser Stelle haben wir jetzt bei der Interpretation ein paar 
Probleme. Vielleicht hat jemand einen Ansatz wie es hier weitergehen 
könnte?

viele Grüße
Frank

Autor: Frank Hi (frank77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

hat noch jemand eine Idee wie wir hier weiterkommen können?

Gruß und schönes Wochenende
Frank

Autor: nerv (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem ist der ganze Kram ist stark undurchsichtig (u.a. weil doch 
recht lang) und die wenigsten hier haben Lust für lau(!) ihre Zeit damit 
zu verbringen...

Hast du noch andere .c oder .h gefunden? Gibt es Doku? Was macht das 
System GENAU? Das "Ding" scheint doch eine Menge zu können, entsprechend 
undurchsichtig ist der Code (zumindestens auf den ersten Blick).

>schönes Wochenende
Ebenfalls.

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.