Hallo zusammen!
Ich versuche schon seit geraumer Zeit, einen mir unbekannten Algorithmus
zur Berechnung einer Checksumme über einen 512 byte großen EEPROM
Bereich zu finden.
Es geht dabei um RFID Chips von Philips/NXP, wie sie häufig in
Funkschlüsseln verwendet werden. Als Beispiel habe ich hier einen
PCF7961.
Ich habe die Möglichkeit, beliebige Daten auf das EEPROM zu schreiben
und die zugehörige 24 byte lange Checksumme vom Chip auszulesen.
Eine Doku zum benutzten Algorithmus konnte ich leider nirgends finden.
Im Anhang sind einige EEPROM dumps, in denen ich hauptsächlich den Wert
eines Bytes verändert habe. Die resultierende Checksumme sieht man am
Ende des Dateinamens jeder Datei.
Ist hier jemand dabei, der mir helfen kann den zugrunde liegenden
Algorithmus zu finden? Auch die Vorgehensweise für so eine Aufgabe wäre
für mich (und sicher auch einige andere hier) sehr interessant.
Mir selbst fehlt leider das nötige mathematische Verständnis, um solch
eine Aufgabe anzugehen.
Vielen Dank schonmal für zielführende Hilfestellungen.
Gruß,
Philipp
Eigentlich so ziemlich unmöglich. Du musst an den Algorithmus
herankommen. Den kannst du dann im Disassembler begutachten, wobei er
auch direkt in Hardware "gegossen" sein kann.
Google Suche ergibt https://hackaday.com/tag/mifareclassic/ :D
> Ich versuche [..], einen mir unbekannten Algorithmus zur Berechnung> einer Checksumme über einen 512 byte großen EEPROM Bereich zu finden.
Wozu? Du hast doch ein Orakel:
> Ich habe die Möglichkeit, beliebige Daten auf das EEPROM zu schreiben> und die zugehörige 24 byte lange Checksumme vom Chip auszulesen.
Blob generieren, ans Orakel geben, Prüfsumme zurücklesen, adäquat
ablegen, feddisch.
HTH
Wenn du hinreichend viele Codes mit korrekter Prüfsumme hast, liefert
evtl. eine Statistik-Software über den Versuch einer Regression einen
Hinweis ...
Alexander schrieb:> Warum postet man sowas in Fahrzeugelektronik
Weil es der Funkschlüssel für ein Fahrzeug ist.
Wäre es der Funkschlüssel für's Haus --> Haus & Smart Home
Und wäre es der Funkschlüssel der Berufsschule --> Ausbildund & Beruf
Dieter schrieb:> Es gibt verschiedene Tools, die helfen können den Algorithmus> einer> unbekannte CRC zu finden, z.B. CRC RevEng:>> https://github.com/berney/reveng
Habe mit diesem Tool schon ein paar CRC-24 Algorithmen durchprobiert.
Leider ohne Erfolg. Kann aber nicht ausschließen dass ich das Tool
falsch bedient habe. Vielleicht hat jemand von euch mehr Erfahrung damit
und kann es mal ausprobieren?
g457 schrieb:> Blob generieren, ans Orakel geben, Prüfsumme zurücklesen, adäquat> ablegen, feddisch.
Dann bräuchte ich ja immer den Funkchip. Mein Ziel ist es aber, die
Prüfsumme auch offline berechnen zu können. Nach dem Flashen des Chips
lese ich dann die Prüfsumme aus und kann so prüfen, ob die Daten richtig
geschrieben wurden.
Frank E. schrieb:> Wenn du hinreichend viele Codes mit korrekter Prüfsumme hast, liefert> evtl. eine Statistik-Software über den Versuch einer Regression einen> Hinweis ...
Könntest du mir dabei eine Hilfestellung geben? Ich habe keine Ahnung wo
ich da ansetzen kann. Im Internet hab ich auch keinen Hinweis darauf
gefunden.
Alexander schrieb:> Warum postet man sowas in Fahrzeugelektronik und nicht in> Programmierung? Was hat Reverse Engineering mit Elektronik oder KFZ zu> tun?
Genau, es geht um einen Funkschlüssel für ein Auto. Mit
PC-Programmierung hat das also nichts zu tun.
Philipp schrieb:>> Habe mit diesem Tool schon ein paar CRC-24 Algorithmen durchprobiert.> Leider ohne Erfolg. Kann aber nicht ausschließen dass ich das Tool> falsch bedient habe. Vielleicht hat jemand von euch mehr Erfahrung damit> und kann es mal ausprobieren?
CRC RevEng hat eine Option um alle möglichen Polynome einer bestimmten
CRC Länge durchzuprobieren. Es gibt eine umfangreiche Doku für das Tool,
die erklärt das recht gut. Ich habe das hier mal auf die Schnelle mit
ein paar von den obigen Dateinen ausprobiert, bei 24-Bit dauert es ja
nicht lange. Allerdings wurde kein passendes CRC Polynom gefunden.
Falls die Dateien keine Fehler enthalten und die angegebene CRC stimmt
gibt es mehrere Möglichkeiten warum kein CRC-24 Polynom gefunden wurde,
z.B. die beiden folgenden:
1.) Die CRC wird nicht über die gesamten 512 Byte der Datei berechnet.
Mich wundern u.a. die vier Byte "MIKR" am Anfang jeder Datei, das ist
das Default Passwort einiger NFC Tags (u.a. HITAG). Die Länge muss
passen sonst funktioniert es nicht. Wenn also z.B. die vier Byte am
Anfang nicht für die CRC Berechnung verwendet werden dann dürfen diese
auch nicht an CRC RevEng übergeben werden. Ähnlich sieht es mit den
Bytes am Ende der Dateien aus.
2.) Es ist keine CRC sondern irgendetwas anderes. Es gibt unzählige
Möglichkeiten eine "Prüsumme" zu berechnen nicht nur einfache Summen
oder CRCs. Es könnten z.B. auch ein paar Byte eines Hash sein (auch
ein Secure-Hash mit geheimen Schlüssel ist denkbar).
Woher weisst Du dass es eine CRC ist? Kannst Du das Datenblatt für
den Chip hier posten bzw. eine Link dazu angeben? Also nicht für den
PCF7961 sondern konkret für den EEPROM den Du verwendest.
Philipp schrieb:> Genau, es geht um einen Funkschlüssel für ein Auto. Mit> PC-Programmierung hat das also nichts zu tun.
Ach eure CRC RevEng Tools laufen auf dem Bordcomputer vom Auto? Cool...
Dieter schrieb:> Philipp schrieb:>>>> Habe mit diesem Tool schon ein paar CRC-24 Algorithmen durchprobiert.>> Leider ohne Erfolg. Kann aber nicht ausschließen dass ich das Tool>> falsch bedient habe. Vielleicht hat jemand von euch mehr Erfahrung damit>> und kann es mal ausprobieren?>> CRC RevEng hat eine Option um alle möglichen Polynome einer bestimmten> CRC Länge durchzuprobieren. Es gibt eine umfangreiche Doku für das Tool,> die erklärt das recht gut. Ich habe das hier mal auf die Schnelle mit> ein paar von den obigen Dateinen ausprobiert, bei 24-Bit dauert es ja> nicht lange. Allerdings wurde kein passendes CRC Polynom gefunden.>> Falls die Dateien keine Fehler enthalten und die angegebene CRC stimmt> gibt es mehrere Möglichkeiten warum kein CRC-24 Polynom gefunden wurde,> z.B. die beiden folgenden:
Erstmal vielen Dank für deine Antwort! Find ich wirklich klasse dass du
es selbst mal mit reveng ausprobiert hast!
> 1.) Die CRC wird nicht über die gesamten 512 Byte der Datei berechnet.> Mich wundern u.a. die vier Byte "MIKR" am Anfang jeder Datei, das ist> das Default Passwort einiger NFC Tags (u.a. HITAG). Die Länge muss> passen sonst funktioniert es nicht. Wenn also z.B. die vier Byte am> Anfang nicht für die CRC Berechnung verwendet werden dann dürfen diese> auch nicht an CRC RevEng übergeben werden. Ähnlich sieht es mit den> Bytes am Ende der Dateien aus.
Die ersten 4 bytes sind eigentlich die ID des chips. Da ich meine
Versuche immer mit dem selben Schlüsseln gemacht habe, ist diese immer
gleich. Seltsam ist allerdings, dass diese "MIKR" lautet. Das ist
eigentlich - wie von dir bereits festgestellt - das standard passwort
für alle PCF79xx chips.
Weiterhin gibt es am Ende noch einen 8 byte langen "Spezialbereich". In
diesem stehen Konfigurationen für den Chip, die teilweise nur OTP bei
der Produktion geschrieben werden, teilweise auch nur mit speziellen
befehlen programmiert werden können.
Könntest du es vielleicht nochmal die CRC24 berechnen und die ersten 4
und letzten 8 bytes ausblenden?
> 2.) Es ist keine CRC sondern irgendetwas anderes. Es gibt unzählige> Möglichkeiten eine "Prüsumme" zu berechnen nicht nur einfache Summen> oder CRCs. Es könnten z.B. auch ein paar Byte eines Hash sein (auch> ein Secure-Hash mit geheimen Schlüssel ist denkbar).>> Woher weisst Du dass es eine CRC ist? Kannst Du das Datenblatt für> den Chip hier posten bzw. eine Link dazu angeben? Also nicht für den> PCF7961 sondern konkret für den EEPROM den Du verwendest.
Ich weiß überhaupt nicht dass es eine CRC ist. Im Datenblatt wird immer
nur von einer "Signature" gesprochen. CRC ist aber das einzige das ich
kenne ;-)
Bei diesem Speicherbereich handelt es sich um das interne EEPROM des
PCF7961 Chips. Es gibt also kein extra Datenblatt für das EEPROM.
Leider schweigt sich das PCF7961 Manual komplett über diese Signatur
aus. Einzig und alleine in der Doku der Programmierschnittstelle wird
sie erwähnt. Dort werden aber auch nur die Befehle zum Auslesen
beschrieben. Es gibt keine Details zur Signatur selber.
Alexander schrieb:> Philipp schrieb:>> Genau, es geht um einen Funkschlüssel für ein Auto. Mit>> PC-Programmierung hat das also nichts zu tun.>> Ach eure CRC RevEng Tools laufen auf dem Bordcomputer vom Auto? Cool...
Natürlich nicht ;-)
Aber es geht ja nicht darum, das reveng Tool nachzuprogrammieren (das
wäre PC-Programmierung), sondern es wird einfach nur benutzt.
Philipp schrieb:>> Könntest du es vielleicht nochmal die CRC24 berechnen und die ersten 4> und letzten 8 bytes ausblenden?
Das ändert nichts am Ergebnis, CRC RevEng findet kein passendes
Polynom. Ich habe übrigens zur Sicherheit dass ich keinen Fehler
gemacht habe auch mal einen bekannten CRC-24 Algorithmus ausprobiert,
in diesem Fall gibt es ein Ergebnis.
> Bei diesem Speicherbereich handelt es sich um das interne EEPROM des> PCF7961 Chips. Es gibt also kein extra Datenblatt für das EEPROM.> Leider schweigt sich das PCF7961 Manual komplett über diese Signatur> aus. Einzig und alleine in der Doku der Programmierschnittstelle wird> sie erwähnt. Dort werden aber auch nur die Befehle zum Auslesen> beschrieben. Es gibt keine Details zur Signatur selber.
"Signatur" klingt erst mal nicht nach CRC. Gibt es denn einen
Hinweis für was diese Signatur verwendet werden kann?
Dieter schrieb:> Philipp schrieb:>>>> Könntest du es vielleicht nochmal die CRC24 berechnen und die ersten 4>> und letzten 8 bytes ausblenden?>> Das ändert nichts am Ergebnis, CRC RevEng findet kein passendes> Polynom. Ich habe übrigens zur Sicherheit dass ich keinen Fehler> gemacht habe auch mal einen bekannten CRC-24 Algorithmus ausprobiert,> in diesem Fall gibt es ein Ergebnis.>>> Bei diesem Speicherbereich handelt es sich um das interne EEPROM des>> PCF7961 Chips. Es gibt also kein extra Datenblatt für das EEPROM.>> Leider schweigt sich das PCF7961 Manual komplett über diese Signatur>> aus. Einzig und alleine in der Doku der Programmierschnittstelle wird>> sie erwähnt. Dort werden aber auch nur die Befehle zum Auslesen>> beschrieben. Es gibt keine Details zur Signatur selber.>> "Signatur" klingt erst mal nicht nach CRC. Gibt es denn einen> Hinweis für was diese Signatur verwendet werden kann?
Ok, vielen Dank!
Ich habe gerade nochmal einen Test gemacht: Nach Verändern der letzten
beiden Bytes hat sich auch die Checksumme geändert. Das lässt vermuten
dass zumindest der Block am Ende auch in die Signaturberechnung
einfließt.
Ich denke die Signatur wird nur dazu verwendet, um den Speicherinhalt
nach dem Programmieren zu prüfen.
Gerade habe ich doch ein Muster gefunden:
Verändert wurde nur das letzte EEPROM byte.
Byte 512 Signatur
AE (= 0x75 bit-invertiert) --> FD4D1F
6E (= 0x76 bit-invertiert) --> FD4E1F
EE (= 0x77 bit-invertiert) --> FD4F1F
Kann man daraus irgendwas schließen?
Philipp schrieb:>> Kann man daraus irgendwas schließen?
Das schaut nicht nach einer CRC aus, da würde sich mehr ändern.
Kommst Du an die Firmware des Chip? Dann könnte man schauen wie
die Signatur berechnet wird (falls es nicht durch Hardware passiert).
Dieter schrieb:> Philipp schrieb:>>>> Kann man daraus irgendwas schließen?>> Das schaut nicht nach einer CRC aus, da würde sich mehr ändern.>> Kommst Du an die Firmware des Chip? Dann könnte man schauen wie> die Signatur berechnet wird (falls es nicht durch Hardware passiert).
Ich komme leide nur an den "User"-Flash. Die Signatur wird aber im ROM
berechnet, da habe ich leider keinen Zugriff.
