Hacking the Rigol DHO800/900 Scope

[souldevelop]

this is assuming it is correct infos there (about the gpl license, and it being intree). that this is not been honestly mistaken. and it assumes rigol respects the terms of the linux kernel, and the terms of the gpl license?

Correct. And I would say they will send you the code.

They sent all the GPL code for the MSO5000 to @Olliver. And he has it on his Github page...

As long as you have experience in Linux driver development, find a .ko driver template and implement the following functions:
gpio_hdcode_drv_open
gpio_hdcode_drv_ioctl
gpio_hdcode_drv_read
gpio_hdcode_init
gpio_hdcode_exit

And refactor and modify the gpio_hdcode_drv_read function, the following is the important location source code of hdcode_gpio.ko:

Code: [Select]

ssize_t __fastcall gpio_hdcode_drv_read(file *file, unsigned __int8 *buf, size_t len, loff_t *f_pos)
{
  size_t v5; // x19
  __int64 v6; // x0
  int v7; // w20
  __int64 v8; // x0
  int v9; // w20
  __int64 v10; // x0
  __int64 v11; // x0
  unsigned __int64 v12; // x1
  bool v13; // cc
  __int64 v15; // x0
  _BYTE v17[4]; // [xsp+33h] [xbp+33h] BYREF

  v5 = len;
  v6 = ((__int64 (__fastcall *)(__int64, unsigned __int8 *, size_t, loff_t *))gpio_to_desc)(4LL, buf, len, f_pos);
  v7 = ((__int64 (__fastcall *)(__int64))gpiod_get_raw_value)(v6) & 1;
  v8 = ((__int64 (__fastcall *)(__int64))gpio_to_desc)(8LL);
  v9 = v7 & 0xFFFFFFFD | (2 * (((__int64 (__fastcall *)(__int64))gpiod_get_raw_value)(v8) & 1));
  v10 = ((__int64 (__fastcall *)(__int64))gpio_to_desc)(11LL);
  LOBYTE(v9) = v9 & 0xFB | (4 * (((__int64 (__fastcall *)(__int64))gpiod_get_raw_value)(v10) & 1));
  v11 = ((__int64 (__fastcall *)(__int64))gpio_to_desc)(12LL);
  v17[0] = v9 & 0xF7 | (8 * (((__int64 (__fastcall *)(__int64))gpiod_get_raw_value)(v11) & 1));
  v12 = *(_QWORD *)(_ReadStatusReg(ARM64_SYSREG(3, 0, 4, 1, 0)) + 8);
  if ( __CFADD__(buf, v5) )
    v13 = 1;
  else
    v13 = (unsigned __int64)&buf[v5] > v12;
  if ( !v13 )
  {
    ((void (__fastcall *)(_BYTE *, size_t, __int64))_check_object_size)(v17, v5, 1LL);
    v15 = ((__int64 (__fastcall *)(unsigned __int8 *, _BYTE *, size_t))_arch_copy_to_user)(buf, v17, v5);
  }
  else
  {
    v15 = v5;
  }
  if ( v15 )
  {
    v5 = -14LL;
    ((void (__fastcall *)(const char *))printk)("copy failed\n");
  }
  return v5;
}

[iMo]

This might be the config resistors for the 924..
Let us compare it with Dave's 814 teardown shots..
Looks the same..

[souldevelop]

This might be the config resistors for the 924..
Let us compare it with Dave's 814 teardown shots..

I've carefully compared the 800 and 900 series teardown HD pictures before, and I didn't find the HDCode setting bits.
According to the previous analysis results, PIN4~PIN12 should be near the mark point of the first pin of the chip.

[iMo]

..Hmm, then you have to fake the source there in the above snippet..
Where would you put the bits then? When not on pcb, I would put it into the fpga..
FPGA reads the bitstream and the bits are there. And I can reuse those 4 signals for something else as well..

[souldevelop]

..Hmm, then you have to fake the source there in the above snippet..

Maybe,set the resistor in the RK3399 PCB buttom layer, but this is just guessing. it is better to directly construct a driver module to fake it.

[souldevelop]

..Hmm, then you have to fake the source there in the above snippet..
Where would you put the bits then? When not on pcb, I would put it into the fpga..
FPGA reads the bitstream and the bits are there. And I can reuse those 4 signals for something else as well..

This is quite possible because I've looked at the files under \rigol\FPGA\ .bit .bin and they do have differences. for this case, the FPGA bitstream files of the DHO914 and DHO804 can be compared.

[iMo]

Yea, but messing with the fpga's bitstream is quite difficult. Nobody will ever touch it, I would guess..

[souldevelop]

Yea, but messing with the fpga's bitstream is quite difficult. Nobody will ever touch it, I would guess..

It's a nightmare!!
I'd rather download the huge and complex RK3399 cross-compilation environment.

[iMo]

Perhaps you could HEX Edit the entire sequence above (NOPing the reading of the 4 bits) with a simple MOV of the number I want into the W20 at the end.. (sorry for my rather naive approach I was using many many decades back, but I could not resist the temptation..)   

[tv84]

This is quite possible because I've looked at the files under \rigol\FPGA\ .bit .bin and they do have differences. for this case, the FPGA bitstream files of the DHO914 and DHO804 can be compared.

It's perfectly understandable that they are different BUT, if the bits were in the FPGA, I guess we just would have to insert the 900 .bit in the 800 package and flash it once. Once you do that, the device thinks it's a 9xx.    The only thing possibly missing would be the vendor.bin change.

[Fungus]

It's perfectly understandable that they are different BUT, if the bits were in the FPGA, I guess we just would have to insert the 900 .bit in the 800 package and flash it once. Once you do that, the device thinks it's a 9xx.    The only thing possibly missing would be the vendor.bin change.

Yes, those hacks are easy but I don't want my 800 to think it's a 900. I want it to think it's an 800 with 125Mhz and 50MPts. 

The 900 puts a lot of useless extra menus on screen that I can't ever use. I'd prefer it not to.

(Still waiting for mine so I can play around with it...)

[souldevelop]

This is quite possible because I've looked at the files under \rigol\FPGA\ .bit .bin and they do have differences. for this case, the FPGA bitstream files of the DHO914 and DHO804 can be compared.

It's perfectly understandable that they are different BUT, if the bits were in the FPGA, I guess we just would have to insert the 900 .bit in the 800 package and flash it once. Once you do that, the device thinks it's a 9xx.    The only thing possibly missing would be the vendor.bin change.

Use the DHO Tool I published to modify the hardware identity ID inside the vendor.bin.

[Nikki Smith]

Can anyone give an overview over the H/W variants of the 800/900 series scopes? E.g. which ones do have hardware capabilites preinstalled for the AWG and stuff like that.

Are all DHO900 series scopes identical hardware-wise, since all of them have the LA connector preinstalled as well as the AWG output at the back? I'd like to avoid having to cut into the case, so I'd go for the DHO914 in that case, as long as all the DHO924S features can be hacked software-wise.

In brief, the motherboard of all the 800/900 series are the same, just the 800 series is missing a few components.
All the 900 series have the LA connector on the front, while the 800 series don't have that connector soldered on the motherboard.
Only the 914S/924S models have the AFG module hardware inside, the 914/924 don't (at least that is my assumption).
The DHO924/DHO924S come with 350MHz probe, but the 914 and 800 series come with 150MHz probes.

[Fungus]

Are all DHO900 series scopes identical hardware-wise, since all of them have the LA connector preinstalled as well as the AWG output at the back?

No, the AWG is a daughterboard which is only installed on the S models.

[RAPo]

Thanks for all the good work in this thread.

As I opted for the DHO942S (not yet arrived), I'm not that interested in adding additional options to hack a DHO800 upwards.
However, I'm curious to know if there are glimpses of functionalities not advertised i.e. extra decoding options above the advertised set.

Any info on that?

[Fungus]

I'm curious to know if there are glimpses of functionalities not advertised i.e. extra decoding options above the advertised set.

They might have power analysis functions like the 4000 series does.

[iMo]

..In brief, the motherboard of all the 800/900 series are the same, just the 800 series is missing a few components. ..

Have you check it on the level of resistors/jumpers/bridges/capacitors/inductors etc?
That is what this thread is about..

[Fungus]

..In brief, the motherboard of all the 800/900 series are the same, just the 800 series is missing a few components. ..

Have you check it on the level of resistors/jumpers/bridges/capacitors/inductors etc?
That is what this thread is about..

I'm not sure the PCB is different. If the device selection was by hardware jumpers then why does vendor.bin override it?

This code might be unused:

[iMo]

..In brief, the motherboard of all the 800/900 series are the same, just the 800 series is missing a few components. ..

Have you check it on the level of resistors/jumpers/bridges/capacitors/inductors etc?
That is what this thread is about..

I'm not sure the PCB is different..

Again, the question is whether all the 800/900 boards are the same (except the AWG, LA, probes type). If one claimed "the all 800/900 series boards are the same", I would certainly ask him whether he doublechecked that at the level of _each_ component on the board, including pcb traces etc. This thread is about hacking a complex device, not about general chat about this scope (there are another 2 threads on that general chat).

[Fungus]

I'm not sure the PCB is different..

Again, the question is whether all the 800/900 boards are the same (except the AWG, LA, probes type)

I think they'll be the same.

The massive clue that they're the exact same PCB is that the HDO800 has all the components for the logic analyzer installed except for the external connector. If they were going to run a separate production line for each model they'd have left those components off the DHO800 boards to save money.

I've carefully compared the 800 and 900 series teardown HD pictures before, and I didn't find the HDCode setting bits.

I don't think they're there. I think it's all configured in vendor.bin

[mwb1100]

The 900 series come with 350MHz probes (or just the 924/924S ?), but the 800 series come with 150MHz probes.

Datasheets say:

  - DHO814/DHO804: Passive Probe x4 (150 MHz) PVP3150
  - DHO812/DHO802: Passive Probe x2 (150 MHz) PVP3150

  - DHO924/DHO924S: Passive Probe x4 (350 MHz) PVP2350
  - DHO914/DHO914S: Passive Probe x4 (150 MHz) PVP3150

[souldevelop]

I don't think they're there. I think it's all configured in vendor.bin

your conclusion is not correct, HDCode's reading is not in the vendor.bin, I have tracked the entire process of reading HDCODE, and have confirmed that it reads information from the GPIO port.

[Fungus]

I have tracked the entire process of reading HDCODE, and have confirmed that it reads information from the GPIO port.

OK, but what does it do with that number?

[souldevelop]

I have tracked the entire process of reading HDCODE, and have confirmed that it reads information from the GPIO port.

OK, but what does it do with that number?

Have you carefully read the analysis content in front of this thread, HDCODE is a 4-bit binary code,
HDCODE 1000 = Hardware version is 8
HDCODE 1100 = Hardware version is 12.
You should be familiar with similar computer coding.

[Fungus]

I have tracked the entire process of reading HDCODE, and have confirmed that it reads information from the GPIO port.

OK, but what does it do with that number?

Have you carefully read the analysis content in front of this thread, HDCODE is a 4-bit binary code,
HDCODE 1000 = Hardware version is 8
HDCODE 1100 = Hardware version is 12.
You should be familiar with similar computer coding.

Yes, I know all that...

The question is what does it do with that number? People have turned their DHO800s into DHO900s with vendor.bin so the firmware doesn't appear to do much with HDCODE.