Hallo zusammen, ich glaube das ist mein erster Beitrag hier.
Vielen Dank an Brottoaster und boyak75 für ihre Recherche!
Wie t161 habe ich boyak75-Patches auf FW 120 ausprobiert und sie funktionieren gut: Es erkennt meine gefälschte Seriennummer (eZn6IX2r) nicht als solche (1. Patch) und akzeptiert jeden zufälligen Aktivierungscode (2. Patch).
Ich habe auch nur den ersten Patch ausprobiert und dann mit dem von seinem Keygen (8CED) generierten Code aktiviert, und es hat auch funktioniert.
Aber in beiden Fällen bleibt ein Problem: Jedes Mal, wenn ich das Oszilloskop neu starte, muss ich den Freischaltcode erneut eingeben (zufällig, wenn zwei Patches angewendet werden, oder 8CED, wenn nur der erste angewendet wurde). Anscheinend ist das von Brottoaster in seinem letzten Beitrag erwähnte angebliche Unlocking-Bit im EEPROM nicht richtig gesetzt.
Mit dieser Idee im Hinterkopf habe ich auch versucht, das EEPROM zu lesen, aber es ist anscheinend leer (übrigens habe ich es auch in einem entsperrten echten DSO138mini versucht, das ich habe, mit den gleichen Ergebnissen), also dachte ich, entweder ich lese es nicht in Ordnung (ich verwende einen CH341A-Programmierer, bei dem das EEPROM von den Oszilloskopen abgelötet ist, und es funktioniert mit anderen 24LCXX-EEPROMs einwandfrei, also glaube ich nicht, dass das das Problem ist), oder vielleicht wurde das angebliche Entsperr-Bit dort nicht gespeichert.
Nach dem, was ich gefunden habe, ist das EEPROM in DSO150 und DSO138mini kein einfaches EEPROM, sondern so etwas wie ein Microchip ATSHA204A CryptoAuthentication-Gerät, das neben einem I2C-EEPROM eine eindeutige Seriennummer und andere Authentifizierungsmerkmale enthält, also ist es nicht seltsam es liest leer mit einem Standard-EEPROM-Leser.
Nach dem, was ich in diesem und anderen Foren gelesen habe, verwendet die Firmware die STM32-Optionsbytes (speziell WDG_SW), um das Oszilloskop zu blocken, wenn eine gefälschte Seriennummer erkannt wird (zum Glück ist es einfach, es mit dem Programmiertool zu entsperren!), also Ich dachte, diese Optionsbytes könnten auch verwendet werden, um das ausweichende "Entsperr-Bit" zu speichern, und... BINGO! Ich konnte feststellen, dass sich die sogenannten "Benutzerdatenspeicheroptionsbytes" ändern, wenn der Einführungsprozess des Entsperrcodes abgeschlossen ist. Außerdem stimmt der Inhalt dieser Bytes mit den Hex-Daten überein, die während des Bootvorgangs in der oberen rechten Ecke des Bildschirms erscheinen (LSB first), aber nicht mit dem Entsperrcode. In meinem Fall sind die "Benutzerdatenspeicheroptionsbytes" 0x0F (Daten 0) und 0x8D (Daten1), die Nummer im oberen linken Bildschirm ist 8D0F und der Freischaltcode 8CED und die Seriennummer eZn6IX2r, wie ich bereits sagte.
Hat jemand mit dem gleichen Problem experimentiert (muss man bei jedem Aus- und Einschalten das Entsperrcodemenü aufrufen)? Können Sie einen Zusammenhang zwischen der Seriennummer und der in den Optionsbytes programmierten Nummer feststellen? Aus Videos im Internet und meinen eigenen Oszilloskopen konnte ich die folgenden Daten finden (Oszilloskope, Firmware-Version, vollständige 205661-Seriennummer, Freischaltcode -vom Keygen-, Bootscreen-Code), aber ich kann keinen Zusammenhang finden:
Mein gefälschter DSO150 FW120 1500000D-002387-eZn6IXZr-161202, 8CED, 8D0F (0x9341)
Mein echter DSO138mini: FW 116, 1380000I-Vm0Qigin, B06F, D56B (0x7789)
Youtubers DSO150: FW 111, 1500000E-106319-bKPU6V7W-171129, D058, DD50
Youtubers DSO150: FW 120, 1500000E2-210374-km0jG5zr-191015, 717D, 5983
In die beiden ersten füge ich (in Klammern) noch eine Zahl ein, die in der oberen linken Ecke des Startbildschirms erscheint, wenn Sie während des Startvorgangs die OK-Taste drücken (in diesem Fall stoppt es bei diesem Bildschirm). Ich hänge ein Foto dieses Bildschirms und einen Screenshot der STM32-Programmiersoftware mit den Optionsbytes an:
