Hacking the Rigol DHO800/900 Scope

[Fungus]

yeah! especially an MSO that you can get at ~$600 including LA probe up the game? probably 1-2GSps MSO? buy siglent SDS800X! and those AFG and LA module sold separately. (ps: i dont mind mentioning the name here as i sense rigol fanboys dont get easily insulted )

FWIW I don't think the DHO900 is a very good purchase for the LA.

(and I never have...)

The only DHO model really worth buying right now is the DHO804. The DHO1000 was good when they were selling them at$600. I wouldn't pay $1000 for one though.

If there was a DHO800 with AWG optino for $100 more? That would be cool...

I really don't care if there's a new Siglent. My DHO800 does what I need and some things about it seem better (eg. the display). It's also much smaller and has VESA/HDMI.

I hope I never see Siglent boys in Rigol threads saying the Rigol shouldn't be bought under any circumstances.   

[Fungus]

OTOH, the 900 is a true MSO, the SDS800 only gets decimated display data from the acquisition hardware on the logic probe.

Interesting... 

[ebastler]

OTOH, the 900 is a true MSO, the SDS800 only gets decimated display data from the acquisition hardware on the logic probe.

Interesting... 

A bit misleading, I think. The display data are of course decimated (as they are in any scope), except for the fastest time base settings: The display obviously does not have the same horizontal resolution as the acquisition buffer.

The difference for the entry-level Siglent MSOs, in my understanding, is that the full digital data reside in the external logic analyzer unit. But they can be decoded there with the full time resolution -- not limited to the down-sampled display contents like in the good ol' DS1054Z.

[Antonio90]

You are right. The point I was trying to make is that the triggering and processing is done in the external module and, although the signals are time-correlated in the scope screen, the 800X-HD doesn't get the full data. As such, it is not truly MSO, which shows in the triggering, for example.
It sure is useful, but not equivalent to the 2000 series Siglent scopes, the MSO5000, or the DHO900. Bugs notwithstanding anyway.

[Randy222]

Can someone show me the filesystem data, just ssh into the dho and run "mount" command.

[ebastler]

[...]  it is not truly MSO, which shows in the triggering, for example.
It sure is useful, but not equivalent to the 2000 series Siglent scopes, the MSO5000, or the DHO900. Bugs notwithstanding anyway.

The triggering limitation caused by the separate acquisition of the digital data is that a mixed analog/digital pattern trigger is not supported, to my knowledge. But can the DHO900 or MSO5000 do that? It might be a hardware limitation in the Siglent, a software limitation in the Rigol -- but is the user-facing functionality any different?

But we digress... If I recall correctly,we only opened this can of worms after I referred to the DHO900's compromised sampling rates as an argument why there likely is a hardware bottleneck in the scope's downstream data processing. Which I still consider a valid argument -- but maybe we should have left it there; apologies for being part of the subsequent digression.
 

[AndyBig]

Can someone show me the filesystem data, just ssh into the dho and run "mount" command.

Code: [Select]

rk3399_rigol:/ # mount
rootfs on / type rootfs (ro,size=1832008k,nr_inodes=458002)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=1966596k,nr_inodes=491649,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime,gid=3009,hidepid=2)
sysfs on /sys type sysfs (rw,relatime)
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,relatime,mode=755)
/sys/kernel/debug/tracing on /sys/kernel/debug/tracing type tracefs (rw,relatime,mode=755)
none on /acct type cgroup (rw,relatime,cpuacct)
none on /dev/stune type cgroup (rw,relatime,schedtune)
tmpfs on /mnt type tmpfs (rw,relatime,size=1966596k,nr_inodes=491649,mode=755,gid=1000)
none on /config type configfs (rw,relatime)
none on /dev/memcg type cgroup (rw,relatime,memory)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
none on /dev/cpuset type cgroup (rw,relatime,cpuset,noprefix,release_agent=/sbin/cpuset_release_agent)
pstore on /sys/fs/pstore type pstore (rw,relatime)
/dev/block/mmcblk1p10 on /system type ext4 (ro,noatime,nodiratime,noauto_da_alloc,data=ordered)
/dev/block/mmcblk1p9 on /cache type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,noauto_da_alloc,data=ordered)
/dev/block/mmcblk1p11 on /metadata type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,noauto_da_alloc,data=ordered)
/dev/block/mmcblk1p16 on /data type ext4 (rw,dirsync,nosuid,nodev,noatime,nodiratime,discard,noauto_da_alloc,errors=panic,data=ordered)
/dev/block/mmcblk1p15 on /rigol type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,noauto_da_alloc,data=ordered)
tmpfs on /storage type tmpfs (rw,relatime,size=1966596k,nr_inodes=491649,mode=755,gid=1000)
/data/media on /mnt/runtime/default/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6)
/data/media on /storage/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6)
/data/media on /mnt/runtime/read/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=23)
/data/media on /mnt/runtime/write/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=7)
rk3399_rigol:/ #


[FileFixer]

Is all of that hack what work on DHO804 (BW 100MHz, 50 Mpts memory depth), work also on DHO802?

Welcome!  Yes, follow the guide by @AndyBig found here.  Have fun!

My target will be extension from 70MHz bandwith to 100MHz and from 25Mpts to 50Mpts memory depth as options. For bandwith if I understand there will be BW7T10 and RLU for memory upgrade. To choose a model, maybe can be DHO812?!
In Zalea script for vendor.bin I see there is DHO812 model with BW7T10 and RLU options inside DHO8xx models.

Umm... but what would be the target model to upgrade to? There is no DHO912 or 922, right?

Sorry, Yes.  @FileFixer you'll want to upgrade by applying the licenses, not by doing the Vendor (I.e., model number) upgrade.

FYI:  there are 3 methods in that guide., and you don't have to make it a 900 series to get the upgrades.

My target will be extension from 70MHz bandwith to 100MHz and from 25Mpts to 50Mpts memory depth as options. For bandwith if I understand there will be BW7T10 and RLU for memory upgrade. To choose a model, maybe can be DHO812?!
In Zalea script for vendor.bin I see there is DHO812 model with BW7T10 and RLU options inside DHO8xx models.

[AceyTech]

My target will be extension from 70MHz bandwith to 100MHz and from 25Mpts to 50Mpts memory depth as options. For bandwith if I understand there will be BW7T10 and RLU for memory upgrade. To choose a model, maybe can be DHO812?!
In Zalea script for vendor.bin I see there is DHO812 model with BW7T10 and RLU options inside DHO8xx models.

Yes, DHO812 is what you want, since your hardware is missing the 3rd AFE(analog front end)  Actually, once you apply the BW/Mem upgrades it doesn't matter if you leave it as a 802., you still get the performance, IIRC

[Randy222]

My DHO 804 sdcard appears to have only two Android partitions, "android_meta" and "android_expand". I think the "16" number mentioned elsewhere in this hackng thread is the number of mount points, and not partitions.

Well, my sdcard might very well be encrypted.
The GUID number for type (used by android) seems to suggest encryption is used.

If the DHO has no HSM to store keys (or does it?), then the question becomes, are the keys on the sd card, and if so maybe they are in the _meta partition. I can't mount _meta either.

Edit: hexdump -C on the _expand partition does show some ascii stuff up front, seems like boot info about cpu and some settings. I am trying to find the expand_ .key file that's used by vold on Android. Without an HSM to access the vold key has to be on sdcard as non-encrypted. The mystery gets deeper.

I used testdisk on Linux on a DD imaged backup of my original Nov/2023 SDCard, and it found several partitions, EXT4 and Unallocated(like other's have) --and most importantly-- I noticed they were all Deleted.  Note: this was only using the quick scan.  Deep scan revealed 100's
I undeleted the main partition, and I was able to do a lot more with the card.  In my case, it's a 64G card that I'm currently thrashing on, and I was able to resize the 29.5 gigs to full size of the card using "disks" GUI tool in Ubuntu.

Also, It appears that Rigol had an image that was slightly too large for the target cards, thus making it difficult to image. i.e., DD complains about 1 byte not getting copied when it finishes quits.  Other users have reported similar findings all the way back when the first scopes were shipped.

I think it might be interesting to make a new card with partitions then imagecopy the useful partitions over.  I don't really know how, but I'll probably try some day.

Don't use dd, use ddrescue.

[Randy222]

"new" dho 800-900 "high res" models? So new that when you click Models and Pricing there's none listed as 50M.

Seems like they just opened them up to max? (corrected by next post). Bad marketing I guess.

https://www.rigolna.com/dho/

[ebastler]

"new" dho 800-900 "high res" models? So new that when you click Models and Pricing there's none listed as 50M.

Seems like they just opened them up to max?

https://www.rigolna.com/dho/

These are "new" as in "the newest models in our offering". They are the DHO800 and 900 as originally launched, just with a copy & paste error on the title page (incorrectly stating 50 MPts memory for the DHO800).

[Randy222]

Is all of that hack what work on DHO804 (BW 100MHz, 50 Mpts memory depth), work also on DHO802?

Welcome!  Yes, follow the guide by @AndyBig found here.  Have fun!

My target will be extension from 70MHz bandwith to 100MHz and from 25Mpts to 50Mpts memory depth as options. For bandwith if I understand there will be BW7T10 and RLU for memory upgrade. To choose a model, maybe can be DHO812?!
In Zalea script for vendor.bin I see there is DHO812 model with BW7T10 and RLU options inside DHO8xx models.

Umm... but what would be the target model to upgrade to? There is no DHO912 or 922, right?

Sorry, Yes.  @FileFixer you'll want to upgrade by applying the licenses, not by doing the Vendor (I.e., model number) upgrade.

FYI:  there are 3 methods in that guide., and you don't have to make it a 900 series to get the upgrades.

My target will be extension from 70MHz bandwith to 100MHz and from 25Mpts to 50Mpts memory depth as options. For bandwith if I understand there will be BW7T10 and RLU for memory upgrade. To choose a model, maybe can be DHO812?!
In Zalea script for vendor.bin I see there is DHO812 model with BW7T10 and RLU options inside DHO8xx models.

An 802 will likley run as a 924 vendor bin, but 2ch only. What the gui will look like will be fun. But even so, and 802 can become an 812 easily.

[norbert.kiszka]

Don't use dd, use ddrescue.

If there is no problem with reading data, then dd, ddrescue and cp will do same job. cp cant do offsets but its faster.

[AceyTech]

The DRAM or its interface to the FPGA is a likely suspect.

Yes, I think so too. It’s not for nothing that they installed a cheaper FPGA compared to the 1000/4000 series.

That's hardly fair.  Street price is $299USD for the DHO802 and the Zync is $100 of the BOM cost for just one part.  I don't think there was  room for anything more(much. less an Artix 7), and still stay in business.

[AceyTech]

Don't use dd, use ddrescue.

You Linux guys have more tools than you know how to use.  --And each of you has better tools than everyone else...   

Seriously tho':  @Randy222, ddrescue is not built into Linux and dd is, so that's what I know how to use.  I appreciate the advice, I got lucky installing & using testdisk, and can't wait to try ddrescue.

[ebastler]

The DRAM or its interface to the FPGA is a likely suspect.

Yes, I think so too. It’s not for nothing that they installed a cheaper FPGA compared to the 1000/4000 series.

That's hardly fair.  Street price is $299USD for the DHO802 and the Zync is $100 of the BOM cost for just one part.  I don't think there was  room for anything more(much. less an Artix 7), and still stay in business.

I think we can safely assume that Rigol don't pay $100. And the Zync is certainly a good choice for the DHO800!

With the DHO900, I still like the theory that Rigol originally planned to get extra DRAM bandwidth from the additional DRAM chip on the main board, and had to fall back to the compromised sampling rates late in the game since they could not configure the FPGA to feed both DRAM channels at the required speed. Maybe that's yet to come? I think they must be working on successors for the DHO1000 and 4000 series (with MSO capability) right now...

[sizz0p]

I've followed most of this thread but not all. Some of the work that's been accomplished is incredible.

I was not paying attention for a while to the thread and came back to read a good bit of text about certificates and keys.

I wanted to chime-in that at the very least a person who wanted to sign software as Rigol would need Rigol's (Certificate Authority) private key (ultimately stripped of the passphrase) that was used to sign software - or whatever else you may want to digitally sign. I admittedly have not looked at any of the certs or keys and I have not done any investigation of rigol's infrastructure - like their CAs - to see how their systems might be configured.

I do know that there would be no valid reason for Rigol to leave the private key on the device. I don't think any amount of searching is going to turn up the private key - which would be needed, due to the way PKI functions.

[shapirus]

You Linux guys have more tools than you know how to use.  --And each of you has better tools than everyone else...   

Seriously tho':  @Randy222, ddrescue is not built into Linux and dd is, so that's what I know how to use.  I appreciate the advice, I got lucky installing & using testdisk, and can't wait to try ddrescue.

All right, let's play this game for a moment.

Neither dd, not ddrescue is built into Linux. But they may be installed in some operating systems using Linux.
Both are available via standard package repositories in Debian and derivatives, and one of them is always installed, as it comes in a package that has the "required" priority.

...and yes, there is no reason to go for ddrescue unless you need to recover data from a partially faulty medium.

[norbert.kiszka]

If somebody wants to play with HW number, there is simpler way, than I wrote before.

Code: [Select]

printf '\x8' > /dev/hdcode_gpio
Of course, get rid of hdcode_gpio module first, by unloading it (rmmod hdcode_gpio) and commenting it out in /rigol/shell/start_rigol_app.sh - above command can go into this file (personally I did it at very beginning).

[shapirus]

I do know that there would be no valid reason for Rigol to leave the private key on the device. I don't think any amount of searching is going to turn up the private key - which would be needed, due to the way PKI functions.

Yeah that's obvious. That part of the discussion ended up with two questions that have yet to be answered: a) where is the keystore that the respective public key is stored in and b) is it possible to add an arbitrary public key to that store? Technically we have root, so the answer to the second one should be "yes", but it's not certain.

[norbert.kiszka]

You Linux guys have more tools than you know how to use.  --And each of you has better tools than everyone else...   

Seriously tho':  @Randy222, ddrescue is not built into Linux and dd is, so that's what I know how to use.  I appreciate the advice, I got lucky installing & using testdisk, and can't wait to try ddrescue.

All right, let's play this game for a moment.

Neither dd, not ddrescue is built into Linux. But they may be installed in some operating systems using Linux.
Both are available via standard package repositories in Debian and derivatives, and one of them is always installed, as it comes in a package that has the "required" priority.

...and yes, there is no reason to go for ddrescue unless you need to recover data from a partially faulty medium.

Linux is not a system. Its just a kernel which do very low-level staff. In Debian (one of reasons why I like this distro) You have incredible amount of software in repositories. I dont see any reason to use Ubuntu which is not user-friendly like its at first glance.

[AceyTech]

I think we can safely assume that Rigol don't pay $100. And the Zync is certainly a good choice for the DHO800!

With the DHO900, I still like the theory that Rigol originally planned to get extra DRAM bandwidth from the additional DRAM chip on the main board, and had to fall back to the compromised sampling rates late in the game since they could not configure the FPGA to feed both DRAM channels at the required speed. Maybe that's yet to come? I think they must be working on successors for the DHO1000 and 4000 series (with MSO capability) right now...

Well, FPGA's are expensive parts. You know that better than most.
BTW:  Low quantity(1-10 piece) pricing here is roughly $150, and 1k pricing is around $110., I assumed they have preferred pricing, and chose $100 as a pretty realistic price point, based on experience.  So maybe they're $80?  Still, that's a pretty decent chunk of the BOM cost for one part.

And yeah, I did a bit of feature investigation into the Zync, and those are amazing little parts.  They're certainly faster and more capable looking than some here are giving them credit.  I think your "fall back to compromised..." statement is the most likely scenario for why they're not getting more and deeper acquisition on the DHO900's.  I would love to sit down with their team and hear their story.

[AceyTech]

Neither dd, not ddrescue is built into Linux. But they may be installed in some operating systems using Linux.

Yep., sorry.  I stand corrected.  I have never installed or used Linux on a system that didn't have dd on it "out of the box".  Maybe back in 1991 or '92 when I installed it for the first time(from a CDROM from the back of a 1200 page "Linux Bible" book, but never in modern times.

...and yes, there is no reason to go for ddrescue unless you need to recover data from a partially faulty medium.

Which is pretty much the case with this "partially faulty" SDCard., 

[sizz0p]

I do know that there would be no valid reason for Rigol to leave the private key on the device. I don't think any amount of searching is going to turn up the private key - which would be needed, due to the way PKI functions.

Yeah that's obvious. That part of the discussion ended up with two questions that have yet to be answered: a) where is the keystore that the respective public key is stored in and b) is it possible to add an arbitrary public key to that store? Technically we have root, so the answer to the second one should be "yes", but it's not certain.

Answering both of those questions is not going to help you sign software as Rigol.