Hello all, I think this is my first post here.
Many thanks to brottoaster and boyak75 for their research!
Like t161, I've tried boyak75 patches on FW 120 and they work OK: It doesn't detect my fake serial (eZn6IX2r) as such (1st patch) and accepts any random activation code (2nd patch).
I've also tried the first patch only and then activating with the code generated by his keygen (8CED), and it also worked.
But, in both cases, a problem remains: Every time I restart the scope I have to introduce the unlocking code again (random if two patches are applied or 8CED if only the first one was applied). It seems like the supposed unlocking bit in the EEPROM mentioned by brottoaster in his last post is not correctly set...
With this idea in mind, I also tried to read the EEPROM, but it's apparently empty (by the way, also tried it in an unlocked genuine DSO138mini that I have with the same results), so I thought either I was not reading it OK (I'm using a CH341A programmer with the EEPROM unsoldered from the scopes, and it works OK with other 24LCXX EEPROMs, so I don't think that's the problem), or, maybe, the supposed unlocking bit wasn't stored there.
From what I've found, the EEPROM in DSO150 and DSO138mini is not a simple EEPROM but something like a Microchip ATSHA204A CryptoAuthentication device which, apart from an I2C EEPROM, contains a unique serial number and other authentication features, so it's not strange it reads empty with a standard EEPROM reader.
From what I've read in this and other forums, the firmware uses the STM32 option bytes (WDG_SW specifically) to brick the scope when a fake serial number is detected (luckily, it's easy to unbrick it with the programming tool!), so I thought these option bytes might also be used to store the evasive "unlocking bit" and... BINGO!, I could find that the so-called "User data storage option bytes" change when the unlocking code introduction process is completed. Moreover, the content of these bytes coincides with the hex data that appears in the upper right corner of the screen during the boot process (LSB first), but not with the unlocking code. In my case, the "User data storage option bytes" are 0x0F (Data 0) and 0x8D (Data1), the number in the upper left screen is 8D0F and the unlocking code 8CED and serial nº eZn6IX2r, as I said before.
Has anyone experimented the same problem (having to enter the unlock code menu each power cycle)? Can you find any relationship between the serial nº and the number programmed in the option bytes? From videos on the internet and my own scopes, I could find the following data (Scope, firmware version, full 205661-serial nº, unlocking code -from keygen-, boot screen code), but I'm not able to find any relationship:
My fake DSO150 FW120 1500000D-002387-eZn6IXZr-161202, 8CED, 8D0F (0x9341)
My genuine DSO138mini: FW 116, 1380000I-Vm0Qigin, B06F, D56B (0x7789)
Youtuber's DSO150: FW 111, 1500000E-106319-bKPU6V7W- 171129, D058, DD50
Youtuber's DSO150: FW 120, 1500000E2-210374-km0jG5zr-191015, 717D, 5983
In the two first, I also include (in brackets) another number that appears in the upper left corner of the boot screen if you press the OK key during the boot process (it stops at this screen in this case). I'm attaching a photo of this screen and a screenshot of the STM32 programmer software with the option bytes: