Hacking the Rigol MSO5000 series oscilloscopes - Page 1
Forum section: electronics / testgear

author: Agne
author_rank: Contributor
timestamp: December 02, 2018, 04:19:19 pm
content: TL;DR This thread is only for hacking of the Rigol 5000 oscilloscope. I own a Rigol 5000 series oscilloscope and have tried the old (Rigol 1000z & 2000A series) trick of dumping the RAM using SCPI commands but unfortunate this does not appear to work on the 5000 series. Next step is trying the JTAG memory dumping method.------------------------------------------------------------------------------------------------------------------Since the previous thread about the Rigol 5000 series oscilloscope has been completely derailed from discussing the Rigol 5000 to arguing about A and B brands and if Lecroy and Tektronix are still A brands etc, I would like to start this new thread dedicated to hacking of the 5000 series.To keep this thread clear from what made the previous thread unusable from a Rigol 5000 hackers perspective I would like to set some simple rules for it.* This tread is only for hacking the Rigol 5000 series oscilloscope* If you would like to discuss other things such as if you should buy the 5000 series or what is an A or B brand then please post that in a different thread.-----------------------------------------------------------------------------------------------------------------------With that over with lets discuss what hacking progress has been made so far.I have tried on my 5000 series scope the SCPI memory dump command that was successfully used on the Rigol 1000z and 2000A series oscilloscopes. Unfortunately the command does not work on the 5000 series. When using the memory dump command with Netcat on my mac I get no reply from the scope and when using RigolBildschirmkopie I get “there was an error when sending the SCPI comand”. To verify that SCPI was working I tried the *IDN? , :SYSTEM:TIME? and the SYSTEM:DATE? commands and they worked with out issue.Rigol appears to have either removed or changed the name of the SCPI command used to dump the memory on the older scopes. At this point I think using JTAG to dump the memory is our best bet. I will post an update when I know more.

author: Agne
author_rank: Contributor
timestamp: December 02, 2018, 08:31:44 pm
content: I have now opened my Rigol 5000 series scope and looked for possible JTAG connectors. There appears to be spaces for two JTAG connectors on the board, one for the Zynq FPGA and one for the Spartan FPGA.Unfortunately Rigol have not mounted the pin headers for the JTAG on the PCB.This reduces there BOM cost by a few cents and makes connecting a JTAG programmer to the board more difficult.I have attached below some images showing the inside of the scope and I have highlighted the possible location for the JTAG connectors. The connector that I am most interested in is small 9 pin one because it looks like the JTAG connector used to dump the memory on the Rigol 1000Z and 2000A series oscilloscopes.

author: nctnico
author_rank: Super Contributor
timestamp: December 02, 2018, 09:09:37 pm
content: I'd look at the unmarked 14 pin connector to the right.

author: Agne
author_rank: Contributor
timestamp: December 02, 2018, 11:25:59 pm
content: After looking for a simple solution to the problem of not having pin headers mounted on the JTAG connectors and not wanting to completely disassemble the scope to permanently solder in pin headers I found solderless press fit pin headers. I have ordered some and my hope is that I can push them in partially, just enough to make good contact while still being able to remove them when done.

author: nctnico
author_rank: Super Contributor
timestamp: December 03, 2018, 07:35:34 am
content: I wouldn't use press-fit connectors. You'll need to put way too much force on the board which might damage it. Ceramic capacitors don't like being bend. Just take it apart and solder a connector in.

author: TheSteve
author_rank: Unknown
timestamp: December 03, 2018, 07:59:07 am
content: Quote from: nctnico on December 03, 2018, 07:35:34 amAgreed, solder a normal header in.Or you could use pogo pins, but you'd need to find a way to maintain pressure on the pins.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 03, 2018, 09:12:46 am
content: If you don't want to solder headers in, get a long pin header - 10mm or more, then bend alternate pins. It can then be inserted such that the bent pins exert pressure on the sides of the holes.

author: Fungus
author_rank: Super Contributor
timestamp: December 03, 2018, 09:21:24 am
content: Quote from: mikeselectricstuff on December 03, 2018, 09:12:46 amIf you get square pins they might exert enough pressure to make contact all by themselves.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 03, 2018, 09:23:30 am
content: Quote from: Fungus on December 03, 2018, 09:21:24 amYou need bent pins so each pin is independently spruing

author: mrpackethead
author_rank: Super Contributor
timestamp: December 03, 2018, 09:42:20 am
content: is the upgrade licence file encypted?

author: glenenglish
author_rank: Frequent Contributor
timestamp: December 03, 2018, 10:01:39 am
content: how about I buy a 70 also and buy the upgrade to 100 in the same breath ? that should be useful.I'll have mine in 2 weeks or so... am a Xilinx man...

author: Fungus
author_rank: Super Contributor
timestamp: December 03, 2018, 10:12:27 am
content: Quote from: mrpackethead on December 03, 2018, 09:42:20 amIn the programming guide it shows this example of installing a license key:The key's definitely a lot longer than a key for a DS1054Z.Does anybody have a license file? Can you look at it and see if the contents look like that?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 03, 2018, 10:34:59 am
content: Quote from: Fungus on December 03, 2018, 10:12:27 amPretty sure Dave mentioned he had one

author: EEVblog
author_rank: Unknown
timestamp: December 03, 2018, 10:46:10 am
content: Quote from: mrpackethead on December 03, 2018, 09:42:20 amThe license file is a single line of text as shown above."DS5000-2RL@" followed by 128 bytes of key dataWhere 2RL seems to be the license type codeMy license file didn't work though.They need your serial number to generate the key.

author: tv84
author_rank: Super Contributor
timestamp: December 03, 2018, 12:27:55 pm
content: (128 bytes => 1024 bits)It seems to me that we will be seeing asymmetric crypto. I think the MSO7000 will be the same.As such, there won't be any licenses soon and the solution could be SW patches.If the FW is signed, that is another ballgame (HW patch...).Nonetheless, waiting for the memdump...

author: Bud
author_rank: Super Contributor
timestamp: December 03, 2018, 12:52:42 pm
content: Quote from: EEVblog on December 03, 2018, 10:46:10 amThen it seems the hex string is a 1024-bit digital signature of the license code.

author: Fungus
author_rank: Super Contributor
timestamp: December 03, 2018, 01:06:53 pm
content: Quote from: Bud on December 03, 2018, 12:52:42 pmMost likely the license type+the serial number.If somebody can find the hash code in the ROM then it's easy to make a key generator.The bad news would be if it's a 1024-bit signature of the license type+serial number+a secret salt value that's written to the flash memory at the same time as the serial number.It would mean you need to get the salt value out and that might only be possible by opening it up and using JTAG.Finger crossed that they didn't do that.If this thing runs Linux then step (1) would be to get access to the file system and dump all the files. See if there's anything interesting in there.Step (2) would be to dump all the files before/after installing an option and see what changes.

author: Fungus
author_rank: Super Contributor
timestamp: December 03, 2018, 01:40:44 pm
content: Can anybody post all the RS232 logging messages from a bootup? Maybe there's useful info in there.

author: TNorthover
author_rank: Contributor
timestamp: December 03, 2018, 03:04:58 pm
content: Quote from: Fungus on December 03, 2018, 01:06:53 pmIf it's an actual 1024-bit signature rather than a simple hash or something (as the size suggests) then no-one is going to be generating them any time soon. You also need Rigol's private key.

author: tv84
author_rank: Super Contributor
timestamp: December 03, 2018, 03:05:44 pm
content: Fungus,With asym crypto involved and the boot signed, there's no salt reading or flash dumps that can help.The most one can do is obtain the public key. But that is useless to create new software.Let's wait for the next steps.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: December 03, 2018, 04:38:38 pm
content: If I wanted to make a product like this with good security, I'd include a random number stored in the device as part of the production process, with a factory database of this number versus serial number, and use that rather than the serial no. for authenticating/decrypting license keys, so the actual serial number bears no useable relationship to the license key.

author: maginnovision
author_rank: Super Contributor
timestamp: December 03, 2018, 04:41:00 pm
content: Didn't the distributor generate the key though? I assume that means no asym crypto or the key isn't that safe.

author: Fungus
author_rank: Super Contributor
timestamp: December 03, 2018, 04:57:10 pm
content: Quote from: maginnovision on December 03, 2018, 04:41:00 pmThey generate them on the Rigol web site.Rigolcouldhave a private key on there.

author: maginnovision
author_rank: Super Contributor
timestamp: December 03, 2018, 05:03:49 pm
content: Quote from: Fungus on December 03, 2018, 04:57:10 pmOh right. The internet. I forgot about the internet.

author: Fungus
author_rank: Super Contributor
timestamp: December 03, 2018, 05:04:46 pm
content: Dave posted the boot output inanother thread.Code:U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)I2C: readyMemory: ECC disabledDRAM: 448 MiBDPU: 20170604NAND: OnDie ECC supported, 1024 MiBzynq-In: serialzynq-Out: serialzynq-Err: serialNet: Gem.e000b000BootParam=0x0Hit any key to stop autoboot: 0NAND read: device 0 offset 0x4900000, size 0x3591fdþNAND read: device 0 offset 0x4900000, size 0x88 bytes read: OKNAND read: device 0 offset 0x4500000, size 0x12c0081228808 bytes read: OKLoading logo, x=310,y=247,width=404,height=89NAND read: device 0 offset 0x5100000, size 0xd8ebf014216176 bytes read: OK## Loading kernel from FIT Image at 03000000 ...Using 'rootfs@1' configurationTrying 'kernel@1' kernel subimageDescription: Kerstrel Linux kernelType: Kernel ImageCompression: uncompressedData Start: 0x030000f8Data Size: 3302448 Bytes = 3.1 MiBArchitecture: ARMOS: LinuxLoad Address: 0x00100000Entry Point: 0x00100000Hash algo: sha1Hash value: bece162e8cad943c68714d8eb8020d68e1db896bVerifying Hash Integrity ... sha1+ OK## Loading ramdisk from FIT Image at 03000000 ...Using 'rootfs@1' configurationTrying 'ramdisk@1' ramdisk subimageDescription: kerstrel-Update-RamdiskType: RAMDisk ImageCompression: gzip compressedData Start: 0x03328c5cData Size: 10901113 Bytes = 10.4 MiBArchitecture: ARMOS: LinuxLoad Address: unavailableEntry Point: unavailableHash algo: sha1Hash value: 55bdcbebccba845da403130143793ee0135e53a1Verifying Hash Integrity ... sha1+ OK## Loading fdt from FIT Image at 03000000 ...Using 'rootfs@1' configurationTrying 'fdt@1' fdt subimageDescription: Flattened Device Tree blobType: Flat Device TreeCompression: uncompressedData Start: 0x0332661cData Size: 9597 Bytes = 9.4 KiBArchitecture: ARMHash algo: sha1Hash value: da2d17ba0d5a71b5897deec4cb026014f3132185Verifying Hash Integrity ... sha1+ OKBooting using the fdt blob at 0x332661cLoading Kernel Image ... OKLoading Ramdisk to 1b099000, end 1bafe679 ... OKLoading Device Tree to 1b093000, end 1b09857c ... OKStarting kernel ...Uncompressing Linux... done, booting the kernel.Booting Linux on physical CPU 0x0Linux version 3.12.0-xilinx (rigolee[member=167213]Jim) (gcc version 4.8.1 (Sourcery CodeBench Lite 2013.11-53) ) #43 SMP PREEMPT Sat Jul 28 12:14:01 CST 2018CPU: ARMv7 Processor  revision 0 (ARMv7), cr=18c5387dCPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cacheMachine: Xilinx Zynq Platform, model: Xilinx ZynqMemory policy: Data cache writeallocPERCPU: Embedded 8 pages/cpu @c09f1000 s8384 r8192 d16192 u32768Built 1 zonelists in Zone order, mobility grouping on. Total pages: 113792Kernel command line: console=ttyPS0,115200 no_console_suspend, root=/dev/ram rwPID hash table entries: 2048 (order: 1, 8192 bytes)Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)Memory: 437416K/458752K available (4197K kernel code, 255K rwdata, 1716K rodata, 176K init, 179K bss, 21336K reserved, 0K highmem)Virtual kernel memory layout:vector : 0xffff0000 - 0xffff1000 ( 4 kB)fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)vmalloc : 0xdc800000 - 0xff000000 ( 552 MB)lowmem : 0xc0000000 - 0xdc000000 ( 448 MB)pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)modules : 0xbf000000 - 0xbfe00000 ( 14 MB).text : 0xc0008000 - 0xc05ce880 (5915 kB).init : 0xc05cf000 - 0xc05fb0c0 ( 177 kB).data : 0xc05fc000 - 0xc063bd78 ( 256 kB).bss : 0xc063bd84 - 0xc06689a4 ( 180 kB)Preemptible hierarchical RCU implementation.Dump stacks of tasks blocking RCU-preempt GP.RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.NR_IRQS:16 nr_irqs:16 16ps7-slcr mapped to dc802000Zynq clock initsched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286msConsole: colour dummy device 80x30Calibrating delay loop... 1725.23 BogoMIPS (lpj=8626176)pid_max: default: 32768 minimum: 301Mount-cache hash table entries: 512CPU: Testing write buffer coherency: okCPU0: thread -1, cpu 0, socket 0, mpidr 80000000Setting up static identity map for 0xc03fa6b8 - 0xc03fa710L310 cache controller enabledl2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72360000, Cache size: 512 kBCPU1: Booted secondary processorCPU1: thread -1, cpu 1, socket 0, mpidr 80000001Brought up 2 CPUsSMP: Total of 2 processors activated.CPU: All CPU(s) started in SVC mode.devtmpfs: initializedVFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4regulator-dummy: no parametersNET: Registered protocol family 16DMA: preallocated 256 KiB pool for atomic coherent allocationsgpio->base_addr is:0xdc84e000The gpio irq num is:52zynq_gpio e000a000.ps7-gpio: gpio at 0xe000a000 mapped to 0xdc84e000hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.hw-breakpoint: maximum watchpoint size is 4 bytes.zynq_ocm f800c000.ps7-ocmc: ZYNQ OCM pool: 256 KiB @ 0xdc880000bio: create slab <bio-0> at 0vgaarb: loadedSCSI subsystem initializedusbcore: registered new interface driver usbfsusbcore: registered new interface driver hubusbcore: registered new device driver usbpps_core: LinuxPPS API ver. 1 registeredpps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti[member=183778]linux.it>PTP clock support registeredEDAC MC: Ver: 3.0.0NET: Registered protocol family 2TCP established hash table entries: 4096 (order: 3, 32768 bytes)TCP bind hash table entries: 4096 (order: 3, 32768 bytes)TCP: Hash tables configured (established 4096 bind 4096)TCP: reno registeredUDP hash table entries: 256 (order: 1, 8192 bytes)UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)NET: Registered protocol family 1RPC: Registered named UNIX socket transport module.RPC: Registered udp transport module.RPC: Registered tcp transport module.RPC: Registered tcp NFSv4.1 backchannel transport module.Trying to unpack rootfs image as initramfs...rootfs image is not initramfs (no cpio magic); looks like an initrdFreeing initrd memory: 10644K (db099000 - dbafe000)hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters availableNTFS driver 2.1.30 [Flags: R/W].msgmni has been set to 875io scheduler noop registeredio scheduler deadline registeredio scheduler cfq registered (default)DPU:Map vRam to 0xdca00000DPU:Map iReg to 0xdcc00000DPU:Ver=0x20170711dma-pl330 f8003000.ps7-dma: unable to set the seg sizedma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-2364208dma-pl330 f8003000.ps7-dma: DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 6249999) is a xuartpsconsole  enabledxuartps e0001000.serial: failed to get alias id, errno -19e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 6249999) is a xuartpsbrd: module loadedloop: module loadedxspips e0006000.ps7-spi: master is unqueued, this is deprecatedxspips e0006000.ps7-spi: at 0xE0006000 mapped to 0xDC858000, irq=58libphy: XEMACPS mii bus: probedxemacps e000b000.ps7-ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driverehci-pci: EHCI PCI platform driverULPI transceiver vendor/product ID 0x0424/0x0009ULPI integrity check: passed.ULPI transceiver vendor/product ID 0x0424/0x0009ULPI integrity check: passed.xusbps-ehci xusbps-ehci.1: Xilinx PS USB EHCI Host Controllerxusbps-ehci xusbps-ehci.1: new USB bus registered, assigned bus number 1xusbps-ehci xusbps-ehci.1: irq 76, io mem 0x00000000xusbps-ehci xusbps-ehci.1: USB 2.0 started, EHCI 1.00hub 1-0:1.0: USB hub foundhub 1-0:1.0: 1 port detectedusbcore: registered new interface driver usb-storagemousedev: PS/2 mouse device common for all micei2c /dev entries driverrtc-rx8010sj 0-0032: Update timer was detectedrtc-rx8010sj 0-0032: rtc core: registered rtc-rx8010sj as rtc0input: Goodix-TS as /devices/virtual/input/input0xi2cps e0004000.ps7-i2c: 90 kHz mmio e0004000 irq 57zynq-edac f8006000.ps7-ddrc: ecc not enabledsdhci: Secure Digital Host Controller Interface driversdhci: Copyright(c) Pierre Ossmansdhci-pltfm: SDHCI platform and OF driver helperusbcore: registered new interface driver usbhidusbhid: USB HID core driverONFI param page 0 validONFI flash detectedNAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron MT29F8G08ADADAH4), 1024MiB, page size: 2048, OOB size: 64Bad block table found at page 524224, version 0x01Bad block table found at page 524160, version 0x0113 ofpart partitions found on MTD device pl353-nandCreating 13 MTD partitions on "pl353-nand":0x000000000000-0x000000040000 : "Env"0x000000100000-0x000004100000 : "DATA"0x000004100000-0x000004500000 : "Bmp"0x000004500000-0x000004900000 : "Bmp1"0x000004900000-0x000005100000 : "Bit1"0x000005100000-0x000007100000 : "Sys1"0x000007100000-0x00000d500000 : "App1"0x00000d500000-0x00000d900000 : "Bmp2"0x00000d900000-0x00000e100000 : "Bit2"0x00000e100000-0x000010100000 : "Sys2"0x000010100000-0x000016500000 : "App2"0x000016500000-0x00001a800000 : "Reserved"0x00001a800000-0x000040000000 : "User"TCP: cubic registeredNET: Registered protocol family 17Registering SWP/SWPB emulation handlerrtc-rx8010sj 0-0032: setting system clock to 2018-11-10 12:15:08 UTC (1541852108)RAMDISK: gzip image found at block 0VFS: Mounted root (ext2 filesystem) on device 1:0.devtmpfs: mountedFreeing unused kernel memory: 176K (c05cf000 - c05fb000)Starting rcS...++ Mounting filesystem++ Setting up mdev++ Starting ftp daemonrcS Complete<root@rigol>rpcbind: cannot create socket for udp6rpcbind: cannot create socket for tcp62018-11-10 12:15:21: (log.c.166) server started7 2048 16 2 "/dev/fb0"Mount user space to:/userdefault setting by user setRigol Device gadget: Rigol Device readyusbcore: registered new interface driver usbtmcI don't know anything about that world, does anybody know if Xilinx do a complete secure boot process?(and can you tell if they're using it from that output?)