Hacking the Rigol DHO800/900 Scope

[Fungus]

How can you actually read a bin. file ?
That would interest me.

You mean vendor.bin?

It has binary data in it. You can see it using something like HxD (on windows) to see it in hexadecimal/ASCII.

It's encrypted though so you won't see much. 

[Serg65536]

Is anyone willing to share their key.data file? Or has one been attached to post already? Looking at libscope-auklet.so inside sparrow apk, there are two references where it looks

How do you get such a nice function names? I'm trying to load the sparrow.apk with IDA Pro 7.7.220118 (last unlocked version), but no pseudocode (F5) is available.

[t_i_t_o]

APK is zip archive, unzip it first.

[Mechatrommer]

How can you actually read a bin. file ?
That would interest me.

You mean vendor.bin?
It has binary data in it. You can see it using something like HxD (on windows) to see it in hexadecimal/ASCII.
It's encrypted though so you won't see much. 

i downloaded the so called decrypted vendor.bin i still dont see much with hex editor... so i dont know whats the deal with xxtea encryt/decryption.

APK is zip archive, unzip it first.

more specifically... classes.dex right?

[tv84]

How can you actually read a bin. file ?
That would interest me.

A .bin file can be read with any hexadecimal (or binary) editor, like HxD. BUT, unless you know or are able to recognize what's inside that specific .bin file, usually a .bin file has a data structure format that's is gibberish for an (untrained) human eye.

So, a .bin file can have practically endless format combinations.

[tv84]

There's an FRAM chip to store the current settings every time you change them.

Usually (since MSO5k) that FRAM has also been used to store the vendor.bin, Key.data and licenses. From preliminary analysis of the DHO behavior done by others (I've not verified this), I would say that it seems the DHO doesn't work exactly the same (and if so, I can only attribute to programmer's laziness, sloppiness or pure lack of knowledge) as people have been able to change things just by replacing files.

[Serg65536]

APK is zip archive, unzip it first.

IDA is smart enough to do it automatically, it finds the entry point and does analysis,  but the result is poorly readable.

[Serg65536]

i downloaded the so called decrypted vendor.bin i still dont see much with hex editor... so i dont know whats the deal with xxtea encryt/decryption.

Encrypted files are random from the point of simple analysis.
Successful decryption gives meaningful content: zero sequences in this case. It's extremely low probability to have such data in random sequence.
That's the sign of successful decryption.

[Fungus]

i downloaded the so called decrypted vendor.bin i still dont see much with hex editor...

Ah, the untrained eye...

I lost track of the post with that decrypted file but it was definitely decrypted/correct.

[tv84]

I lost track of the post with that decrypted file but it was definitely decrypted/correct.

  It's in the 1st page.

[swperk]

I just received my DHO914S Scope. I wanted to get the least expensive model that had both the logic analyzer and the AWG hardware, hoping to be able to unlock the 250 MHz bandwidth.

I modified the rgtool.go script to use with the DHO900 but never found the bandwidth license. Next I installed the 924 vendor.bin file, and although it enabled the 250 MHz bandwidth, it also disabled the AWG and the associated Bode plot option.

What is the best course of action for me to enable everything on this scope? Is there a DHO 924S vendor.bin file available, or preferably a known working rgtool.go for the DHO900?

Thanks,
Stan

[Fungus]

I lost track of the post with that decrypted file but it was definitely decrypted/correct.

  It's in the 1st page.

Oh, yeah, duh!

Here's the hex dump of the decrypted file as shown in HxD:


First up: You can see a lot of zeros, that's a good sign of correct decryption.

Here's the analysis:

Code: [Select]

00000000  File CRC32: A2A69654  [00000008-000000D3]  CRC OK
00000004 File Length: 204  Size OK
-----------------------------------------------------------
00000008    NameSize: 4
0000000C        Name: E_CFG_MODEL_RAW
00000010   FieldSize: 56
00000014       CRC32: 0ADE0274  [0000001C-0000004B]  CRC OK
00000018    DataSize: 44  Size OK
0000001C        Data: DHO924
-----------------------------------------------------------
0000004C    NameSize: 4
00000050        Name: E_CFG_SN_RAW
00000054   FieldSize: 56
00000058       CRC32: 6184E52C  [00000060-0000008F]  CRC OK
0000005C    DataSize: 44  Size OK
00000060        Data: DHO9A252500008
-----------------------------------------------------------
00000090    NameSize: 4
00000094        Name: E_CFG_MAC
00000098   FieldSize: 56
0000009C       CRC32: 8292C492  [000000A4-000000D3]  CRC OK
000000A0    DataSize: 44  Size OK
000000A4        Data: 0019AFA00004
  File processed OK

First up: The checksum is hexadecimal A2A69654

In the hexdump you can see the first four bytes are 54 96 A6 A2. That's the same four bytes as the checksum but reversed, that tells me the rest of the file will also have any 32-bit numbers reversed in it.

Next up in the hex dump we have CC 00 00 00. Reverse that and we get 0x000000CC - 204 in decimal. That's the file size.

After that is 04 00 00 00, that gives us "NameSize: 4". It looks like every packet of data in the file is preceded by its size so we read out 4 bytes. "05 00 00 00". 5 must be the code for E_CFG_MODEL_RAW (which I assume is "model number").

Then we get 38 00 00 00, ie 0x00000038, 56 in decimal. The remainder of the "E_CFG_MODEL_RAW" packet is 56 bytes long. It has a 4-byte CRC ("0ADE0274  ") and then this:

06 00 00 00 31 67 FA 5A AE C8 12 02 15 AA 70 96 0A CA 4E A0 EF 82 04 1B B2 36 40 C3 23 CF 2E EF 3A 03 58 80 76 02 1B CD BF 10 1A 36 45 2C 02 98

I'm not exactly sure how that works but the first 4 bytes are"6" (the length of the string "DHO924") plus what I assume is an encrypted version of the text (there's no zeros or recognizable characters in the data and some bytes are higher than 127).

The next packet is the serial number. It starts at offset 0x00004c and has the same structure.

The final packet is the MAC address and starts at 0x00000090. Same structure again.

Why would they encrypt the strings inside the file? No idea. It's suspicious that all three strings in the file have 40 bytes of data even though the strings are different lengths.

[Mechatrommer]

i downloaded the so called decrypted vendor.bin i still dont see much with hex editor...

Ah, the untrained eye...
I lost track of the post with that decrypted file but it was definitely decrypted/correct.

i'm not intending to work hard on that, up to a point where i dont know what is real and what is interpolated i expect i can see my serial number and scope model in plain text in hex editor... so there must be a method/function to translate all those values between zerooos into plain text serial number.

[tv84]

what I assume is an encrypted version of the text (there's no zeros or recognizable characters in the data and some bytes are higher than 127).

Correct. The file is XXTEA encrypted and the strings inside are again XXTEA encrypted. AFAIR someone posted a tool that takes care of all of this... or I imagined that?

[Martin72]

Actually, that's perfectly OK if my 804 now has 50Mpts and 100Mhz (measured 200Mhz) bandwidth.
But...
It would be nicer to have the 2ns/div and the other decoders without having to make it a 900.
Let's see where this thread leads to.

[Mechatrommer]

currently i have 2 sd cards ready... v1.14 DHO924 (which currently i use) and the other v1.01 DHO804 (legit copy) ordering more 32GB sd cards for other version, so switching between versions and models, or for hacking trial and error, is only a matter of switching sd card and redo self-cal. i prefer all DHO924S features, except with latest FW from rigol site, and my original serial number.

[Fungus]

It would be nicer to have the 2ns/div and the other decoders without having to make it a 900.
Let's see where this thread leads to.

Does the DHO900 have 2ns/div? I don't care much about all the other DHO900 stuff but that would be nice to have.

We'll probably need to modify the .apk file to get it though and I don't know anything about doing that...

(yet)

[ebastler]

Does the DHO900 have 2ns/div?

Datasheet say "yes".

[Mechatrommer]

It would be nicer to have the 2ns/div and the other decoders without having to make it a 900.
Let's see where this thread leads to.

Does the DHO900 have 2ns/div? I don't care much about all the other DHO900 stuff but that would be nice to have.

We'll probably need to modify the .apk file to get it though and I don't know anything about doing that...

(yet)

yes, but v1.14 FW has some quirk there. https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5135757/#msg5135757

[chris178]

Do your scopes use the MAC address that is embedded into the vendor.bin?
Mine uses different MAC on ethernet NIC - one starting with 56:30:2a. vendor.bin has MAC starting 00:19:AF.
Not sure where this comes from... any ideas?

[Fungus]

Do your scopes use the MAC address that is embedded into the vendor.bin?

Mine does.

[ebastler]

Do your scopes use the MAC address that is embedded into the vendor.bin?
Mine uses different MAC on ethernet NIC - one starting with 56:30:2a. vendor.bin has MAC starting 00:19:AF.
Not sure where this comes from... any ideas?

00:19:AF is the MAC address block assigned to Rigol; 56:30:2a comes back as "unassigned". Strange...
https://maclookup.app/search/result?mac=00:19:AF

[chris178]

Do your scopes use the MAC address that is embedded into the vendor.bin?
Mine uses different MAC on ethernet NIC - one starting with 56:30:2a. vendor.bin has MAC starting 00:19:AF.
Not sure where this comes from... any ideas?

00:19:AF is the MAC address block assigned to Rigol; 56:30:2a comes back as "unassigned". Strange...
https://maclookup.app/search/result?mac=00:19:AF

From dmesg:

Code: [Select]

[    5.827923] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: mac address: 56:30:2a:xxxxxx
[    5.827960] eth0: device MAC address 56:30:2a:xxxxxxxx
[    7.219817] ethernet PHY : genphy init done, phyid = 0x00000128.
[    7.238202] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    7.508644] init: Service 'up_eth0' (pid 230) exited with status 0
[   10.230097] rk_gmac-dwmac fe300000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
I've grepped briefly rigol scripts and can't see anything that would be overriding it in any way...
Am I thinking correct that rk_gmac-dwmac fetches this mac from the rockchip SoC registers...?
Not super important but curious...

[mwb1100]

FWIW, 56:30:2a is a MAC OUI that has the "locally administered" bit set, which means that it's an OID that is "made up" and not in the IEEE OUI registry (which is why a MAC address search tool won't find a match).

I don't know why the oscilloscope would use one of those instead of the Rigol owned MAC address, but I have a guess from Google:

This post on some armbian forum shows the following lines in dmesg:

Code: [Select]

[    7.853012] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: rk_vendor_read eth mac address failed (-1)
[    7.853052] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: generate random eth mac address: 5a:b7:f0:5b:53:d4
[    7.853058] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: rk_vendor_write eth mac address failed (-1)
[    7.853066] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: mac address: 5a:b7:f0:5b:53:d4
[    7.853071] eth0: device MAC address 5a:b7:f0:5b:53:d4

In that case the MAC address is randomly generated on each boot.  If your randomly generated MAC address is stable across boots, then what might have happened is that on first boot 'rk_vendor_read eth mac address failed' occurred and a random MAC was generated (with OUI 56:30:2a).  But in your case maybe the following 'rk_vendor_write eth` did not fail and was written to some saved configuration location and subsequent boot successfully read that MAC?

I don't think this randomly generated MAC address will cause big problems.  It's highly unlikely that a duplicate MAC will be found on your local network which is the the most important place the MAC address is used.  However there are two other scenarios I can think of where MAC addresses get used that aren't uncommon:

  - some licensing algorithms will use a MAC address as an identifier.  I don't think Rigol uses MAC addresses for its option licenses, so I don't think there's a problem there
  - DHCP can use MAC address to identify if a node asking for an IP address was recently assigned some IP address so the DHCP server will give that node the same address (if it hasn't already been given to another node).  If the oscilloscope's MAC address changes with each boot, it's more likely to get a different IP address each time.  This is generally not a big problem unless you want the scope's IP address to generally be stable or want to configure the DHCP server to assign a fixed IP to that oscilloscope.  The workaround for that is to assign a fixed IP outside of the DHCP range on the scope itself (I assume the scope's settings have some mechanism for that?)

[chris178]

FWIW, 56:30:2a is a MAC OUI that has the "locally administered" bit set, which means that it's an OID that is "made up" and not in the IEEE OUI registry (which is why a MAC address search tool won't find a match).

I don't know why the oscilloscope would use one of those instead of the Rigol owned MAC address, but I have a guess from Google:

This post on some armbian forum shows the following lines in dmesg:

Code: [Select]

[    7.853012] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: rk_vendor_read eth mac address failed (-1)
[    7.853052] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: generate random eth mac address: 5a:b7:f0:5b:53:d4
[    7.853058] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: rk_vendor_write eth mac address failed (-1)
[    7.853066] rk_gmac-dwmac fe300000.ethernet: rk_get_eth_addr: mac address: 5a:b7:f0:5b:53:d4
[    7.853071] eth0: device MAC address 5a:b7:f0:5b:53:d4

In that case the MAC address is randomly generated on each boot.  If your randomly generated MAC address is stable across boots, then what might have happened is that on first boot 'rk_vendor_read eth mac address failed' occurred and a random MAC was generated (with OUI 56:30:2a).  But in your case maybe the following 'rk_vendor_write eth` did not fail and was written to some saved configuration location and subsequent boot successfully read that MAC?

I don't think this randomly generated MAC address will cause big problems.  It's highly unlikely that a duplicate MAC will be found on your local network which is the the most important place the MAC address is used.  However there are two other scenarios I can think of where MAC addresses get used that aren't uncommon:

  - some licensing algorithms will use a MAC address as an identifier.  I don't think Rigol uses MAC addresses for its option licenses, so I don't think there's a problem there
  - DHCP can use MAC address to identify if a node asking for an IP address was recently assigned some IP address so the DHCP server will give that node the same address (if it hasn't already been given to another node).  If the oscilloscope's MAC address changes with each boot, it's more likely to get a different IP address each time.  This is generally not a big problem unless you want the scope's IP address to generally be stable or want to configure the DHCP server to assign a fixed IP to that oscilloscope.  The workaround for that is to assign a fixed IP outside of the DHCP range on the scope itself (I assume the scope's settings have some mechanism for that?)

That's what I thought that this is locally defined set. However I don't see any other errors in dmesg log related, hence I was curious why this is the case.
This MAC is persistent and same after every reboot (cold).
The other theory I have is that perhaps bootloader is reading and configuring NIC's MAC register at the early boot stage.
Perhaps it cannot read it from where it's stored and psuedo-random is generated (however always same).
My guess is that it could be before mentioned fRAM... that might be storing same information as in the vendor.bin file.

I haven't broken the seal on my unit yet, but perhaps early boot console log would shed more light at it.

Other work around would be to run small script to override MAC with correct one. (ip link set dev <your device here> address <your new mac address>).
But in my case MAC is persistent and hence DHCP assigned IP so not a problem at all...

Also I wonder if anyone that tried substituting vendor.bin from other models have seen MAC address being updated on their devices to correspond with used file?