Oszilloskop DSO150 Firmware - This board is FAKE!

Hallo boyak75,

Vielen Dank für Ihr Feedback!

Vielleicht ist das EEPROM wirklich weg. Ich habe mehrere Experimente sowohl mit DSO150 (gefälscht) als auch mit DSO138mini (echt) durchgeführt, von denen einige den Umtausch des EEPROM zwischen ihnen beinhalteten, um zu sehen, ob ich auf diese Weise die 150 "echt" machen könnte und die FW aktualisieren, und vielleicht habe ich sie in einem dieser Experimente kaputtgemacht. Oder vielleicht auch nicht, weil ich ein billiges CH341-Lesegerät verwende und dies die Ursache dafür sein könnte, dass ich es nicht lesen kann. Aber Brottoaster konnte es auch nicht lesen (oder leer lesen), also ist es vielleicht auch wirklich so.

Auf der anderen Seite, selbst wenn es sich nicht an den Entsperrvorgang erinnert, scheint es sich an andere Einstellungen (Zeitbasis, Volt/Div) zu erinnern, also werden diese und andere Daten möglicherweise eher im internen EEPROM von STM als im externen gespeichert, und der externe dient nur den Funktionen des CryptoAuthentication-Geräts, da die Seriennummer gespeichert wird (aber nicht im Standard-I2C-EEPROM-Speicherplatz).

Ich denke darüber nach, ein einfaches Programm für das STM zu erstellen, um das EEPROM zu lesen, ohne dass ein externer Programmierer erforderlich ist oder sogar verwendet wird diese Bibliothek um die Sonderregister des ATSHA204A oder eines ähnlichen CryptoAuthentication-Geräts vollständig zu lesen. Ich bin nicht sehr begabt im Programmieren von Mikrocontrollern, aber mit etwas Glück reicht vielleicht ein bisschen Modifizieren der Beispiele aus der Bibliothek. Vielleicht kannst du das Projekt für gewisse Zeit lassen und es auf diese Weise versuchen, aber ich werde es auch versuchen.

Nochmals vielen Dank und ich hoffe, wir können einige Fortschritte machen, hauptsächlich aus Neugier und zum Lernen (oder einfach nur so ), da ich in der Praxis das Oszilloskop so verwenden kann, wie er ist, einfach das Aktivierungsmenü am Anfang aufrufen oder zur 064-Version zurückkehren oder eine der vielleicht noch besseren Open-Source-FWs verwenden (beim Kauf eines "echten" Oszilloskop gibt es inzwischen gut aussehende Geräte für <200 €).

Deine Beiträge und die von Brottoaster waren die ersten, in denen ich echte Fortschritte beim Hacken dieses Dings finden konnte, nachdem ich vor Jahren in einem russischen Forum einige Beiträge über eine gepatchte 064-Version gefunden hatte (die nicht viele Hinweise darauf enthielten, wie sie gemacht wurden).

Hallo morgan_flint!

Sie können einen Blick in die alte Open Source von JYE https://github.com/JYEtech/DSO-Shell-open-source-version- werfen.
Hier finden Sie die Dateien eeprom.h und .c. Dieser "Treiber" ist eine EEPROM-Emulation. Das bedeutet, dass die Daten im internen MCU-Flash gespeichert werden. Siehe https://www.st.com/resource/en/application_no...2f10x-microcontrollers-stmicroelectronics.pdf

Wir sehen, dass die Idee darin besteht, Änderungen der Variablen inkrementell zu schreiben. Das bedeutet, dass wir nicht alle Variablen auf einmal an die gleiche Stelle im Speicher schreiben.
Nein! Wir schreiben nur Änderungen. Und die Änderungen werden an eine steigende Speicheradresse geschrieben. Diese Methode dient sicherlich dazu, den Verschleiß des EEPROMs zu verhindern.
Dies ist eine halbe Antwort auf Ihre Frage "wo werden die Informationen gespeichert", die ich mit "überall" beantworten möchte.

Werfen wir einen genaueren Blick auf die im EEPROM gespeicherte Datenstruktur.
Die Datenstruktur ist eine 16-Bit-Variablen-ID (virtuelle Adresse), gefolgt von einem 16-Bit-Datenwert, den Sie speichern möchten.
Dies wird als Schlüsselwert bezeichnet und wird sehr oft im Softwaredesign verwendet, um dynamische Daten oder in Kommunikationsprotokollen zu speichern.

So weit... viel Spaß... mein nächster Schritt wird sein, mir die Optionsbytes genauer anzusehen.

Ok, das rechtfertigt (zumindest teilweise), dass das externe I2C-EEPROM leer aussieht.

Ich weiß nicht, warum Jyetech es nicht zum Speichern der Einstellungen verwenden möchte, anstatt des internen Flash, der diese Verschleißprobleme hat.

Wenn man bei Jyetech nachfragt ob man beim Ersetzen des U2 etwas beachten soll, dann bekommt man folgende Antwort:
"Unfortunately the U2 on the main board was used to secure the board against counterfeiting. It must be programmed in our factory to become functional. The firmware won't run without the chip."

@boyak75 vielen Dank mein Freund, dein Patch funktioniert perfekt in meinem chinesischen DSO150!

Hallo
Ich habe ein DSO150 fnirsi Oszilloskop von aliexpress gekauft, aber es funktioniert nicht. Ich habe den STM32-Chip ersetzt, die Software wurde hochgeladen, aber es gab keinen Bildschirm, ich habe es durch den Kauf eines neuen Bildschirms behoben. Jetzt habe ich alle DSO150-Programme im Internet ausprobiert (einschließlich der auf dieser Website beschriebenen), sie bleiben alle auf dem Startbildschirm stehen wie auf dem Bild. Es geht nicht weiter. Wie kann ich dieses Problem lösen? Soweit ich das auf dem Bild verstehe, gibt es eine PID-Kennung am unteren Rand, aber bei mir ist sie beschädigt. Vielen Dank an alle, die helfen können. Ich versuche, als Hobby besser mit Elektronik umzugehen.

Ich habe genau den gleichen Startbildschirm mit dem roten E und verstümmeltem Text unten. Gleiches FNIRSI dso150.
Ich habe weder die MCU geändert, noch irgendwelche Hardware-Modifikationen vorgenommen.

UPDATE: Ich habe schließlich "lnDSO150" installiert, das spezielle Unterstützung für FNIRSI bietet: https://github.com/mean00/lnDSO150

>>19885111

Wenn jemand nach dem Patch für 113-15001-122 sucht, ist er hier. Schön ist das reduzierte Flackern.


[F]

mrsim0ns hat geschrieben:

Wenn jemand nach dem Patch für 113-15001-122 sucht, ist er hier. Schön ist das reduzierte Flackern.

Hallo zusammen, nach langer Zeit.

Ich habe den Patch von mrsim0ns auf FW-Version 122 ausprobiert und er funktioniert genauso gut wie der von boyak75 auf Version 120.

Allerdings bleibt mein früheres Problem bestehen: Ich muss den Aktivierungscode jedes Mal eingeben, wenn ich einschalte, egal ob ich beide Patches anwende (zufälliger Aktivierungscode) oder nur den gefälschten Seriennummer-Erkennungspatch („guter“ Aktivierungscode aus dem Keygen von Boyak75). Mir ist auch aufgefallen, dass ich nach der Eingabe des Aktivierungscodes nach dem Aus- und Einschalten die Nullpunktkorrektur (V/DIV langes Drücken) erneut anwenden muss, obwohl die Einstellungen (V/DIV, SEC/DIV...) scheinbar stimmen dasselbe vor der Aktivierung (es sieht also so aus, als würde sich das Oszilloskop die Einstellungen merken, sie aber bei der Aktivierung auf die Standardeinstellungen zurücksetzen),

Hat jemand weitergeforscht, wie und wo die Markierung „bereits aktiviert“ gespeichert wird?

Übrigens, falls es für dieses Problem relevant sein könnte, flashe ich die MCU mit dem ST-Link V2-Programmierer und dem STM32 ST-LINK-Dienstprogramm, anstatt mit einem Seriell-zu-USB-Konverter und einer Demonstrator-GUI; Dies ist viel praktischer, da es nicht notwendig ist, BOOT0 und BOOT1 jedes Mal zu überbrücken und wieder aufzuheben.

Hallo,
Ich arbeite schon seit einiger Zeit mit der Firmware und habe die Firmware auch mit Ghidra untersucht und kann Ihnen folgenden Sachverhalt mitteilen. Ab Firmware > 64 werden die Einstellwerte nicht mehr im internen Speicher des STM32 gespeichert, sondern im Chip U2, bei dem es sich nicht um ein Eeprom, sondern um einen Mikrocontroller handelt, der über I2C mit dem STM32 kommuniziert. In Ihrem Fall funktioniert das U2 nicht richtig, da dort auch die Aktivierung gespeichert ist. In Deinem Fall vermute ich, dass bestimmte Speicheradressen im U2 defekt sind. Es trat folgender Effekt auf: Nach der Programmierung mit den Patches 1+2 lief die Firmware auf dem DSO, aber nach einer Weile funktionierte der Encoder nicht mehr. Aus diesem Grund habe ich mit Ghidra die Firmware untersucht und die Stelle gefunden, an der die Einstellwerte einfach auf Null zurückgesetzt werden und der Encoder nicht mehr funktioniert. Seitdem läuft die Firmware 122, ohne dass der Encoder ausfällt. Bis zur Version 64 wurden die Einstellwerte im internen Speicher des STM in einer Art Ringpuffer abgelegt. Ich hoffe, ich konnte dir helfen.

Nach den Patch laufen zwar die neusten Firmware auf den sogenannten Fake Boards, jedoch besteht das Problem insoweit, dass nach einiger Zeit der Encoder nicht mehr funktioniert. (Falls jemand das gleiche Problem hat ich hätte die Lösung). Übrigens der kleine Chip auf dem Board ist kein Eeprom, es handelt sich hierbei um einen Microcontroller der auch über I2C kommuniziert. Ab Version > 64 werden die Einstellwerte nicht mehr im Internen Eeprom gespeichert.

Hinzugefügt nach 3 [Stunden] 33 [Minuten]:

Hinzugefügt nach 59 [Sekunden]:

Hallo,
Ich arbeite schon seit einiger Zeit mit der Firmware und habe die Firmware auch mit Ghidra untersucht und kann Ihnen folgenden Sachverhalt mitteilen. Ab Firmware > 64 werden die Einstellwerte nicht mehr im internen Speicher des STM32 gespeichert, sondern im Chip U2, bei dem es sich nicht um ein Eeprom, sondern um einen Mikrocontroller handelt, der über I2C mit dem STM32 kommuniziert. In Ihrem Fall funktioniert das U2 nicht richtig, da dort auch die Aktivierung gespeichert ist. In Deinem Fall vermute ich, dass bestimmte Speicheradressen im U2 defekt sind. Es trat folgender Effekt auf: Nach der Programmierung mit den Patches 1+2 lief die Firmware auf dem DSO, aber nach einer Weile funktionierte der Encoder nicht mehr. Aus diesem Grund habe ich mit Ghidra die Firmware untersucht und die Stelle gefunden, an der die Einstellwerte einfach auf Null zurückgesetzt werden und der Encoder nicht mehr funktioniert. Seitdem läuft die Firmware 122, ohne dass der Encoder ausfällt. Bis zur Version 64 wurden die Einstellwerte im internen Speicher des STM in einer Art Ringpuffer abgelegt. Ich hoffe, ich konnte dir helfen.

Vielen Dank für Ihre Antwort! Einige Kommentare:

Benutzername hat geschrieben:

Ab Firmware > 64 werden die Einstellwerte nicht mehr im internen Speicher des STM32 gespeichert, sondern im Chip U2, bei dem es sich nicht um ein Eeprom, sondern um einen Mikrocontroller handelt, der über I2C mit dem STM32 kommuniziert

Du hast recht, wie ich schon sagte Hier :

morgan_flint hat geschrieben:

Das EEPROM im DSO150 und DSO138mini ist kein einfaches EEPROM, sondern so etwas wie ein Microchip ATSHA204A CryptoAuthentication-Gerät, das neben einem I2C-EEPROM eine eindeutige Seriennummer und andere Authentifizierungsfunktionen enthält

Es handelt sich nicht um ein normales EEPROM, sondern um etwas Komplizierteres. Ich bin mir nicht sicher, ob es sich im „normalen Gebrauch“ wie ein normales EEPROM verhält und nur dann so ist, wie es wirklich ist, wenn man sich mit den Sonderfunktionen befasst. Dies würde es ermöglichen, dass es bei Fälschungen ordnungsgemäß funktioniert, solange die Firmware die speziellen Funktionen (z. B. Überprüfung von Seriennummern) nicht berücksichtigt.

Benutzername hat geschrieben:

In Ihrem Fall funktioniert das U2 nicht richtig, da dort auch die Aktivierung gespeichert ist. In Deinem Fall vermute ich, dass bestimmte Speicheradressen im U2 defekt sind. Es trat folgender Effekt auf: Nach der Programmierung mit den Patches 1+2 lief die Firmware auf dem DSO, aber nach einer Weile funktionierte der Encoder nicht mehr

Es ist nicht unbedingt so, dass es nach einer Weile nicht mehr funktionierte, sondern dass es nach dem Neustart nicht mehr funktionierte. Wie auch immer, aus dem, was Sie sagen, verstehe ich, dass die Schlussfolgerungen dieselben sein könnten. Es würde auch erklären, warum ich die Nullpunktkorrektur nach dem Neustart und der erneuten Aktivierung neu kalibrieren muss, da diese Einstellung möglicherweise auch im EEPROM gespeichert ist.

Angenommen, mein U2 hat einige fehlerhafte Adressen im EEPROM-Teil: Würde das Gerät ordnungsgemäß funktionieren, wenn ich es gegen ein „normales“ EEPROM eintausche? Oder benötige ich ein echtes „CryptoAuthentication-Gerät“, das auf Anfrage eine Seriennummer meldet?

Wenn letzteres der Fall ist, ist das ein Problem, weil es schwieriger zu finden wäre, aber der Vorteil wäre, dass ich auf die Patches verzichten könnte, da die (vermeintlich eindeutige) Seriennummer nicht auf der Blacklist wäre und ich sie nur müsste Aktivieren Sie mit einem korrekten Code, der mit dem Keygen von @boyak75 generiert wurde.

Dies wirft eine weitere Frage auf: Wie haben es die gefälschten Hersteller geschafft, ihre Klone alle mit denselben Seriennummern herzustellen? Eine Möglichkeit wäre, dass sie einen Mikrocontroller verwenden, um das Verhalten eines echten ATSHA204A CryptoAuthentication-Geräts nachzuahmen, aber ich finde das zu anspruchsvoll ... Was denken Sie?

Hallo,
Ich habe die I2C-Kommunikation zwischen STM32 und U2 aufgezeichnet und ausgewertet und es handelt sich definitiv nicht um ein EEprom. Im Chip steckt eine Logik, die Telegramme auswertet und darauf reagiert. Die Einstellungen werden beispielsweise zyklisch vom STM32 an den U2 übertragen und auch dann gelesen und geschrieben, wenn keine Änderungen an den Einstellungen vorgenommen wurden, d. h. der U2 prüft, ob Änderungen vorgenommen wurden und speichert diese. Da die Typenbezeichnung beim U2 fehlt, ist es schwierig herauszufinden. Wie bereits gesagt, werden bei Version <=64 die Einstellungen im internen Speicher des STM32 gespeichert. Wenn Sie also die neuen Funktionen ab Version 64 nicht benötigen, sollten Sie besser darauf zurückgreifen

Ich füge das Datenblatt von ATSHA204A bei. Ist der von Ihnen analysierte Datenverkehr damit kompatibel?

Nach den Informationen, die ich vor einiger Zeit in mehreren Foren gefunden habe, dürfte es sich hierbei um den Chip mit der Bezeichnung U2 handeln.

Ich habe mehrere Fotos von einem nicht gefälschten DSO150 und DSO138mini (gleiche Philosophie bezüglich des Fälschungsschutzes), auf denen einige Markierungen in U2 sichtbar sind, zum Beispiel das nächste von DSO138mini:


Aber die Suche danach findet nichts, was normal wäre, wenn es sich um einen ATSHA204A handeln würde, wie im Datenblatt steht:

Ich habe mir bereits das Datenblatt des ATSHA204A angeschaut, die Pinbelegung würde passen, die I2C Adresse ist einstellbar (DSO erwartet Adresse h64) der Datenaustausch beginnt auch bei meinen Aufzeichnung mit 0=Reset oder 3=Command was auch dafür sprechen würde. Man müsste sich näher mit diesem Teil beschäftigen, in meinem Fall funktioniert dieser U2 auch ordnungsgemäß so dass ich mich nicht mit dem beschäftigen würde.
Ich habe für Untersuchungszwecke das DSO auf einem Experimentierboard nachgebaut (ohne Analogteil) nur Display und zwei STM32f103 einer von den macht das DSO der andere simuliert den U2 (ohne die Einstellwertespeicherung was aber jetzt auch nicht unbedingt das große Problem wäre). Ist zwar ein wilder Aufbau erfüllt aber seinen Zweck.

Ok, danke für die Info!

Scheint, als würde Ihr Experiment einen neuen Weg eröffnen, dieses Ding zu hacken ... die Simulation von U2 mit einem anderen Mikrocontroller. Aber vielleicht lohnt es sich nicht, zu viel daran zu arbeiten, da mein Fall wahrscheinlich nicht häufig vorkommt und die meisten Leute es mit dem Patch und dem Keygen schaffen.

Ich bin mir nicht sicher, ob ich Ihr Experiment reproduzieren kann, aber wenn Sie den Code für das zweite STM teilen, könnte ich es versuchen! Ich könnte versuchen, den Teil zum Speichern von Einstellungen hinzuzufügen, obwohl ich mir aufgrund meiner begrenzten Programmierfähigkeiten nicht ganz sicher bin, ob mir das gelingt.

Hier ist der Arduino code zur Simulation

Danke!

Ich werde versuchen zu erraten, wie es funktioniert, bin mir aber nicht ganz sicher, ob es gelingt :-(

Ich habe Ihre Beiträge noch einmal gelesen und dazu:

Benutzername hat geschrieben:

Ab Firmware > 64 werden die Einstellwerte nicht mehr im internen Speicher des STM32 gespeichert, sondern im Chip U2, der kein Eeprom, sondern ein Mikrocontroller ist, der über I2C mit dem STM32 kommuniziert. In Ihrem Fall funktioniert das U2 nicht richtig, da dort auch die Aktivierung gespeichert ist. In Ihrem Fall vermute ich, dass bestimmte Speicheradressen in U2 defekt sind

Ihr Setup ließ mich über eine andere Möglichkeit nachdenken, um zu erklären, warum meine nicht richtig funktioniert und jedes Mal eine erneute Aktivierung erfordert: Die gefälschten Hersteller haben das Gleiche getan wie Sie und anstatt ATSHA204A oder ähnliches zu verwenden, haben sie einen Mikrocontroller so programmiert, dass er genau das nachahmt war für U2 in älteren FW-Versionen erforderlich, d. h. es musste eine Seriennummer bereitgestellt, aber nichts gespeichert werden (dies würde auch erklären, warum alle Fälschungen alle diese beiden spezifischen Seriennummern haben), da dies für die von ihnen verwendeten FW-Versionen nicht erforderlich war . Jyetech entdeckte dies und begann, die Speicherfunktionen von ATSHA204A zu nutzen, um der Möglichkeit entgegenzuwirken, die Überprüfung gefälschter Seriennummern zu patchen. Durch Hinzufügen des Speicherteils zur FW des U2-Simulators könnte dieses Problem behoben werden. Ersetzen Sie dann U2 durch einen bekannten Mikrocontroller mit derselben Pinbelegung oder versuchen Sie zu erraten, um welchen es sich handelt ... Zu viel Arbeit für etwas in dieser Preisklasse, aber ich kann mir vorstellen, dass die meisten von uns dies eher aus Spaß als aus echten Gründen tun Gewinn oder Bedarf (Ich habe vor einiger Zeit endlich auch ein "richtiges" Oszilloskop gekauft [url=I finally bought a "real" oscilloscope, also very "hackable"] sehr „hackbar“ [/url] )

Benutzername hat geschrieben:

Nach dem Patch läuft auf den sogenannten Fake-Boards zwar die aktuellste Firmware, das Problem ist jedoch, dass der Encoder nach einiger Zeit nicht mehr funktioniert. (Wenn jemand das gleiche Problem hat, habe ich die Lösung)

Benutzername hat geschrieben:

Aus diesem Grund habe ich mit Ghidra die Firmware untersucht und die Stelle gefunden, an der die Einstellwerte einfach auf Null zurückgesetzt werden und der Encoder nicht mehr funktioniert. Seitdem läuft die Firmware 122, ohne dass der Encoder ausfällt

Ich habe das auch noch einmal gelesen. Ist Ihre Lösung ein weiterer Patch, um dieses Zurücksetzen zu vermeiden? Oder meinst du etwas anderes?

Dank im Voraus!

Hier ist der geänderte Bin-file der das Reset der Einstellwerte verhindert (wenn der Encoder einfriert).
Das Bin-File hat die beiden Patches was zuvor beschrieben wurde, und zusätzlich eine Jump über den Teil der den Encoder sozusagen einfrieren lässt.
Zu Deinem Gedanken, ob der Chip bei den Fake DSO anderer wären, kann ich nur nein sagen es sind überall die gleichen verbaut. Das speichern der Einstellwerte funktioniert ja auch auf den Fakeboards.
Ich glaube eher, dass die DSO in mehreren Fertigungslinien unter Lizenz produziert wurde, irgend jemand hat dann Lizenzrechte verletzt worauf die Entwickler dann die Software angepasst haben. Dies dürfte der Zeitraum der Version 64 gewesen sein.
Vielleicht ist es aber auch eine Marketingstrategie der Chinesen.

Benutzername hat geschrieben:

Die bin-Datei hat die beiden oben beschriebenen Patches, plus einen Sprung über den Teil, der den Encoder einfriert, sozusagen.

Hallo, ich habe gerade deine .bin-Datei ausprobiert, aber leider hat sie das gleiche Verhalten wie die vorherige FW, die ich benutzt habe, V122, die ich selbst nach @mrsim0ns Anweisungen gepatcht habe (d.h., nach der Aktivierung mit einem zufälligen Code und wenn alles gut funktioniert, friert der Encoder nach dem Neustart wieder ein und eine neue Aktivierung ist erforderlich)... bist du sicher, dass du den dritten Patch angewendet hast oder interpretiere ich etwas falsch? Oder vielleicht wird mein vermutlich schlechtes U2 auch für etwas anderes benötigt?

Die bin Datei enthält die Patches
--- 113-15001-122.hex 2023-07-07 16:50:17.000000000 -0700
+++ 113-15001-122-patched.hex 2023-07-07 17:30:24.000000000 -0700
@@ -1634,7 +1634,7 @@
:1066000030B52D4D83B008202C490DF106022C4BDE
:1066100098476A7829781202E878BDF8063042EA8D
:106620000132A978024383F4734342EA011283F0F2
-:10663000A70392B29342ADF8063013D0214C638980
+:10663000A70392B29342ADF8063013D1214C63897F
:106640005A1C022B62810AD80023A28A23812B6064
:106650001D4B42F003022362A28203B030BD1B4BEC
:106660009847F1E71A4B1B4898471B4B98471B4B21
@@ -2983,8 +2983,8 @@
:10BA50000000C8420000C842567070000D0A4A59E2
:10BA6000452054656368204C74642E00566D696EE1
:10BA70003A0000000040674500003E4300003E439E
-:10BA80000D0A44534F205368656C6C00655A6E363E
-:10BA90004958327200743275764779386100000077
+:10BA80000D0A44534F205368656C6C00665A6E363D
+:10BA90004958327200753275764779386100000076
:10BAA00000000000000000004475747900000000F0
:10BAB0000000FFFF01000000000000000000000087
:10BAC000000000000000000000000100FFFF000077

sowie ein Änderung von mir die bei mir das Einfrieren verhindert. Bei mir war es so, wenn ich nur diese Patches anwende läuft das DSO einige Zeit gut, aber nach einiger Zeit (Tage oder Wochen) kommt es vor, dass der Encoder nicht mehr geht, die Einstellwerte können dann nicht mehr geändert werden, auch nicht nach Neustart. Deshalb habe ich das untersucht und die Stelle gefunden, die bei mir Probleme macht. Ich habe den Assemblercode so geändert, dass absolut über diesen Punkt gesprungen wird. Ich denke bei Dir liegt das Problem am defekten U2.
Was meintest Du mit Patch 3 ? oder meinst Du die drei Zeilen ?

Benutzername hat geschrieben:

Was meinten Sie mit Patch 3 ? oder meinen Sie die drei Zeilen ?

Mit "dritter Patch" meinte ich den, den du zu den beiden von @mrsim0ns vorgeschlagenen Patches hinzugefügt hast hier , aber ich muss dich wohl falsch interpretiert haben, denn ich dachte, dieser Patch würde das Einfrieren des Encoders in meinem Fall verhindern (und die Notwendigkeit, den Aktivierungscode erneut einzugeben), aber ich sehe jetzt, dass du ein langfristiges Einfrieren meintest, nicht meinen Fall.

Wenn mein Problem ein defektes U2 ist, wäre die einzige Lösung, wieder das interne Flash zu verwenden (wie vor V64), aber ich verstehe, dass das mit einem Patch nicht zu erreichen ist.

Auf jeden Fall werde ich aus reiner Neugierde versuchen wieder den U2 zwischen meinem gefälschten DSO150 und meinem echten DSO138mini auszutauschen, um zu sehen was passiert

Hallo schon lange nichts mehr gehört von Dir, hast Du denn den U2 mal getauscht ?
Ich habe mich mit dem Crypto Chip ATSHA204A beschäftigt, d.h. ich habe mir den Chip besorgt und etwas mit ihm herumexperimentiert.
Ich kann Dir auch schon im Vorfeld sagen dass es sich bei dem U2 definitiv auch um diesen handelt, leider ist es aus meiner Sicht nicht so einfach möglich diesen so zu beschreiben, dass dieser mit dem DSO funktioniert.
Meine Simulation des U2 mit einem STM32 habe ich nun auch erweitert so dass das Parameter speichern auch funktioniert.

Benutzername hat geschrieben:

Hallo, schon lange nichts mehr von Dir gehört, hast Du die U2 schon getauscht?

Noch nicht, ich habe mit anderen Projekten herumgespielt ... Ich werde es nächste Woche versuchen

Ok, schließlich habe ich den Austausch durchgeführt, ohne Erfolg: Der Einbau eines echten ATSHA204A von einem echten DSO138 mini in meinen gefälschten DSO150 führte dazu, dass der Startbildschirm nicht angezeigt wurde und unleserliche zufällige Zeichen an der Stelle, an der die Seriennummer stehen sollte, zu sehen waren:

Die Bilder entsprechen zwei verschiedenen Einschaltsequenzen, die zweite nach dem Drücken von OK (rotes R änderte sich in gelbes 0x9341)

Nach 8 [Minuten] hinzugefügt:

Benutzername hat geschrieben:

Ich habe nun meine Simulation des U2 um einen STM32 erweitert, sodass auch das Speichern von Parametern funktioniert

Das hatte ich übersehen ... Wäre es möglich, Ihren Code auf einen kleineren Mikrocontroller (ATtiny oder ähnliches) zu portieren, um ihn dort zu installieren, wo U2 ist, wie es der Fälscher getan hat?
Vielleicht mit ein wenig chirurgischem Eingriff, wenn wir keinen mit einer kompatiblen Pinbelegung für Strom- und Datenpins finden ... Wenn ATtiny, Vcc, GNG und SDA zusammenfallen, könnte SCL leicht mit einem dünnen Draht umgeleitet werden, wenn dies der Fall ist Es war nicht möglich, es auf Pin 6 zu konfigurieren: