 bisschen Mathematik zum Aufwachen. Der Vortrag ist entstanden aus dem Problem, dass ich eben genau einen Protokollreverse inliniert habe, wie ihr vielleicht aus anderen Vorträgen von mir kennt, das war Iridium. Und wenn man einfach nur auf Daten startet und sagt, da muss doch eine Prüfzumme sein, das sieht doch wie eine Prüfzumme aus, aber ein paar Tunen nicht drauf kommt, wie diese Prüfzumme berechnet wird, weil man möchte ja eventuell doch wissen, wie die Prüfzumme berechnet wird, um zu sehen, ob man das richtig empfangen hat, was man da gerade belauscht. Und ich habe im Internet gesucht, wie man das so tut, wenn man irgendein Problem hat. Vielleicht hat es ja schon jemand für mich gelöst. Das einzige, was ich wirklich gefunden habe, das kommt später in den Slides auch noch mal ganz kurz vor, ein Python-Ding auf GitHub, das CLC-Blootforce heißt, dass letztendlich nichts anderes macht, als man gibt ihm die Daten, sagt hier, glaube ich, dass die CLC ist und dann probiert es einfach mal wild durch und schaut, ob es was Götiges findet. Das ist irgendwie unglaublich uneffizient, dauert im Zweifelsfall irgendwie im Stundenbereich oder zumindest im mehrere Minutenbereich und hat bei mir nichts gefunden, weil es halt, es gibt halt noch gewisse Randbedingungen bei CLCs, die man dann auch noch durchprobieren muss. Und wenn man dann sich irgendwo in den Bits vertan hat, da ist vielleicht ein Bit zu viel oder ein Bit zu wenig, dann funktioniert dieses Tool nicht und dann schaut man in die Röhre. Und dann habe ich irgendwie weiter geguckt und habe eine Seite, die ich nachher auch noch auf der letzten Slide habe von jemand gefunden, der gesagt hat, da geht das, geht mit Mathematik auch. Ich habe aber seine Seite nicht wirklich verstanden. Also das, was er gemacht hat, habe ich versucht, bin nicht zum Erfolg gekommen, habe mir gedacht, das muss aber doch gehen. Ich habe dann halt ein bisschen Wikipedia gelesen und ein bisschen rumprobiert und festgestellt, es ist eigentlich gar nicht so schwierig und mir ist eigentlich unerklärlich, warum das nicht schon irgendwie längst als Text existiert und um mich zu motivieren, das dann irgendwie nachher auch noch auf eine Webseite zu parken, habe ich mir gedacht, ich reich mal schnell den Vortrag ein, damit das dann nachher dokumentiert ist und der nächste, der das Problem hat, das vielleicht etwas leichter hat. Wie viele von euch wissen, was eine CLC ist? Schon sehr viele. Also ihr wisst auch, wie man sie so berechnet. Also grundsätzlich ist es halt eine Prüfsumme, die nur dazu benutzt wird, zu festzustellen, ob die Daten korrekt angekommen ist. Es ist nicht so Fehlerkorrektur gedacht. Also man kann, es gibt noch andere Arten von Prüfsummen, mit denen man einzelne Bitfehler nachher noch korrigieren kann, das kann man mit CLCs in der Regel nicht. Die, ganz schnell für die, die es jetzt vielleicht doch nicht mehr parat haben, wie ich so eine CLC berechne, es gibt ein paar verschiedene Methoden, die billige Methode es einfach zu machen ist. Man nimmt seine Daten und schiebt die Bitweise um eins nach links und immer wenn das Bit, was links rausfällt, nach eins ist, dann X-Ort man das Polinom, also die magische Zahl, die diese CLC berechnet, obendrauf. Und wenn man alle Datenbits rausgeschoben hat, dann ist das, was in dem Register übrig bleibt, die CLC. Ein kleines Beispiel, wenn ich als CLC-Polinom die 7 verwende, also das ist so eine Sache, wie man das CLC-Polinom definiert. Genau genommen ist das CLC-Polinom an der Stelle Hexadecimal 107. Also das oberste Bit, was nicht mehr zur CLC gehört, ist immer 1. Deswegen kann man das natürlich, wenn man darüber spricht, auch einfach noch schnell weglassen. Aber mathematisch gesehen ist es natürlich mit dabei. Jetzt nehme ich meine Hex 42, schiebe die um ein Bit nach links, da habe ich keine 0 rausgeschoben, muss also nichts machen, schiebe es noch mal eins nach links, dann kommt halt 108 raus, dann X-Ore ich meinen Polinom, die 107 drauf, bin bei 0xf und so weiter und das muss ich halt, wenn ich jetzt 8 Datenbits habe, habe ich alle 8 Datenbits rausgeschoben der Reihe nach und komme am Schluss auf meine Prüfsumme, die in dem Fall 0xc9 ist. Soweit alles klar? Wenn man das in der, auf der mathematischen Seite betrachtet, dann rechnet man bei CLCs mit Polinomen über dem Feld GF2, also dem Binärenfeld, wo alle Zahlen nur 0 oder 1 sein kann. Das heißt die Zahl 42 Binär so dargestellt, würde man als Polinom x hoch 6 plus x hoch 1, also das sechste Bit und das esste Bit ist gesetzt, man fängt mal 0 an zu zählen und wenn man zum Beispiel zwei Zahlen addiert, nämlich 42 und 7, dann kann man die als Polinome addieren und dann käme 2x hoch 1 raus und weil das eben über dem Binärenfeld ist, ist 2 auch gleich wieder 0, so wraparoundmäßig und das heißt, das wäre dann 42 plus 7 mathematisch an der Stelle gesprochen ist, 45 und das ist das, was wir als xo erkennen. Nur so als Einführung. Eine CLC selber berechnen ist dann in dieser, was mathematischer Sicht, eine Division. Dazu motiviere ich einfach die Zahl als Polinom durch das CLC-Polinom. Dazu muss ich die Zahl vorher noch so viele Bits nach links schieben, wie das, wie die CLC nachher lang ist und wenn ich das in irgendeinen Computer-Eigepraßystem eintippe oder es auch per Hand mache, dann kann man sich die Wikipedia-Seite anschauen, kommt genau wieder diese Prüfzumme raus. Die paar Effekte, die bei einer CLC auftreten ist, ist, dass wenn ich auf diese Weise eine CLC berechne und vorne an die Nachricht 0 Bits anhänge, dann kommt genau der gleiche Wert raus. Weil wenn ich in meinen 0 Register, wir erinnern uns vor an die Berechnung 0 Bits reinschiebe, dann schiebe ich vorne auch immer 0 Bits raus, dann ändert das nichts an dem Wert. Das heißt, ich kann auf die Weise nicht feststellen, ob vorne an der Nachricht extra 0 Bits dran sind. Der Trick, den man da machen kann, ist man kann die CLC Berechnung anfangen, indem man in dieses Register als Initialwert eben nicht 0 reinschriebt, sondern was anderes, meistens lauter 1 Bits, also minus 1 sozusagen, dann tritt dieser Effekt nicht mehr auf. Aber das ist wie einer dieser Fälle, wo die CLC Berechnung ist eben nicht nur das Polinom, sondern eben auch der Initialwert in dem Register. Der ist meistens entweder 0 oder eben FF, aber man weiß es nicht. Und der zweite Effekt von CLC ist, wenn ich eine CLC mit dem gleichen Polinom berechne über die Message mit der CLC hinten anhängend, dann kommt 0 raus. Weil ich der letzte Schritt im Prinzip ist, die Prüfsumme mit den hineinzurechnen, das geht sich halt, ich will das jetzt nicht detailliert ausführen, geht sich genauso aus, dass 0 ist. Das hat den Effekt, wenn ich in diese Kombination hinten noch 0 Bits anhänge, dann kann ich das wieder nicht feststellen. Also ich kann als CLC Prüfen, als Empfänger, ist die billige Methode eben, ich berechne einfach die CLC über die gesamte eingekommene Nachricht und wenn dann hinten 0 rauskommt, dann bin ich glücklich. Dann kann ich aber nicht feststellen, ob jemand die Nachricht mit 0 wird hinten gepaddet hat, wenn eventuell mein Empfänger irgendwie zu viel empfangen hat. Das kann ich auch wieder machen, indem ich den Schlusswert, den ich aus der CLC Berechnung bekomme, mit irgendwas X Ohre eben wieder mit 0x FF meinetwegen, dann kann ich allerdings nicht mehr diesen Effekt machen, dass ich einfach die CLC Anhänge und die CLC, eine neue CLC über die kombinierte Dingberechnung, sondern muss ich halt wirklich prüfen, ob der Schlusswert genau der richtige Wert ist. Kommen wir zum Reversen. Da ist dieses Brutforce-CRC-Tool, was es auf GitHub gibt. Aufs Auswort? Ich glaube, es gibt es auch auf GitHub. Wie ich vorhin schon erwähnt habe, das dauert alles ein bisschen länger und man muss sich relativ sicher sein, wo man seine CLC anfängt und auch aufhört. Das war für mich nicht so der Hit. Deswegen habe ich mir dann die Mathematik angeschaut. Für die Mathematik brauchen wir zwei Sachen später. Ist aber nicht so wichtig. Wenn ich eine CLC berechne über eine Nachricht, die aus zwei Teilen besteht, kann ich auch die CLC über die erste Hälfte berechnen und die zweite Hälfte mit der CLC X Ohren und darüber wieder die CLC berechnen. Das ist der gleiche Wert. Das benutzen normale CLC-Implementierungen. Wenn ich eine Nachricht habe, die länger als die CLC-Länge ist, wenn ich eine 8-Bit CLC berechne, dann ist meine Prüfung bei Januar 8-Bit und dann kann ich den Status von vorherigen Berechnungen in 8 bethalten und muss nicht immer die ganze Message haben. Wenn ihr in irgendeiner Programmiersprache eine CLC-Implementierung habt, gibt es meistens eine Funktion, die inkrementell CLC berechnet, wo man sagt, jetzt stopfe ich fünf Beide rein und dann schubbe ich nochmal zehn Beide rein und so weiter. Und die funktioniert halt auf diese Weise. Und das zweite ist, CLCs sind linear. In dem Fall ist die X Ohre, also die Addition, die X-Operation ist transitiv. Ich kann die CLC über zwei Messages, die ich miteinander X Ohre berechnen, indem ich einfach die einzelnen Messages CLC berechne und die CLC ist X Ohre. Das ist, als Beispiel habe ich hier halt mal von allen für ein hier unbekanntes Polinom für jedes Bit die CLC berechnet und jetzt will ich halt für die Zahl 42 zum Beispiel die CLC berechnen. Das ist, dann suche ich mir halt die beiden Bits raus, X Ohre, die miteinander und habe meine neue CLC. Das heißt, ich kann, wenn ich eine CLC Reverse engenieren möchte, kann ich im Prinzip mich darum kümmern, dass ich weiß, wie jedes einzelne Bit der Nachricht, was der CLC wert ist und könnte dann die CLC, also diese Prüfzumme einfach berechnen, ohne zu wissen, was das Polinom ist. Ich habe einfach genügend Testnachrichten schicke, die jeweils nur einen Bit gesetzt haben, kann ich daraus meine Prüfzumme berechnen, ohne dass ich das Polinom kennen muss. Was hierbei aber auftritt ist, wenn ich die CLC um ein Bit, also eine berechnete CLC um ein Bit nach links schiebe oder den Input um ein Bit nach links schiebe und davon die CLC berechne. Wenn wir uns erinnern an die billige Methode, wie ich die CLC berechne, dann schiebe ich dieses Register ja um ein Bit nach links und wenn das rausgeschobene Bit eins ist, dann X-ohre ich das Polinom rauf. Das heißt, diese Gleichung, die da oben steht, die ist entweder null für eine CLC oder genau das Polinom. Das heißt, ich kann also meine einzelnen Bits nehmen und jeweils die, in dem Fall die Zeile drüber mal 2 nehmen und auf die CLC der nächsten Zeile drauf rechnen, hier und dann kommt halt hinten raus entweder null oder das Polinom, je nachdem wie der interne Status der CLC an der Stelle ist. Entweder wenn ich ein 1 Bit rausgeschoben habe hinten, dann bekomme ich das Polinom raus und wenn ich ein 0 Bit rausgeschoben habe, dann ist dieses X-ohr halt null. Das heißt, auf diese Weise kann ich, wenn ich für einzelne Bits die CLC-Werte habe, rausfinden, was das Polinom ist. Jetzt kommt der ein bisschen ekelige mathematische Teil, den ich hier ein bisschen sanft drüber hin weggehe. Das funktioniert, also dieses Beispiel hier funktioniert, wenn ich mich am Anfang der CLC befinde. Das heißt, wenn das Register, das was da existiert, vorne null ist, also vorher noch keine Bits in der CLC waren. Wenn da schon Bits drin waren, nämlich in dem Fall eine unbekannte Nachricht P oder ein unbekannter Status P vorne an der Nachricht und ich mache diese gleiche Mathematik, also da habe ich vor zwei Slides gezogen und formen das ein bisschen um. Dann kommt das raus, was ich da in der letzten Zeile habe. Die allerletzte Zeile ist wieder dieses die CLC von X um 1 Bit nach links geschoben, X-ohr mit der CLC von dem Bit um 1 Bit nach links geschoben. Das wird aber noch GX-Ort mit dem Ausdruck, der eine Zeile drüber steht, der aber konstant abhängig ist von dem vorherigen Zustand. Das ist also der Vorteil an der Stelle. Das heißt, es kommt nicht null oder das Polinom raus, sondern eine konstante Zahl GX-Ort mit null oder die konstante Zahl GX-Ort mit dem Polinom. Das ist ja kein Problem. Das heißt, wenn ich in einer CLC mache, wo ich vorher irgendwas Unbekanntes stehen habe, was konstant ist, mache das gleiche Spielchen. X-Ore immer die Zeilen mit dem mal zwei Multiplizierten von der vorherigen Zeile. Dann kommen zwei verschiedene Werte raus. Wenn ich die beiden miteinander X-Ore komme, komme ich dann wieder auf das Polinom, weil ich dann die Konstante fällt raus. Eine Konstante mit sich selbst GX-Ort ist null. Das ist eigentlich schon alles, was man an der Stelle irgendwie wissen muss. Der Teil, der dann vielleicht noch spannend ist, ist, ich kann ja eventuell nicht einzelne Bits in dieser Nachricht selber senden, sondern ich bekomme irgendwelche Nachrichten, die ich gesnift oder was auch immer habe. Ich habe also irgendwie ein Berg von Daten, wo die CLC drauf berechnet ist und will die irgendwie schön auflösen, dass ich da einzelne Bits habe. Was man einfach macht, das ist, wie ich vorher gesagt habe, CLCs sind linear, das heißt, ich kann zwei Zeilen einfach auf X-Oren. Vielleicht erinnert sich da irgendjemand schon dunkel an die Schule. Das ist einfach nur ein lineares Gleichungssystem mit entsprechend vielen Unbekannten, wie viele Bits in dieser Nachricht sind. Das kann man entweder per Hand machen. Das ist sehr, sehr mühsam oder ich nehme einfach irgendein beliebiges Computeralgebra-System. In dem Fall habe ich jetzt Sage genommen, was frei ist und auch unter Linux wunderbar läuft. Und das kann das dann für mich. Dann habe ich ein Beispiel hier für die EH gemacht. Das ist die Art, wie ich das in Sage schreibe. Ich sage halt, ich habe eine Matrix, die gilt über dieses GF2, also dieses binäre Feld und habe halt vorne meine Daten und hinten meine Prüfsummen. In dem Fall sage ich Sage noch mit Subdivide 8, dass er da, wo jetzt hier diese Spaces sind, nachher später eine Linie einzeichnen soll. Die hat aber für die Berechnung keine Auswirkungen und dann sage ich ihm, er soll mir das in Dreiecksform bringen, also für ein lineares Gleichungssystem ums zu lösen. Was Sage dann ausgibt, ist das hier. Da sehen wir, wir hatten genug Informationen in der Eingabe, um jedes Bit einzeln quasi herauszufinden. Die Tatsache, dass da unten eine Zeile mit Null ist, sagt uns, dass wir sogar eine Input-Zeile zu viel hatten. Die hat keine weitere Informationen mehr geliefert. Und damit habe ich für jedes dieser Bits hinten, die jeweils passende CRC. Und wenn man da so mit dem Auge drauf schaut, sieht man schon, dass da eben auch diese Schiff, dieser Schiff mancher Zeilen um ein Bit mehr oder minder reflektiert ist. Und wenn ich dann diese Zeilen einfach rausnehme, mir in Hex-Darstelle dann wieder dieses Spiel mache, die jeweils andere Zeile mit 2 multiplisiert drauf zu X-Oren, dann kommt wieder genau dieser Effekt raus und dann weiß ich, ah, das Polinom für diese Geschichte war in dem Fall 0x131. Das Ganze funktioniert natürlich auch wunderbar für längere CRCs. Also ich habe das jetzt in allen Beispielen nur mit 8 Bit gemacht, weil sonst passt es nicht auf die Slides. Damit ihr seht, dass das nicht nur ein theoretisches Ding ist, noch schnell ein real-welt Beispiel dazu vorführen. Das ist aus eben meinen Iridium Short-Burst-Data-Segments. Das ist jetzt extrem kleiner von... Ich habe hier alle Nullen durch Unterstriche ersetzt, damit man halt auch wirklich sieht, wo da was ist, weil Nullen und Einzen kann man in der Größe nicht mehr sehen. Aber man sieht zumindest in den Daten, die ich empfangen habe, relativ stark, dass da ganz hinten am Ende das wird wohl eine Prüfsumme sein. Also das, was mich zu dem veranlasst hat, dass da wohl eine CRC-Prüfsumme ist. Also der Verdacht war, dass es eine CRC ist, das wussten wir zu dem Zeitpunkt nicht sicher, aber die Chance ist schon relativ hoch an der Stelle. Genau, und das Ganze nimmt man dann und schmeißt es also in passender Formatierung halt ins Sage rein. Und das tut jetzt bei diesem Input-File, dauert 14 Sekunden und dann kommt das raus. Wie man sieht, ist da am rechten Rand noch relativ viel Müll. Das sagt mir, ich habe nicht genug Input gehabt, um wirklich alle Bits aufzulösen. Ich müsste halt noch mehr Input reinwerfen, um das wirklich aufzulösen, also um das komplett zu lösen. Und auch diese Sprünge in den Einsanen sagt mir, dass ich manche Bits einfach gar nicht gesehen habe. In keiner meiner Nachricht, wo die in der Diagonalen die Einzen fehlen, habe ich keine einzige Nachricht gesehen, in der dieses Bit gesetzt ist. Ist aber jetzt nicht so ein Problem, weil wir sehen, es gibt da ein paar Zeilen, die er trotzdem sehr gut auflösen konnte. Für diese Bits da vorne, für diese fünf Bits da oben und dann die zwei und die drei da unten, war jeweils genügend unterschiedlicher Input vorhanden, um die aufzulösen, bis auf den Teil hinten, wo die CRC dann zu sehen ist. Und dann nehmen wir einfach diesen Schnupsel und hier jetzt zur Verteutlichung mal die mittleren Nullen dann rausgeschnitten, weil sonst kann man ja nichts lesen. Da sehen wir auch wieder am rechten Rand dieses Verhalten, dass es da um ein Bit geschiftet wird. Und wir sehen auch, dass da hinten vermutlich noch, also in der Praxis war es so, dass dann eben da hinten immer noch vier Null Bits dran sind, was mit ein Grund ist, warum man mit einem CRC Brutforcer nichts gefunden hat, weil wenn da hinten nochmal leere Null Bits dran sind, dann geht es halt irgendwie schief oder irgendwelche Bits. Und dann schnappe ich mir diese, das sind in dem Fall 16 Bits, das sieht schon mal ganz, ganz plausibel aus. Dann nehme ich diese 16 Bits, schneide ich es mir raus, rechne sie in Hex um, nehme dann halt wieder jeweils die Zahl mal zwei und X Euro sie drauf, dann kommt in der Zahl Null raus, in der Zahl auch Null raus und in der Zahl kommt dann eine Zahl raus. Jö, das ist unser Polinom. Und das stimmt dann auch, das habe ich dann implementiert und das hat dann funktioniert. Ich bin mir jetzt auch nicht ganz sicher, warum ich das mit dem Brutforcer nicht tatsächlich gefunden habe, weil ich war wahrscheinlich auch einfach zu ungeduldig und habe nicht alle Varianten korrekt durchprobiert. Und das ist eigentlich alles, was ich zu dem Thema sagen. Ich habe hier noch ein paar Links. Also das Sage ist ein relativ schnuckeliges Computer Algebra System, die auch eine Web-Oberfläche haben, die cloud.sagemath.com, wo man das Ganze tatsächlich auch einfach live online machen kann, indem man da seinen, zumindest seine Testgrößen, also wenn man hinreichend große Errays da reinwirft, dann ermotzt er dann irgendwann an, dass der Output zu groß ist, sondern muss man irgendwie das Ding umkonfigurieren, dass es einen den Output überhaupt gibt. Das ist ein bisschen mühsam. Wer sich über für die Mathematik interessiert, kann sich auf der Wikipedia nochmal die Details nachlesen. Und die eine Webseite, die mich auf den Gedanken gebracht hat, dass es überhaupt geht, ist die ganz unten. Das ist eigentlich alles. Ein Ding zu der Sage Cloud, muss ich noch sagen. Ich hatte ein Worksheet vorbereitet, dass das auch noch mal live auf der Cloud irgendwie zeigen kann, wie das geht. Leider hat dann irgendwie einen kleinen Schluck auf und stattdessen, statt einem schönen Worksheet gab, hat es mir komische Java, JSON-Bahnen entgegengeworfen, wo in die Teile meines eingetippten Textes drin sind. Deswegen kann ich das jetzt leider nicht zeigen. Ich hatte keine Zeit mehr, das irgendwie zu reparieren. Aber wenn jemand Interesse hat, damit rum zu spielen, ich habe jetzt nur ganz simpel auf meinem Webserver und das muss mir vielleicht auch noch rüberschieben, damit man das sieht. Auf mcp.42.org, slash crc, ein kleines Perlskript hingelegt, dass ein Beispiel generiert, also das ist der Output von ... Hallo? Oh, das Internet. Ja. Okay, also das ist das eine Beispiel, was ich gezeigt habe, wie man das mit Sage macht. Das ist das Perlskript, was das Beispiel generiert. In dem Sage ist dann der Input. Wenn man das dann durch Sage durchlaufen lässt, kommt in Out der Output. Und wenn man aus dem Output den Prüf-Sumentteil rausschneidet, was in dem EH-Punk-Poli drin ist und das durch BIN durch TO-Poli jagt, dann gibt es einem das Polinom aus. Falls jemand keine Lust hat, die Schritte, die ich in den Folien beschrieben habe, irgendwie selber parhand nachzuimplementieren, sind da zwei kleine Skripten. Aber wie gesagt, der Aufwand ist eher gering, das zu tun. Damit wäre ich eigentlich schon fertig. Es gibt ziemliche Fragen. Soll ich noch irgendwas zeigen? Nein, da hinten. Also das war jetzt nur für die Shortburst-Data-Nachrichten und für die ist das immer gleich. Für die Pager habe ich das nicht mit der Methode gemacht. Für die Pager habe ich tatsächlich noch, oder? Ich weiß es gar nicht mehr. Das ist schon so lange her. Ich glaube, bei den Pagers habe ich noch mit Rumprobieren und Brutforce gemacht. Das war auch eine CRC. Die wäre auch so gegangen, nur damals wusste ich das noch nicht. Damals habe ich, glaube ich, noch mit der Methode gemacht, dass wenn man das Polinom korrekt hat und die CRC berechnet über die Nachricht plus das CRC-Prüfzumme, dann soll ja null rauskommen. Und wenn man da irgendwie den initialen Status oder ein paar initiale Bits, die Konstanz, den falsch hat, dann kommt nicht null, aber ein konstanter Wert raus. Auf diese Weise kann man dann schon erahnen, dass man das Polinom zumindest richtig erraten hat. Ich habe damals, glaube ich, mehr selber rumgebrutforst und noch nicht das Internet befragt, wie man das besser macht. Noch andere Fragen? Nein? Ein Moment. Das Problem, das du da beschrieben hast mit den CRCs, für mich wäre die intuitive Lösungsstrategie, die das mit einem SATA oder SMT-Solver zu lösen, zum Beispiel über eine so akkurzartige Präsentierung von dem CRC. Ja, das geht wahrscheinlich auch. Ich würde vermuten, dass es schneller geht, dass diese 14 Sekunden für die Eingaben der Größe, die da gezeigt hat, die Worte wissen, ob du das in Erwägung gezogen hast. Nein, habe ich nicht in Erwägung gezogen. Das war tatsächlich so, dass ich mir den mathematischen Teil so ein bisschen hergeleitet habe und dann gesehen habe, dass ich eigentlich nur die Zeilen miteinander X ohren muss, damit ich auf die einzelnen Bits komme, habe mich dann erinnert, dass ich das in der Schule zum Lösen lineare Gleichungssysteme gemacht habe und mir gedacht, das kann doch ein Computer für mich machen und habe dann genau den Ansatz genommen. Wahrscheinlich könnte ich das mit einem SATA-Solver auch machen. Ich muss allerdings zugeben, obwohl ich schon mehrfach davon gehört habe, da habe ich noch nie etwas mit einem SATA-Solver gemacht und deswegen war das nicht mein erster Gedanke an der Stelle. Das würde aber wahrscheinlich auch gehen. Aber so hat man meinen dafür halt ein bisschen mehr Verständnis, der für was da passiert. Ja. Anzeichen der CRC von irgendeinem Error-Correction-Code was zu unterscheiden? Also die Methode, das auf die Bits aufzulösen, funktioniert bei allen Prüfsummen, die linear sind. Also theoretisch kann ich mir vorstellen, eine Prüfsumme zu haben, die linear ist aber keine CRC. Dann würde bei dem letzten Schritt, den wir gemacht haben, das Polinom zu bestimmen, Quark rauskommen. Könntest du einfach mit der Matrix, der Bits trotzdem diese Prüfsumme berechnen. Mir ist allerdings das bisher nicht untergekommen, mir fällt auch ad hoc nichts ein, dass das tut. Ich wollte das mal für BCH Prüfsummen probieren, weil ich mir nicht sicher bin, ob die auch linear sind oder nicht. Hat er aber nicht nur die Zeit, das auszuprobieren. Du würdest halt letztendlich sehen, dass das bei dem, wenn ich das in Sage reinschmeiße und in die 3x Form bekomme, dass dann hinten völliger Quark rauskommt. Also wenn ich diese Schiftaparation mache, um dann das Polinom zu bestimmen und da kommt zwischen jedem Zeile was anderes raus, dann ist es, dann ist irgendwas faul. Dann ist es möglicherweise keine CRC oder können das keine lineare Prüfsumme. mcp.42.org slash crc. Okay, noch irgendwelche Fragen. Okay, dann danke ich euch allen.