Witam wszystkich, myślę, że to mój pierwszy post tutaj.
Wielkie podziękowania dla brottaastera i boyak75 za ich badania!
Podobnie jak t161, wypróbowałem łatki boyak75 na FW 120 i działają OK: Nie wykrywa mojego fałszywego numeru seryjnego (eZn6IX2r) jako takiego (1. łatka) i akceptuje dowolny losowy kod aktywacyjny (2. łatka).
Próbowałem też tylko pierwszego patcha, a potem aktywowałem go kodem wygenerowanym przez jego generację kluczy (8CED) i też zadziałało.
Ale w obu przypadkach problem pozostaje: za każdym razem, gdy ponownie uruchamiam oscyloskop, muszę ponownie wprowadzić kod odblokowujący (losowo, jeśli zastosowano dwie łatki lub 8CED, jeśli zastosowano tylko pierwszą). Wygląda na to, że rzekomy bit odblokowujący w EEPROM, o którym wspominał brottoaster w jego ostatnim poście, nie jest poprawnie ustawiony...
Mając ten pomysł na uwadze spróbowałem też odczytać EEPROM, ale podobno jest pusty (swoją drogą spróbowałem też w odblokowanym oryginalnym DSO138mini, który mam z tymi samymi wynikami), więc pomyślałem, że albo nie czytam OK (Używam programatora CH341A z EEPROM-em wylutowanym z oscyloskopów i działa dobrze z innymi EEPROM-ami 24LCXX, więc nie sądzę, że to jest problem), a może rzekomy bit odblokowujący nie był tam przechowywany.
Z tego, co znalazłem, EEPROM w DSO150 i DSO138mini nie jest prostym EEPROMem, ale czymś w rodzaju urządzenia Microchip ATSHA204A CryptoAuthentication, które oprócz EEPROM I2C zawiera unikalny numer seryjny i inne funkcje uwierzytelniające, więc nie jest dziwny, że czyta pusty ze standardowym czytnikiem EEPROM.
Z tego, co wyczytałem na tym i innych forach, oprogramowanie układowe używa bajtów opcji STM32 (konkretnie WDG_SW) do zamurowania zakresu po wykryciu fałszywego numeru seryjnego (na szczęście łatwo go usunąć za pomocą narzędzia programistycznego!), więc Pomyślałem, że te bajty opcji mogą być również używane do przechowywania unikającego ,,bitu odblokowującego" i... BINGO!, udało mi się zauważyć, że tak zwane ,,bajty opcji przechowywania danych użytkownika" zmieniają się po zakończeniu procesu wprowadzania kodu odblokowującego. Co więcej, zawartość tych bajtów pokrywa się z danymi szesnastkowym, które pojawiają się w prawym górnym rogu ekranu podczas procesu uruchamiania (najpierw LSB), ale nie z kodem odblokowującym. W moim przypadku "Bajty opcji przechowywania danych użytkownika" to 0x0F (Data 0) i 0x8D (Data1), liczba w lewym górnym ekranie to 8D0F, a kod odblokowujący 8CED i numer seryjny eZn6IX2r, jak już wspomniałem.
Czy ktoś eksperymentował z tym samym problemem (trzeba wejść do menu kodu odblokowującego przy każdym cyklu zasilania)? Czy możesz znaleźć związek między numerem seryjnym a numerem zaprogramowanym w bajtach opcji? Z filmów w Internecie i własnych oscyloskopów udało mi się znaleźć następujące dane (zakres, wersja oprogramowania, pełny nr seryjny 205661, kod odblokowujący -z generatora kluczy-, kod ekranu startowego), ale nie mogę znaleźć żadnego związku :
Mój fałszywy DSO150 FW120 1500000D-002387-eZn6IXZr-161202, 8CED, 8D0F (0x9341)
Moje oryginalne DSO138mini: FW 116, 1380000I-Vm0Qigin, B06F, D56B (0x7789)
Youtuber DSO150: FW 111, 1500000E-106319-bKPU6V7W- 171129, D058, DD50
Youtuber DSO150: FW 120, 1500000E2-210374-km0jG5zr-191015, 717D, 5983
W dwóch pierwszych dołączam również (w nawiasach) inną liczbę, która pojawia się w lewym górnym rogu ekranu rozruchowego, jeśli naciśniesz klawisz OK podczas procesu rozruchu (w tym przypadku zatrzymuje się na tym ekranie). Załączam zdjęcie tego ekranu oraz zrzut ekranu oprogramowania programatora STM32 z opcją bajtów:
