Oscyloskop DSO150 firmware - This board is FAKE !

Hi, boyak75,

Thank you very much for your feedback!

Maybe the EEPROM is really gone... I've done several experiments with both DSO150 (fake) and DSO138mini (genuine), some of which included transplanting the EEPROM between them, to see if this way I could "genuinize" the 150 and update the FW, and maybe in one of these experiments I killed it... Or maybe not, because I'm using a cheap CH341 reader and this could be the cause of not being able to read it. But Brottoaster couldn't read it either (or read it empty), so maybe also it is really like this.

On the other hand, even if it doesn't remember the unlock procedure, it seems to remember other settings (timebase, volts/div...), so maybe these and other data are stored in STM's internal EEPROM rather than the external one, and the external one is only for the CryptoAuthentication device capabilities, as storing the serial nº (but not in the standard I2C EEPROM space).

I'm thinking of creating a simple program for the STM to read the EEPROM without the need of an external programmer, or even using this library to fully read the special registers of the ATSHA204A or similar CryptoAuthentication device. I'm not very skilled in programming microcontrollers, but with some luck maybe a bit of modding of the library's examples will suffice... maybe you can distract some time from your project and try this way, but I'll also give it a try

Thanks again and I hope we can make some advances, mostly for curiosity and learning (or just for the sake of it ) as, in practice, I can use the scope as is, just entering the activation menu at the beginning, or going back to 064 version, or using one of the maybe even better open-source FWs out there (or, better yet, buying a "real" scope, there are now good looking units for <200€).

Your posts and Brottoaster's were the first ones I could find with real advances on hacking this thing after some posts about a patched 064 version years ago in a Russian forum (which didn't give many clues on how they were done)

Hi morgan_flint!

You can take a look into the old open source of JYE https://github.com/JYEtech/DSO-Shell-open-source-version-
Here you can find the files eeprom.h and .c. This "driver" is a eeprom emulation. This means the data is stored to the internal MCU flash. See https://www.st.com/resource/en/application_no...2f10x-microcontrollers-stmicroelectronics.pdf

We see that the idea is to write changes of the variables in a incremental way. This means we dont write all variables in one go to the same place in memory.
No! We write only changes. And the chages will be written to an increasing memory address. This method is surely to prevent the eeprom from wearout.
This is a half answer to your question "where is the information stored" which i want to answer with "everywhere"

Lets take a closer look to the datastructure stored into the eeprom.
The structure of data is a 16bit variable id (virtual address) followed by a 16bit data value you want to store.
This is called as key value and is very often used in software design to store dynamic data or in communication protocols.

So far...... have fun... my next step will be to take a closer look into the option bytes.

Ok, that justifies (at least, partially), that the external I2C EEPROM looks empty...

I don't know why Jyetech wouldn't want to use it to store the settings, instead of the internal flash that has those wearout problems.

If you ask Jyetech if there is anything you should consider when replacing the U2, you will get the following answer:
"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 thank you very much friend, your pach worked perfectly for my chinese dso150!

Hello, I bought dso150 fnirsi oscilloscope from aliexpress. But it malfunctioned. I changed the STM32 chip, the software was being thrown, but there was no screen, I repaired it by buying a new screen. Now, I tried all the dso150 software on the internet (including the ones described on this page), they all stay on the boot screen as in the picture. Does not continue. How can i solve this problem. As far as I understand in the picture, there is a pid ID at the bottom, but it is broken for me. Thank you to those who will help. I'm trying to improve myself in electronics for hobby purposes.

I have exact same boot screen, with the red E and garbled text in the bottom. Same FNIRSI dso150.
I haven't changed the MCU, nor made any hardware modification.

UPDATE: I ended up installing "lnDSO150", it has specific support for FNIRSI: https://github.com/mean00/lnDSO150

>>19885111

If anyone is looking for the patch for 113-15001-122 here it is. The reduced flickering is nice.

mrsim0ns wrote:

If anyone is looking for the patch for 113-15001-122 here it is. The reduced flickering is nice.

Hello all, after a long time.

I've tried mrsim0ns' patch on FW version 122 and it works well, as boyak75's did on version 120.

However, my former problem remains: I have to enter the activation code each time I power on, whether if I apply both patches (random activation code) or just the fake serial nº detection patch ("good" activation code from boyak75's keygen. I've also noticed that I have to apply again the zero offset correction (V/DIV long press) after entering the activation code after the power cycle, although the settings (V/DIV, SEC/DIV...) seem to be the same before activation (so it looks like the scope remembers the settings but resets them to default on activation),

Has anybody advanced in investigating how and where the "already activated" flag is stored?

BTW, in case it could be relevant for this problem, I'm flashing the MCU with ST-Link V2 programmer and STM32 ST-LINK Utility, instead of serial to USB converter and Demonstrator GUI; it's much more practical as it's not necessary to bridge and unbridge BOOT0 and BOOT1 each time

Hello,
I have been working with the firmware for some time and have also examined the firmware with Ghidra and can tell you the following facts. From firmware > 64, the setting values ​​are no longer stored in the internal memory of the STM32 but in the chip U2, which is not an Eeprom but a microcontroller that communicates with the STM32 via I2C. In your case, the U2 is not working properly because the activation is also stored there. In your case, I suspect that certain memory addresses in the U2 are defective. The following effect occurred: after programming with patches 1+2, the firmware on the DSO ran, but after a while the encoder stopped working. For this reason, I examined the firmware with Ghidra and found the place where the setting values ​​are simply reset to zero and the encoder no longer works. Since then, the firmware 122 has been running without the encoder failing. Up to version 64, the setting values ​​were stored in the internal memory of the STM in a kind of ring buffer. I hope I could help you.

After the patch, the latest firmware runs on the so-called fake boards, but the problem is that after a while the encoder no longer works. (If anyone has the same problem I have the solution). By the way, the small chip on the board is not Eeprom, it is a microcontroller that also communicates via I2C. From version > 64, the setting values are no longer saved in the internal Eeprom.

Added after 3 [hours] 33 [minutes]:

Added after 59 [seconds]:

Hello,
I have been working with the firmware for some time and have also examined the firmware with Ghidra and can tell you the following facts. From firmware > 64, the setting values are no longer stored in the internal memory of the STM32, but in the chip U2, which is not an Eeprom, but a microcontroller that communicates with the STM32 via I2C. In your case the U2 is not working properly as the activation is also stored there. In your case I suspect that certain memory addresses in U2 are defective. The following effect occurred: After programming with patches 1+2, the firmware ran on the DSO, but after a while the encoder stopped working. For this reason, I used Ghidra to examine the firmware and found the place where the setting values are simply reset to zero and the encoder no longer works. Since then, the firmware 122 has been running without the encoder failing. Up to version 64, the setting values were stored in the internal memory of the STM in a kind of ring buffer. I hope I could help you.

Thank you for your answer! Some comments:

Benutzername wrote:

From firmware > 64, the setting values ​​are no longer stored in the internal memory of the STM32 but in the chip U2, which is not an Eeprom but a microcontroller that communicates with the STM32 via I2C

You're right, as I said here:

morgan_flint wrote:

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

It's not a regular EEPROM, but something more complicated. What I'm not sure about is if it behaves as a regular EEPROM in "normal use" and only like what it really is when you address the special functions. This would allow it to work properly in fakes, as long as the firmware doesn't address the special functions (checking serial numbers, for example).

Benutzername wrote:

In your case, the U2 is not working properly because the activation is also stored there. In your case, I suspect that certain memory addresses in the U2 are defective. The following effect occurred: after programming with patches 1+2, the firmware on the DSO ran, but after a while the encoder stopped working

It's not exactly that it stopped working after a while, but that it stopped working after rebooting. Anyway, from what you say, I understand that the conclusions could be the same. It would also explain why I have to recalibrate the zero offset correction after rebooting and reactivating, as this setting also might be stored in the EEPROM.

So, the question is, supposing my U2 has some bad addresses in the EEPROM part: Would the device work properly if I change it for a "regular" EEPROM? Or do I need a real "CryptoAuthentication device" that reports a serial number upon request?

If the latter is the case, it's a problem because it would be harder to find, but the advantage would be I could obviate the patches, as the (supposedly unique) serial number would not be in the blacklist, and I would only have to activate with a correct code generated with @boyak75's keygen.

This raises another question: How did the fake manufacturers manage to make their clones all with the same serial numbers? A possibility would be they used a microcontroller to mimic the behavior of a real ATSHA204A CryptoAuthentication device, but I find that too sophisticated... What do you think?

Hello,
I recorded and evaluated the I2C communication between STM32 and U2 and it is definitely not a EEprom. There is logic in the chip that evaluates telegrams and reacts to them. The settings, for example, are cyclically transferred from the STM32 to the U2 and read and written even if no changes have been made to the settings, which means that the U2 checks whether changes have been made and saves them . Since the type labeling on the U2 is missing, it is difficult to find out. As already said, with version <=64 the settings are saved in the internal memory of the STM32, so if you don't need the new features from version 64 onwards, it would be better to return to this

I'm attaching ATSHA204A's datasheet. Is the traffic you analyzed compatible with it?

According to the information I found some time ago in several forums, this should be the chip marked as U2.

I have several photos of a non-counterfeit DSO150 and DSO138mini (same philosophy regarding counterfeit protection) where some markings are visible in U2, for example, next one of DSO138mini:


But searching for them doesn't find anything, which would be normal in case it was an ATSHA204A, as the datasheet says:

I have already looked at the data sheet of the ATSHA204A, the pin assignment would be correct, the I2C address can be set (DSO expects address h64) and the data exchange also starts with 0=Reset or 3=Command in my recording, which would also speak for it. You would have to look into this part in more detail, in my case this U2 works properly so I wouldn`t bother with it.
For investigation purposes, I recreated the DSO on an experimental board (without an analogue part), just a display and two STM32f103s. One of them does the DSO, the other simulates the U2 (without saving the setting values, which wouldn`t necessarily be a big problem). It`s a wild structure but it serves its purpose.

Ok, thanks for the info!

Seems like your experiment opens a new way to hack this thing... simulating U2 with another microcontroller. But maybe it's not worth working too much on it, as probably my case is not common, so with the patch and the keygen most people can do it.

I'm not sure if I'm going to be able to replicate your experiment, but if you share the code for the second STM, I could give it a try! I could try adding the part of saving settings although, because of my limited programming abilities, I'm not very sure to succeed on this.

Here is the Arduino code for simulation

Thanks!

I'll try to guess how it works, but I'm not very sure to succeed

I've been re-reading your posts and, regarding this:

Benutzername wrote:

From firmware > 64, the setting values are no longer stored in the internal memory of the STM32, but in the chip U2, which is not an Eeprom, but a microcontroller that communicates with the STM32 via I2C. In your case the U2 is not working properly as the activation is also stored there. In your case I suspect that certain memory addresses in U2 are defective

Your setup made me think of another possibility to explain why mine is not working properly and requires re-activation each time: The fake manufacturers did the same as you and, instead of using ATSHA204A or the like, they programmed a microcontroller to mimic just what was needed for U2 in older FW versions, i.e., providing a serial number (this also would explain why all fakes have all those two specific serial numbers), but not storing anything, as it wasn't needed for the FW versions they were using. Jyetech discovered that and, to counterfight the possibility of patching fake serial number verification, started using also the storage capabilities of ATSHA204A. So, adding the storage part to the U2 simulator's FW would overcome this. Then, substitute U2 for a known microcontroller with the same pinout or try to guess which one is it... Too much work for something of this price, but I imagine most of us do this more for the sake of it than for a real profit or need (I finally bought some time ago a "real" oscilloscope, also very "hackable")

Benutzername wrote:

After the patch, the latest firmware runs on the so-called fake boards, but the problem is that after a while the encoder no longer works. (If anyone has the same problem I have the solution)

Benutzername wrote:

For this reason, I examined the firmware with Ghidra and found the place where the setting values ​​are simply reset to zero and the encoder no longer works. Since then, the firmware 122 has been running without the encoder failing

I also re-read this. Is your solution another patch to avoid this resetting? Or do you mean another thing?

Thanks in advance!

Here is the changed bin file that prevents the setting values from being reset (if the encoder freezes).
The bin file has the two patches described above, plus a jump over the part that freezes the encoder, so to speak.
I can only say no to your idea of whether the chip in the fake DSOs is someone else`s - the same ones are installed everywhere. Saving the setting values also works on the fakeboards.
I rather believe that the DSO was produced under license in several production lines and someone then violated license rights and the developers then adapted the software. This may have been the period of version 64.
But perhaps it is also a marketing strategy by the Chinese.

Benutzername wrote:

The bin file has the two patches described above, plus a jump over the part that freezes the encoder, so to speak.

Hello, I've just tried your .bin file but, unfortunately, it has the same behavior as the previous FW I was using, V122 patched by myself following @mrsim0ns instructions (i.e., after activating with random code and with all working OK, the encoder freezes again after rebooting and a new activation is needed)... are you sure you applied the third patch or am I interpreting something wrong? Or, maybe, my presumably bad U2 is also needed for something else?

The bin file contains the 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
:10BAC000000000000000000000000100FFFF00000077

as well as a change I made that prevented it from freezing on my end. In my case, if I only apply these patches, the DSO runs fine for a while, but after a while (days or weeks) the encoder stops working and the settings can no longer be changed, even after a restart. That's why I investigated this and found the part that was causing me problems. I have changed the assembler code so that it jumps absolutely over this point. I think the problem with you is the defective U2.
What did you mean by patch 3 ? or do you mean the three lines ?

Benutzername wrote:

What did you mean by patch 3 ? or do you mean the three lines ?

By "third patch" I meant the one you added to the two patches proposed by @mrsim0ns here, but I must have misinterpreted you, because I thought that patch would stop encoder freezing in my case (and needing to reenter the activation code), but I see now that you meant a long term freezing, not my case.

If my problem is defective U2, the only solution would be to use internal flash again (as in pre-V64), but I understand this is too much to achieve with a patch.

Anyway, just for curiosity, I'll try again exchanging U2 between my fake DSO150 and my genuine DSO138mini to see what happens

Hello, haven`t heard from you for a long time, have you swapped the U2?
I looked into the Crypto Chip ATSHA204A, meaning I got the chip and experimented with it a bit.
I can also tell you in advance that the U2 is definitely this too, unfortunately in my opinion it is not so easy to describe it in such a way that it works with the DSO.
I have now expanded my simulation of the U2 with an STM32 so that saving parameters also works.

Benutzername wrote:

Hello, haven`t heard from you for a long time, have you swapped the U2?

Not yet, have been messing around with other projects... I'll try to do it next week

Ok, finally I did the swapping, with no luck: Installing a genuine ATSHA204A from a genuine DSO138 mini in my fake DSO150 resulted in no passing of the boot screen and illegible random characters where the serial number should be:

The images correspond to two different power-up sequences, the second one after pushing OK (red R changed to yellow 0x9341)

Added after 8 [minutes]:

Benutzername wrote:

I have now expanded my simulation of the U2 with an STM32 so that saving parameters also works

I had missed this one... Would it be possible to port your code to a smaller microcontroller (ATtiny or the like) to install it where U2 is, as the counterfeiter did?
Maybe with some surgery, if we can't find one with a compatible pinout for power and data pins... In the case of ATtiny, Vcc, GNG, and SDA coincide, SCL could be easily rerouted with a thin wire, if it wasn't possible to configure it to pin 6: