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
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.
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
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
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)
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
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)
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
>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)...
PS: Wenn es wirklich CRC ist könnte es sich doch um eine CRC16 mit 2 eingefügten Nullen handeln (warum auch immer...)
>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.
Wer sagt denn überhaupt daßßß es CRC sein muß? Evtl. wird das Wetter oder irgendwas zur Prüfung kodiert?
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.
Ihr habt den Quellcode vom Steuerungsprogramm und versucht die Formel aus den gesnifften Daten rauszulesen???
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
> 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
>Ihr habt den Quellcode vom Steuerungsprogramm und versucht die Formel >aus den gesnifften Daten rauszulesen??? Waaaaaahhh - Durch die Brust ins Auge, weils spannender ist ....
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
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.
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...
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
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.
Moin, was tut das Ding?
1 | file Desktop/movecell.qnx |
2 | 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
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...
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
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:
1 | FF 2500 0000 0000 0000 98BF 0000 0000 0000 0000 B004 |
2 | 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)
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
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
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
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
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
Hallo zusammen, hat noch jemand eine Idee wie wir hier weiterkommen können? Gruß und schönes Wochenende Frank
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.