For some reason Im very interested with a image of this SD card 
would be interesting if the contained apk modules would work on a DHO8xx/9xx as well - maybe thier decoders will work there as well.
I don't know how much MHO98 decoders has. But in my mod currently it looks like this:
Looks like "DiskGenius" could actually delete files in a mounted image:
So, which are the critical files?
vendor.bin, BND.lic, RLU05.lic, key.data? Something else?
Definitely I don't need .lic files, because Im hacking app directly.
Vendor.bin and Key.data contains serial number, model name, MAC address and staff like that.
Has anyone deconstructed the app enough to tell whether these decoders are implemented and packaged in such a way that we could write our own and inject them into the app?
Has anyone deconstructed the app enough to tell whether these decoders are implemented and packaged in such a way that we could write our own and inject them into the app?
As they say: everything is open source if You can read Assembly.
After some old school hacking in the upcoming days-weeks, I will make a new app from the scratch - primarily linked with the original .so lib (because it will be much faster). With fast and open source API - at least for the separate UI (also open source).
Has anyone deconstructed the app enough to tell whether these decoders are implemented and packaged in such a way that we could write our own and inject them into the app?
They aren't "plugins", if that's what you mean.
They're all in the app and enabled with license files.
Looks like "DiskGenius" could actually delete files in a mounted image:
(Attachment Link)
So, which are the critical files?
vendor.bin, BND.lic, RLU05.lic, key.data? Something else?
But ... is the info overwritten or does it just remove them from the directory?
Has anyone deconstructed the app enough to tell whether these decoders are implemented and packaged in such a way that we could write our own and inject them into the app?
They aren't "plugins", if that's what you mean.
They're all in the app and enabled with license files.
It can be enabled by hacking You forget to say (as usual...).
New can be added by writing in Assembly.
Looks like "DiskGenius" could actually delete files in a mounted image:
(Attachment Link)
So, which are the critical files?
vendor.bin, BND.lic, RLU05.lic, key.data? Something else?
But ... is the info overwritten or does it just remove them from the directory?
In DHO800/900 (stock app) additional licenses are saved in FRAM in a separate IC.
But ... is the info overwritten or does it just remove them from the directory?
Both is possible. I used overwrite with 0
I was curious about the app (apk) and why it crashes on my DHO924S.
Code that made a crash was a part of completely different license system. This time they were more clever than using XOR or similar easy to hack things as they did before. So rigol_vendor_bin likely will not work here - at least not in the same way.
Anyway, still this is not a problem for me, because Im just bypassing those license functions. So the function contents doesn't matter.
I bypassed communication with the FPGA and app now works on my DHO924S - as in the attachment.
Hacking it should be easy.
Has anyone deconstructed the app enough to tell whether these decoders are implemented and packaged in such a way that we could write our own and inject them into the app?
They aren't "plugins", if that's what you mean.
They're all in the app and enabled with license files.
It can be enabled by hacking You forget to say (as usual...).
Yes, because the question (and therefore my answer) was
about writing custom decoders, not about how unlockable the existing ones are.
Has anyone deconstructed the app enough to tell whether these decoders are implemented and packaged in such a way that we could write our own and inject them into the app?
They aren't "plugins", if that's what you mean.
They're all in the app and enabled with license files.
It can be enabled by hacking You forget to say (as usual...).
Yes, because the question (and therefore my answer) was about writing custom decoders, not about how unlockable the existing ones are.
Correct. I was wondering whether Rigol had some sort of non-public mechanism that dynamically loaded (call it a plugin if you want) decoders. Where, if you could implement the same interface and drop a binary in the right place, you could sneak in your own. It sounds like the answer is no (I'll assume the decoders are all compiled into the same binary). Thanks for the answers.
My teardown pics are up:
https://www.flickr.com/photos/eevblog/albums/72177720330041928
The standard 4-pin fan header will make fan upgrades/mods easy 
In my preliminary reverse engineering I noticed PWM kernel module - for sure it's used to drive fan. Knowing Rigol, they did this management in scope app instead of separate process - that's bad, because when app will crash and nobody will restart it, everything can overheat.
The standard 4-pin fan header will make fan upgrades/mods easy
I haven't looked for alternatives yet, but yes, the fan is annoyingly loud. 57W power consumption.
No surprise for me. Windows and Windows-only software is almost always useless.
Just to be fair: "DiskGenius" is also able to find all the partitions in the complete raw "mmcblk0" SD card dump:
It's the only (somewhat) free Windows tool I found up to now which can actually do that.
This also allows inspecting (dumps of) SD cards from other Linux systems, e.g. Raspberry Pi.
Unfortunately, the free version is limited to extracting small files.
My teardown pics are up:
https://www.flickr.com/photos/eevblog/albums/72177720330041928
The standard 4-pin fan header will make fan upgrades/mods easy
In my preliminary reverse engineering I noticed PWM kernel module - for sure it's used to drive fan. Knowing Rigol, they did this management in scope app instead of separate process - that's bad, because when app will crash and nobody will restart it, everything can overheat.
Hopefully it has a fan controller that will revert to 100% if not constantly commanded to hold a lower speed (like on PCs).
Yeah but if the app crashes while the fan is set to a low speed I assume it will just not update the PWM value and cook itself.
Yeah but if the app crashes while the fan is set to a low speed I assume it will just not update the PWM value and cook itself.
That's the worst-case scenario, and it might be the case if they are using what is literally only a PWM circuit. But if it's a fan controller, they fail-safe to 100% speed (or to a temperature-based speed control if fancy enough and configured to).
As a side note, I didn't have the impression that there is any kind of fan regulation. It seems to always run a the same speed.