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.
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.
You need bent pins so each pin is independently spruingIf 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.
If you get square pins they might exert enough pressure to make contact all by themselves.
is the upgrade licence file encypted?
Pretty sure Dave mentioned he had oneis the upgrade licence file encypted?
In the programming guide it shows this example of installing a license key:
(https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/?action=dlattach;attach=586757;image)
The key's definitely a lot longer than a key for a DS1054Z. :popcorn:
Does anybody have a license file? Can you look at it and see if the contents look like that?
is the upgrade licence file encypted?
is the upgrade licence file encypted?
The license file is a single line of text as shown above.
"DS5000-2RL@" followed by 128 bytes of key data
Where 2RL seems to be the license type code
Then it seems the hex string is a 1024-bit digital signature of the license code.
Most 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.
Didn't the distributor generate the key though? I assume that means no asym crypto or the key isn't that safe.
Didn't the distributor generate the key though? I assume that means no asym crypto or the key isn't that safe.
They generate them on the Rigol web site.
Rigol could have a private key on there.
U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
I2C: ready
Memory: ECC disabled
DRAM: 448 MiB
DPU: 20170604
NAND: OnDie ECC supported, 1024 MiB
zynq-In: serial
zynq-Out: serial
zynq-Err: serial
Net: Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot: 0
NAND read: device 0 offset 0x4900000, size 0x3591fd
þ
NAND read: device 0 offset 0x4900000, size 0x8
8 bytes read: OK
NAND read: device 0 offset 0x4500000, size 0x12c008
1228808 bytes read: OK
Loading logo, x=310,y=247,width=404,height=89
NAND read: device 0 offset 0x5100000, size 0xd8ebf0
14216176 bytes read: OK
## Loading kernel from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'kernel@1' kernel subimage
Description: Kerstrel Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x030000f8
Data Size: 3302448 Bytes = 3.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00100000
Entry Point: 0x00100000
Hash algo: sha1
Hash value: bece162e8cad943c68714d8eb8020d68e1db896b
Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'ramdisk@1' ramdisk subimage
Description: kerstrel-Update-Ramdisk
Type: RAMDisk Image
Compression: gzip compressed
Data Start: 0x03328c5c
Data Size: 10901113 Bytes = 10.4 MiB
Architecture: ARM
OS: Linux
Load Address: unavailable
Entry Point: unavailable
Hash algo: sha1
Hash value: 55bdcbebccba845da403130143793ee0135e53a1
Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'fdt@1' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x0332661c
Data Size: 9597 Bytes = 9.4 KiB
Architecture: ARM
Hash algo: sha1
Hash value: da2d17ba0d5a71b5897deec4cb026014f3132185
Verifying Hash Integrity ... sha1+ OK
Booting using the fdt blob at 0x332661c
Loading Kernel Image ... OK
Loading Ramdisk to 1b099000, end 1bafe679 ... OK
Loading Device Tree to 1b093000, end 1b09857c ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.12.0-xilinx (rigolee[member=167213]Jim[/member]) (gcc version 4.8.1 (Sourcery CodeBench Lite 2013.11-53) ) #43 SMP PREEMPT Sat Jul 28 12:14:01 CST 2018
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq
Memory policy: Data cache writealloc
PERCPU: Embedded 8 pages/cpu @c09f1000 s8384 r8192 d16192 u32768
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 113792
Kernel command line: console=ttyPS0,115200 no_console_suspend, root=/dev/ram rw
PID 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 16
ps7-slcr mapped to dc802000
Zynq clock init
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 1725.23 BogoMIPS (lpj=8626176)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0xc03fa6b8 - 0xc03fa710
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72360000, Cache size: 512 kB
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
gpio->base_addr is:0xdc84e000
The gpio irq num is:52
zynq_gpio e000a000.ps7-gpio: gpio at 0xe000a000 mapped to 0xdc84e000
hw-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 @ 0xdc880000
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti[member=183778]linux[/member].it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
NET: Registered protocol family 2
TCP 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 registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: 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 initrd
Freeing initrd memory: 10644K (db099000 - dbafe000)
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
NTFS driver 2.1.30 [Flags: R/W].
msgmni has been set to 875
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
DPU:Map vRam to 0xdca00000
DPU:Map iReg to 0xdcc00000
DPU:Ver=0x20170711
dma-pl330 f8003000.ps7-dma: unable to set the seg size
dma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-2364208
dma-pl330 f8003000.ps7-dma: DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 6249999) is a xuartps
console [ttyPS0] enabled
xuartps e0001000.serial: failed to get alias id, errno -19
e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 6249999) is a xuartps
brd: module loaded
loop: module loaded
xspips e0006000.ps7-spi: master is unqueued, this is deprecated
xspips e0006000.ps7-spi: at 0xE0006000 mapped to 0xDC858000, irq=58
libphy: XEMACPS mii bus: probed
xemacps e000b000.ps7-ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
xusbps-ehci xusbps-ehci.1: Xilinx PS USB EHCI Host Controller
xusbps-ehci xusbps-ehci.1: new USB bus registered, assigned bus number 1
xusbps-ehci xusbps-ehci.1: irq 76, io mem 0x00000000
xusbps-ehci xusbps-ehci.1: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-rx8010sj 0-0032: Update timer was detected
rtc-rx8010sj 0-0032: rtc core: registered rtc-rx8010sj as rtc0
input: Goodix-TS as /devices/virtual/input/input0
xi2cps e0004000.ps7-i2c: 90 kHz mmio e0004000 irq 57
zynq-edac f8006000.ps7-ddrc: ecc not enabled
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron MT29F8G08ADADAH4), 1024MiB, page size: 2048, OOB size: 64
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, version 0x01
13 ofpart partitions found on MTD device pl353-nand
Creating 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 registered
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
rtc-rx8010sj 0-0032: setting system clock to 2018-11-10 12:15:08 UTC (1541852108)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 176K (c05cf000 - c05fb000)
Starting rcS...
++ Mounting filesystem
++ Setting up mdev
++ Starting ftp daemon
rcS Complete
<root@rigol>rpcbind: cannot create socket for udp6
rpcbind: cannot create socket for tcp6
2018-11-10 12:15:21: (log.c.166) server started
7 2048 16 2 "/dev/fb0"
Mount user space to:/user
default setting by user set
Rigol Device gadget: Rigol Device ready
usbcore: registered new interface driver usbtmc
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.But that wouldn't stop patching the binaries just like the older Agilent DSO6000 / DSO7000 scopes. I don't think the licensing system is very complicated because it just costs time with very little return.
Dave posted the boot output in another thread (https://www.eevblog.com/forum/blog/new-rigol-scope/msg1954405/#msg1954405).Code: [Select]## Loading kernel from [b]FIT Image[/b] at 03000000 ...
Using 'rootfs@1' configuration
Trying 'kernel@1' kernel subimage
Description: Kerstrel Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x030000f8
Data Size: 3302448 Bytes = 3.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00100000
Entry Point: 0x00100000
[b] Hash algo: sha1
Hash value: bece162e8cad943c68714d8eb8020d68e1db896b
Verifying Hash Integrity ... sha1+ OK[/b]
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.
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.
That just becomes obscurity rather than security. The serial number is just a look up, so they know which public key to use to encrypt the data with. If you were able to find the public key, you can't do much useful with it. I'm picking you want to target the Zync as it whats running linux. Its certainly got secure boot
QuoteThat just becomes obscurity rather than security. The serial number is just a look up, so they know which public key to use to encrypt the data with. If you were able to find the public key, you can't do much useful with it. I'm picking you want to target the Zync as it whats running linux. Its certainly got secure boot
It would prevent a keygen - AIUI the previous riglol hack duplicates Rigol's process for generating a license from the serial number. If the scope's internal process used a key derived from Rigol's serial->key database, then it would not be possible to generate compatible license keys.
@lukier, SHA1 is an hash algorithm, not a digital signing algo! The fact that the NAND blocks are hashed doesn't mean much.
I feel resonably confident that they would have used secure boot.
tools $ file *
axi: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
axi_GP0: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
beeper: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
cfger: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, stripped <——— !!!
checkAXI: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
checkboot: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
dpuTest: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
fram: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
socket: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, stripped <——— !!!
spi2cpld: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
spi2dev: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
spi2k7: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
spi2pll: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
ssd2543: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
touch: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
############################################
#fetch system information from bootloader
############################################
$TOOLS/cfger -i /tmp/sysinfo.txt
#Read Nand Block 0 data
nanddump -s 0 -l 0x40000 -f /tmp/env.bin /dev/mtd0
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-03 23:44 W. Europe Standard Time
NSE: Loaded 148 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 23:44
Completed NSE at 23:44, 0.00s elapsed
Initiating NSE at 23:44
Completed NSE at 23:44, 0.00s elapsed
Initiating ARP Ping Scan at 23:44
Scanning 192.168.2.134 [1 port]
Completed ARP Ping Scan at 23:44, 0.66s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 23:44
Completed Parallel DNS resolution of 1 host. at 23:44, 5.51s elapsed
Initiating SYN Stealth Scan at 23:44
Scanning RIGOL_MS5A********* (192.168.2.134) [1000 ports]
Discovered open port 80/tcp on 192.168.2.134
Discovered open port 111/tcp on 192.168.2.134
Discovered open port 22/tcp on 192.168.2.134
Discovered open port 21/tcp on 192.168.2.134
Discovered open port 5555/tcp on 192.168.2.134
Completed SYN Stealth Scan at 23:44, 0.59s elapsed (1000 total ports)
Initiating Service scan at 23:44
Scanning 5 services on RIGOL_MS5A********* (192.168.2.134)
Completed Service scan at 23:46, 151.31s elapsed (5 services on 1 host)
Initiating OS detection (try #1) against RIGOL_MS5A********* (192.168.2.134)
NSE: Script scanning 192.168.2.134.
Initiating NSE at 23:46
Completed NSE at 23:46, 0.58s elapsed
Initiating NSE at 23:46
Completed NSE at 23:46, 1.04s elapsed
Nmap scan report for RIGOL_MS5A********* (192.168.2.134)
Host is up (0.0025s latency).
Not shown: 995 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp BusyBox ftpd (D-Link DCS-932L IP-Cam camera)
22/tcp open ssh OpenSSH 6.0 (protocol 2.0)
| ssh-hostkey:
| 1024 dc:eb:8b:b2:55:43:48:10:0c:7b:49:70:74:**:**:** (DSA)
| 2048 e4:02:cd:a8:fd:c7:68:54:f4:26:49:0a:50:**:**:** (RSA)
|_ 256 6f:c4:43:18:a3:95:f1:88:4f:f1:73:28:39:**:**:** (ECDSA)
80/tcp open http lighttpd 1.4.33
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: lighttpd/1.4.33
|_http-title: 400 - Bad Request
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 395183 1 873/udp
| 395183 1 877/tcp
| 395184 1 873/udp
| 395184 1 877/tcp
| 395185 1 873/udp
|_ 395185 1 877/tcp
5555/tcp open freeciv?
MAC Address: **:**:**:**:**:** (Rigol Technologies)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Uptime guess: 0.015 days (since Mon Dec 03 23:25:16 2018)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=259 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: Device: webcam; CPE: cpe:/h:dlink:dcs-932l
TRACEROUTE
HOP RTT ADDRESS
1 2.52 ms RIGOL_MS5A******** (192.168.2.134)
NSE: Script Post-scanning.
Initiating NSE at 23:46
Completed NSE at 23:46, 0.00s elapsed
Initiating NSE at 23:46
Completed NSE at 23:46, 0.00s elapsed
Read data files from: C:\Program Files (x86)\Nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 164.92 seconds
Raw packets sent: 1026 (46.790KB) | Rcvd: 1016 (41.042KB)
I got some firmware from some undisclosed "Address" in the interwebs, please don't ask for binaries and don't tell :)
I can brief you on some interesting snippets I found after mounting UBIFS mount points and whatnot from the firmware, please notice which binaries are stripped of symbols:
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
# The default requires explicit activation of protocol 1
#Protocol 2
# HostKey for protocol version 1
#HostKey /etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh_host_rsa_key
#HostKey /etc/ssh_host_dsa_key
#HostKey /etc/ssh_host_ecdsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#RSAAuthentication yes
#PubkeyAuthentication yes
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys
# For this to work you will also need host keys in /etc/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none
# no default banner path
#Banner none
# override default of no subsystems
Subsystem sftp /usr/lib/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server
[0x00000000]> cat /root/etc/passwd
root:$1$qC.CEbjC$SVJyqm.IG.gkElhaeM.FD0:0:0:root:/root:/bin/sh
[0x00000000]> cat /root/etc/shadow
[0x00000000]> cat /root/etc/ssh_config
# $OpenBSD: ssh_config,v 1.26 2010/01/11 01:39:46 dtucker Exp $
# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.
# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.
# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
@lukier, SHA1 is an hash algorithm, not a digital signing algo! The fact that the NAND blocks are hashed doesn't mean much.
Yep: root:$1$qC.CEbjC$SVJyqm.IG.gkElhaeM.FD0:0:0:root:/root:/bin/sh ;)
Queue John the Ripper
This all sounds so lame it must be intentional :-DD Even pricing-wise the base 70 MHz model is more expensive than Keysight DSOX1000. Hackability as a marketing feature :D
I wouldn't be surprised! That's where EEVBLOG does a wonderful (and totally free) job for these manufacturers.
Yada Yada... Look up my "Project Yaigol" post for details.
root:$1$qC.CEbjC$SVJyqm.IG.gkElhaeM.FD0:0:0:root:/root:/bin/sh ;)
user: root
pass: root
login as: root
root@192.168.2.134's password:
<root@rigol>cd /
<root@rigol>df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 31.0M 21.9M 9.1M 71% /
devtmpfs 213.6M 0 213.6M 0% /dev
none 100.0M 284.0K 99.7M 0% /tmp
/dev/ubi6_0 85.1M 69.6M 15.6M 82% /rigol
/dev/ubi1_0 37.2M 276.0K 35.0M 1% /rigol/data
/dev/ubi12_0 516.6M 67.3M 444.6M 13% /user
<root@rigol>ls
bin home lost+found proc sys usr
checkapp lib media rigol tmp var
dev licenses mnt root ubifs-util
etc linuxrc opt sbin user
<root@rigol>
Can you get me a memdump? /dev/mem
I think I am going to need some help with the RAM dump since Linux have made copying the RAM more difficult in newer versions.
For those playing along at home the scope report the Linux version as “3.12.0-xilinx”
Any suggestions how to dump the RAM over SSH?
I completely forgot that the scope had a USB port.
I completely forgot that the scope had a USB port.
It's the problem with these advanced equipments that should only be connected to the internet! They also have USB interface... beware SEC Consult!
Im quite suprized. They certainly dont' seem to have made too much effort 'so far' to secure things.
Im quite suprized. They certainly dont' seem to have made too much effort 'so far' to secure things.Why are you surprised? According to Dave a lot of functionality needs at least some attention. Securing things usually is last on the list. Get the product out first. Rigol can always choose to plug holes in later firmware releases if necessary.
Indeed, there are a ton of similarities with that post against what I did a few days ago, thanks for sharing @tv84 :)
.data:000196D4 AES_KEY DCD 0xFECFD8BA ; DATA XREF: sub_B174+34o
.data:000196D8 dword_196D8 DCD 0xC4B5AABB
.data:000196DC dword_196DC DCD 0xBFD4D8C3
.data:000196E0 dword_196E0 DCD 0xDDBEFDCA
Indeed, there are a ton of similarities with that post against what I did a few days ago, thanks for sharing @tv84 :)
So, cfger is indeed the encryptor/decryptor of the shell scripts. It uses AES encryption.
<root@rigol>./cfger -h
-r name:read the value of name
-i file:read model,version,date to file
-c name value: compare bwtween the value of name with value
-s name value: set the value of name
-t file: remove the all zero of the file
-d input output: decrypt the input to output by aes
-e input output: crypt the input to output by aes
-h : show this help information
Enjoy: :popcorn:Code: [Select].data:000196D4 AES_KEY DCD 0xFECFD8BA ; DATA XREF: sub_B174+34o
.data:000196D8 dword_196D8 DCD 0xC4B5AABB
.data:000196DC dword_196DC DCD 0xBFD4D8C3
.data:000196E0 dword_196E0 DCD 0xDDBEFDCA
Here are the 2 scripts decrypted with AES-CBC.
AES_KEY: BAD8CFFEBBAAB5C4C3D8D4BFCAFDBEDD
Im quite suprized. They certainly dont' seem to have made too much effort 'so far' to secure things.Why? A large part of their business is built on hacking.
I bet sales of the DS1054Z paid for a lot of the development of that ASIC.
So if someone can get such a dump (from the lucky ones having the real device already on their benches), it will inform my analysis. I know this information is rather fragmented and incomplete, but I'm still putting the pieces together and have more juicy bits for future posts.
What would be interesting to know, is if the AES_KEY is the same for all machines, or if each one is unique.
I received an unsolicted Private message last night. It was from a user with NO posts, and just registered yesterday. I'm sure they are reading the thread. Their github profile suggests they are in China. but who knows. I checked the github repo, and i coud'nt find anything relevent.. Anyone else get this message.
Hello, I have cracked the MSO5074 into 350MHz model version, and I will publish it to my github (http://github.com/__deleted__ (http://github.com/__deleted__)) until all option unlocked. But I did a wrong thing: I erased my scope's option FRAM. So If you have buy a MSO5074, I can upgrade it's bandwidth, and I want a FRAM dump from your scope to reverse the option part for this scope. Thanks!
You can contact me by this mail: deleted@gmail.com
"Well, I have patched the firmware, let it jump out license verify produce. But I can't make it public until next year March. Because Rigol sold out about less than 300 units now.
In fact I'm working on my friend's scope and I havent ordered yet (lack of money...Im just a ungraduated). I m wonder if I make it public prematurely, maybe they will fix it and it can't be cracked anymore.
Btw, there's no keygen for 5000 series oscilloscope because it cant be realize. The only way to crack it is to patch firmware.
The detail of crack this scope I will
publish it to my github when my scope is successfully cracked."
I just got an email from someone (who is not anonymous) that claims to have cracked the scope and is seeing performance up to 1GHz after setting the front end chip to 4GHz bandwidth.
I just got an email from someone (who is not anonymous) that claims to have cracked the scope and is seeing performance up to 1GHz after setting the front end chip to 4GHz bandwidth.
I just got an email from someone (who is not anonymous) that claims to have cracked the scope and is seeing performance up to 1GHz after setting the front end chip to 4GHz bandwidth.
The problem with claims is that they are just claims untill there is something to substainate them.
so does this mean that we're going to have another big wave of scopes with shitty hardware design choices (such as the 2mV/div and 1mV/div which are zoomed 8 bit data) and shitty software design choices (such as how decoding is displayed) where no complaints are allowed because shut up they're cheap and hackable?Quite possibly, we've seen this happen before. ::)
Im quite suprized. They certainly dont' seem to have made too much effort 'so far' to secure things.Why are you surprised? According to Dave a lot of functionality needs at least some attention. Securing things usually is last on the list. Get the product out first. Rigol can always choose to plug holes in later firmware releases if necessary.
so does this mean that we're going to have another big wave of scopes with shitty hardware design choices (such as the 2mV/div and 1mV/div which are zoomed 8 bit data) and shitty software design choices (such as how decoding is displayed) where no complaints are allowed because shut up they're cheap and hackable?Quite possibly, we've seen this happen before. ::)
Ok so you missed the member being banned for daring to question the capabilities of the forums favorite DSO.so does this mean that we're going to have another big wave of scopes with shitty hardware design choices (such as the 2mV/div and 1mV/div which are zoomed 8 bit data) and shitty software design choices (such as how decoding is displayed) where no complaints are allowed because shut up they're cheap and hackable?Quite possibly, we've seen this happen before. ::)
And the next big Siglent release will probably come with a buttload of shilling and aggressive forum posts from people with a financial stake in their sales, what's new?
Gentlemen, please discuss this in the generic MSO5000 thread.
The problem with claims is that they are just claims untill there is something to substainate them.
From what we've seen so far it doesn't look like it will be difficult for somebody who really knows the Xilinx system.
OTOH if it can be unlocked to 1GHz then Rigol has a real problem on its hands: How on earth are they going to manufacture enough of them?
Even at a low price having 1GHz of bandwidth without real 50 Ohm inputs is going to be a problem. Then again the same hack may work on the MSO7000.The problem with claims is that they are just claims untill there is something to substainate them.From what we've seen so far it doesn't look like it will be difficult for somebody who really knows the Xilinx system.
OTOH if it can be unlocked to 1GHz then Rigol has a real problem on its hands: How on earth are they going to manufacture enough of them?
Which is a bass ackwards way of developing and shipping an appliance with a network connection no matter how you look at it.It's always the same people singing the same song, isn't it? ::)
And the next big Siglent release will probably come with a buttload of shilling and aggressive forum posts from people with a financial stake in their sales, what's new?
Obviously I'm not going to say who they are ...I wonder if Banksy has anything to do with all this. ;D
We actually plan to release it after the RIGOL fix their bugs...
Maybe better to wait til the firmware has improved, so there's a hack for a better FW in case future versions get locked down more effectivelyWe actually plan to release it after the RIGOL fix their bugs...
I can not believe you're refusing to release the hack method.
We actually plan to release it after the RIGOL fix their bugs...Which means... NEVER :-DD
Here are their screen shots of a 100MHz square wave and the FFT
Obviously I'm not going to say who they are, but they are sending me something (not related to this) for a video, and went, "oh, BTW, we hacked the MSO5000". It was a friend on their design team who cracked it. They seem legit.
OK I admit it.... I am the anonymous who patched Hanxiao's oscillscope...Yesterday we made a successful crack to unlock all options and 350Mhz bandwidth.Taking things off the internet isn't really a thing that exists. It's out here, for better or worse.
So...It is pity to made this thing public early...I have to order one now and create a repository to publish our cracking produce...
I request to set this topic hidden in this forum, if RIGOL saw that thread, there would be no cracking at all! I recommend don't discuss this topic until half-year passed...
rgwan,
Your group is not the only ones who have claimed to have hacked the scope. Others have already made the same claims. The methodology for hacking it, is to find where the firmware checks the features, and just return true. the fact that you posted it first, really doesnt make much difference, someone will have.
You can assume that multiple Rigol dealers have read this, and that this information is already in the hands of Rigol. What rigol choose to do, will be interesting. They historically have not made any attempts to stop so-called hacking. they may see it as a way to actually improve their sales. its entirely possible that the archtiecture was designed so it coudl be hacked.
Your saying it was hacked to 350Mhz, however it seems that Hanxiao was saying 1Ghz? is that correct?
Even if this thread was removed, its still the internet and its gone. you can't make it go away.
First, No... I did not make any statement on the analog bandwidth of it. The test is based on an all license on MSO5074 Unit.
Second, the efforts put into hacking is much harder than you thought. They did a fairly good job on license protection (but not the system as a whole).
I wish to see posts from other team that reach this far :P
I recommend don't discuss this topic until half-year passed...
rgwan,
Your group is not the only ones who have claimed to have hacked the scope. Others have already made the same claims. The methodology for hacking it, is to find where the firmware checks the features, and just return true. the fact that you posted it first, really doesnt make much difference, someone will have.
You can assume that multiple Rigol dealers have read this, and that this information is already in the hands of Rigol. What rigol choose to do, will be interesting. They historically have not made any attempts to stop so-called hacking. they may see it as a way to actually improve their sales. its entirely possible that the archtiecture was designed so it coudl be hacked.
Your saying it was hacked to 350Mhz, however it seems that Hanxiao was saying 1Ghz? is that correct?
Even if this thread was removed, its still the internet and its gone. you can't make it go away.
I request to set this topic hidden in this forum, if RIGOL saw that thread, there would be no cracking at all! I recommend don't discuss this topic until half-year passed...
Once again, I would like to recommend the administrator in this forum hide this thread. It is too dangerous. And Rigol's new 1000Z-S series seems can't be unlock any more. I don't want to see this happen again.
I request to set this topic hidden in this forum, if RIGOL saw that thread, there would be no cracking at all! I recommend don't discuss this topic until half-year passed...
Sorry but we don't hide threads here.
I'll happily remove the images I got, but I'm not going to remove anyone else's images or posts, they'll have to do that themselves.
Also thanks for RIGOL to provide such this relatively cheap instrument with such high performance.
8256485683450c0341861cd090fab646 YOU UNDERSTAND
so does this mean that we're going to have another big wave of scopes whereno complaints are allowedwhiny complaints seem childish because shut up they're cheap and hackable and nobody's forcing you to use one?
The other way o look at is is: If this is hackable then the bean counters at Rigol will see the sales figures of the base model and think, "Why would we try to stop that?"
30A989AFC82C0A21139573591DE4E5FF37994F7D1506A9ACF2B5997005C2649F
Without any evidence of a hack, the people claiming it are losing face ( 丢脸 ) very quickly.
I dont' have a scope yet ( get it in Jan ), and when i do, i'll be keen to see how the hacks work, but if i use the features, i'll just be doign the boring thing and paying for it. ( because thats the right thing to do ).
That's the current hour/date in the scope.
That's the current hour/date in the scope.
No, it said ‘Build date’ on the photo
If indeed Rigol pursue the market this way, and they monitor these forums...
One question: If this thing runs Linux and has a shell account then can it run batch files, etc?Forum member RHB is having a long term plan for something like that. A lot of scopes run on the Zync platform nowadays so except for the ADCs and display size many oscilloscopes are practically identical. Don't get excited yet because writing firmware for an oscilloscope is a massive task but once there is a core feature set then it shouldn't be hard to port it to different hardware platforms.
What's installed in the system? Is there a C compiler?
Can you upload executable files and get it to do new things that way?
Well thats really strange. They said that it is trival. So, how about you to ask them for the reason why they dont choose to release it now?
Btw, you have said that you re interested in embedded system security, why do you dont analyze firmware yourself? The process of analysing is more fun than the answer. So, dont hesitate to wait our answer anymore. Try to find your own! LOL
The Christmas gift for all Rigol fans out here:
Go to /rigol/shell/start.sh
and add the "-fullopt" to the command line that executes appEntry (before the &).
PS: And it's not an hack. It's a feature!
How odd! That was remarkably easy to do...
Would be interested to find out if this also turns a 2 channel into 4 channel. I assume the same technique would work on a MSO7000?Was also thinking the same thing, although, for the US$99.00 difference, you get the two additional 350 MHz probes. That’s assuming they perform well for the price.
Can’t say if it turns a 2 channel into a 4 channel, mine is the 5074. I paid the extra 90 euros for a 4 channel as that way I got warranty on all 4 channels and an extra couple of probes. I would imagine it enables 4 channels though, can’t see why it wouldn’t.I don’t think there are any two-channel 7000 series scopes. The base model is the 7014 four channel.
Anybody with a 7000 series can give it a go, it’s a very simple process.
The Christmas gift for all Rigol fans out here:Does the license screen show the options as PERMANENT or maybe it is a 30-day demo activation?
Go to /rigol/shell/start.sh
and add the "-fullopt" to the command line that executes appEntry (before the &).
PS: And it's not an hack. It's a feature!
The Christmas gift for all Rigol fans out here:Does the license screen show the options as PERMANENT or maybe it is a 30-day demo activation?
Go to /rigol/shell/start.sh
and add the "-fullopt" to the command line that executes appEntry (before the &).
PS: And it's not an hack. It's a feature!
Does the license screen show the options as PERMANENT or maybe it is a 30-day demo activation?
Things like the AWG's and power analysis are shown as not enabled - BUT they work.
Does the license screen show the options as PERMANENT or maybe it is a 30-day demo activation?
It's a feature so, I think, it's independent from the license scheme. But TopLoser may provide a license menu printscreen.
If I understood correctly, the 4CH option is not activated.
BTW, what is the BND option? Was it activated?Things like the AWG's and power analysis are shown as not enabled - BUT they work.
If that's the case, then probably all is activated... Can someone test each of the Options to see if they are active?
All that I tested is activated.
00 "BW1T2" DS7000
01 "BW1T3" DS7000
02 "BW1T5" DS7000
03 "BW2T3" DS7000
04 "BW2T5" DS7000
05 "BW3T5" DS7000
06 "MSO"
07 "2RL" MSO5000 DS7000
08 "5RL" DS7000
09 "BND" = COMP + EMBD + AUTO + FLEX + AUDIO + AERO + PWR + AWG
10 "COMP" MSO5000 DS7000
11 "EMBD" MSO5000 DS7000
12 "AUTO" MSO5000 DS7000
13 "FLEX" MSO5000 DS7000
14 "AUDIO MSO5000 DS7000
15 "SENSOR
16 "AERO" MSO5000 DS7000
17 "ARINC"
18 "AWG" MSO5000
19 "JITTER"
20 "MASK"
21 "PWR" MSO5000 DS7000
22 "DVM"
23 "CTR"
24 "EDK"
25 "4CH"
26 "BW07T1" MSO5000
27 "BW07T2" MSO5000
28 "BW07T3" MSO5000
29 "BW07T5"
Can’t say if it turns a 2 channel into a 4 channel, mine is the 5074. I paid the extra 90 euros for a 4 channel as that way I got warranty on all 4 channels and an extra couple of probes. I would imagine it enables 4 channels though, can’t see why it wouldn’t.I don’t think there are any two-channel 7000 series scopes. The base model is the 7014 four channel.
Anybody with a 7000 series can give it a go, it’s a very simple process.
How odd! That was remarkably easy to do...
Disappointed? You wanted more of a fight...? :popcorn:
Tried this with our DS7014, now has full 500MHz bandwidth and 500M memory...
Well thats really strange. They said that it is trival. So, how about you to ask them for the reason why they dont choose to release it now?
Btw, you have said that you re interested in embedded system security, why do you dont analyze firmware yourself? The process of analysing is more fun than the answer. So, dont hesitate to wait our answer anymore. Try to find your own! LOL
To keep Rigol happy, if it wasn't for this hack I would not be considering a Rigol as my next scope, more likely RTB2000 or RTM3000 (discounted the Keysight now) but with gritted teeth due to the ridiculous option pricing). Now firmly back in my option list (just can't decide if 5000 or 7000).you were considering a scope with a 10bit adc, now you are considering a scope that at the max amplification will be a 5-6 bit scope (1mV/div is 5mV/div digitally zoomed!) then look at how the decode and search is implemented
you were considering a scope with a 10bit adc, now you are considering a scope that at the max amplification will be a 5-6 bit scope
£970 vs £2500 (incl. the 50% PK1 pack) is quite persuasive but I appreciate that the R&S is the next level up. And that comparison doesn't cover bandwidth.
I wouldn't call protocol decoding which is actually working a 'little extra' if you need this kind of functionality. It is kind off buying a car without windscreen whipers. If it never rains that will be OK but if you drive through rain regulary then such a car will become useless real quick.£970 vs £2500 (incl. the 50% PK1 pack) is quite persuasive but I appreciate that the R&S is the next level up. And that comparison doesn't cover bandwidth.Yep. The next step up from this is now a huge difference in price. You'll pay dearly for those little extras.
I wouldn't call protocol decoding which is actually working a 'little extra' if you need this kind of functionality.
It is kind off buying a car without windscreen whipers. If it never rains that will be OK but if you drive through rain regulary then such a car will become useless real quick.
Lots of people genuinely don't need it.
Tried this with our DS7014, now has full 500MHz bandwidth and 500M memory...
Lots of people genuinely don't need it.
Most people actually do not need new scope at all, but then suddenly something black with pink ring around female connector surfaces... Pretty dirty (https://www.eevblog.com/forum/blog/new-rigol-scope/msg1954405/#msg1954405) move!
Channel 3 = Input channel or Pay-TV channel? :)
If they patch the bugs, and don't fully close the hacking options, I'll replace both my older Teks with them without blinking.
Any news on whether the hack upgrades the bandwidth?
Nope, there's only root under /etc/passwd and the sshd_config is all commented out except UsePrivilegeSeparation no directive. Shadow is empty.They don't seem to have disabled key based authentication, so it might be possible to drop a public key into ~root/.ssh/authorized_keys and used that to circumvent the password check for ssh. Assuming you can write to ~root/.ssh.
It’s just an old marketing trick.
I am quite confident that the first 'claim' of the hack ( though unverified ) was exactly this.
verification on the hack
verification on the hack
It's a built-in feature. Not an hack!
-“It appears Rigol’s engineers are designing their products to capitalize on the hacker’s proclivity to buy their tools to get the ‘free’ upgrade. This, of course, sounds just slightly insane, but no one seems to mind.”
Write my words on the wall: no conspiracy marketing tricks here, all of this is just because the Chinese do mot know any better than copy each other whitout understanding how the code they copy works. I predict we will contunue see stupid things lke this one for the years ahead.I sense too much xenophobia in this post...
Write my words on the wall: no conspiracy marketing tricks here, all of this is just because the Chinese do mot know any better than copy each other whitout understanding how the code they copy works. I predict we will contunue see stupid things lke this one for the years ahead.I sense too much xenophobia in this post...
I don't think he's afraid of the chinese, that's ridiculous. That's a horribly stupid word people started over using. He's just racist against the chinese.No it is absolutely not ridiculous. But this is OT in this thread (and perhaps even on this forum altogether).
Broad brush generalisations about one races abillitys are just that. Generalisations.It is not about race but about how a country is being run. The Chinese educational system for example supresses critical and out-of-the-box thinking. Basically killing any creativity needed to come up with a novel product.
The Chinese educational system for example supresses critical and out-of-the-box thinking.
The Chinese educational system for example supresses critical and out-of-the-box thinking. Basically killing any creativity needed to come up with a novel product.
Some interesting inventions that the chinese were responsible for included;
Paper, Movable type printing, GunPowder, The compass, Alcohol, Clocks, Tea Production, Silk, Umbrellas, Iron Smelthing, Bronze, Kites, Growing food in rows, Toothbrushes, and paper money.
Paper, Movable type printing, GunPowder, The compass, Alcohol, Clocks, Tea Production, Silk, Umbrellas, Iron Smelthing, Bronze, Kites, Growing food in rows, Toothbrushes, and paper money.:palm: The Egyptians build pyramids long before that. Look at them today. Roman empire: same story. You have to look at the more recent history to see why the Chinese need to catch up so much when it comes to engineering and producing a good product.
Certainly not in this thread. Take it elsewhere please?
I think its helpful in the background information for working out why Rigol have released a product in the way they have.
Rigol needs to recover the $$$ from the custom ASIC R&D and using them in as many models as possible makes a lot of sense
Couple DS7000s we got at work today. Walked right in. SCP'd some nice screen saver images over while I was in there. Being they're work machines, I didn't want to run right into using --fullopt. Instead, prolly spend Monday picking through what that touches.
Confirming the rather funny ssh root/root situation.
Couple DS7000s we got at work today. Walked right in. SCP'd some nice screen saver images over while I was in there. Being they're work machines, I didn't want to run right into using --fullopt. Instead, prolly spend Monday picking through what that touches.
Eyeballing a DS5000 right now. Dim screen reports have me a little worried though. It's a different screen than the 7k, so can't use it for reference (which, in person, is fairly decent screen wise).
Those BW strcpy's are a little funny. 4G.....Rigol seems pretty optimistic in the future it seems :P
Now with info at hand, I'm left wondering do I go MSO7x or MSO5x.
@TopLoser
Thank you for your description. With Putty, I can successfully connect to my MSO5104. It answers the command *IDN? correctly. But I have not been able to gain 'root' access to proceed with the other steps. Can you help me?
Thank you.
Martin
Thank you for your description. With Putty, I can successfully connect to my MSO5104. It answers the command *IDN? correctly.
Guys,
thank you for your speedy replies.
With Putty set to SSH and port 22, I get the reply 'login as:'.
When I enter 'admin', I get the following request: 'admin@'IP address of my scope' password:'.
When I enter 'rigol' I get the reply 'Access denied.'
I thought this was the standard user name and password to be used.
I appreciate your patience with me and look forward to your replies.
Martin
Has someone tried to verify if the "upgrade" enables also the other two channels on the MSO5XX2? ^-^
when it says login as: use rootwhen it says "login as" use: root
when it asks for password: use root
when it says login as: use rootwhen it says "login as" use: root
when it asks for password: use root
when it asks for "password" use: root
when it says login as: use rootwhen it says "login as" use: root
when it asks for password: use root
when it asks for "password" use: root
Dunno why, seeing this thread title with the word "hacking" and reading these replies, made me chuckle. :-DD
I’m not sure it’s worth saving 90 euros to find out the hard way. Buy the 4 channel model and you get 2 extra 350MHz probes and a warranty that covers all 4 channels.
I am a little concerned about all this "MSO5k is dim" stuff though.It looks like everybody wants a more challenging hack... Make the LCD LED backlight adjustable, it might be an interesting hack project
I had the same thought about the LCD screen. It's great that their scope can be hacked. Too bad you can't see the wiggly lines. Question is.... How did that get out of the door like that? Someone at Rigol must of said to themselves "Geezzz that display is kinda dark is it not?"
Hi,
The Display is not too dark :
https://www.eevblog.com/forum/blog/new-rigol-scope/440/ (https://www.eevblog.com/forum/blog/new-rigol-scope/440/)
(post #440)
Hmm, doesn't seem too bad!LeCroy WS3000 = Siglent SDS3000.......now quite old model, both versions updated to X versions with faster WFMS and greater mem depth.
Sort of hard to tell with all the different exposures :P But next to a Lecroy gives some reference.
With all options "for free" you can save a little bit more and buy the 5072 instead the 5074.
...if you've got some spare 350Mhz probes for the other two channels.
The Siglent SDS1104X-E seems sufficient for my needs. Any reason to buy the Rigol MSO5074 and then unlock features?
With all options "for free" you can save a little bit more and buy the 5072 instead the 5074.Is that guaranteed?
Only the 200 and 350Mhz models are on stock, i.e. by batronix.
With all options "for free" you can save a little bit more and buy the 5072 instead the 5074.
They'll be dual differential output (LVDS or ECL) comparators. Shouldn't be too hard to find
Is that guaranteed?
They'll be dual differential output (LVDS or ECL) comparators. Shouldn't be too hard to find
ADCMP567 a possibility? 2 channel, right number of pins.
ADCMP567 has 32 pins , x-ray shows 24They'll be dual differential output (LVDS or ECL) comparators. Shouldn't be too hard to find
ADCMP567 a possibility? 2 channel, right number of pins.
ADCMP567 has 32 pins , x-ray shows 24They'll be dual differential output (LVDS or ECL) comparators. Shouldn't be too hard to find
ADCMP567 a possibility? 2 channel, right number of pins.
All the pinouts I can see are consistent with LMH7322ADCMP567 has 32 pins , x-ray shows 24They'll be dual differential output (LVDS or ECL) comparators. Shouldn't be too hard to find
ADCMP567 a possibility? 2 channel, right number of pins.
I Can't count, sorry.
Closer xray attached. I can get closer and tweak settings if it help.
The Christmas gift for all Rigol fans out here:
...
PS: And it's not an hack. It's a feature!
Anybody fancy guessing what these 8 (identical I assume) IC's might be? Or do I have to get all medieval on it, no screws or clips unfortunately...
Had a quick look at the 50 way logic connector while having coffee
...
D0-7V X X D8-15 VREF 10:1 INPUT +/- 1V5
...
For the people wondering about the MSO5072 being "upgradeable" to 4ch via the magic flag... all that needs to be said is: yep ;)
The hackers are paying the regular price, it's all the businesses and educational institutions that are paying extra.
Quote from: Fungus link=topic=154682.msg2058286#msg2058286The hackers are paying the regular price, it's all the businesses and educational institutions that are paying extra.
I"m not so sure. Let's wait until the real hacking begins.
The hackers are paying the regular price, it's all the businesses and educational institutions that are paying extra.I'm pretty sure sane businesses and educational institutes are going to wait until the hobbyists bought enough units so Rigol finishes the firmware. It also depends on whether Rigol blocks the extremely simple workaround (it isn't even a hack) to enable all features in a future firmware update.
I feel like removing the firmware hack would tank potential hobbyist sales? This might not be much, but again, in a world where hobbyists aren't buying the high end features, and institutions are, it's just icing on the cake to attract that market.When I read the posts in the test equipment section I get the feeling there are quite a few hobbyists out there which spend several $k on a single piece test equipment. This market isn't big but it does seem to exist.
I guess Rigol and it's big distributors are watching the market, observing and going to conclude whether next move will be to lock or keep it open.
I am between two chairs…
Buying the option bundle which costs about 700€ incl. tax don´t worry me.
The memory upgrade.... I´m not interested in - 100M standard is more than enough.
But the bandwith upgrades..
The price killing me as an owner of a 5074.
Buying the options but hacking the bandwith, this is in my mind, weird… ;)
I am between two chairs…I don't get it. You bought this for private use didn't you? If yes, then hack it and be done with it.
Buying the option bundle which costs about 700€ incl. tax don´t worry me.
The memory upgrade.... I´m not interested in - 100M standard is more than enough.
But the bandwith upgrades..
The price killing me as an owner of a 5074.
Buying the options but hacking the bandwith, this is in my mind, weird… ;)
dmesg
cat /proc/cpuinfo
lspci
lsusb
df
cat /proc/mtd
I'm particularly interested in the output ofCode: [Select]dmesg
cat /proc/cpuinfo
lspci
lsusb
df
cat /proc/mtd
<root@rigol>dmesg
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq
Memory policy: Data cache writealloc
On node 0 totalpages: 114688
free_area_init_node: node 0, pgdat c0631c80, node_mem_map c0669000
Normal zone: 896 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 114688 pages, LIFO batch:31
PERCPU: Embedded 8 pages/cpu @c09f1000 s8384 r8192 d16192 u32768
pcpu-alloc: s8384 r8192 d16192 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 113792
Kernel command line: console=ttyPS0,115200 no_console_suspend, root=/dev/ram rw
PID 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 16
ps7-slcr mapped to dc802000
Zynq clock init
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 1725.23 BogoMIPS (lpj=8626176)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0xc03fa6b8 - 0xc03fa710
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72360000, Cache size: 512 kB
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
gpio->base_addr is:0xdc84e000
The gpio irq num is:52
zynq_gpio e000a000.ps7-gpio: gpio at 0xe000a000 mapped to 0xdc84e000
hw-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 @ 0xdc880000
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
NET: Registered protocol family 2
TCP 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 registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
PCI: CLS 0 bytes, default 64
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 10644K (db099000 - dbafe000)
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
NTFS driver 2.1.30 [Flags: R/W].
msgmni has been set to 875
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
DPU:Map vRam to 0xdca00000
DPU:Map iReg to 0xdcc00000
DPU:Ver=0x20170711
dma-pl330 f8003000.ps7-dma: unable to set the seg size
dma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-2364208
dma-pl330 f8003000.ps7-dma: DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 6249999) is a xuartps
console [ttyPS0] enabled
xuartps e0001000.serial: failed to get alias id, errno -19
e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 6249999) is a xuartps
brd: module loaded
loop: module loaded
xspips e0006000.ps7-spi: master is unqueued, this is deprecated
xspips e0006000.ps7-spi: at 0xE0006000 mapped to 0xDC858000, irq=58
libphy: XEMACPS mii bus: probed
xemacps e000b000.ps7-ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
xusbps-ehci xusbps-ehci.1: Xilinx PS USB EHCI Host Controller
xusbps-ehci xusbps-ehci.1: new USB bus registered, assigned bus number 1
xusbps-ehci xusbps-ehci.1: irq 76, io mem 0x00000000
xusbps-ehci xusbps-ehci.1: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-rx8010sj 0-0032: Update timer was detected
rtc-rx8010sj 0-0032: rtc core: registered rtc-rx8010sj as rtc0
input: Goodix-TS as /devices/virtual/input/input0
xi2cps e0004000.ps7-i2c: 90 kHz mmio e0004000 irq 57
zynq-edac f8006000.ps7-ddrc: ecc not enabled
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron MT29F8G08ADADAH4), 1024MiB, page size: 2048, OOB size: 64
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, version 0x01
13 ofpart partitions found on MTD device pl353-nand
Creating 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 registered
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
rtc-rx8010sj 0-0032: setting system clock to 2018-12-23 22:14:55 UTC (1545603295)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 176K (c05cf000 - c05fb000)
UBI: attaching mtd6 to ubi6
UBI: scanning is finished
UBI warning: print_rsvd_warning: cannot reserve enough PEBs for bad PEB handling, reserved 19, need 160
UBI: attached mtd6 (name "App1", size 100 MiB) to ubi6
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 800, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 137759694
UBI: available PEBs: 0, total reserved PEBs: 800, PEBs reserved for bad PEB handling: 19
UBI: background thread "ubi_bgt6d" started, PID 655
UBIFS: background thread "ubifs_bgt6_0" started, PID 658
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 6, volume 0, name "app"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 97263616 bytes (92 MiB, 766 LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
UBIFS: reserved for root: 0 bytes (0 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 29D18BC9-40D5-47EB-8093-D75BB394A334, small LPT model
UBI: attaching mtd1 to ubi1
UBI: scanning is finished
UBI: attached mtd1 (name "DATA", size 64 MiB) to ubi1
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 512, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 1383059050
UBI: available PEBs: 0, total reserved PEBs: 512, PEBs reserved for bad PEB handling: 160
UBI: background thread "ubi_bgt1d" started, PID 687
UBIFS: background thread "ubifs_bgt1_0" started, PID 691
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 1, volume 0, name "DATA"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 42917888 bytes (40 MiB, 338 LEBs), journal size 2158592 bytes (2 MiB, 17 LEBs)
UBIFS: reserved for root: 2027117 bytes (1979 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 678F0810-83AE-49F3-AD8C-BB561AFDEDBD, small LPT model
UBI: attaching mtd12 to ubi12
UBI: scanning is finished
UBI: attached mtd12 (name "User", size 600 MiB) to ubi12
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 4796, bad PEBs: 4, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1737885595
UBI: available PEBs: 0, total reserved PEBs: 4796, PEBs reserved for bad PEB handling: 156
UBI: background thread "ubi_bgt12d" started, PID 728
UBIFS: background thread "ubifs_bgt12_0" started, PID 732
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 12, volume 0, name "USER"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 586502144 bytes (559 MiB, 4619 LEBs), journal size 29331456 bytes (27 MiB, 231 LEBs)
UBIFS: reserved for root: 4952683 bytes (4836 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 7C7DEB0E-5611-4D11-9900-4290138ACF6B, small LPT model
xemacps e000b000.ps7-ethernet: Set clk to 24999999 Hz
xemacps e000b000.ps7-ethernet: link up (100/FULL)
Rigol Device gadget: Rigol Device ready
usbcore: registered new interface driver usbtmc
<root@rigol>cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 0 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0
processor : 1
model name : ARMv7 Processor rev 0 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0
Hardware : Xilinx Zynq Platform
Revision : 0000
Serial : 0000000000000000
<root@rigol>lspci
<root@rigol>lsusb
Bus 001 Device 001: ID 1d6b:0002
<root@rigol>df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 31729 22410 9319 71% /
devtmpfs 218708 0 218708 0% /dev
none 102400 284 102116 0% /tmp
/dev/ubi6_0 87160 71224 15936 82% /rigol
/dev/ubi1_0 38072 256 35836 1% /rigol/data
/dev/ubi12_0 529048 408 523804 0% /user
<root@rigol>cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00020000 "Env"
mtd1: 04000000 00020000 "DATA"
mtd2: 00400000 00020000 "Bmp"
mtd3: 00400000 00020000 "Bmp1"
mtd4: 00800000 00020000 "Bit1"
mtd5: 02000000 00020000 "Sys1"
mtd6: 06400000 00020000 "App1"
mtd7: 00400000 00020000 "Bmp2"
mtd8: 00800000 00020000 "Bit2"
mtd9: 02000000 00020000 "Sys2"
mtd10: 06400000 00020000 "App2"
mtd11: 04300000 00020000 "Reserved"
mtd12: 25800000 00020000 "User"
<root@rigol>
I don't get it. You bought this for private use didn't you? If yes, then hack it and be done with it.
I also understand that you aren't very happy with the current state of the firmware. Don't make the mistake I made in trusting firmware issues will be fixed soon. If you are going to spend more cash then buy a scope which works out of the box right now. When I was in your situation I didn't listen to this advice and I wish I did. I ended up buying a different scope and the cheaper Chinese scope ended up to be a total waste of money.
Don't make the mistake I made in trusting firmware issues will be fixed soon.
Another option is to lower the requirements a little bit. In the end I bought a scope from GW Instek which just works. The highest bandwidth model of the MSO2000E version will still set you back around 2000 euro so it is not particulary cheap. OTOH it does have a few features the other oscilloscopes don't have: input filtering and you can change the decoding settings afterwards. There isn't such a thing as a perfect oscilloscope.
The hackability of the Rigol scopes may seem like a lot of fun and getting things 'for free' but in the end that doesn't help you if the features don't work the way you need them to work. Let alone if you are going to pay for the options.
You've got it all wrong. Martin72 is on exactly the same path I was a couple of years ago. Looking for a good oscilloscope which does a lot except breaking the bank. As I wrote before: I wish I had listened to the advice I was given on this forum back then. And I also like to share what has been my solution in the end. I can't help it if that doesn't sit right with you but the facts are the facts.Another option is to lower the requirements a little bit. In the end I bought a scope from GW Instek which just works. The highest bandwidth model of the MSO2000E version will still set you back around 2000 euro so it is not particulary cheap. OTOH it does have a few features the other oscilloscopes don't have: input filtering and you can change the decoding settings afterwards. There isn't such a thing as a perfect oscilloscope.
The hackability of the Rigol scopes may seem like a lot of fun and getting things 'for free' but in the end that doesn't help you if the features don't work the way you need them to work. Let alone if you are going to pay for the options.
C'mon, this is a pure technical thread, not just a general discussion for this scope, yet you're still keep pushing & pushing GW Instek here, while constantly keep bashing Rigol, sound really desperate, aren't you ?
You've got it all wrong. Martin72 is on exactly the same path I was a couple of years ago. Looking for a good oscilloscope which does a lot except breaking the bank. As I wrote before: I wish I had listened to the advice I was given on this forum back then. And I also like to share what has been my solution in the end. I can't help it if that doesn't sit right with you but the facts are the facts.
BTW: I have nothing to gain by pushing any brand. I'm just a demanding test equipment user sharing what works for me and what doesn't.
It’s stupidly easy... (even I did it)
BTW, if anyone could post true bandwidth sweeps, with/without fullopt, would be great.
MSO5000 FW v01.01.02.03 (https://cld.pt/dl/download/7d02db7b-5669-43ba-a3d3-0636fc04753d/Firmware_01.01.02.03.GEL.tar)
(link will expire after 24h)
I'm particularly interested in the output ofCode: [Select]dmesg
cat /proc/cpuinfo
lspci
lsusb
df
cat /proc/mtdCode: [Select]<root@rigol>dmesg
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq
Memory policy: Data cache writealloc
On node 0 totalpages: 114688
free_area_init_node: node 0, pgdat c0631c80, node_mem_map c0669000
Normal zone: 896 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 114688 pages, LIFO batch:31
PERCPU: Embedded 8 pages/cpu @c09f1000 s8384 r8192 d16192 u32768
pcpu-alloc: s8384 r8192 d16192 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 113792
Kernel command line: console=ttyPS0,115200 no_console_suspend, root=/dev/ram rw
PID 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 16
ps7-slcr mapped to dc802000
Zynq clock init
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 1725.23 BogoMIPS (lpj=8626176)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0xc03fa6b8 - 0xc03fa710
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72360000, Cache size: 512 kB
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
gpio->base_addr is:0xdc84e000
The gpio irq num is:52
zynq_gpio e000a000.ps7-gpio: gpio at 0xe000a000 mapped to 0xdc84e000
hw-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 @ 0xdc880000
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
NET: Registered protocol family 2
TCP 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 registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
PCI: CLS 0 bytes, default 64
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 10644K (db099000 - dbafe000)
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
NTFS driver 2.1.30 [Flags: R/W].
msgmni has been set to 875
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
DPU:Map vRam to 0xdca00000
DPU:Map iReg to 0xdcc00000
DPU:Ver=0x20170711
dma-pl330 f8003000.ps7-dma: unable to set the seg size
dma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-2364208
dma-pl330 f8003000.ps7-dma: DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 6249999) is a xuartps
console [ttyPS0] enabled
xuartps e0001000.serial: failed to get alias id, errno -19
e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 6249999) is a xuartps
brd: module loaded
loop: module loaded
xspips e0006000.ps7-spi: master is unqueued, this is deprecated
xspips e0006000.ps7-spi: at 0xE0006000 mapped to 0xDC858000, irq=58
libphy: XEMACPS mii bus: probed
xemacps e000b000.ps7-ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
xusbps-ehci xusbps-ehci.1: Xilinx PS USB EHCI Host Controller
xusbps-ehci xusbps-ehci.1: new USB bus registered, assigned bus number 1
xusbps-ehci xusbps-ehci.1: irq 76, io mem 0x00000000
xusbps-ehci xusbps-ehci.1: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-rx8010sj 0-0032: Update timer was detected
rtc-rx8010sj 0-0032: rtc core: registered rtc-rx8010sj as rtc0
input: Goodix-TS as /devices/virtual/input/input0
xi2cps e0004000.ps7-i2c: 90 kHz mmio e0004000 irq 57
zynq-edac f8006000.ps7-ddrc: ecc not enabled
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron MT29F8G08ADADAH4), 1024MiB, page size: 2048, OOB size: 64
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, version 0x01
13 ofpart partitions found on MTD device pl353-nand
Creating 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 registered
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
rtc-rx8010sj 0-0032: setting system clock to 2018-12-23 22:14:55 UTC (1545603295)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 176K (c05cf000 - c05fb000)
UBI: attaching mtd6 to ubi6
UBI: scanning is finished
UBI warning: print_rsvd_warning: cannot reserve enough PEBs for bad PEB handling, reserved 19, need 160
UBI: attached mtd6 (name "App1", size 100 MiB) to ubi6
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 800, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 137759694
UBI: available PEBs: 0, total reserved PEBs: 800, PEBs reserved for bad PEB handling: 19
UBI: background thread "ubi_bgt6d" started, PID 655
UBIFS: background thread "ubifs_bgt6_0" started, PID 658
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 6, volume 0, name "app"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 97263616 bytes (92 MiB, 766 LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
UBIFS: reserved for root: 0 bytes (0 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 29D18BC9-40D5-47EB-8093-D75BB394A334, small LPT model
UBI: attaching mtd1 to ubi1
UBI: scanning is finished
UBI: attached mtd1 (name "DATA", size 64 MiB) to ubi1
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 512, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 1383059050
UBI: available PEBs: 0, total reserved PEBs: 512, PEBs reserved for bad PEB handling: 160
UBI: background thread "ubi_bgt1d" started, PID 687
UBIFS: background thread "ubifs_bgt1_0" started, PID 691
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 1, volume 0, name "DATA"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 42917888 bytes (40 MiB, 338 LEBs), journal size 2158592 bytes (2 MiB, 17 LEBs)
UBIFS: reserved for root: 2027117 bytes (1979 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 678F0810-83AE-49F3-AD8C-BB561AFDEDBD, small LPT model
UBI: attaching mtd12 to ubi12
UBI: scanning is finished
UBI: attached mtd12 (name "User", size 600 MiB) to ubi12
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 4796, bad PEBs: 4, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1737885595
UBI: available PEBs: 0, total reserved PEBs: 4796, PEBs reserved for bad PEB handling: 156
UBI: background thread "ubi_bgt12d" started, PID 728
UBIFS: background thread "ubifs_bgt12_0" started, PID 732
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 12, volume 0, name "USER"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 586502144 bytes (559 MiB, 4619 LEBs), journal size 29331456 bytes (27 MiB, 231 LEBs)
UBIFS: reserved for root: 4952683 bytes (4836 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 7C7DEB0E-5611-4D11-9900-4290138ACF6B, small LPT model
xemacps e000b000.ps7-ethernet: Set clk to 24999999 Hz
xemacps e000b000.ps7-ethernet: link up (100/FULL)
Rigol Device gadget: Rigol Device ready
usbcore: registered new interface driver usbtmc
<root@rigol>cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 0 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0
processor : 1
model name : ARMv7 Processor rev 0 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0
Hardware : Xilinx Zynq Platform
Revision : 0000
Serial : 0000000000000000
<root@rigol>lspci
<root@rigol>lsusb
Bus 001 Device 001: ID 1d6b:0002
<root@rigol>df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 31729 22410 9319 71% /
devtmpfs 218708 0 218708 0% /dev
none 102400 284 102116 0% /tmp
/dev/ubi6_0 87160 71224 15936 82% /rigol
/dev/ubi1_0 38072 256 35836 1% /rigol/data
/dev/ubi12_0 529048 408 523804 0% /user
<root@rigol>cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00020000 "Env"
mtd1: 04000000 00020000 "DATA"
mtd2: 00400000 00020000 "Bmp"
mtd3: 00400000 00020000 "Bmp1"
mtd4: 00800000 00020000 "Bit1"
mtd5: 02000000 00020000 "Sys1"
mtd6: 06400000 00020000 "App1"
mtd7: 00400000 00020000 "Bmp2"
mtd8: 00800000 00020000 "Bit2"
mtd9: 02000000 00020000 "Sys2"
mtd10: 06400000 00020000 "App2"
mtd11: 04300000 00020000 "Reserved"
mtd12: 25800000 00020000 "User"
<root@rigol>
MSO5000 FW v01.01.02.03 (https://cld.pt/dl/download/7d02db7b-5669-43ba-a3d3-0636fc04753d/Firmware_01.01.02.03.GEL.tar)
(link will expire after 24h)
Thanks for that! This is the original GEL, as in the version that comes shipped on the scopes yeah? Do you have this for the 7000 as well? For that I only have 00.01.01.07.01 so far ...
Many thanks for that. Sadly, this _still_ does not show me which zynq they are using. I think someone mentioned somewhere that it's a 7020, at least we know it's a dual-core. So that leaves out a few of them and we know it runs about 800 MHz based on the bogomips.
What do you do with those?
Many thanks for that. Sadly, this _still_ does not show me which zynq they are using. I think someone mentioned somewhere that it's a 7020, at least we know it's a dual-core. So that leaves out a few of them and we know it runs about 800 MHz based on the bogomips.
You can see the Zynq model in my DS7000 FPGAs parsing. (see the DS7000 thread (https://www.eevblog.com/forum/testgear/new-rigol-ds7000/msg1761803/#msg1761803))
I assume the Zynq is the same (7015). But I can parse the 5000 .bit file and verify that for you.
What do you do with this gel file. I can untar it, and get four .img.gz files, plus the encrypted shell scripts. Futher untarring and and i get some .img files..
What do you do with those?MSO5000 FW v01.01.02.03 (https://cld.pt/dl/download/7d02db7b-5669-43ba-a3d3-0636fc04753d/Firmware_01.01.02.03.GEL.tar)
(link will expire after 24h)
Thanks for that! This is the original GEL, as in the version that comes shipped on the scopes yeah? Do you have this for the 7000 as well? For that I only have 00.01.01.07.01 so far ...
Ah see that's where I saw it (lots of threads about the 5k and 7k. With the similarities between the two platform, the OP statement about this being only about the 5k should be redacted to be about 5k and 7k. Having the information in one thread is always easier :) I believe we have 3 threads now with information scattered...
Ah see that's where I saw it (lots of threads about the 5k and 7k. With the similarities between the two platform, the OP statement about this being only about the 5k should be redacted to be about 5k and 7k. Having the information in one thread is always easier :) I believe we have 3 threads now with information scattered...
Makes some sense since they are so similar (or "too much similar"...). I'll ask OP to change the thread name.
BTW, what is the 3rd thread?
The two script files are interesting, as it actually shows two potential upgrade paths. One is from within linux, the other from within u-boot. My guess is that if the upgrade fails via linux, if you have the usb stick with GEL inserted during boot, u-boot will parse the update file and perform the update. Why they did this I am not sure yet.
I remember having read in the past that DS1000Z firmware downgrade is a matter of writing a special signature on the flash drive that carries the downgrade firmware. Is there any chance I can have that special signature or any other help to downgrade the DS1000Z firmware, please?
<root@rigol> mount
rootfs on / type rootfs (rw)
/dev/root on / type ext2 (rw,relatime,errors=continue)
devtmpfs on /dev type devtmpfs (rw,relatime,size=218708k,nr_inodes=54677,mode=755)
none on /proc type proc (rw,relatime)
none on /sys type sysfs (rw,relatime)
none on /tmp type tmpfs (rw,relatime,size=102400k)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/ubi6_0 on /rigol type ubifs (rw,relatime)
/dev/ubi1_0 on /rigol/data type ubifs (rw,sync,relatime)
/dev/ubi12_0 on /user type ubifs (rw,sync,relatime)
>>> /dev/sda1 on /media/sda1 type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=936,iocharset=utf8,shortname=mixed,errors=remount-ro)
<root@rigol> dd if=/dev/mtd7 of=/media/sda1/logo_orig.hex
8192+0 records in
8192+0 records out
4194304 bytes (4.0MB) copied, 1.070000 seconds, 3.7MB/s
<root@rigol> flash_eraseall /dev/mtd7
Erasing 128 Kibyte @ 400000 - 100% complete.
<root@rigol> nandwrite -p /dev/mtd7 /media/sda1/Logo_FireBird.hex
Writing at 0x00000000
Writing at 0x00020000
Writing at 0x00040000
Writing at 0x00060000
Writing at 0x00080000
Writing at 0x000a0000
Writing at 0x000c0000
Writing at 0x000e0000
Writing at 0x00100000
Writing at 0x00120000
George,
Don't hijack with such a OT. It's better to send a PM. Contact janekivi as he may be able to help. I think you have 2 ways: using the special Rigol USB vendor disk and patching the version number in the previous FW. I think Janekivi can help with both. I would have to do some development to replicate it.
Re. logo screen: as there wasn’t any reply, I guess there isn’t such an information available yet. Or nobody is interested. :) Anyway…
dev: size erasesize name
mtd0: 00040000 00020000 "Env" ; Environment as a NULL terminated list and a dword at the beginning
mtd1: 04000000 00020000 "DATA" ; UBI FS -> /rigol/data
mtd2: 00400000 00020000 "Bmp" ; unused FF
mtd3: 00400000 00020000 "Bmp1" ; App A unused FF
mtd4: 00800000 00020000 "Bit1" ; App A unused FF
mtd5: 02000000 00020000 "Sys1" ; App A unused FF
mtd6: 06400000 00020000 "App1" ; App A unused FF
mtd7: 00400000 00020000 "Bmp2" ; App B Boot Logo <- logo.hex
mtd8: 00800000 00020000 "Bit2" ; App B Zynq Bitstream <- zynq.bit
mtd9: 02000000 00020000 "Sys2" ; App B Linux Kernel <- system.img
mtd10: 06400000 00020000 "App2" ; App B UBI FS -> /rigol <- app.img
mtd11: 04300000 00020000 "Reserved" ; unused FF
mtd12: 25800000 00020000 "User" ; UBI FS -> /user
BTW, dump both original BMP from the NAND and attach them here (as .PNGs). People like to look at some images.
Yep, might be handy someday, when someone yells ... "I want the original logo back, where can I find one ..." :-DD
Rigol is talking in their update script about app A and B. All app A blocks are empty.
What do you do with this gel file. I can untar it, and get four .img.gz files, plus the encrypted shell scripts. Futher untarring and and i get some .img files..
What do you do with those?MSO5000 FW v01.01.02.03 (https://cld.pt/dl/download/7d02db7b-5669-43ba-a3d3-0636fc04753d/Firmware_01.01.02.03.GEL.tar)
(link will expire after 24h)
Thanks for that! This is the original GEL, as in the version that comes shipped on the scopes yeah? Do you have this for the 7000 as well? For that I only have 00.01.01.07.01 so far ...
Well mostly compare between the different versions, as for the image files, they are regular linux filesystem images.
.....
I'm curious about this special 'vendor' usb stick. Is it something we can obtain/download/create?The two script files are interesting, as it actually shows two potential upgrade paths. One is from within linux, the other from within u-boot. My guess is that if the upgrade fails via linux, if you have the usb stick with GEL inserted during boot, u-boot will parse the update file and perform the update. Why they did this I am not sure yet.
The scope accepts the usual ultra-special Rigol vendor USB flashdrive (with the special boot sector).
Don't know yet what that allows but... ;)
Tell me what zynq dev board do you have in mind for 100USD?
That's probably u-boot's splash screen. I'd be suprised if it is initially different from the other two to keep a 'smooth' logo experience.Re. logo screen: as there wasn’t any reply, I guess there isn’t such an information available yet. Or nobody is interested. :) Anyway…
People are shy... :) Keep those contributions! If everyone does a bit, it costs less.
What about MTD3? What is the BMP there?
Rigol is talking in their update script about app A and B. All app A blocks are empty.Standard u-boot environment created from a text file and 'compiled' with mkimage. The dword in front is the header.Code: [Select]dev: size erasesize name
mtd0: 00040000 00020000 "Env" ; Environment as a NULL terminated list and a dword at the beginning
As I mentioned earlier, probably configuration data and the likeCode: [Select]mtd1: 04000000 00020000 "DATA" ; UBI FS -> /rigol/data
Hmm strange that it is unused, I would have expected the logo for u-boot to use.Code: [Select]mtd2: 00400000 00020000 "Bmp" ; unused FF
This will be populated the first time an update is performed, the update script updates the 'backup', and boots from that next time.Code: [Select]mtd3: 00400000 00020000 "Bmp1" ; App A unused FF
mtd4: 00800000 00020000 "Bit1" ; App A unused FF
mtd5: 02000000 00020000 "Sys1" ; App A unused FF
mtd6: 06400000 00020000 "App1" ; App A unused FF
Code: [Select]mtd7: 00400000 00020000 "Bmp2" ; App B Boot Logo <- logo.hex
mtd8: 00800000 00020000 "Bit2" ; App B Zynq Bitstream <- zynq.bit
mtd9: 02000000 00020000 "Sys2" ; App B Linux Kernel <- system.img
mtd10: 06400000 00020000 "App2" ; App B UBI FS -> /rigol <- app.img
mtd11: 04300000 00020000 "Reserved" ; unused FF
mtd12: 25800000 00020000 "User" ; UBI FS -> /user
I'm curious about this special 'vendor' usb stick. Is it something we can obtain/download/create?
I guess dumping the environment from /dev/mtd0 (and attaching it here) yields us all the scripts etc, if anybody could be so kind :)
and boy is there a difference. The Siglent's small display is incredibly bright and clear. On the MSO5000 it is not only a dim screen but also bad diffusion of the back lights. All the edges of the MSO5000 are brighter than the rest of the display. I think they may have reduced the back-light brightness to reduce this effect. Comparing the display to a DSA815 the MSO5000 is still much dimmer and lower resolution.
Has anybody been able to 'interrupt' u-boot yet with the any-key press? Normally if you press it a few times (space works great) just before the message appears (keyboard buffer an all that) it should pick it up, IF the tx is not disabled ... But I guess very few have it opened and a debug header connected other then dave ...
[12/24 17:12:56.0]
[12/24 17:12:56.0]U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
[12/24 17:12:56.0]
[12/24 17:12:56.0]I2C: ready
[12/24 17:12:56.0]Memory: ECC disabled
[12/24 17:12:56.0]DRAM: 448 MiB
[12/24 17:12:56.1]DPU: 20170604
[12/24 17:12:56.1]NAND: OnDie ECC supported, 1024 MiB
[12/24 17:12:57.1]zynq-In: serial
[12/24 17:12:57.1]zynq-Out: serial
[12/24 17:12:57.1]zynq-Err: serial
[12/24 17:12:57.1]Net: Gem.e000b000
[12/24 17:12:57.1]BootParam=0x0
[12/24 17:12:57.1]Hit any key to stop autoboot: 0
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]rigol-uboot>U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
[12/24 17:12:57.1]Unknown command 'U-Boot' - try 'help'
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]Unknown command 'U-Boot' - try 'help'
[12/24 17:12:57.3](
[12/24 17:12:57.3]Unknown command 'U-Boot' - try 'help'
[12/24 17:12:57.3]rigol-uboot>
[12/24 17:12:57.3] aesTest base bdinfo beeper boot bootd bootm bootp bootz checkGTP checkVer
[12/24 17:12:57.3] clk cmp coninfo cp cpldver crc32 dcache ...
[12/24 17:12:57.3]rigol-uboot>
Is all options != 350mhz? It almost seems like it’s 500mhz ?Some features stop working after 350Mhz. For example the counter option does not work after 350Mhz. Also the frequency measurement gets iffy after 500Mhz. It will show the correct frequency 50% of the time.
I had seen rumors of making it run at 1ghz?
It will measure and show waveforms at 1Ghz but the quality is poor and I would not consider this "hack" to unlock a 1Ghz scope.
It will measure and show waveforms at 1Ghz but the quality is poor and I would not consider this "hack" to unlock a 1Ghz scope.
ehm, on your picture, you do sample with 2GSa/s, i though it can get up to 8GSa/s?
That, is awesome :) While they can still fix this trivially (by editing the environment and disabling it) I was afraid that TX would not work. I guess Dave just made a booboo somewhere where it did not work (in the video). Probably tried to late. (one of those things that need an edit in the video with a text overlay saying it does work.
Has anybody been able to 'interrupt' u-boot yet with the any-key press? Normally if you press it a few times (space works great) just before the message appears (keyboard buffer an all that) it should pick it up, IF the tx is not disabled ... But I guess very few have it opened and a debug header connected other then dave ...
Yes you can halt the boot processCode: [Select][12/24 17:12:56.0]
[12/24 17:12:56.0]U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
[12/24 17:12:56.0]
[12/24 17:12:56.0]I2C: ready
[12/24 17:12:56.0]Memory: ECC disabled
[12/24 17:12:56.0]DRAM: 448 MiB
[12/24 17:12:56.1]DPU: 20170604
[12/24 17:12:56.1]NAND: OnDie ECC supported, 1024 MiB
[12/24 17:12:57.1]zynq-In: serial
[12/24 17:12:57.1]zynq-Out: serial
[12/24 17:12:57.1]zynq-Err: serial
[12/24 17:12:57.1]Net: Gem.e000b000
[12/24 17:12:57.1]BootParam=0x0
[12/24 17:12:57.1]Hit any key to stop autoboot: 0
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]rigol-uboot>U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
[12/24 17:12:57.1]Unknown command 'U-Boot' - try 'help'
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]Unknown command 'U-Boot' - try 'help'
[12/24 17:12:57.3](
[12/24 17:12:57.3]Unknown command 'U-Boot' - try 'help'
[12/24 17:12:57.3]rigol-uboot>
[12/24 17:12:57.3] aesTest base bdinfo beeper boot bootd bootm bootp bootz checkGTP checkVer
[12/24 17:12:57.3] clk cmp coninfo cp cpldver crc32 dcache ...
[12/24 17:12:57.3]rigol-uboot>
If someone could be so kind as to get me a mtd0 dump, I can poke there a little.
-TOUCHSCREEN_Goodix_TS y
TOUCHSCREEN_SSD2543 n -> y
The MSO5000 has the SD2543 touchscreen, and I think the MSO7000 has a Goodix ts.But thanks. The 7010, 7015 and 7020 are similar enough that any dev board with these chips should be accurate enough. I think it's mostly CPU speed and maybe FPGA gate count that's different, so I guess they couldn't fit their bitstream into the 7010 and went one up ...Not exactly. 7015 is fundamentally different from 10/20 in that its' fabric has 4 MGTs (GTPs) which support up to 6.6 Gbps per channel. I suspect they use these transceivers to talk to their ASICs.
If someone could be so kind as to get me a mtd0 dump, I can poke there a little.
By your command.
backpart=B
baudrate=115200
bootdelay=1
bootver=2018.06.27
ethact=Gem.e000b000
ethaddr=00:0a:35:00:01:2a
gatewayip=172.16.3.1
ipaddr=172.16.3.254
modeboot=qspiboot
nandboot=loadzynq;ledoff;run bootlogo; nand read 0x3000000 0x1100000 0x1000000;bootm 0x3000000
netmask=255.255.255.0
nfsboot=nfs 0x3000000 172.16.3.38:/home/rigolee/workspace/nfs/system.img && bootm 0x3000000
serverip=172.16.3.252
stderr=serial
stdin=serial
stdout=serial
update=if tar 0x4000000 0x2000000 fw4uboot.sh; then aesTest 0x2000000 ${temp_file_size} 0x2100000if exec 0x2100000; then echo update success!; else echo update failed!; fi;else echo can not find update shell!;fi;
upnet=nfs 0x4000000 172.16.3.38:/home/rigolee/workspace/nfs/FlamingoUpdate.GEL && run update
usbboot=if usb start; then echo Copying Linux from USB to RAM... && fatload usb 0 0x3000000 uImage && fatload usb 0 0x2A00000 devicetree.dtb && fatload usb 0 0x2000000 uramdisk.gz && bootm 0x3000000 0x2000000 0x2A00000; fi;
usbupdate=upgradeFromUSB
vendor=RIGOL TECHNOLOGIES
nandbootA=checkGTP;loadzynq 0x4900000;ledoff;loadlogo 0x4500000;nand read 0x3000000 0x5100000 0xd8ebf0;bootm 0x3000000
nandbootB=checkGTP;loadzynq 0xd900000;ledoff;loadlogo 0xd500000;nand read 0x3000000 0xe100000 0xd8ebf0;bootm 0x3000000
bootlogo=loadlogo 0xd500000
builddate=2018-10-11 16:45:53
softver=00.01.01.02.03
bootpart=B
bootcmd=if run nandbootB; then echo 'ok'; else setenv bootpart A;save;run nandbootA; fi
<snip>The two script files are interesting, as it actually shows two potential upgrade paths. One is from within linux, the other from within u-boot. My guess is that if the upgrade fails via linux, if you have the usb stick with GEL inserted during boot, u-boot will parse the update file and perform the update. Why they did this I am not sure yet.
The scope accepts the usual ultra-special Rigol vendor USB flashdrive (with the special boot sector).
Don't know yet what that allows but... ;)
Tell me what zynq dev board do you have in mind for 100USD?
I find pricing for these boards can very, not sure why. (Same board, different sites, double the price). If I find a nice vendor where i can buy stuff; i'll post a link
Not exactly. 7015 is fundamentally different from 10/20 in that its' fabric has 4 MGTs (GTPs) which support up to 6.6 Gbps per channel. I suspect they use these transceivers to talk to their ASICs.
I wonder if that mac address is unique or identical for all devices.I have the same MAC in my environment but 00:0a:35 is a Xilinx MAC and I haven't captured it during a normal boot. During normal operation, the packets have Rigol MACs (00:19:af).
So clearly, currently they could be violating the GPL. While I don't think it's important yet to start bugging them about it (I doubt they have (m)any changes from upstream and the only code they wrote is in flamingo_console/appEntry) I am curious how they will deal with this ... I think this is their first-ish Linux offering ...Just for starters, do the 'scope comes with the usual leaflet (or pages at the end of the manual) about notes on GPL licensed components and how to request the source code?
They only have to provide the sourcecode (of the GPL'ed parts) if they modified it.
Maybe they use unmodified GPL'ed software.
Just for starters, do the 'scope comes with the usual leaflet (or pages at the end of the manual) about notes on GPL licensed components and how to request the source code?Anybody who has the box and manuals already took a peak with regards to a software offer? I do know it must be somewhere on the scope, as there is /license/ on the device with the licenses of some of the parts in it.
Anybody who has the box and manuals already took a peak with regards to a software offer? I do know it must be somewhere on the scope, as there is /license/ on the device with the licenses of some of the parts in it.
Dump of MSO5074 NAND for anybody that's interested...
https://www.dropbox.com/s/zb9ay97a0df00cb/Rigol%20MSO5074%20NAND.zip?dl=0 (https://www.dropbox.com/s/zb9ay97a0df00cb/Rigol%20MSO5074%20NAND.zip?dl=0)
sf probe
sf read 0x4900000 0 <size of flash> (assuming its 16 Mbit, sf probe prints it) that will be 0x1000000)
md 0x4900000 0x1000000
becuase the serial console is quite slow, that will run for a few minutes, so logging of the serial output is required. (When using screen for example you can make it log everything into a file. Not sure if putty has that capability but https://www.viktorious.nl/2013/01/14/putty-log-all-session-output/ (https://www.viktorious.nl/2013/01/14/putty-log-all-session-output/) seems to suggest it is so.
While this is super appreciated! I think you should at least remove mtd1 from there, as that contains scope specific parameters is my guess (If not, its okay, i think it is mapped to /rigol/data if you want to check), such as serial numbers and licenses.
I have ordered the MYIR z-turn lite 7010 so we'll see when it arrives here. Not to bad for 95 Euro's (I got the GPIO breakout board). Probably will take 6 weeks to get here though :(
So if we can get the output of 'sf probe' we know u-boot can talk to it, and if so, we can use sf read to read it into memory.
While here, also do a printenv :)
I do now :DI have ordered the MYIR z-turn lite 7010 so we'll see when it arrives here. Not to bad for 95 Euro's (I got the GPIO breakout board). Probably will take 6 weeks to get here though :(
I also bought the 7020... :)
Do you read PMs?
So if we can get the output of 'sf probe' we know u-boot can talk to it, and if so, we can use sf read to read it into memory.
While here, also do a printenv :)
Ok... breaking into u-boot is a right pain so far. There is the 'Hit any key' message but the countdown timer starts at zero so no time to hit a key. I tried holding SPACE down continuously during the boot process and never managed to break in.
But... if I spew a stream of data at the scope during boot I can break in...
rigol-uboot>sf probe
zynq_qspi_setup_slave: No QSPI device detected based on MIO settings
SF: Failed to set up slave
Failed to initialize SPI flash at 0:0
rigol-uboot>printenv
Invalid input(hxh)
Not very promising so far...
rigol-uboot> setenv bootdelay 2
for example, followed by either a `saveenv` or just `save`<enter>. These days it is saveenv, but i see rigol use in the scripts (to modify the bootpart parameter) use save instead.rigol-uboot> save
ls -laF /tmp/env.bin
and then modify the env :)/rigol/tools/cfger -s "bootdelay 2"
flash_eraseall /dev/mtd0
nandwrite -p /dev/mtd0 /tmp/env.bin
setenv bootdelay 3
followed bysave
without the save, nothing happens. You basically just set the bootdelay variable to read '3 save' and after a reboot it's gone (reset, without the save)
I'm sorry I wasn't clear, but they are two commands
soCode: [Select]setenv bootdelay 3
followed byCode: [Select]save
without the save, nothing happens. You basically just set the bootdelay variable to read '3 save' and after a reboot it's gone (reset, without the save)
/rigol/tools/cfger -s "bootdelay 5"
flash_eraseall /dev/mtd0
nandwrite -p /dev/mtd0 /tmp/env.bin
Help? Been there done that....
rigol-uboot>bollocks
Unknown command 'bollocks' - try 'help'
rigol-uboot>help
Invalid input(hxh)
Help? Been there done that....
rigol-uboot>bollocks
Unknown command 'bollocks' - try 'help'
rigol-uboot>help
Invalid input(hxh)
LOL they removed the 'help' command to make the binary smaller (or remove it to please the user lol)
ok, so then i'll just have to get the info from an older u-boot manual.
until now, i had to do all this from memory :p
00000000 - FFFFFFFF Padding
00000004 - FFFFFFFF Padding
00000008 - FFFFFFFF Padding
0000000C - FFFFFFFF Padding
00000010 - FFFFFFFF Padding
00000014 - FFFFFFFF Padding
00000018 - FFFFFFFF Padding
0000001C - FFFFFFFF Padding
00000020 - 000000BB Bus width auto detect, word 1
00000024 - 11220044 Bus width auto detect, word 2
00000028 - FFFFFFFF Padding
0000002C - FFFFFFFF Padding
00000030 - AA995566 Sync Word (BPI/SPI Mode)
00000034 - 20000000 T1 - 00000000 NOP (1x)
00000038 - 30022001 00000000 T1 W 00000001 TIMER
00000040 - 30020001 00000000 T1 W 00000001 WBSTAR
00000048 - 30008001 00000000 T1 W 00000001 CMD NULL - No Operation
00000050 - 20000000 T1 - 00000000 NOP (1x)
00000054 - 30008001 00000007 T1 W 00000001 CMD RCRC - Reset CRC
0000005C - 20000000 T1 - 00000000 NOP (2x)
00000064 - 30026001 00000000 T1 W 00000001 FALL_EDGE
0000006C - 30012001 02003FE5 T1 W 00000001 COR0
00000074 - 3001C001 00000000 T1 W 00000001 COR1
0000007C - 30018001 0373B093 T1 W 00000001 IDCODE
00000084 - 30008001 00000009 T1 W 00000001 CMD SWITCH - Switch CCLK Frequency
0000008C - 20000000 T1 - 00000000 NOP (1x)
00000090 - 3000C001 00000401 T1 W 00000001 MASK
00000098 - 3000A001 00000501 T1 W 00000001 CTL0
000000A0 - 3000C001 00000000 T1 W 00000001 MASK
000000A8 - 30030001 00000000 T1 W 00000001 CTL1
000000B0 - 20000000 T1 - 00000000 NOP (8x)
000000D0 - 30002001 00000000 T1 W 00000001 FAR
000000D8 - 30008001 00000001 T1 W 00000001 CMD WCFG - Write Config Data
000000E0 - 20000000 T1 - 00000000 NOP (1x)
000000E4 - 30004000 T1 W 00000000 FDRI
000000E8 - 500D621C T2 W 000D621C
00358964 - 20000000 T1 - 00000000 NOP (2x)
0035896C - 30008001 0000000A T1 W 00000001 CMD GRESTORE - Pulse GRESTORE Signal
00358974 - 20000000 T1 - 00000000 NOP (1x)
00358978 - 30008001 00000003 T1 W 00000001 CMD DGHIGH/LFRM - Last Frame Write
00358980 - 20000000 T1 - 00000000 NOP (100x)
00358B10 - 30008001 00000005 T1 W 00000001 CMD START - Begin Startup Sequence
00358B18 - 20000000 T1 - 00000000 NOP (1x)
00358B1C - 30002001 03BE0000 T1 W 00000001 FAR
00358B24 - 3000C001 00000501 T1 W 00000001 MASK
00358B2C - 3000A001 00000501 T1 W 00000001 CTL0
00358B34 - 30000001 E3AD7EA5 T1 W 00000001 CRC
00358B3C - 20000000 T1 - 00000000 NOP (2x)
00358B44 - 30008001 0000000D T1 W 00000001 CMD DESYNC - Reset DALIGN Signal
00358B4C - 20000000 T1 - 00000000 NOP (400x)
<root@rigol>./cfger -h
-r name:read the value of name
-i file:read model,version,date to file
-c name value: compare bwtween the value of name with value
-s name value: set the value of name
-t file: remove the all zero of the file
-d input output: decrypt the input to output by aes
-e input output: crypt the input to output by aes
-h : show this help information
I'm sorry I wasn't clear, but they are two commands
soCode: [Select]setenv bootdelay 3
followed byCode: [Select]save
without the save, nothing happens. You basically just set the bootdelay variable to read '3 save' and after a reboot it's gone (reset, without the save)
Ok cool... well it made no difference so I tried the Linux way:Code: [Select]/rigol/tools/cfger -s "bootdelay 5"
flash_eraseall /dev/mtd0
nandwrite -p /dev/mtd0 /tmp/env.bin
That made no difference either, countdown is still instantaneous.
Would it be possible to hack it so it boots faster?
I mean, what's it doing for a whole minute? That's an eternity.
Help? Been there done that....LOL they removed the 'help' command to make the binary smaller (or remove it to please the user lol)
rigol-uboot>bollocks
Unknown command 'bollocks' - try 'help'
rigol-uboot>help
Invalid input(hxh)
ok, so then i'll just have to get the info from an older u-boot manual.
until now, i had to do all this from memory :p
I just went though a list of 'standard uboot commands and quite a few work as expected. BDINFO and VERSION churn out some info, but HELP and PRINTENV are very much absent.
So, the zynq.bit parsing is below:Code: [Select]00000000 - FFFFFFFF Padding
00000004 - FFFFFFFF Padding
00000008 - FFFFFFFF Padding
0000000C - FFFFFFFF Padding
00000010 - FFFFFFFF Padding
00000014 - FFFFFFFF Padding
00000018 - FFFFFFFF Padding
0000001C - FFFFFFFF Padding
00000020 - 000000BB Bus width auto detect, word 1
00000024 - 11220044 Bus width auto detect, word 2
00000028 - FFFFFFFF Padding
0000002C - FFFFFFFF Padding
00000030 - AA995566 Sync Word (BPI/SPI Mode)
00000034 - 20000000 T1 - 00000000 NOP (1x)
00000038 - 30022001 00000000 T1 W 00000001 TIMER
00000040 - 30020001 00000000 T1 W 00000001 WBSTAR
00000048 - 30008001 00000000 T1 W 00000001 CMD NULL - No Operation
00000050 - 20000000 T1 - 00000000 NOP (1x)
00000054 - 30008001 00000007 T1 W 00000001 CMD RCRC - Reset CRC
0000005C - 20000000 T1 - 00000000 NOP (2x)
00000064 - 30026001 00000000 T1 W 00000001 FALL_EDGE
0000006C - 30012001 02003FE5 T1 W 00000001 COR0
00000074 - 3001C001 00000000 T1 W 00000001 COR1
0000007C - 30018001 0373B093 T1 W 00000001 IDCODE
00000084 - 30008001 00000009 T1 W 00000001 CMD SWITCH - Switch CCLK Frequency
0000008C - 20000000 T1 - 00000000 NOP (1x)
00000090 - 3000C001 00000401 T1 W 00000001 MASK
00000098 - 3000A001 00000501 T1 W 00000001 CTL0
000000A0 - 3000C001 00000000 T1 W 00000001 MASK
000000A8 - 30030001 00000000 T1 W 00000001 CTL1
000000B0 - 20000000 T1 - 00000000 NOP (8x)
000000D0 - 30002001 00000000 T1 W 00000001 FAR
000000D8 - 30008001 00000001 T1 W 00000001 CMD WCFG - Write Config Data
000000E0 - 20000000 T1 - 00000000 NOP (1x)
000000E4 - 30004000 T1 W 00000000 FDRI
000000E8 - 500D621C T2 W 000D621C
00358964 - 20000000 T1 - 00000000 NOP (2x)
0035896C - 30008001 0000000A T1 W 00000001 CMD GRESTORE - Pulse GRESTORE Signal
00358974 - 20000000 T1 - 00000000 NOP (1x)
00358978 - 30008001 00000003 T1 W 00000001 CMD DGHIGH/LFRM - Last Frame Write
00358980 - 20000000 T1 - 00000000 NOP (100x)
00358B10 - 30008001 00000005 T1 W 00000001 CMD START - Begin Startup Sequence
00358B18 - 20000000 T1 - 00000000 NOP (1x)
00358B1C - 30002001 03BE0000 T1 W 00000001 FAR
00358B24 - 3000C001 00000501 T1 W 00000001 MASK
00358B2C - 3000A001 00000501 T1 W 00000001 CTL0
00358B34 - 30000001 E3AD7EA5 T1 W 00000001 CRC
00358B3C - 20000000 T1 - 00000000 NOP (2x)
00358B44 - 30008001 0000000D T1 W 00000001 CMD DESYNC - Reset DALIGN Signal
00358B4C - 20000000 T1 - 00000000 NOP (400x)
The IDCODE = 0373B093 corresponds to the Xilinx Zynq-7015. The same as in the DS7000.
The decrypted scripts (full) are attached.
The file /tmp/env.bin is protected by a CRC-32 (ISO-HDLC) in it's first 4 bytes. cfger tests this CRC before doing anything.
I'm sorry I wasn't clear, but they are two commands
soCode: [Select]setenv bootdelay 3
followed byCode: [Select]save
without the save, nothing happens. You basically just set the bootdelay variable to read '3 save' and after a reboot it's gone (reset, without the save)
Ok cool... well it made no difference so I tried the Linux way:Code: [Select]/rigol/tools/cfger -s "bootdelay 5"
flash_eraseall /dev/mtd0
nandwrite -p /dev/mtd0 /tmp/env.bin
That made no difference either, countdown is still instantaneous.
Hmm, I doubt cfgver is checking anything in that file, like filtering bootdelay, so it could be, that they removed it from the binary.
In any case, we _can_ get in if needed, so that's a win. I am curious that, next time your in u-boot, what "echo $bootdelay" will say. It should yield the 5 you saved, if not, we did something wrong with the cfgver tool (or whatever it was, I forget)
That's the same bit as from the MSO7000 thread right? Nice to have it all in one place :)
Seems to be stuck at 1. But I can reliably get into uboot now by streaming crap at the scope at boot time.that's interesting; as initially it is set to 0. Well I'll dig into this at some point.
rigol-uboot>echo $bootdelay
1
I'm not surprised at that at all. I think MS07000 and MSO5000 are more or less the same platform. Not sure I understand the difference in PCB yet however ... I doubt they are using different ASIC's though; maybe yield differences for now; but then, that means if yields get better, there will be even less differences ...That's the same bit as from the MSO7000 thread right? Nice to have it all in one place :)
No it isn't. This one is from the MSO5000.
That means the 2 bit files should be the same in 5000 and 7000 !!!! :)
<decrypted files>They are more or less identical, except hashes and so, to the MSO7000 files. No suprise there :)
Meanwhile, what do you mean with a stream of crap? I know you can set keys to allow interrupts, space is or 'c' are common. CTRL-c also tends to work to interrupt a running bootscript. Is it just random keyboard mashing; is it isolated to an area of button mashing?
Meanwhile, what do you mean with a stream of crap? I know you can set keys to allow interrupts, space is or 'c' are common. CTRL-c also tends to work to interrupt a running bootscript. Is it just random keyboard mashing; is it isolated to an area of button mashing?
I just loop output back to input, that does it!
Meanwhile, what do you mean with a stream of crap? I know you can set keys to allow interrupts, space is or 'c' are common. CTRL-c also tends to work to interrupt a running bootscript. Is it just random keyboard mashing; is it isolated to an area of button mashing?
I just loop output back to input, that does it!
like shortening RX to TX? that's bizare :D It must be one of the character (combinations) in there. It IS possible they have set a 'password' as the any-key and it happens to be part of the input lol, like rigolee or dirty :p
That's the same bit as from the MSO7000 thread right? Nice to have it all in one place :) Not sure what I'm seeing in the zynq bit file, more curious as to whether its possible to do any partial reconfiguration. I know FPGA's support it, just need to know what's needed, as I desperately want to overwrite some bits (like the display unit).There seems to be a lot of myths regarding partial reconfiguration floating around, so please watch this video from Xilinx explaining what PR actually is and how it works: https://www.xilinx.com/video/hardware/partial-reconfiguration-in-vivado.html (https://www.xilinx.com/video/hardware/partial-reconfiguration-in-vivado.html)
anyone tried logging in with firmware version 00.01.01.02.04? Build: 2018-11-09 19:49:21
i ordered the mso5074 after reading about the "hack" on hackaday. received it an hour ago, but can't log in over the lan interface & ssh...
login as: root
root@192.168.1.109's password:
Access denied
anyone tried logging in with firmware version 00.01.01.02.04? Build: 2018-11-09 19:49:21
i ordered the mso5074 after reading about the "hack" on hackaday. received it an hour ago, but can't log in over the lan interface & ssh...
Here's version 00.01.01.02.03 (http://firebird.tms-taps.net/Rigol/DS5000Update.GEL). You could put it on a thumb drive and try to downgrade. But maybe someone else would like to try something with 1.2.4 first.thank you! will try and report
P.S.: Upload will be finished in about 10 minutes.
Just for kicks I connected my scope using just the serial interface.
Let it boot all the way and then I seem to have access to all the Linux commands without having to enter a username or password.
Looks like I can copy the start.sh file to USB, edit it and then copy it back into the scope.
Trying to use VI in single line mode is a nightmare!!!
Just for kicks I connected my scope using just the serial interface.
Let it boot all the way and then I seem to have access to all the Linux commands without having to enter a username or password.
Looks like I can copy the start.sh file to USB, edit it and then copy it back into the scope.
Trying to use VI in single line mode is a nightmare!!!
Can you replace /etc/passwd?
Here's version 00.01.01.02.03 (http://firebird.tms-taps.net/Rigol/DS5000Update.GEL). You could put it on a thumb drive and try to downgrade. But maybe someone else would like to try something with 1.2.4 first.thank you! will try and report
P.S.: Upload will be finished in about 10 minutes.
I'll leave that to tv84 and oliv3r. It's encypted and probably can't be transferred to another scope.
anyone tried logging in with firmware version 00.01.01.02.04? Build: 2018-11-09 19:49:21
i ordered the mso5074 after reading about the "hack" on hackaday. received it an hour ago, but can't log in over the lan interface & ssh...
Can we patch the update script so that it thinks that it is at least the same version?It took a bit longer but let’s see if we can fool that little bastard. :) If I didn't mess things up, here’s a file (http://firebird.tms-taps.net/Rigol/DS5000UpdateX.GEL) that should change the environment to make the scope think that it has the older firmware installed and that this is a installation of the same version.
Got an update from Tequip....updated Jan 31 ship date (site says 15 in stock |O )
Read between the lines. Rigol does not want these being hacked.
Wow! that was quick and WORKING!! i can login nowCan we patch the update script so that it thinks that it is at least the same version?It took a bit longer but let’s see if we can fool that little bastard. :) If I didn't mess things up, here’s a file (http://firebird.tms-taps.net/Rigol/DS5000UpdateX.GEL) that should change the environment to make the scope think that it has the older firmware installed and that this is a installation of the same version.
After you’ve downloaded the file, rename it to “DS5000Update.GEL” before you put it on the thumb drive. Good luck!
You just flashed 1.2.3... No use.During my tests, the firmware were flashed into the app A space (mtd3, 4, 5 and 6). Dumping mtds 7 to 10 might provide the new f/w.
But, nonetheless. Tell us what you see in the /user/download/empty
New Firmware ?It has a higher version number but we do not know if the login lock out is the only change.
[Supported Model] All the MSO5000 Series Digital Oscilloscopes
[Latest Revision Date] 2018/10/15
[Updated Contents]
--------------------
v00.01.01.02.03 2018/10/15
- Release the production version
Which password is this?That is an encrypted password. Unix/Linux does not decrypt passwords in /etc/passwd, it only encrypts user typed password using the same key and compares it to the string stored in /etc/passwd
root:qkiAP.hEBSnSY:0:0:root:/root:/bin/sh
Which password is this?20 minutes with hashcat on a radeon hd7900 -> Rigol201 :-DD
root:qkiAP.hEBSnSY:0:0:root:/root:/bin/sh
hashcat64.exe -a 3 -m 1500 rigol.hash
The password is stored in the ramdisk, which is part of the FIT image, so while you can change it, it is never saved to disk. Also even if we changed it, the hash of the initrd wouldn't mach of the FIT image anymore, so we'd have to update as well. Not impossible, not trivial either.Just for kicks I connected my scope using just the serial interface.
Let it boot all the way and then I seem to have access to all the Linux commands without having to enter a username or password.
Looks like I can copy the start.sh file to USB, edit it and then copy it back into the scope.
Trying to use VI in single line mode is a nightmare!!!
Can you replace /etc/passwd?
Can we patch the update script so that it thinks that it is at least the same version?I would assume so; we can re-crypt it with cfger I believe and they can't/shouldn't change the keys easily, as they'd want the 'new' keys to still be accepted by old scopes
I wonder where they are getting it from ... Or even more importantly, if they are telling their users to upgrade; where should we get it from?anyone tried logging in with firmware version 00.01.01.02.04? Build: 2018-11-09 19:49:21
i ordered the mso5074 after reading about the "hack" on hackaday. received it an hour ago, but can't log in over the lan interface & ssh...
Same here. The distributor thought it was a nice thing to update the firmware before shipping. |O
Same here. The distributor thought it was a nice thing to update the firmware before shipping. |OI wonder where they are getting it from ...
Which password is this?20 minutes with hashcat on a radeon hd7900 -> Rigol201 :-DD
root:qkiAP.hEBSnSY:0:0:root:/root:/bin/sh
for those interested. researching this took longer then 20mins ;-) linux seems to use DES by default for encrypting passwords. 13 chars and no $-signs point to using that default. i copied the hash part into a file (rigol.hash) and here's the command i used for hashcat:Code: [Select]hashcat64.exe -a 3 -m 1500 rigol.hash
With current state of hacks done, will they able to lock this opening permanently if they want to thru newer firmware "only" ?It’s hard to say if it is impossible to open future firmware updates but a lot of knowledge has been collected in the meantime which makes it easier for us. But as we learn from their changes, they will learn from our hacks and there is a possibility that a future version is not hackable and you’re stuck at a specific version if you don’t want to give up fullopt.
What's "wifi.sh"? :popcorn:Yes, there are a few supported wifi modules (not sure if there is a UI element to configure them however)
(and "send_mail.sh"...do these things send email?)
Noob question, assuming Rigol does not want to screw up existing early buyers/adopters for future firmware upgrades, also with assumption there will be no major hardware change/revision for newly produced scopes.Yes, remote access they can. But best keep quiet so we don't give them idea's.
With current state of hacks done, will they able to lock this opening permanently if they want to thru newer firmware "only" ?
And yes, these can in theory send e-mails :)
And yes, these can in theory send e-mails :)
I had seen that and it seems very complete.
Which raises the questions:
Why would one need to have a mail client in a scope? Does ET need to phone home??
Some oscilloscopes can send an e-mail as part of a data logging feature. If a trigger occured an e-mail notice will be send (and in some cases it is also possible to have a screendump or data send as an attachement).And yes, these can in theory send e-mails :)
I had seen that and it seems very complete.
Which raises the questions:
Why would one need to have a mail client in a scope? Does ET need to phone home??
:-+I wonder if you'd notice this thread :)
And yes, these can in theory send e-mails :)
I had seen that and it seems very complete.
Which raises the questions:
Why would one need to have a mail client in a scope? Does ET need to phone home??
it will be placed on a isolated vlan, with no internet access, and not attached to anything thats important. given the poor security posture that Rigol takes, these become a real possiblity for a security breech.
Some oscilloscopes can send an e-mail as part of a data logging feature. If a trigger occured an e-mail notice will be send (and in some cases it is also possible to have a screendump or data send as an attachement).
And yes, these can in theory send e-mails :)
I had seen that and it seems very complete.
Which raises the questions:
Why would one need to have a mail client in a scope? Does ET need to phone home??
You need to read the terms and conditions and small print on the online update screen....
And yes, these can in theory send e-mails :)
I had seen that and it seems very complete.
Which raises the questions:
Why would one need to have a mail client in a scope? Does ET need to phone home??
You need to read the terms and conditions and small print on the online update screen....
"The system will COLLECT and JUDGE the following information"
"The working state of the key components and user defined function"
:-DD
And yes, these can in theory send e-mails :)
I had seen that and it seems very complete.
Which raises the questions:
Why would one need to have a mail client in a scope? Does ET need to phone home??
You need to read the terms and conditions and small print on the online update screen....
"The system will COLLECT and JUDGE the following information"
"The working state of the key components and user defined function"
:-DD
So that's why I need that touchscreen! :p
While I would not trust them to connect to the internet, it is so easy and happens before you know it; plug-in bam; problems. So if you are not tech-savvy, and do want to locally connect to your scope (ds-remote, lsi tools etc) but don't want it to poke on the internet ... without firewalling or network isolation, the scope just became a ... god knows what.
While I would not trust them to connect to the internet, it is so easy and happens before you know it; plug-in bam; problems. So if you are not tech-savvy, and do want to locally connect to your scope (ds-remote, lsi tools etc) but don't want it to poke on the internet ... without firewalling or network isolation, the scope just became a ... god knows what.
Give it a manual IP and leave the gateway IP blank, it can't call home that way.You might think that but there are several ways to generate network traffic and get the gateway anyway.
I've heard that Rigol adds High-Resolution to Acquire Mode for new firmware version. If this feature is available on your scope, Then congratulations!
I would like to post an SPI Flash dump on this thread and some other hack on appEntry. BTW, we have a u-boot dump without tear it down (In fact, the u-boot itself contains a command to switch between NOR and NAND Flash, because they share several pins), analyzing it is little troublesome. Althrough we know the u-boot passphrase, but how to check in u-boot it still remains a mystery.
I've heard that Rigol adds High-Resolution to Acquire Mode for new firmware version. If this feature is available on your scope, Then congratulations!Not sure why this information would get you banned. U-Boot is GPL software for one. Secondly the software is already being shared via the forum.
I would like to post an SPI Flash dump on this thread and some other hack on appEntry. BTW, we have a u-boot dump without tear it down (In fact, the u-boot itself contains a command to switch between NOR and NAND Flash, because they share several pins), analyzing it is little troublesome. Althrough we know the u-boot passphrase, but how to check in u-boot it still remains a mystery.
rgwan, you have too much inbox stuff, get me some space. :)
I can 100% sure that the SPI Flash contains FSBL, a Zynq bit (will be overridden by the boot progress) and a U-Boot image because there's no any Zynq boot image in the NAND Flash.
So far I know the boot progress (by analyzing SPI image) is: Zynq bootrom->QSPI FSBL(XIP)->load U-boot image from SPI Flash into 0x01000000->jump to U-boot->U-boot switch the pinmux to NAND Flash->U-Boot reads env->U-boot executes env->Linux.
About the QDR SRAM controlled by Zynq, I think it is used to handle the phosphor process. Because the phosphor process needs huge random access to the framebuffer, it is reasonable to use QDR SRAM.
So, our team thinks that acquire and some DSP function is processed by K7, and plotting is processed by Zynq PL.
Not sure why this information would get you banned. U-Boot is GPL software for one. Secondly the software is already being shared via the forum.
As long as people don't attach hacked firmware files or keys onto my server I don't care what they publish.
I've heard that Rigol adds High-Resolution to Acquire Mode for new firmware version. If this feature is available on your scope, Then congratulations!
I've heard that Rigol adds High-Resolution to Acquire Mode for new firmware version. If this feature is available on your scope, Then congratulations!
It´s not the only issue got to be fixed and also I wonder why this "update" isn´t avaible for download anywhere on their sites.
The "new" Firmware seems to be preliminary, comes with "newer" 5000s out of stock, but isn´t the "final" version worth to be uploaded as an upgrade.
Hm ?
I thought, new updates will be present on the regular rigol sites…..
You got a new update ? What does the "changes" say ?
Martin
Also can someone confirm you can do math on math?
I tried with -average_filter but can't find any difference. Anyway, I can't find the hi-res mode, there is a "fine" switch in the channel settings, but without any effect on the signal.
I tried with -average_filter but can't find any difference. Anyway, I can't find the hi-res mode, there is a "fine" switch in the channel settings, but without any effect on the signal.
I think they added this option to put the average filter by default since it's really ugly without averaging. Look at all their videos, it's always averaging, with color gradient.
Righ, so a link is fine; still sharing the file, which I was after.Not sure why this information would get you banned. U-Boot is GPL software for one. Secondly the software is already being shared via the forum.Quote from: EEVblogAs long as people don't attach hacked firmware files or keys onto my server I don't care what they publish.
Cause dave said so? No problems with the thread or discussion though ( or links )
so far, rough diff is:
app.img:
shell/start.sh # add -average_filter option to appEntry
shell/send_mail.sh # finally! add model/version/serial/date to the body :clap:
resource/scpi/MEAsure.xml # cmd id + 1??
bunch of other xml, hlp or hex files
appEntry (of course)
default/precision.hex
K160_TOP.bin
(edit) many many changes in appEntry, hard to diff, but so far, no change about our prefered start option.
system.img:
/etc/passwd #we already knew that
/etc/init.d/rcS # remove echo ++ Starting ftp daemon
/etc/inittab # swap shell on ttyPS0 from /bin/ash to /bin/login, huh?
+/etc/passwd.root # this is the old one
- /lib/firmware/rtfwifi/rtl{8812,8192}*.bin # bye bye
However, what if it is NOT a hacked firmware, but the actual firmware from the device. Just extracted from. Like in this case u-boot. I don't see how that would be wrong?
-notrace_ch servtrace.cpp
-notrace_digi servtrace.cpp
-notrace_eye servtrace.cpp
-notrace_dx servtrace.cpp
-notrace_la servtrace.cpp
-log_trace servtrace.cpp
-log_ch servtrace.cpp
-log_la servtrace.cpp
-log_eye servtrace.cpp
-no_trace tracethread.cpp (trace not running)
-debug
-fullopt
-novcal (calibration??)
-no_cfg cdsophy.cpp
-noprivacy servdso_session.cpp
-default servdso_session.cpp (default settings)
-nonv
-ds8000
-log_id dsoengine_trace.cpp
-no_horiplay dsoengine_playback.cpp
-log_engine dsoengine_playback.cpp
-log_adc_cal cdsorecengine_adc.cpp
-log_hori cdsorecengine_hori.cpp
-noinit cplatform.cpp
-no_autoplay cdsoautostopengine.cpp
-log_afe chcal.cpp
-average_filter cdsorecengine_ch.cpp
-peak_compress horiunit.cpp
-wait_assert iphyccu.cpp
-DS8000 ??? :scared:But what about DS9000! That would be over 9000 easy!
USB device disconnected
DS7000Update.GEL
MSO8
DS8000Update.GEL
MSO5
DS5000Update.GEL
MSO9
DS9000Update.GEL
media
RIGOL TECHNOLOGIES,DS1000Z,SPARROW,201212
deb_msg(&v7, "servrecord_spy.cpp", 120, "void servRecord::disable_xxx(servRecord::RecordState)");
QMessageLogger::debug(&v6);
v3 = sub_43774(&v6, "servrecord_spy.cpp");
v4 = sub_4F428(v3);
v5 = sub_43774(v4, "stat:");
sub_4F428(v5);
result = QDebug::~QDebug(&v6);
Interesting piece of code:Code: [Select]deb_msg(&v7, "servrecord_spy.cpp", 120, "void servRecord::disable_xxx(servRecord::RecordState)");
QMessageLogger::debug(&v6);
v3 = sub_43774(&v6, "servrecord_spy.cpp");
v4 = sub_4F428(v3);
v5 = sub_43774(v4, "stat:");
sub_4F428(v5);
result = QDebug::~QDebug(&v6);
I did a search for all types of start options and here is a list:Code: [Select]-notrace_ch servtrace.cpp
-notrace_digi servtrace.cpp
-notrace_eye servtrace.cpp
-notrace_dx servtrace.cpp
-notrace_la servtrace.cpp
-log_trace servtrace.cpp
-log_ch servtrace.cpp
-log_la servtrace.cpp
-log_eye servtrace.cpp
-no_trace tracethread.cpp (trace not running)
-debug
-fullopt
-novcal (calibration??)
-no_cfg cdsophy.cpp
-noprivacy servdso_session.cpp
-default servdso_session.cpp (default settings)
-nonv
-ds8000
-log_id dsoengine_trace.cpp
-no_horiplay dsoengine_playback.cpp
-log_engine dsoengine_playback.cpp
-log_adc_cal cdsorecengine_adc.cpp
-log_hori cdsorecengine_hori.cpp
-noinit cplatform.cpp
-no_autoplay cdsoautostopengine.cpp
-log_afe chcal.cpp
-average_filter cdsorecengine_ch.cpp
-peak_compress horiunit.cpp
-wait_assert iphyccu.cpp
On the right is the source code module that (I think) relates to it.
If anyone wants to do experiments and share their discoveries...
ATTENTION: use at your own risk; you may brick your scope!
Has anyone done a bandwidth sweep with -fullopt and -ds8000 simultaneously?
I need some high speed signal generators it seems.
I need some high speed signal generators it seems.
Precisely that.
I need some high speed signal generators it seems.
Precisely that.
I'll get my scope mid next week, though i'll not be in teh lab. ( picking it up in teh US, on my way home )..
Can we restore the scope if we brick it yet?
I need some high speed signal generators it seems.
Precisely that.
I'll get my scope mid next week, though i'll not be in teh lab. ( picking it up in teh US, on my way home )..
Can we restore the scope if we brick it yet?
You have to do it with uboot, via serial port (requires open the box). Or JTAG...
First thing is do a NAND dump.
Only a license file will survive an upgrade.
Only a license file will survive an upgrade.
Yes, you'd need to go and 'hack' the new binarys. ( assuming they have changed ). This is of course is unverified as nobody has seen his hack yet, and they seem unwillling to share it. ( I think they feel that Rigol will close the hack if they release it ). It is very hard to know, who is who, Part of me thinks that Rigol itself might be feeding part of the info in this thread. The change of password in teh latest fw, was extremely weak. There were lots of things that could have been done ( and simply )... They theory that they want to be hacked has merit.
Only a license file will survive an upgrade.
The change of password in teh latest fw, was extremely weak.Remember that this firmware has been created before the release of Dave’s teardown video. It was not a reaction to our hacks.
So it needs to find someone who bought an upgrade ( option-bundle, bandwith or memory) to find the differences before/after upgrading ?There are license files for the demo mode of the decoders. Location and format of the files are known.
@Oliv3r, thanks for the qspi push, but could you fix the missing / at col2 line 1 in qspi_unpack.sh and remove the -eu also?
I need some high speed signal generators it seems.
Precisely that.
I'll get my scope mid next week, though i'll not be in teh lab. ( picking it up in teh US, on my way home )..
Can we restore the scope if we brick it yet?
You have to do it with uboot, via serial port (requires open the box). Or JTAG...
First thing is do a NAND dump.
Anyone played around with trying to make the fullopt stuff permanent? Tried Radare2 but I am not that great with it and appEntry is huge.That's because appEntry is a statically compiled binary with everything in it; well almost everything. There's tons of XML output even compiled into the app. Crazy.
That of course helps a great deal, even if indirectly. And I think it's basically files from /rigol/data ...Only a license file will survive an upgrade.
Hm-hm....
So it needs to find someone who bought an upgrade ( option-bundle, bandwith or memory) to find the differences before/after upgrading ?
Yeah it has a bunch of crap in it. Some tantalizing bits including their scpi parser as well. I think they are using ecdsa for key digests which is smart, makes the short keys make more sense.Anyone played around with trying to make the fullopt stuff permanent? Tried Radare2 but I am not that great with it and appEntry is huge.That's because appEntry is a statically compiled binary with everything in it; well almost everything. There's tons of XML output even compiled into the app. Crazy.
The only think I think they are loading externally via dlopen is Qt5.5 ...
So it needs to find someone who bought an upgrade ( option-bundle, bandwith or memory) to find the differences before/after upgrading ?There are license files for the demo mode of the decoders. Location and format of the files are known.
############################################
#Mount key data partition. cost:1s
############################################
/rigol/shell/mount_user_space.sh 0
$TOOLS/beeper
#Don't allow the kernel to output
echo 0 > /proc/sys/kernel/printk
if [ $YourInput -eq '0' ]; then
#########################################################
# mount data partition for Calibration and License data
#########################################################
mount_mtd $SPACE_DATA $SPACE_DATA $DATA_PATH "DATA"
Result=$?
if [ $Result -ne 0 ]; then
if [ $Result -ne 1 ]; then
echo 'mounting DATA partition failed'
/rigol/tools/beeper 1
else
cp /rigol/default/* $DATA_PATH
fi
fi
fi
cd /tmp
ps -ef | grep appEntry
ulimit -c unlimited
kill -ABRT <appEntry PID>
Core should be dumped and can be copied over to USB jumpdrive for analysis on PC. I'd try this myself if my scope was here.Hah, how much time would it take to remove sshd?
The files that seem to be interesting there are not calibration files (.hex), but Key.data, sysvendor.bin and various .lic files. Key.data is read from and written to it seems based on options installed. sysvendor.bin is also read from/written to. Various .lic files are of format <OPTION>;<KEY>. There are also references to ECC cryptography in appEntry, which is what was used before for licensing. I looked at some old code for generating licenses that used ecc crypto and the hash of choice was SHA1 (20 bytes/40 hex characters). New keys seems to be SHA512 (64 bytes/128 hex characters). I could be completely wrong though as I have no way to test any of the stuff until my scope arrives. My Zynq board is in use elsewhere currently.
The files that seem to be interesting there are not calibration files (.hex), but Key.data, sysvendor.bin and various .lic files. Key.data is read from and written to it seems based on options installed. sysvendor.bin is also read from/written to. Various .lic files are of format <OPTION>;<KEY>. There are also references to ECC cryptography in appEntry, which is what was used before for licensing. I looked at some old code for generating licenses that used ecc crypto and the hash of choice was SHA1 (20 bytes/40 hex characters). New keys seems to be SHA512 (64 bytes/128 hex characters). I could be completely wrong though as I have no way to test any of the stuff until my scope arrives. My Zynq board is in use elsewhere currently.
The .hex files have smple CRC32 protecting them but, of course, are of no use.
The key.dat has a ECC Curve + PubKey inside. It's XXTEA encrypted.
The sysvendor.bin is also XXTEA encrypted with another key. Contains info about the scope inside (SN, MAC, etc)
The LICs are related to the key in key.dat.
In hash terms I see evidences only of SHA256 use but may be incomplete.
The memdumps from zynq are not helpful. At least, worse that I expected.
A byte pacthing solution is the most easy and obvious one, besides the -fullopt feature.
From what I've seen it could be done in a couple of days. Easy for me to believe that rgwan & friends have done it already. Don't discredit them.
A future-proof solution can also be done, it's just a matter of tuning other factors. Probably just as easy.
Discovering how to go beyond the stated features is the hard part (hoping that the HW is able to physically handle it...)
BTW, I'm not buying the theory that Rigol is making things easy on purpose. I believe that we'll see more evidences of that in future updates. Give them time.
Btw, We already have our license generator, But patch the application is necessary, at least this application will send a report contains Sn and license state to Rigol server on power up. If you want your scope keep on the Internet, you have to patch it, otherwise you may lose your warranty.
So, we're waiting for new firmware. When it is ready, then We will ready to release.
Well, does anyone noticed that the CH1 and CH3 has overshoot on measuring calibration square wave? And you can't remove it by adjust the probe.
Wow, that's impressive. How did you guys do it? Did they mess up in the key validation/generation and leave the priv key exposed somehow? Or, knowing Rigol, something dumber :D I wouldn't put these scopes on the internet, given that they have SSH exposed. Best to keep them isolated!It would be impressive if it was verified. What is impressive is olivers repo, and tv84s infomation. This is the internet, been around way too long and am probably very cynical, but seen lots of claims of things, and have learned until you can actually verify things, you can't put much weight on them.
Thanks :) Just dropping a nother note here however, it is all WiP and any damages to your scope are not my responsibility nor fault. Can't iterate this often enough, as I have not tested everything very well yet (the scripts on the scope) as I do not have one yet :)Wow, that's impressive. How did you guys do it? Did they mess up in the key validation/generation and leave the priv key exposed somehow? Or, knowing Rigol, something dumber :D I wouldn't put these scopes on the internet, given that they have SSH exposed. Best to keep them isolated!It would be impressive if it was verified. What is impressive is olivers repo, and tv84s infomation. This is the internet, been around way too long and am probably very cynical, but seen lots of claims of things, and have learned until you can actually verify things, you can't put much weight on them.
What I really want at some point however is (broken scope anyone :D) is to desolder all parts and 'sand down' the PCB with pictures, as I want to know where all the ZYNQ pins connect too :p
If you want to see something funny, try this:
Connect generator 1 to CH1, enable and change to square. Manually enter 999kHz as frequency then observe the waveform change when increasing to 1MHz.
Not worth 269$.
- Generator, the knob to change the frequency: turn left -> -10 , turn right +1
- CH1, probe to ground: never read 0V, but depends on vertical scale:
Well its worth a try sure; but it's a 4 or probably 6 layer board, with chips ontop. So it can give you an indication, very roughly. Best way is to just the PCB down layer for layer and scan the PCB.What I really want at some point however is (broken scope anyone :D) is to desolder all parts and 'sand down' the PCB with pictures, as I want to know where all the ZYNQ pins connect too :p
This might be a job for an Xray inspection? Not sure how many layers the PCB is of course..
Well its worth a try sure; but it's a 4 or probably 6 layer board, with chips ontop. So it can give you an indication, very roughly. Best way is to just the PCB down layer for layer and scan the PCB.
But first a scope needs to break >:D or we raid the PCB factory's trash-bin where they dump broken PCB's :-DD
- Generator, the knob to change the frequency: turn left -> -10 , turn right +1
- CH1, probe to ground: never read 0V, but depends on vertical scale:
Generator Knob behaves like this only when decrasing from like 1MHz to sub 1Mhz (or 1kHz to Hz).
This is because the increments above 1Mhz are in 10kHz steps and the first decrement therefore is as well. If you are then in the kHz-range the decrements are 1kHz. I don't think this is a bug.
For your CH1 problem, this does not happen on my scope, probe to GND always reads 0V (more or less).
Also you have to adjust the scale of the math channel, this normally would be the larger scale setting of the two channels (when operation A+B is chosen).
I'm now running the self cal procedurePlease record how long it takes.
That's pretty embarrassing, self-cal won't workHave you disconnected all probes from the inputs before running self-cal?
We should start a new thread for those numerous bugs.
TopLoser is playing with Photoshop...
Coming back to the logic probe pod, I've created separate thread with teardown photos of RPL1116 pod for MSO1000Z series. It seems to be very similar to PLA2216 for MSO5000.Considering they also use the LMH7322 I think they are identical (in the schematic form) on page 6? TopLoser took some xray foto's. But yes, lets keep the conversation focused in your thread instead.
https://www.eevblog.com/forum/testgear/rpl1116-active-logic-probe-pod-for-1000z-series-teardown/msg2085451/#msg2085451 (https://www.eevblog.com/forum/testgear/rpl1116-active-logic-probe-pod-for-1000z-series-teardown/msg2085451/#msg2085451)
Not too difficult to replicate.
awesome great idea; we can talk about hacking here then :)We should start a new thread for those numerous bugs.
So we did. Here you go. Bugs away!
https://www.eevblog.com/forum/testgear/rigol-5000-bugs/ (https://www.eevblog.com/forum/testgear/rigol-5000-bugs/)
And now, average(64) + fine + aliasing does something : a very fine trace (1px). To All: Do run a self cal.
That is no difference between x10 and x1. No matter how you adjust the probe, the little overshoot won't disappear.
That is no difference between x10 and x1. No matter how you adjust the probe, the little overshoot won't disappear.
Although I don´t have the issue with my 5074, it sounds like a mismatch problem - we bought a couple of probes cause the originals were mostly "vanished"...
On some scopes there was no problem to adjust them.
Other scopes showed exactly your problem - we couldn´t compensate the overshoots completely, it´s a matter oft the Input capacity.
Only with their original probes everything was fine.
Either the input capacity on your rigol was different (tolerance) or the probes are defective.
Same exact overshoot in every case at 1kHz
We should start a new thread for those numerous bugs.
So we did. Here you go. Bugs away!
https://www.eevblog.com/forum/testgear/rigol-5000-bugs/ (https://www.eevblog.com/forum/testgear/rigol-5000-bugs/)
The overshoot is likely due to a factory adjustment of the input circuit. Is there some way to run a self-calibration or adjustment procedure? I don't recall whether there is a trim capacitor in the input circuit or not.QuoteThat is no difference between x10 and x1. No matter how you adjust the probe, the little overshoot won't disappear.A little to my dismay, I found the same result on the MSO7k we have at work. Tried different probes with slightly different loading, square waves from a few different sources. Same exact overshoot in every case at 1kHz, which seemed a bit odd :/
Although I don´t have the issue with my 5074, it sounds like a mismatch problem - we bought a couple of probes cause the originals were mostly "vanished"...
On some scopes there was no problem to adjust them.
Other scopes showed exactly your problem - we couldn´t compensate the overshoots completely, it´s a matter oft the Input capacity.
Only with their original probes everything was fine.
Either the input capacity on your rigol was different (tolerance) or the probes are defective.
I'll try the other 7k in the office that came in from the same batch tomorrow as well.
The overshoot is likely due to a factory adjustment of the input circuit. Is there some way to run a self-calibration or adjustment procedure? I don't recall whether there is a trim capacitor in the input circuit or not.
Gentlemen,
Is it so difficult to take all this OT to another thread? >:(
qemu-system-aarch64: -serial mon:pty: char device redirected to /dev/pts/19 (label serial0-base)
qemu-system-aarch64: -serial mon:pty: char device redirected to /dev/pts/20 (label serial2-base)
qemu-system-aarch64: warning: nic ethernet@e000c000 has no peer
rom: requested regions overlap (rom bootloader. free=0x000000000000ed70, addr=0x0000000000000000)
U-Boot 2018.01 (Jan 04 2019 - 11:47:57 -0800) Xilinx Zynq ZC702
Model: Zynq ZC702 Development Board
Board: Xilinx Zynq
Silicon: v0.0
I2C: ready
DRAM: ECC disabled 1 GiB
MMC: Card did not respond to voltage select!
mmc_init: -95, time 12
sdhci@e0100000 - probe failed: -95
Card did not respond to voltage select!
mmc_init: -95, time 11
SF: Detected n25q512 with page size 256 Bytes, erase size 4 KiB, total 64 MiB
*** Warning - bad CRC, using default environment
In: serial@e0001000
Out: serial@e0001000
Err: serial@e0001000
Model: Zynq ZC702 Development Board
Board: Xilinx Zynq
Silicon: v0.0
Net: ZYNQ GEM: e000b000, phyaddr 7, interface rgmii-id
eth0: ethernet@e000b000
U-BOOT for xilinx-zc702-2018_2
BOOTP broadcast 1
DHCP client bound to address 192.168.76.9 (2 ms)
Hit any key to stop autoboot: 0
Zynq> tftpboot 0x03000000 image.ub
Using ethernet@e000b000 device
TFTP from server 10.5.3.218; our IP address is 192.168.76.9; sending through gateway 192.168.76.2
Filename 'image.ub'.
Load address: 0x3000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
###########
15 MiB/s
done
Bytes transferred = 33554432 (2000000 hex)
Zynq> printenv baudrate
baudrate=115200
Zynq> bootm
## Loading kernel from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Verifying Hash Integrity ... OK
Trying 'kernel@1' kernel subimage
Description: Kerstrel Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x030000f8
Data Size: 3302448 Bytes = 3.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00100000
Entry Point: 0x00100000
Hash algo: sha1
Hash value: bece162e8cad943c68714d8eb8020d68e1db896b
Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'ramdisk@1' ramdisk subimage
Description: kerstrel-Update-Ramdisk
Type: RAMDisk Image
Compression: gzip compressed
Data Start: 0x03328c5c
Data Size: 10901113 Bytes = 10.4 MiB
Architecture: ARM
OS: Linux
Load Address: unavailable
Entry Point: unavailable
Hash algo: sha1
Hash value: 55bdcbebccba845da403130143793ee0135e53a1
Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'fdt@1' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x0332661c
Data Size: 9597 Bytes = 9.4 KiB
Architecture: ARM
Hash algo: sha1
Hash value: da2d17ba0d5a71b5897deec4cb026014f3132185
Verifying Hash Integrity ... sha1+ OK
Booting using the fdt blob at 0x332661c
Loading Kernel Image ... OK
Loading Ramdisk to 0759a000, end 07fff679 ... OK
Loading Device Tree to 07594000, end 0759957c ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.12.0-xilinx (rigolee@Jim) (gcc version 4.8.1 (Sourcery CodeBench Lite 2013.11-53) ) #43 SMP PREEMPT Sat Jul 28 12:14:01 CST 2018
CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq
Memory policy: Data cache writealloc
PERCPU: Embedded 8 pages/cpu @c0e74000 s8384 r8192 d16192 u32768
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260624
Kernel command line: console=ttyPS0,115200 no_console_suspend, root=/dev/ram rw
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1022228K/1048576K available (4197K kernel code, 255K rwdata, 1716K rodat a, 176K init, 179K bss, 26348K reserved, 270336K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
lowmem : 0xc0000000 - 0xef800000 ( 760 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 16
ps7-slcr mapped to f0004000
Zynq clock init
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 1454.89 BogoMIPS (lpj=7274496)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0xc03fa6b8 - 0xc03fa710
L2x0 series cache controller enabled
l2x0: 8 ways, CACHE_ID 0x00000000, AUX_CTRL 0x00000000, Cache size: 512 kB
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 0
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
gpio->base_addr is:0xf0050000
The gpio irq num is:52
zynq_gpio e000a000.ps7-gpio: gpio at 0xe000a000 mapped to 0xf0050000
hw-breakpoint: debug architecture 0x4 unsupported.
zynq_ocm f800c000.ps7-ocmc: ZYNQ OCM pool: 256 KiB @ 0xf0080000
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@l inux.it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: 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 initrd
Freeing initrd memory: 10644K (c759a000 - c7fff000)
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 1 counters available
Boot process: fb dev not inited, boot process not start!
bounce pool size: 64 pages
NTFS driver 2.1.30 [Flags: R/W].
msgmni has been set to 1489
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
bg request_mem_region failed!
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0xf c/0x17c()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-xilinx #43
[<c0015074>] (unwind_backtrace+0x0/0x11c) from [<c0011568>] (show_stack+0x10/0x1 4)
[<c0011568>] (show_stack+0x10/0x14) from [<c03f5c08>] (dump_stack+0x8c/0xd4)
[<c03f5c08>] (dump_stack+0x8c/0xd4) from [<c00218a4>] (warn_slowpath_common+0x60 /0x84)
[<c00218a4>] (warn_slowpath_common+0x60/0x84) from [<c0021958>] (warn_slowpath_n ull+0x18/0x20)
[<c0021958>] (warn_slowpath_null+0x18/0x20) from [<c001a484>] (__arm_ioremap_pfn _caller+0xfc/0x17c)
[<c001a484>] (__arm_ioremap_pfn_caller+0xfc/0x17c) from [<c001a550>] (__arm_iore map_caller+0x4c/0x54)
[<c001a550>] (__arm_ioremap_caller+0x4c/0x54) from [<c001a25c>] (__arm_ioremap+0 x14/0x1c)
[<c001a25c>] (__arm_ioremap+0x14/0x1c) from [<c02321b0>] (xilinxfb_of_probe+0x74 /0x3d8)
[<c02321b0>] (xilinxfb_of_probe+0x74/0x3d8) from [<c02684a0>] (platform_drv_prob e+0x14/0x18)
[<c02684a0>] (platform_drv_probe+0x14/0x18) from [<c0267208>] (driver_probe_devi ce+0x11c/0x324)
[<c0267208>] (driver_probe_device+0x11c/0x324) from [<c02674bc>] (__driver_attac h+0x68/0x8c)
[<c02674bc>] (__driver_attach+0x68/0x8c) from [<c02656a8>] (bus_for_each_dev+0x7 0/0x84)
[<c02656a8>] (bus_for_each_dev+0x70/0x84) from [<c02667f0>] (bus_add_driver+0xfc /0x268)
[<c02667f0>] (bus_add_driver+0xfc/0x268) from [<c0267ab8>] (driver_register+0x9c /0xe0)
[<c0267ab8>] (driver_register+0x9c/0xe0) from [<c00087ac>] (do_one_initcall+0xb8 /0x15c)
[<c00087ac>] (do_one_initcall+0xb8/0x15c) from [<c05cfb9c>] (kernel_init_freeabl e+0x108/0x1cc)
[<c05cfb9c>] (kernel_init_freeable+0x108/0x1cc) from [<c03f1e50>] (kernel_init+0 x8/0xe4)
[<c03f1e50>] (kernel_init+0x8/0xe4) from [<c000e5b8>] (ret_from_fork+0x14/0x3c)
---[ end trace ca10809752213256 ]---
DPU:Map vRam to 0x0
DPU:Map iReg to 0xf0200000
DPU:Ver=0x0
Could not allocate frame buffer memory
devDPU: probe of 40000000.ps7-fb failed with error -12
dma-pl330 f8003000.ps7-dma: unable to set the seg size
dma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-2364208
dma-pl330 f8003000.ps7-dma: DBUFF-256x8bytes Num_Chans-8 Num_Peri-4 Num_Even ts-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 992063) is a x uartps
console [ttyPS0] enabled
xuartps e0001000.serial: failed to get alias id, errno -19
e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 992063) is a x uartps
brd: module loaded
loop: module loaded
xspips e0006000.ps7-spi: master is unqueued, this is deprecated
xspips e0006000.ps7-spi: at 0xE0006000 mapped to 0xF005A000, irq=58
libphy: XEMACPS mii bus: probed
xemacps e000b000.ps7-ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ULPI transceiver vendor/product ID 0x0000/0x0000
ULPI integrity check: failed!
xusbps-dr e0002000.ps7-usb: Unable to init USB phy, missing?
ULPI transceiver vendor/product ID 0x0000/0x0000
ULPI integrity check: failed!
xusbps-dr e0003000.ps7-usb: Unable to init USB phy, missing?
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-rx8010sj 0-0032: Unable to write register #23
i2c i2c-0: probing for rx8010 failed
rtc-rx8010sj: probe of 0-0032 failed with error -110
Retry another address of GTP
input: Goodix-TS as /devices/virtual/input/input0
xi2cps e0004000.ps7-i2c: 90 kHz mmio e0004000 irq 57
zynq-edac f8006000.ps7-ddrc: ecc not enabled
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
NAND device: Manufacturer ID: 0x20, Chip ID: 0xaa (ST Micro NAND 256MiB 1,8V 8-bit), 256MiB, page size: 2048, OOB size: 64
pl353_nand_calculate_hwecc status failed
pl353_nand_calculate_hwecc status failed
pl353_nand_calculate_hwecc status failed
pl353_nand_calculate_hwecc status failed
Bad block table not found for chip 0
pl353_nand_calculate_hwecc status failed
pl353_nand_calculate_hwecc status failed
pl353_nand_calculate_hwecc status failed
pl353_nand_calculate_hwecc status failed
Bad block table not found for chip 0
Scanning device for bad blocks
pl353_nand_calculate_hwecc status failed
Bad block table written to 0x00000ffe0000, version 0x01
pl353_nand_calculate_hwecc status failed
Bad block table written to 0x00000ffc0000, version 0x01
13 ofpart partitions found on MTD device pl353-nand
Creating 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"
mtd: partition "Sys2" extends beyond the end of device "pl353-nand" -- size truncated to 0x1f00000
0x000010100000-0x000016500000 : "App2"
mtd: partition "App2" is out of reach -- disabled
0x000016500000-0x00001a800000 : "Reserved"
mtd: partition "Reserved" is out of reach -- disabled
0x00001a800000-0x000040000000 : "User"
mtd: partition "User" is out of reach -- disabled
TCP: cubic registered
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 176K (c05cf000 - c05fb000)
Starting rcS...
++ Mounting filesystem
++ Setting up mdev
++ Starting ftp daemon
rcS Complete
pl353_nand_calculate_hwecc status failed
<snip>
Segmentation fault
mount: mounting /dev/ubi6_0 on /rigol failed: Invalid argument
**********Mount App partition failed.Check Nandflash********
Scope arrived yesterday. :) old version of firmware installed but calibrated at the end of December. Seems that everything works as expected.
Scope arrived yesterday. :) old version of firmware installed but calibrated at the end of December. Seems that everything works as expected.
Likewise here.
Neither the probe calibration signal nor a 1 Khz signal from the function generator (after "hacking" it of course) result in a stable waveform, there's lots of jitter! This is a bit worrisome, is that expected?
I've been sniffing my scope on an isolated network for 3 hours now and so far the only network traffic was the initial DHCP address assignment. If it's phoning home it's not doing it very aggressively.
Skip
When I tried to get http://www.rigol.com/Support/ProductUpgradePackage?sn=MS5xxxxxxxxxx (http://www.rigol.com/Support/ProductUpgradePackage?sn=MS5xxxxxxxxxx) from my browser I got a "Something went wrong."I've tried it with 3 different serial numbers and it always starts to download the firmware GEL.
When I tried to get http://www.rigol.com/Support/ProductUpgradePackage?sn=MS5xxxxxxxxxx (http://www.rigol.com/Support/ProductUpgradePackage?sn=MS5xxxxxxxxxx) from my browser I got a "Something went wrong."I've tried it with 3 different serial numbers and it always starts to download the firmware GEL.
Did you try a bogus serial number?I've tried some and they didn't work and lead to the error page. But I've captured an upload from the scope to the server.
So if I bought a rigol mso5000 in next week, can it then be hacked?
Sorry I am asking, it's because I am a noob and all those 22 pages of informations and comments confuse me.
Thanks for you wary fast answer!! :-)
Is there anything that I shall think about, except for the guaranty being void?
I mean before jumping out and buy.
Does anybody know where the scope stores configuration settings?
I've tried altering stuff like the email configuration and then looked for modified files using: find / -type f -mmin -1 but I did not find any files with interesting content, so it seems there's no simple config file that stores the settings.
There is the very real risk that in future software updates all the 'bonus' features will disappear. Only you can decide if you want to take that risk.
So if I bought a rigol mso5000 in next week, can it then be hacked?
Sorry I am asking, it's because I am a noob and all those 22 pages of informations and comments confuse me.
There is the very real risk that in future software updates all the 'bonus' features will disappear. Only you can decide if you want to take that risk.
These annoying bug will force you to install further updates.
These annoying bug will force you to install further updates.
We now know so much about the MSO5000 that whatever Rigol does will be re-hacked in a hours.
(and nobody is *forcing* you to install updates)
I'm not sure why Rigol changed the password. The new password was obviously weak and if they want to keep people out they could just disable shell access completely (there's no reason to enable it, it's not useful to anybody except hackers).
I think they just didn't want it to be root/root to avoid basic IOT malware scanners.
He ( and I ) remain unconvinced that Rigol are deliberately making their devices 'hackable'. Its just they dont' know how to secure them properly.
I'm not sure why Rigol changed the password. The new password was obviously weak and if they want to keep people out they could just disable shell access completely (there's no reason to enable it, it's not useful to anybody except hackers).
I think they just didn't want it to be root/root to avoid basic IOT malware scanners.
I had an interesting chat ( face to face ) with another eevblog member last week ( who is well known and respected ) about the entire rigol thing. He ( and I ) remain unconvinced that Rigol are deliberately making their devices 'hackable'. Its just they dont' know how to secure them properly. Not suprizingly, so many 'devices' these days that are network attached, are just so insecure.. The IoT will be the finish of us all!
I beg to differ.He ( and I ) remain unconvinced that Rigol are deliberately making their devices 'hackable'. Its just they dont' know how to secure them properly.
Complete bollocks.
Even the cheapo DS1000Z line can't be hacked easily once you get above the base model (eg. the DS1074Z Plus (https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/4303/))
In the new 5000/7000 models? Xilinx secure boot is hardly a secret, they freely document it on their web site (https://www.xilinx.com/support/documentation/application_notes/xapp1175_zynq_secure_boot.pdf).
Whatever the reasons are, it's not incompetence.
These annoying bug will force you to install further updates.
The trick is not to install them two seconds after they're released.
Wait a few days until other people have done it. :popcorn:
He ( and I ) remain unconvinced that Rigol are deliberately making their devices 'hackable'. Its just they dont' know how to secure them properly.
Complete bollocks.
Even the cheapo DS1000Z line can't be hacked easily once you get above the base model (eg. the DS1074Z Plus (https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/4303/))
In the new 5000/7000 models? Xilinx secure boot is hardly a secret, they freely document it on their web site (https://www.xilinx.com/support/documentation/application_notes/xapp1175_zynq_secure_boot.pdf).
Whatever the reasons are, it's not incompetence.
But secure-boot is hard and expensive. Getting the fuses set is something (I guess) will have to be done by xilinx in the factory, which is an extra service, not cheap.This is BS. No extra service is needed, everything can be done via JTAG just like regular programming/configuration.
Understanding how it all works and comes together, is also; not for the fait of heart.Reading documentation is all it takes. But even if we suppose they are somehow too stupid to figure it out (yet somehow manage a several orders of magnitude more complicated task of designing an actual system in FPGAs), they could always enlist Xilinx FE to help them out.
There there no need to be cross.But secure-boot is hard and expensive. Getting the fuses set is something (I guess) will have to be done by xilinx in the factory, which is an extra service, not cheap.This is BS. No extra service is needed, everything can be done via JTAG just like regular programming/configuration.
Different task, different people, different skill. They are a _hardware_ company, and while *I* feel that VHDL/Verilog programming is just a different skill of programming; it tends to be done by EE's. As such bringing up a secure linux with UI is not their problem.Understanding how it all works and comes together, is also; not for the faint of heart.Reading documentation is all it takes. But even if we suppose they are somehow too stupid to figure it out (yet somehow manage a several orders of magnitude more complicated task of designing an actual system in FPGAs), they could always enlist Xilinx FE to help them out.
I suggest you stop projecting. They clearly can read documentation, and I'm 99,(9)% sure they leave devices open on purpose.
Rather than incompetence, it could just be laziness, or not enough time. The engineer just does the bare minimum that the manager asks.I think it boils down to the Chinese mentality of making a product just good enough to ship.
The manager finds on the net that you can log in with root/root and hack the scope, he asks the engineer to fix it ASAP. 5 minutes later he tries again to log in, he gets an error message, he is happy. Everyone is happy. Problem solved.
Rather than incompetence, it could just be laziness, or not enough time. The engineer just does the bare minimum that the manager asks.Of course; but the work I see is extremely sloppy and lazy and very unexperienced. Even if it is an engineer who does not dare to push back to the manager; There's quality, and there's ... well this :)
The manager finds on the net that you can log in with root/root and hack the scope, he asks the engineer to fix it ASAP. 5 minutes later he tries again to log in, he gets an error message, he is happy. Everyone is happy. Problem solved.
Rather than incompetence, it could just be laziness, or not enough time. The engineer just does the bare minimum that the manager asks.I think it boils down to the Chinese mentality of making a product just good enough to ship.
The manager finds on the net that you can log in with root/root and hack the scope, he asks the engineer to fix it ASAP. 5 minutes later he tries again to log in, he gets an error message, he is happy. Everyone is happy. Problem solved.
Security is a very complex issue, and needs some imaginitive thinking (something that is very rare in China due to the educational system), to consider and pre-empt possible entry points.
You can put the best lock in the world on the front door but that's no good if you can open a window with screwdriver.
FPGA systems and tools are very complex, and so is Linux, and the designers need to have a far better grasp on it all to make it secure, than they do to ship a working product.
Firmware 01.01.03.05 Patch Notes:
- Incorporated all security features/approaches discussed on eevblog forums (thnx u)
Maybe I misunderstood the topic of this thread. I thought we were trying to hack the MSO5000, not advise Rigol on how to make it unhackableEEVBLOG hacker's moto: No challenge, no fun
:-DDCode: [Select]Firmware 01.01.03.05 Patch Notes:
- Incorporated all security features/approaches discussed on eevblog forums (thnx u)
Somebody asked me to post a photo of my 'system information' screen.
Rather than incompetence, it could just be laziness, or not enough time. The engineer just does the bare minimum that the manager asks.
The manager finds on the net that you can log in with root/root and hack the scope, he asks the engineer to fix it ASAP. 5 minutes later he tries again to log in, he gets an error message, he is happy. Everyone is happy. Problem solved.
Somebody asked me to post a photo of my 'system information' screen.
Were you a beta tester??? :-DD
Did anyone try to make their own (PLA2216) logic probe for cheap, considering it is priced at $400!
Did anyone try to make their own (PLA2216) logic probe for cheap, considering it is priced at $400!Should be easy enough as it's just a bunch of ECL comparators. Probably just a matter of time before they show up on Aliexpress
What does this image show?
What does this image show?
350ps fal time? 1GHz bandwidth?
What does this image show?What is your signal source?
It's a transistor catching fire?
It's a transistor catching fire?
We are almost OT but I would like to see if you guys confirm that this can be used as proof of the claims that were made a few weeks ago...
BTW, Fungus, can you recreate this with your (any) scope?
Fungus searching for "Avalanche Pulser" then you will know what it is.
And that 90V ist OK for an Avalanche Transistor...
It's a transistor catching fire?
We are almost OT but I would like to see if you guys confirm that this can be used as proof of the claims that were made a few weeks ago...
BTW, Fungus, can you recreate this with your (any) scope?
Did you calibrate the KC901V to remove the cable effects?
Have you checked the return loss of the terminator itself?
Can you run it with a lower max frequency as anything above 500 MHz/ 1 GHz is likely meaningless.
Lastly many scopes 50 ohm inputs are only rated to have an SWR of 1.5:1 or better - that is only 14 dB of return loss.
I don't think you're seeing any problem with the scope, it is just the nature of trying to use a 50 ohm feed through connected to the 1 meg-ohm input of a scope. A scope with a 50 ohm internal path is optimized for such things. Using a feed-through will only match a proper 50 ohm input at very low frequencies.
Here is an example of what my Keysight scope looks like with its native 50 ohm input, and then using a 50 ohm feed-through with the scope input back at 1 meg-ohm. It looks absolutely horrible using the feed-through. The third shot is the 50 ohm feed-through on its own just for reference.
I don't think you're seeing any problem with the scope, it is just the nature of trying to use a 50 ohm feed through connected to the 1 meg-ohm input of a scope. A scope with a 50 ohm internal path is optimized for such things. Using a feed-through will only match a proper 50 ohm input at very low frequencies.
Here is an example of what my Keysight scope looks like with its native 50 ohm input, and then using a 50 ohm feed-through with the scope input back at 1 meg-ohm. It looks absolutely horrible using the feed-through. The third shot is the 50 ohm feed-through on its own just for reference.
I mean this scope is not designed for testing above 350MHz signal. It just not perform well and maybe it needs some hardware modification to make use of the high sample rate.
I don't think you're seeing any problem with the scope, it is just the nature of trying to use a 50 ohm feed through connected to the 1 meg-ohm input of a scope. A scope with a 50 ohm internal path is optimized for such things. Using a feed-through will only match a proper 50 ohm input at very low frequencies.
Here is an example of what my Keysight scope looks like with its native 50 ohm input, and then using a 50 ohm feed-through with the scope input back at 1 meg-ohm. It looks absolutely horrible using the feed-through. The third shot is the 50 ohm feed-through on its own just for reference.
I mean this scope is not designed for testing above 350MHz signal. It just not perform well and maybe it needs some hardware modification to make use of the high sample rate.
You cannot just hack it.. For higher frequencies you need to use 50 OHm path, and that has to exist in the scope from input connector to A/D converter. It has to be controlled impedance layout.
Basically, it has to exist as separate part of PCB made for just that purpose that is just not there on MSO5000 board.
Chipset and front end chip in MSO7000 and MSO5000 is identical and capable of same bandwidth (frontend chipset is capable of few GHz actually). It's just that your signal from input BNC cannot get to it without being destroyed.
For a scope of this class it is more important that it has good 300 MHz with good signal integrity(which is a miracle itself), that hacking it to 1GHz with distorted signal. You get worse scope actually, and much more noise...
Here is an example of what my Keysight scope looks like with its native 50 ohm input, and then using a 50 ohm feed-through with the scope input back at 1 meg-ohm. It looks absolutely horrible using the feed-through. The third shot is the 50 ohm feed-through on its own just for reference.
Slightly off topic. TEquipment has 2 MSO5074 in stock. It was 3 before I bought one :Pwtf? I bought one and got my delivery bumped back and forth
wtf? I bought one and got my delivery bumped back and forthYeah my confirmation e-mail indicates a shipping date of the 15th. I suspect shenanigans
wtf? I bought one and got my delivery bumped back and forthYeah my confirmation e-mail indicates a shipping date of the 15th. I suspect shenanigans
anyone tried logging in with firmware version 00.01.01.02.04? Build: 2018-11-09 19:49:21
i ordered the mso5074 after reading about the "hack" on hackaday. received it an hour ago, but can't log in over the lan interface & ssh...
Chipset and front end chip in MSO7000 and MSO5000 is identical and capable of same bandwidth (frontend chipset is capable of few GHz actually). It's just that your signal from input BNC cannot get to it without being destroyed.
For a scope of this class it is more important that it has good 300 MHz with good signal integrity(which is a miracle itself), that hacking it to 1GHz with distorted signal. You get worse scope actually, and much more noise...
Chipset and front end chip in MSO7000 and MSO5000 is identical and capable of same bandwidth (frontend chipset is capable of few GHz actually). It's just that your signal from input BNC cannot get to it without being destroyed.
For a scope of this class it is more important that it has good 300 MHz with good signal integrity(which is a miracle itself), that hacking it to 1GHz with distorted signal. You get worse scope actually, and much more noise...
By looking at these FW strings (in the current models):
600MHz to 1GHz Bandwidth Upgrade Option
600MHz to 2GHz Bandwidth Upgrade Option
1GHz to 2GHz Bandwidth Upgrade Option
I would imagine that ds8000 (or ds9000) could be available in 600MHz or 1GHz base, with options to upgrade to 2GHz.
Let's hope that with another PCB as you say.
No need for speculation. 8000 is up to 2GHz model.
9000 is yet to be released up to 4GHz model.
Spoke with Rigol on Electronica. 8000 was there, looks pretty much like black 7000....
As Dave Jones pointed out already in his review: The entry level DS1054Z series seems to have a better display than the MSO5000 series. How come? Did you change display vendor?
One is a touch screen. Matte touch screens show all the fingerprints much more.Actually, it's quite the opposite. I always use a matte screen protector on my smartphones and fingerprints are much less visible there compared to a glossy screen.
I was on Friday, last day.. I might have been mistaken,it was a long day..
No need for speculation. 8000 is up to 2GHz model.
9000 is yet to be released up to 4GHz model.
Spoke with Rigol on Electronica. 8000 was there, looks pretty much like black 7000....
There where no DS/MSO8000 on the Electronica fair? IIRC the RSA5000 was the only black instrument at the Rigol stand apart from the MSO5000.
anyone tried logging in with firmware version 00.01.01.02.04? Build: 2018-11-09 19:49:21
i ordered the mso5074 after reading about the "hack" on hackaday. received it an hour ago, but can't log in over the lan interface & ssh...
Thought maybe the update is only via online connection to the scope avaible and take it to home, connect LAN...
No, no firmare avaible.
This resistor had been left off the circuit board.
The corrupted data out of the MSO5074 was found to be caused by varying widths of the Low going data bits in the serial data stream.
At 115200 bits/sec, the nominal bit width is 8.68us. Some of the Low going bits from the UART interface were down to 3us width.
The over all packet timing was correct, just the width of the low going bits varied.
So depending on when the receiving equipment clocks the data in, it may see either a "0" or "1"
This was solved by feeding the data through an external Pulse stretching circuit to set the minimum bit width correctly.
The second issue of no response to commands was tracked down to an open circuit on the PCB trace from the UART interface connection point.In the video #1146 Dave wasn't able to send commands to it either, but then if you where following along on this thread others have tried the UART interface and where able to use it with no problem and no mention of a missing resistor, and if you let it boot completely you should get a root shell without being asked to login, right?
The Data IN to the MSO5074 goes via a series resistor. This resistor had been left off the circuit board.
Hm ?
I thought, new updates will be present on the regular rigol sites…..
You got a new update ? What does the "changes" say ?
Martin
Single file, no 'changelog'
https://www.dropbox.com/s/7xhvif1n0ayrzju/DS5000Update%20prelim.GEL?dl=0 (https://www.dropbox.com/s/7xhvif1n0ayrzju/DS5000Update%20prelim.GEL?dl=0)
Hm ?
I thought, new updates will be present on the regular rigol sites…..
You got a new update ? What does the "changes" say ?
Martin
Single file, no 'changelog'
https://www.dropbox.com/s/7xhvif1n0ayrzju/DS5000Update%20prelim.GEL?dl=0 (https://www.dropbox.com/s/7xhvif1n0ayrzju/DS5000Update%20prelim.GEL?dl=0)
Just a few seconds before, I download the file, transfer it to a usb stick, plug it in the rigol…..
Stick will be recognized but "local upgrade" isn´t avaible…
Martin
Yes, this works and upgrading will be done very quick.
But I can´t see any remarkable changes except the version number.
Maybe the update was only for changing the "root" password
Has someone tried to verify if the "upgrade" enables also the other two channels on the MSO5XX2? ^-^
No they haven’t, but tv84 thinks it won’t. I’m not sure it’s worth saving 90 euros to find out the hard way. Buy the 4 channel model and you get 2 extra 350MHz probes and a warranty that covers all 4 channels.
But it would be interesting to have somebody verify it.
The corrupted data out of the MSO5074 was found to be caused by varying widths of the Low going data bits in the serial data stream.
At 115200 bits/sec, the nominal bit width is 8.68us. Some of the Low going bits from the UART interface were down to 3us width.
The over all packet timing was correct, just the width of the low going bits varied.
So depending on when the receiving equipment clocks the data in, it may see either a "0" or "1"
This was solved by feeding the data through an external Pulse stretching circuit to set the minimum bit width correctly.
could you share this external Pulse stretching circuit ?The second issue of no response to commands was tracked down to an open circuit on the PCB trace from the UART interface connection point.In the video #1146 Dave wasn't able to send commands to it either, but then if you where following along on this thread others have tried the UART interface and where able to use it with no problem and no mention of a missing resistor, and if you let it boot completely you should get a root shell without being asked to login, right?
The Data IN to the MSO5074 goes via a series resistor. This resistor had been left off the circuit board.
Hi all! Long-time reader, first-time poster. When I read the MSO5000 had a trivially-accessible Linux shell, I pulled the trigger and now have a nice MSO5074 on my desk. Thought I would also add something to the hacking community, although it's quite trite.
So, there's an ancient rule on the Internet that whenever something runs Linux and is hacked, it shall be made to run Doom. I noticed that the fine community of MSO5000 hackers has up till now flagrantly disregarded this rule, so I decided to correct that. I present to you: Doom running on a MSO5000 oscilloscope:
https://www.youtube.com/watch?v=m2JOs0Aldq0 (https://www.youtube.com/watch?v=m2JOs0Aldq0)
If you want to try this yourself (or look at the sources), feel free to take a gander in the Github repo (https://github.com/Spritetm/prboom-mso5k/releases/tag/v1.0). It's more-or-less a straight port of prboom, with some hacks in order to support the weird framebuffer hardware the scope has, and to interface with the front panel.
...
So, there's an ancient rule on the Internet that whenever something runs Linux and is hacked, it shall be made to run Doom. I noticed that the fine community of MSO5000 hackers has up till now flagrantly disregarded this rule, so I decided to correct that. I present to you: Doom running on a MSO5000 oscilloscope:
...
What is the actual state of the MSO5000 hack.
What I will get if I buy a MSO 5072 and hack it.
I assume 4 chanelss 350 Mhz and all options, Is that True?
Have any one post only guideline on do the Hack ?
What is the actual state of the MSO5000 hack.
What I will get if I buy a MSO 5072 and hack it.
I assume 4 chanelss 350 Mhz and all options, Is that True?
Have any one post only guideline on do the Hack ?
The option table does not change. However, everything I have tried - works. I.E the AWG buttons prior to the change brought up a screen saying a license was required - and the function did not come up. For me with a 5072 - the same occurred when I selected channel 3 or 4. Now, with the change - all function without any license notification....
FYI...
What is the actual state of the MSO5000 hack.
What I will get if I buy a MSO 5072 and hack it.
I assume 4 chanelss 350 Mhz and all options, Is that True?
Have any one post only guideline on do the Hack ?
Hmpf, it would be nice (and not so irritating) to have "the official touch" too.
So, what else do we need to do to hack this.
Rigol MSO5074 Ordered from Tequipment (U.S.A.) Delivered today. Shipped with build date of 2018-10-15 and firmware 00.01.01.02.03. Called Rigol support and asked for a firmware upgrade. Technician stated that 00.01.01.02.03 is the Current firmware in the USA. Expected new firmware in 30 days. root/root login still worked. >:D FYI
If the -fullopt will be closed with the next update...
Probably digging into it and finding undocumented stuff. E.g. how have they implemented the protocol decoders. As they are done in the screen buffer it likely means others can be added.They are not done in screen buffer. They are decoded mostly in FPGA over whole acquisition buffer.
If the -fullopt will be closed with the next update...
Then it will be interesting again (for a few hours).
New Rigol 5000/7000 series is not missing any significant features. And aside it being new and in need of debugging (which they will eventually do and it will be fine)
Hi all! Long-time reader, first-time poster. When I read the MSO5000 had a trivially-accessible Linux shell, I pulled the trigger and now have a nice MSO5074 on my desk. Thought I would also add something to the hacking community, although it's quite trite.Aww, you took that slice of cheese from my sandwitch :p
So, there's an ancient rule on the Internet that whenever something runs Linux and is hacked, it shall be made to run Doom. I noticed that the fine community of MSO5000 hackers has up till now flagrantly disregarded this rule, so I decided to correct that. I present to you: Doom running on a MSO5000 oscilloscope:
https://www.youtube.com/watch?v=m2JOs0Aldq0 (https://www.youtube.com/watch?v=m2JOs0Aldq0)
If you want to try this yourself (or look at the sources), feel free to take a gander in the Github repo (https://github.com/Spritetm/prboom-mso5k/releases/tag/v1.0). It's more-or-less a straight port of prboom, with some hacks in order to support the weird framebuffer hardware the scope has, and to interface with the front panel.
But you are absolutly right; and it runs doom as it should!
I've mentioned it before but nobody answered: Why does this thing take so long to boot? A whole minute seems ridiculous.I doubt Rigol have enough knowledge of the OS to be able to optimise boot time, or at least were prioritising the scope functionality
a) Is this time typical of this sort of Xilinx/Linux system or just somebody at Rigol being lazy?
b) Could it be improved?
A whole minute seems ridiculous.
I've mentioned it before but nobody answered: Why does this thing take so long to boot? A whole minute seems ridiculous.
a) Is this time typical of this sort of Xilinx/Linux system or just somebody at Rigol being lazy?
b) Could it be improved?
I doubt Rigol have enough knowledge of the OS to be able to optimise boot time, or at least were prioritising the scope functionalitySometimes I wonder if Rigol let the 'hack' leak so that somebody else can improve their scope at no R&D cost.
I doubt Rigol have enough knowledge of the OS to be able to optimise boot time, or at least were prioritising the scope functionalitySometimes I wonder if Rigol let the 'hack' leak so that somebody else can improve their scope at no R&D cost.
The idea of an intended hack or leak is fundamentally stupid. How do you think it is practically implemented? This is a fair size company with directors, top and mid managers, bunch of departments, documentation, legal, development, marketing, etc. I imagine the board of directors in a meeting and Mr.Woo saying why don't we create a hack or leak. You Mr. Boo take care of communicating the hackable instrument strategy to the engineering department and make sure every engineer follows it. You Mr. Noo make sure proper documentation gets build on the hack feature. You Mr. Doo get your sockpuppet team deployed to the major electronics forums to strategically leak information according to the plan Mr.Zoo will create. And make goddamn sure our hole dont accidentally become patched with the next firmware update. You Mr.Foo is responsible for regression testing to make sure this is not happen.I doubt Rigol have enough knowledge of the OS to be able to optimise boot time, or at least were prioritising the scope functionalitySometimes I wonder if Rigol let the 'hack' leak so that somebody else can improve their scope at no R&D cost.
TEquipment now has over 80 MSO5074 units on order. We are working our best to fulfill orders on a first come, first serve basis. We would suggest placing your pre-order now to get in line, as they will be shipped on a first come, first serve basis.
We currently have the following models in stock if anyone wants something more immediate, please see here: https://www.screencast.com/t/huJDkWJKtIk (https://www.screencast.com/t/huJDkWJKtIk)
If we can help to answer any more detailed questions, please do not hesitate to contact us: salesteam@tequipment.net or direct by phone: 1-877-571-7901
Thank you for all of your patronage and support,
The TEquipment Team
Asking the question would satiate our curiosity (if we ever get a response from Rigol) but it may lead them to think that it's not just a bunch of geeks in their garage hacking their scopes anymore...TEquipment now has over 80 MSO5074 units on order. We are working our best to fulfill orders on a first come, first serve basis. We would suggest placing your pre-order now to get in line, as they will be shipped on a first come, first serve basis.
We currently have the following models in stock if anyone wants something more immediate, please see here: https://www.screencast.com/t/huJDkWJKtIk (https://www.screencast.com/t/huJDkWJKtIk)
If we can help to answer any more detailed questions, please do not hesitate to contact us: salesteam@tequipment.net or direct by phone: 1-877-571-7901
Thank you for all of your patronage and support,
The TEquipment Team
Guessing the 5074 is outselling the other models. TEquipment could you tell us if Rigol accidently left their devices very insecure or was it deliberate?
Guessing the 5074 is outselling the other models. TEquipment could you tell us if Rigol accidently left their devices very insecure or was it deliberate?
If you just take Linux distro and load it to a scope (like they did) it will not be secure.
So it's not that they are stupid, they are not, and being a rather big company by now, they could have hired ANY security consultant for anywhere in the world if they didn't have a staff on board.
Securing things is expensive and not only once, but whole platform needs to be maintained in different workflow once you go that route.
Also they know that even top notch protection is breakable once there is enough will to spend time on it.
Securing Linux isn't difficult. If it was then half the web servers in the world would be hacked.
Securing Linux isn't difficult. If it was then half the web servers in the world would be hacked.Securing Linux (or anything) against physical access to the machine is HARD - to the point of being damn near impossible.
They don't have to make it 100% secure, they just have to make it so you have to at least open it up and solder JTAG wires to the PCB to reprogram it (or whatever). That would reduce hacking massively and could probably be done with a couple of morning's work.
Fungus, this is also not a definitive solution.
After the hack being discovered with a JTAG access, etc, etc, a patch could be done so that people can easily install it without requiring JTAG accesses, or a keygen ;) could be generated and there goes the neighborhood...
Once you have the capability to install FW updates and the FW is decompiled/decrypted it's extremely difficult to make it secure.
Fungus, this is also not a definitive solution.
After the hack being discovered with a JTAG access, etc, etc, a patch could be done so that people can easily install it without requiring JTAG accesses, or a keygen ;) could be generated and there goes the neighborhood...
Once you have the capability to install FW updates and the FW is decompiled/decrypted it's extremely difficult to make it secure.
They could start shipping them with a firmware that will only install signed firmware updates. That would prevent users from simply loading a modified firmware (at least for the first time).
I’m tempted to say that if Rigol employed you as their security expert they would end up with a product just as exposed as the one they are already shipping...
Maybe you could point out the errors?
How would a signed-firmware-only requirement fail to prevent users from loading modified firmware?
I can imagine getting everything so locked up that it's impossible to get persistent-root may require more engineering power than is wise to spend on Rigols side.
If I might make an observation - short of Rigol jumping on this forum and explaining exactly what their stance is w/r/t hacking their products, everything else is just idle speculation and contributes essentially nothing to the larger effort. Everyone has an opinion, but none of it matters in the end. They're going to do what they're going to do in future releases and our guesses about the rationale won't better prepare us to deal with new approaches for firmware mods when new firmware releases land.
The S:N here is getting pretty deep into the noise end of the spectrum and the issue will never be definitively answered without Rigol telling us directly, so can we maybe just put the issue to rest and get on with hacking the scope?
"Your opponent"? are you serious??If I might make an observation - short of Rigol jumping on this forum and explaining exactly what their stance is w/r/t hacking their products, everything else is just idle speculation and contributes essentially nothing to the larger effort. Everyone has an opinion, but none of it matters in the end. They're going to do what they're going to do in future releases and our guesses about the rationale won't better prepare us to deal with new approaches for firmware mods when new firmware releases land.
The S:N here is getting pretty deep into the noise end of the spectrum and the issue will never be definitively answered without Rigol telling us directly, so can we maybe just put the issue to rest and get on with hacking the scope?
Actually i think the opposite. Understanding the rationale behind why they have taken a particular approach is critial to being able to keep ahead of them. Knowing how your opponent thinks and behaves is critical in a war. 90%+ of 'hacking' is possible becuase Humans have taken a particular course of action.
Rigol is actually on *our* side by not putting the effort into securing their scopes (and yes it is INTENTIONAL, whether it is by lack of care, or to voluntary help the community. We will never know for sure, but it makes no difference anyway).
"Your opponent"? are you serious??
Knowing how your opponent thinks and behaves is critical in a war.
I’m tempted to say that if Rigol employed you as their security expert they would end up with a product just as exposed as the one they are already shipping...
Maybe you could point out the errors?
How would a signed-firmware-only requirement fail to prevent users from loading modified firmware?
Maybe you could point out the errors?
How would a signed-firmware-only requirement fail to prevent users from loading modified firmware?
To be fair, in theory root-of-trust and signed firmware should indeed stop all software-based attacks from happening when implemented 100% correctly, so you're right there. On the other hand, in practice it never seems to be implemented 100% well: there's data loaded from unsecured sources (e.g. the user partition) using insecure parsers, network connectivity is implemented badly, there's a bug in partition checking code, you name it. I'll not go into the personal-attack-y bits of the conversation between you two, but I can imagine getting everything so locked up that it's impossible to get persistent-root may require more engineering power than is wise to spend on Rigols side.
If the Microsoft budget couldn't prevent the XBox being hacked...
Guessing the 5074 is outselling the other models. TEquipment could you tell us if Rigol accidently left their devices very insecure or was it deliberate?
What do you want? A definitive statement from the head of Rigol? :-//
Can someone please offer some inputs on a concern, I am really interested in this scope but only with the 'workaround' in place.
If a current MSO5000 scope can be made full featured by logging in with a given username/password (i.e. this hack), will it always be the case even if I'd want to update the firmware in the future?
>>The concern here would be not having access to future bug fixes or feature improvements without unhinging the full feature workaround if this hack is patched in later firmware updates.
Can someone please offer some inputs on a concern, I am really interested in this scope but only with the 'workaround' in place.
If a current MSO5000 scope can be made full featured by logging in with a given username/password (i.e. this hack), will it always be the case even if I'd want to update the firmware in the future?
>>The concern here would be not having access to future bug fixes or feature improvements without unhinging the full feature workaround if this hack is patched in later firmware updates.
Can someone please offer some inputs on a concern, I am really interested in this scope but only with the 'workaround' in place.
If a current MSO5000 scope can be made full featured by logging in with a given username/password (i.e. this hack), will it always be the case even if I'd want to update the firmware in the future?
99.999% yes. "Hacability" is a Rigol sales technique and has been for many years. They've never made the slightest effort to prevent it..
If you are worried, about an update, just dont' update it untill the collective borg has dealt to it. Seriously its only goign to be a matter of a few days at worse.So true. I was feeling a little rushed to buy a potentially buggy (manufacturing maturity, hardware and software) product that I believe was released only two months ago. I think now I'll be waiting on this purchase to see how it's hackability evolves over time. 'The Donktor' just commented that they stopped a hack on a spectrum analyzer a while back, so I may be taking a gamble waiting.
I am a little concerned that Rigol are displeased with all the goings on as they attempted a fix by updating the password recently.The firmware with the new password is rather old and has been released before the hacking started. But I agree that there is no 100% guarantee that future firmwares will be hackable. The current ETA for the next release is sometime this month.
The firmware with the new password is rather old and has been released before the hacking started. But I agree that there is no 100% guarantee that future firmwares will be hackable. The current ETA for the next release is sometime this month.
They stopped the hack on 1 of their spectrum analyzers a while back.
Rigol are displeased with all the goings on as they attempted a fix by updating the password recently.
The DSA815The firmware with the new password is rather old and has been released before the hacking started. But I agree that there is no 100% guarantee that future firmwares will be hackable. The current ETA for the next release is sometime this month.
For this model, will be hackable. Confidence greater than "six nines".They stopped the hack on 1 of their spectrum analyzers a while back.
They did? Which one?
They did? Which one?The DSA815
All sound points that contradict my knee jerk assumptions. The MSO5000 series has that hobbyist feel to it; support for only passive probes, no 50ohm termination, all in one functionality, 0.1 inch spacing header digital signal access and hardware changes to reduce cost (ex. crapped-on capacitors...). I suspect that sales for their top end versions of this series will stagnate in industry as the pricing just isn't competitive, but provided the workarounds remain, the low-end versions of the scopes are going to be flying off the shelves. Rigol is going to foster brand recognition in a new generation of soon to be professionals, so staying the course makes sound business sense. Regarding point C, the MSO5000 is at the top of the list by a long shot, I've wanted a scope like this for many years.Rigol are displeased with all the goings on as they attempted a fix by updating the password recently.
a) You don't know why they did that.
It might simply have been to protect against all the botnets out there that are busy sending "root"/"root" to every single IP address on the internet.
It would have been just as easy (and much more sensible from a security point of view) for them to disable shell access altogether.
All you do is change one line in a text file and no more shell access. Google it.
b) What are the chances of somebody at Rigol thinking, "You know, we're selling too many of these oscilloscopes to hackers. I think we should give our friends at Siglent a chance to sell to them instead..."
and,
C) What else are you going to buy for $1000? Have you made a list? How long is it, and how do the devices on it compare to a hacked MSO5000?
People are unhappy that they can buy scope for very little money (compared to what it used to be) that can be hacked to full specs.
Option bundle for RTB2000 costs € 1,190.- net (no VAT).
You can buy MSO5074 + Logic probe for that money and unlock all features.
.
Option bundle for RTB2000 costs € 1,190.- net (no VAT).
Option bundle for RTB2000 costs € 1,190.- net (no VAT).
You can buy MSO5074 + Logic probe for that money and unlock all features.
.
Quote
Option bundle for RTB2000 costs € 1,190.- net (no VAT).
You can buy MSO5074 + Logic probe for that money and unlock all features.
.
Hi, see above...
If people are taking them apart then another thing to look for the manufacturer/model of the screen.
Some people are complaining it's too dark, it would be good to find out if it's being under-driven or not and how the brightness is controlled. Maybe it's possible to make it brighter by swapping a resistor or something like that.
If people are taking them apart then another thing to look for the manufacturer/model of the screen.
Some people are complaining it's too dark, it would be good to find out if it's being under-driven or not and how the brightness is controlled. Maybe it's possible to make it brighter by swapping a resistor or something like that.
Rigol chipset consists of 3 chips:Thanks, but that's mostly the marketing speak :)
"the Analog Front End Chip (named Beta Phoenicis) will allow for front end bandwidth of 4GHz with highly integrated capability allowing for simplified and highly reliable front end design.
The Signal Processing Chip (named Ankaa) supports 10GSa/s sampling with bandwidth up to 6GHz.
Also there is the Probe Amplifier Chip (named Gamma Phoenicis) will support a 6GHz Active Differential probe. "
for 5000:
The core of RIGOL's UltraVision II architecture is its Phoenix chip-set. Two custom ASICs provide analog front end and signal processing performance. These chips are surrounded by a high performance hardware design including Xilinx Zync-7000 SoC, Dual Core ARM-9 Processors, a Linux +Qt Operating System, High Speed DDR System Memory and QDRII Display memory.
Signal Processing Chip (named Ankaa) is A/D and first level of DSP. It connects to FPGA that has Ultravision II architecture implemented in it.
Unlike Keysight, they separated first level A/D and waveform engine. That approach is more modular, and is more flexible and makes it easy to modify and grow. That is also how it is easy for them to add huge memory and such.
They will also have a handful of smaller support chips..
I wonder if we could find an OLED that's the right size >: )
The TOP BIG heatsinked chip is very likely a Kintex-7; Not something rigol designed. Unless they put an FPGA in there of course.
The kintex7 packaging documentation shows something that looks very much like the photos I posted earlier...
Missing is indeed, the 4x analog frontends; so that would map to Beta Phoenicis chip?Yes.
We then have the first BOTTOM BIG heatsinked chip. This is the ADC. So what's that, is that anka? Is that a standard ADC?No, it is not standard A/D. It is Rigol designed ADC with first level of signal processing that is tailored for scopes, as opposed to general purpose ADC.
I've attached pictures of what is visible from the side of the 2 big heatsinks. That adhesive is really strong, there's no way I'm going to risk trying to break those heatsinks off...Haha, you've done more then enough already!! :) But if someone gets his hands on a broken one ... send it to TopLoser, I'm sure he'll <dave voice> take it apart</dave voice> and take nice PCB X-rays :D
The kintex7 packaging documentation shows something that looks very much like the photos I posted earlier...I should have looked at that (and at the picture before)... busy mind busy mind :(
Missing is indeed, the 4x analog frontends; so that would map to Beta Phoenicis chip?Yes.We then have the first BOTTOM BIG heatsinked chip. This is the ADC. So what's that, is that anka? Is that a standard ADC?No, it is not standard A/D. It is Rigol designed ADC with first level of signal processing that is tailored for scopes, as opposed to general purpose ADC.
Rest of chips are different from DS7000 which revolves arround Zync-7000
No, One Kyntex-7, One artix-7 (in the Zynq-7015), one spartan 6 and one tiny Asic for the keyboard.The kintex7 packaging documentation shows something that looks very much like the photos I posted earlier...
So, 2 kyntex?
The kintex 7 K160 seems to have different neighborhood than what is shown in Toploser's pictures.That's the one, looks identical just 90-ish degree's rotated.
zlib @002c:
00000000: 0000 0000 0001 0000 0000 001e 0000 0024 ...............$
00000010: 0b00 0000 5200 4900 4700 4f00 4c00 2000 ....R.I.G.O.L. .
00000020: 5300 6300 6f00 7000 6500 241a 0000 003a S.c.o.p.e.$....:
00000030: 002f 0070 0069 0063 0074 0075 0072 0065 ./.p.i.c.t.u.r.e
00000040: 0073 002f 0075 0074 0069 006c 0069 0074 .s./.u.t.i.l.i.t
00000050: 0079 002f 0073 0063 0072 002e 006a 0070 .y./.s.c.r...j.p
00000060: 0067 0001 0000 00 .g.....
zlib @00a8:
00000000: 00a0 8601 0000 0000 0000 0000 0000 0100 ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0003 ................
00000020: 0000 0024 0300 0000 4300 4800 3400 0006 ...$....C.H.4...
00000030: 0000 0000 0000 0000 0000 00 ...........
zlib @00e4:
00000000: 00a0 8601 0000 0000 0000 0000 0000 0100 ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0003 ................
00000020: 0000 0024 0300 0000 4300 4800 3300 0006 ...$....C.H.3...
00000030: 0000 0000 0000 0000 0000 00 ...........
zlib @0120:
00000000: 0140 420f 0040 2bfe ff00 0000 0000 0100 .@B..@+.........
00000010: 0000 0000 0000 0000 0000 0000 0000 0003 ................
00000020: 0000 0024 0300 0000 4300 4800 3200 0006 ...$....C.H.2...
00000030: 0000 0000 0000 0000 0000 00 ...........
zlib @015c:
00000000: 0088 1300 00d8 2700 0000 0000 0000 0100 ......'.........
00000010: 0000 0000 0000 0000 0000 0000 0000 0003 ................
00000020: 0000 0024 0300 0000 4300 4800 3100 0006 ...$....C.H.1...
00000030: 0000 0000 0000 0000 0000 0000 0000 00 ...............
zlib @0198:
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000010: 0000 0000 00f0 ff1f 0000 0000 0001 0000 ................
00000020: 00c0 5c15 00c0 5c15 0001 0000 0000 0000 ..\...\.........
00000030: 0000 0005 0000 0000 0000 0024 0200 0000 ...........$....
00000040: 4400 3000 0100 0000 2402 0000 0044 0031 D.0.....$....D.1
00000050: 0002 0000 0024 0200 0000 4400 3200 0300 .....$....D.2...
00000060: 0000 2402 0000 0044 0033 0004 0000 0024 ..$....D.3.....$
00000070: 0200 0000 4400 3400 0500 0000 2402 0000 ....D.4.....$...
00000080: 0044 0035 0006 0000 0024 0200 0000 4400 .D.5.....$....D.
00000090: 3600 0700 0000 2402 0000 0044 0037 0008 6.....$....D.7..
000000a0: 0000 0024 0200 0000 4400 3800 0900 0000 ...$....D.8.....
000000b0: 2402 0000 0044 0039 000a 0000 0024 0300 $....D.9.....$..
000000c0: 0000 4400 3100 3000 0b00 0000 2403 0000 ..D.1.0.....$...
000000d0: 0044 0031 0031 000c 0000 0024 0300 0000 .D.1.1.....$....
000000e0: 4400 3100 3200 0d00 0000 2403 0000 0044 D.1.2.....$....D
000000f0: 0031 0033 000e 0000 0024 0300 0000 4400 .1.3.....$....D.
00000100: 3100 3400 0f00 0000 2403 0000 0044 0031 1.4.....$....D.1
00000110: 0035 0000 0000 0001 0000 0002 0000 00 .5.............
zlib @0270:
00000000: 0800 0000 8013 8119 0000 0000 2403 0000 ............$...
00000010: 0041 0044 0044 0000 0202 0202 0270 a28d .A.D.D.......p..
00000020: 0a00 0000 0000 1827 fa04 0000 0000 e40b .......'........
00000030: 5402 0000 0000 0000 0000 0000 0000 10a5 T...............
00000040: d4e8 0000 0000 d098 d4af 7100 0000 a031 ..........q....1
00000050: a95f e300 0000 0057 d347 0100 0000 00d2 ._.....W.G......
00000060: 496b 0000 0000 0005 0000 0000 0000 0005 Ik..............
00000070: 0000 0001 0102 0101 0000 0000 0000 0000 ................
00000080: 0000 0000 0103 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 ..............
zlib @02ec:
00000000: 0000 0000 0000 0000 0000 0000 2403 0000 ............$...
00000010: 0041 0044 0044 0000 0202 0202 0200 65cd .A.D.D........e.
00000020: 1d00 0000 0000 9435 7700 0000 0000 e40b .......5w.......
00000030: 5402 0000 0000 0000 0000 0000 0000 10a5 T...............
00000040: d4e8 0000 0000 5039 278c 0400 0000 a072 ......P9'......r
00000050: 4e18 0900 0000 0057 d347 0100 0000 00d2 N......W.G......
00000060: 496b 0000 0000 0005 0000 0000 0000 0005 Ik..............
00000070: 0000 0001 0102 0101 0000 0000 0000 0000 ................
00000080: 0000 0000 0103 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 ..............
zlib @0358:
00000000: 0000 0000 0000 0000 0000 0000 2403 0000 ............$...
00000010: 0041 0044 0044 0000 0202 0202 0200 65cd .A.D.D........e.
00000020: 1d00 0000 0000 9435 7700 0000 0000 e40b .......5w.......
00000030: 5402 0000 0000 0000 0000 0000 0000 10a5 T...............
00000040: d4e8 0000 0000 5039 278c 0400 0000 a072 ......P9'......r
00000050: 4e18 0900 0000 0057 d347 0100 0000 00d2 N......W.G......
00000060: 496b 0000 0000 0005 0000 0000 0000 0005 Ik..............
00000070: 0000 0001 0102 0101 0000 0000 0000 0000 ................
00000080: 0000 0000 0103 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 ..............
zlib @03c4:
00000000: 0000 0000 0000 0000 0000 0000 2403 0000 ............$...
00000010: 0041 0044 0044 0000 0202 0202 0200 65cd .A.D.D........e.
00000020: 1d00 0000 0000 9435 7700 0000 0000 e40b .......5w.......
00000030: 5402 0000 0000 0000 0000 0000 0000 10a5 T...............
00000040: d4e8 0000 0000 5039 278c 0400 0000 a072 ......P9'......r
00000050: 4e18 0900 0000 0057 d347 0100 0000 00d2 N......W.G......
00000060: 496b 0000 0000 0005 0000 0000 0000 0005 Ik..............
00000070: 0000 0001 0102 0101 0000 0000 0000 0000 ................
00000080: 0000 0000 0103 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 ..............
zlib @049c:
00000000: 0000 0000 0000 0000 0000 0004 0000 0024 ...............$
00000010: 0400 0000 5200 4500 4600 3100 0000 0000 ....R.E.F.1.....
00000020: 0300 0000 2404 0000 0052 0045 0046 0032 ....$....R.E.F.2
00000030: 0000 0000 0002 0000 0024 0400 0000 5200 .........$....R.
00000040: 4500 4600 3300 0000 0000 0100 0000 2404 E.F.3.........$.
00000050: 0000 0052 0045 0046 0034 0000 0000 0000 ...R.E.F.4......
00000060: 0000 0024 0400 0000 5200 4500 4600 3500 ...$....R.E.F.5.
00000070: 0000 0000 0400 0000 2404 0000 0052 0045 ........$....R.E
00000080: 0046 0036 0000 0000 0003 0000 0024 0400 .F.6.........$..
00000090: 0000 5200 4500 4600 3700 0000 0000 0200 ..R.E.F.7.......
000000a0: 0000 2404 0000 0052 0045 0046 0038 0000 ..$....R.E.F.8..
000000b0: 0000 0001 0000 0024 0400 0000 5200 4500 .......$....R.E.
000000c0: 4600 3900 0000 0000 0000 0000 2405 0000 F.9.........$...
000000d0: 0052 0045 0046 0031 0030 00 .R.E.F.1.0.
zlib @0bf1:
00000000: 240c 0000 0031 0039 0032 002e 0031 0036 $....1.9.2...1.6
00000010: 0038 002e 0031 002e 0031 0030 0024 0d00 .8...1...1.0.$..
00000020: 0000 3200 3500 3500 2e00 3200 3500 3500 ..2.5.5...2.5.5.
00000030: 2e00 3200 3500 3500 2e00 3000 240b 0000 ..2.5.5...0.$...
00000040: 0031 0039 0032 002e 0031 0036 0038 002e .1.9.2...1.6.8..
00000050: 0031 002e 0031 0024 0b00 0000 3100 3900 .1...1.$....1.9.
00000060: 3200 2e00 3100 3600 3800 2e00 3100 2e00 2...1.6.8...1...
00000070: 3100 0300 0000 1.....
zlib @0c5d:
00000000: 240e 0000 006d 0061 0069 006c 002e 0072 $....m.a.i.l...r
00000010: 0069 0067 006f 006c 002e 0063 006f 006d .i.g.o.l...c.o.m
00000020: 0019 0000 0024 1200 0000 7200 6900 6700 .....$....r.i.g.
00000030: 6f00 6c00 5f00 6400 7300 4000 7200 6900 o.l._.d.s.@.r.i.
00000040: 6700 6f00 6c00 2e00 6300 6f00 6d00 2409 g.o.l...c.o.m.$.
00000050: 0000 0052 0069 0067 006f 006c 0030 0036 ...R.i.g.o.l.0.6
00000060: 0031 0034 0024 1200 0000 7200 6900 6700 .1.4.$....r.i.g.
00000070: 6f00 6c00 6d00 6100 6900 6c00 4000 7300 o.l.m.a.i.l.@.s.
00000080: 6900 6e00 6100 2e00 6300 6f00 6d00 0000 i.n.a...c.o.m...
00000090: 0000 2400 0000 00 ..$....
Has anybody figured or worked around the new mso5k wfm file format?
so far,
A short header followed by 53 fairly short zflated blocks, separated by varying junk.
Then a huge blank of around ~5,000,000 x'00s
Then an assortment of ~17,000,000 x'c7 or x'c8 or x'c9 (with some interludes). Maybe data per chan.
LED backlight voltage is a standard 3 x 3.3v LED string so 9.9v - it's not modulated in any way.
Datasheets seem to indicate 10.2v max is allowed (with reduced life) but it's already plenty bright enough for me anyway.
Whatever ... if datasheet says 10.2V and it's measured as 9.9V then there's not much room for boosting it. People will have to look elsewhere for an upgrade.
CONFIRMATION
Hey Guys! Thx a million times you crafty geniuses!! ;D :-+ :-+ :-+
Type: MSO5074
Firmware: 00.01.01.02.04
Successful SSH Login via Putty:
USR: root
PWD: Rigol201
I followed the instructions from @TopLoser:
##################################
Download and install PuTTY on your PC
On your scope find its IP address by UTILITY, IO, LAN
Run PuTTY and connect using that IP address and SSH with port 22
Login as ‘root’ password ‘root’
Enter ‘cd /rigol/shell’
Enter ‘vi start.sh’
Change line 82 to read:
‘/rigol/appEntry $PowerOn -run -fullopt &’
Google vi commands to find out how to insert text into the file
Basically press ‘i’ to enter edit mode then move cursor, insert text and then ESC to exit edit mode.
Save the file and quit ‘:wq’
Reboot.
##################################
Rock on guys! Great work!
I think we're all still waiting for the backordered scopes to arrive :D
I received an MSO5074 in mid February. Another larger shipment into North America is expected at the end of February.
I received an MSO5074 in mid February. Another larger shipment into North America is expected at the end of February.
Can you check and confirm if you have a perfectly aligned compensation square wave or get similar as discussed here please ?
https://www.eevblog.com/forum/blog/new-rigol-scope/msg2215035/#msg2215035 (https://www.eevblog.com/forum/blog/new-rigol-scope/msg2215035/#msg2215035)
The question is, do the Rigol PVP2350 probes meet their intended specs.
The question is, do the Rigol PVP2350 probes meet their intended specs.
What's the result if the probes are set at 1x? On my 'scope the signal has the same overshoot as with 10x compensated. Both times getting signal from the 1kHz compensation generator.
A new Firmware is now available for MSO5000!
http://int.rigol.com/File/ProductSoftWare/20190227/DS5000(ARM)Update.rar (http://int.rigol.com/File/ProductSoftWare/20190227/DS5000(ARM)Update.rar)
modified: firmware/fw4linux.sh
modified: firmware/fw4uboot.sh
modified: firmware/rootfs/rigol/K160M_TOP.bit
modified: firmware/rootfs/rigol/appEntry
modified: firmware/rootfs/rigol/default/cal.hex
modified: firmware/rootfs/rigol/resource/appmeta.xml
modified: firmware/rootfs/rigol/resource/boardmeta.xml
modified: firmware/rootfs/rigol/resource/dsometa.xml
modified: firmware/rootfs/rigol/resource/help/b/chan1.hlp
modified: firmware/rootfs/rigol/resource/help/b/eyejit.hlp
modified: firmware/rootfs/rigol/resource/help/b/help.hlp
modified: firmware/rootfs/rigol/resource/help/b/histogram.hlp
modified: firmware/rootfs/rigol/resource/help/b/horizontal.hlp
modified: firmware/rootfs/rigol/resource/help/d/chan1.hlp
modified: firmware/rootfs/rigol/resource/help/d/eyejit.hlp
modified: firmware/rootfs/rigol/resource/help/d/help.hlp
modified: firmware/rootfs/rigol/resource/help/d/histogram.hlp
modified: firmware/rootfs/rigol/resource/help/d/horizontal.hlp
modified: firmware/rootfs/rigol/resource/menu/b.hex
modified: firmware/rootfs/rigol/resource/menu/c.hex
modified: firmware/rootfs/rigol/resource/menu/d.hex
modified: firmware/rootfs/rigol/resource/menu/desc.hex
modified: firmware/rootfs/rigol/resource/menu/h.hex
modified: firmware/rootfs/rigol/resource/menu/i.hex
modified: firmware/rootfs/rigol/resource/menu/j.hex
modified: firmware/rootfs/rigol/resource/menu/k.hex
modified: firmware/rootfs/rigol/resource/menu/l.hex
modified: firmware/rootfs/rigol/resource/menu/m.hex
modified: firmware/rootfs/rigol/resource/menu/menu.hex
modified: firmware/rootfs/rigol/resource/menu/modelconfig_ch.hex
modified: firmware/rootfs/rigol/resource/menu/modelconfig_ext.hex
modified: firmware/rootfs/rigol/resource/menu/msg.h
modified: firmware/rootfs/rigol/resource/menu/n.hex
modified: firmware/rootfs/rigol/resource/menu/o.hex
modified: firmware/rootfs/rigol/resource/menu/pic.hex
modified: firmware/rootfs/rigol/resource/menu/res.hex
modified: firmware/rootfs/rigol/resource/menu/t.hex
modified: firmware/rootfs/rigol/resource/menu/u.hex
modified: firmware/rootfs/rigol/resource/res.qrc
modified: firmware/rootfs/rigol/resource/scpi/CALibration.xml
modified: firmware/rootfs/rigol/resource/scpi/CHANnel1.xml
modified: firmware/rootfs/rigol/resource/scpi/DISPlay.xml
modified: firmware/rootfs/rigol/resource/scpi/HISTogram.xml
modified: firmware/rootfs/rigol/resource/scpi/MASK.xml
modified: firmware/rootfs/rigol/resource/scpi/MEASure.xml
modified: firmware/rootfs/rigol/resource/scpi/SYSTem.xml
modified: firmware/rootfs/rigol/resource/scpi/WAVeform.xml
modified: firmware/rootfs/rigol/shell/start.sh
modified: firmware/rootfs/rigol/webcontrol/webpages/PrintScreen.html
modified: firmware/zImage
modified: firmware/zynq.bit
Only a .GEL file, no release notes.
Uboot access might prove impossible over the serial interface and SSH access probably won’t work anymore.
softver=00.01.01.04.04You skipped one: new file: rootfs/rigol/webcontrol/webpages/remote.html
builddate="2019-02-20 16:27:49"Code: [Select]modified: firmware/fw4linux.sh
modified: firmware/fw4uboot.sh
modified: firmware/rootfs/rigol/K160M_TOP.bit
modified: firmware/rootfs/rigol/appEntry
modified: firmware/rootfs/rigol/default/cal.hex
modified: firmware/rootfs/rigol/resource/appmeta.xml
modified: firmware/rootfs/rigol/resource/boardmeta.xml
modified: firmware/rootfs/rigol/resource/dsometa.xml
modified: firmware/rootfs/rigol/resource/help/b/chan1.hlp
modified: firmware/rootfs/rigol/resource/help/b/eyejit.hlp
modified: firmware/rootfs/rigol/resource/help/b/help.hlp
modified: firmware/rootfs/rigol/resource/help/b/histogram.hlp
modified: firmware/rootfs/rigol/resource/help/b/horizontal.hlp
modified: firmware/rootfs/rigol/resource/help/d/chan1.hlp
modified: firmware/rootfs/rigol/resource/help/d/eyejit.hlp
modified: firmware/rootfs/rigol/resource/help/d/help.hlp
modified: firmware/rootfs/rigol/resource/help/d/histogram.hlp
modified: firmware/rootfs/rigol/resource/help/d/horizontal.hlp
modified: firmware/rootfs/rigol/resource/menu/b.hex
modified: firmware/rootfs/rigol/resource/menu/c.hex
modified: firmware/rootfs/rigol/resource/menu/d.hex
modified: firmware/rootfs/rigol/resource/menu/desc.hex
modified: firmware/rootfs/rigol/resource/menu/h.hex
modified: firmware/rootfs/rigol/resource/menu/i.hex
modified: firmware/rootfs/rigol/resource/menu/j.hex
modified: firmware/rootfs/rigol/resource/menu/k.hex
modified: firmware/rootfs/rigol/resource/menu/l.hex
modified: firmware/rootfs/rigol/resource/menu/m.hex
modified: firmware/rootfs/rigol/resource/menu/menu.hex
modified: firmware/rootfs/rigol/resource/menu/modelconfig_ch.hex
modified: firmware/rootfs/rigol/resource/menu/modelconfig_ext.hex
modified: firmware/rootfs/rigol/resource/menu/msg.h
modified: firmware/rootfs/rigol/resource/menu/n.hex
modified: firmware/rootfs/rigol/resource/menu/o.hex
modified: firmware/rootfs/rigol/resource/menu/pic.hex
modified: firmware/rootfs/rigol/resource/menu/res.hex
modified: firmware/rootfs/rigol/resource/menu/t.hex
modified: firmware/rootfs/rigol/resource/menu/u.hex
modified: firmware/rootfs/rigol/resource/res.qrc
modified: firmware/rootfs/rigol/resource/scpi/CALibration.xml
modified: firmware/rootfs/rigol/resource/scpi/CHANnel1.xml
modified: firmware/rootfs/rigol/resource/scpi/DISPlay.xml
modified: firmware/rootfs/rigol/resource/scpi/HISTogram.xml
modified: firmware/rootfs/rigol/resource/scpi/MASK.xml
modified: firmware/rootfs/rigol/resource/scpi/MEASure.xml
modified: firmware/rootfs/rigol/resource/scpi/SYSTem.xml
modified: firmware/rootfs/rigol/resource/scpi/WAVeform.xml
modified: firmware/rootfs/rigol/shell/start.sh
modified: firmware/rootfs/rigol/webcontrol/webpages/PrintScreen.html
modified: firmware/zImage
modified: firmware/zynq.bit
no release notes.
EDIT: fullopt cannot be found in latest appEntry[/size]It means hack was disabled?
SSH does not work anymore, so no hack on this path.
ssh -p Rigol201 root@host "nohup /usr/bin/sshd -p 22"
Does it mean now that you have a real 12-bit oscilloscope, and that it beats the R&S RTB series 10-bit oscilloscope?
the firmware ZIP file contains a physical 12-bit ADC
the firmware ZIP file contains a physical 12-bit ADC
Please explain what you mean by this.
the firmware ZIP file contains a physical 12-bit ADCPlease explain what you mean by this.
Its likely just enhanced resolution mode by adding samples, Add up 16x 8 bit values, and you can get a not very reliable 12 bit value. You will likely find the sample rate it cut down by an equivalent amount.
sorry translate error
this is the line from the file
/rigol/appEntry $PowerOn -run -fullopt&
is ther not at factor default switch ?? or key combination
thanks sounds like a good idea but where can i download it ??
I can't find the hosa rigol.
does anyone know where it is?
A new Firmware is now available for MSO5000!Release notes for FW v00.01.01.04.04:
http://int.rigol.com/File/ProductSoftWare/20190227/DS5000(ARM)Update.rar (http://int.rigol.com/File/ProductSoftWare/20190227/DS5000(ARM)Update.rar)
Just don't forget to rename Update file to the following: "DS5000Update.GEL"
yes i dit just what DS5000Update.GEL
but nothing happens :-(
nmap -sn 169.254.0.0/16
Release notes for FW v00.01.01.04.04:
[Latest Revision Date] 2019/02/27
[Updated Contents]
So whats the conclusion? Seems that new firmware can't be hacked? :)
So whats the conclusion? Seems that new firmware can't be hacked? :)
With the right timing, something likeCode: [Select]ssh -p Rigol201 root@host "nohup /usr/bin/sshd -p 22"
Should give you ssh on port 22 >:D Haven't tried it though.
Looking at the disassambled appEntry file, it looks to me like it's only able to start a ssh and ftp daemon, but not to stop any of them.
diff --git a/firmware/rootfs/etc/init.d/rcS b/firmware/rootfs/etc/init.d/rcS
index f3559f1..a8f3117 100755
--- a/firmware/rootfs/etc/init.d/rcS
+++ b/firmware/rootfs/etc/init.d/rcS
@@ -30,10 +30,10 @@ mount -t devpts devpts /dev/pts
#httpd -h /var/www
#echo "++ Starting ftp daemon"
-tcpsvd 0:21 ftpd ftpd -w /&
+#tcpsvd 0:21 ftpd ftpd -w /&
#echo "++ Starting ssh daemon"
-/usr/sbin/sshd
+#/usr/sbin/sshd
echo "rcS Complete"
Good news is that it looks like the "-fullopt" checking instructions can easily be merged into the new appEntry version.
This is my first post btw, so a big hello to everybody here!Welcome! May I ask what tools you use for disassembly?
I'm not sure how to start it though. The start command is close to other UI stuff, and the string "Enter Project mode" is used close to it. I could imagine there is something like a maintanance menu we don't know about yet.
#define MSG_HISTO_STATISEN 17670
<TotalItem>
<head>^(:?HISTogram|:?HIST)(:STATic|:STAT)\?$</head>
<service>histo</service>
<cmd>17670</cmd>
<minSize>-1</minSize>
<indexes>
<i>1</i>
</indexes>
<unit>
</unit>
</TotalItem>
#define MSG_APP_UTILITY_PROJECT 12073
which is unfortunately not mapped, but might be somewhere in appEntry.
I believe you are right. I did not notice earlier, but rootfs/etc/init.d/rcS was modified such that sshd is not run.Code: [Select]-/usr/sbin/sshd
+#/usr/sbin/sshd
Welcome! May I ask what tools you use for disassembly?Thank you! I'm using Binary Ninja right now.
I believe the license checking function is at 0x0041801c. It seems to set r0 to #0x1 if the user owns the requested license.
At least that's what the -fullopt flag did in the previous versions.
I would guess so. Still waiting for the scope to be delivered. You can also use oliv3r's packer I think: https://gitlab.com/riglol/rigolee/#gel-packer
But I'm not sure if this is tested at all.
Thank you! I'm using Binary Ninja right now.
I believe the license checking function is at 0x0041801c. It seems to set r0 to #0x1 if the user owns the requested license.
At least that's what the -fullopt flag did in the previous versions.
Superseeded by later work.
I tried an intermediate update to 00.01.01.02.06, and now ssh is gone?! Strange....
Yes, 00.01.01.02.06 was the first version having the the start of the ssh daemon commited away in /etc/init.d/rcS
You could try an earlier version or be the first person to try oliv3r's packer :D
Or did someone already test the packaging function?
I'm back in :scared:congratulation :D
I'm back in :scared:congratulation :D
So next step is to pack the rootfs/rigol folder as an UBIFS image
superseded by later work
|O Anyways. I don't know if downgrading is a good idea with calibration data and such.
I wanted to first backup the calibration data.
In fact I just did the quivalent patch to the old appEntry as mentioned before - and behold, all features are there without -fullopt :popcorn: :-DD Many thanks go to piskers for finding the function and pointing me to the right direction.
Since none of these versions change the bootloader, you can do all the harm that you want and there will always be a safe exit.
This means hacking is now as easy as inserting a USB key and pressing "Go!" (or whatever it says on screen).
No need to mess around with SSH or Vi.
Since none of these versions change the bootloader, you can do all the harm that you want and there will always be a safe exit.And an easy way to de-hack it if it ever has to go back under warranty. :)
mtdinfo /dev/mtd0
on the device so that we know the parameters for packing of the UBI image?Could someone runCode: [Select]mtdinfo /dev/mtd0
on the device so that we know the parameters for packing of the UBI image?
EDIT: Actually /dev/mtd6 and /dev/mtd10 just to be sure
<root@rigol>/user/mtdinfo --all --ubi-info
Count of MTD devices: 13
Present MTD devices: mtd0, mtd1, mtd2, mtd3, mtd4, mtd5, mtd6, mtd7, mtd8, mtd9, mtd10, mtd11, mtd12
Sysfs interface supported: yes
mtd0
Name: Env
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 2 (262144 bytes, 256.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:0
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd1
Name: DATA
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 512 (67108864 bytes, 64.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:2
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd2
Name: Bmp
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 32 (4194304 bytes, 4.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:4
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd3
Name: Bmp1
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 32 (4194304 bytes, 4.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:6
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd4
Name: Bit1
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 64 (8388608 bytes, 8.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:8
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd5
Name: Sys1
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 256 (33554432 bytes, 32.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:10
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd6
Name: App1
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 800 (104857600 bytes, 100.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:12
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd7
Name: Bmp2
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 32 (4194304 bytes, 4.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:14
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd8
Name: Bit2
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 64 (8388608 bytes, 8.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:16
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd9
Name: Sys2
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 256 (33554432 bytes, 32.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:18
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd10
Name: App2
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 800 (104857600 bytes, 100.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:20
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd11
Name: Reserved
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 536 (70254592 bytes, 67.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:22
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd12
Name: User
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 4800 (629145600 bytes, 600.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:24
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mkfs.ubifs -m 2048 -e 128KiB -c 800 -r /rootfs/rigol app.img
Not sure about the compression type (-x param)..ubireader_utils_info app.img
Volume app
alignment -a 1
default_compr -x lzo
fanout -f 8
image_seq -Q 329026723
key_hash -k r5
leb_size -e 126976
log_lebs -l 5
max_bud_bytes -j 8388608
max_leb_cnt -c 825
min_io_size -m 2048
name -N app
orph_lebs -p 1
peb_size -p 131072
sub_page_size -s 2048
version -x 1
vid_hdr_offset -O 2048
vol_id -n 0
#ubinize.ini#
[app]
vol_name=app
vol_size=98660352
vol_flags=autoresize
vol_type=dynamic
vol_alignment=1
vol_id=0
Which they claim maps to/usr/sbin/mkfs.ubifs -m 2048 -e 126976 -c 825 -x lzo -f 8 -k r5 -p 1 -l 5 -r $1 img-329026723_0.ubifs
/usr/sbin/ubinize -p 131072 -m 2048 -O 2048 -s 2048 -x 1 -Q 329026723 -o img-329026723.ubi img-329026723.ini
I understand nothing about, but.....wow ;D
Now, what we can finally do is generate a small upgrade file which will only patch appEntry. I would like to be as legally correct as possible, hence only provide a binary patch instead of the full file. Unfortunately, I cannot get a binary patcher to run on the scope.... So that is stalled for now. Hence it's not convenient yet.
Once I find a patcher which runs, the user just needs to plug in the USB stick and he is done. Easiest hack ever. We even check if the versions match our patch. ^-^
You misunderstood me.
I propose the user flashes the original firmware upgrade, and we just flash a small additional patch-GEL over it. I basically have it running right now, but it contains the full >20MB appEntry program, instead of just 172B of binary patches. I don't feel confident in sharing such a file. Others might want to create it though.
Once I find a patcher which runs, the user just needs to plug in the USB stick and he is done. Easiest hack ever. We even check if the versions match our patch. ^-^
edit: looks like it is (https://gitlab.com/riglol/rigolee/tree/MSO5000/firmware/rootfs/bin). With some leg work you should be able to convert a patch file into a bash script using dd to manually write each byte. Not pretty (and not fun), but it seems like it should do the trick.
Looking at the disassambled appEntry file, it looks to me like it's only able to start a ssh and ftp daemon, but not to stop any of them.
I'm missing something... how do you plan to patch the app file that is currently running?? The system allows it?Sure, an upgrade is just a shell script like any other. Under linux you can modify used files. No issue here.
the SSH patch works, but the "-fullopt" in start.sh does not bring any extensionThat is because you need to additionally patch the scope. See this post.
Do not worry, it takes around 5 minutes to apply all the patches.
Do not worry, it takes around 5 minutes to apply all the patches.
5 mins???? Are you mining in between??? :-DD
One more thing that we should look for is whether the device contacts rigol when it's connected to the internet and possibly transfers the S/N and licenses. I didn't find anything yet in the appEntry.
At least when checking for an update it doesn't transmit anything else.
I would guess so. Still waiting for the scope to be delivered. You can also use oliv3r's packer I think: https://gitlab.com/riglol/rigolee/#gel-packerIt was only tested to generate small GEL files that do, for example, backup the calibration partition etc. using the scripts here; https://gitlab.com/riglol/rigolee/tree/MSO5000/target
But I'm not sure if this is tested at all.
Yes, 00.01.01.02.06 was the first version having the the start of the ssh daemon commited away in /etc/init.d/rcS
You could try an earlier version or be the first person to try oliv3r's packer :D
Or did someone already test the packaging function?
EDIT: Oh okay, I guess downgrading is not possible?
|O Anyways. I don't know if downgrading is a good idea with calibration data and such. I think i also saw a check against it in fw4linux.sh.
oliv3r's packer will only do the firmware flash encryption (so i could batch out the downgrade stop). It will not generate the image files etc.
@Oliv3r, I had to add --owner=rigolee --group=rigolee to the tar commands.Sure, but why? Then again, I've only run the scripts so far, so the change does seem sensible of course.
So next step is to pack the rootfs/rigol folder as an UBIFS imageYeah, but that's a little trickier with the permissions, git doesn't like the users much. I do add them with the proper permissions I think (root:root 600 for example) but haven't check what happens to this on check-out.
I've written the packer a few months ago :p and posted links here; nobody took up to challange to write scripts to do these things :) (such as adding the -fullopt for example, and now patching the appEntry).This means hacking is now as easy as inserting a USB key and pressing "Go!" (or whatever it says on screen).
No need to mess around with SSH or Vi.
Once we can create the update files. I'm not the best in shell scripts, so somebody else might be faster. Oliv3r?
Thank you!
So packaging should be possible with:Code: [Select]mkfs.ubifs -m 2048 -e 128KiB -c 800 -r /rootfs/rigol app.img
Not sure about the compression type (-x param)..
Then gzip it and run oliv3r's script. Can't try it till tomorrow though..
I'm missing something... how do you plan to patch the app file that is currently running?? The system allows it?Should work just fine, the file is read into memory and executed from there. App-entry should never try to rewrite itself anyway. So copy file, reboot scope, profit :)
Good idea :-D, but no. The easiest solution i found was to just convert the binary file to hexadecimal representation, patch it as text, and reverse the process. It looks like the busybox patch command is very slow though. But as an advantage you get the context sensitivity of patch, so it will also fail if the "surroundings" of the binary do not exactly match.Little sledge-hammer method. Just be sure not to write the HEX file to the NAND filesystem. NAND is already super sensitive to wear and tear. Writing so much data just for the patch, just wears the NAND unessaserly. Write to tmpfs/ramfs instead. (/ and probably /tmp should be ramfs).
The easiest solution i found was to just convert the binary file to hexadecimal representation, patch it as text, and reverse the process. It looks like the busybox patch command is very slow though. But as an advantage you get the context sensitivity of patch, so it will also fail if the "surroundings" of the binary do not exactly match.
BUT monday/tuesday I should finally receive my own scope. Now if someone can free up some time on my calander :D
Good idea :-D, but no. The easiest solution i found was to just convert the binary file to hexadecimal representation, patch it as text, and reverse the process. It looks like the busybox patch command is very slow though. But as an advantage you get the context sensitivity of patch, so it will also fail if the "surroundings" of the binary do not exactly match.Little sledge-hammer method. Just be sure not to write the HEX file to the NAND filesystem. NAND is already super sensitive to wear and tear. Writing so much data just for the patch, just wears the NAND unessaserly. Write to tmpfs/ramfs instead. (/ and probably /tmp should be ramfs).
Write to tmpfs/ramfs instead. (/ and probably /tmp should be ramfs).
Question: How much free 'disk' and RAM have these things got?
<root@rigol>df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 31.0M 21.8M 9.2M 70% /
devtmpfs 213.6M 0 213.6M 0% /dev
none 100.0M 292.0K 99.7M 0% /tmp
/dev/ubi6_0 85.1M 71.1M 14.1M 83% /rigol
/dev/ubi1_0 37.2M 244.0K 35.0M 1% /rigol/data
/dev/ubi12_0 516.6M 1.6M 510.4M 0% /user
<root@rigol>free -m
total used free shared buffers
Mem: 437 154 283 0 0
-/+ buffers: 153 283
Swap: 0 0 0
Btw, the appEntry also seems to have support for (jitter) eye diagrams..
The patch enables "Power analyzer", "Eye trigger" and "jitter" in the measurement analyze menu. Previously -fullopt still had one additional check, which I bypassed too.
The patch enables "Power analyzer", "Eye trigger" and "jitter" in the measurement analyze menu. Previously -fullopt still had one additional check, which I bypassed too.
That isn't correct. fullopt had no further checks. It enabled all the Options.
Code: [Select]<root@rigol>df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 31.0M 21.8M 9.2M 70% /
devtmpfs 213.6M 0 213.6M 0% /dev
none 100.0M 292.0K 99.7M 0% /tmp
/dev/ubi6_0 85.1M 71.1M 14.1M 83% /rigol
/dev/ubi1_0 37.2M 244.0K 35.0M 1% /rigol/data
/dev/ubi12_0 516.6M 1.6M 510.4M 0% /user
<root@rigol>free -m
total used free shared buffers
Mem: 437 154 283 0 0
-/+ buffers: 153 283
Swap: 0 0 0
For when people brick their scopes there is an easy way to recover them...
Serial port is disabled in the latest version so no playing about with Uboot now.
How do you enter into that menu?
After that, apply the update attached to this file.
I seem to be one of the lucky ones with no overcompensation on any channel and I've read that after re-calibration overcompensation will occur.
Did they a U-Boot Update from inside Linux? Or why is serial disabled?
This is Bad.. If you Brick anything you can't recover it even with opening the case 😔 we should try to reenable serial with our "inofficial" update.
Okay got it. I read it in english and thought in German... Sometimes its hard... :palm: |O
Would you please share how have you arrived to this nicely decompiled code? I tried using IDA pro v7 didn't get that nice result!The patch enables "Power analyzer", "Eye trigger" and "jitter" in the measurement analyze menu. Previously -fullopt still had one additional check, which I bypassed too.
That isn't correct. fullopt had no further checks. It enabled all the Options.
Would you please share how have you arrived to this nicely decompiled code? I tried using IDA pro v7 didn't get that nice result!
what does get_IsUsbKey_Ready() do?
00 "BW1T2" DS7000
01 "BW1T3" DS7000
02 "BW1T5" DS7000
03 "BW2T3" DS7000
04 "BW2T5" DS7000
05 "BW3T5" DS7000
06 "MSO" (LA)
07 "2RL" MSO5000 DS7000
08 "5RL" DS7000
09 "BND" = COMP + EMBD + AUTO + FLEX + AUDIO + AERO + PWR + AWG
10 "COMP" MSO5000 DS7000
11 "EMBD" MSO5000 DS7000
12 "AUTO" MSO5000 DS7000
13 "FLEX" MSO5000 DS7000
14 "AUDIO MSO5000 DS7000
15 "SENSOR
16 "AERO" MSO5000 DS7000
17 "ARINC"
18 "AWG" MSO5000 (DG)
19 "JITTER"
20 "MASK"
21 "PWR" MSO5000 DS7000
22 "DVM"
23 "CTR"
24 "EDK"
25 "4CH"
26 "BW07T1" MSO5000
27 "BW07T2" MSO5000
28 "BW07T3" MSO5000
29 "BW07T5"
How do you enter into that menu?
"Not married" key while ubooting.
So ... the 'scope keeps a copy of the factory-installed firmware somewhere, and you can restore it by pressing a button at startup?
That's awesome if true. It means hacking new firmwares is risk-free.
|O Anyways. I don't know if downgrading is a good idea with calibration data and such.I wanted to first backup the calibration data.
Ummm... isn't that what self-cal is for - to generate some new data? :popcorn:
Ummm... isn't that what self-cal is for - to generate some new data? :popcorn:
It turns out that the new firmware has troubles with auto-calibration. Using my backuped calibration files the spikes also reported by others are gone :popcorn:
EDIT: See also here (https://www.eevblog.com/forum/blog/new-rigol-scope/msg2238324/#msg2238324)
As reported - I lost 2 channels, the AWGs.... Interestingly enough, in the acquisition menu it still showed 200M, but when changed - the 200M option disappeared.
I played with the SSH enable .GEL. Upon installing - my scope always says its corrupt. Tried and re-tried many times. I did finally checked, after it failed - and sure enough - it was working. So maybe the corrupt file warning is normal for this patch? I have not tried to go in and make it permanent - it appears that the patch just turns it on for this boot...
The patch for the license... I reformatted the drive again, Put the file on the USB drive, and selected it on the scope. No errors - it updated perfectly. Then it asked me to reboot - which I did......:phew: First confirmed successful patch after my scope. Nice!
My scope is back...!!!! All 4 channels, the 2 AWGs, 200M samples. I went to the license page - looks just as shown -- all enabled and permanent.
I'm not much of a Linux guru. How do I back up my calibration data, and how do I restore it after upgrade/patch?
mkdir /media/sda1/calib_backup
cp -v /rigol/data/* /media/sda1/calib_backup
sync
cp -v /media/sda1/calib_backup/*.hex /rigol/data/
sync
I ordered an MSO5074, beginning on Februrary from my distributor supposed to be delivered End of February.
Now they say they won't be restocked by Rigol until end of March.
I am afraid when they are restocked it will be with patched firmware scopes....
would this enable the logic analyzer? so i can pick up some probes?
So bottom line - it worked here although I have some more work to do to make SSH on permanently.SSH is enabled/disabled via /etc/init.d/rcS which is stored in the initramfs of the linux system. So every change there will be non-permanent.
#!/bin/sh
/usr/sbin/sshd
export QTDIR=/rigol/Qt5.5
The Rigol LA probe is a bit spendy, so I designed my own: https://gitlab.com/dren.dk/mso5k-la-pod (https://gitlab.com/dren.dk/mso5k-la-pod)
Actually others have done the same in this thread:
https://www.eevblog.com/forum/testgear/rpl1116-active-logic-probe-pod-for-1000z-series-teardown/new/?topicseen#new (https://www.eevblog.com/forum/testgear/rpl1116-active-logic-probe-pod-for-1000z-series-teardown/new/?topicseen#new)
My parts just shipped from Mouser, so I expect to have three working LA probe sets done next week or so.
....
After upgrading the firmware (prior to that I’ve made a backup) to 01.01.04.04, I found that the calibration files didn’t change at all and everything remains perfect. Even though I’ve made a calibration with the new firmware and notice that in the window (before starting the calibaration) was displayed the date of my previous calibration. Lucky for me this calibration went flawlessly and didn’t change any of the 4 channels - everything remains as flat as it was.
These are my “lfcal.hex” before and after - which interestingly enough in my case are the SAME. May be they are something unit specific.
- some screenshots 1) before, 2) after upgrade with previous calibration and 3) after upgrade with new calibration.
Anybody else thinking that a wiki of some sort with some instructions on what to do with this would be a good thing? The forum is great, but finding the right bits now has got kind of hard.
Beginning to think we're dealing with a low freq factory cal file done on a Friday afternoon, and this pretty much seals it for me (short of looking at the disassembly) that it's not something auto cal touches.
The thing I'd wonder, is if there's a factory menu or tool that can be used hidden on the scope somewhere, or if it's some special firmware we'll never get. Calibration references are no problem to get a hold of, so it's especially frustrating that it's seemingly a cal file behind all of it.....
Anybody else thinking that a wiki of some sort with some instructions on what to do with this would be a good thing? The forum is great, but finding the right bits now has got kind of hard.
Anybody else thinking that a wiki of some sort with some instructions on what to do with this would be a good thing? The forum is great, but finding the right bits now has got kind of hard.
Definitely. This thread is about 70% non-hacking discussion. They asked for it to be moved but that never took hold.
Is this great effort somehow applicable to the DS7000 as well??
"Tried this with our DS7014, now has full 500MHz bandwidth and 500M memory..."
I read the serial number could be lost after the patch, if I restore to official firmware state, then is the serial number restored?Serial number is saved in /rigol/data together with the calibration data. Once you loose that, you loos it, I think.
If I have is for whatever reason if I need to back out the patch to restore to official firmware state, is there a tested process to do that? Is is just to reapply the official update, or is there more?
Anybody else thinking that a wiki of some sort with some instructions on what to do with this would be a good thing? The forum is great, but finding the right bits now has got kind of hard.
Definitely. This thread is about 70% non-hacking discussion. They asked for it to be moved but that never took hold.
I don't think the hack is finished yet.
When it is it will just be "a) Download this file onto a USB stick, b) Insert stick into 'scope".
I'm sure a new thread can be started for that so that people can endlessly post "Does this still work?"
I don't think the hack is finished yet.
When it is it will just be "a) Download this file onto a USB stick, b) Insert stick into 'scope".
I don't think the hack is finished yet.
When it is it will just be "a) Download this file onto a USB stick, b) Insert stick into 'scope".
I don't think the hack is completely finished, there are still so many bugs even in the latest firmware that a new firmware release is bound to come out and may need to be re-hacked.
However, I did receive my 5074 today and it was as easy as downloading the file and inserting into the scope. It took about 45 minutes of reading through posts though. I purchased this scope over a month ago and it has been on back order. When I purchased the scope and checked the forum, the hack was as simple as SSH and editing a line in the start file. After reading through tons of off topic posts and stories I found the solution, at least as of now.
All I did to unlock the scope was
a)download and copy the file onto my fat32 formatted usb drive.
I got the file from this post https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2235282/#msg2235282 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2235282/#msg2235282)
(I also had to rename the file to DS5000Update.GEL)
b) plug the flash drive into the scope and run a local upgrade
c) enjoy the unlocked scope
I did not bother backing up the calibration data as my scope came with firmware version 01.01.04.04 and had a messed up calibration out of the box consistent with how others have described the calibration with the new firmware.
Not wanting to toot my own horn much, but we have a wiki already :) (well not on the eevblog wiki, which we could also do) but https://gitlab.com/riglol/rigolee/firmware/ has an extensive README already on some of the things, and there's also a wiki (which lacks all the hacking details so far) https://gitlab.com/riglol/rigolee/firmware/-/wikis/homeAnybody else thinking that a wiki of some sort with some instructions on what to do with this would be a good thing? The forum is great, but finding the right bits now has got kind of hard.
Definitely. This thread is about 70% non-hacking discussion. They asked for it to be moved but that never took hold.
It would be really nice if in the same process, the script also provides an option to backup the calibration data, and optionally the entire scope data to the USB.
Then followed by another option to restore calibration data only, or the entire scope data before the patch.
This will allow flexibility for a full rollback in case something went wrong in the patch process.
I know that is a lot of extra work in scripting, but as a solution architect for 30 years, such capability has always been invaluable when disaster strikes on numerous upgrades I have been involved in. Sorry if it is too much to ask ;D as I am not a developer.
Thanks in advance for all the great work done by the members of this wonderful community.Anybody else thinking that a wiki of some sort with some instructions on what to do with this would be a good thing? The forum is great, but finding the right bits now has got kind of hard.
Definitely. This thread is about 70% non-hacking discussion. They asked for it to be moved but that never took hold.
I don't think the hack is finished yet.
When it is it will just be "a) Download this file onto a USB stick, b) Insert stick into 'scope".
I'm sure a new thread can be started for that so that people can endlessly post "Does this still work?"
Secret menu allows installing any version, even previous ones.
Initially it did not worked for me from the first time as well.Worked first try! Thank you!
Keep pressing "SINGLE" key at the same time as you Power On.
You should see two options at the top right corner.
I'm not common with uboot, more with barebox.
What ist boot from Gold-Finger? Is it a common uboot command or rigol specific?
EDIT2: That actually works. Nice! We can definitely unbrick any scope and even clone scopes if we liked. Very nice.
Not sure, but there is a header called GoldFinger on the scopes PCB.The GoldFinger enables the 10bit ADCs :-DD
So ... the 'scope keeps a copy of the factory-installed firmware somewhere, and you can restore it by pressing a button at startup?
That's awesome if true. It means hacking new firmwares is risk-free.
No. It just restores default scope settings.
The method here seems to be setting the uboot variable bootparam to 0x44454654
But /rigol/data only exists once, doesn't it?Yepp.
Initially it did not worked for me from the first time as well.
Keep pressing "SINGLE" key at the same time as you Power On.
You should see two options at the top right corner.
Initially it did not worked for me from the first time as well.How long did you hold pressed the SINGLE key? At what time the menu popup ? Do I need to release it at particular moment.
Keep pressing "SINGLE" key at the same time as you Power On.
You should see two options at the top right corner.
It doesn't work for me - my Boot: 2018.06.27
Initially it did not worked for me from the first time as well.How long did you hold pressed the SINGLE key? At what time the menu popup ? Do I need to release it at particular moment.
Keep pressing "SINGLE" key at the same time as you Power On.
You should see two options at the top right corner.
It doesn't work for me - my Boot: 2018.06.27
The trick is to
Press "SINGLE" button multiple times until you see additional menu items.
If progress bar is in the middle this indicates that you missed it - start over again (turn off & on).
Interestingly when you use the web interface the options list shows many with the demo time.
Are there any risks, like this overshoot Thing ( which I don´t have ) ?
When a new FW is there and upgraded to the scope, the hack will be gone, I guess ?Yes. with no trace left. Somebody will need to create a new patch then.
So it is a difference between installing the options buying - which stays forever.
It would be helpful I guess, when someone buy the option-bundle (or even one) and let the cracks having a look on it.
Is there a good solution to have SSH enabled on each boot?
Of course, real licenses are the only thing that will be future-proof...
Current best practice:
- Note your current software version down. If it is older than 01.01.04.04 you will need to upgrade.
- Backup your scope specific data such as calibration values. Get the DS5000Update_backup.GEL.txt from here. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2251380/#msg2251380) Rename to DS5000Update.GEL and put it on a USB drive. Execute an upgrade. You will see the scope doing a backup. Unplug the stick and make sure you have a backup in the data_backup folder on the stick.
- If you have an older version of the firmware, download 01.01.04.04 from here (https://gitlab.com/riglol/rigolee/blob/MSO5000/GEL/DS5000Update_01.01.04.04.GEL). Also rename it to DS5000Update.GEL, put it on your usb drive, and upgrade.
- Make sure you are on the 01.01.04.04 firmware in the about dialog.
- Patch the scope to have all licenses. For that download the patch from here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2235282/#msg2235282). Again rename and copy to usb drive. This time the upgrade might take a bit longer, it should ask you to reboot, if not something failed, but it is probably not fatal for your scope, no worries. Reboot.
- Check that all licences are activated.
- If you want, do an auto calibration and check that everything is still okay.
You can get temporary SSH access by executing this upgrade (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076). The upgrade will "fail", but you will have ssh until reboot. You can use this to fix your calibration data, if truly required.
So it is a difference between installing the options buying - which stays forever.
It would be helpful I guess, when someone buy the option-bundle (or even one) and let the cracks having a look on it.
Of course, real licenses are the only thing that will be future-proof...
The trial licenses that everybody has are sufficient to see how they are done. The .LIC files are basically ECDSA Signatures.
Those signatures are verified with the PubKey in KEY.DATA file.
One quick question, does the DS5000Update_backup.GEL also backup other data other than the calibration data? I understand some files could be lost as part of the patch (I believe the license file being one of them, is there others?), it would be nice if this backs up all the files that could be lost so we can do a full rollback/restore if needed.
OK, then just patch the KEY.DATA PubKey to whatever?
One quick question, does the DS5000Update_backup.GEL also backup other data other than the calibration data? I understand some files could be lost as part of the patch (I believe the license file being one of them, is there others?), it would be nice if this backs up all the files that could be lost so we can do a full rollback/restore if needed.
Yes it backs everything scope specific up, including licenses. Regarding loosing things, only the actual firmware upgrade has been observed messing with it, not the license patch.OK, then just patch the KEY.DATA PubKey to whatever?
Sure, could do. "All Roads Lead to Rome". But you will loose compatibility to original keys, and that is what you initially wanted.
OK, then just patch the KEY.DATA PubKey to whatever?
it would be nice if this backs up all the files that could be lost so we can do a full rollback/restore if needed.
OK, then just patch the KEY.DATA PubKey to whatever?
A "special" whatever... ;)
Current best practice:
- Note your current software version down. If it is older than 01.01.04.04 you will need to upgrade.
- Backup your scope specific data such as calibration values. Get the DS5000Update_backup.GEL.txt from here. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2251380/#msg2251380) Rename to DS5000Update.GEL and put it on a USB drive. Execute an upgrade. You will see the scope doing a backup. Unplug the stick and make sure you have a backup in the data_backup folder on the stick.
- If you have an older version of the firmware, download 01.01.04.04 from here (https://gitlab.com/riglol/rigolee/blob/MSO5000/GEL/DS5000Update_01.01.04.04.GEL). Also rename it to DS5000Update.GEL, put it on your usb drive, and upgrade.
- Make sure you are on the 01.01.04.04 firmware in the about dialog.
- Patch the scope to have all licenses. For that download the patch from here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2235282/#msg2235282). Again rename and copy to usb drive. This time the upgrade might take a bit longer, it should ask you to reboot, if not something failed, but it is probably not fatal for your scope, no worries. Reboot.
- Check that all licences are activated.
- If you want, do an auto calibration and check that everything is still okay.
You can get temporary SSH access by executing this upgrade (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076). The upgrade will "fail", but you will have ssh until reboot. You can use this to fix your calibration data, if truly required.
Current best practice:
- Note your current software version down. If it is older than 01.01.04.04 you will need to upgrade.
- Backup your scope specific data such as calibration values. Get the DS5000Update_backup.GEL.txt from here. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2251380/#msg2251380) Rename to DS5000Update.GEL and put it on a USB drive. Execute an upgrade. You will see the scope doing a backup. Unplug the stick and make sure you have a backup in the data_backup folder on the stick.
- If you have an older version of the firmware, download 01.01.04.04 from here (https://gitlab.com/riglol/rigolee/blob/MSO5000/GEL/DS5000Update_01.01.04.04.GEL). Also rename it to DS5000Update.GEL, put it on your usb drive, and upgrade.
- Make sure you are on the 01.01.04.04 firmware in the about dialog.
- Patch the scope to have all licenses. For that download the patch from here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2235282/#msg2235282). Again rename and copy to usb drive. This time the upgrade might take a bit longer, it should ask you to reboot, if not something failed, but it is probably not fatal for your scope, no worries. Reboot.
- Check that all licences are activated.
- If you want, do an auto calibration and check that everything is still okay.
You can get temporary SSH access by executing this upgrade (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076). The upgrade will "fail", but you will have ssh until reboot. You can use this to fix your calibration data, if truly required.
Ive upgraded to the newest firmware but when I upload the patch (with renaming) scope says fail to update please check package
Ive upgraded to the newest firmware but when I upload the patch (with renaming) scope says fail to update please check package
I already got the 01.01.04.04 Version (and wonder, why it isn´t on the webpages of rigol U.S. or europe)
It is no different in the U.S., we have to register before download as well.
Current best practice:
- Note your current software version down. If it is older than 01.01.04.04 you will need to upgrade.
- Backup your scope specific data such as calibration values. Get the DS5000Update_backup.GEL.txt from here. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2251380/#msg2251380) Rename to DS5000Update.GEL and put it on a USB drive. Execute an upgrade. You will see the scope doing a backup. Unplug the stick and make sure you have a backup in the data_backup folder on the stick.
- If you have an older version of the firmware, download 01.01.04.04 from here (https://gitlab.com/riglol/rigolee/blob/MSO5000/GEL/DS5000Update_01.01.04.04.GEL). Also rename it to DS5000Update.GEL, put it on your usb drive, and upgrade.
- Make sure you are on the 01.01.04.04 firmware in the about dialog.
- Patch the scope to have all licenses. For that download the patch from here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2235282/#msg2235282). Again rename and copy to usb drive. This time the upgrade might take a bit longer, it should ask you to reboot, if not something failed, but it is probably not fatal for your scope, no worries. Reboot.
- Check that all licences are activated.
- If you want, do an auto calibration and check that everything is still okay.
You can get temporary SSH access by executing this upgrade (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076). The upgrade will "fail", but you will have ssh until reboot. You can use this to fix your calibration data, if truly required.
Ive upgraded to the newest firmware but when I upload the patch (with renaming) scope says fail to update please check package
Did you read the last sentence? (highlighted)
Ive upgraded to the newest firmware but when I upload the patch (with renaming) scope says fail to update please check package
If you are talking about the license patch. This is strange. It is the first observed failure. I could only recommend trying again with a freshly FAT32 formatted usb drive. (It uses the drive as space for intermediate patching results, so there should be space.) If this does not work, you either have to wait for a new patch with better debug output on the screen, or ssh in and execute "/rigol/shell/update.sh /media/sda1/DS5000Update.GEL" and report back any failures you see.
Try a third party dedicated usb formatting tool. It has been said that the one built into Windows 7 and on is problematic. May be the same for Mac, I think Apple is worse than Microsoft about tweaking things to suite themselves.Ive upgraded to the newest firmware but when I upload the patch (with renaming) scope says fail to update please check package
If you are talking about the license patch. This is strange. It is the first observed failure. I could only recommend trying again with a freshly FAT32 formatted usb drive. (It uses the drive as space for intermediate patching results, so there should be space.) If this does not work, you either have to wait for a new patch with better debug output on the screen, or ssh in and execute "/rigol/shell/update.sh /media/sda1/DS5000Update.GEL" and report back any failures you see.
Thanks I will try this. I think it's just not detecting my usb for some reason. Maybe because I formatted using my Mac? Are you guys formatting the drives on a windows machine? I'll keep you posted with my results.
Ive upgraded to the newest firmware but when I upload the patch (with renaming) scope says fail to update please check package
If you are talking about the license patch. This is strange. It is the first observed failure. I could only recommend trying again with a freshly FAT32 formatted usb drive. (It uses the drive as space for intermediate patching results, so there should be space.) If this does not work, you either have to wait for a new patch with better debug output on the screen, or ssh in and execute "/rigol/shell/update.sh /media/sda1/DS5000Update.GEL" and report back any failures you see.
Thanks I will try this. I think it's just not detecting my usb for some reason. Maybe because I formatted using my Mac? Are you guys formatting the drives on a windows machine? I'll keep you posted with my results.
If you can cancel your order batterfly . com have them in stock right now, I've bought mine from there and was sent on the next day with free shipping
Hi all.
I'm new to this forum and have been following this thread for about two weeks.
A week or so ago, I decided purchased a Rigol MSO5104 (which came with F/W v02.03) and then added the -fullopt to a line on the start.sh file.
Two days ago, I decided to upgrade the F/W to v04.04 and used the various .GEL files produced by mabl (a big thanks to you) and I too can confirm that update patch works :-+
Afterwards, I edited the start.sh file as suggest by oliv3r (see https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2245083/#msg2245083 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2245083/#msg2245083)) instead of having to insert a USB stick with the 10kB .GEL file on it (see https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076)) in order to enable SSH.
Fellow members, I have a few questions for you:
Q1: I tried editing two commented-out lines in /etc/init.d/rcS to enable SSH and FTP, but would like to know why/how it reverts back to the commented-out lines after a reboot?
Q2: Also, is the power button/switch the only way to reboot (other than connecting via SSH and running the command reboot ?
Q3: I backed-up my .hex calibration files (using mabl's .GEL file) before upgrading the F/W and then manually copied them back afterwards. Is it safe to do a self-calibration with the current F/W version or should one stick to the backed up calibration files (as I have done)?
Thanks again to all those who have contributed to this forum. :)
Hi all.
I'm new to this forum and have been following this thread for about two weeks.
A week or so ago, I decided purchased a Rigol MSO5104 (which came with F/W v02.03) and then added the -fullopt to a line on the start.sh file.
Two days ago, I decided to upgrade the F/W to v04.04 and used the various .GEL files produced by mabl (a big thanks to you) and I too can confirm that update patch works :-+
Afterwards, I edited the start.sh file as suggest by oliv3r (see https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2245083/#msg2245083 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2245083/#msg2245083)) instead of having to insert a USB stick with the 10kB .GEL file on it (see https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076)) in order to enable SSH.
Fellow members, I have a few questions for you:
Q1: I tried editing two commented-out lines in /etc/init.d/rcS to enable SSH and FTP, but would like to know why/how it reverts back to the commented-out lines after a reboot?
Q2: Also, is the power button/switch the only way to reboot (other than connecting via SSH and running the command reboot) ?
Q3: I backed-up my .hex calibration files (using mabl's .GEL file) before upgrading the F/W and then manually copied them back afterwards. Is it safe to do a self-calibration with the current F/W version or should one stick to the backed up calibration files (as I have done)?
Thanks again to all those who have contributed to this forum. :)
I read the serial number could be lost after the patch, if I restore to official firmware state, then is the serial number restored?Serial number is saved in /rigol/data together with the calibration data. Once you loose that, you loos it, I think.If I have is for whatever reason if I need to back out the patch to restore to official firmware state, is there a tested process to do that? Is is just to reapply the official update, or is there more?
Either manually copy back appEntry over ssh, or flash the original firmware. I'm not sure if there is a patch against same-version flashing though. Could potentially be patched out, though.
I just realized, you may also want to start udhcpc -i eth0 & somewhere :) probably before your ssh line. If your appEntry fails to start or crashes or whatever, the devices will be without an IP, so ssh will be up and running, but you won't be able to access it.
appEntry does its own network management (wtf much?) but that doesn't conflict.
After rereading all the posts after page 30, I believe I made a mistake in saying that the serial number may be lost. Looks like what could be lost are the "licenses", are we only referring to losing the 2160 min of trial serial decoder licenses?I read the serial number could be lost after the patch, if I restore to official firmware state, then is the serial number restored?Serial number is saved in /rigol/data together with the calibration data. Once you loose that, you loos it, I think.
1) Regarding the ssh command (I'm using Terminal on the Mac), it keeps saying "Warning: Permanently added '<IP address>' (ECDSA) to the list of known hosts." - is this anything to worry about?
2) Does anyone know if there a terminal command (on the scope) that can check the FAT-formatted partition on a USB memory stick (I usually use fsck but can't see the msdos version)?
If you can cancel your order batterfly . com have them in stock right now, I've bought mine from there and was sent on the next day with free shipping
Great advice! As you suggested I ordered with batterfly (just 2days ago). Same day free shipping. I just now got the scope delivered with FW 00.01.01.02.03. Fully recommended!
First of all, I have updated the backup script (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2251380/#msg2251380), and it should be more reliable now. Do use it, really ;D
First of all, I have updated the backup script (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2251380/#msg2251380), and it should be more reliable now. Do use it, really ;D
Q: Is this updated .GEL file for running from a USB memory stick and/or via a terminal command, as it says "Press any key to continue..." ?
I saw that too, I just push one of the red key on the right of the screen, the screen will then go black for about 10 sec, then the scope screen will return.
After that, you will get a backup file on the USB with an extension of .tar.bz3 (if I recall correctly). I don't believe the extra bz3 extension was there before in the old script. I just delete the extra .bz3, and I was able to untar it into its own directory on a Windows 10 PC.It tried to do it previously too, but failed due to timing during this process. The new system will make sure everything is written first and adds the user interaction.
I also noticed that Windows will report the USB drive needs to be repaired when it comes back from the scope. I wonder if it has to do with me not doing a proper eject on the scope. On that note, is there even an eject USB drive option on the scope?
In any event, I did not repair the USB drive and ignored the message on the Windows 10 machine, Windows was able to retrieve the file without any problem.
A big shoutout to mabl for making all this possible, thank you!
Current best practice:
- Patch the scope to have all licenses. For that download the patch from here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2235282/#msg2235282). Again rename and copy to usb drive. This time the upgrade might take a bit longer, it should ask you to reboot, if not something failed, but it is probably not fatal for your scope, no worries. Reboot.
I renamed it to DSO5000Update.GEL put it to the stick, do local upgrade....Message "No package found" appears.
For windows it´s still a txt format while the "original" GEL file will be displayed as a GEL.file .
Maybe that´s the reason it doesn´t work on the scope too ?
That is how the backup script should look like. Did your patch succeed now? You can run it from the command line too, but it will not give as much output.
I just realized, you may also want to start udhcpc -i eth0 & somewhere :) probably before your ssh line. If your appEntry fails to start or crashes or whatever, the devices will be without an IP, so ssh will be up and running, but you won't be able to access it.
appEntry does its own network management (wtf much?) but that doesn't conflict.
Hi oliv3r.
Thanks for the suggestion above - I'll try it out and see if it works... :) Would I expect udhcpc in the list of processes by running ps -al in the terminal?
I have a few additional questions for this thread/forum ;)
1) Regarding the ssh command (I'm using Terminal on the Mac), it keeps saying "Warning: Permanently added '<IP address>' (ECDSA) to the list of known hosts." - is this anything to worry about?
2) Does anyone know if there a terminal command (on the scope) that can check the FAT-formatted partition on a USB memory stick (I usually use fsck but can't see the msdos version)?
3) I'm not sure if this is the correct Rigol MSO5000-related thread to post this question... So, I decided to use the Measure menu to add Frequency, Period, Undershoot and Overshoot measurements in order to calibrate the four passive probes supplied with my MSO5104. I managed to get both the Under/Overshoot down to ~0.6060% for channels 1, 2 and 4 using the 1KHz square wave (from the probe compensation terminal) and those three channels now show a good flat square wave. However, channel 3 is showing a bit of overshoot (0.6711%) that I can't get rid of - is this normal and/or is it possible to rectify it?? Not sure if it's a software or hardware problem either. I have attached, below, a screenshot of the measurements and I did run the SelfCal function beforehand.
2) umount /dev/sda1 && fsck -a -f /dev/sda1 you mean?
Thanks !
Now I got a GEL. file…... 8)
(tomorrow a shot with the same voltage resolution (forgot it) )
Quote(tomorrow a shot with the same voltage resolution (forgot it) )
Done, posted there to keep this thread clean:
https://www.eevblog.com/forum/blog/new-rigol-scope/msg2270838/#msg2270838 (https://www.eevblog.com/forum/blog/new-rigol-scope/msg2270838/#msg2270838)
Cleaning is deleting!
Big thanks for such an easy thing to do.
When the next firmware update will be released, the hack will be gone - then we could patch it again with the same file….perhaps.
When this can be done, it´s an evidence that rigol doesn´t want to stop hacking seriously.
fsck.minix is the only fsck version available :( so sad. So you'd have to do it locally on a desktop system
2) umount /dev/sda1 && fsck -a -f /dev/sda1 you mean?
Yes exactly that - but I get the error message as shown at the bottom of the attached image. |O
It amazes me how these companies will rush a basically good piece of hardware to market with this many firmware bugs... and with only half-assed beta testing (if any)... This is generally where the community decides to take matters into their own hands, and makes it a fully open-source project. Can anyone say, "OpenWRT"?Absolutly, as long as you realize, it's a massive amount of work of course.
You've dumped all the firmware... Clearly, some people are using IDA Pro to reverse engineer some of that code. You could amp-this-up by using FLIRT signatures in IDA for code pattern recognition of known libraries (I did this for an STM-based Set-Top-Box using all their code libraries). Once all the "canned" code is identified, what's left is custom-written code/drivers - and you can figure-out what they're doing with some work... I'm sure this was the same basic process that resulted in the OpenWrt Project (maybe we should call it the "OpenScope Project"?)Cute :) but you understatimate the effort :)
It's only a matter of time before we, as a community, pick a relatively inexpensive "base" piece of DSO hardware and make it our own (as in, we maintain the firmware/software - they just compete on the best hardware). What DSO engineering company wouldn't want to be "chosen" by our community as the first hardware "base"? ...Certainly not Rigol - they just want to sell their hardware... and I'm half thinking (at least, in part) this is Rigol's modus operandi when it comes to the ease of hacking their scopes. I'm actually really surprised that a entire source code tree hasn't mysteriously "appeared" on the web to force some companies' sales into the stratosphere... and it would!I love your enthousiasm, but so far, mostly hardware guys in this thread (which we also badly need). Step one, with any project, is understanding the hardware. We have some good resources though, but at least I haven't documented all my findings yet :) In time, in time. The wiki also has some knowledge of the chips used for example. We ain't sleepin' ya know.
Once you force the issue, these DSO engineering companies will work/compete on making a better hardware platforms for our "OpenScope" software...I welcome you to help! Please :)
It's only a matter of time... and the first DSO engineering company that adopts this marketing strategy, will win all the marbles... and it will be a paradigm shift for the entire O-scope industry. Sure, they'll all still continue making expensive +500MHz scopes (IBM still makes mainframes) for universities and fortune 500 companies, but they'll relinquish the entire sub-500MHz market to Open Source software... kind of like your generic PC hardware is now.
...All it will take is for it to happen just once on a "chosen" platform... kinda like this one... ;)
BB
Well I know that after the double beep you hear during boot, 'appEntry' starts (their main application). That's where the scope spends most its time. Even the 8 seconds it takes to load the FPGA (which is needed anyway) is insignificant compared to the bloated QT app to load. So they must have reduces some sleeps/waits in some loops during startup to shave those 16 seconds off, and pray that everything still works :)When the next firmware update will be released, the hack will be gone - then we could patch it again with the same file….perhaps.
When this can be done, it´s an evidence that rigol doesn´t want to stop hacking seriously.
The firmware release notes states that it 'Boots in less than a minute'" so obviously some boss gave the order to "Make it boot in less than a minute!"
It used to boot in 1:15 and now it takes 0:59 so they shaved off just enough to comply with the order. As soon as it was less than 60s they stopped work.
Switching off SSL might have been one of the things they did to reach that goal, ie. it wasn't switched off for security reasons but purely for boot-timing reasons. :popcorn:
.... the bloated QT app to load.
It aint so!.... the bloated QT app to load.
QT? Say it ain't so. :palm:
but I'm quite baffled, as to why I can't get decent text out of my console on the scope. Lets start with a screenshot :) (see attachment)
I recently had a need to use the UART interface on an MSO5074 and found this to be a challenging exercise.
There were two issues:-
1. The data out of the MSO5074 was corrupted from time to time.
2. There was no response to commands sent to the unit.
The corrupted data out of the MSO5074 was found to be caused by varying widths of the Low going data bits in the serial data stream.
At 115200 bits/sec, the nominal bit width is 8.68us. Some of the Low going bits from the UART interface were down to 3us width.
The over all packet timing was correct, just the width of the low going bits varied.
So depending on when the receiving equipment clocks the data in, it may see either a "0" or "1"
This was solved by feeding the data through an external Pulse stretching circuit to set the minimum bit width correctly.
The second issue of no response to commands was tracked down to an open circuit on the PCB trace from the UART interface connection point.
The Data IN to the MSO5074 goes via a series resistor. This resistor had been left off the circuit board.
Since the resistor is mounted on the back of the board, this meant completely dismantling the unit to bridge the gap on the trace.
After solving these issues, using the UART interface to talk to the MSO5074 was straight forward.
I found that "U Boot" can be easily interrupted by holding a keyboard key down from when the MSO5074 is powered ON.
** Edit. Added Pulse stretching Circuit. **
Accidentally now of course ;)
So this doesn't look very much like a pulse that's not wide enough, but bits being shuffled ....
So this doesn't look very much like a pulse that's not wide enough, but bits being shuffled ....
So, is it serial port obfuscation (by port driver modding)?
If so, a custom terminal is needed.
Meanwhile, I can read 'just about enough' to debug stuff. I do have to take appart the scope to see if I'm missing the 0? oHm resistor.
@TopLoser, you are using serial extensively as is Dave; how come your scope is not suffering from this clock stretching need?
I do not have my scope open, but is it possible that there is a termination resistor missing in the design? If they were using a open drain output without a pull up, the leakage current from the receiving gate might make it appear to sort of work....
Just a thought...
Seems much more likely than a change in timing in the low bits.
Maybe somebody at Rigol has been Muntzing, try adding a 2k pullup to the line and see what happens (or maybe a pulldown...)
Indeed it makes sense but just because Rigol must have wanted to make it unaccessible...
Serial is disabled immediately after the 'Hit any key' prompt, so you can still enter uboot at that point. Not available when the scope is up and running though.
Their diagnostic/repair tools might have a pullup resistor in them so they figured they could save a couple of cents by Muntzing that.
Serial is disabled immediately after the 'Hit any key' prompt, so you can still enter uboot at that point. Not available when the scope is up and running though.
TopLoser, can you confirm that while on uboot you have serial output and it just disappears when the app is called?
U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
I2C: ready
Memory: ECC disabled
DRAM: 448 MiB
DPU: 20170604
NAND: OnDie ECC supported, 1024 MiB
zynq-In: serial
zynq-Out: serial
zynq-Err: serial
Net: Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot: 0
NAND read: device 0 offset 0xd900000, size 0x3591fd
Ÿ
U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
I2C: ready
Memory: ECC disabled
DRAM: 448 MiB
DPU: 20170604
NAND: OnDie ECC supported, 1024 MiB
zynq-In: serial
zynq-Out: serial
zynq-Err: serial
Net: Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot: 0
NAND read: device 0 offset 0x4900000, size 0x3591fd
þ
NAND read: device 0 offset 0x4900000, size 0x8
8 bytes read: OK
NAND read: device 0 offset 0x4500000, size 0x12c008
1228808 bytes read: OK
Loading logo, x=310,y=247,width=404,height=89
NAND read: device 0 offset 0x5100000, size 0xd8ebf0
14216176 bytes read: OK
## Loading kernel from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'kernel@1' kernel subimage
Description: Kerstrel Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x030000f8
Data Size: 3302448 Bytes = 3.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00100000
Entry Point: 0x00100000
Hash algo: sha1
Hash value: bece162e8cad943c68714d8eb8020d68e1db896b
Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'ramdisk@1' ramdisk subimage
Description: kerstrel-Update-Ramdisk
Type: RAMDisk Image
Compression: gzip compressed
Data Start: 0x03328c5c
Data Size: 10901113 Bytes = 10.4 MiB
Architecture: ARM
OS: Linux
Load Address: unavailable
Entry Point: unavailable
Hash algo: sha1
Hash value: 55bdcbebccba845da403130143793ee0135e53a1
Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'fdt@1' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x0332661c
Data Size: 9597 Bytes = 9.4 KiB
Architecture: ARM
Hash algo: sha1
Hash value: da2d17ba0d5a71b5897deec4cb026014f3132185
Verifying Hash Integrity ... sha1+ OK
Booting using the fdt blob at 0x332661c
Loading Kernel Image ... OK
Loading Ramdisk to 1b099000, end 1bafe679 ... OK
Loading Device Tree to 1b093000, end 1b09857c ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.12.0-xilinx (rigolee[member=167213]Jim[/member]) (gcc version 4.8.1 (Sourcery CodeBench Lite 2013.11-53) ) #43 SMP PREEMPT Sat Jul 28 12:14:01 CST 2018
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq
Memory policy: Data cache writealloc
PERCPU: Embedded 8 pages/cpu @c09f1000 s8384 r8192 d16192 u32768
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 113792
Kernel command line: console=ttyPS0,115200 no_console_suspend, root=/dev/ram rw
PID 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 16
ps7-slcr mapped to dc802000
Zynq clock init
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 1725.23 BogoMIPS (lpj=8626176)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0xc03fa6b8 - 0xc03fa710
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72360000, Cache size: 512 kB
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
gpio->base_addr is:0xdc84e000
The gpio irq num is:52
zynq_gpio e000a000.ps7-gpio: gpio at 0xe000a000 mapped to 0xdc84e000
hw-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 @ 0xdc880000
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti[member=183778]linux[/member].it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
NET: Registered protocol family 2
TCP 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 registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: 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 initrd
Freeing initrd memory: 10644K (db099000 - dbafe000)
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
NTFS driver 2.1.30 [Flags: R/W].
msgmni has been set to 875
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
DPU:Map vRam to 0xdca00000
DPU:Map iReg to 0xdcc00000
DPU:Ver=0x20170711
dma-pl330 f8003000.ps7-dma: unable to set the seg size
dma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-2364208
dma-pl330 f8003000.ps7-dma: DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 6249999) is a xuartps
console [ttyPS0] enabled
xuartps e0001000.serial: failed to get alias id, errno -19
e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 6249999) is a xuartps
brd: module loaded
loop: module loaded
xspips e0006000.ps7-spi: master is unqueued, this is deprecated
xspips e0006000.ps7-spi: at 0xE0006000 mapped to 0xDC858000, irq=58
libphy: XEMACPS mii bus: probed
xemacps e000b000.ps7-ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
xusbps-ehci xusbps-ehci.1: Xilinx PS USB EHCI Host Controller
xusbps-ehci xusbps-ehci.1: new USB bus registered, assigned bus number 1
xusbps-ehci xusbps-ehci.1: irq 76, io mem 0x00000000
xusbps-ehci xusbps-ehci.1: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-rx8010sj 0-0032: Update timer was detected
rtc-rx8010sj 0-0032: rtc core: registered rtc-rx8010sj as rtc0
input: Goodix-TS as /devices/virtual/input/input0
xi2cps e0004000.ps7-i2c: 90 kHz mmio e0004000 irq 57
zynq-edac f8006000.ps7-ddrc: ecc not enabled
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron MT29F8G08ADADAH4), 1024MiB, page size: 2048, OOB size: 64
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, version 0x01
13 ofpart partitions found on MTD device pl353-nand
Creating 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 registered
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
rtc-rx8010sj 0-0032: setting system clock to 2018-11-10 12:15:08 UTC (1541852108)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 176K (c05cf000 - c05fb000)
Starting rcS...
++ Mounting filesystem
++ Setting up mdev
++ Starting ftp daemon
rcS Complete
<root@rigol>rpcbind: cannot create socket for udp6
rpcbind: cannot create socket for tcp6
2018-11-10 12:15:21: (log.c.166) server started
7 2048 16 2 "/dev/fb0"
Mount user space to:/user
default setting by user set
Rigol Device gadget: Rigol Device ready
usbcore: registered new interface driver usbtmc
Serial is disabled immediately after the 'Hit any key' prompt, so you can still enter uboot at that point. Not available when the scope is up and running though.
TopLoser, can you confirm that while on uboot you have serial output and it just disappears when the app is called?
This where it stops:Code: [Select]U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
I2C: ready
Memory: ECC disabled
DRAM: 448 MiB
DPU: 20170604
NAND: OnDie ECC supported, 1024 MiB
zynq-In: serial
zynq-Out: serial
zynq-Err: serial
Net: Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot: 0
NAND read: device 0 offset 0xd900000, size 0x3591fd
Ÿ
Disabled before the kernel is loaded - compared to previous versions:Code: [Select]U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
I2C: ready
Memory: ECC disabled
DRAM: 448 MiB
DPU: 20170604
NAND: OnDie ECC supported, 1024 MiB
zynq-In: serial
zynq-Out: serial
zynq-Err: serial
Net: Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot: 0
NAND read: device 0 offset 0x4900000, size 0x3591fd
þ
NAND read: device 0 offset 0x4900000, size 0x8
8 bytes read: OK
NAND read: device 0 offset 0x4500000, size 0x12c008
1228808 bytes read: OK
Loading logo, x=310,y=247,width=404,height=89
NAND read: device 0 offset 0x5100000, size 0xd8ebf0
14216176 bytes read: OK
## Loading kernel from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'kernel@1' kernel subimage
Description: Kerstrel Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x030000f8
Data Size: 3302448 Bytes = 3.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00100000
Entry Point: 0x00100000
Hash algo: sha1
Hash value: bece162e8cad943c68714d8eb8020d68e1db896b
Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'ramdisk@1' ramdisk subimage
Description: kerstrel-Update-Ramdisk
Type: RAMDisk Image
Compression: gzip compressed
Data Start: 0x03328c5c
Data Size: 10901113 Bytes = 10.4 MiB
Architecture: ARM
OS: Linux
Load Address: unavailable
Entry Point: unavailable
Hash algo: sha1
Hash value: 55bdcbebccba845da403130143793ee0135e53a1
Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'fdt@1' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x0332661c
Data Size: 9597 Bytes = 9.4 KiB
Architecture: ARM
Hash algo: sha1
Hash value: da2d17ba0d5a71b5897deec4cb026014f3132185
Verifying Hash Integrity ... sha1+ OK
Booting using the fdt blob at 0x332661c
Loading Kernel Image ... OK
Loading Ramdisk to 1b099000, end 1bafe679 ... OK
Loading Device Tree to 1b093000, end 1b09857c ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.12.0-xilinx (rigolee[member=167213]Jim[/member]) (gcc version 4.8.1 (Sourcery CodeBench Lite 2013.11-53) ) #43 SMP PREEMPT Sat Jul 28 12:14:01 CST 2018
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq
Memory policy: Data cache writealloc
PERCPU: Embedded 8 pages/cpu @c09f1000 s8384 r8192 d16192 u32768
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 113792
Kernel command line: console=ttyPS0,115200 no_console_suspend, root=/dev/ram rw
PID 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 16
ps7-slcr mapped to dc802000
Zynq clock init
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 1725.23 BogoMIPS (lpj=8626176)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0xc03fa6b8 - 0xc03fa710
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72360000, Cache size: 512 kB
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
gpio->base_addr is:0xdc84e000
The gpio irq num is:52
zynq_gpio e000a000.ps7-gpio: gpio at 0xe000a000 mapped to 0xdc84e000
hw-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 @ 0xdc880000
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti[member=183778]linux[/member].it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
NET: Registered protocol family 2
TCP 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 registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: 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 initrd
Freeing initrd memory: 10644K (db099000 - dbafe000)
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
NTFS driver 2.1.30 [Flags: R/W].
msgmni has been set to 875
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
DPU:Map vRam to 0xdca00000
DPU:Map iReg to 0xdcc00000
DPU:Ver=0x20170711
dma-pl330 f8003000.ps7-dma: unable to set the seg size
dma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-2364208
dma-pl330 f8003000.ps7-dma: DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 6249999) is a xuartps
console [ttyPS0] enabled
xuartps e0001000.serial: failed to get alias id, errno -19
e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 6249999) is a xuartps
brd: module loaded
loop: module loaded
xspips e0006000.ps7-spi: master is unqueued, this is deprecated
xspips e0006000.ps7-spi: at 0xE0006000 mapped to 0xDC858000, irq=58
libphy: XEMACPS mii bus: probed
xemacps e000b000.ps7-ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
xusbps-ehci xusbps-ehci.1: Xilinx PS USB EHCI Host Controller
xusbps-ehci xusbps-ehci.1: new USB bus registered, assigned bus number 1
xusbps-ehci xusbps-ehci.1: irq 76, io mem 0x00000000
xusbps-ehci xusbps-ehci.1: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-rx8010sj 0-0032: Update timer was detected
rtc-rx8010sj 0-0032: rtc core: registered rtc-rx8010sj as rtc0
input: Goodix-TS as /devices/virtual/input/input0
xi2cps e0004000.ps7-i2c: 90 kHz mmio e0004000 irq 57
zynq-edac f8006000.ps7-ddrc: ecc not enabled
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron MT29F8G08ADADAH4), 1024MiB, page size: 2048, OOB size: 64
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, version 0x01
13 ofpart partitions found on MTD device pl353-nand
Creating 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 registered
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
rtc-rx8010sj 0-0032: setting system clock to 2018-11-10 12:15:08 UTC (1541852108)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 176K (c05cf000 - c05fb000)
Starting rcS...
++ Mounting filesystem
++ Setting up mdev
++ Starting ftp daemon
rcS Complete
<root@rigol>rpcbind: cannot create socket for udp6
rpcbind: cannot create socket for tcp6
2018-11-10 12:15:21: (log.c.166) server started
7 2048 16 2 "/dev/fb0"
Mount user space to:/user
default setting by user set
Rigol Device gadget: Rigol Device ready
usbcore: registered new interface driver usbtmc
Meanwhile, I can read 'just about enough' to debug stuff. I do have to take appart the scope to see if I'm missing the 0? oHm resistor.
Or, as I've hinted in the past, maybe the serial passes through the FPGA and something went bad in the latest programming.
If it was unintented, a bad recovery serial port is not something very pleasant to have...
So ... yes, I spend an hour taking it apart (I didn't realize it was such a painfull job TopLoser. Thank you for all your dissasemblies!!Seems much more likely than a change in timing in the low bits.
Maybe somebody at Rigol has been Muntzing, try adding a 2k pullup to the line and see what happens (or maybe a pulldown...)
Indeed it makes sense but just because Rigol must have wanted to make it unaccessible...
Olliver, what can you see in TopLoser's PCB images?
Edit: Oopsss! The photo is from TopLoser and he has the RES... Must disassemble yours.
Ok this is way way way before the kernel is even informed, and we already checked the environment. BUTSerial is disabled immediately after the 'Hit any key' prompt, so you can still enter uboot at that point. Not available when the scope is up and running though.
TopLoser, can you confirm that while on uboot you have serial output and it just disappears when the app is called?
This where it stops:Code: [Select]U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
I2C: ready
Memory: ECC disabled
DRAM: 448 MiB
DPU: 20170604
NAND: OnDie ECC supported, 1024 MiB
zynq-In: serial
zynq-Out: serial
zynq-Err: serial
Net: Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot: 0
NAND read: device 0 offset 0xd900000, size 0x3591fd
Ÿ
Disabled before the kernel is loaded - compared to previous versions:Code: [Select]U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
I2C: ready
Memory: ECC disabled
DRAM: 448 MiB
DPU: 20170604
NAND: OnDie ECC supported, 1024 MiB
zynq-In: serial
zynq-Out: serial
zynq-Err: serial
Net: Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot: 0
NAND read: device 0 offset 0x4900000, size 0x3591fd
þ
NAND read: device 0 offset 0x4900000, size 0x8
8 bytes read: OK
NAND read: device 0 offset 0x4500000, size 0x12c008
1228808 bytes read: OK
Loading logo, x=310,y=247,width=404,height=89
NAND read: device 0 offset 0x5100000, size 0xd8ebf0
14216176 bytes read: OK
## Loading kernel from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'kernel@1' kernel subimage
Description: Kerstrel Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x030000f8
Data Size: 3302448 Bytes = 3.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00100000
Entry Point: 0x00100000
Hash algo: sha1
Hash value: bece162e8cad943c68714d8eb8020d68e1db896b
Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'ramdisk@1' ramdisk subimage
Description: kerstrel-Update-Ramdisk
Type: RAMDisk Image
Compression: gzip compressed
Data Start: 0x03328c5c
Data Size: 10901113 Bytes = 10.4 MiB
Architecture: ARM
OS: Linux
Load Address: unavailable
Entry Point: unavailable
Hash algo: sha1
Hash value: 55bdcbebccba845da403130143793ee0135e53a1
Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 03000000 ...
Using 'rootfs@1' configuration
Trying 'fdt@1' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x0332661c
Data Size: 9597 Bytes = 9.4 KiB
Architecture: ARM
Hash algo: sha1
Hash value: da2d17ba0d5a71b5897deec4cb026014f3132185
Verifying Hash Integrity ... sha1+ OK
Booting using the fdt blob at 0x332661c
Loading Kernel Image ... OK
Loading Ramdisk to 1b099000, end 1bafe679 ... OK
Loading Device Tree to 1b093000, end 1b09857c ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.12.0-xilinx (rigolee[member=167213]Jim[/member]) (gcc version 4.8.1 (Sourcery CodeBench Lite 2013.11-53) ) #43 SMP PREEMPT Sat Jul 28 12:14:01 CST 2018
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq
Memory policy: Data cache writealloc
PERCPU: Embedded 8 pages/cpu @c09f1000 s8384 r8192 d16192 u32768
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 113792
Kernel command line: console=ttyPS0,115200 no_console_suspend, root=/dev/ram rw
PID 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 16
ps7-slcr mapped to dc802000
Zynq clock init
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 1725.23 BogoMIPS (lpj=8626176)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0xc03fa6b8 - 0xc03fa710
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72360000, Cache size: 512 kB
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
gpio->base_addr is:0xdc84e000
The gpio irq num is:52
zynq_gpio e000a000.ps7-gpio: gpio at 0xe000a000 mapped to 0xdc84e000
hw-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 @ 0xdc880000
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti[member=183778]linux[/member].it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
NET: Registered protocol family 2
TCP 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 registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: 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 initrd
Freeing initrd memory: 10644K (db099000 - dbafe000)
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
NTFS driver 2.1.30 [Flags: R/W].
msgmni has been set to 875
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
DPU:Map vRam to 0xdca00000
DPU:Map iReg to 0xdcc00000
DPU:Ver=0x20170711
dma-pl330 f8003000.ps7-dma: unable to set the seg size
dma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-2364208
dma-pl330 f8003000.ps7-dma: DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 6249999) is a xuartps
console [ttyPS0] enabled
xuartps e0001000.serial: failed to get alias id, errno -19
e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 6249999) is a xuartps
brd: module loaded
loop: module loaded
xspips e0006000.ps7-spi: master is unqueued, this is deprecated
xspips e0006000.ps7-spi: at 0xE0006000 mapped to 0xDC858000, irq=58
libphy: XEMACPS mii bus: probed
xemacps e000b000.ps7-ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
xusbps-ehci xusbps-ehci.1: Xilinx PS USB EHCI Host Controller
xusbps-ehci xusbps-ehci.1: new USB bus registered, assigned bus number 1
xusbps-ehci xusbps-ehci.1: irq 76, io mem 0x00000000
xusbps-ehci xusbps-ehci.1: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-rx8010sj 0-0032: Update timer was detected
rtc-rx8010sj 0-0032: rtc core: registered rtc-rx8010sj as rtc0
input: Goodix-TS as /devices/virtual/input/input0
xi2cps e0004000.ps7-i2c: 90 kHz mmio e0004000 irq 57
zynq-edac f8006000.ps7-ddrc: ecc not enabled
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron MT29F8G08ADADAH4), 1024MiB, page size: 2048, OOB size: 64
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, version 0x01
13 ofpart partitions found on MTD device pl353-nand
Creating 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 registered
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
rtc-rx8010sj 0-0032: setting system clock to 2018-11-10 12:15:08 UTC (1541852108)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 176K (c05cf000 - c05fb000)
Starting rcS...
++ Mounting filesystem
++ Setting up mdev
++ Starting ftp daemon
rcS Complete
<root@rigol>rpcbind: cannot create socket for udp6
rpcbind: cannot create socket for tcp6
2018-11-10 12:15:21: (log.c.166) server started
7 2048 16 2 "/dev/fb0"
Mount user space to:/user
default setting by user set
Rigol Device gadget: Rigol Device ready
usbcore: registered new interface driver usbtmc
They already set the PS0's pinmux configuration to PL and assign it to zero by Zynq bitstream in the new firmware. It is easy to work around, just an ordinary anti-hack trick.
Solder the RES and that part will be solved.For the data going into the scope; but getting data out of the scope still requires some magic :(
oliv3r.
I put a solder bridge across the PCB traces where the resistor is missing and then used an external 560 ohm resistor in series with the data line as a precaution.
This value of resistor had no effect on the amplitude or shape of the data bits going into the MSO5000.
Regards.
Solder the RES and that part will be solved.For the data going into the scope; but getting data out of the scope still requires some magic :(
Hello! I do not understand - any Rigol mso 5xxx is unlocked. Or is it necessary to buy a four channel? (5074/72)
Thanks for the quick response. Now it is clear. 4 probes - there is something to think about. |
Current best practice:
First: You will perform a series of upgrades. These have to be done using the help menu and the DS5000Update.GEL filename. The files you download here have a .txt extension. Remove it and rename it to the proper name. Attention, Windows might just hide the .txt extension! Make sure to properly unmount your USB drive, and that there is free space left on it (<50MB).
Now:
- Note your current software version down. If it is older than 01.01.04.04 you will need to upgrade.
- Backup your scope specific data such as calibration values. Get the DS5000Update_backup.GEL.txt from here. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2251380/#msg2251380) Rename to DS5000Update.GEL and put it on a USB drive. Execute an upgrade using the help menu in your scope, NOT the secret menu. You will see the scope doing a backup. Unplug the stick and make sure you have a backup in the data_backup folder on the stick.
- If you have an older version of the firmware, download 01.01.04.04 from here (https://gitlab.com/riglol/rigolee/blob/MSO5000/GEL/DS5000Update_01.01.04.04.GEL). Also rename it to DS5000Update.GEL, put it on your usb drive, and upgrade.
- Make sure you are on the 01.01.04.04 firmware in the about dialog.
- Patch the scope to have all licenses. For that download the patch from here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2235282/#msg2235282). Again rename and copy to usb drive. This time the upgrade might take a bit longer, it should ask you to reboot, if not something failed, but it is probably not fatal for your scope, no worries. Reboot.
- Check that all licences are activated.
- If you want, do an auto calibration and check that everything is still okay.
You can get temporary SSH access by executing this upgrade (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076). The upgrade will "fail", but you will have ssh until reboot. You can use this to fix your calibration data, if truly required.
Is there a simple way to deactivate this hack ?
Is there a USB stick to automatically switch between the two firmwares in the machine?
That would be cool for testing things.
Thank you very much for your explenation how to crack the password from hash. I downloaded hashcat and tryed it on my machine:Which password is this?20 minutes with hashcat on a radeon hd7900 -> Rigol201 :-DD
root:qkiAP.hEBSnSY:0:0:root:/root:/bin/sh
for those interested. researching this took longer then 20mins ;-) linux seems to use DES by default for encrypting passwords. 13 chars and no $-signs point to using that default. i copied the hash part into a file (rigol.hash) and here's the command i used for hashcat:Code: [Select]hashcat64.exe -a 3 -m 1500 rigol.hash
qkiAP.hEBSnSY:Rigol201
Session..........: hashcat
Status...........: Cracked
Hash.Type........: descrypt, DES (Unix), Traditional DES
Hash.Target......: qkiAP.hEBSnSY
Time.Started.....: Sat Apr 20 01:34:19 2019 (2 mins, 38 secs)
Time.Estimated...: Sat Apr 20 01:36:57 2019 (0 secs)
Guess.Mask.......: ?1?2?2?2?2?2?2?3 [8]
Guess.Charset....: -1 ?l?d?u, -2 ?l?d, -3 ?l?d*!$@_, -4 Undefined
Guess.Queue......: 8/8 (100.00%)
Speed.#1.........: 876.7 MH/s (11.41ms) @ Accel:2 Loops:1024 Thr:256 Vec:1
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 139148328960/5533380698112 (2.51%)
Rejected.........: 0/139148328960 (0.00%)
Restore.Point....: 1730560/68864256 (2.51%)
Restore.Sub.#1...: Salt:0 Amplifier:8192-9216 Iteration:0-1024
Candidates.#1....: lnitsorl -> Lurghbou
Hardware.Mon.#1..: Temp: 77c Fan: 60% Util: 97% Core:1898MHz Mem:4513MHz Bus:16
Started: Sat Apr 20 01:31:31 2019
Stopped: Sat Apr 20 01:36:58 2019
It took only 5 minutes on an i7-8700K with GTX 1080.
deleted: firmware/env.cmd
modified: firmware/fw4linux.sh
modified: firmware/fw4uboot.sh
modified: firmware/kerstrel.dts
deleted: firmware/kerstrel.its
modified: firmware/rootfs/rigol/K160M_TOP.bit
modified: firmware/rootfs/rigol/appEntry
modified: firmware/rootfs/rigol/mail/etc/Muttrc
modified: firmware/rootfs/rigol/mail/etc/msmtprc
modified: firmware/rootfs/rigol/resource/appmeta.xml
modified: firmware/rootfs/rigol/resource/dsometa.xml
modified: firmware/rootfs/rigol/resource/help/b/cursor.hlp
modified: firmware/rootfs/rigol/resource/help/b/display.hlp
modified: firmware/rootfs/rigol/resource/help/b/eyejit.hlp
modified: firmware/rootfs/rigol/resource/help/b/help.hlp
modified: firmware/rootfs/rigol/resource/help/b/la.hlp
modified: firmware/rootfs/rigol/resource/help/b/quick.hlp
modified: firmware/rootfs/rigol/resource/help/b/ref.hlp
modified: firmware/rootfs/rigol/resource/help/b/storage.hlp
modified: firmware/rootfs/rigol/resource/help/b/trigger.hlp
modified: firmware/rootfs/rigol/resource/help/b/utility.hlp
modified: firmware/rootfs/rigol/resource/help/b/vdecode.hlp
modified: firmware/rootfs/rigol/resource/help/d/eyejit.hlp
modified: firmware/rootfs/rigol/resource/help/d/help.hlp
modified: firmware/rootfs/rigol/resource/help/d/quick.hlp
modified: firmware/rootfs/rigol/resource/help/d/trigger.hlp
modified: firmware/rootfs/rigol/resource/menu/b.hex
modified: firmware/rootfs/rigol/resource/menu/c.hex
modified: firmware/rootfs/rigol/resource/menu/d.hex
modified: firmware/rootfs/rigol/resource/menu/desc.hex
modified: firmware/rootfs/rigol/resource/menu/h.hex
modified: firmware/rootfs/rigol/resource/menu/i.hex
modified: firmware/rootfs/rigol/resource/menu/j.hex
modified: firmware/rootfs/rigol/resource/menu/k.hex
modified: firmware/rootfs/rigol/resource/menu/l.hex
modified: firmware/rootfs/rigol/resource/menu/m.hex
modified: firmware/rootfs/rigol/resource/menu/menu.hex
modified: firmware/rootfs/rigol/resource/menu/modelconfig_ch.hex
modified: firmware/rootfs/rigol/resource/menu/modelconfig_ext.hex
modified: firmware/rootfs/rigol/resource/menu/msg.h
modified: firmware/rootfs/rigol/resource/menu/n.hex
modified: firmware/rootfs/rigol/resource/menu/o.hex
modified: firmware/rootfs/rigol/resource/menu/res.hex
modified: firmware/rootfs/rigol/resource/menu/t.hex
modified: firmware/rootfs/rigol/resource/menu/u.hex
modified: firmware/rootfs/rigol/resource/scpi/ACQuire.xml
modified: firmware/rootfs/rigol/resource/scpi/BUS1.xml
modified: firmware/rootfs/rigol/resource/scpi/BUS2.xml
modified: firmware/rootfs/rigol/resource/scpi/BUS3.xml
modified: firmware/rootfs/rigol/resource/scpi/BUS4.xml
modified: firmware/rootfs/rigol/resource/scpi/CALibration.xml
modified: firmware/rootfs/rigol/resource/scpi/CHANnel1.xml
modified: firmware/rootfs/rigol/resource/scpi/CHANnel2.xml
modified: firmware/rootfs/rigol/resource/scpi/CHANnel3.xml
modified: firmware/rootfs/rigol/resource/scpi/CHANnel4.xml
modified: firmware/rootfs/rigol/resource/scpi/JITTer.xml
modified: firmware/rootfs/rigol/resource/scpi/MATH1.xml
modified: firmware/rootfs/rigol/resource/scpi/MATH2.xml
modified: firmware/rootfs/rigol/resource/scpi/MATH3.xml
modified: firmware/rootfs/rigol/resource/scpi/MATH4.xml
modified: firmware/rootfs/rigol/resource/scpi/SEARch.xml
modified: firmware/rootfs/rigol/resource/scpi/SYSTem.xml
modified: firmware/rootfs/rigol/resource/scpi/TIMebase.xml
modified: firmware/rootfs/rigol/resource/scpi/TRIGger.xml
modified: firmware/rootfs/rigol/resource/scpi/scpiConfig.xml
modified: firmware/rootfs/rigol/shell/send_mail.sh
modified: firmware/rootfs/rigol/webcontrol/lib/libpcre.so.0.0.1
modified: firmware/rootfs/rigol/webcontrol/lib/libpcrecpp.so.0.0.0
modified: firmware/rootfs/rigol/webcontrol/lib/libpcreposix.so.0.0.0
modified: firmware/rootfs/rigol/webcontrol/lib/libz.so.1.2.7
modified: firmware/rootfs/rigol/webcontrol/sbin/lighttpd
modified: firmware/rootfs/rigol/webcontrol/sbin/lighttpd-angel
modified: firmware/zImage
modified: firmware/zynq.bit
Looking at the disassambled appEntry file, it looks to me like it's only able to start a ssh and ftp daemon, but not to stop any of them.
I'm not sure how to start it though. The start command is close to other UI stuff, and the string "Enter Project mode" is used close to it. I could imagine there is something like a maintenance menu we don't know about yet.
Do you have more info on that vendor disk?
:D You didn't complete your homework...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2064766/#msg2064766 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2064766/#msg2064766)
UPS dropped mine off today. I got a 5072. Within about 5 minutes of opening it, I had all options.
Thanks Mabl and company for the hard work to make hacking this thing easy.
Does that include a bandwidth upgrade? If so, to what level?Full (350 MHz)
UPS dropped mine off today. I got a 5072. Within about 5 minutes of opening it, I had all options.
Thanks Mabl and company for the hard work to make hacking this thing easy.
I emailed rigol support and they said this feature is not available to North America. I don't understand why this would be the case.Tariffs war? :)
If I go to measurement, analysis, and jitter analysis. In PLL mode with a 1MHz FM modulated 10MHz carrier my scope freezes.
I emailed rigol support and they said this feature is not available to North America. I don't understand why this would be the case.
Isn't Jitter measurement part of the power analysis feature, opened by the hack?
Isn't Jitter measurement part of the power analysis feature, opened by the hack?
Why would jitter measurements be in power analysis?Maybe to analyze switching power supplies?
Jitter measurements are clock/ timing related, for digital clocks and serial communications and such.
Not much to do with power measurements.
It makes sense to be connected with histograms though.
If I go to measurement, analysis, and jitter analysis. In PLL mode with a 1MHz FM modulated 10MHz carrier my scope freezes.
I emailed rigol support and they said this feature is not available to North America. I don't understand why this would be the case.
Can anyone else replicate, confirm, or offer advice?
If I go to measurement, analysis, and jitter analysis. In PLL mode with a 1MHz FM modulated 10MHz carrier my scope freezes.
I emailed rigol support and they said this feature is not available to North America. I don't understand why this would be the case.
Can anyone else replicate, confirm, or offer advice?
Hi Angelo
Mine to, however I am located in the UK, also purchased power analysis option with the scope.
The hack worked fine thank you chaps 8)
Every time I use the jitter feature (tie mode) and switch in jitter spectrum it freezes, also when using the jitter trend mode it runs for around a couple of minutes then locks up
The scope locks up in normal and high res modes as well
All other features are fine more than likely a firmware issue that has missed the beta testers at Rigol?
I'd be interested to hear if anyone does get this feature operational, or can confirm that it is bugged, or that it is non functional but option is just enabled in the 5000 hack.You can just remove the hack and verify it yourself
I'd be interested to hear if anyone does get this feature operational, or can confirm that it is bugged, or that it is non functional but option is just enabled in the 5000 hack.You can just remove the hack and verify it yourself
You are correct. I misunderstood your question.I'd be interested to hear if anyone does get this feature operational, or can confirm that it is bugged, or that it is non functional but option is just enabled in the 5000 hack.You can just remove the hack and verify it yourself
I'm sure that it will go away if disable the hack.
What I meant was, perhaps my settings/test is bugged and the feature works. Or, perhaps it just shows up but will never work.
I got mine yesterday - MSO5354.
Why, when you already got the DS7014 (https://www.eevblog.com/forum/testgear/new-rigol-ds7000/msg2414466/#msg2414466) ?
I installed this and it seems to have worked perfectly, with one exception. I cannot get the probe to compensate correctly on channel 1. On the other 3 channels I can get the probe compensated, but Channel 1 has a hump above the peak of the square wave regardless of the probe I use. Is this something wrong with the scope, or something wrong with the hack? Should I roll back to the non-hacked version? I'm not entirely sure how to resolve this.
Thanks,
Steven
It should be fixed in the next firmware version: https://www.eevblog.com/forum/blog/new-rigol-scope/msg2366808/#msg2366808 (https://www.eevblog.com/forum/blog/new-rigol-scope/msg2366808/#msg2366808)
Will they allow users change the resistors and honor the factory warranty?
Any word on how they intend to handle existing units with what appears to be a manufacturing/design fault?
I got one MSO5074.
I though I can dump many times with high bandwidth for data aquctation.
but it's not possible.
If you send it in, it might come back with some new firmware that is not hackable...
Dear All,
a little help to a novice: I flashed 01.01.04.04 on my MSO5074 and while I can ping the scope, ssh gives me "connection refused"... anyone has experienced this?
Interesting you only have one bandwidth upgrade installed tv84.
How could that have happened?!
Interesting you only have one bandwidth upgrade installed tv84.
How could that have happened?!
"One option to rule them all..." ;)
That's the first thing I replaced, they are very tight and a pain to pull off.
I got in my MSO5000. Seems to work well. Mfg date was 20 Feb 2019. HW 01.00.000 FW 00.01.01.04.04 Screen is nice and bright. Fan is nice and quiet.I think you are not handling them correctly... if you push the probe BNC in (it has a spring mechanism), then rotates very easily.
Only complaint is the rubber boots on the probe BNCs. They like to rotate without turning the BNC shell... makes it a pain to attach / remove the probes.
I think you are not handling them correctly... if you push the probe BNC in (it has a spring mechanism), then rotates very easily.
Just to make sure I understand correctly. I can upgrade the MSO 5072 to a MSO 5354 with the procedure mentioned in this thread?
Do I also unlock the function generator?
mabl's summary of best practices, with helpful links, worked a treat
Ahh I'm so envious. I so wonder what the differences are between the two hardware revisions. DAAaavveeee tear another one down and compare it for us :DInteresting you only have one bandwidth upgrade installed tv84.
How could that have happened?!
"One option to rule them all..." ;)
Looking at the questions from myself and others. How about we add some information into the starting post of this thread? Then we have a central place. Of course it takes some time to keep it up to date, but on the other hands, people wouldn't need to search through the whole thread.Wish it where so easy, the original author is long gone and awol, and I yet have to receive a pull request on https://gitlab.com/riglol/rigolee or an update on the wiki https://gitlab.com/riglol/rigolee/wikis/home
I was hoping a moderator could add the stuff with a notification like "Added by moderator" or something.Looking at the questions from myself and others. How about we add some information into the starting post of this thread? Then we have a central place. Of course it takes some time to keep it up to date, but on the other hands, people wouldn't need to search through the whole thread.Wish it where so easy, the original author is long gone and awol, and I yet have to receive a pull request on https://gitlab.com/riglol/rigolee or an update on the wiki https://gitlab.com/riglol/rigolee/wikis/home
While I admit I have been tardy (not, just super busy :p) I'll pick up on the subject again once I have more time.
I'm still waiting for someone to share the exact value of the resistor of the uart TX line, so I can solder that :) and I've almost started playing with my FPGA board again, trying to write some code helping to identify the pin used by the uart's RX.
Starting from today, as soon as I connect the LAN cable and boot up the oscilloscope it stops reacting to any input after around 7 seconds.
- I tried it a couple of times, without LAN(with internet) connected, the oscilloscope works fine.
- But WITH LAN connected, it stops reacting to the touch screen, buttons and knobs after around 5-7 seconds.
- It seems like the oscilloscope is deactivating itself because it checks with a server and figures out it got hacked.
- It worked fine yesterday.
I'm using the DS5000Update_01.01.04.04.GEL firmware
Did anybody else notice that?
But WITH LAN connected, it stops reacting to the touch screen, buttons and knobs after around 5-7 seconds.
Hi,Ah, ok, thanks for the reliefQuoteBut WITH LAN connected, it stops reacting to the touch screen, buttons and knobs after around 5-7 seconds.
Have a look:
https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/msg2518821/#msg2518821 (https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/msg2518821/#msg2518821)
https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/msg2521134/#msg2521134 (https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/msg2521134/#msg2521134)
Martin
Hi people. The site https://cn.rigol.com/Support/SoftDownload/3 (https://cn.rigol.com/Support/SoftDownload/3) has a new firmware MSO5000_00.01.01.04.08. Good luck to all.
v00.01.01.04.08 2019/08/02
-Fixed system crashed when clicking Default.
-Fixed 4CH option bug.
-Fixed noise signal captured.
-Improved the measure result updating rate.
-Fixed accurate measurements not updated in ROLL
Not a big upgrade from the notes, no bode plot or high-res fixes.
Enhancements "patch" not working with 04.08
Good to know, as the install instruction doc states that firmware cannot be downgraded.
#echo "++ Starting telnet daemon"
#telnetd -l /bin/sh
#echo "++ Starting http daemon"
#httpd -h /var/www
#echo "++ Starting ftp daemon"
#tcpsvd 0:21 ftpd ftpd -w /&
#echo "++ Starting ssh daemon"
#/usr/sbin/sshd
Interesting that the K160 FPGA programming is the same as in the MSO8000 FW released a few days ago.
MSO5000_00.01.01.04.08:
Interesting that the K160 FPGA programming is the same as in the MSO8000 FW released a few days ago.
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: firmware/fw4linux.sh
modified: firmware/fw4uboot.sh
deleted: firmware/kerstrel.config
deleted: firmware/kerstrel.dts
modified: firmware/logo.png
modified: firmware/rootfs/rigol/appEntry
modified: firmware/rootfs/rigol/default/cal.hex
modified: firmware/rootfs/rigol/drivers/usbtmc_dev.ko
modified: firmware/rootfs/rigol/resource/appmeta.xml
modified: firmware/rootfs/rigol/resource/boardmeta.xml
modified: firmware/rootfs/rigol/resource/dsometa.xml
deleted: firmware/rootfs/rigol/resource/satable/hori_2g/100K
deleted: firmware/rootfs/rigol/resource/satable/hori_2g/10K
deleted: firmware/rootfs/rigol/resource/satable/hori_2g/10M
deleted: firmware/rootfs/rigol/resource/satable/hori_2g/1K
deleted: firmware/rootfs/rigol/resource/satable/hori_2g/1M
deleted: firmware/rootfs/rigol/resource/satable/hori_2g/25M
deleted: firmware/rootfs/rigol/resource/satable/hori_2g/50M
deleted: firmware/rootfs/rigol/resource/satable/hori_2g/AUTO
deleted: firmware/rootfs/rigol/resource/satable/hori_4g/100K
deleted: firmware/rootfs/rigol/resource/satable/hori_4g/100M
deleted: firmware/rootfs/rigol/resource/satable/hori_4g/10K
deleted: firmware/rootfs/rigol/resource/satable/hori_4g/10M
deleted: firmware/rootfs/rigol/resource/satable/hori_4g/1K
deleted: firmware/rootfs/rigol/resource/satable/hori_4g/1M
deleted: firmware/rootfs/rigol/resource/satable/hori_4g/25M
deleted: firmware/rootfs/rigol/resource/satable/hori_4g/50M
deleted: firmware/rootfs/rigol/resource/satable/hori_4g/AUTO
deleted: firmware/rootfs/rigol/resource/satable/hori_8g/100K
deleted: firmware/rootfs/rigol/resource/satable/hori_8g/100M
deleted: firmware/rootfs/rigol/resource/satable/hori_8g/10K
deleted: firmware/rootfs/rigol/resource/satable/hori_8g/10M
deleted: firmware/rootfs/rigol/resource/satable/hori_8g/1K
deleted: firmware/rootfs/rigol/resource/satable/hori_8g/1M
deleted: firmware/rootfs/rigol/resource/satable/hori_8g/200M
deleted: firmware/rootfs/rigol/resource/satable/hori_8g/25M
deleted: firmware/rootfs/rigol/resource/satable/hori_8g/50M
deleted: firmware/rootfs/rigol/resource/satable/hori_8g/AUTO
modified: firmware/rootfs/rigol/resource/scpi/SYSTem.xml
modified: firmware/rootfs/rigol/shell/start.sh
modified: firmware/rootfs/rigol/tools/spi2cpld
modified: firmware/rootfs/rigol/tools/spi2dev
modified: firmware/rootfs/rigol/tools/spi2k7
modified: firmware/rootfs/rigol/tools/spi2pll
modified: firmware/rootfs/rigol/webcontrol/lib/libpcre.a
modified: firmware/rootfs/rigol/webcontrol/lib/libpcrecpp.a
modified: firmware/rootfs/rigol/webcontrol/lib/libpcreposix.a
modified: firmware/rootfs/rigol/webcontrol/lib/libz.a
modified: firmware/rootfs/rigol/webcontrol/webpages/Help.html
modified: firmware/rootfs/rigol/webcontrol/webpages/images/1.jpg
modified: firmware/zImage
modified: firmware/zynq.bit
Untracked files:
(use "git add <file>..." to include in what will be committed)
GEL/DS8000Update_00.01.01.00.00.GEL
firmware/rootfs/rigol/cups/testPage.bmp
firmware/rootfs/rigol/resource/satable/hori_10g/
firmware/rootfs/rigol/resource/satable/hori_20g/
firmware/rootfs/rigol/resource/satable/hori_2_5g/
firmware/rootfs/rigol/resource/satable/hori_5g/
firmware/rootfs/rigol/resource/satable/hori_5g_100m/
firmware/unknown.config
firmware/unknown.dts
Just a heads up. On a hacked latest firmware the Jitter analysis works :popcorn: (Did not get eye to work though.)
I leave it to others to prepare a general auto patcher this time, though. >:D
Remember, that jitter feature is not officially part of the MSO5000.
Would you mind posting some images for this in actual operation, mine always crashes after 60 or so seconds then freezes requiring a hard reset.
So the previous patch for SSH should work on the new firmware. Can anyone confirm that?
Following mabl's lead, all that would be necessary to update the .GEL patch with a new appEntry_01_01_04_04.patch.gz file which locates the same code fragment in the updated appEntry. Then repack...
Remember, that jitter feature is not officially part of the MSO5000. The patch just blindly enables all features there are, I rigged up a simple test with the internal wave generator and firmware 01.01.04.08. See attached file. It feels stable. I guess they invested some effort for the MSO8000 launch and we just profit from that . Also auto baud rate detection works rather well.
I just don't want to commit mass copy right infringements anymore :-\
I will say, the hardware rev should have the fan fix but it's also infrequently emitting a really high pitch whine that's driving me mad and I'm going to have to replace it. The joys of being on the younger side to hear it.
I will say, the hardware rev should have the fan fix but it's also infrequently emitting a really high pitch whine that's driving me mad and I'm going to have to replace it. The joys of being on the younger side to hear it.
I'm not sure what you imagine happens to people's hearing as they age, but it's not true.
(unless you frequently go to too-loud places without hearing protection)
I incidentally had to delivered to work, all the old guys around me couldn't hear it. Who knows, maybe they lived through the time less OSHA regulations quite well heh
I'm not sure what you imagine happens to people's hearing as they age, but it's not true.
(unless you frequently go to too-loud places without hearing protection)
Agreed on the hearing part.
But back to the subject at hand, thm_w and delfinom have given us the clue to us firmware neophytes in #1151 and #1152, along with the work mabl and others provided in the last release - THANK YOU!
delfinom, to make use of your tar file, do I untar, change name to appEntry (by removing the version number behind it) and follow the last three steps in thm_w procedure?
Thanks.
I'm not sure what you imagine happens to people's hearing as they age, but it's not true.The only thing worse than aging is denying it while you do it. Or maybe not aging at all is worst.
(unless you frequently go to too-loud places without hearing protection)
I'm not sure what you imagine happens to people's hearing as they age, but it's not true.The only thing worse than aging is denying it while you do it. Or maybe not aging at all is worst.
(unless you frequently go to too-loud places without hearing protection)
Wondering if it is happening to everyone or just some unlucky individuals.I use firmware 04.08 without patch. My scope is always connected to LAN and boots flawless. Previously I had patched firmware 04.04 and LAN connected while booting also without problems.
The new firmware upgrade went well, except now when I boot the scope with the LAN cable attached, it freezes solid a couple seconds after it completes the boot. It will not respond to any button inputs, the only way to fix it is to reboot with out a LAN cable attached.No issues here. The patch does not touch any section of the program that is involved in networking.
If I boot without the LAN cable attached, everything is fine. I can attached the LAN after boot, no problem, it connects to the LAN properly and gets an IP address.
The problem began when I finished all the steps required for the "patch", my appEntry has the right MD5 checksum, I copy it back to the rigol directory, did a sync, reboot, and that's when the freeze began occurring. I have downgraded back to the 04_04 version, the problem persists now in 04_04, 04_08, with and without "patch" in both versions.
Does anyone has an idea of a fix or what to look for?
BTW, I have noticed that there are a couple posts here with similar problem even prior to 04.08, as well as a couple incidents in the MSO5000 bug topic. Wondering if it is happening to everyone or just some unlucky individuals.
Thanks in advance.
Is it the law or are people allowed to vary? According to that I shouldn't be able to hear much above 8kHz but that's definitely not true. I just did quick test and I can hear up to about 13.5kHz, no problem. Starts to get iffy around 14kHz.The exact numbers vary as with any biological process. In the end it's aging and we know there's no escaping that.
Maybe I could maybe rephrase the original statement though. It's probably true in general.
No issues here. The patch does not touch any section of the program that is involved in networking.
You don't have any IVI/LXI/lan control utilities running on your PC(s) on the same network do you? They may be scanning and picking up the scope on boot and triggering it into remote mode/locking the input.
Solved thanks to thm_w ,delfinom ,mabl
attached files for windows and how i've done it:)
appEntry file not included . you can always update this attachement and share it with others
Good luck
Solved thanks to thm_w ,delfinom ,mabl
attached files for windows and how i've done it:)
appEntry file not included . you can always update this attachement and share it with others
Good luck
Hey Delfinom and timber23,
Thanks for your quick responses. I don't have anything running on my PC for remote control, but I will try it later today with the computer off just to be sure. I will do another test to attach it to another router that is not connected to anything else to see how it reacts.
Update: Definitely odd behavior, when I connect it to a Cisco router that is not attached to anything, it works fine. It gets an IP address from the router, my next test would be trying to identify whether it is something in my LAN or the WAN that's causing the hang. It may help those who are dealing with the same problem.No issues here. The patch does not touch any section of the program that is involved in networking.
You don't have any IVI/LXI/lan control utilities running on your PC(s) on the same network do you? They may be scanning and picking up the scope on boot and triggering it into remote mode/locking the input.
The plot thickens. I did more test on the freeze problem, and I discovered the following:
* If router is not attached to anything, machine boots fine.
* If router is not connected to the Internet, but connected to all my local resources, machine boots fine. So nothing on my local network is trying to issue remote control to the scope.
* Once I connect the router to the Internet, machine hangs a few seconds after boot up, just around the time the "Online Update" button flashes on.
My local network is firewalled from external access, so it cannot be someone on the Internet trying to take over my scope via remote control. The action must be initiated from my scope, and the only thing I can think of is it tries to connect back to Rigol to check for online updates even without pressing the button. And something went wrong and cause the scope to hang. It may be due to the fact that rigolna still only has the 04_04 upgrade, and the scope cannot deal with a version higher than the version from the rigolna site. Not sure, but at least I think I might have found a probable trigger condition for the hang.
Strange thing is it does not occur to everyone, very odd indeed.Hey Delfinom and timber23,
Thanks for your quick responses. I don't have anything running on my PC for remote control, but I will try it later today with the computer off just to be sure. I will do another test to attach it to another router that is not connected to anything else to see how it reacts.
Update: Definitely odd behavior, when I connect it to a Cisco router that is not attached to anything, it works fine. It gets an IP address from the router, my next test would be trying to identify whether it is something in my LAN or the WAN that's causing the hang. It may help those who are dealing with the same problem.No issues here. The patch does not touch any section of the program that is involved in networking.
You don't have any IVI/LXI/lan control utilities running on your PC(s) on the same network do you? They may be scanning and picking up the scope on boot and triggering it into remote mode/locking the input.
ACQuire:AVERages
ACQuire:AVERages?
ACQuire:MDEPth
ACQuire:MDEPth?
ACQuire:SRATe?
ACQuire:LA:SRATe?
ACQuire:LA:MDEPth?
ACQuire:TYPE
ACQuire:TYPE?
ACQuire:AALias
ACQuire:AALias?
ACQuire:INTerleave
ACQuire:INTerleave?
BUS1:MODE
BUS1:MODE?
BUS1:DISPlay
BUS1:DISPlay?
BUS1:FORMat
BUS1:FORMat?
BUS1:EVENt
BUS1:EVENt?
BUS1:EVENt:FORMat
BUS1:EVENt:FORMat?
BUS1:EVENt:VIEW
BUS1:EVENt:VIEW?
BUS1:LABel
BUS1:LABel?
BUS1:EEXPort
BUS1:DATA?
BUS1:POSition
BUS1:POSition?
BUS1:THReshold
BUS1:THReshold?
BUS1:PARallel:CLK
BUS1:PARallel:CLK?
BUS1:PARallel:SLOPe
BUS1:PARallel:SLOPe?
BUS1:PARallel:BUS
BUS1:PARallel:BUS?
BUS1:PARallel:WIDTh
BUS1:PARallel:WIDTh?
BUS1:PARallel:BITX
BUS1:PARallel:BITX?
BUS1:PARallel:SOURce
BUS1:PARallel:SOURce?
BUS1:PARallel:POLarity
BUS1:PARallel:POLarity?
BUS1:PARallel:NREJect
BUS1:PARallel:NREJect?
BUS1:PARallel:NRTime
BUS1:PARallel:NRTime?
BUS1:RS232:TX
BUS1:RS232:TX?
BUS1:RS232:RX
BUS1:RS232:RX?
BUS1:RS232:POLarity
BUS1:RS232:POLarity?
BUS1:RS232:ENDian
BUS1:RS232:ENDian?
BUS1:RS232:BAUD
BUS1:RS232:BAUD?
BUS1:RS232:BUSer
BUS1:RS232:BUSer?
BUS1:RS232:DBITs
BUS1:RS232:DBITs?
BUS1:RS232:SBITs
BUS1:RS232:SBITs?
BUS1:RS232:PARity
BUS1:RS232:PARity?
BUS1:RS232:PACKet
BUS1:RS232:PACKet?
BUS1:RS232:PEND
BUS1:RS232:PEND?
BUS1:IIC:SCLK:SOURce
BUS1:IIC:SCLK:SOURce?
BUS1:IIC:SDA:SOURce
BUS1:IIC:SDA:SOURce?
BUS1:IIC:ADDRess
BUS1:IIC:ADDRess?
BUS1:SPI:SCLK:SOURce
BUS1:SPI:SCLK:SOURce?
BUS1:SPI:SCLK:SLOPe
BUS1:SPI:SCLK:SLOPe?
BUS1:SPI:MISO:SOURce
BUS1:SPI:MISO:SOURce?
BUS1:SPI:MISO:POLarity
BUS1:SPI:MISO:POLarity?
BUS1:SPI:MOSI:SOURce
BUS1:SPI:MOSI:SOURce?
BUS1:SPI:MOSI:POLarity
BUS1:SPI:MOSI:POLarity?
BUS1:SPI:DBITs
BUS1:SPI:DBITs?
BUS1:SPI:ENDian
BUS1:SPI:ENDian?
BUS1:SPI:MODE
BUS1:SPI:MODE?
BUS1:SPI:TIMeout:TIME
BUS1:SPI:TIMeout:TIME?
BUS1:SPI:SS:SOURce
BUS1:SPI:SS:SOURce?
BUS1:SPI:SS:POLarity
BUS1:SPI:SS:POLarity?
BUS1:CAN:SOURce
BUS1:CAN:SOURce?
BUS1:CAN:STYPe
BUS1:CAN:STYPe?
BUS1:CAN:BAUD
BUS1:CAN:BAUD?
BUS1:CAN:BUSer
BUS1:CAN:BUSer?
BUS1:CAN:SPOint
BUS1:CAN:SPOint?
BUS1:FLEXray:BAUD
BUS1:FLEXray:BAUD?
BUS1:FLEXray:SOURce
BUS1:FLEXray:SOURce?
BUS1:FLEXray:SPOint
BUS1:FLEXray:SPOint?
BUS1:FLEXray:STYPe
BUS1:FLEXray:STYPe?
BUS1:LIN:BAUD
BUS1:LIN:BAUD?
BUS1:LIN:BUSer
BUS1:LIN:BUSer?
BUS1:LIN:IDFormat
BUS1:LIN:IDFormat?
BUS1:LIN:POLarity
BUS1:LIN:POLarity?
BUS1:LIN:SOURce
BUS1:LIN:SOURce?
BUS1:LIN:STANdard
BUS1:LIN:STANdard?
BUS1:IIS:SOURce:CLOCk
BUS1:IIS:SOURce:CLOCk?
BUS1:IIS:SOURce:DATA
BUS1:IIS:SOURce:DATA?
BUS1:IIS:SOURce:WSELect
BUS1:IIS:SOURce:WSELect?
BUS1:IIS:ALIGnment
BUS1:IIS:ALIGnment?
BUS1:IIS:CLOCk:SLOPe
BUS1:IIS:CLOCk:SLOPe?
BUS1:IIS:RWIDth
BUS1:IIS:RWIDth?
BUS1:M1553:SOURce
BUS1:M1553:SOURce?
BUS2:MODE
BUS2:MODE?
BUS2:DISPlay
BUS2:DISPlay?
BUS2:FORMat
BUS2:FORMat?
BUS2:EVENt
BUS2:EVENt?
BUS2:EVENt:FORMat
BUS2:EVENt:FORMat?
BUS2:EVENt:VIEW
BUS2:EVENt:VIEW?
BUS2:LABel
BUS2:LABel?
BUS2:EEXPort
BUS2:DATA?
BUS2:POSition
BUS2:POSition?
BUS2:THReshold
BUS2:THReshold?
BUS2:PARallel:CLK
BUS2:PARallel:CLK?
BUS2:PARallel:SLOPe
BUS2:PARallel:SLOPe?
BUS2:PARallel:BUS
BUS2:PARallel:BUS?
BUS2:PARallel:WIDTh
BUS2:PARallel:WIDTh?
BUS2:PARallel:BITX
BUS2:PARallel:BITX?
BUS2:PARallel:SOURce
BUS2:PARallel:SOURce?
BUS2:PARallel:POLarity
BUS2:PARallel:POLarity?
BUS2:PARallel:NREJect
BUS2:PARallel:NREJect?
BUS2:PARallel:NRTime
BUS2:PARallel:NRTime?
BUS2:RS232:TX
BUS2:RS232:TX?
BUS2:RS232:RX
BUS2:RS232:RX?
BUS2:RS232:POLarity
BUS2:RS232:POLarity?
BUS2:RS232:ENDian
BUS2:RS232:ENDian?
BUS2:RS232:BAUD
BUS2:RS232:BAUD?
BUS2:RS232:BUSer
BUS2:RS232:BUSer?
BUS2:RS232:DBITs
BUS2:RS232:DBITs?
BUS2:RS232:SBITs
BUS2:RS232:SBITs?
BUS2:RS232:PARity
BUS2:RS232:PARity?
BUS2:RS232:PACKet
BUS2:RS232:PACKet?
BUS2:RS232:PEND
BUS2:RS232:PEND?
BUS2:IIC:SCLK:SOURce
BUS2:IIC:SCLK:SOURce?
BUS2:IIC:SDA:SOURce
BUS2:IIC:SDA:SOURce?
BUS2:IIC:ADDRess
BUS2:IIC:ADDRess?
BUS2:SPI:SCLK:SOURce
BUS2:SPI:SCLK:SOURce?
BUS2:SPI:SCLK:SLOPe
BUS2:SPI:SCLK:SLOPe?
BUS2:SPI:MISO:SOURce
BUS2:SPI:MISO:SOURce?
BUS2:SPI:MISO:POLarity
BUS2:SPI:MISO:POLarity?
BUS2:SPI:MOSI:SOURce
BUS2:SPI:MOSI:SOURce?
BUS2:SPI:MOSI:POLarity
BUS2:SPI:MOSI:POLarity?
BUS2:SPI:DBITs
BUS2:SPI:DBITs?
BUS2:SPI:ENDian
BUS2:SPI:ENDian?
BUS2:SPI:MODE
BUS2:SPI:MODE?
BUS2:SPI:TIMeout:TIME
BUS2:SPI:TIMeout:TIME?
BUS2:SPI:SS:SOURce
BUS2:SPI:SS:SOURce?
BUS2:SPI:SS:POLarity
BUS2:SPI:SS:POLarity?
BUS2:CAN:SOURce
BUS2:CAN:SOURce?
BUS2:CAN:STYPe
BUS2:CAN:STYPe?
BUS2:CAN:BAUD
BUS2:CAN:BAUD?
BUS2:CAN:BUSer
BUS2:CAN:BUSer?
BUS2:CAN:SPOint
BUS2:CAN:SPOint?
BUS2:FLEXray:BAUD
BUS2:FLEXray:BAUD?
BUS2:FLEXray:SOURce
BUS2:FLEXray:SOURce?
BUS2:FLEXray:SPOint
BUS2:FLEXray:SPOint?
BUS2:FLEXray:STYPe
BUS2:FLEXray:STYPe?
BUS2:LIN:BAUD
BUS2:LIN:BAUD?
BUS2:LIN:BUSer
BUS2:LIN:BUSer?
BUS2:LIN:IDFormat
BUS2:LIN:IDFormat?
BUS2:LIN:POLarity
BUS2:LIN:POLarity?
BUS2:LIN:SOURce
BUS2:LIN:SOURce?
BUS2:LIN:STANdard
BUS2:LIN:STANdard?
BUS2:IIS:SOURce:CLOCk
BUS2:IIS:SOURce:CLOCk?
BUS2:IIS:SOURce:DATA
BUS2:IIS:SOURce:DATA?
BUS2:IIS:SOURce:WSELect
BUS2:IIS:SOURce:WSELect?
BUS2:IIS:ALIGnment
BUS2:IIS:ALIGnment?
BUS2:IIS:CLOCk:SLOPe
BUS2:IIS:CLOCk:SLOPe?
BUS2:IIS:RWIDth
BUS2:IIS:RWIDth?
BUS2:M1553:SOURce
BUS2:M1553:SOURce?
BUS3:MODE
BUS3:MODE?
BUS3:DISPlay
BUS3:DISPlay?
BUS3:FORMat
BUS3:FORMat?
BUS3:EVENt
BUS3:EVENt?
BUS3:EVENt:FORMat
BUS3:EVENt:FORMat?
BUS3:EVENt:VIEW
BUS3:EVENt:VIEW?
BUS3:LABel
BUS3:LABel?
BUS3:EEXPort
BUS3:DATA?
BUS3:POSition
BUS3:POSition?
BUS3:THReshold
BUS3:THReshold?
BUS3:PARallel:CLK
BUS3:PARallel:CLK?
BUS3:PARallel:SLOPe
BUS3:PARallel:SLOPe?
BUS3:PARallel:BUS
BUS3:PARallel:BUS?
BUS3:PARallel:WIDTh
BUS3:PARallel:WIDTh?
BUS3:PARallel:BITX
BUS3:PARallel:BITX?
BUS3:PARallel:SOURce
BUS3:PARallel:SOURce?
BUS3:PARallel:POLarity
BUS3:PARallel:POLarity?
BUS3:PARallel:NREJect
BUS3:PARallel:NREJect?
BUS3:PARallel:NRTime
BUS3:PARallel:NRTime?
BUS3:RS232:TX
BUS3:RS232:TX?
BUS3:RS232:RX
BUS3:RS232:RX?
BUS3:RS232:POLarity
BUS3:RS232:POLarity?
BUS3:RS232:ENDian
BUS3:RS232:ENDian?
BUS3:RS232:BAUD
BUS3:RS232:BAUD?
BUS3:RS232:BUSer
BUS3:RS232:BUSer?
BUS3:RS232:DBITs
BUS3:RS232:DBITs?
BUS3:RS232:SBITs
BUS3:RS232:SBITs?
BUS3:RS232:PARity
BUS3:RS232:PARity?
BUS3:RS232:PACKet
BUS3:RS232:PACKet?
BUS3:RS232:PEND
BUS3:RS232:PEND?
BUS3:IIC:SCLK:SOURce
BUS3:IIC:SCLK:SOURce?
BUS3:IIC:SDA:SOURce
BUS3:IIC:SDA:SOURce?
BUS3:IIC:ADDRess
BUS3:IIC:ADDRess?
BUS3:SPI:SCLK:SOURce
BUS3:SPI:SCLK:SOURce?
BUS3:SPI:SCLK:SLOPe
BUS3:SPI:SCLK:SLOPe?
BUS3:SPI:MISO:SOURce
BUS3:SPI:MISO:SOURce?
BUS3:SPI:MISO:POLarity
BUS3:SPI:MISO:POLarity?
BUS3:SPI:MOSI:SOURce
BUS3:SPI:MOSI:SOURce?
BUS3:SPI:MOSI:POLarity
BUS3:SPI:MOSI:POLarity?
BUS3:SPI:DBITs
BUS3:SPI:DBITs?
BUS3:SPI:ENDian
BUS3:SPI:ENDian?
BUS3:SPI:MODE
BUS3:SPI:MODE?
BUS3:SPI:TIMeout:TIME
BUS3:SPI:TIMeout:TIME?
BUS3:SPI:SS:SOURce
BUS3:SPI:SS:SOURce?
BUS3:SPI:SS:POLarity
BUS3:SPI:SS:POLarity?
BUS3:CAN:SOURce
BUS3:CAN:SOURce?
BUS3:CAN:STYPe
BUS3:CAN:STYPe?
BUS3:CAN:BAUD
BUS3:CAN:BAUD?
BUS3:CAN:BUSer
BUS3:CAN:BUSer?
BUS3:CAN:SPOint
BUS3:CAN:SPOint?
BUS3:FLEXray:BAUD
BUS3:FLEXray:BAUD?
BUS3:FLEXray:SOURce
BUS3:FLEXray:SOURce?
BUS3:FLEXray:SPOint
BUS3:FLEXray:SPOint?
BUS3:FLEXray:STYPe
BUS3:FLEXray:STYPe?
BUS3:LIN:BAUD
BUS3:LIN:BAUD?
BUS3:LIN:BUSer
BUS3:LIN:BUSer?
BUS3:LIN:IDFormat
BUS3:LIN:IDFormat?
BUS3:LIN:POLarity
BUS3:LIN:POLarity?
BUS3:LIN:SOURce
BUS3:LIN:SOURce?
BUS3:LIN:STANdard
BUS3:LIN:STANdard?
BUS3:IIS:SOURce:CLOCk
BUS3:IIS:SOURce:CLOCk?
BUS3:IIS:SOURce:DATA
BUS3:IIS:SOURce:DATA?
BUS3:IIS:SOURce:WSELect
BUS3:IIS:SOURce:WSELect?
BUS3:IIS:ALIGnment
BUS3:IIS:ALIGnment?
BUS3:IIS:CLOCk:SLOPe
BUS3:IIS:CLOCk:SLOPe?
BUS3:IIS:RWIDth
BUS3:IIS:RWIDth?
BUS3:M1553:SOURce
BUS3:M1553:SOURce?
BUS4:MODE
BUS4:MODE?
BUS4:DISPlay
BUS4:DISPlay?
BUS4:FORMat
BUS4:FORMat?
BUS4:EVENt
BUS4:EVENt?
BUS4:EVENt:FORMat
BUS4:EVENt:FORMat?
BUS4:EVENt:VIEW
BUS4:EVENt:VIEW?
BUS4:LABel
BUS4:LABel?
BUS4:EEXPort
BUS4:DATA?
BUS4:POSition
BUS4:POSition?
BUS4:THReshold
BUS4:THReshold?
BUS4:PARallel:CLK
BUS4:PARallel:CLK?
BUS4:PARallel:SLOPe
BUS4:PARallel:SLOPe?
BUS4:PARallel:BUS
BUS4:PARallel:BUS?
BUS4:PARallel:WIDTh
BUS4:PARallel:WIDTh?
BUS4:PARallel:BITX
BUS4:PARallel:BITX?
BUS4:PARallel:SOURce
BUS4:PARallel:SOURce?
BUS4:PARallel:POLarity
BUS4:PARallel:POLarity?
BUS4:PARallel:NREJect
BUS4:PARallel:NREJect?
BUS4:PARallel:NRTime
BUS4:PARallel:NRTime?
BUS4:RS232:TX
BUS4:RS232:TX?
BUS4:RS232:RX
BUS4:RS232:RX?
BUS4:RS232:POLarity
BUS4:RS232:POLarity?
BUS4:RS232:ENDian
BUS4:RS232:ENDian?
BUS4:RS232:BAUD
BUS4:RS232:BAUD?
BUS4:RS232:BUSer
BUS4:RS232:BUSer?
BUS4:RS232:DBITs
BUS4:RS232:DBITs?
BUS4:RS232:SBITs
BUS4:RS232:SBITs?
BUS4:RS232:PARity
BUS4:RS232:PARity?
BUS4:RS232:PACKet
BUS4:RS232:PACKet?
BUS4:RS232:PEND
BUS4:RS232:PEND?
BUS4:IIC:SCLK:SOURce
BUS4:IIC:SCLK:SOURce?
BUS4:IIC:SDA:SOURce
BUS4:IIC:SDA:SOURce?
BUS4:IIC:ADDRess
BUS4:IIC:ADDRess?
BUS4:SPI:SCLK:SOURce
BUS4:SPI:SCLK:SOURce?
BUS4:SPI:SCLK:SLOPe
BUS4:SPI:SCLK:SLOPe?
BUS4:SPI:MISO:SOURce
BUS4:SPI:MISO:SOURce?
BUS4:SPI:MISO:POLarity
BUS4:SPI:MISO:POLarity?
BUS4:SPI:MOSI:SOURce
BUS4:SPI:MOSI:SOURce?
BUS4:SPI:MOSI:POLarity
BUS4:SPI:MOSI:POLarity?
BUS4:SPI:DBITs
BUS4:SPI:DBITs?
BUS4:SPI:ENDian
BUS4:SPI:ENDian?
BUS4:SPI:MODE
BUS4:SPI:MODE?
BUS4:SPI:TIMeout:TIME
BUS4:SPI:TIMeout:TIME?
BUS4:SPI:SS:SOURce
BUS4:SPI:SS:SOURce?
BUS4:SPI:SS:POLarity
BUS4:SPI:SS:POLarity?
BUS4:CAN:SOURce
BUS4:CAN:SOURce?
BUS4:CAN:STYPe
BUS4:CAN:STYPe?
BUS4:CAN:BAUD
BUS4:CAN:BAUD?
BUS4:CAN:BUSer
BUS4:CAN:BUSer?
BUS4:CAN:SPOint
BUS4:CAN:SPOint?
BUS4:FLEXray:BAUD
BUS4:FLEXray:BAUD?
BUS4:FLEXray:SOURce
BUS4:FLEXray:SOURce?
BUS4:FLEXray:SPOint
BUS4:FLEXray:SPOint?
BUS4:FLEXray:STYPe
BUS4:FLEXray:STYPe?
BUS4:LIN:BAUD
BUS4:LIN:BAUD?
BUS4:LIN:BUSer
BUS4:LIN:BUSer?
BUS4:LIN:IDFormat
BUS4:LIN:IDFormat?
BUS4:LIN:POLarity
BUS4:LIN:POLarity?
BUS4:LIN:SOURce
BUS4:LIN:SOURce?
BUS4:LIN:STANdard
BUS4:LIN:STANdard?
BUS4:IIS:SOURce:CLOCk
BUS4:IIS:SOURce:CLOCk?
BUS4:IIS:SOURce:DATA
BUS4:IIS:SOURce:DATA?
BUS4:IIS:SOURce:WSELect
BUS4:IIS:SOURce:WSELect?
BUS4:IIS:ALIGnment
BUS4:IIS:ALIGnment?
BUS4:IIS:CLOCk:SLOPe
BUS4:IIS:CLOCk:SLOPe?
BUS4:IIS:RWIDth
BUS4:IIS:RWIDth?
BUS4:M1553:SOURce
BUS4:M1553:SOURce?
CALibration:ENTer
CALibration:EXIT
CALibration:STATus?
CALibration:COMPlete?
CALibration:AFE:PATH
CALibration:AFE:K
CALibration:AFE:K?
CALibration:AFE:KX
CALibration:AFE:KX?
CALibration:AFE:ZERO
CALibration:AFE:ZERO?
CALibration:AFE:LSB
CALibration:AFE:LSB?
CALibration:AFE:REG
CALibration:AFE:REG?
CALibration:AFE:CFGM
CALibration:AFE:CMT
CALibration:AFE:CMT?
CALibration:AFE:RC
CALibration:AFE:R?
CALibration:AFE:C?
CALibration:AFE:VPP?
CALibration:AFE:MAX?
CALibration:AFE:MIN?
CALibration:AFE:FAVG?
CALibration:AFE:AVG?
CALibration:AFE:FPP?
CALibration:AFE:osel
CALibration:AFE:dsel
CALibration:AFE:zcal
CALibration:AFE:zcal?
CALibration:AFE:AZVos
CALibration:AFE:AZVos?
CALibration:AFE:GPO0
CALibration:DAC
CALibration:DAC?
CALibration:SAVE
CALibration:LOAD
CALibration:DELay
CALibration:DELay?
CALibration:PLL:MASTer:OUTPut
CALibration:PLL:MASTer:REG
CALibration:PLL:MASTer:CFG
CALibration:PLL:MASTer:CFG?
CALibration:PLL:SLAVe:OUTPut
CALibration:PLL:SLAVe:REG
CALibration:PLL:SLAVe:CFG
CALibration:PLL:SLAVe:CFG?
CALibration:STARt
CALibration:QUIT
CALibration:DATE?
CALibration:TIME?
CALibration:LA
CALibration:LA?
CALibration:LA:PATTern?
CALibration:LAData?
CALibration:ADC:BWTRim
CALibration:ADC:BWTRim?
CALibration:ADC:REG
CALibration:ADC:REG?
CHANnel1:BWLimit
CHANnel1:BWLimit?
CHANnel1:COUPling
CHANnel1:COUPling?
CHANnel1:DISPlay
CHANnel1:DISPlay?
CHANnel1:INVert
CHANnel1:INVert?
CHANnel1:OFFSet
CHANnel1:OFFSet?
CHANnel1:POSition
CHANnel1:POSition?
CHANnel1:SCALe
CHANnel1:SCALe?
CHANnel1:UNITs
CHANnel1:UNITs?
CHANnel1:VERNier
CHANnel1:VERNier?
CHANnel1:TCALibrate
CHANnel1:TCALibrate?
CHANnel1:IMPedance
CHANnel1:IMPedance?
CHANnel1:BVOLtage
CHANnel1:BVOLtage?
CHANnel1:CSTart
CHANnel1:PROBe
CHANnel1:PROBe?
CHANnel1:PROBe:PROT
CHANnel1:PROBe:PROT?
CHANnel1:PROBe:DELAY
CHANnel1:PROBe:DELAY?
CHANnel1:PROBe:BIAS
CHANnel1:PROBe:BIAS?
CHANnel1:PROBe:CALibration
CHANnel1:CHCAL
CHANnel1:CHCAL?
CHANnel2:BWLimit
CHANnel2:BWLimit?
CHANnel2:COUPling
CHANnel2:COUPling?
CHANnel2:DISPlay
CHANnel2:DISPlay?
CHANnel2:INVert
CHANnel2:INVert?
CHANnel2:OFFSet
CHANnel2:OFFSet?
CHANnel2:POSition
CHANnel2:POSition?
CHANnel2:SCALe
CHANnel2:SCALe?
CHANnel2:UNITs
CHANnel2:UNITs?
CHANnel2:VERNier
CHANnel2:VERNier?
CHANnel2:TCALibrate
CHANnel2:TCALibrate?
CHANnel2:IMPedance
CHANnel2:IMPedance?
CHANnel2:BVOLtage
CHANnel2:BVOLtage?
CHANnel2:CSTart
CHANnel2:PROBe
CHANnel2:PROBe?
CHANnel2:PROBe:PROT
CHANnel2:PROBe:PROT?
CHANnel2:PROBe:DELAY
CHANnel2:PROBe:DELAY?
CHANnel2:PROBe:BIAS
CHANnel2:PROBe:BIAS?
CHANnel2:PROBe:CALibration
CHANnel2:CHCAL
CHANnel2:CHCAL?
CHANnel3:BWLimit
CHANnel3:BWLimit?
CHANnel3:COUPling
CHANnel3:COUPling?
CHANnel3:DISPlay
CHANnel3:DISPlay?
CHANnel3:INVert
CHANnel3:INVert?
CHANnel3:OFFSet
CHANnel3:OFFSet?
CHANnel3:POSition
CHANnel3:POSition?
CHANnel3:SCALe
CHANnel3:SCALe?
CHANnel3:UNITs
CHANnel3:UNITs?
CHANnel3:VERNier
CHANnel3:VERNier?
CHANnel3:TCALibrate
CHANnel3:TCALibrate?
CHANnel3:IMPedance
CHANnel3:IMPedance?
CHANnel3:BVOLtage
CHANnel3:BVOLtage?
CHANnel3:CSTart
CHANnel3:PROBe
CHANnel3:PROBe?
CHANnel3:PROBe:PROT
CHANnel3:PROBe:PROT?
CHANnel3:PROBe:DELAY
CHANnel3:PROBe:DELAY?
CHANnel3:PROBe:BIAS
CHANnel3:PROBe:BIAS?
CHANnel3:PROBe:CALibration
CHANnel3:CHCAL
CHANnel3:CHCAL?
CHANnel4:BWLimit
CHANnel4:BWLimit?
CHANnel4:COUPling
CHANnel4:COUPling?
CHANnel4:DISPlay
CHANnel4:DISPlay?
CHANnel4:INVert
CHANnel4:INVert?
CHANnel4:OFFSet
CHANnel4:OFFSet?
CHANnel4:POSition
CHANnel4:POSition?
CHANnel4:SCALe
CHANnel4:SCALe?
CHANnel4:UNITs
CHANnel4:UNITs?
CHANnel4:VERNier
CHANnel4:VERNier?
CHANnel4:TCALibrate
CHANnel4:TCALibrate?
CHANnel4:IMPedance
CHANnel4:IMPedance?
CHANnel4:BVOLtage
CHANnel4:BVOLtage?
CHANnel4:CSTart
CHANnel4:PROBe
CHANnel4:PROBe?
CHANnel4:PROBe:PROT
CHANnel4:PROBe:PROT?
CHANnel4:PROBe:DELAY
CHANnel4:PROBe:DELAY?
CHANnel4:PROBe:BIAS
CHANnel4:PROBe:BIAS?
CHANnel4:PROBe:CALibration
CHANnel4:CHCAL
CHANnel4:CHCAL?
*CLS
*ESE
*ESE?
*ESR?
*IDN?
*OPC
*OPC?
*RCL
*RST
*SAV
*SRE
*SRE?
*STB?
*WAI
*TST?
*TEST?
GPIB:PARSE:END
COUNter:CURRent?
COUNter:ENABle
COUNter:ENABle?
COUNter:SOURce
COUNter:SOURce?
COUNter:MODE
COUNter:MODE?
COUNter:NDIGits
COUNter:NDIGits?
COUNter:TOTalize:ENABle
COUNter:TOTalize:ENABle?
COUNter:TOTalize:CLEar
CURSor:MODE
CURSor:MODE?
CURSor:MANual:TYPE
CURSor:MANual:TYPE?
CURSor:MANual:SOURce
CURSor:MANual:SOURce?
CURSor:MANual:TUNit
CURSor:MANual:TUNit?
CURSor:MANual:VUNit
CURSor:MANual:VUNit?
CURSor:MANual:CAX
CURSor:MANual:CAX?
CURSor:MANual:CBX
CURSor:MANual:CBX?
CURSor:MANual:CAY
CURSor:MANual:CAY?
CURSor:MANual:CBY
CURSor:MANual:CBY?
CURSor:MANual:AXValue?
CURSor:MANual:BXValue?
CURSor:MANual:AYValue?
CURSor:MANual:BYValue?
CURSor:MANual:XDELta?
CURSor:MANual:IXDelta?
CURSor:MANual:YDELta?
CURSor:TRACk:SOURce1
CURSor:TRACk:SOURce1?
CURSor:TRACk:SOURce2
CURSor:TRACk:SOURce2?
CURSor:TRACk:CAX
CURSor:TRACk:CAX?
CURSor:TRACk:CBX
CURSor:TRACk:CBX?
CURSor:TRACk:CAY?
CURSor:TRACk:CBY?
CURSor:TRACk:AXValue?
CURSor:TRACk:AYValue?
CURSor:TRACk:BXValue?
CURSor:TRACk:BYValue?
CURSor:TRACk:XDELta?
CURSor:TRACk:YDELta?
CURSor:TRACk:IXDelta?
CURSor:XY:AX
CURSor:XY:AX?
CURSor:XY:BX
CURSor:XY:BX?
CURSor:XY:AY
CURSor:XY:AY?
CURSor:XY:BY
CURSor:XY:BY?
CURSor:XY:AXValue?
CURSor:XY:AYValue?
CURSor:XY:BXValue?
CURSor:XY:BYValue?
CURSor:MEASure:INDicator
CURSor:MEASure:INDicator?
DISPlay:CLEar
DISPlay:TYPE
DISPlay:TYPE?
DISPlay:GRADing:TIME
DISPlay:GRADing:TIME?
DISPlay:WBRightness
DISPlay:WBRightness?
DISPlay:GRID
DISPlay:GRID?
DISPlay:GBRightness
DISPlay:GBRightness?
DISPlay:SNAP?
DISPlay:PULL?
DISPlay:READy?
DISPlay:DATA?
DISPlay:RULers
DISPlay:RULers?
DISPlay:VDIV
DISPlay:VDIV?
DISPlay:COLor
DISPlay:COLor?
DVM:CURRent?
DVM:ENABle
DVM:ENABle?
DVM:SOURce
DVM:SOURce?
DVM:MODE
DVM:MODE?
HISTogram:DISPlay
HISTogram:DISPlay?
HISTogram:TYPE
HISTogram:TYPE?
HISTogram:SOURce
HISTogram:SOURce?
HISTogram:SIZE
HISTogram:SIZE?
HISTogram:STATic
HISTogram:STATic?
HISTogram:RESet
HISTogram:BLIMit
HISTogram:BLIMit?
HISTogram:LLIMit
HISTogram:LLIMit?
HISTogram:RLIMit
HISTogram:RLIMit?
HISTogram:TLIMit
HISTogram:TLIMit?
JITTer:ENABle
JITTer:ENABle?
JITTer:SOURce
JITTer:SOURce?
JITTer:HISTogram:APPLy
JITTer:HISTogram:APPLy?
JITTer:SPECtrum:APPLy
JITTer:SPECtrum:APPLy?
JITTer:TRENd:APPLy
JITTer:TRENd:APPLy?
JITTer:MEASure:TYPE
JITTer:MEASure:TYPE?
JITTer:MEASure:ITEM
JITTer:MEASure:ITEM?
JITTer:MEASure:STATistic:ITEM?
JITTer:MEASure:ENABle
JITTer:MEASure:ENABle?
JITTer:SLOPe
JITTer:SLOPe?
CLOCk:METHod
CLOCk:METHod?
CLOCk:TYPE
CLOCk:TYPE?
CLOCk:RATE
CLOCk:RATE?
CLOCk:PLL:ORDer
CLOCk:PLL:ORDer?
CLOCk:PLL:BW
CLOCk:PLL:BW?
CLOCk:EXTChan
CLOCk:EXTChan?
EYE:ENABle
EYE:ENABle?
EYE:SOURce
EYE:SOURce?
EYE:MEASure:ENABle
EYE:MEASure:ENABle?
EYE:MEASure:ITEM?
EYE:OVERlap
EYE:OVERlap?
LA:STATe
LA:STATe?
LA:ACTive
LA:ACTive?
LA:DISPlay
LA:DISPlay?
LA:AUTosort
LA:DELete
LA:SIZE
LA:SIZE?
LA:TCALibrate
LA:TCALibrate?
LA:DIGital:DISPlay
LA:DIGital:DISPlay?
LA:DIGital:POSition
LA:DIGital:POSition?
LA:DIGital:LABel
LA:DIGital:LABel?
LA:POD1:DISPlay
LA:POD1:DISPlay?
LA:POD1:THReshold
LA:POD1:THReshold?
LA:POD2:DISPlay
LA:POD2:DISPlay?
LA:POD2:THReshold
LA:POD2:THReshold?
LA:GROup:APPend
LA:probe:status?
LAN:DHCP
LAN:DHCP?
LAN:AUToip
LAN:AUToip?
LAN:GATeway
LAN:GATeway?
LAN:DNS
LAN:DNS?
LAN:MAC?
LAN:DSERver?
LAN:MANual
LAN:MANual?
LAN:INITiate
LAN:IPADdress
LAN:IPADdress?
LAN:SMASk
LAN:SMASk?
LAN:STATus?
LAN:VISA?
LAN:MDNS
LAN:MDNS?
LAN:APPLy
LAN:HOST:NAME
LAN:HOST:NAME?
LAN:DOMain
LAN:DOMain?
LAN:DESCription
LAN:DESCription?
LAN:IPMode
LAN:WEBControl:DEFault
MASK:ENABle
MASK:ENABle?
MASK:SOURce
MASK:SOURce?
MASK:OPERate
MASK:OPERate?
MASK:MDISplay
MASK:MDISplay?
MASK:X
MASK:X?
MASK:Y
MASK:Y?
MASK:CREate
MASK:RESet
MASK:NUMBers?
MASK:ERRaction
MASK:ERRaction?
MATH1:DISPlay
MATH1:DISPlay?
MATH1:OPERator
MATH1:OPERator?
MATH1:SOURce1
MATH1:SOURce1?
MATH1:SOURce2
MATH1:SOURce2?
MATH1:LSOurce1
MATH1:LSOurce1?
MATH1:LSOurce2
MATH1:LSOurce2?
MATH1:SCALe
MATH1:SCALe?
MATH1:OFFSet
MATH1:OFFSet?
MATH1:INVert
MATH1:INVert?
MATH1:RESet
MATH1:FFT:SOURce
MATH1:FFT:SOURce?
MATH1:FFT:WINDow
MATH1:FFT:WINDow?
MATH1:FFT:SPLit
MATH1:FFT:SPLit?
MATH1:FFT:UNIT
MATH1:FFT:UNIT?
MATH1:FFT:SCALe
MATH1:FFT:SCALe?
MATH1:FFT:OFFSet
MATH1:FFT:OFFSet?
MATH1:FFT:HSCale
MATH1:FFT:HSCale?
MATH1:FFT:HCENter
MATH1:FFT:HCENter?
MATH1:FFT:FREQuency:STARt
MATH1:FFT:FREQuency:STARt?
MATH1:FFT:FREQuency:END
MATH1:FFT:FREQuency:END?
MATH1:FFT:SEARch:ENABle
MATH1:FFT:SEARch:ENABle?
MATH1:FFT:SEARch:NUM
MATH1:FFT:SEARch:NUM?
MATH1:FFT:SEARch:THReshold
MATH1:FFT:SEARch:THReshold?
MATH1:FFT:SEARch:EXCursion
MATH1:FFT:SEARch:EXCursion?
MATH1:FFT:SEARch:ORDer
MATH1:FFT:SEARch:ORDer?
MATH1:FFT:SEARch:Res?
MATH1:FILTer:TYPE
MATH1:FILTer:TYPE?
MATH1:FILTer:W1
MATH1:FILTer:W1?
MATH1:FILTer:W2
MATH1:FILTer:W2?
MATH1:SENSitivity
MATH1:SENSitivity?
MATH1:DISTance
MATH1:DISTance?
MATH1:THReshold1
MATH1:THReshold1?
MATH1:THReshold2
MATH1:THReshold2?
MATH1:THReshold3
MATH1:THReshold3?
MATH1:THReshold4
MATH1:THReshold4?
MATH2:DISPlay
MATH2:DISPlay?
MATH2:OPERator
MATH2:OPERator?
MATH2:SOURce1
MATH2:SOURce1?
MATH2:SOURce2
MATH2:SOURce2?
MATH2:LSOurce1
MATH2:LSOurce1?
MATH2:LSOurce2
MATH2:LSOurce2?
MATH2:SCALe
MATH2:SCALe?
MATH2:OFFSet
MATH2:OFFSet?
MATH2:INVert
MATH2:INVert?
MATH2:RESet
MATH2:FFT:SOURce
MATH2:FFT:SOURce?
MATH2:FFT:WINDow
MATH2:FFT:WINDow?
MATH2:FFT:SPLit
MATH2:FFT:SPLit?
MATH2:FFT:UNIT
MATH2:FFT:UNIT?
MATH2:FFT:SCALe
MATH2:FFT:SCALe?
MATH2:FFT:OFFSet
MATH2:FFT:OFFSet?
MATH2:FFT:HSCale
MATH2:FFT:HSCale?
MATH2:FFT:HCENter
MATH2:FFT:HCENter?
MATH2:FFT:FREQuency:STARt
MATH2:FFT:FREQuency:STARt?
MATH2:FFT:FREQuency:END
MATH2:FFT:FREQuency:END?
MATH2:FFT:SEARch:ENABle
MATH2:FFT:SEARch:ENABle?
MATH2:FFT:SEARch:NUM
MATH2:FFT:SEARch:NUM?
MATH2:FFT:SEARch:THReshold
MATH2:FFT:SEARch:THReshold?
MATH2:FFT:SEARch:EXCursion
MATH2:FFT:SEARch:EXCursion?
MATH2:FFT:SEARch:ORDer
MATH2:FFT:SEARch:ORDer?
MATH2:FFT:SEARch:Res?
MATH2:FILTer:TYPE
MATH2:FILTer:TYPE?
MATH2:FILTer:W1
MATH2:FILTer:W1?
MATH2:FILTer:W2
MATH2:FILTer:W2?
MATH2:SENSitivity
MATH2:SENSitivity?
MATH2:DISTance
MATH2:DISTance?
MATH2:THReshold1
MATH2:THReshold1?
MATH2:THReshold2
MATH2:THReshold2?
MATH2:THReshold3
MATH2:THReshold3?
MATH2:THReshold4
MATH2:THReshold4?
MATH3:DISPlay
MATH3:DISPlay?
MATH3:OPERator
MATH3:OPERator?
MATH3:SOURce1
MATH3:SOURce1?
MATH3:SOURce2
MATH3:SOURce2?
MATH3:LSOurce1
MATH3:LSOurce1?
MATH3:LSOurce2
MATH3:LSOurce2?
MATH3:SCALe
MATH3:SCALe?
MATH3:OFFSet
MATH3:OFFSet?
MATH3:INVert
MATH3:INVert?
MATH3:RESet
MATH3:FFT:SOURce
MATH3:FFT:SOURce?
MATH3:FFT:WINDow
MATH3:FFT:WINDow?
MATH3:FFT:SPLit
MATH3:FFT:SPLit?
MATH3:FFT:UNIT
MATH3:FFT:UNIT?
MATH3:FFT:SCALe
MATH3:FFT:SCALe?
MATH3:FFT:OFFSet
MATH3:FFT:OFFSet?
MATH3:FFT:HSCale
MATH3:FFT:HSCale?
MATH3:FFT:HCENter
MATH3:FFT:HCENter?
MATH3:FFT:FREQuency:STARt
MATH3:FFT:FREQuency:STARt?
MATH3:FFT:FREQuency:END
MATH3:FFT:FREQuency:END?
MATH3:FFT:SEARch:ENABle
MATH3:FFT:SEARch:ENABle?
MATH3:FFT:SEARch:NUM
MATH3:FFT:SEARch:NUM?
MATH3:FFT:SEARch:THReshold
MATH3:FFT:SEARch:THReshold?
MATH3:FFT:SEARch:EXCursion
MATH3:FFT:SEARch:EXCursion?
MATH3:FFT:SEARch:ORDer
MATH3:FFT:SEARch:ORDer?
MATH3:FFT:SEARch:Res?
MATH3:FILTer:TYPE
MATH3:FILTer:TYPE?
MATH3:FILTer:W1
MATH3:FILTer:W1?
MATH3:FILTer:W2
MATH3:FILTer:W2?
MATH3:SENSitivity
MATH3:SENSitivity?
MATH3:DISTance
MATH3:DISTance?
MATH3:THReshold1
MATH3:THReshold1?
MATH3:THReshold2
MATH3:THReshold2?
MATH3:THReshold3
MATH3:THReshold3?
MATH3:THReshold4
MATH3:THReshold4?
MATH4:DISPlay
MATH4:DISPlay?
MATH4:OPERator
MATH4:OPERator?
MATH4:SOURce1
MATH4:SOURce1?
MATH4:SOURce2
MATH4:SOURce2?
MATH4:LSOurce1
MATH4:LSOurce1?
MATH4:LSOurce2
MATH4:LSOurce2?
MATH4:SCALe
MATH4:SCALe?
MATH4:OFFSet
MATH4:OFFSet?
MATH4:INVert
MATH4:INVert?
MATH4:RESet
MATH4:FFT:SOURce
MATH4:FFT:SOURce?
MATH4:FFT:WINDow
MATH4:FFT:WINDow?
MATH4:FFT:SPLit
MATH4:FFT:SPLit?
MATH4:FFT:UNIT
MATH4:FFT:UNIT?
MATH4:FFT:SCALe
MATH4:FFT:SCALe?
MATH4:FFT:OFFSet
MATH4:FFT:OFFSet?
MATH4:FFT:HSCale
MATH4:FFT:HSCale?
MATH4:FFT:HCENter
MATH4:FFT:HCENter?
MATH4:FFT:FREQuency:STARt
MATH4:FFT:FREQuency:STARt?
MATH4:FFT:FREQuency:END
MATH4:FFT:FREQuency:END?
MATH4:FFT:SEARch:ENABle
MATH4:FFT:SEARch:ENABle?
MATH4:FFT:SEARch:NUM
MATH4:FFT:SEARch:NUM?
MATH4:FFT:SEARch:THReshold
MATH4:FFT:SEARch:THReshold?
MATH4:FFT:SEARch:EXCursion
MATH4:FFT:SEARch:EXCursion?
MATH4:FFT:SEARch:ORDer
MATH4:FFT:SEARch:ORDer?
MATH4:FFT:SEARch:Res?
MATH4:FILTer:TYPE
MATH4:FILTer:TYPE?
MATH4:FILTer:W1
MATH4:FILTer:W1?
MATH4:FILTer:W2
MATH4:FILTer:W2?
MATH4:SENSitivity
MATH4:SENSitivity?
MATH4:DISTance
MATH4:DISTance?
MATH4:THReshold1
MATH4:THReshold1?
MATH4:THReshold2
MATH4:THReshold2?
MATH4:THReshold3
MATH4:THReshold3?
MATH4:THReshold4
MATH4:THReshold4?
MEASure:SOURce
MEASure:SOURce?
MEASure:COUNter:ENABle
MEASure:COUNter:ENABle?
MEASure:COUNter:SOURce
MEASure:COUNter:SOURce?
MEASure:COUNter:VALue?
MEASure:CLEar
MEASure:AMSource
MEASure:AMSource?
MEASure:STATistic:DISPlay
MEASure:STATistic:DISPlay?
MEASure:STATistic:RESet
MEASure:STATistic:ITEM
MEASure:STATistic:ITEM?
MEASure:SETup:MAX
MEASure:SETup:MAX?
MEASure:SETup:MID
MEASure:SETup:MID?
MEASure:SETup:MIN
MEASure:SETup:MIN?
MEASure:SETup:PSA
MEASure:SETup:PSA?
MEASure:SETup:PSB
MEASure:SETup:PSB?
MEASure:SETup:DSA
MEASure:SETup:DSA?
MEASure:SETup:DSB
MEASure:SETup:DSB?
MEASure:THReshold:SOURce
MEASure:THReshold:DEFault
MEASure:MODE
MEASure:MODE?
MEASure:AREA
MEASure:AREA?
MEASure:TYPE
MEASure:TYPE?
MEASure:CREGion:CAX
MEASure:CREGion:CAX?
MEASure:CREGion:CBX
MEASure:CREGion:CBX?
MEASure:ITEM
MEASure:ITEM?
MEASure:EPOS:SA?
MEASure:EPOS:SB?
MEASure:CATegory
MEASure:CATegory?
MEASure:INDicator
MEASure:INDicator?
POWer:TYPE
POWer:TYPE?
POWer:CURRentsource
POWer:CURRentsource?
POWer:VOLTagesource
POWer:VOLTagesource?
POWer:REFLevel:METHod
POWer:REFLevel:METHod?
POWer:REFLevel:ABSolute:HIGH
POWer:REFLevel:ABSolute:HIGH?
POWer:REFLevel:ABSolute:LOW
POWer:REFLevel:ABSolute:LOW?
POWer:REFLevel:ABSolute:MID
POWer:REFLevel:ABSolute:MID?
POWer:REFLevel:PERCent:HIGH
POWer:REFLevel:PERCent:HIGH?
POWer:REFLevel:PERCent:LOW
POWer:REFLevel:PERCent:LOW?
POWer:REFLevel:PERCent:MID
POWer:REFLevel:PERCent:MID?
POWer:QUALity:DISPlay
POWer:QUALity:DISPlay?
POWer:QUALity:FREQreference
POWer:QUALity:FREQreference?
POWer:RIPPle:SOURce
POWer:RIPPle:SOURce?
POWer:RIPPle:DISPlay
POWer:RIPPle:DISPlay?
POWer:STATistics:RESet
QUICk:OPERation
QUICk:OPERation?
RECord:ENABle
RECord:ENABle?
RECord:STARt
RECord:STARt?
RECord:PLAY
RECord:PLAY?
RECord:CURRent
RECord:CURRent?
RECord:FRAMes
RECord:FRAMes?
REFerence:DISPlay
REFerence:DISPlay?
REFerence:SOURce
REFerence:SOURce?
REFerence:VSCale
REFerence:VSCale?
REFerence:VOFFset
REFerence:VOFFset?
REFerence:RESet
REFerence:CURRent
REFerence:SAVe
REFerence:COLor
REFerence:COLor?
REFerence:LABel:ENABle
REFerence:LABel:ENABle?
REFerence:LABel:CONTent
REFerence:LABel:CONTent?
SAVE:CSV
SAVE:CSV:FACTors
SAVE:CSV:FACTors?
SAVE:CSV:LENGth
SAVE:CSV:LENGth?
SAVE:FORMat
SAVE:FORMat?
SAVE:IMAGe
SAVE:IMAGe:TYPE
SAVE:IMAGe:TYPE?
SAVE:IMAGe:FACTors
SAVE:IMAGe:FACTors?
SAVE:IMAGe:INVert
SAVE:IMAGe:INVert?
SAVE:IMAGe:COLor
SAVE:IMAGe:COLor?
SAVE:SETup
SAVE:WAVeform
SAVE:STATus?
LOAd:SETup
SEARch:STATe
SEARch:STATe?
SEARch:MODE
SEARch:MODE?
SEARch:EVENt
SEARch:EVENt?
SEARch:COUNt?
SEARch:VALue?
SEARch:EDGE:SLOPe
SEARch:EDGE:SLOPe?
SEARch:EDGE:SOURce
SEARch:EDGE:SOURce?
SEARch:EDGE:THReshold
SEARch:EDGE:THReshold?
SEARch:RUNT:POLarity
SEARch:RUNT:POLarity?
SEARch:RUNT:QUALifier
SEARch:RUNT:QUALifier?
SEARch:RUNT:SOURce
SEARch:RUNT:SOURce?
SEARch:RUNT:WUPPer
SEARch:RUNT:WUPPer?
SEARch:RUNT:WLOWer
SEARch:RUNT:WLOWer?
SEARch:RUNT:THReshold1
SEARch:RUNT:THReshold1?
SEARch:RUNT:THReshold2
SEARch:RUNT:THReshold2?
SEARch:PULSe:POLarity
SEARch:PULSe:POLarity?
SEARch:PULSe:QUALifier
SEARch:PULSe:QUALifier?
SEARch:PULSe:SOURce
SEARch:PULSe:SOURce?
SEARch:PULSe:UWIDth
SEARch:PULSe:UWIDth?
SEARch:PULSe:LWIDth
SEARch:PULSe:LWIDth?
SEARch:PULSe:THReshold
SEARch:PULSe:THReshold?
SEARch:SLOPe:POLarity
SEARch:SLOPe:POLarity?
SEARch:SLOPe:QUALifier
SEARch:SLOPe:QUALifier?
SEARch:SLOPe:SOURce
SEARch:SLOPe:SOURce?
SEARch:SLOPe:TUPPer
SEARch:SLOPe:TUPPer?
SEARch:SLOPe:TLOWer
SEARch:SLOPe:TLOWer?
SEARch:SLOPe:THReshold1
SEARch:SLOPe:THReshold1?
SEARch:SLOPe:THReshold2
SEARch:SLOPe:THReshold2?
SOURce:FREQuency:FIXed
SOURce:FREQuency:FIXed?
SOURce:PHASe:ADJust
SOURce:PHASe:ADJust?
SOURce:PHASe:INITiate
SOURce:FUNCtion:SHAPe
SOURce:FUNCtion:SHAPe?
SOURce:FUNCtion:RAMP:SYMMetry
SOURce:FUNCtion:RAMP:SYMMetry?
SOURce:VOLTage:LEVel:IMMediate:AMPLitude
SOURce:VOLTage:LEVel:IMMediate:AMPLitude?
SOURce:VOLTage:LEVel:IMMediate:OFFSet
SOURce:VOLTage:LEVel:IMMediate:OFFSet?
SOURce:PULSe:DCYCle
SOURce:PULSe:DCYCle?
SOURce:MOD:TYPE
SOURce:MOD:TYPE?
SOURce:MOD:AM:DEPTh
SOURce:MOD:AM:DEPTh?
SOURce:MOD:AM:INTernal:FREQuency
SOURce:MOD:AM:INTernal:FREQuency?
SOURce:MOD:AM:INTernal:FUNCtion
SOURce:MOD:AM:INTernal:FUNCtion?
SOURce:MOD:FM:DEViation
SOURce:MOD:FM:DEViation?
SOURce:MOD:FM:INTernal:FREQuency
SOURce:MOD:FM:INTernal:FREQuency?
SOURce:MOD:FM:INTernal:FUNCtion
SOURce:MOD:FM:INTernal:FUNCtion?
SOURce:SWEep:TYPE
SOURce:SWEep:TYPE?
SOURce:SWEep:STIMe
SOURce:SWEep:STIMe?
SOURce:SWEep:BTIMe
SOURce:SWEep:BTIMe?
SOURce:BURSt:TYPE
SOURce:BURSt:TYPE?
SOURce:BURSt:CYCLes
SOURce:BURSt:CYCLes?
SOURce:BURSt:DELay
SOURce:BURSt:DELay?
SOURce:APPLy:NOISe
SOURce:APPLy:PULSe
SOURce:APPLy:RAMP
SOURce:APPLy:SINusoid
SOURce:APPLy:SQUare
SOURce:APPLy:DC
SOURce:APPLy:USER
SOURce:APPLy?
SOURce:OUTPut:STATe
SOURce:OUTPut:STATe?
SOURce:OUTPut:IMPedance
SOURce:OUTPut:IMPedance?
SOURce:OUTPut1:STATe
SOURce:OUTPut1:STATe?
SOURce:OUTPut1:IMPedance
SOURce:OUTPut1:IMPedance?
SOURce:OUTPut2:STATe
SOURce:OUTPut2:STATe?
SOURce:OUTPut2:IMPedance
SOURce:OUTPut2:IMPedance?
SOURce:CALibration:VCTXo
SOURce:CALibration:VCTXo?
SOURce:CALibration:PHASe
SOURce:CALibration:PHASe?
SOURce:CALibration:OFFSet
SOURce:CALibration:OFFSet?
SOURce:CALibration:DC
SOURce:CALibration:DC?
SOURce:CALibration:AMP
SOURce:CALibration:AMP?
SOURce:CALibration:SAVedata
SOURce:CALibration:DEFault
SOURce1:FREQuency:FIXed
SOURce1:FREQuency:FIXed?
SOURce1:PHASe:ADJust
SOURce1:PHASe:ADJust?
SOURce1:PHASe:INITiate
SOURce1:FUNCtion:SHAPe
SOURce1:FUNCtion:SHAPe?
SOURce1:FUNCtion:RAMP:SYMMetry
SOURce1:FUNCtion:RAMP:SYMMetry?
SOURce1:VOLTage:LEVel:IMMediate:AMPLitude
SOURce1:VOLTage:LEVel:IMMediate:AMPLitude?
SOURce1:VOLTage:LEVel:IMMediate:OFFSet
SOURce1:VOLTage:LEVel:IMMediate:OFFSet?
SOURce1:PULSe:DCYCle
SOURce1:PULSe:DCYCle?
SOURce1:TYPE
SOURce1:TYPE?
SOURce1:MOD:TYPE
SOURce1:MOD:TYPE?
SOURce1:MOD:AM:DEPTh
SOURce1:MOD:AM:DEPTh?
SOURce1:MOD:AM:INTernal:FREQuency
SOURce1:MOD:AM:INTernal:FREQuency?
SOURce1:MOD:AM:INTernal:FUNCtion
SOURce1:MOD:AM:INTernal:FUNCtion?
SOURce1:MOD:FM:DEViation
SOURce1:MOD:FM:DEViation?
SOURce1:MOD:FM:INTernal:FREQuency
SOURce1:MOD:FM:INTernal:FREQuency?
SOURce1:MOD:FM:INTernal:FUNCtion
SOURce1:MOD:FM:INTernal:FUNCtion?
SOURce1:SWEep:TYPE
SOURce1:SWEep:TYPE?
SOURce1:SWEep:STIMe
SOURce1:SWEep:STIMe?
SOURce1:SWEep:BTIMe
SOURce1:SWEep:BTIMe?
SOURce1:BURSt:TYPE
SOURce1:BURSt:TYPE?
SOURce1:BURSt:CYCLes
SOURce1:BURSt:CYCLes?
SOURce1:BURSt:DELay
SOURce1:BURSt:DELay?
SOURce1:APPLy:NOISe
SOURce1:APPLy:PULSe
SOURce1:APPLy:RAMP
SOURce1:APPLy:SINusoid
SOURce1:APPLy:SQUare
SOURce1:APPLy:DC
SOURce1:APPLy:USER
SOURce1:APPLy?
SOURce1:OUTPut:STATe
SOURce1:OUTPut:STATe?
SOURce1:OUTPut:IMPedance
SOURce1:OUTPut:IMPedance?
SOURce1:OUTPut1:STATe
SOURce1:OUTPut1:STATe?
SOURce1:OUTPut1:IMPedance
SOURce1:OUTPut1:IMPedance?
SOURce1:OUTPut2:STATe
SOURce1:OUTPut2:STATe?
SOURce1:OUTPut2:IMPedance
SOURce1:OUTPut2:IMPedance?
SOURce1:CALibration:VCTXo
SOURce1:CALibration:VCTXo?
SOURce1:CALibration:PHASe
SOURce1:CALibration:PHASe?
SOURce1:CALibration:OFFSet
SOURce1:CALibration:OFFSet?
SOURce1:CALibration:DC
SOURce1:CALibration:DC?
SOURce1:CALibration:AMP
SOURce1:CALibration:AMP?
SOURce1:CALibration:SAVedata
SOURce1:CALibration:DEFault
SOURce2:FREQuency:FIXed
SOURce2:FREQuency:FIXed?
SOURce2:PHASe:ADJust
SOURce2:PHASe:ADJust?
SOURce2:PHASe:INITiate
SOURce2:FUNCtion:SHAPe
SOURce2:FUNCtion:SHAPe?
SOURce2:FUNCtion:RAMP:SYMMetry
SOURce2:FUNCtion:RAMP:SYMMetry?
SOURce2:VOLTage:LEVel:IMMediate:AMPLitude
SOURce2:VOLTage:LEVel:IMMediate:AMPLitude?
SOURce2:VOLTage:LEVel:IMMediate:OFFSet
SOURce2:VOLTage:LEVel:IMMediate:OFFSet?
SOURce2:PULSe:DCYCle
SOURce2:PULSe:DCYCle?
SOURce2:TYPE
SOURce2:TYPE?
SOURce2:MOD:TYPE
SOURce2:MOD:TYPE?
SOURce2:MOD:AM:DEPTh
SOURce2:MOD:AM:DEPTh?
SOURce2:MOD:AM:INTernal:FREQuency
SOURce2:MOD:AM:INTernal:FREQuency?
SOURce2:MOD:AM:INTernal:FUNCtion
SOURce2:MOD:AM:INTernal:FUNCtion?
SOURce2:MOD:FM:DEViation
SOURce2:MOD:FM:DEViation?
SOURce2:MOD:FM:INTernal:FREQuency
SOURce2:MOD:FM:INTernal:FREQuency?
SOURce2:MOD:FM:INTernal:FUNCtion
SOURce2:MOD:FM:INTernal:FUNCtion?
SOURce2:SWEep:TYPE
SOURce2:SWEep:TYPE?
SOURce2:SWEep:STIMe
SOURce2:SWEep:STIMe?
SOURce2:SWEep:BTIMe
SOURce2:SWEep:BTIMe?
SOURce2:BURSt:TYPE
SOURce2:BURSt:TYPE?
SOURce2:BURSt:CYCLes
SOURce2:BURSt:CYCLes?
SOURce2:BURSt:DELay
SOURce2:BURSt:DELay?
SOURce2:APPLy:NOISe
SOURce2:APPLy:PULSe
SOURce2:APPLy:RAMP
SOURce2:APPLy:SINusoid
SOURce2:APPLy:SQUare
SOURce2:APPLy:DC
SOURce2:APPLy:USER
SOURce2:APPLy?
SOURce2:OUTPut:STATe
SOURce2:OUTPut:STATe?
SOURce2:OUTPut:IMPedance
SOURce2:OUTPut:IMPedance?
SOURce2:OUTPut1:STATe
SOURce2:OUTPut1:STATe?
SOURce2:OUTPut1:IMPedance
SOURce2:OUTPut1:IMPedance?
SOURce2:OUTPut2:STATe
SOURce2:OUTPut2:STATe?
SOURce2:OUTPut2:IMPedance
SOURce2:OUTPut2:IMPedance?
SOURce2:CALibration:VCTXo
SOURce2:CALibration:VCTXo?
SOURce2:CALibration:PHASe
SOURce2:CALibration:PHASe?
SOURce2:CALibration:OFFSet
SOURce2:CALibration:OFFSet?
SOURce2:CALibration:DC
SOURce2:CALibration:DC?
SOURce2:CALibration:AMP
SOURce2:CALibration:AMP?
SOURce2:CALibration:SAVedata
SOURce2:CALibration:DEFault
SYSTem:AOUTput
SYSTem:AOUTput?
SYSTem:AUToscale
SYSTem:AUToscale?
SYSTem:BEEPer
SYSTem:BEEPer?
SYSTem:TICK
SYSTem:DATE
SYSTem:DATE?
SYSTem:ERRor:NEXT?
SYSTem:GAMount?
SYSTem:GPIB
SYSTem:GPIB?
SYSTem:KEY:PRESs
SYSTem:KEY:INCRease
SYSTem:KEY:DECRease
SYSTem:TOUCh
SYSTem:LANGuage
SYSTem:LANGuage?
SYSTem:OPTion:INSTall
SYSTem:OPTion:UNITem
SYSTem:OPTion:UNINstall
SYSTem:OPTion:STATus?
SYSTem:OPTion:VALid?
SYSTem:OPTion:LIST?
SYSTem:FLASh:WRITe
SYSTem:PON
SYSTem:PON?
SYSTem:PSTatus
SYSTem:PSTatus?
SYSTem:RAMount?
SYSTem:RESet
SYSTem:SETup
SYSTem:SETup?
SYSTem:SSAVer:TIME
SYSTem:SSAVer:TIME?
SYSTem:TIME
SYSTem:TIME?
SYSTem:VERSion?
SYSTem:SCINfo?
SYSTem:LOCKed
SYSTem:LOCKed?
SYSTem:MODules?
SYSTem:PRES
SYSTem:PRES?
SYSTem:LABel
SYSTem:DGSTatus?
SYSTem:RCLock
SYSTem:RCLock?
SYSTem:NVClear
SYSTem:PWDClear
SYSTem:ROM?
SYSTem:AUTClear
SYSTem:KIMPedance
SYSTem:KIMPedance?
VENDor:CONFigure
VENDor:CONFigure?
TIMebase:DELay:ENABle
TIMebase:DELay:ENABle?
TIMebase:DELay:OFFSet
TIMebase:DELay:OFFSet?
TIMebase:DELay:SCALe
TIMebase:DELay:SCALe?
TIMebase:MAIN:OFFSet
TIMebase:MAIN:OFFSet?
TIMebase:MAIN:SCALe
TIMebase:MAIN:SCALe?
TIMebase:MODE
TIMebase:MODE?
TIMebase:HREFerence:MODE
TIMebase:HREFerence:MODE?
TIMebase:HREFerence:POSition
TIMebase:HREFerence:POSition?
TIMebase:VERNier
TIMebase:VERNier?
TIMebase:HOTKeys
TIMebase:STATus?
AUToscale
TRIGger:MODE
TRIGger:MODE?
TRIGger:COUPling
TRIGger:COUPling?
TRIGger:STATus?
TRIGger:SWEep
TRIGger:SWEep?
TRIGger:HOLDoff
TRIGger:HOLDoff?
TRIGger:NREJect
TRIGger:NREJect?
TRIGger:POSition?
TRIGger:EDGE:SOURce
TRIGger:EDGE:SOURce?
TRIGger:EDGE:SLOPe
TRIGger:EDGE:SLOPe?
TRIGger:EDGE:LEVel
TRIGger:EDGE:LEVel?
TRIGger:PULSe:SOURce
TRIGger:PULSe:SOURce?
TRIGger:PULSe:WHEN
TRIGger:PULSe:WHEN?
TRIGger:PULSe:WIDTh
TRIGger:PULSe:WIDTh?
TRIGger:PULSe:UWIDth
TRIGger:PULSe:UWIDth?
TRIGger:PULSe:LWIDth
TRIGger:PULSe:LWIDth?
TRIGger:PULSe:LEVel
TRIGger:PULSe:LEVel?
TRIGger:SLOPe:SOURce
TRIGger:SLOPe:SOURce?
TRIGger:SLOPe:WHEN
TRIGger:SLOPe:WHEN?
TRIGger:SLOPe:TIME
TRIGger:SLOPe:TIME?
TRIGger:SLOPe:TUPPer
TRIGger:SLOPe:TUPPer?
TRIGger:SLOPe:TLOWer
TRIGger:SLOPe:TLOWer?
TRIGger:SLOPe:WINDow
TRIGger:SLOPe:WINDow?
TRIGger:SLOPe:ALEVel
TRIGger:SLOPe:ALEVel?
TRIGger:SLOPe:BLEVel
TRIGger:SLOPe:BLEVel?
TRIGger:VIDeo:SOURce
TRIGger:VIDeo:SOURce?
TRIGger:VIDeo:POLarity
TRIGger:VIDeo:POLarity?
TRIGger:VIDeo:MODE
TRIGger:VIDeo:MODE?
TRIGger:VIDeo:LINE
TRIGger:VIDeo:LINE?
TRIGger:VIDeo:STANdard
TRIGger:VIDeo:STANdard?
TRIGger:VIDeo:LEVel
TRIGger:VIDeo:LEVel?
TRIGger:PATTern:PATTern
TRIGger:PATTern:PATTern?
TRIGger:PATTern:LEVel
TRIGger:PATTern:LEVel?
TRIGger:PATTern:SOURce
TRIGger:PATTern:SOURce?
TRIGger:DURation:SOURce
TRIGger:DURation:SOURce?
TRIGger:DURation:TYPE
TRIGger:DURation:TYPE?
TRIGger:DURation:WHEN
TRIGger:DURation:WHEN?
TRIGger:DURation:TUPPer
TRIGger:DURation:TUPPer?
TRIGger:DURation:TLOWer
TRIGger:DURation:TLOWer?
TRIGger:DURation:LEVel
TRIGger:DURation:LEVel?
TRIGger:TIMeout:SOURce
TRIGger:TIMeout:SOURce?
TRIGger:TIMeout:SLOPe
TRIGger:TIMeout:SLOPe?
TRIGger:TIMeout:TIME
TRIGger:TIMeout:TIME?
TRIGger:TIMeout:LEVel
TRIGger:TIMeout:LEVel?
TRIGger:RUNT:SOURce
TRIGger:RUNT:SOURce?
TRIGger:RUNT:POLarity
TRIGger:RUNT:POLarity?
TRIGger:RUNT:WHEN
TRIGger:RUNT:WHEN?
TRIGger:RUNT:WUPPer
TRIGger:RUNT:WUPPer?
TRIGger:RUNT:WLOWer
TRIGger:RUNT:WLOWer?
TRIGger:RUNT:ALEVel
TRIGger:RUNT:ALEVel?
TRIGger:RUNT:BLEVel
TRIGger:RUNT:BLEVel?
TRIGger:WINDows:SOURce
TRIGger:WINDows:SOURce?
TRIGger:WINDows:SLOPe
TRIGger:WINDows:SLOPe?
TRIGger:WINDows:POSition
TRIGger:WINDows:POSition?
TRIGger:WINDows:TIME
TRIGger:WINDows:TIME?
TRIGger:WINDows:ALEVel
TRIGger:WINDows:ALEVel?
TRIGger:WINDows:BLEVel
TRIGger:WINDows:BLEVel?
TRIGger:DELay:SA
TRIGger:DELay:SA?
TRIGger:DELay:SLOPa
TRIGger:DELay:SLOPa?
TRIGger:DELay:SB
TRIGger:DELay:SB?
TRIGger:DELay:SLOPb
TRIGger:DELay:SLOPb?
TRIGger:DELay:TYPE
TRIGger:DELay:TYPE?
TRIGger:DELay:TUPPer
TRIGger:DELay:TUPPer?
TRIGger:DELay:TLOWer
TRIGger:DELay:TLOWer?
TRIGger:DELay:ALEVel
TRIGger:DELay:ALEVel?
TRIGger:DELay:BLEVel
TRIGger:DELay:BLEVel?
TRIGger:SHOLd:DSRC
TRIGger:SHOLd:DSRC?
TRIGger:SHOLd:CSRC
TRIGger:SHOLd:CSRC?
TRIGger:SHOLd:SLOPe
TRIGger:SHOLd:SLOPe?
TRIGger:SHOLd:PATTern
TRIGger:SHOLd:PATTern?
TRIGger:SHOLd:TYPE
TRIGger:SHOLd:TYPE?
TRIGger:SHOLd:STIMe
TRIGger:SHOLd:STIMe?
TRIGger:SHOLd:HTIMe
TRIGger:SHOLd:HTIMe?
TRIGger:SHOLd:DLEVel
TRIGger:SHOLd:DLEVel?
TRIGger:SHOLd:CLEVel
TRIGger:SHOLd:CLEVel?
TRIGger:NEDGe:SOURce
TRIGger:NEDGe:SOURce?
TRIGger:NEDGe:SLOPe
TRIGger:NEDGe:SLOPe?
TRIGger:NEDGe:IDLE
TRIGger:NEDGe:IDLE?
TRIGger:NEDGe:EDGE
TRIGger:NEDGe:EDGE?
TRIGger:NEDGe:LEVel
TRIGger:NEDGe:LEVel?
TRIGger:RS232:SOURce
TRIGger:RS232:SOURce?
TRIGger:RS232:WHEN
TRIGger:RS232:WHEN?
TRIGger:RS232:PARity
TRIGger:RS232:PARity?
TRIGger:RS232:STOP
TRIGger:RS232:STOP?
TRIGger:RS232:DATA
TRIGger:RS232:DATA?
TRIGger:RS232:WIDTh
TRIGger:RS232:WIDTh?
TRIGger:RS232:BAUD
TRIGger:RS232:BAUD?
TRIGger:RS232:BUSer
TRIGger:RS232:BUSer?
TRIGger:RS232:LEVel
TRIGger:RS232:LEVel?
TRIGger:IIC:SCL
TRIGger:IIC:SCL?
TRIGger:IIC:SDA
TRIGger:IIC:SDA?
TRIGger:IIC:WHEN
TRIGger:IIC:WHEN?
TRIGger:IIC:AWIDth
TRIGger:IIC:AWIDth?
TRIGger:IIC:ADDRess
TRIGger:IIC:ADDRess?
TRIGger:IIC:DIRection
TRIGger:IIC:DIRection?
TRIGger:IIC:DATA
TRIGger:IIC:DATA?
TRIGger:IIC:CLEVel
TRIGger:IIC:CLEVel?
TRIGger:IIC:DLEVel
TRIGger:IIC:DLEVel?
TRIGger:CAN:BAUD
TRIGger:CAN:BAUD?
TRIGger:CAN:SOURce
TRIGger:CAN:SOURce?
TRIGger:CAN:STYPe
TRIGger:CAN:STYPe?
TRIGger:CAN:WHEN
TRIGger:CAN:WHEN?
TRIGger:CAN:SPOint
TRIGger:CAN:SPOint?
TRIGger:CAN:LEVel
TRIGger:CAN:LEVel?
TRIGger:SPI:CLEVel
TRIGger:SPI:CLEVel?
TRIGger:SPI:DLEVel
TRIGger:SPI:DLEVel?
TRIGger:SPI:CS
TRIGger:SPI:CS?
TRIGger:SPI:DATA
TRIGger:SPI:DATA?
TRIGger:SPI:MODE
TRIGger:SPI:MODE?
TRIGger:SPI:SCL
TRIGger:SPI:SCL?
TRIGger:SPI:SDA
TRIGger:SPI:SDA?
TRIGger:SPI:SLEVel
TRIGger:SPI:SLEVel?
TRIGger:SPI:SLOPe
TRIGger:SPI:SLOPe?
TRIGger:SPI:TIMeout
TRIGger:SPI:TIMeout?
TRIGger:SPI:WHEN
TRIGger:SPI:WHEN?
TRIGger:SPI:WIDTh
TRIGger:SPI:WIDTh?
TRIGger:FLEXray:BAUD
TRIGger:FLEXray:BAUD?
TRIGger:FLEXray:SOURce
TRIGger:FLEXray:SOURce?
TRIGger:FLEXray:WHEN
TRIGger:FLEXray:WHEN?
TRIGger:FLEXray:LEVel
TRIGger:FLEXray:LEVel?
TRIGger:IIS:ALIGnment
TRIGger:IIS:ALIGnment?
TRIGger:IIS:CLOCk:SLOPe
TRIGger:IIS:CLOCk:SLOPe?
TRIGger:IIS:SOURce:CLOCk
TRIGger:IIS:SOURce:CLOCk?
TRIGger:IIS:SOURce:DATA
TRIGger:IIS:SOURce:DATA?
TRIGger:IIS:SOURce:WSELect
TRIGger:IIS:SOURce:WSELect?
TRIGger:IIS:WHEN
TRIGger:IIS:WHEN?
TRIGger:IIS:AUDio
TRIGger:IIS:AUDio?
TRIGger:IIS:DATA
TRIGger:IIS:DATA?
TRIGger:LIN:SOURce
TRIGger:LIN:SOURce?
TRIGger:LIN:ID
TRIGger:LIN:ID?
TRIGger:LIN:BAUD
TRIGger:LIN:BAUD?
TRIGger:LIN:STANdard
TRIGger:LIN:STANdard?
TRIGger:LIN:SAMPlepoint
TRIGger:LIN:SAMPlepoint?
TRIGger:LIN:WHEN
TRIGger:LIN:WHEN?
TRIGger:LIN:LEVel
TRIGger:LIN:LEVel?
TRIGger:M1553:SOURce
TRIGger:M1553:SOURce?
TRIGger:M1553:WHEN
TRIGger:M1553:WHEN?
TRIGger:M1553:POLarity
TRIGger:M1553:POLarity?
TRIGger:M1553:ALEVel
TRIGger:M1553:ALEVel?
TRIGger:M1553:BLEVel
TRIGger:M1553:BLEVel?
TFORce
WAVeform:SOURce
WAVeform:SOURce?
WAVeform:MODE
WAVeform:MODE?
WAVeform:FORMat
WAVeform:FORMat?
WAVeform:POINts
WAVeform:POINts?
WAVeform:DATA?
WAVeform:XINCrement?
WAVeform:XORigin?
WAVeform:XREFerence?
WAVeform:YINCrement?
WAVeform:YORigin?
WAVeform:YREFerence?
WAVeform:STARt
WAVeform:STARt?
WAVeform:STOP
WAVeform:STOP?
WAVeform:BEGin
WAVeform:END
WAVeform:RESet
WAVeform:PREamble?
WAVeform:STATus?
I think its pretty certain that the scope phones home everytime it can.
One thing it does in that phone call, i think, is to send a RSA encrypted pack that contains some relevant data from the /data dir. Personal data: keys, licenses,etc
If someone wants to put a wireshark to work we can verify this info.
I think its pretty certain that the scope phones home everytime it can.
If someone wants to put a wireshark to work we can verify this info.
Thanks delfinom, you rock :-+
You think perhaps something erroneous got stored in the firmware.xml response file on the affected scopes and that's what caused the hang? And if so, you think there's a way to copy over a good copy and fix the problem without going through re-patching? Once the freeze occurs, even the original 04.04 and 04.08 without patch would cause the freeze, that's what leads me to think some erroneous data got stored somewhere.
If not, there's no big deal. It is easy to re-patch just to remove the phone home "features", especially given how infrequent patches are released.
Again, thanks for all your hard work to look into this matter, it is much appreciated..
I think its pretty certain that the scope phones home everytime it can.
I dunno about "every time it can" but it looks like it does something at bootup.If someone wants to put a wireshark to work we can verify this info.
Maybe it's just checking for updates. Has anybody seen any sort of "new updates are available" message on one of these?
Tracking how much hacking is going on seems pointless (it's probably in the "90%" region) but that doesn't mean they aren't doing it.
Making the 'scope hang at bootup is a bug though, it needs fixing. A wireshark session would be very informative, if only to figure out what it's doing and how to tweak routers to block it so it boots up as fast as possible.
Well there are two callbacks.
One is definitely an update check, and doesn't send anything other than your scope serial number.
Mabl, no pissing contest here, but i released the SCPI commands in the general Rigol all SCPI commands thread. I'll try and check with yours.
Well there are two callbacks.
One is definitely an update check, and doesn't send anything other than your scope serial number.
The other is a "upload" function but it's not set to upload anything that would reveal it's hacked since that is only in appEntry with no file system modifications.
More than likely it's a diagnostic/troubleshooting function. But I can't even find where it's triggered and is most likely not in use.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<h1>301 Moved Permanently</h1>
<p>The requested resource has been assigned a new permanent URI.</p>
<hr/>Powered by Tengine</body>
</html>
[...] scope does a regular http (not https) get of "/Support/ProductUpgradeFile?sn=MS5xxxxxxxxxx&hardware=1.0&behaviour=soft&software=00.01.01.02.03 HTTP/1.1".
<firmware>http://www.rigol.com/Support/ProductUpgradeFile?sn=%1$hardware=%2$behaviour=%3$software=%4</firmware>
<uploadurl>http://www.rigol.com/up.aspx?act=%1$filename=%2</uploadurl>
#0 0x000c4fe4 in ?? ()
#1 0xb62fec28 in QMetaObject::activate(QObject*, int, int, void**) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#2 0x000d42e8 in CHttp::sigFinish(QNetworkReply::NetworkError) ()
#3 0x000cf3f0 in ?? ()
#4 0x000cf1bc in ?? ()
#5 0x000d3e88 in ?? ()
#6 0xb62fec28 in QMetaObject::activate(QObject*, int, int, void**) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#7 0xb6630770 in ?? () from target:/rigol/Qt5.5/lib/libQt5Network.so.5
#8 0xb66907b4 in ?? () from target:/rigol/Qt5.5/lib/libQt5Network.so.5
#9 0xb62fc8c4 in QMetaCallEvent::placeMetaCall(QObject*) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#10 0xb630006c in QObject::event(QEvent*) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#11 0xb6bb76e8 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from target:/rigol/Qt5.5/lib/libQt5Widgets.so.5
#12 0xb6bbcccc in QApplication::notify(QObject*, QEvent*) () from target:/rigol/Qt5.5/lib/libQt5Widgets.so.5
#13 0xb62ce5bc in QCoreApplication::notifyInternal(QObject*, QEvent*) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#14 0xb62d151c in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#15 0xb6325ec0 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#16 0xb5914ba0 in QUnixEventDispatcherQPA::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from target:/rigol/Qt5.5/plugins/platforms/libqlinuxfb.so
#17 0xb62cc3f0 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#18 0xb62cc81c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#19 0xb62d43e0 in QCoreApplication::exec() () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#20 0x0004334c in ?? ()
#21 0xb5da7874 in __libc_start_main () from target:/lib/libc.so.6
#22 0x00042d98 in ?? ()
#0 0xb5dbfb48 in raise () from target:/lib/libc.so.6
#1 0xb5dc4ed8 in abort () from target:/lib/libc.so.6
#2 0xb60f1018 in QMessageLogger::fatal(char const*, ...) const () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#3 0xb60ec660 in qt_assert(char const*, char const*, int) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#4 0x0087256c in ?? ()
#5 0x0087065c in ?? ()
#6 0x000c5b28 in ?? ()
#7 0x000c50a0 in ?? ()
#8 0x000d2544 in ?? ()
#9 0xb62fec28 in QMetaObject::activate(QObject*, int, int, void**) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#10 0x000d42e8 in CHttp::sigFinish(QNetworkReply::NetworkError) ()
#11 0x000cf3f0 in ?? ()
#12 0x000cf1bc in ?? ()
#13 0x000d3e88 in ?? ()
#14 0xb62fec28 in QMetaObject::activate(QObject*, int, int, void**) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#15 0xb6630770 in ?? () from target:/rigol/Qt5.5/lib/libQt5Network.so.5
#16 0xb66907b4 in ?? () from target:/rigol/Qt5.5/lib/libQt5Network.so.5
#17 0xb62fc8c4 in QMetaCallEvent::placeMetaCall(QObject*) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#18 0xb630006c in QObject::event(QEvent*) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#19 0xb6bb76e8 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from target:/rigol/Qt5.5/lib/libQt5Widgets.so.5
#20 0xb6bbcccc in QApplication::notify(QObject*, QEvent*) () from target:/rigol/Qt5.5/lib/libQt5Widgets.so.5
#21 0xb62ce5bc in QCoreApplication::notifyInternal(QObject*, QEvent*) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#22 0xb62d151c in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#23 0xb6325ec0 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#24 0xb5914ba0 in QUnixEventDispatcherQPA::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from target:/rigol/Qt5.5/plugins/platforms/libqlinuxfb.so
#25 0xb62cc3f0 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#26 0xb62cc81c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#27 0xb62d43e0 in QCoreApplication::exec() () from target:/rigol/Qt5.5/lib/libQt5Core.so.5
#28 0x0004334c in ?? ()
--Type <RET> for more, q to quit, c to continue without paging--
#29 0xb5da7874 in __libc_start_main () from target:/lib/libc.so.6
#30 0x00042d98 in ?? ()
I would guess that on some machines, the update check triggers automatically without manual update check, gets a "mal-formed" XML and then appEntry dies. I don't get why my scope doesn't do it however...
Yea, I triggered it manually and didn't have it die, same exact file contents you have and that same typoed url.Strange.
I see you are much further along by running gdb on the scope :P
$ ./gdbserver localhost:30000 /rigol/appEntry -run
$ arm-linux-gnueabihf-gdb
target remote ip:30000
b *0xaddress
layout asm
c
I also wonder if the freeze at bootup has to do with the fact the online update button press is also persisted, if you press the button it greys out, and if you were to reboot the scope, it stays greyed out for some time still.
But I did try and it had no effect on it freezing.
/dev/ubi1_0 on /rigol/data type ubifs (rw,sync,relatime)
It looks like the scope writes the current state (a 1K field of memory) approximately every minute to /rigol/data/stat.dat (independently of the power on state setting). That mount point has the realtime option:
It's been a long time since I saw that but I have the impression that all those constant writings are in the FRAM copy and not in the NAND.
The other is a "upload" function but it's not set to upload anything that would reveal it's hacked since that is only in appEntry with no file system modifications.
Code: [Select]<firmware>http://www.rigol.com/Support/ProductUpgradeFile?sn=%1$hardware=%2$behaviour=%3$software=%4</firmware>
<uploadurl>http://www.rigol.com/up.aspx?act=%1$filename=%2</uploadurl>
That upload-url makes me a bit squeezy.
It is self-healing!
To try out some of the latest finding you have discovered, I removed the firewall rule on my router, plug the scope into the network, and tried to recreate the problem. Guess what, now the scope boots fine with the LAN attached, and rigol.com no longer blocked.
Intriguing idea |O. Possibly there is some kind of counter for power-ups or time persisted in /rigol/data/stat.dat. Next time I debug this, I'll set a breakpoint and try to trigger that auto-connect.
Let's admit that they keep track of the last date when you reported your scope status. And, from time to time, they require you to report the status. If you don't...
Let's admit that they keep track of the last date when you reported your scope status. And, from time to time, they require you to report the status. If you don't...
What if you never connect it to a network? :popcorn:
Let's admit that they keep track of the last date when you reported your scope status. And, from time to time, they require you to report the status. If you don't...
What if you never connect it to a network? :popcorn:
Of course, that's one solution. Better one is to patch the hyperlinks that try to dump the XML link page and do the upload.
BTW, we also must remember that in the code there is an email client, so the reporting can exist via email. The email address to which it reports can be easily found in the code.
Oh dear.... I did see the hard coded credentials, but thought nobody was crazy enough to do this. I once even checked the credentials on an older firmware and they did not work for sending mails (maybe the server was down or I made a mistake or they even changed).Are you sure it's not due to your ISP blocking port 25 like mine does?
Now you get into their company mail server? And see the employee directory? :palm: Maybe even see all the old sent emails by that account?
This is where the fun ends. Please contact Rigol as soon as possible.
EDIT: I tried sending them a warning message using their own SMTP server - it did not answer on port 25, which the scope also uses. So as I said before, their mail credentials seems broken. I wonder if this is due to your last message now, or if they removed plain text SMTP...
Oh dear.... I did see the hard coded credentials, but thought nobody was crazy enough to do this. I once even checked the credentials on an older firmware and they did not work for sending mails (maybe the server was down or I made a mistake or they even changed).Are you sure it's not due to your ISP blocking port 25 like mine does?
Now you get into their company mail server? And see the employee directory? :palm: Maybe even see all the old sent emails by that account?
This is where the fun ends. Please contact Rigol as soon as possible.
EDIT: I tried sending them a warning message using their own SMTP server - it did not answer on port 25, which the scope also uses. So as I said before, their mail credentials seems broken. I wonder if this is due to your last message now, or if they removed plain text SMTP...
Oh dear.... I did see the hard coded credentials, but thought nobody was crazy enough to do this. I once even checked the credentials on an older firmware and they did not work for sending mails (maybe the server was down or I made a mistake or they even changed).Are you sure it's not due to your ISP blocking port 25 like mine does?
Now you get into their company mail server? And see the employee directory? :palm: Maybe even see all the old sent emails by that account?
This is where the fun ends. Please contact Rigol as soon as possible.
EDIT: I tried sending them a warning message using their own SMTP server - it did not answer on port 25, which the scope also uses. So as I said before, their mail credentials seems broken. I wonder if this is due to your last message now, or if they removed plain text SMTP...
Why would they include credentials? If it is sending email to @rigol.com, then it just needs to connect to the rigol.com MX.
Of course, as you mention they cannot rely on port 25 being open outbound (rarely is these days) so they'd want to use 587 or similar, and I guess their server configuration may then require auth.
In any case, sending email from the scope is just stupid when they could more reliably use a web API for notifications or data exfiltration.
This is where the fun ends. Please contact Rigol as soon as possible.
They are using the credentials as a smtp relay which is normal. There's a giant list of reasons why nobody sends mail directly to domains these days (i.e. 90% chance the receiving mail server or your ISP or corporate network will block you)
They are using the credentials as a smtp relay which is normal. There's a giant list of reasons why nobody sends mail directly to domains these days (i.e. 90% chance the receiving mail server or your ISP or corporate network will block you)
Yes, the fact it will likely be blocked, even if using a non-standard SMTP port, is why this whole thing is bonkers.
The fact that they then included credentials that can be used to do more than sending emails to their domain, just shows they shouldn't be writing networking code, or probably any embedded applications.
Please update us if you hear back from them. If you don't hear that they've closed up the security hole in a pretty short time, then this should be reported to a security researcher to name & shame them. e.g Brian Krebs or Troy Hunt.
Meh, you are making it worse than it is. Shit I've seen worse at major defense contractors and the stories I could tell.
Is it bad? Yes.
But does it mean they shouldn't be writing networking code or embedded applications? Hah
Meh, you are making it worse than it is. Shit I've seen worse at major defense contractors and the stories I could tell.
Possibly, but they've just compromised their own email server. Think about that, and then what concerns there might be in putting this scope on an engineering network in a large corporation or university.
These scopes connect to external web servers via http (not https, so no encryption and no way to validate certificate to ensure there isn't a MITM attack), and then writes downloaded data to the filesystem. I wouldn't be surprised if there was a serious vulnerability there that allowed malicious code to be injected and run on the scope, and not just via the firmware update process.Is it bad? Yes.
But does it mean they shouldn't be writing networking code or embedded applications? Hah
The fact that a lot worse happens elsewhere doesn't mimimise how bad this is.
Of course... if it wasn't for these same developers this thread wouldn't exist at all. And Rigol would be selling a lot less of their latest scopes.
Possibly, but they've just compromised their own email server. Think about that, and then what concerns there might be in putting this scope on an engineering network in a large corporation or university.
Dave tweeted about it, so the word has got out >:D
Glad they closed the hole so quickly.
I think its pretty certain that the scope phones home everytime it can.Curious. At least I haven't observed anything of the sort with a DS1000Z, SDS1202X-E nor a SVA1015X (and I keep a year worth of Netflow data for my home network).
One thing it does in that phone call, i think, is to send a RSA encrypted pack that contains some relevant data from the /data dir. Personal data: keys, licenses,etc
If someone wants to put a wireshark to work we can verify this info.
Mabl, no pissing contest here, but i released the SCPI commands in the general Rigol all SCPI commands thread. I'll try and check with yours.
Phoning home would be quite rude.
Phoning home would be quite rude.
I hate something like this and specially when it's done by the same guys who are able to create the SMTP vulnerabilities that we saw in the last few days...
Deeply worrisome!!
With all the paranoia about Chinese equipment with backdoors it's extraordinarily dumb to do something like that.
If they are deeply worried about hacking, well, it's not that hard ot make it much more difficult. I can even imagine that they somewhat tolerate some hacking activity in the lower end.
Never attribute to malice that which is adequately explained by stupidity
So is it really just an RSA encrypted packet? If it connects using SSL/TLS it could be possible to try to intercept it. Maybe they won't actually check the certificate (or it's possible to replace certificate trust settings on a firmware file).
So is it really just an RSA encrypted packet? If it connects using SSL/TLS it could be possible to try to intercept it. Maybe they won't actually check the certificate (or it's possible to replace certificate trust settings on a firmware file).
Most of the backdoors I have seen even in examples of the "backdoored" Chinese equipment can be described by Hanlon's razor just like in Rigol's smtp case.QuoteNever attribute to malice that which is adequately explained by stupidity
People get paranoid because of the "Chinese" boogeyman (not to say there isn't a threat), but I've seen as equivalent stupidity from American equipment vendors, even big names like Cisco are part of itOf course. Getting it right in a big company is very hard. Especially when everything was just soooo coool, dude, in happiest times! ;) Straightening poor practices inherited from the past is really difficult.
Just reinforcing the point that you can't trust any piece of networked hardware from any vendor period.And indeed you are right. My commment deals with the trust problem that these new manufacturers can face. They are newcomers, they are beginning to sell somewhat mature products and nowadays people pays much more attention to this crap than 30 years ago.
Of course. Getting it right in a big company is very hard. Especially when everything was just soooo coool, dude, in happiest times! ;) Straightening poor practices inherited from the past is really difficult.
Here's a new bspatch that should disable two callbacks to rigol. But I could only test that it stopped storing the response in /tmp/firmware.xml right now.
Here's a new bspatch that should disable two callbacks to rigol. But I could only test that it stopped storing the response in /tmp/firmware.xml right now.
delfinom, what about disabling email capabilities?
sub_273B50
sub_2745AC
I just got an email from someone (who is not anonymous) that claims to have cracked the scope and is seeing performance up to 1GHz after setting the front end chip to 4GHz bandwidth.
But, at first sight, it seems that the BW limit of the MSO5000 is definitely near the 500MHz mark and doesnt go further:Maybe the lack of 50ohm input?
tv84,
That’s an excellent update, can’t wait to learn more.
Even if we don’t use all 500MHz, just not having the -3dB drop at 350MHz is a welcomed enhancement.
I agree that not having the 50 Ohm input would limit how high we can go on the hardware without modification.
Have you had a chance to check if heat on the front end increases with the update and how well the existing cooling handles it?
tv84,
That’s an excellent update, can’t wait to learn more.
Even if we don’t use all 500MHz, just not having the -3dB drop at 350MHz is a welcomed enhancement.
I agree that not having the 50 Ohm input would limit how high we can go on the hardware without modification.
Have you had a chance to check if heat on the front end increases with the update and how well the existing cooling handles it?
Its already been measured at 450-500MHz prior to modifications tv84 is currently working on: https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/ (https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/)
What he could unlock is possibly >500MHz or >8Gs/s, the second of which would increase power consumption.
Its already been measured at 450-500MHz prior to modifications tv84 is currently working on: https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/ (https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/)
What he could unlock is possibly >500MHz or >8Gs/s, the second of which would increase power consumption.
/usr/sbin/sshd
/etc/init.d/550sshd restart
I've tried holding down the SINGLE button while booting
50 ohm pass through with 1 GHz bandwidth?
How does one enable this mystical 500MHz mode?
Have you tried what happens if you set E_CFG_MODEL_RAW to be an MSO7000 model?
Looking at the System Information menu code we can see that it was prepared to display the following params:Where the red ones are the more interesting finds :)
Manufacturer: INF_SYS_VENDOR
Model: INF_SYS_MODEL
Serial number: INF_SYS_SERIAL
Firmware: INF_SYS_FIRMWARE
Hardware: INF_SYS_HARDWARE
Boot: INF_SYS_BOOT
Build date: INF_SYS_BUILD
FPGA.K7:
FPGA.ZYNQ:
FPGA.SP6:
ADC.ID0:
ADC.ID0:
AFE.VER0:
AFE.VER1:
AFE.VER2:
AFE.VER3:
Started:
Live Time:
The red ones are missing from the final display.
Do we know also how this information is read? Or is it simply not implemented. Have you managed to get it onto the screen? I'm curious to see if we can probe these over the SPI bus ourselves (should be possible of course). Maybe these fields are only shown when putting the scope into 'debug' or 'dev' mode. Getting the versions also means we can see if/when these are changed of course. Sadly, I don't think it'll be easy to extract this information from the FPGA binaries.
That the FPGA's had individual versions makes sense, they are uploaded each boot.
ADC.ID0 is in the list twice, a typo perhaps?
I won't go into details because the benefits are residual compared to the possible headaches when executing the procedure wrongly. I leave that as homework for the ones who are not faint of heart.
Hey tv84,
If I interpret your finding properly, does the model change actually upgrade the -3dB point from 350MHz to 470MHz by removing any hidden software limitation? And other than the 500ps horizontal scale, is there any other benefit that you observed?
I won't go into details because the benefits are residual compared to the possible headaches when executing the procedure wrongly. I leave that as homework for the ones who are not faint of heart.
If I interpret your finding properly, does the model change actually upgrade the -3dB point from 350MHz to 470MHz by removing any hidden software limitation? And other than the 500ps horizontal scale, is there any other benefit that you observed?
Yes, I also looked into these. However, I do think all interaction is via SCPI commands and there is hence no secret there, which is not also in the SCPI definitions in /rigol/resources.
It looks to me, that there is a message passing system, which is also partially used to define the SCPI commands. However not all messages are also exposed via SCPI commands. I believe the production version of the firmware is not shipped with a full set of SCPI command definitions, hence giving no way to access all possible messages. (until we define our own SCPI commands to access them :popcorn:. I failed in my first quick attempt tough.)
<TotalItem>
<head>^(:?HACK|:?H)(:PROJECT|:PRO)$</head>
<service>utility</service>
<cmd>48</cmd>
<minSize>-1</minSize>
<indexes>
</indexes>
<unit>
</unit>
</TotalItem>
resource/menu/msg.h:#define MSG_APP_UTILITY_PROJECT 12073
<root@rigol>ls /media/sda1/cal/
ADC1_iDelay.csv hzgnd1.csv hzscale1.csv lzgnd0.csv lzscale_20x_flt0.csv lzscale_20x_normal0.csv lzscale_2x_flt0.csv lzscale_2x_normal0.csv
ADC2_iDelay.csv hzgnd2.csv hzscale2.csv lzgnd1.csv lzscale_20x_flt1.csv lzscale_20x_normal1.csv lzscale_2x_flt1.csv lzscale_2x_normal1.csv
go.csv hzgnd3.csv hzscale3.csv lzgnd2.csv lzscale_20x_flt2.csv lzscale_20x_normal2.csv lzscale_2x_flt2.csv lzscale_2x_normal2.csv
hzgnd0.csv hzscale0.csv lf.csv lzgnd3.csv lzscale_20x_flt3.csv lzscale_20x_normal3.csv lzscale_2x_flt3.csv lzscale_2x_normal3.csv
Well after reading all of this thread and half the rest of the forum - bought my first Oscilloscope yesterday from the RigolNA clearance section - MSO5074. Buy once cry once - but I'll update once I get it setup and ... patched .... :-+
They had a 5072 there as well the other day but I wanted 4 probes and factory warranty for four channelsWell after reading all of this thread and half the rest of the forum - bought my first Oscilloscope yesterday from the RigolNA clearance section - MSO5074. Buy once cry once - but I'll update once I get it setup and ... patched .... :-+
Nice catch. I wouldn't have expected MSO5000 to be in there already.
That code decodes inside the servEdgeTrigger::_cmdEntry (at 0x0149e634) to function at 0x0023ccbc. However that function forwards to the identical code 12073 to "utility" (at 0x014a1f58) to fun at 0x0027839c. That function returns if the project mode is enabled or not, I would have expected it to route to the project state toggle (cmd 48) defined one entry above. But anyways, it looks like there is a relation between edge trigger mode and project mode. Interestingly, going into edge trigger mode was one of the requirements to manually trigger project mode on older scopes, see also here (https://beyondmeasure.rigoltech.com/acton/attachment/1579/f-04b7/1/-/-/-/-/DS4000%20Calibration%20Guide.pdf?sid=TV2:xBDzVJlWK).
You need firmware 04.08 to have the overshoot-undershoot correctionAwesome! I may have missed it but I'm assuming there's a different update patch in this thread I can find once I'm back at my PC, or it's back to the ole Putty?
Very interesting, how can I activate this ?
Rigol.eu told me, they don´t know about a project mode on the 5000/7000....
But, refer them to mabl's post and they'll learn how to enable it.
After updating to 01.01.04.08, mabl´s usb patch wouldn´t function any more... :(What is mabi's usb patch?
I don´t have the skills to do the hack apart from the usb hack file….. :(I struggled my way through it and will do a write up shortly, but in the meantime if you don't have a Linux computer I recommend downloading VirtualBox (https://www.virtualbox.org/) and following the instructions to install Linux on your virtual computer running inside virtualbox (https://download.virtualbox.org/virtualbox/6.0.12/UserManual.pdf)
So I have to wait until someone have mercy for users like me. ;)
It works on mac osx as well... it should work on windows 10 with WSL (Windows Subsystem for Linux)I don´t have the skills to do the hack apart from the usb hack file….. :(I struggled my way through it and will do a write up shortly, but in the meantime if you don't have a Linux computer I recommend downloading VirtualBox (https://www.virtualbox.org/ (https://www.virtualbox.org/)) and following the instructions to install Linux on your virtual computer running inside virtualbox (https://download.virtualbox.org/virtualbox/6.0.12/UserManual.pdf (https://download.virtualbox.org/virtualbox/6.0.12/UserManual.pdf))
So I have to wait until someone have mercy for users like me. ;)
Once you've got Linux installed it will make it possible to accomplish the patch.
For non-Linux nerds this distro is very user friendly - https://www.linuxmint.com/ (https://www.linuxmint.com/)
It is possible to accommodate the patch using Windows software but it's much easier in Linux
After an embarrassing long delay, here are the changes for 01.04.08 uploaded to git:
https://gitlab.com/riglol/rigolee/commit/ae77323ac04da753d98ae9a1d99a658e000b9088
for those that care ;)
@AngusBeef :
Sounds complicating to me, but I will try it at forthcoming weekend....
file_to_patch=/rigol/appEntry
file_to_patch_md5sum=afe3e7c2d38bdebb66d3f1f11d910743
patch_file=name_of_patch.bpatch
after_patch_md5sum=expected_md5_sum_after_patch
Does anyone know why the FW update is still absent from the North America site?
Does anyone know why the FW update is still absent from the North America site?
And still absent in europe (rigol.eu), strange….
I´ve ask them about without getting an answer.
I´ll try again.
Probably the 01.01.04.08 firmware from the chinese site is a beta version - Because today I got an answer from rigol support.
They await the next official version in october and recommend to use the official updates on their site…..
https://rigol.com/SUPPORTS/Software-Firmware-Download_3.html (https://rigol.com/SUPPORTS/Software-Firmware-Download_3.html)
So you think 1B chinese are beta-testers??
I´m really thinking about to buy the optionbundle, but there´s the bandwith upgrade for free in this hack....
I am a proud owner of a new Rigol MSo5000. I do not know if I should hack or wait for the new firmware to be posted to US site. What do you think? >:D
I am a proud owner of a new Rigol MSo5000. I do not know if I should hack or wait for the new firmware to be posted to US site. What do you think? >:D
Hi,Yes, change it for a Keysight
I own an MSO5074 as well. My real concern is that it is extremely slow. All the reactions and the boot and everything. It is jut not as responsive, as any other equipment i ever owned.
Is there a fix for that?
Thanks
Hi,Yes, change it for a Keysight
I own an MSO5074 as well. My real concern is that it is extremely slow. All the reactions and the boot and everything. It is jut not as responsive, as any other equipment i ever owned.
Is there a fix for that?
Thanks
Yes, change it for a Keysight[/quote]
Rigols are sluggish. If you look at the MSO8000 video on youtube doing serial decoding, it shows the waveform, then 1 second later the decoded information. It is the same on the MSO5000 that I have.
The knobs are sluggish, it takes some time from when you move them and the scope shows the update. It has been the same since the 2nd generation (DSO1054Z). It used to be very responsive when they were manufacturing for Agilent, around 2009.
It has nothing to do with the capture memory. It only decodes what is being displayed. I set it to auto, and it is sluggish even with some KB of capture memory. If you get used to it, it is fine. Or use the event table.Rigols are sluggish. If you look at the MSO8000 video on youtube doing serial decoding, it shows the waveform, then 1 second later the decoded information. It is the same on the MSO5000 that I have.
400Mb of RAM takes time to process. It's not really fair to compare it with 1MB RAM Keysights. :popcorn:
You can probably reduce the memory depth a bit if you want faster decodes.
It has nothing to do with the capture memory. It only decodes what is being displayed.Rigols are sluggish. If you look at the MSO8000 video on youtube doing serial decoding, it shows the waveform, then 1 second later the decoded information. It is the same on the MSO5000 that I have.
400Mb of RAM takes time to process. It's not really fair to compare it with 1MB RAM Keysights. :popcorn:
You can probably reduce the memory depth a bit if you want faster decodes.
Though after that, everything is pretty much instant. The R&S boots much faster but is much more sluggish in useHi,Yes, change it for a Keysight
I own an MSO5074 as well. My real concern is that it is extremely slow. All the reactions and the boot and everything. It is jut not as responsive, as any other equipment i ever owned.
Is there a fix for that?
Thanks
Exactly. Because my Keysight 3000T boots in 55 seconds...
Got an offer where I couldn´t resist, delievery time 1-2 weeks.
Let the scope use DHCP and create a static lease in your router which will be tied to the scopes NIC. The router will always respond to the scopes NIC's DHCP request with the IP you set. Simple enough....
-Stan
Effective yesterday, any purchase of a MSO5000 oscilloscope will include the BUNDLE OPTION for FREE: https://www.tequipment.net/Rigol/MSO5000-BND/Options/ (https://www.tequipment.net/Rigol/MSO5000-BND/Options/)
Oscilloscopes purchased during the promotion period qualifies for a free bundle upgrade with registration. This option bundle enables all serial decode capabilities, power analysis, and the integrated function generator.
Same offer in the U.S., bundle includes protocol analysis, waveform generator, and power analysis ($699) value. You get it when you register your product, offer expires 3/31/20. MSO5204 gets a bandwidth upgrade to 350MHz
This makes the MSO5000 a much more compelling offering in the MSO space.
BTW, DS7000, MSO7000, MSO8000 all offers free bundles, and some with free bandwidth upgrade.
Just got this from tequipmentQuoteEffective yesterday, any purchase of a MSO5000 oscilloscope will include the BUNDLE OPTION for FREE: https://www.tequipment.net/Rigol/MSO5000-BND/Options/ (https://www.tequipment.net/Rigol/MSO5000-BND/Options/)
Oscilloscopes purchased during the promotion period qualifies for a free bundle upgrade with registration. This option bundle enables all serial decode capabilities, power analysis, and the integrated function generator.
I wonder what this means.....
If they want to give something away I wish it would have been the overpriced logic probe. You know, the thing that makes an "MSO" an "MSO". Charging 40% the base cost of the scope is ridiculous.
https://www.tequipment.net/Rigol/PLA2216/Logic-Probes/ (https://www.tequipment.net/Rigol/PLA2216/Logic-Probes/)
but the trick with pressing "single" with the original firmware (01.01.04.04) from Rigol on USB-stick failed?
Oh, shit, I saw the same for-ever-boot-screen as Antlanpz, but the trick with pressing "single" with the original firmware (01.01.04.04) from Rigol on USB-stick failed? Are there any other suggestions to restore to factory default?
after entering "root" it writes to enter the password, but does not respond to typing, only to Enter.
Oh .. It turned out with a password! But he can not find either: "cp / rigol / appEntry / media / sda1 /" nor: "cd / media / sda1" I think and more ... :-[ What can I do? Thank!You are doing it wrong... there must be a space after cp.
Thank you, I realized it! But it is not clear in "Step 7". Do you need to register the path to the USB drive to create a "bspatch" file in it? Can you please for more details. Thank!Every file involved in the bspatch execution must be located in the same directory... I assume appEntry is in your USB drive, so yes... change directory to the USB drive where all the files are located before executing bspatch.
Oh, shit, I saw the same for-ever-boot-screen as Antlanpz, but the trick with pressing "single" with the original firmware (01.01.04.04) from Rigol on USB-stick failed? Are there any other suggestions to restore to factory default?
You should not need to do manual patching if you want to apply a bspatch. You can use my automatic patcher (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2704640/#msg2704640) to apply any patch you want. You will have to provide the proper checksums, which will be checked and the patch only applied if everything worked.
- after_patch_md5sum - change to value to the expected checksum after patch_file was applied to file_to_patch.
- after_patch_md5sum - change to value to the expected checksum after patch_file was applied to file_to_patch.
Where/how does one come up with this checksum?
Also instead of running strange third party software to compute a md5sum of a file on windows just do
CertUtil -hashfile appEntry MD5
in a command window
It is also possible to generate the MD5 checksum in windows, as delfinom pointed out in this message
Also instead of running strange third party software to compute a md5sum of a file on windows just do
CertUtil -hashfile appEntry MD5
in a command window
Or you can use hxd hex editor to find the md5 hash
Could someone please help?
I really don't have a notion about what I'm doing wrong...
Finally, the time arrives and I will trigger an order for 5072 or 5074
Are the new ones hackable same way, as the old ones?
Any terrifying problem that can void the new order plan?
Still the best Scope for 1K USD? ( assuming I will hack, and I will )
Finally, the time arrives and I will trigger an order for 5072 or 5074And Rigol has a promotion where you can get lots of the software options included for free (does not include BW upgrade, 4-channel in case you purchase 2-channel model and maybe some other options are not included in the promotion)... but you can still hack it and get all the options activated.
Are the new ones hackable same way, as the old ones?
Any terrifying problem that can void the new order plan?
Still the best Scope for 1K USD? ( assuming I will hack, and I will )
I got it from here and called it MABI.GEL just to make it simple during the bsdiff/bspatch process:
Or is it something even different?
The latest firmware got my interest due to fix the overshoot in the 4 channels, something that also seen in my scope in channels 3 and 4.
Being ungodly unblessed with any kind of hacking skills, I tried my best to follow the instructions given to other members and attached You can see what I got.
EDIT3:
The problematic calibration is lfcal.hex. Just replacing that file gives perfectly shaped squares again.
mabl, would it be possible for you to upload, or send to me, your working lfcal.hex?
See attached.I will check later to be sure, but I suspect that auto-cal does nothing... I have the overshoots on 3 channels and nothing changes when I use auto-cal. I even did it while I had input signals fed to all channels - the result didn’t change, everything looked as before, and I suppose that in that scenario the ‘scope should have lost calibration.
Cannot confirm. When using the default calibration, the spikes are less pronounced then after the autocalibration. Things do not change afterwards however.
Any ideas how I can fix this?
backup + FRAM: 2 minutes 40 seconds
NAND: not tested yet
Sorry, it is for TV84backup + FRAM: 2 minutes 40 seconds
NAND: not tested yet
I'm sorry, if this was to me, I'm not sure what you mean.
Hello,
I have full opetion mode version 01.01.04.04, does someone try to make the upgrade 01.01.04.08?
Do you always keep the full option?
Does anyone know why the FW update is still absent from the North America site?
And still absent in europe (rigol.eu), strange….
I´ve ask them about without getting an answer.
I´ll try again.
Could someone dump rights and ownership of /rigol/data directory and files (/rigol/data folder itself too). Thank you.
Hello!
Help patch. Did everything by intrusion above:
3 files on a flash drive, starting the update. Gives an error message:
Dear skander36 promptly helped! Many thanks to everyone!
You have to use LINUX line endings (not Windows) for patch.txt.I have used Windows (Notepad used) with no problem. Nothing edit with Linux .
Dear skander36 promptly helped! Many thanks to everyone!
Hi! Can you tell me how you hacked the oscilloscope? What was wrong with the three files? I just ordered the oscilloscope, haven't received it yet. Prepare)
This is just a play-by-play of what I did – I struggled my way through it so there are ways to run things more efficiently or better that I wasn’t aware of at the time.
Step 1: Get your Linux workstation functional, either by installing directly or running it within VirtualBox. I’m using a Windows PC so I’m running everything through VirtualBox, which just adds a couple intermediate steps.
Step 2: Get organized – I made 3 folders, “Upgrade”, “Enable SSH”, and “Patch”.
- In the Upgrade folder, download the 01.01.04.08 GEL from GitLab and rename it DS5000Update.GEL ([url]https://gitlab.com/riglol/rigolee/blob/MSO5000/GEL/DS5000Update_01.01.04.08.GEL[/url] ([url]https://gitlab.com/riglol/rigolee/blob/MSO5000/GEL/DS5000Update_01.01.04.08.GEL[/url]))
- In the Enable SSH folder, add the GEL file from this post and rename it DS5000Update.GEL ([url]https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076[/url] ([url]https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076[/url]))
- In the Patch folder, download the Bpatch folder from this post and remove the .txt extension ([url]https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2620701/#msg2620701[/url] ([url]https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2620701/#msg2620701[/url]))
Step 3: Upgrade the MSO5000 using the DS5000Update.GEL file from the Upgrade Folder. Put the file onto the root directory of the USB drive and then go to the Utility / System / Help / Local Upgade menu once you’ve put the USB into the MSO5000 and upgrade to 01.01.04.08. Restart the Oscilloscope
Step 4: Now time for the heavy lifting. Put the USB drive back into the computer and remove the update file you just used from the USB stick. Now go to the Enable SSH folder and put that DS5000Update.GEL file onto the USB drive. Put the USB stick into the MSO5000 and run the Local Upgrade again. Oh no, it failed! Except it didn’t, as @mabl stated in his post, it will look like it failed but it works. DO NOT RESTART THE OSCILLOSCOPE, otherwise you will have to run step 4 again. Also, leave the USB stick in the MSO5000 for the next steps.
Step 5: If it’s not already connected, connect your MSO5000 to your LAN or use a crossover cable if you have one to hook it to your computer. If all you have is “normal” LAN cables, you’ll need to use your router and can’t hook directly to your PC. Now go to the Utility/ IO / LAN menu and write down the IP address of your MSO5000.
Step 6: If it’s not already in your distro, go to the software manager and download Putty so that you can SSH (Secure Shell) across the network into your MSO5000. Once it’s downloaded, you’re going to follow some of the instructions from @TopLoser that @TrickTronic posted. First, run PuTTY and put the IP address into the IP window, use Port 22, and select SSH for your connection type. Then, use “root” as the username and “Rigol201” as the pwd. You’re now connected to the Oscilloscope.
Step 7: In the SSH, type (without quotes) “cp /rigol/appEntry /media/sda1/”. Once it’s finished writing it to the USB stick (although it’s probably not the “best” answer, just pull the USB stick out and put it back into your computer. Copy the bspatch file into the root of the USB stick as well. Right click and open a terminal window starting in the USB stick and type “bspatch appEntry appEntryPatched appEntry_01_01_04_08.bpatch” into the terminal. It will create you a new file called appEntryPatched. Rename the original file to appEntryUnpatched or something similar and then rename the patched file to appEntry. Now remove the USB stick and put it back into the Oscilloscope.
Step 8: I hope you kept your SSH open, if not then open it back up. Type “cd /media/sda1”. If the command fails, replace sda1 with sdb1. My MSO5000 mounted the USB drive into this second location when I put it back in. Type “ls” (LS in lower case if the font here sucks) to see the files in the directory. You should see your files. Now run “chmod +x appEntry” to allow the appEntry file to be an executable, otherwise it will not work. To make this next step easier, move back to the root directory using “cd /”. You can type “pwd” at any time in SSH or Terminal to see the directory you’re currently in at any time. Now copy the file back to the oscilloscope, “cp /media/sda1/appEntry /rigol/” and you should be good to go.
Step 9: Restart your Oscilloscope and don’t forget to thank the dozens of people on this forum who made this possible.
As long as the current fw. version 01.01.04.08 is available from Rigol site, the procedure for patching is simple .Thank you for recap, this worked really well, it's really as simple as that. Applied on MSO5074 01.01.04.04 factory firmware.
<SNIP>
But no ssh available to take a look on files, who needs since everything is hacked as expected
Yep.. :(
I´ve asked again on october 29th, answer was sorry for delaying but it should happen "soon".....
........................My biggest concern with buying this scope without updated FW is the trigger over shoot bug................................What trigger overshoot bug ?
The one Dave identify in his initial review video of the scope. This (https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/msg2677629/#msg2677629) post and the 3 after it discuss the problem and a "fix" that seems to work for some users.What does that have to do with triggering?
Martin 72 has Boris given you any indication of when the 5000 FW is going to updated at all?
I suspect now the 8000 is moving the 5000 fw upgrade will not be long now
Sighound36 was kind enough to loan me his time and new purchase so that I could try some model changes... :popcorn:
More to come later in the week.
A few questions about my DS7014:
Does the appEntry hack survive firmware upgrades?
Is it possible to downgrade the firmware to 01.01.04 from 01.01.06?
If so, where can I find a copy of the 01.01.04 firmware?
Thanks!
Hi,QuoteMartin 72 has Boris given you any indication of when the 5000 FW is going to updated at all?
In short form he "told" me "in a couple of days (at last) " .
This was on Nov26th.
Hi,QuoteMartin 72 has Boris given you any indication of when the 5000 FW is going to updated at all?
In short form he "told" me "in a couple of days (at last) " .
This was on Nov26th.
Asked today again, the launch date will be postponed until the end of january.. :palm: :--
Your guy's could confirm that a MSO5074 70 Mhz version could be upgraded to 350 Mhz? :popcorn:
Two quick questions:
1. If someone were to buy a scope to upgrade, can they buy the MSO5072 and end up with a MSO5354?
I just received a brand new 5072 today and come with the fw ver 01.01.04.08.
Those three files from skander36 are perfectly work.
I encountered a problem while using 16GB USB Drive. But it solved after replace with the 32GB USB Drive. It is highly recommend that you have prepared two or more different brand and size USB Drive before perform the upgrade. My failure one is Sandisk 16GB and workable one is Sandisk 32GB (Tiny one).
Case :
When you found that the USB Drive is empty except the GEL file after the backup process:
- Attach the USB drive back to the scope, press Storage/Disk
- If you found there are two or more USB Disk, it means that you may need to try another USB Drive.
Enclosed with all the files from skander36 and backup GEL file from TV84.
My workflow are :
(Please read carefully especially handle the same name GEL files).
1. Format the USB Drive (FAT32 Format);
2. Copy the DS5000Update.GEL.backup.doc to the USB Drive;
3. Rename it by delete the "backup.doc" extension;
4. Attach the USB Drive to scope;
5. Press Utility/System/Help/Local upgrade;
6. After finished the screen will have message told you to reboot the scope;
7. Turn off the scope;
8. Attach the USB drive back to your Mac / PC;
9. Copy all the file except the GEL files and folder back to your Mac / PC for your backup;
10. Format the USB Drive (FAT32 Format);
11. Copy another three files to the USB Drive, rename them by remove the ".doc" extension;
12. Attach the USB Drive back to the Scope, turn it on;
14. Wait for the screen shows that USB Drive was attached.
15. Press Utility/System/Help/Local upgrade
16. The screen will turn to white background and follow the instruction to press any keys.
17. After the upgrade process is finished, the scope will reboot.
18. Done! Enjoy!
Please correct me if any mistake or typo. Thanks!
Thank you so much for all of you to contribute here!
I have 00.01.01.020.03.
A big, "Thank you!" to everybody who contributed to this thread. You guys and gals are amazing.I say go ahead and write a post here giving your specific experience, people do it all the time and it is useful as it's otherwise necessary to go through pages of comments to see what worked for others and if anything got changed along the way.
I will say, the important info unnecessarily buried throughout the thread. But the process is quite painless once you figure it out. I thought about writing a definitive set of instructions. But that would probably just make it even more confusing for newcomers.
My last information was "probably end of january".
Finally Rigol acknowledging the use of Open Source in their latest products!!!!!!!!!!
MSO5000 example (https://eu.rigol.com/Public/Uploads/uploadfile/files/ftp/DS/MSO5000%20Open%20Source%20Acknowledgment.pdf)
::) well let's assume "acknowledgement" is what they meant.
And, if we could access the source code then that would be a killer factor! :popcorn:
And, if we could access the source code then that would be a killer factor! :popcorn:
It's only a matter of time before we, as a community, pick a relatively inexpensive "base" piece of DSO hardware and make it our own (as in, we maintain the firmware/software - they just compete on the best hardware). What DSO engineering company wouldn't want to be "chosen" by our community as the first hardware "base"? ...Certainly not Rigol - they just want to sell their hardware... and I'm half thinking (at least, in part) this is Rigol's modus operandi when it comes to the ease of hacking their scopes. I'm actually really surprised that a entire source code tree hasn't mysteriously "appeared" on the web to force some companies' sales into the stratosphere... and it would!
Finally Rigol acknowledging the use of Open Source in their latest products!!!!!!!!!!
MSO5000 example (https://eu.rigol.com/Public/Uploads/uploadfile/files/ftp/DS/MSO5000%20Open%20Source%20Acknowledgment.pdf)
::) well let's assume "acknowledgement" is what they meant.
And, if we could access the source code then that would be a killer factor! :popcorn:
Unfortunately, using open source software in their product is not as interesting as publishing theirs as open source. The software they use is pretty standard stuff (lighttpd, linux, lua, lxi, u-boot, etc.).
My last information was "probably end of january".
My last information was "probably end of january".
Chance to add the bode plot feature?
Hey, so not totally hacking related but if you bought your scope after 10/1/2019 Rigol will update your license for free.
Now, this does not include the bandwidth, but it enables all the serial decode capabilities, power analysis and also enables the function generator
https://beyondmeasure.rigoltech.com/acton/form/1579/0065:/0/index.htm?sid=TV2:U3tSfkw22 (https://beyondmeasure.rigoltech.com/acton/form/1579/0065:/0/index.htm?sid=TV2:U3tSfkw22)
As it is a promo, it does end on 3/30/2020
This is just a play-by-play of what I did – I struggled my way through it so there are ways to run things more efficiently or better that I wasn’t aware of at the time.Nice! My Rigol is dead!
Step 1: Get your Linux workstation functional, either by installing directly or running it within VirtualBox. I’m using a Windows PC so I’m running everything through VirtualBox, which just adds a couple intermediate steps.
Step 2: Get organized – I made 3 folders, “Upgrade”, “Enable SSH”, and “Patch”.
- In the Upgrade folder, download the 01.01.04.08 GEL from GitLab and rename it DS5000Update.GEL ([url]https://gitlab.com/riglol/rigolee/blob/MSO5000/GEL/DS5000Update_01.01.04.08.GEL[/url] ([url]https://gitlab.com/riglol/rigolee/blob/MSO5000/GEL/DS5000Update_01.01.04.08.GEL[/url]))
- In the Enable SSH folder, add the GEL file from this post and rename it DS5000Update.GEL ([url]https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076[/url] ([url]https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076[/url]))
- In the Patch folder, download the Bpatch folder from this post and remove the .txt extension ([url]https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2620701/#msg2620701[/url] ([url]https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2620701/#msg2620701[/url]))
Step 3: Upgrade the MSO5000 using the DS5000Update.GEL file from the Upgrade Folder. Put the file onto the root directory of the USB drive and then go to the Utility / System / Help / Local Upgade menu once you’ve put the USB into the MSO5000 and upgrade to 01.01.04.08. Restart the Oscilloscope
Step 4: Now time for the heavy lifting. Put the USB drive back into the computer and remove the update file you just used from the USB stick. Now go to the Enable SSH folder and put that DS5000Update.GEL file onto the USB drive. Put the USB stick into the MSO5000 and run the Local Upgrade again. Oh no, it failed! Except it didn’t, as @mabl stated in his post, it will look like it failed but it works. DO NOT RESTART THE OSCILLOSCOPE, otherwise you will have to run step 4 again. Also, leave the USB stick in the MSO5000 for the next steps.
Step 5: If it’s not already connected, connect your MSO5000 to your LAN or use a crossover cable if you have one to hook it to your computer. If all you have is “normal” LAN cables, you’ll need to use your router and can’t hook directly to your PC. Now go to the Utility/ IO / LAN menu and write down the IP address of your MSO5000.
Step 6: If it’s not already in your distro, go to the software manager and download Putty so that you can SSH (Secure Shell) across the network into your MSO5000. Once it’s downloaded, you’re going to follow some of the instructions from @TopLoser that @TrickTronic posted. First, run PuTTY and put the IP address into the IP window, use Port 22, and select SSH for your connection type. Then, use “root” as the username and “Rigol201” as the pwd. You’re now connected to the Oscilloscope.
Step 7: In the SSH, type (without quotes) “cp /rigol/appEntry /media/sda1/”. Once it’s finished writing it to the USB stick (although it’s probably not the “best” answer, just pull the USB stick out and put it back into your computer. Copy the bspatch file into the root of the USB stick as well. Right click and open a terminal window starting in the USB stick and type “bspatch appEntry appEntryPatched appEntry_01_01_04_08.bpatch” into the terminal. It will create you a new file called appEntryPatched. Rename the original file to appEntryUnpatched or something similar and then rename the patched file to appEntry. Now remove the USB stick and put it back into the Oscilloscope.
Step 8: I hope you kept your SSH open, if not then open it back up. Type “cd /media/sda1”. If the command fails, replace sda1 with sdb1. My MSO5000 mounted the USB drive into this second location when I put it back in. Type “ls” (LS in lower case if the font here sucks) to see the files in the directory. You should see your files. Now run “chmod +x appEntry” to allow the appEntry file to be an executable, otherwise it will not work. To make this next step easier, move back to the root directory using “cd /”. You can type “pwd” at any time in SSH or Terminal to see the directory you’re currently in at any time. Now copy the file back to the oscilloscope, “cp /media/sda1/appEntry /rigol/” and you should be good to go.
Step 9: Restart your Oscilloscope and don’t forget to thank the dozens of people on this forum who made this possible.
It is most probable that you made a mistake in one of the steps. I think there is a MAGIC button you can press while the scope powers up to recover it from bricked stateThis is just a play-by-play of what I did – I struggled my way through it so there are ways to run things more efficiently or better that I wasn’t aware of at the time.Nice! My Rigol is dead!
Step 1: Get your Linux workstation functional, either by installing directly or running it within VirtualBox. I’m using a Windows PC so I’m running everything through VirtualBox, which just adds a couple intermediate steps.
Step 2: Get organized – I made 3 folders, “Upgrade”, “Enable SSH”, and “Patch”.
- In the Upgrade folder, download the 01.01.04.08 GEL from GitLab and rename it DS5000Update.GEL ([url]https://gitlab.com/riglol/rigolee/blob/MSO5000/GEL/DS5000Update_01.01.04.08.GEL[/url] ([url]https://gitlab.com/riglol/rigolee/blob/MSO5000/GEL/DS5000Update_01.01.04.08.GEL[/url]))
- In the Enable SSH folder, add the GEL file from this post and rename it DS5000Update.GEL ([url]https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076[/url] ([url]https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2234076/#msg2234076[/url]))
- In the Patch folder, download the Bpatch folder from this post and remove the .txt extension ([url]https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2620701/#msg2620701[/url] ([url]https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2620701/#msg2620701[/url]))
Step 3: Upgrade the MSO5000 using the DS5000Update.GEL file from the Upgrade Folder. Put the file onto the root directory of the USB drive and then go to the Utility / System / Help / Local Upgade menu once you’ve put the USB into the MSO5000 and upgrade to 01.01.04.08. Restart the Oscilloscope
Step 4: Now time for the heavy lifting. Put the USB drive back into the computer and remove the update file you just used from the USB stick. Now go to the Enable SSH folder and put that DS5000Update.GEL file onto the USB drive. Put the USB stick into the MSO5000 and run the Local Upgrade again. Oh no, it failed! Except it didn’t, as @mabl stated in his post, it will look like it failed but it works. DO NOT RESTART THE OSCILLOSCOPE, otherwise you will have to run step 4 again. Also, leave the USB stick in the MSO5000 for the next steps.
Step 5: If it’s not already connected, connect your MSO5000 to your LAN or use a crossover cable if you have one to hook it to your computer. If all you have is “normal” LAN cables, you’ll need to use your router and can’t hook directly to your PC. Now go to the Utility/ IO / LAN menu and write down the IP address of your MSO5000.
Step 6: If it’s not already in your distro, go to the software manager and download Putty so that you can SSH (Secure Shell) across the network into your MSO5000. Once it’s downloaded, you’re going to follow some of the instructions from @TopLoser that @TrickTronic posted. First, run PuTTY and put the IP address into the IP window, use Port 22, and select SSH for your connection type. Then, use “root” as the username and “Rigol201” as the pwd. You’re now connected to the Oscilloscope.
Step 7: In the SSH, type (without quotes) “cp /rigol/appEntry /media/sda1/”. Once it’s finished writing it to the USB stick (although it’s probably not the “best” answer, just pull the USB stick out and put it back into your computer. Copy the bspatch file into the root of the USB stick as well. Right click and open a terminal window starting in the USB stick and type “bspatch appEntry appEntryPatched appEntry_01_01_04_08.bpatch” into the terminal. It will create you a new file called appEntryPatched. Rename the original file to appEntryUnpatched or something similar and then rename the patched file to appEntry. Now remove the USB stick and put it back into the Oscilloscope.
Step 8: I hope you kept your SSH open, if not then open it back up. Type “cd /media/sda1”. If the command fails, replace sda1 with sdb1. My MSO5000 mounted the USB drive into this second location when I put it back in. Type “ls” (LS in lower case if the font here sucks) to see the files in the directory. You should see your files. Now run “chmod +x appEntry” to allow the appEntry file to be an executable, otherwise it will not work. To make this next step easier, move back to the root directory using “cd /”. You can type “pwd” at any time in SSH or Terminal to see the directory you’re currently in at any time. Now copy the file back to the oscilloscope, “cp /media/sda1/appEntry /rigol/” and you should be good to go.
Step 9: Restart your Oscilloscope and don’t forget to thank the dozens of people on this forum who made this possible.
Patch not work for my Rigol...Current firmware available is 00.01.01.04.08 . It is from august 2019 .
I have downloaded new firmware from the official Rigol web. Maybe there's new protection. ???
Cust
EDIT: I have FFT, I have some features... I do not understand that.
You mean:
1) downgrade to version 1.04.04
2) upgrade by "DS5000Update_patch_01_01_04_04_usb.GEL"
3) upgrade to version 1.08.08
ufff, my MSO has BW 350 MHz :-)You mean:
1) downgrade to version 1.04.04
2) upgrade by "DS5000Update_patch_01_01_04_04_usb.GEL"
3) upgrade to version 1.08.08
He is saying you might be applying the 1.04.04 patch to the 1.04.08 firmware which won't work.
Follow the instructions posted recently here, try again from scratch get rid of whatever files you have. Make sure ethernet cable is unplugged from oscilloscope, in case that is interfering with bootup.
If you are on 1.04.08 and its working then no downgrading/upgrading/etc is needed.
My last information was "probably end of january".
Chance to add the bode plot feature?
Once they (rigol EU support) told me clearly, bode will come.
But they did it in may 2019.
Now we got january 2020 and still there´s no update.
v00.01.01.04.08 2019/08/02
-Fixed system crashed when clicking Default.
-Fixed 4CH option bug.
-Fixed noise signal captured.
-Improved the measure result updating rate.
-Fixed accurate measurements not updated in ROLL
Can´t believe it:Quotev00.01.01.04.08 2019/08/02
-Fixed system crashed when clicking Default.
-Fixed 4CH option bug.
-Fixed noise signal captured.
-Improved the measure result updating rate.
-Fixed accurate measurements not updated in ROLL
Old known things...
Hello , anybody know if there is a software that can control the AWG in MSO5000 ?
Thank you !
#disable generator
gen.write(':source1:output1 0')
print(gen.query(':source1:output?'))
#Set generator output 1 voltage/frequency sine wave
gen.write(':source1:volt 1')
gen.write(':source1:freq 1000')
gen.write(':source1:function sin')
gen.write(':source1:voltage:offset 0')
#enable generator output
gen.write(':source1:output1 1')
#normal or precision measurement
gen.write(':measure:mode normal')
gen.write(':measure:source channel1')
#Memory depth
gen.write(':acq:type aver')
gen.write(':acq:averages 4')
gen.write(':acq:mdepth 100k')
print('Settings: ' + gen.query(':source1:apply?'))
gen.write(':measure:source channel1')
Thanks ,
I know about pyvisa aproach .I used it for a FFT on Rigol DS2000. In fact if we combine this two and a some UI we can create a FRA app .
Next step, port the code to QT and integrate into MSO 5000 firmware ... ;D
The reality is that Rigol has launched this new line of scopes without a proper PC software applications that can use new functions aboard on this .
All of their PC software is garbage IMO. I wouldn't expect anything less.
Their SCPI however, is incredibly well documented, broad, and for the most part works.
I agree there is potential for FRA, bode plots, quadrature modulation (?), etc. which can be more convenient to do in a single instrument. I'm working on a board to amplify the 2 channel gen to 2x the current voltage, but there are many more things you could think of to do with 2 outputs and 4 inputs. Another idea I have is measuring one channel current and one voltage.
Backup scripts for Rigol MSO5000 and MSO/DS7000
Attached is a .GEL that does a backup of the /rigol/data directory and the 8 kB FRAM memory. Run as a normal update.
It also does a memdump (450MB) so you should use a USB disk with size >= 512 MB. (Why this one? Because sometimes its useful... ;) )
With /rigol/data and FRAM, we can recreate the scope from scratch (as long as the bootloader is OK).
If anyone tests the script, please report the results and how much time it took.
Edit1: Added a .GEL that does a backup of the full NAND (mt0->mt12). Since the NAND is 1 GB in size, you must be patient! It could take some minutes.
* Rigol_MSO5000_7000_backup_scripts.zip (1.4 kB - downloaded 288 times.)
* Rigol_MSO5000_7000_NAND_backup_scripts.zip (2.1 kB - downloaded 204 times.)
« Last Edit: October 28, 2019, 03:23:02 pm by tv84 »
For example, if the program of oscilloscope will crash or the instrument will be repaired, how can I write saved backups of FRAM, NAND and / rigol / data back to the device? I rarely had to do this before. Please tell me the steps by step to know to do this. On my PC Windows 7, PuTTY and Ultra Sigma are installed. The scope is connected to a PC via USB, and can be connected via LAN.
Having just sold my Keysight MSO7104B, I'm thinking of a MSO5074. A few questions:
1. What is the serial decode like? Is it hardware or software based? Either way, is it any good?
2. What alternatives, if any, has anyone figured out for the $360 PLA2216 logic probe accessory?
3. Is there still an offer to get official free serial decode options?
Thanks in advance.
... one step removed from understanding cuneiform.
About the screen , everyone complain about , but mine is very bright , I did not feel the need to make it brighter . It was aquired in Octomber 2019 .
The UI is laggy indeed but not so laggy as DS1054 with all 4 channels activated.
Also it does not have a software companion . You need to use Ultra Scope which is not updated for the new series 5x/7x/8x .
You can still get bundle promo until end of march : Keysight MSO7104B https://www.rigolna.com/promos/ (https://www.rigolna.com/promos/)
:-+
LOL Keysight... ^-^
|O
yeap, I removed it now . It was on my clipboard . I searched for it .
I still don't understand how one may want to get rid of such scope and turn to a Rigol ....
sorry for offtopic .
Has anyone created a DIY LA harness?
Thanks in advance.
Read the probe thread carefully, apparently there is a lot of noise from the homemade probes, and the cost is not low, probably only 50% of the cost of the original one. And most of the published PCB files has mistakes on them.
Has anyone created a DIY LA harness?
Thanks in advance.
Yes there is such of thing :
https://www.eevblog.com/forum/testgear/rpl1116-active-logic-probe-pod-for-1000z-series-teardown/msg2908500/#msg2908500 (https://www.eevblog.com/forum/testgear/rpl1116-active-logic-probe-pod-for-1000z-series-teardown/msg2908500/#msg2908500)
Yeah, I read through that thread and thought it would be better to buy the Rigol original. Thanks.
Yeah but they were getting wrapped around the axles on detail like balanced pair routing and equal length tracks; it's a 350 MHz scope at which frequency the wavelength is 0.86 meters and the logic signals would probably not go over 100 MHz anyway.Yeah, I read through that thread and thought it would be better to buy the Rigol original. Thanks.
There's a lot more to those adapters than just a few cables. I'm not saying they cost $300 to manufacture but making your own isn't for the faint-hearted.
Yeah but they were getting wrapped around the axles on detail like balanced pair routing and equal length tracks; it's a 350 MHz scope at which frequency the wavelength is 0.86 meters and the logic signals would probably not go over 100 MHz anyway.
I think a much simpler design with less exotic buffers and standard 0.05" ribbon cable would work just fine.
Read the probe thread carefully, apparently there is a lot of noise from the homemade probes, and the cost is not low, probably only 50% of the cost of the original one. And most of the published PCB files has mistakes on them.
Can someone please do us new purchasers a favor and make a summary comment on the latest state of play with regards to hacking? I am ready to buy an MSO5074 but looking through the thread I'm confused as to the latest recommended best practice approach.
Thanks :D
[EDIT] Is post #933 still the latest to follow?
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2251401/#msg2251401 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2251401/#msg2251401)
md5sum of appEntry before patching | afe3e7c2d38bdebb66d3f1f11d910743 |
md5sum of appEntry after patching | 3f95cb3236b47826e303de960596f966 |
Rigol had updated the V00.01.02.00.02 firmwire for MSO5000 few days ago. Does anyone use this latest version?Yeah , but doesn't seem to worth loosing "upgrades".
[Supported Model] All the MSO5000 Series Digital Oscilloscopes
[Latest Revision Date] 2020/02/25
[Updated Contents]
--------------------
v00.01.02.00.02 2020/02/25
- Optimized the connection HDMI start problem optimized the connection HDMI start problem
- Optimize the vertical gear, channel zero elimination error
- Optimization of the inconsistency between SPI CLK and SDA names
- Zoom mode square wave display in optimized 2S time base
- Added command to get pass / fail times
- Delete the default email account and password
- Problems in remote instructions are optimized
- Optimized 1K storage depth, waveform recording
- The problem of too many stuck events in optimized decoding
- Delete the default email account and password
I afraid they are referring to the email feature documented in the manual, not the undocumented phone home feature. Who knows, they might actually have fixed the undocumented one :-DD
Any chance you can work on a new patch file for this version?
So perhaps your last email to them using the hidden ID actually made it through.I actually attached a patch just like that for the .08 firmware miles back. It just seems everyone ignored it. :-//
When you create the patch, it would definitely be a good idea to create a version with disabled ET phone home, it just opens such a security hole in the lab network. The scope should have no business emailing Rigol anything without a user’s knowledge.
Hey delfinom,
A big thank as usual, did you notice any new options or notable changes in the firmware?
No warranties.
Before: 78d71292a1828ee597a341bd14797e18
After: 86d162a29297ae03af88a6d8f7c40247
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: firmware/fw4linux.sh
modified: firmware/fw4uboot.sh
modified: firmware/logo.png
modified: firmware/rootfs/rigol/K160M_TOP.bit
modified: firmware/rootfs/rigol/appEntry
modified: firmware/rootfs/rigol/resource/help/b/chan1.hlp
modified: firmware/rootfs/rigol/resource/help/b/display.hlp
modified: firmware/rootfs/rigol/resource/help/b/email.hlp
modified: firmware/rootfs/rigol/resource/help/b/help.hlp
modified: firmware/rootfs/rigol/resource/help/b/horizontal.hlp
modified: firmware/rootfs/rigol/resource/help/b/storage.hlp
modified: firmware/rootfs/rigol/resource/help/b/trigger.hlp
modified: firmware/rootfs/rigol/resource/help/d/chan1.hlp
modified: firmware/rootfs/rigol/resource/help/d/display.hlp
modified: firmware/rootfs/rigol/resource/help/d/help.hlp
modified: firmware/rootfs/rigol/resource/help/d/horizontal.hlp
modified: firmware/rootfs/rigol/resource/help/d/storage.hlp
modified: firmware/rootfs/rigol/resource/help/d/trigger.hlp
modified: firmware/rootfs/rigol/resource/menu/b.hex
modified: firmware/rootfs/rigol/resource/menu/c.hex
modified: firmware/rootfs/rigol/resource/menu/d.hex
modified: firmware/rootfs/rigol/resource/menu/desc.hex
modified: firmware/rootfs/rigol/resource/menu/h.hex
modified: firmware/rootfs/rigol/resource/menu/i.hex
modified: firmware/rootfs/rigol/resource/menu/j.hex
modified: firmware/rootfs/rigol/resource/menu/k.hex
modified: firmware/rootfs/rigol/resource/menu/l.hex
modified: firmware/rootfs/rigol/resource/menu/m.hex
modified: firmware/rootfs/rigol/resource/menu/menu.hex
modified: firmware/rootfs/rigol/resource/menu/modelconfig_ch.hex
modified: firmware/rootfs/rigol/resource/menu/modelconfig_ext.hex
modified: firmware/rootfs/rigol/resource/menu/msg.h
modified: firmware/rootfs/rigol/resource/menu/n.hex
modified: firmware/rootfs/rigol/resource/menu/o.hex
modified: firmware/rootfs/rigol/resource/menu/pic.hex
modified: firmware/rootfs/rigol/resource/menu/res.hex
modified: firmware/rootfs/rigol/resource/menu/t.hex
modified: firmware/rootfs/rigol/resource/menu/u.hex
modified: firmware/rootfs/rigol/resource/scpi/ACQuire.xml
modified: firmware/rootfs/rigol/resource/scpi/CHANnel1.xml
modified: firmware/rootfs/rigol/resource/scpi/CHANnel2.xml
modified: firmware/rootfs/rigol/resource/scpi/CHANnel3.xml
modified: firmware/rootfs/rigol/resource/scpi/CHANnel4.xml
modified: firmware/rootfs/rigol/resource/scpi/COMMon.xml
modified: firmware/rootfs/rigol/resource/scpi/DISPlay.xml
modified: firmware/rootfs/rigol/resource/scpi/LA.xml
modified: firmware/rootfs/rigol/resource/scpi/LAN.xml
modified: firmware/rootfs/rigol/resource/scpi/MASK.xml
modified: firmware/rootfs/rigol/resource/scpi/MATH1.xml
modified: firmware/rootfs/rigol/resource/scpi/MATH2.xml
modified: firmware/rootfs/rigol/resource/scpi/MATH3.xml
modified: firmware/rootfs/rigol/resource/scpi/MATH4.xml
modified: firmware/rootfs/rigol/resource/scpi/REF.xml
modified: firmware/rootfs/rigol/resource/scpi/SAVE.xml
modified: firmware/rootfs/rigol/resource/scpi/SOURce.xml
modified: firmware/rootfs/rigol/resource/scpi/SOURce1.xml
modified: firmware/rootfs/rigol/resource/scpi/SOURce2.xml
modified: firmware/rootfs/rigol/resource/scpi/SYSTem.xml
modified: firmware/rootfs/rigol/resource/scpi/TIMebase.xml
modified: firmware/rootfs/rigol/resource/scpi/TRIGger.xml
modified: firmware/rootfs/rigol/resource/scpi/compatible/BUS1.xml
modified: firmware/rootfs/rigol/resource/scpi/compatible/BUS2.xml
modified: firmware/rootfs/rigol/resource/scpi/compatible/BUS3.xml
modified: firmware/rootfs/rigol/resource/scpi/compatible/BUS4.xml
modified: firmware/rootfs/rigol/resource/scpi/compatible/DISPlay.xml
modified: firmware/rootfs/rigol/resource/scpi/compatible/LA.xml
modified: firmware/rootfs/rigol/resource/scpi/compatible/MEASure.xml
modified: firmware/rootfs/rigol/resource/scpi/compatible/REF.xml
deleted: firmware/rootfs/rigol/resource/scpi/compatible/Ref.xml
modified: firmware/rootfs/rigol/resource/scpi/compatible/SYSTem.xml
modified: firmware/rootfs/rigol/resource/scpi/compatible/TIMebase.xml
modified: firmware/rootfs/rigol/resource/scpi/compatible/TRIGger.xml
deleted: firmware/rootfs/rigol/resource/scpi/compatible/common.xml
deleted: firmware/rootfs/rigol/resource/scpi/compatible/cursor.xml
deleted: firmware/rootfs/rigol/resource/scpi/compatible/quick.xml
modified: firmware/rootfs/rigol/resource/scpi/scpiConfig.xml
deleted: firmware/rootfs/rigol/webcontrol/config/conf.d/Makefile
deleted: firmware/rootfs/rigol/webcontrol/config/conf.d/Makefile.am
deleted: firmware/rootfs/rigol/webcontrol/config/conf.d/Makefile.in
deleted: firmware/rootfs/rigol/webcontrol/include/openssl/ui_compat.h
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/AUTHORS
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/COPYING
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/ChangeLog
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/LICENCE
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/NEWS
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/README
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/index.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre-config.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_compile.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_compile2.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_config.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_copy_named_substring.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_copy_substring.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_dfa_exec.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_exec.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_free_substring.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_free_substring_list.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_fullinfo.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_get_named_substring.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_get_stringnumber.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_get_stringtable_entries.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_get_substring.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_get_substring_list.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_info.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_maketables.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_refcount.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_study.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcre_version.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcreapi.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcrebuild.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcrecallout.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcrecompat.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcrecpp.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcredemo.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcregrep.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcrematching.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcrepartial.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcrepattern.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcreperform.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcreposix.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcreprecompile.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcresample.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcrestack.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcresyntax.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/html/pcretest.html
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/pcre-config.txt
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/pcre.txt
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/pcregrep.txt
deleted: firmware/rootfs/rigol/webcontrol/share/doc/pcre/pcretest.txt
Untracked files:
(use "git add <file>..." to include in what will be committed)
firmware/rootfs/rigol/cups/testPage.bmp
firmware/rootfs/rigol/resource/help/b/CVS/
firmware/rootfs/rigol/resource/help/d/CVS/
firmware/rootfs/rigol/resource/help/picture/CVS/
firmware/rootfs/rigol/resource/help/picture/autoset/CVS/
firmware/rootfs/rigol/resource/help/picture/chan1/
firmware/rootfs/rigol/resource/help/picture/counter/
firmware/rootfs/rigol/resource/help/picture/cursor/CVS/
firmware/rootfs/rigol/resource/help/picture/display/
firmware/rootfs/rigol/resource/help/picture/dvm/
firmware/rootfs/rigol/resource/help/picture/email/
firmware/rootfs/rigol/resource/help/picture/eyejit/CVS/
firmware/rootfs/rigol/resource/help/picture/help/
firmware/rootfs/rigol/resource/help/picture/horizontal/
firmware/rootfs/rigol/resource/help/picture/ioset/
firmware/rootfs/rigol/resource/help/picture/la/CVS/
firmware/rootfs/rigol/resource/help/picture/mask/CVS/
firmware/rootfs/rigol/resource/help/picture/math/CVS/
firmware/rootfs/rigol/resource/help/picture/mathsel/
firmware/rootfs/rigol/resource/help/picture/measure/CVS/
firmware/rootfs/rigol/resource/help/picture/print/
firmware/rootfs/rigol/resource/help/picture/quick/
firmware/rootfs/rigol/resource/help/picture/record/
firmware/rootfs/rigol/resource/help/picture/ref/CVS/
firmware/rootfs/rigol/resource/help/picture/search/
firmware/rootfs/rigol/resource/help/picture/selfcal/
firmware/rootfs/rigol/resource/help/picture/source/CVS/
firmware/rootfs/rigol/resource/help/picture/trigger/CVS/
firmware/rootfs/rigol/resource/help/picture/upa/CVS/
firmware/rootfs/rigol/resource/help/picture/utility/
firmware/rootfs/rigol/resource/help/picture/vdecode/CVS/
firmware/rootfs/rigol/resource/help/picture/vdecodesel/
firmware/rootfs/rigol/resource/help/picture/wifi/
firmware/rootfs/rigol/tools/cfg_gtp
Changes to the file system:
Did anyone noticed a new script added on the latest FW ("/rigol/tools/cfg_gtp")?
Checked MSO7000 / 5000 / 8000 series & this script exists on all.
Checked on IDA & it looks very suspicious as on execution it writes to /dev/i2c-0 with an increment constant data.
Worth writing a small script to backup this registry (just in case) as it may contain valuable data which would be overwritten by this script.
It does have a getter method but it's never called.
On nandboot there is a call to "checkGTP".
Can this all mean that this script may be included for a purpose of locking down hacked scopes ?
Can somebody check this theory, or brave enough try to run it ? :)
An interesting line found on MSO8000 fw4linux.sh script:
Chinese (Original):
#checkGTP;金手指里面已经执行了GTP配置,普通启动取消该配置,由于8000一台机器发现这里导致无法启动
Translation:
#checkGTP; GTP configuration has been performed in cheat. Normal configuration cancels the configuration. 8000 machines found it and failed to start.
So "checkGTP" is disabled on MSO8000 because it fails to start due to a false trigger on GTP configuration.
This increase my concerns on a new added script.
#Checkgtp: GTP configuration has been executed in goldfinger. It is cancelled during normal startup. Because 8000 machines find this, they cannot startGoldFinger is simply their name for the ASIC I think, they even have a JTAG header for it named Goldfinger
Just don't forget that scope have a magic "call home" function & capability to execute any shell command i.e. sshd.
This combination can lead to a locked scope. It's better to be cautious & be critical on the changes found on new FW's.
So, can we use the current patch for the new firmware? Do we need to edit the patch file? Thanks - I'm on firmware 00.01.02.00.02
Do I need to downgrade firmware?
Thank you
The only safe option is to buy a license.
So regarding recently discussed GTP thing would say it's something to look at in more details, but it should be safe as #delfinom already tested & confirmed that no "fireworks" had been rendered on the scope after execution.
I own MSO7000 so the patch is not available for my device yet & as I can't see any major improvement on the new FW I'll postpone upgrade on my device.
Just an additional 2 cents:
We can even recreate a FRAM from scratch so I think there are no reasons for elevating the DEFCON level.
We can even recreate a FRAM from scratch so I think there are no reasons for elevating the DEFCON level.
We can even recreate a FRAM from scratch so I think there are no reasons for elevating the DEFCON level.
Point of clarification: DEFCON means Defense Readiness Condition. So you lower the DEFCON level when closer to danger, not elevate it. 8)
I thought that only meant defcon one was Tautech was on the prowl :-DDWho me ? Always ! >:D
https://www.temcom.com/instruments-presented-by-rigol-at-embedded-world-2020/ (https://www.temcom.com/instruments-presented-by-rigol-at-embedded-world-2020/)From the same source: Both series (MSO8000 and MSO5000) have been expanded with a 12-bit high resolution mode.
"As a further novelty, the BodePlot function has now been integrated in all MSO5000 series oscilloscopes as an addition to the existing standard application."
Can anybody confirm the Bodeplot function ?
We can even recreate a FRAM from scratch so I think there are no reasons for elevating the DEFCON level.
Point of clarification: DEFCON means Defense Readiness Condition. So you lower the DEFCON level when closer to danger, not elevate it. 8)
We can even recreate a FRAM from scratch so I think there are no reasons for elevating the DEFCON level.
Point of clarification: DEFCON means Defense Readiness Condition. So you lower the DEFCON level when closer to danger, not elevate it. 8)
DEFCON 1 is at the top of the list so you go upwards towards it.
The scope doesn't have any mechanism to check if it's an "official" or "unofficial" license.
The scope doesn't have any mechanism to check if it's an "official" or "unofficial" license.
There is no way to be sure of that! There are plenty of possibilities they could use to detect if the firmware is modded.
BTW, with a full NAND backup you can reflash any of theses MSOs from scratch as long as you have your bootloader healthy.
Well, but thats definitely not true because of the e-fuses:BTW, with a full NAND backup you can reflash any of theses MSOs from scratch as long as you have your bootloader healthy.
They seem to hide that stuff pretty good from a disassembler.
All I'm saying is that there are ways for rigol in which this is not true and one could loose warranty forever. Once written eFuses cannot be cleared again. There are many cases where manufacturers in the past used eFuses to prevent warranty service (Samsung Knox e.g.)
1.02.00.02 patch
Before: 78d71292a1828ee597a341bd14797e18
After: 86d162a29297ae03af88a6d8f7c40247
Has anyone done the 01.02.00.02? Can you please confirm that the steps above are the correct ones?
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2963402/#msg2963402 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2963402/#msg2963402)
Well done! Do you now get channel 3 coming on even if you have nothing attached to it when you press Auto (if you have a signal on channel 1)? So far, this appears to be a major bug they introduced in the new firmware, but I don’t know if this is affecting all scopes, mine has 1.00.00 hardware.
If that is the case with you as well, my personal recommendations is not to upgrade until they fix the Auto problem, unless you see something in the small fix list that you need.
No idea how the “in your face” Auto problem ever pass any QA test in Rigol.
Has anyone done the 01.02.00.02? Can you please confirm that the steps above are the correct ones?
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2963402/#msg2963402 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2963402/#msg2963402)
Similar patch as in the exact same patch?
Similar patch as in the exact same patch?
Similar, as in opened-up a disassembler, looking at the chances and applying a similar modification to the slightly moved functions version in the new firmware. So not the exact same patch. ;) I just wanted to encourage everyone to look at the newest firmware.
Also, I would like to stress that my patcher will check the MD5 sumes before and after the patch. So it is very hard to corrupt the system using it.
So it is very hard to corrupt the system using it.
So it is very hard to corrupt the system using it.
Assuming that the patch is well done... ;) A faulty patch with correct hashes will still not work. (just decided to nitpick a bit... :) )
So it is very hard to corrupt the system using it.
Assuming that the patch is well done... ;) A faulty patch with correct hashes will still not work. (just decided to nitpick a bit... :) )
Haha right you are. It assumes the patch is good. I was implicitly thinking people would develop and test their patches via SSH. But funny enough, I did my patch on 00.01.02.00.03 and directly used the patcher, and only while patching realized what I was doing without much of a safety net. It worked, but in the worst case scenario I would have had to reflash from the bootloader.
Hello. I bought an oscilloscope with firmware 00.01.02.00.03 tell me how to patch it?
Is it possible to flash on top of 00.01.02.00.03 patched 00.01.02.00.02?
Hi , congratulations !
....
But I have a question , as I have seen that on the other thread there is another who show the oscilloscope options panel . Why you aren't get MSO Bundle license (Serial Decoding , WaveGEN,PWR analisys) . It was supposed to be until the end of march valid. You acquired in April ?
I got my bundle license the day after I filled out the form. I'm in the US if it matters.When did you send the request?
I just filled the form from rigol webpage
waiting for answer
I sent request twice (january and marth) and no answer..
Please, reply if you got answer.
I got my bundle license the day after I filled out the form. I'm in the US if it matters.When did you send the request?
Folks, Before I pull the trigger on the entry level 5000 I wanted to be sure that "improvements" in this thread will still work with current firmware. Should I still be able to implement these?
Cheers...Doug
Yes, it is possible to hack the latest firmware.Can you share the recipe?
Yes, it is possible to hack the latest firmware.Can you share the recipe?
These steps worked fine for meIs the medicine for 01.01.04.08 suitable for 01.02.00.03 without changes? Are the checksums the same?
I know this is a long thread guys, but all the answers are here, most of them with in the last 3 pages. Just gotta read a bit ;)I read the whole topic. And now separately the last 4 pages. There is a solution for version 02. And the mention that there is a cure for version 03. But there is no cure. Or am I stupid enough :(
I know this is a long thread guys, but all the answers are here, most of them with in the last 3 pages. Just gotta read a bit ;)I read the whole topic. And now separately the last 4 pages. There is a solution for version 02. And the mention that there is a cure for version 03. But there is no cure. Or am I stupid enough :(
[Edited] Has anyone done the 01.02.00.02? Can you please confirm that the steps below are the correct ones?
I've read the entire post. So far I've done:
1) Updated to v01.02.00.02
2) Downloaded 01.02.00.02.bspatch from Post #1558 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2943152/#msg2943152). Removed .txt extension
3) Downloaded Patch.txt from Post #1451 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2833308/#msg2833308)
4) Edited the before and after md5sum in the patch.txt file to Before: 78d71292a1828ee597a341bd14797e18 After: 86d162a29297ae03af88a6d8f7c40247 as described in Post #1558 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2943152/#msg2943152). This should correspond to the new v01.02.00.02.
5) Put DS5000Update.GEL (the v01.02.00.02 firmware), patch.txt, and 01.02.00.02.bspatch on a USB drive formatted for FAT32.
6) Performed a local update from the scope by going to Utility -> System -> Help -> Local Update
7) The firmware updates fine and says to reboot - but after I restart none of the upgrades are enabled - for example if I select channel 3 it says "This function requires the following license..."
8] Decided to try to install v01.01.04.08 firmware since it's the most recent 'stable' version (then I could try the well-known working v01.01.04.08 hack/patch). Downloaded the old firmware version from Github (https://gitlab.com/riglol/rigolee/-/tree/MSO5000/GEL). However when I try to update the scope says "Failed to Upgrade. Check the File". This is the official file from Rigol that was simply reposed to Github for safe-keeping. Early pages from this thread state that the firmware can't be downgraded, so I guess those of us with units shipped with v01.02.00.02 and above will have to wait for a working method?
Can someone attach a screenshot of Bode plot function ;Dhttps://www.eevblog.com/forum/testgear/rigol-mso-5000-hardwaresoftware-revisions/msg3021120/#msg3021120 (https://www.eevblog.com/forum/testgear/rigol-mso-5000-hardwaresoftware-revisions/msg3021120/#msg3021120)
Can someone attach a screenshot of Bode plot function ;Dhttps://www.eevblog.com/forum/testgear/rigol-mso-5000-hardwaresoftware-revisions/msg3021120/#msg3021120 (https://www.eevblog.com/forum/testgear/rigol-mso-5000-hardwaresoftware-revisions/msg3021120/#msg3021120)
Here's a patch for 01.03.00.01.
Before: 2efa4605b83bf1af48bf6736bfae3255
After: 965a689e7e5f29c180db4a2aaf21ce6b
Thank you! But, can anyone make full instruction for 01.03.00.01?Here's a patch for 01.03.00.01.
Before: 2efa4605b83bf1af48bf6736bfae3255
After: 965a689e7e5f29c180db4a2aaf21ce6b
Here is another flavor of patch for 01.03.00.01 that will disable the "phone home" firmware upgrade check in addition to enabling options.
Thank you! But, can anyone make full instruction for 01.03.00.01?Here's a patch for 01.03.00.01.
Before: 2efa4605b83bf1af48bf6736bfae3255
After: 965a689e7e5f29c180db4a2aaf21ce6b
Here is another flavor of patch for 01.03.00.01 that will disable the "phone home" firmware upgrade check in addition to enabling options.
Hm,
I think your (typoknig) patch is not working right.
I updated to 1.3 and it was working. Then i sshed in and grabbed appEntry. Checked the md5sums and then i applied your patch on my linux machine. Checked md5sum again. Patched appEntry has correct md5sum. I did chmod +x appEntry and copied back onto the scope.
But now it is not starting up anymore. Think i have to apply the original patch again...
Maybe i have to check again spelling and chmod but i think it was correct..
-rwxr-xr-x 1 root root 22558088 Apr 19 07:00 appEntry
... Checked the md5sums and then i applied your patch on my linux machine. Checked md5sum again. Patched appEntry has correct md5sum. I did chmod +x appEntry and copied back onto the scope.
But now it is not starting up anymore. Think i have to apply the original patch again...
Hm,
I think your (typoknig) patch is not working right.
I updated to 1.3 and it was working. Then i sshed in and grabbed appEntry. Checked the md5sums and then i applied your patch on my linux machine. Checked md5sum again. Patched appEntry has correct md5sum. I did chmod +x appEntry and copied back onto the scope.
But now it is not starting up anymore. Think i have to apply the original patch again...
Maybe i have to check again spelling and chmod but i think it was correct..
Using SSH to apply the patch isn't necessary. Just use the DS5000Update.GEL.doc file from this post (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2833308/#msg2833308). I have re-attached it here for convenience.
The permissions, owner, and group of appEntry should be 0755, root, and root respectively. It will look like this when correct:Code: [Select]-rwxr-xr-x 1 root root 22558088 Apr 19 07:00 appEntry
Here's a patch for 01.03.00.01.
Before: 2efa4605b83bf1af48bf6736bfae3255
After: 965a689e7e5f29c180db4a2aaf21ce6b
Here is another flavor of patch for 01.03.00.01 that will disable the "phone home" firmware upgrade check in addition to enabling options.
Here's a patch for 01.03.00.01.
Before: 2efa4605b83bf1af48bf6736bfae3255
After: 965a689e7e5f29c180db4a2aaf21ce6b
Here is another flavor of patch for 01.03.00.01 that will disable the "phone home" firmware upgrade check in addition to enabling options.
I've applied this particular version of the patch for 01.03.00.01 and, just to give others comfort, it all seems to be working as intended.
Here's a patch for 01.03.00.01.
Before: 2efa4605b83bf1af48bf6736bfae3255
After: 965a689e7e5f29c180db4a2aaf21ce6b
Here is another flavor of patch for 01.03.00.01 that will disable the "phone home" firmware upgrade check in addition to enabling options.
I've applied this particular version of the patch for 01.03.00.01 and, just to give others comfort, it all seems to be working as intended.
I find it a bit strange that the updated firmware seems to be available only on the Rigol NA site, not on intl or EU.
Here's a patch for 01.03.00.01.
Before: 2efa4605b83bf1af48bf6736bfae3255
After: 965a689e7e5f29c180db4a2aaf21ce6b
Here is another flavor of patch for 01.03.00.01 that will disable the "phone home" firmware upgrade check in addition to enabling options.
I've applied this particular version of the patch for 01.03.00.01 and, just to give others comfort, it all seems to be working as intended.
Did anyone ever try to run their own kernel on these things?
Did anyone ever try to run their own kernel on these things?
I've ran 1 or 2 homemade apps but a kernel ? ? :scared: That's big boys stuff...
The device tree reveals a lot and nothing at the same time. There's no interesting peripherals listed here, the really interesting stuff will be in the PL part of the Zynq-7000.
Depends on whether it's a stock kernel, or whether rigol made a lot of modifications.
Can someone attach a screenshot of Bode plot function ;D
Hi all,
I read through a lot of posts of this thread, but there are 68 pages now! On the last couple of pages, I saw that the MSO5000 is pretty easily hackable without a big brick-risk. I am now about to order an MSO5074 or an MSO5104. Both have nearly all software options enabled because of a special offer. The only thing locked is the frequency.
So what I am not sure still is, if the frequencies can also be unlocked with this hack. The 70 Mhz Version is like 200 Euros (net) less, and I need the PLA2216, too. Should I spare myself the money and get the 70Mhz and "hack" as soon as I need more bandwidth, or should I go with the 100Mhz version "just in case"?
And what about the persistence of the hack? Somewhere in the thread, I read that it is gone after a reboot. But I guess this was just a work-in-progress issue during the investigation of a possible hack. Am I right?
A status overview page would be really helpful on this topic for us noobs.
I really appreciate all your efforts! Stay safe!
Martin
Hi all,
I read through a lot of posts of this thread, but there are 68 pages now! On the last couple of pages, I saw that the MSO5000 is pretty easily hackable without a big brick-risk. I am now about to order an MSO5074 or an MSO5104. Both have nearly all software options enabled because of a special offer. The only thing locked is the frequency.
So what I am not sure still is, if the frequencies can also be unlocked with this hack. The 70 Mhz Version is like 200 Euros (net) less, and I need the PLA2216, too. Should I spare myself the money and get the 70Mhz and "hack" as soon as I need more bandwidth, or should I go with the 100Mhz version "just in case"?
And what about the persistence of the hack? Somewhere in the thread, I read that it is gone after a reboot. But I guess this was just a work-in-progress issue during the investigation of a possible hack. Am I right?
A status overview page would be really helpful on this topic for us noobs.
I really appreciate all your efforts! Stay safe!
Martin
MSO5074, the hack works like a charm
Also given the hack is so easy, you will have hard time selling the 100Hz more than the 70Hz, so resale value is not as good for the 100Hz
Depends on whether it's a stock kernel, or whether rigol made a lot of modifications.
What is a "stock kernel" in a scope like this? ???
Can someone attach a screenshot of Bode plot function ;D
They run Linux on a commercial chip. It comes with a kernel as a starting point.
Here is another flavor of patch for 01.03.00.01 that will disable the "phone home" firmware upgrade check in addition to enabling options.Thank you!
...And what about the persistence of the hack? Somewhere in the thread, I read that it is gone after a reboot. But I guess this was just a work-in-progress issue during the investigation of a possible hack. Am I right?I think you're wrong, I believe the hack makes it as though the MSO5xxx has all the hacked features and they continue through power cycling.
...And what about the persistence of the hack? Somewhere in the thread, I read that it is gone after a reboot. But I guess this was just a work-in-progress issue during the investigation of a possible hack. Am I right?I think you're wrong, I believe the hack makes it as though the MSO5xxx has all the hacked features and they continue through power cycling.
...
So what I am not sure still is, if the frequencies can also be unlocked with this hack. The 70 Mhz Version is like 200 Euros (net) less, and I need the PLA2216, too. Should I spare myself the money and get the 70Mhz and "hack" as soon as I need more bandwidth, or should I go with the 100Mhz version "just in case"?
...
I also tried a Bode plot of the response of a guitar preamp I'm working on...
Hmmm, well it isn't working very well so I suppose there may be a problem, it's more a tone control than a preamp.I also tried a Bode plot of the response of a guitar preamp I'm working on...
preAMP? I see a maximum gain of -22dB, or is there a scaling trick involved?
Do you need to apply all intermediary patch Or can I go from the 1st one directly to the Last one
Did we already extract the u-boot image and environment? If so, is there an easy way to do this? Hints are very welcome.
aesTest - aes test
base - print or set address offset
bdinfo - print Board Info structure
beeper - Beeper
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BOOTP/TFTP protocol
bootz - boot Linux zImage image from memory
checkGTP- Config the clock 125MHz
checkVer- check version
clk - CLK sub-system
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
cpldver - Get cpld version
crc32 - checksum calculation
dcache - enable or disable data cache
dhcp - boot image via network using DHCP/TFTP protocol
dpu - Init DPU
dver - DPU version
echo - echo args to console
editenv - edit environment variable
env - environment handling commands
exec - exec memaddr ,return 0 on success, or != 0 on error by rigol
exit - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls - list files in a directory (default /)
false - do nothing, unsuccessfully
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
fatwrite- write file into a dos filesystem
fdt - flattened device tree utility commands
fpga - loadable FPGA image support
go - start application at address 'addr'
goldFinger- Set boot from Gold finger
help - print command description/usage
hwver - Get hardware version
i2c - I2C sub-system
icache - enable or disable instruction cache
iminfo - print header information for application image
itest - return true/false on integer compare
ledoff - turn led off
ledon - turn led on
loadb - load binary file over serial line (kermit mode)
loadlogo- load logo
loads - load S-Record file over serial line
loadx - load binary file over serial line (xmodem mode)
loady - load binary file over serial line (ymodem mode)
loadzynq- load zynq bit
loop - infinite loop on address range
md - memory display
md5sum - compute MD5 message digest
mdio - MDIO utility commands
mii - MII utility commands
mm - memory modify (auto-incrementing address)
mw - memory write (fill)
nand - NAND sub-system
nboot - boot from NAND device
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
progGTP - Programing the clock of 125MHz
readfile- Read the package from USB DISK to memory
reset - Perform RESET of the CPU
restart - Restart the power
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv - set environment variables
sf - SPI flash sub-system
showMessage- show message on the bottom of the LCD
showvar - print local hushshell variables
sleep - delay execution for some time
source - run script from memory
sspi - SPI utility command
storage - Select Nand or QSPI as the current storage device
tar - tar command by rigol
test - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
tftpput - TFTP put command, for uploading files to a server
true - do nothing, successfully
unzip - unzip a memory region
upgradeFromUSB- Upgrade firmware from USB Disk
usb - USB sub-system
usbboot - boot from USB device
version - print monitor, compiler and linker version
zynqaes - Zynq AES decryption
zynqrsa - Zynq RSA verfication
Did we already extract the u-boot image and environment? If so, is there an easy way to do this? Hints are very welcome.
AFAIK you need to read the SPI mem externally.
These are the u-boot commands available:Code: [Select]fatwrite- write file into a dos filesystem
nand - NAND sub-system
sspi - SPI utility command
storage - Select Nand or QSPI as the current storage device
upgradeFromUSB- Upgrade firmware from USB Disk
usb - USB sub-system
usbboot - boot from USB device
Might not be necessary. I see there's the "usb" command and the "fatwrite" command, it might be possible to read the boot memory into RAM and then write it out to a memory stick. The "upgradeFromUSB" and "usbboot" commands hint that it's feasible.
Might not be necessary. I see there's the "usb" command and the "fatwrite" command, it might be possible to read the boot memory into RAM and then write it out to a memory stick. The "upgradeFromUSB" and "usbboot" commands hint that it's feasible.
I think that's the problem: IIRC, you can't reach the bus to read to mem.
You mean, u-boot doesn't have a driver for the first-stage boot medium? And the "sspi" command group is not allowing access to it?
i've used the decoders since day 1, and rs232 is working perfectly, except the UI is ugly as hell, and should be nicked Unusable Interface instead. The decoded buffer seems to be the display buffer, and zooming out changes everything in the decoding result.
So yeah, it decodes.
Its really a hell of a machine feature-wise.That statement sums up my thoughts on the MSO5074.
Its really a hell of a machine feature-wise.That statement sums up my thoughts on the MSO5074.
Hi there. appreciate the commentary on my rs232 difficulties. By idling high are u referring to the polarity or maybe the trigger level. I am really rusty at this and am not sure re your question. I just got the sigma installed and though i'm sure the USB connection is working , I am not familiar with entering commands to the mso5074. As far as the polarity the default polarity on the hieroglyphic for the polarity which i assume is negative shows the first transition from high to low. If I dont change it to low to high then it misinterprets the data. Have to make both logic symbols on the trigger and on the decoder i believe positive logic ( with the ist transition low to high) for it to work correctly.I'm referring to the polarity but RS232 is confusing. Going back 20 or 30 years, there were RS232 ports on computers that exchanged data with RS232 devices such as printers using signals that moved between +15 to -15 volts; these voltages were used to make the communications over long cables more reliable.
...
5) Download the DS5000Update.GEL file from Post #1558 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2943152/#msg2943152) which is the script that will apply the patch (bspatch). This one will have 130k.
...
Edit: This thread is getting messy! :o I eventually found this post: https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3025330/#msg3025330 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3025330/#msg3025330)
Hello folks, I'm about to pull the trigger on a MSO5072, which BTW comes as standard ( limited offer until June the 30th) with almost all the options enabled except if I'm not wrong the ->350 MhZ Bandwidth and the -> 4 ch.
Now, after reading almost all the 70 pages on the thread (pheew!), after thanking all the people who contributed to the task on the subject, I got a few questions.
1) Have no clue on how the MSO5072 will arrive, whether with pre-loaded premium features or not...anyone ? I guess they come in a s/n string to dial in...
2) Given question n. 1, if I'll have a "personalized" license to dial-in, is it worth loading it or should I jump to the hack directly ?
3) After updating to the last official version, I already have prepared the content ( 3 files ) to be copied to the USB drive : 01.03.00.01.bspatch + DS5000Update.GEL + patch.txt with this content :
file_to_patch=/rigol/appEntry
file_to_patch_md5sum=2efa4605b83bf1af48bf6736bfae3255
patch_file=01.03.00.01.bspatch
after_patch_md5sum=965a689e7e5f29c180db4a2aaf21ce6b
the question is : being almost dry of Linux knowledge, and using Windows, wil it sufficient to copy the files on the USB drive or am I forced to use any Linux PC to change any file permission etc etc..?
Thank you, and stay safe ! :-+
Ciao
A.
Hello folks, I'm about to pull the trigger on a MSO5072, which BTW comes as standard ( limited offer until June the 30th) with almost all the options enabled except if I'm not wrong the ->350 MhZ Bandwidth and the -> 4 ch.
Hello folks, I'm about to pull the trigger on a MSO5072, which BTW comes as standard ( limited offer until June the 30th) with almost all the options enabled except if I'm not wrong the ->350 MhZ Bandwidth and the -> 4 ch.
Now, after reading almost all the 70 pages on the thread (pheew!), after thanking all the people who contributed to the task on the subject, I got a few questions.
1) Have no clue on how the MSO5072 will arrive, whether with pre-loaded premium features or not...anyone ? I guess they come in a s/n string to dial in...
2) Given question n. 1, if I'll have a "personalized" license to dial-in, is it worth loading it or should
1. For me it came without any preloaded licenses or serial keys. I had to register with Rigol in order to send to me the extra licenses.
2. I didn't even bother installing the licenses, went straight with the hack
3. No special knowledge of linux or windows is needed. Just follow the instructions and it will work.
4. If (3) for some reason doesn't work, reply to this thread. Lots of people, happy to help. If you are really really stuck, just shoot me a message and we can do a zoom or teamviewer meeting.
(4) will not be needed 99%
sb42 & Noy, tnx for the suggestion, however I did not need the two additional probes right now and went for the 5072, although your math was impeccable.
Being a noob, I'm struggling with scope operations still, and on that perspective the MSO5K might be an overkill....but, I don't know...when I saw you could "squeeze" more feature from it by just "tweaking" it ( ;) ;) ), it was like a magnet to me : if I had a psychiatrist, that would be food for his thoughts.. :palm:
A.
sb42 & Noy, tnx for the suggestion, however I did not need the two additional probes right now and went for the 5072, although your math was impeccable.
Hi, first of all, thank you very much for all the effort in the forum.
I would like to know if I can use the appEntry_01_01_04_08.bpatch https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2682411/#msg2682411 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2682411/#msg2682411) for my RIGOL MSO7014 appEntry, oviusly I ahve to update from 01_01_02_00_05 to 01_01_04_08 and actually I didnt find the update file yet. But anyway, I have seen a lot of good result in MSO5k so I want to give a shoot for my MSO7k.
Hi, first of all, thank you very much for all the effort in the forum.
I would like to know if I can use the appEntry_01_01_04_08.bpatch https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2682411/#msg2682411 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2682411/#msg2682411) for my RIGOL MSO7014 appEntry, oviusly I ahve to update from 01_01_02_00_05 to 01_01_04_08 and actually I didnt find the update file yet. But anyway, I have seen a lot of good result in MSO5k so I want to give a shoot for my MSO7k.
Patches are matched to a specific binary (a specific appEntry). Unless the appEntry for the MSO5000 is the same as the appEntry for the MSO7000 (spoiler, it isn't), the patch will not work.
Hi, first of all, thank you very much for all the effort in the forum.
I would like to know if I can use the appEntry_01_01_04_08.bpatch https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2682411/#msg2682411 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2682411/#msg2682411) for my RIGOL MSO7014 appEntry, oviusly I ahve to update from 01_01_02_00_05 to 01_01_04_08 and actually I didnt find the update file yet. But anyway, I have seen a lot of good result in MSO5k so I want to give a shoot for my MSO7k.
Hi, first of all, thank you very much for all the effort in the forum.
I would like to know if I can use the appEntry_01_01_04_08.bpatch https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2682411/#msg2682411 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2682411/#msg2682411) for my RIGOL MSO7014 appEntry, oviusly I ahve to update from 01_01_02_00_05 to 01_01_04_08 and actually I didnt find the update file yet. But anyway, I have seen a lot of good result in MSO5k so I want to give a shoot for my MSO7k.
MSO5000 and MSO7000 have different firmwares!
I can't understand what you are trying to say/accomplish.
v00.01.01.04.08 - is a MSO5000 version
v00.01.02.00.05 - is a MSO7000 version
The hack continues to work on both scopes (on all FW versions)! Although I don't know which ones are public.
Do read the thread, you will find it 7000 has been opened up for over a year
https://www.eevblog.com/forum/testgear/new-rigol-ds7000/ (https://www.eevblog.com/forum/testgear/new-rigol-ds7000/)
Hi everyone!
First, thanks for all the information given in those 70 pages of posts here (and in the other threads about the MSO5k)! :clap:
From all this reading, I have one question: Didn't I read that installing firmware using the "SINGLE" secret boot menu erases factory calibration?!? Doesn't this cause issues in measurements? I'm asking as I keep seeing people downgrading using this menu and there's no mention of the calibration reset, and no mention of having to self-calibrate after...
Finally, I placed my order for a MSO5074. I don't think I need more than 70MHz BW for my hobby use, and with the promo bundle I get the serial decode and AWG (+PWR). And the price difference between 2 and 4 channels is very close to the price of the extra probes. The 4 channels will be useful for SPI decoding, saving the expense of the LA adapter or a separate LA (for now).
Of course, the first thing to do after unboxing is a backup using https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2757356/#msg2757356 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2757356/#msg2757356) :D
Again, thanks everyone!
73s,
Martin
Hi tv84,
I know there are two options in the "secret menu". I'm only talking about the firmware update one.
From what I understand (from here: https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2250324/#msg2250324 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2250324/#msg2250324)), using the firmware update from that menu causes the non-volatile memory (including calibration) to be wiped. I want to understand what is lost in that process.
Thanks,
Martin
<root@rigol>ls -l
total 22324
-rwxrwxr-x 1 root root 22558088 May 22 03:41 appEntry
<root@rigol>md5sum /rigol/appEntry
2efa4605b83bf1af48bf6736bfae3255 /rigol/appEntry
<root@rigol>cp /tmp/appEntry /rigol/
<root@rigol>md5sum /rigol/appEntry
60f1ca21475ffe9444213c2d9a571a99 /rigol/appEntry
I just received my new MSO5074 and I updated everything and it all went very smoothly, thanks to all of the hard work others here on the forum have performed. I was just wondering if, at this point I should go ahead and run the built in calibration sequence or just leave it as is. By the way, I did not do a calibration before I did the updates. I am not noticing anything in particular being out of tolerance, just wondering what the consensus is regarding calibration. Thanks again to all of those who have helped on this forum.
Thanks,
rodorr
I just received my new MSO5074 and I updated everything and it all went very smoothly, thanks to all of the hard work others here on the forum have performed. I was just wondering if, at this point I should go ahead and run the built in calibration sequence or just leave it as is. By the way, I did not do a calibration before I did the updates. I am not noticing anything in particular being out of tolerance, just wondering what the consensus is regarding calibration. Thanks again to all of those who have helped on this forum.
Thanks,
rodorr
Oh boys, how easy life is for a siglent owner... :-X 8)OK, pray tell; how is life easy for a Siglent owner?
I'm there already ;DDoesn't Rigol require repatching and hacking after a firmware upgrade?
Once hacked ( in an "easy" way), you never must fear about it when a next update appear.
i uploaded a video of bode plot function
@tv84 What is the "easy" way you mention? I have read too much in this thread to remember!
@tv84 What is the "easy" way you mention? I have read too much in this thread to remember!
You have to re-read the whole thread but, now, "read between the lines"...
I'll help a bit: read only the last 10 pages.
@tv84 What is the "easy" way you mention? I have read too much in this thread to remember!
You have to re-read the whole thread but, now, "read between the lines"...
I'll help a bit: read only the last 10 pages.
OP is MIA.
I'm not sure if it's too subtle or if I read it and not figured that was it.
Could it be that bode plotting is much more faster than on the siglent sds2k+ ?
edit: forget it, it was played fast forwarding...
i uploaded a video of bode plot function
What was your connection configuration for this test?
speed depends on frequency range and "points" you selected
That's what changing the number of points does. Do few points it's done fast and ugly. Want a more refined plot choose more points.
But then you'd wait a really long time as it repeats the plot over and over and over until you got some unknown resolution.
I don't know maybe that would be useful for someone.
I successfully unlocked all the features on my new MSO5074 today. Thanks for the help :)
One question: if Rigol releases a new firmware and I update with it, will I lose all the unlocked features?
Update: I've changed of memory usb and i've achieved install the last version. Thanks for all, now i'm going to install the patched version.I'm glad you sorted it out. 99% of the time, situations like yours are fixed by using a different USB drive. I had the same problem a couple of weeks ago.
Command (m for help): p
Disk /dev/sdb: 7.2 GiB, 7756087296 bytes, 15148608 sectors
Disk model: DataTraveler 2.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 15148607 15146560 7.2G c W95 FAT32 (LBA)
mkfs.fat -F 32 -I /dev/sdb1
Finally Rigol acknowledging the use of Open Source in their latest products!!!!!!!!!!
MSO5000 example (https://eu.rigol.com/Public/Uploads/uploadfile/files/ftp/DS/MSO5000%20Open%20Source%20Acknowledgment.pdf)
::) well let's assume "acknowledgement" is what they meant.
And, if we could access the source code then that would be a killer factor! :popcorn:
The open source software is provided for free. RIGOL uses third-party open source
software subject to the specified licenses. You are entitled to use the open source
software subject to their respective license. If you or any third party wants to obtain
the complete corresponding source code for the software from us, please contact:
RIGOL (SUZHOU) TECHNOLOGIES
E-mail: service@rigol.com
Website: www.rigol.com (http://www.rigol.com)
This offer is valid for three years after you received the software.
Just wanted to thank everyone here - the MSO5074 was way outside my budget when I started looking, but I got it based on the work done here. All I needed was the AWG...
FWIW, I bought my scope a couple of weeks ago, it came with FW 00.01.03.00.01 and I was able to update it using this file: https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3024236/#msg3024236 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3024236/#msg3024236)
and these instructions:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3105598/#msg3105598 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3105598/#msg3105598)
I also used an old Sandisk Ultra USB 3.0 16GB thumb drive, I know some have had issues with this. Apparenly Windows 10 will not format anything above 32GB in FAT32.
EDIT: no sooner had I posted this than my scope stalled on startup every time (the Rigol screen never cleared). I used the secret menu (single key on startup) and used the "restore settings" function. This appears to have fixed the problem and I didn't see this elsewhere in this thread so thought I'd share here.
However, I would rather first like to understand the issue you have. Anybody has any idea? For example, we could create a special upgrade file which copies the rigol part of the code and check for differences to the offical released 00.01.03.00.01 version.
Slats can execute the NAND dump .GEL. It's somewhere in the thread.
i have fixed this with upload one more time clear firmware 00.01.03.00.01. And then i unlock all without any errors.Yes, that's right method.
I just received a brand new 5072 today and come with the fw ver 01.01.04.08.
Those three files from skander36 are perfectly work.
I encountered a problem while using 16GB USB Drive. But it solved after replace with the 32GB USB Drive. It is highly recommend that you have prepared two or more different brand and size USB Drive before perform the upgrade. My failure one is Sandisk 16GB and workable one is Sandisk 32GB (Tiny one).
Case :
When you found that the USB Drive is empty except the GEL file after the backup process:
- Attach the USB drive back to the scope, press Storage/Disk
- If you found there are two or more USB Disk, it means that you may need to try another USB Drive.
Enclosed with all the files from skander36 and backup GEL file from TV84.
My workflow are :
(Please read carefully especially handle the same name GEL files).
1. Format the USB Drive (FAT32 Format);
2. Copy the DS5000Update.GEL.backup.doc to the USB Drive;
3. Rename it by delete the "backup.doc" extension;
4. Attach the USB Drive to scope;
5. Press Utility/System/Help/Local upgrade;
6. After finished the screen will have message told you to reboot the scope;
7. Turn off the scope;
8. Attach the USB drive back to your Mac / PC;
9. Copy all the file except the GEL files and folder back to your Mac / PC for your backup;
10. Format the USB Drive (FAT32 Format);
11. Copy another three files to the USB Drive, rename them by remove the ".doc" extension;
12. Attach the USB Drive back to the Scope, turn it on;
14. Wait for the screen shows that USB Drive was attached.
15. Press Utility/System/Help/Local upgrade
16. The screen will turn to white background and follow the instruction to press any keys.
17. After the upgrade process is finished, the scope will reboot.
18. Done! Enjoy!
Please correct me if any mistake or typo. Thanks!
Thank you so much for all of you to contribute here!
I applied the patch to my scope, too.
Today I noticed that my channel 1 and 2 are a bit off.
This means when nothing is connected to the probes one shows a lower voltage then the other channel.
Attached a picture of all four channels without a probe connected, averaged and maximum memory depth set to 1k - to see it clearly.
It is visible that the channels are not exactly zeroed.
Does that mean my scope is damaged?
Or is it working and a difference of up to 300µV is totally fine?
Best,
Philipp
EDIT:
I did a self-calibration of the scope before I took the picture.
It was up and running for around 2 hours before, so should be warmed up enough.
EDIT 2:
The difference scales with the voltage per division setting.
With 2V per division it is around 3mV off.
I applied the patch to my scope, too.
Today I noticed that my channel 1 and 2 are a bit off.
This means when nothing is connected to the probes one shows a lower voltage then the other channel.
Attached a picture of all four channels without a probe connected, averaged and maximum memory depth set to 1k - to see it clearly.
It is visible that the channels are not exactly zeroed.
Does that mean my scope is damaged?
Or is it working and a difference of up to 300µV is totally fine?
Best,
Philipp
EDIT:
I did a self-calibration of the scope before I took the picture.
It was up and running for around 2 hours before, so should be warmed up enough.
EDIT 2:
The difference scales with the voltage per division setting.
With 2V per division it is around 3mV off.
I wish my Rigol had a battery option! With the power analysis function it would be THE machine for solar power systems diagnostics!
just reflash the v00.01.03.00.01 build from end of April, and try again.
Probably you got a scope with a v00.01.03.00.01 build from mid may, hence the different checksum.
Has anybody take them up on their offer? It does say it in quite verbatim:QuoteThe open source software is provided for free. RIGOL uses third-party open source
software subject to the specified licenses. You are entitled to use the open source
software subject to their respective license. If you or any third party wants to obtain
the complete corresponding source code for the software from us, please contact:
RIGOL (SUZHOU) TECHNOLOGIES
E-mail: service@rigol.com
Website: www.rigol.com (http://www.rigol.com)
This offer is valid for three years after you received the software.
I did ask them for the software, so lets see what happens next :) (but would be nice to know if others already did this too)
Has anybody take them up on their offer? It does say it in quite verbatim:QuoteThe open source software is provided for free. RIGOL uses third-party open source
software subject to the specified licenses. You are entitled to use the open source
software subject to their respective license. If you or any third party wants to obtain
the complete corresponding source code for the software from us, please contact:
RIGOL (SUZHOU) TECHNOLOGIES
E-mail: service@rigol.com
Website: www.rigol.com (http://www.rigol.com)
This offer is valid for three years after you received the software.
I did ask them for the software, so lets see what happens next :) (but would be nice to know if others already did this too)
So I never received a reply. So yesterday, I've sent a request to the European office, and got a reply promptly. They asked where I've sent the previous request too, and that they would prepare the files I requested (I requested all sources for all products :p)
They said they'd send them to me on november 17th. No idea why it is taking so long, maybe that's the day they'll open their github.com/rigol repo?
Anyway, fingers crossed!
Has anybody take them up on their offer? It does say it in quite verbatim:QuoteThe open source software is provided for free. RIGOL uses third-party open source
software subject to the specified licenses. You are entitled to use the open source
software subject to their respective license. If you or any third party wants to obtain
the complete corresponding source code for the software from us, please contact:
RIGOL (SUZHOU) TECHNOLOGIES
E-mail: service@rigol.com
Website: www.rigol.com (http://www.rigol.com)
This offer is valid for three years after you received the software.
I did ask them for the software, so lets see what happens next :) (but would be nice to know if others already did this too)
So I never received a reply. So yesterday, I've sent a request to the European office, and got a reply promptly. They asked where I've sent the previous request too, and that they would prepare the files I requested (I requested all sources for all products :p)
They said they'd send them to me on november 17th. No idea why it is taking so long, maybe that's the day they'll open their github.com/rigol repo?
Anyway, fingers crossed!
What a turn! You "blew up the bomb" and you will now be feared in Rigol. :-DD
But, they can provide the code executed by the processor that runs in the OS. And this is just the user interface, if I'm not mistaken. The main work is done in the FPGA and they are not required to publicate this code.
Probably the Rigol guys are reading this thread. Guys, come out, don't be afraid of open source - third-party firmware that will inevitably appear will make your product even more popular. :clap: I think people will love your product if you become open. This path was followed by PC-giving the opportunity to independently assemble computers and expand them, thereby sharply breaking away from the closed Apple, which is held in the market of show-offs. :)
If this thread is not read by Rigol specialists, oliv3r, please pass these thoughts on to them. :)
Course the 4 FPGA's are interesting too; but lets treat those as 'hardware' for now :)
once we know the interfaces between the hardware, FPGA and the software, we could even start to re-write the FPGA software :p
But for now, lets first see Rigol uphold the GPL :)
I don't know much about licensing. If I'm not mistaken, using Linux with a GPL license requires publishing the source code of running programs?
They said they'd send them to me on november 17th. No idea why it is taking so long, maybe that's the day they'll open their github.com/rigol repo?
Anyway, fingers crossed!
unfortunately the root:root login is not working, I only get an acces denied message:
login as: root
root@10.0.0.18's password:
Access denied
admin:rigol won't work either.
Has anyone more infos for this scope?
I have a portable inverter with a fairly large battery. It's not the same as having an internal battery. Portable inverter, mine included, are notorious for having very poor A/C waveforms. They're supposed to be "modified sine-waves" but they look much more like a square-wave when examined. I hate to subject my equipment to such poor quality mains power. I have a much older OWON 100MHz, 2-channel scope with battery option. I'll likely continue to use that instrument in the field for my solar installation consulting. (http://)/Users/stevenjaynes/Pictures/Inverter Waveforms/IMG_4918.jpg
just reflash the v00.01.03.00.01 build from end of April, and try again.
Probably you got a scope with a v00.01.03.00.01 build from mid may, hence the different checksum.
Thanks for posting this info!
I just got a MSO5074 with that same mid-May version of the v00.01.03.00.01 firmware (listed onscreen as Build: 2020-05-18 11:42:06)
The patch checksums didn't work.
After I rolled back to the April version of the v00.01.03.00.01 firmware (listed on-screen as Build: 2020-03-30 15:56:36), the patching worked! ;D
Thank you to all who contributed to this effort! It is impressive and apprecitated!
Hi All! Just joined so I could post, after spending... well, multiple hours reading the history of this amazing journey.
[..]
I also just got a MSO5072 with the mid-May firmware, same number and build timestamp listed above.
I went ahead and used the well-worn ssh enabler, ssh in, use the command line to copy the appEntry file onto a USB stick at /media/sda1 and took it to another computer to do the MD5.
If you have any kind of unix computer (linux or Mac) simply type
$ md5 /Volumes/USB_DRIVE/appEntry
or whatever the appropriate path is for you. md5 should be present by default in most unix-like systems.
MD5 (appEntry) = 783a31ebdc0d4acb7b9dc244155ba1c6
From everything I'm seeing here, it seems like this piece of info should be enough to get the patcher to work? Am I misunderstanding?
I'm not sure if it's too subtle or if I read it and not figured that was it.
"Easy way" (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2084152/#msg2084152).
Or, I noticed that some of their posts have apparently been deleted, was this license generator posted and then deleted?
Hey. I just bought one too. I would like to make backup from current firmware and all the data(as i would make image in windows world) before i try this "hack". How can i make backup and later use that backup as a recovery as well? Im not very familiar with linux backup. Thanks in advance.The backup copy is stored in the scope.
Hi All! Just joined so I could post, after spending... well, multiple hours reading the history of this amazing journey.
[..]
I also just got a MSO5072 with the mid-May firmware, same number and build timestamp listed above.
I went ahead and used the well-worn ssh enabler, ssh in, use the command line to copy the appEntry file onto a USB stick at /media/sda1 and took it to another computer to do the MD5.
If you have any kind of unix computer (linux or Mac) simply type
$ md5 /Volumes/USB_DRIVE/appEntry
or whatever the appropriate path is for you. md5 should be present by default in most unix-like systems.
MD5 (appEntry) = 783a31ebdc0d4acb7b9dc244155ba1c6
From everything I'm seeing here, it seems like this piece of info should be enough to get the patcher to work? Am I misunderstanding?
Welcome! Unfortunately, just changing the initial MD5 before patching is not enough. The patch also has to fit the binary, and you need to know the MD5 after the patch. If you want to learn a bit more, I encourage you to try and replicate the patch for your binary. For that, you have to compare the differences between a patched and unpatched appEntry, and replicate the same patch on your newly downloaded appEntry. Then you created the patch file, enter the correct md5, and you are done. :-) I found it well worth learning myself.
As bmx says, at this point you don't need anything more than a disassembler because the binary still has the same structure.
A simple approach is to take an existing patch, apply it to an appropriate appEntry and diff the asm listings that you obtained with objdump. This will show you what the patch is doing. Then look around in your newer appEntry listing and figure out where to make the same changes. Once you know that, write the replacement byte sequences at the new offsets with a hex editor or gdb and then produce a new binary patch at the end.
When I did a patch (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3024236/#msg3024236) for 01.03 I used radare2, but it was more that I wanted an excuse to play with r2 than anything else. :) I found it useful that it can search for instruction sequences (/ad), and that it has a convenient write command (you can seek to an offset and say "write a nop here" and it will do the right thing), but I didn't need any of its RE features.
Thanks for the hack. It worked. However my Rigol still displays model number under system information as MSO5074. Is it correct? Shouldn't it change to MSO5354?
This is super helpful and so far it's going well. Quick sanity check: I ran objdump on the April and May versions of appEntry and then ran diff between the two files.
The objdump files were about 100 MB, which seems reasonable. But then the diff output was 186MB... the files are almost completely different. Is this normal for two subsequent versions of appEntry to be almost completely different by that indicator?
This is super helpful and so far it's going well. Quick sanity check: I ran objdump on the April and May versions of appEntry and then ran diff between the two files.
The objdump files were about 100 MB, which seems reasonable. But then the diff output was 186MB... the files are almost completely different. Is this normal for two subsequent versions of appEntry to be almost completely different by that indicator?
% diff -u ae.s ae-mod.s | diffstat
ae-mod.s | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Namely, IDA for hobbyists is $365/year and the free cloud version of Binary Ninja won't handle files larger than 15Mb.There is Ghidra. Completely free and even better than IDA in some aspects. https://ghidra-sre.org/
This is super helpful and so far it's going well. Quick sanity check: I ran objdump on the April and May versions of appEntry and then ran diff between the two files.
The objdump files were about 100 MB, which seems reasonable. But then the diff output was 186MB... the files are almost completely different. Is this normal for two subsequent versions of appEntry to be almost completely different by that indicator?
The diff should be a few dozen lines long if you're comparing listings for the same appEntry binary, before and after applying the patch:Code: [Select]% diff -u ae.s ae-mod.s | diffstat
ae-mod.s | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
If you compare two different builds (and I think there may be two of them floating around for the latest firmware version?), diff will likely be thrown off by all the symbol address differences.
appEntry: file format ELF32-arm-little | appEntryAprilPatched: file format ELF32-arm-little
c6958: 01 00 00 0a beq #4 <_ZN16searchEventT | c6958: 00 00 a0 e1 mov r0, r0
c7210: 88 00 00 1a bne #544 <_ZN16searchEven | c7210: 88 00 00 ea b #544 <_ZN16searchEven
c744c: 23 00 00 0a beq #140 <_ZN16searchEven | c744c: 00 00 a0 e1 mov r0, r0
18c210: b3 00 00 0a beq #716 <_ZN5QListIPN8me | 18c210: 00 00 a0 e1 mov r0, r0
18c22c: 1a 00 00 1a bne #104 <_ZN5QListIPN8me | 18c22c: 00 00 a0 e1 mov r0, r0
3997d0: 71 00 00 0a beq #452 <_ZN12CIRQListen | 3997d0: 00 00 a0 e1 mov r0, r0
3997ec: 06 00 00 1a bne #24 <_ZN12CIRQListene | 3997ec: 00 00 a0 e1 mov r0, r0
44c6a4: 03 00 00 1a bne #12 <_ZN7MemFileD1Ev+ | 44c6a4: 00 00 a0 e1 mov r0, r0
44c6a8: a9 ff ff eb bl #-348 <_ZN7MemFileD1E | 44c6a8: 01 00 a0 e3 mov r0, #1
sb42, your example showed six changes; this has nine, a group of three and then a group of six. I'm guessing that the difference is that I used the patch file from typoknig that includes the phone-home patch: https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3024342/#msg3024342 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3024342/#msg3024342)
The md5 checks out before and after the patch, as per that patchfile. Seems like I'm on the right track.
Next I'll see if I can find the corresponding lines in the objdump from the May build. This is where it gets tricky!
QuoteThe md5 checks out before and after the patch, as per that patchfile. Seems like I'm on the right track.
Next I'll see if I can find the corresponding lines in the objdump from the May build. This is where it gets tricky!
Yup, this is the fun part ;)
c6958: 01 00 00 0a beq #4 <_ZN16searchEventTable16sigCurrEventTimeEi+0x3650>
c7210: 88 00 00 1a bne #544 <_ZN16searchEventTable16sigCurrEventTimeEi+0x4124>
c744c: 23 00 00 0a beq #140 <_ZN16searchEventTable16sigCurrEventTimeEi+0x41cc>
18c210: b3 00 00 0a beq #716 <_ZN5QListIPN8menu_res8RDsoViewEED1Ev+0x104d8>
18c22c: 1a 00 00 1a bne #104 <_ZN5QListIPN8menu_res8RDsoViewEED1Ev+0x10290>
3997d0: 71 00 00 0a beq #452 <_ZN12CIRQListener10sigHandlerEi+0x2dac>
3997ec: 06 00 00 1a bne #24 <_ZN12CIRQListener10sigHandlerEi+0x2c1c>
44c6a4: 03 00 00 1a bne #12 <_ZN7MemFileD1Ev+0x2344>
44c6a8: a9 ff ff eb bl #-348 <_ZN7MemFileD1Ev+0x21e0>
c6958: 01 00 00 0a beq #4 <_ZN16searchEventTable16sigCurrEventTimeEi+0x3650>
c7210: 88 00 00 1a bne #544 <_ZN16searchEventTable16sigCurrEventTimeEi+0x4124>
c744c: 23 00 00 0a beq #140 <_ZN16searchEventTable16sigCurrEventTimeEi+0x41cc>
18c1c8: b3 00 00 0a beq #716 <_ZN5QListIPN8menu_res8RDsoViewEED1Ev+0x104d8>
18c1e4: 1a 00 00 1a bne #104 <_ZN5QListIPN8menu_res8RDsoViewEED1Ev+0x10290>
399770: 71 00 00 0a beq #452 <_ZN12CIRQListener10sigHandlerEi+0x2dac>
39978c: 06 00 00 1a bne #24 <_ZN12CIRQListener10sigHandlerEi+0x2c1c>
44c644: 03 00 00 1a bne #12 <_ZN7MemFileD1Ev+0x2344>
44c648: a9 ff ff eb bl #-348 <_ZN7MemFileD1Ev+0x21e0>
add a pinch of c++filt, and you're set
(base) omgoleus@slick-biscuit 01_03_00_01_May % c++filt <appEntryApril_diffpre
01 00 00 0a beq #4 <_ZN16searchEventTable16sigCurrEventTimeEi+0x3650>
88 00 00 a bne #544 <_ZN16searchEventTable16sigCurrEventTimeEi+0x4124>
23 00 00 0a beq #140 <_ZN16searchEventTable16sigCurrEventTimeEi+0x41cc>
b3 00 00 0a beq #716 <_ZN5QListIPN8menu_res8RDsoViewEED1Ev+0x104d8>
a 00 00 a bne #104 <_ZN5QListIPN8menu_res8RDsoViewEED1Ev+0x10290>
71 00 00 0a beq #452 <_ZN12CIRQListener10sigHandlerEi+0x2dac>
06 00 00 a bne #24 <_ZN12CIRQListener10sigHandlerEi+0x2c1c>
03 00 00 a bne #12 <_ZN7MemFileD1Ev+0x2344>
a9 ff ff eb bl #-348 <_ZN7MemFileD1Ev+0x21e0>
BTW, you can SCP your patched binary for testing to /tmp and mark it executable. appEntry runs from everywhere. That prevents any chance of bricking the device. ;)
$ objdump ... file | sed ... | awk ... | whatever ... | c++filt
c6958: 01 00 00 0a beq #4 <searchEventTable::sigCurrEventTime(int)+0x3650>
c7210: 88 00 00 1a bne #544 <searchEventTable::sigCurrEventTime(int)+0x4124>
c744c: 23 00 00 0a beq #140 <searchEventTable::sigCurrEventTime(int)+0x41cc>
18c210: b3 00 00 0a beq #716 <QList<menu_res::RDsoView*>::~QList()+0x104d8>
18c22c: 1a 00 00 1a bne #104 <QList<menu_res::RDsoView*>::~QList()+0x10290>
3997d0: 71 00 00 0a beq #452 <CIRQListener::sigHandler(int)+0x2dac>
3997ec: 06 00 00 1a bne #24 <CIRQListener::sigHandler(int)+0x2c1c>
44c6a4: 03 00 00 1a bne #12 <MemFilqe::~MemFile()+0x2344>
44c6a8: a9 ff ff eb bl #-348 <MemFile::~MemFile()+0x21e0>
file_to_patch=/rigol/appEntry
file_to_patch_md5sum=783a31ebdc0d4acb7b9dc244155ba1c6
patch_file=mayBuildPatch.bspatch
after_patch_md5sum=7e39040bfb086c666be3e7cc87dd73b0
Hello guys, I know I am not the first and I won't be last asking this... so try to understand.... probably some of you went already through the pain of reading this massive thread... :scared:
Is there a comprehensive tutorial or sticky post that collects all steps to update the fw in order to unlock all the features of the MSO5074 I am planning to buy?
Again, my apologies to ask again, but due the lack of the sticky post on page #1... is quite hard to find where to start or a proper howto. ^-^
Cheers mates and stay safe!
For completeness, here's the instructions for someone who just wants to patch:
1. In this message mabl posted the "auto patcher".
2. Download that and rename it to remove the .txt (Make sure you actually remove the .txt extension, don't be fooled by your stupid gui.)
3. Check the "About" menu on your scope to see what version and build of firmware you have. If you have a new scope as of the date of this message it probably has 01.03.00.01 with a build date of May. For that version/build you can use the patch file and patch.txt attached to this message. Otherwise you have to search.
4. Follow the instructions in mabl's message. You will know it works because the screen will turn white with text and give you some "hit any key" prompts.
5. If it doesn't get to that screen, it's probably because you're using too large of a flash drive or it's formatted wrong or the file still has a .txt extension.
6. If the black on white text tells you that it worked, it takes a pretty long time (1 minute) for anything else to happen. that's normal.
7. If it got that far but then the licenses don't show up, then you'll have to do some deeper troubleshooting.
8. If your scope becomes non-functional try turning it off and then back on again. If that doesn't work, then you will have to use the "secret menu" and restore the firmware. This is not that hard, but you'll have to search through the thread if it comes to that.
9. At the present time the collective wisdom of this community seems to agree that it is impossible to permanently brick your scope. Restoring firmware via secret menu is the worst case scenario.
10. I think, maybe, you're supposed to use the scope's menus to run its auto-calibration routine once you've done the upgrade?
Id be surprised if you got appEntry source. i did this for a samsung tv some time ago, all i got was the linux kernel i could have downloaded from the source webpage. none of their derivative works or things that used the Open Source libraries.I think I mentioned this before, but 'obviously'. But one can always seem to amaze you ;)
Still, id be happy to be wrong :)
Still, id be happy to be wrong :)I think I mentioned this before, but 'obviously'. But one can always seem to amaze you ;)
Hmmm, Google translate give that as... "who does not ask, does not breast"Still, id be happy to be wrong :)I think I mentioned this before, but 'obviously'. But one can always seem to amaze you ;)
:clap: As we say in portuguese: "quem não pede, não mama"
Anyway, the request went through, and I got the sources.
No, that wasn't a promise. And its not the full source code.
Only the stuff which are GPL based. They had to give it to him otherwise the possibility for law penalities will be opened up.
Same thing did a work colleage for the "Thermomix" ;-)
I don't know if anyone has produced a utility to print out the intentions of a binary patch file; it would probably be relatively trivial to do, reverse-engineering the source for bsdiff.
Just to be clear: The "old" way with (reactivating) SSH and -fullopt is definitively closed?
my real worry is if you do an update to their latest firmware release, is there any way to go back to what I had (my hacked firmware)??? or will it totally lock me out?
So it´s still a problem when updating to a newer firmware, all the hacks are gone ?
There´s no keygen avaible, generating "true" license keys ?
Hello I have the MSO5074 (70MHz) which I purchased a little over one year ago and through this forum I was able to get all the options and features, 350MHz and all other options. However they have now added a new Bode plotter feature with the latest firmware (V00.01.03.00.01 released on April of 2019) My current version installed version is V00.01.01.04.04. I imagine that if I tried to update to the latest I would lose my previous hack and end-up with a lot of missing features and options but my real worry is if you do an update to their latest firmware release, is there any way to go back to what I had (my hacked firmware)??? or will it totally lock me out? Any answers or suggestions to this dilemma would be greatly appreciated.
Thank you so much!
I find still interesting that a lot of people are installing a script "from the internet" without any idea what this script is changing or how.
I find still interesting that a lot of people are installing a script "from the internet" without any idea what this script is changing or how.
That's amazing, could you please share your work?What do you want me to share?
Hi
My scope : MSO5072 01.03.00.01 hw 01.01.000 2018.06.27 2020-05-18
Omgoleus files worked.All option is unlocked forever.
Simply local upgrade from flash drive.(Kingston Data Traveler 100 G3 32GB Fat32).
[...]
I'm struggling now.What exactly are you struggling with?
You have same model and F/W with my 5072.
If you could, let me know the hacking procedures you've done and files.
Hi, is MSO5074 Hacking the same as MSO5072 ?
Hi, just wanted to thank all the work put into this "tune".
I was able to shift some bits to the MSO7024 firmware and got all the "Forevers".
No overshoots, in fact it is shooting just fine as the attached image shows.
I wasn't able to use the patchFinder script (it didn't find the appropriate sections) so I used IDA and the previous posted patches to find the required modifications.
I also changed the bootscreen but had to use mtd3 instead of mtd7 (probably depends on the current shadow image being used).
It is a shame about all the OT though, an "Hide all the BS button" would make things much less painful.
Cheers,
José
If there is a place with such a topic, we will cooperate as much as possible, so please make a place. Or please tell me the location.
Hey!What is the source of the 10MHz signal? If it has 3.5ns it will not get any faster looking at it with a 350MHz or a GHz scope
Does the rising time decrease after unlocking? Or is it determined by the hardware of the model? (In datasheet: MSO5074≤5 ns, MSO5354≤1 ns). I see a 10 MHz square wave on an old oscilloscope(Bandwidth 100 MHz,rising time≤3.5 ns) and on the MSO5074 after unlocking, there is no difference.
I just received a brand new 5072 today and come with the fw ver 01.01.04.08.
Those three files from skander36 are perfectly work.
Enclosed with all the files from skander36 and backup GEL file from TV84.
My workflow are :
(Please read carefully especially handle the same name GEL files).
1. Format the USB Drive (FAT32 Format);
2. Copy the DS5000Update.GEL.backup.doc to the USB Drive;
3. Rename it by delete the "backup.doc" extension;
4. Attach the USB Drive to scope;
5. Press Utility/System/Help/Local upgrade;
6. After finished the screen will have message told you to reboot the scope;
7. Turn off the scope;
8. Attach the USB drive back to your Mac / PC;
9. Copy all the file except the GEL files and folder back to your Mac / PC for your backup;
10. Format the USB Drive (FAT32 Format);
11. Copy another three files to the USB Drive, rename them by remove the ".doc" extension;
12. Attach the USB Drive back to the Scope, turn it on;
14. Wait for the screen shows that USB Drive was attached.
15. Press Utility/System/Help/Local upgrade
16. The screen will turn to white background and follow the instruction to press any keys.
17. After the upgrade process is finished, the scope will reboot.
18. Done! Enjoy!
Please correct me if any mistake or typo. Thanks!
Thank you so much for all of you to contribute here!
Here's a patch for 01.03.00.01.
Before: 2efa4605b83bf1af48bf6736bfae3255
After: 965a689e7e5f29c180db4a2aaf21ce6b
Here is another flavor of patch for 01.03.00.01 that will disable the "phone home" firmware upgrade check in addition to enabling options.
Found this reply and the (01_03_00_01.bspatch file) .. it worked!!!
Currently I use python (pyvisa) to collect traces via the 1Gb ethernet interface and then use pulseview or sigrok to analyse and view the traces. But the process is rather cumbersome due to the amount of data and the inefficiency of the "VISA: virtual instrument software architecture" protocol I assume.
Hi there,
would it be possible to summarize the modding process on the first page?
However, it is a real burden to find the correct post where the files are linked. Please, don't make me and others go through 79 Pages again. Thank you.
However, it is a real burden to find the correct post where the files are linked. Please, don't make me and others go through 79 Pages again. Thank you.
:wtf: Do you prefer to develop the process yourself???
I must be on a good day... here (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3344172/#msg3344172)
Hi guys!
I just received my MSO5074. I also got the offer with included MSO5000-BND (which I understand I will receive as a separate license). If I want to try the hack will I lose the included licence? What happens if I switch back to the original firmware? Thanks!
Persons can correct me if I am incorrect.
Does the print function work for anyone? I upgraded to the latest firmware and applied a patch from a post that said it's supposed to stop the scope from "phoning home." Networking does work. I can access the scope through my browser. But when I try to print to my LaserJet the scope always says "Printer Busy."
Bob's your uncle
RIGOL Starts 2021 with a Rebrand.
There are two different FW 01_03_00_01:
-March 2020
-May 2020
Does any one know the inners difference? I can't find anywhere the May package. The rigolee repo does contain the March one, not the May one.
I checked on every known to me rigol.xx site. na has march, eu march, com march.
That's also why so many people were confused, and freaking out.
Add to that the incompetency of rigol staff in zip/rar management/name convention...
Well, calling them is a no-no to me.
The usual way to look for differences is not to ask the developers what they did but look inside de bits and bytes or what they produced.
So, since a patch.txt was made for the May version, my guess is that someone have dumped the May GEL (or at least the AppEntry), and only forgot to commit it somewhere?
Rigol did it again, just selling the EXACT same hardware as 6 different devices? Just by disabling some features in the firmware.Yes!
Soooooo, I have to ask some seriously dumb question. Rigol did it again, just selling the EXACT same hardware as 6 different devices? Just by disabling some features in the firmware. ......No different to several other brands.....you should do some more research.
So nothing new here at all.
Firmware: 0A.01.03.00.01
The patching method (and others) should work but you need to get your hands on the app file and adapt the diffs.
Also I do not understand - do I need to backup calibrate file or not?
Or you can extract the app and pass it to some of the guys that find the new patch addresses, if they are willing to do it.
Where I can read how to extract the new FW ?
I will put it here.
Backup scripts for Rigol MSO5000 and MSO/DS7000 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2757356/#msg2757356)
What will happen if I will try to apply the old patch for 00.01.03.00.01 on to 0A.01.03.00.01 version?
Can the scope fully die?
Is there possibility to reanimate?
Hello,
is it possible to revert a hacked MSO5072 to original ? do I need to save somthing before the hack?
Thanks!
Hello,
is it possible to revert a hacked MSO5072 to original ? do I need to save somthing before the hack?
Thanks!
Yes, you can reinstall the factory firmware if needed and the scope goes back to normal, just like you look it out of the box.
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3105996/#msg3105996 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3105996/#msg3105996)
Please tell me I rolled back from 01.03.00.01 Build date May 18, 2020 to 01.03.00.01 date March 30, 2020 . Where to download the original GEL on May 18, 2020
DSO5104This topic is about another oscilloscope.
Then a white screen appeared with inscriptions, after which it was not possible to unlock the functions. Please, help!What is your version of the device?
version 00.01.03.00.01The error is written on the screen: the device does not see the USB flash drive. You need to search another flash drive of a small size. (1-4GB)
Here I changed the flash drive, and what happened in the photo.
I just liberated my new MSO5074 yesterday, FW 01.03.00.01 build 2020-05-18, easy peasy and purring like a pussy.Hi do i need to do any backup before upgrading with this method?
I've attached the necessary files and describe below what I did for the convenience of others. Nothing new, it all comes from previous posts.
Steps I took to liberate the scope:I suppose I shiouuld recalibrate now too, which according to Olliver goes like this:
- Verified installed FW is version 01.03.00.01 build date May 18, 2020 (Utility => System => About)
- Copied three files, that can be extracted from attached .7z archive, to root of empty 8GB FAT32 USB drive
- Started up scope
- Inserted drive to front panel USB port
- Utility => System => Help => Local upgrade
- "Upgrade system firware?" => OK
- Let the scope do its thing - takes a minute or two, or five, go with the flow
- Reboot scope
- Verified all options now licensed ...forever... (Utility => System => Help => Option list)
- Bob's your uncle
I verified that all options were upgraded ...forever... (notwithstanding what the effects may be of any future official FW updates I may decide to apply). I did not verify that the patch disables the "phone home" firmware upgrade check, but I have no reason to think it doesn't. This patch does not enable the sshd daemon. To ssh as root into the scope, follow mabl's instructions - which needs to be reapplied after each scope reboot whenever you want SSH access.
- Make sure that the instrument has been operating for at least 30 minutes
- Disconnect all input channels (including probes)
- Utility => System => Self-Cal => Start
- Self calibration takes ~ 35 minutes to complete
- When complete, reboot the scope
This is not going to work for you if your installed FW is not version 01.03.00.01 and having build date May 18, 2020. In that case you will need to adjust the patch.txt file in accordance with instructions that can be found in other posts.
Where the files and info came from:
- Basic GEL file from mabl https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2704640/#msg2704640 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2704640/#msg2704640)
- Modification to disable "call home" FW updates from typoknig https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3024342/#msg3024342 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3024342/#msg3024342)
- Modification for FW version 01.03.00.01 May 2020 build from omgoleus https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3344172/#msg3344172 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3344172/#msg3344172)
Anybody have problems with zeropoint.
After downgrade firmware and open 350mhz some problems with zeropoint. Show dc -160mv. Calibration not help.
ok so it's a simple quick question: purely from the prospects of unlocking as far as possible. what would be the best specific model to get new these days? can it be mso5072 ? or should it be something higher up in the range, eg the mso5074?
On the bright side, you found stock :)Yes, already ordered a couple. Even Farnell had them in stock but they were more expensive, and I had a production order ready to go to Digikey anyway.
https://www.digikey.co.uk/en/products/detail/ISL8203MIRZ/ISL8203MIRZ-ND/4958418 (https://www.digikey.co.uk/en/products/detail/ISL8203MIRZ/ISL8203MIRZ-ND/4958418)
Ooo, yuk, package looks like fun.
Couldn't it be that, say, a ceramic cap has shorted on the rail, and the ISL8203M shows up on IR because it's trying to chuck current into the short?
ok so it's a simple quick question: purely from the prospects of unlocking as far as possible. what would be the best specific model to get new these days? can it be mso5072 ? or should it be something higher up in the range, eg the mso5074?
If you order the 5072, you only get two probes. Makes sense, it's only a 2 channel scope.
If it was me, I would order the 5074. Yes it costs a little extra, but you don't have to worry about buying extra probes and you always have 4 channels to fall back on if you want to sell it later and remove the patched firmware.
Hello everyone. Who ever got the license? I have been sending a request for 3 months and no one is answering me. And he did not receive a license, although they say that it is paid for.
Hmmm.... switched on my MSO5000 to check something about it for someone (it only has about 20 hours of use), after about ten minutes on it powered itself down and I was left with a repeating click and short LED panel flash every second or two.
Took it apaaaart, there's a near short (0.4 ohms) on the PSU connector's 5V pins to ground on the main board.
PSU seems to supply voltages fine.
After giving it a visual, there was not much to be seen so I made up a cable to my bench PSU to power all the 3 supplies (5V, +7.5V, -7.5V), sure enough the 5V was shorting. By the way, the connector is the same as a normal PC ATX connector cut in half, so I made up a cable.
After a bit of manual probing of the obvious power supplies, I got nowhere, the Schottkys all seemed fine.
Got out the IR cam, and the perp showed up like a Christmas tree. Looks like the ISL8203M 3.3V SMPS is dead. I didn't immediately look at this because #1 eyeball was looking for inductors: this device interestingly enough has integrated inductors, quite a feat, I've not seen this before.
Hi All,
Just a quick note that the MSO5000 free options bundle that includes:
MSO5000-COMP - Computer Serial Triggering and Analysis (RS232/UART)
MSO5000-EMBD - Embedded Serial Triggering and Analysis (I2C, SPI)
MSO5000-AUTO - Automotive Serial Triggering and Analysis (CAN/LIN)
MSO5000-FLEX - FlexRay serial bus trigger and analysis (FlexRay)
MSO5000-AUDIO - Audio Serial Triggering and Analysis (I2S)
MSO5000-AERO - MIL-STD 1553 Serial Triggering and Analysis
MSO5000-AWG - Dual Channel 25MHz Waveform Generator
MSO5000-PWR - Integrated Power Analysis
Ends at the end of this month (30th of September).
Who knows if this offer will be extended (probably will, but I have zero contact/idea if that'll happen).
So if you are thinking of getting the MSO5000 series scopes, I'd get one before the end of the month so you can get your free (legitimate) license for these options.
Obviously, this isn't really needed because you can just unlock the features, but it's always nice to have the "real" license for these options in case you want to sell it, or need to restore the factory firmware for some reason.
Hi All,
Just a quick note that the MSO5000 free options bundle that includes:
MSO5000-COMP - Computer Serial Triggering and Analysis (RS232/UART)
MSO5000-EMBD - Embedded Serial Triggering and Analysis (I2C, SPI)
MSO5000-AUTO - Automotive Serial Triggering and Analysis (CAN/LIN)
MSO5000-FLEX - FlexRay serial bus trigger and analysis (FlexRay)
MSO5000-AUDIO - Audio Serial Triggering and Analysis (I2S)
MSO5000-AERO - MIL-STD 1553 Serial Triggering and Analysis
MSO5000-AWG - Dual Channel 25MHz Waveform Generator
MSO5000-PWR - Integrated Power Analysis
Ends at the end of this month (30th of September).
Who knows if this offer will be extended (probably will, but I have zero contact/idea if that'll happen).
So if you are thinking of getting the MSO5000 series scopes, I'd get one before the end of the month so you can get your free (legitimate) license for these options.
Obviously, this isn't really needed because you can just unlock the features, but it's always nice to have the "real" license for these options in case you want to sell it, or need to restore the factory firmware for some reason.
where can I get this bundle? I purchased the mso5072 from Conrad, and there is nothing mentioned there , thanks
Thanks!
I got impatient and applied the hack to mine over my lunch hour. Also registered for the bundle, but that web page seems flakey. I entering my info, clicked submit, and the button disappeared with no confirmation message. I guess if I don't get a notice in a day or two I will try again.
I applied the patch to unlock my scope and this unlocked everything.
However, I am unable to run selfcal, as it never starts.
Channel one goes rail to rail, so it will never start selfcal.
Scope channel is working fine otherwise.
Any ideas?
Fine just ran successfully (first one post-hack).
QuoteFine just ran successfully (first one post-hack).
spiff72 what FW version/date did you have in your scope ?
Different keys.
Great. Then I'm all the more interested if someone could share their Key.data!
tv84, sounds like you already looked into this - how many did you get a chance to compare and did you find anything interesting?
I'd love to hear if someone already looked for nonce reuse.
(https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Security)
Why do you want to see them? They are different keys of the same type. Just that.
They most probably use an ID of the scope to seed the key generation. Never truly investigated that although it has crossed my mind.
Firmware: 0A.01.03.00.01
did you by any chance run a script that might've modified your appEntry?
I'm not sure whether one of these modified appEntry, but the Firmware version was like that all the time.
It seems I have a new build and a different checksum. Now what?
System Information:
Firmware: 0A.01.03.00.01
Boot: 2018.06.27
Build: 2021-05-04 15:50:32
Checksum:
<root@rigol>md5sum appEntry
4669caa3cfb3d19f98adff7833e321db appEntry
I have successfully created a backup, I am able to activate SSH, I can connect with WinSCP and provide files for analysis, if needed. I think I understood how to hack the scope, but the checksums will not match (I have not tried, but that's why I created the MD5 hash to know in advance).
While the promo still appears to be running (I'll check again okt. 1st to see if it was extended again :p) I can't actually reach the form.
While the promo still appears to be running (I'll check again okt. 1st to see if it was extended again :p) I can't actually reach the form.
Both the link on the rigolna site and the direct one work fine for me (Netherlands IP)
This site can’t be reached
beyondmeasure.rigoltech.com refused to connect.
I can't actually reach the form.
'full nand backup'
QuoteI can't actually reach the form.
Same issue here right at the moment. I had problems on September 28th as well, but 2 hours later it worked again.Quote'full nand backup'I don't know what that is. Is there a GEL file to create that kind of backup?Ok, got that one as well from https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2757356/#msg2757356 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2757356/#msg2757356). Will try.
At the moment I only have a calibration backup. But I can connect to the scope using WinSCP and I can access /rigol/appEntry and likely other files if needed.
Find appEntry (22 MB) for a few days on http://37.120.179.6/appEntry-0A.01.03.00.01 (http://37.120.179.6/appEntry-0A.01.03.00.01)
Just checked again and it still works for me, very strangeDidn't work in the NL; used a USA proxy; worked this time around ... weirdness.
Hi!
I have the firmware 00.01.03.00.01 from 30.03.2020
can someone tell me where to download the firmware FW 01.03.00.01 build 2020-05-18
I applied the patch to unlock my scope and this unlocked everything.
However, I am unable to run selfcal, as it never starts.
Channel one goes rail to rail, so it will never start selfcal.
Scope channel is working fine otherwise.
Any ideas?
Mine just ran successfully (first one post-hack).
I applied the patch to unlock my scope and this unlocked everything.
However, I am unable to run selfcal, as it never starts.
Channel one goes rail to rail, so it will never start selfcal.
Scope channel is working fine otherwise.
Any ideas?
Mine just ran successfully (first one post-hack).
See attachment
(Attachment Link)
what exactly did you use, I have the same firmware version and nothing works, please describe in more detail where to start and what files?
Valid Models: MSO5074, MSO5104, MSO5204, MSO5354
note: Other models no longer qualify for the free bundle offer when purchased after 9/30/2021. For purchases of any UltraVision II Oscilloscope that occurred before 10/1/2021 please fill out the form below and your bundle will still be sent per the previous promotion.
Do we have a nand-backup of someone with that firmware? we can generate it then if really needed.Hi!
I have the firmware 00.01.03.00.01 from 30.03.2020
can someone tell me where to download the firmware FW 01.03.00.01 build 2020-05-18
Nowhere. Up till now it's only flashed at factory.
Find appEntry (22 MB) for a few days on http://37.120.179.6/appEntry-0A.01.03.00.01 (http://37.120.179.6/appEntry-0A.01.03.00.01)
My scope came with this: 0A.01.03.00.01
Is this hackable and what do I need to do?
MS5000 came with 01_03_00_01 firmware. I followed the "upgrade" steps using zip file included in https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3024342/#msg3024342. (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3024342/#msg3024342.) I had to update checksums to match what Rigol was expecting (based on what it said when I tried to run the upgrade). After updating both checksums the upgrade said successful. Restarted and now I have a Rigol screen with the progress bar reaching to the end but nothing happens. In the web UI I see a message saying "Loading ... Please Waiting".
I used https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3721423/#msg3721423 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3721423/#msg3721423) and I'm all good. All options are available and still same firmware version. >:D
Thanks for your help!!! I can now relax that scope is not bricked and operational++ !!!
damn! I got the latest build version, who can help me? |O
damn! I got the latest build version, who can help me? |O
You may downgrade software
post # 2017 https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3617041/#msg3617041 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3617041/#msg3617041)
To downgrade the firmware I think you have to use the recovery process.
Use the process here:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3820085/#msg3820085 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3820085/#msg3820085)
Then patch using:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3721423/#msg3721423 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3721423/#msg3721423)
try using other USB flash, try format Flash FAT32 in RUFUS
Turn on the device with the left hand, while pushing the single button with the right hand.
Keep pushing it, over and over and over don't stop pushing, don't wait between pushes.
It works, I don't know why you are having problems.
Does the hack need to be updated to work with firmware 00.01.03.00.03?Yes a new file needs to be created for each new update, the hack is the same but it needs to be applied to new update.
Hi guys,
I have version 00.01.03.00.01, but the bspatch doesn't seem to work. This got me reading more into this thread and used the gel file to enable SSH and do a dump.
Looking into the GEL files I saw that they contain binary shell files and was wondering what those files to.
1. Can someone explain how to encrypt and decrypt the binary shell files? Or at least tell me what's in them?
2. Regarding bspatch, can someone explain what it contains? I am interested in terms of assembly so I can adapt it to the firmware on my scope and maybe any future firmware.
It seems to me that the hacking methods here are pretty opaque and would like to learn more about how they work.
Is it because legal issues with Rigol? If that is the case, I would be very thankful if anyone could send me a PM.
Thanks!
First I updated to FW v00.01.03.00.03. Then used the patch above to activate all options.
Thank you for the work done on the patch!
here is patch for F.W 01_03_00_03Thanks!
have fun ;)
Hi friends, I’m new here :)
I’ve updated my MSO5000 with FW v00.01.03.00.03 and patched it with the patch from qali.pro (Thank you!!), but now I experience a problem using the 20MHz BW limit on the inputs: the trace disappear! :o
Have you the same issue?
Trying better, using using the 20M BW Limit (but not the 100 or 200M) a “negative bias” of approximatly 300mV it’s added to the trace.
So with 10mV or less sensitivity the trace “disappear”
Hi friends, I’m new here :)
I’ve updated my MSO5000 with FW v00.01.03.00.03 and patched it with the patch from qali.pro (Thank you!!), but now I experience a problem using the 20MHz BW limit on the inputs: the trace disappear! :o
Have you the same issue?
Trying better, using using the 20M BW Limit (but not the 100 or 200M) a “negative bias” of approximatly 300mV it’s added to the trace.
So with 10mV or less sensitivity the trace “disappear”
I have found same problem! But no success after 2 times self-calibration ... |O
Below 2mV/div has become useless ... even averaging
In addition BW-20MHz gives offset problems up to 1V/div ... :--
Suggestions? Roll-back?
Thanks!You are welcome.
Have you tried to upgrade the MSO5072 to MSO5504 (BW:500MHz) with firmware 01_03_00_03?
I'll try (BW:500MHz) as soon as possible .
:-// Why? (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2663334/#msg2663334)
@ qali.pro
I haven’t take a screenshoot when the problematic trace display ,using the 20M BW Limit, occoured!
diff 01_03_00_01.txt 01_03_00_03.txt
637a638,643
> CALibration:INIT:ADC:DATa selfcal 72 -1 ('INTEGER',) ()
> CALibration:INIT:ADC:DATa? selfcal 72 -1 () ('INTEGER',)
> CALibration:INIT:ADC:TCMP selfcal 71 -1 ('INTEGER',) ()
> CALibration:INIT:ADC:TCMP? selfcal 71 -1 () ('INTEGER',)
> CALibration:INIT:ADC:TDMX selfcal 70 -1 ('INTEGER',) ()
> CALibration:INIT:ADC:TDMX? selfcal 70 -1 () ('INTEGER',)
652c658
< CALibration:SAVE selfcal 2 -1 (['CHDelay', 'DDELay', 'GGND', 'MLF', 'PRECision'],) ()
---
> CALibration:SAVE selfcal 2 -1 (['CHDelay', 'DDELay', 'GGND', 'MLF', 'PRECision', 'SER'],) ()
1748a1755,1762
> SYSTem:KEEP:ACQuire utility 12093 -1 (['AVERages', 'HRESolution', 'NORMal', 'PEAK'],) ()
> SYSTem:KEEP:ACQuire? utility 12093 -1 () (['AVER', 'HRES', 'NORM', 'PEAK'],)
> SYSTem:KEEP:AVERages utility 12092 -1 ('INTEGER',) ()
> SYSTem:KEEP:AVERages? utility 12092 -1 () ('INTEGER',)
> SYSTem:KEEP:BWLimit utility 12091 -1 (['100M', '10G', '150M', '1G', '200M', '20G', '20M', '250M', '25M', '2G', '300M', '350M', '4G', '500M', '50M', '5G', '600M', '70M', 'OFF'],) ()
> SYSTem:KEEP:BWLimit? utility 12091 -1 () (['100M', '10G', '150M', '1G', '200M', '20G', '20M', '250M', '25M', '2G', '300M', '350M', '4G', '500M', '50M', '5G', '600M', '70M', 'OFF'],)
> SYSTem:KEEP:IMPedance utility 12090 -1 ('BOOL',) ()
> SYSTem:KEEP:IMPedance? utility 12090 -1 () ('BOOL',)
1752,1753d1765
< SYSTem:KIMPedance utility 12090 -1 ('BOOL',) ()
< SYSTem:KIMPedance? utility 12090 -1 () ('BOOL',)
here is patch for F.W 01_03_00_03
have fun ;)
Thanks :-) But are you sure this patch is good? My scope crashes when the licenses are queried over SCPI or the web interface.
2c2
< appEntry: file format elf32-littlearm
---
> appEntry2: file format elf32-littlearm
142769c142769
*< c8498: 0a000001 beq c84a4 <_ZN16searchEventTable16sigCurrEventTimeEi@@Base+0x3650>
---
> c8498: e1a00000 nop ; (mov r0, r0)
143327c143327
< c8d50: 1a000088 bne c8f78 <_ZN16searchEventTable16sigCurrEventTimeEi@@Base+0x4124>
---
> c8d50: ea000088 b c8f78 <_ZN16searchEventTable16sigCurrEventTimeEi@@Base+0x4124>
143470c143470
< c8f8c: 0a000023 beq c9020 <_ZN16searchEventTable16sigCurrEventTimeEi@@Base+0x41cc>
---
> c8f8c: e1a00000 nop ; (mov r0, r0)
345451c345451
< 18e1f0: 0a0000b3 beq 18e4c4 <_ZN5QListIPN8menu_res8RDsoViewEED1Ev@@Base+0x104d8>
---
> 18e1f0: e1a00000 nop ; (mov r0, r0)
345458c345458
< 18e20c: 1a00001a bne 18e27c <_ZN5QListIPN8menu_res8RDsoViewEED1Ev@@Base+0x10290>
---
> 18e20c: e1a00000 nop ; (mov r0, r0)
886012c886012
< 39db6c: 0a000000 beq 39db74 <_ZN12CIRQListener10sigHandlerEi@@Base+0x2bb8>
---
> 39db6c: ea000000 b 39db74 <_ZN12CIRQListener10sigHandlerEi@@Base+0x2bb8>
886018c886018
< 39db84: 0a000071 beq 39dd50 <_ZN12CIRQListener10sigHandlerEi@@Base+0x2d94>
---
> 39db84: e1a00000 nop ; (mov r0, r0)
886025c886025
< 39dba0: 1a000006 bne 39dbc0 <_ZN12CIRQListener10sigHandlerEi@@Base+0x2c04>
---
> 39dba0: e1a00000 nop ; (mov r0, r0)
886147c886147
< 39dd88: 0a00000d beq 39ddc4 <_ZN12CIRQListener10sigHandlerEi@@Base+0x2e08>
---
> 39dd88: eb00000d bl 39ddc4 <_ZN12CIRQListener10sigHandlerEi@@Base+0x2e08>
886274c886274
< 39df84: 1afffee5 bne 39db20 <_ZN12CIRQListener10sigHandlerEi@@Base+0x2b64>
---
> 39df84: eafffee5 b 39db20 <_ZN12CIRQListener10sigHandlerEi@@Base+0x2b64>
1074304,1074305c1074304,1074305
< 45594c: 1a000003 bne 455960 <_ZN7MemFileD1Ev@@Base+0x244c>
< 455950: ebffffa9 bl 4557fc <_ZN7MemFileD1Ev@@Base+0x22e8>
---
> 45594c: e1a00000 nop ; (mov r0, r0)
> 455950: e3a00001 mov r0, #1
1074312c1074312
< 45596c: ebffffa8 bl 455814 <_ZN7MemFileD1Ev@@Base+0x2300>
---
> 45596c: e1a00000 nop ; (mov r0, r0)
Hi everyone.
I nearly bought the MSO5204. Now I changed my mind and I'm about to buy an MSO5074 instead. Is there anything special to consider with regard to patch compatibility?
Is the firmware and required "patch" the same for MSO5072 and MSO5074, or are there differences or special considerations?
I am totaly new to this topic and the thread seems to be very long :(.
So i hope someone can give me a quick reply to help me out so i can buy the scope and get into topic deeper.
The software is the same, the patch will enable all 4 channels on the MSO5072. The difference in cost between MSO5072 and 5074 is the cost of the 2 probes, plus you get the warranty to cover all 4 channels. This is why most persons buy the 5074 vs the 5072.Thanks. Yes that was my intention, to get 2 additional 350MHz probes. Good to hear that there is only one software and patch for all family members of the MSO5000 line.
Hi all,
I'm absolutly new to this forum and to oszis. I bought a MSO5072 because
I work with it at my student job and really like the controlling.
I just found this great forum and its huge informations, so I first wanted to ask if
my device with the following software informations can be hacked and if
somebody can give me some tips and information where to start?
I have following data read out of mine:
Firmware: 0A.01.03.00.01
Hardware: 01.01.000
Boot: 2018.06.27
Build: 2021-05-04 15:50:32
Thanks for any help.
pip install pyvisa-py
python3 SCPIcmd.py -p ':SYSTem:MODules?'
python3 SCPIcmd.py -p ':SYSTem:MODules?'
1,1,0,0,0
I have found a bug regarding the Recording mode in my MSO5000.
The calculated max. number of frames to be recorded decreases only with rising memory-depth but never increases again when lowering memory-depth.
I need to push Default button to get a reset, otherwise the max. frame number can not be changed anymore. |O
Do I am missing something?
I have found a bug regarding the Recording mode in my MSO5000.
The calculated max. number of frames to be recorded decreases only with rising memory-depth but never increases again when lowering memory-depth.
I need to push Default button to get a reset, otherwise the max. frame number can not be changed anymore. |O
Do I am missing something?
Hi RobbiTobi,
Is problem come from a patch or original F.W?
Hello everybody,
I apologize to everyone for the previous problems.
Here is a new patch for real fix all previous problems (finish tested it's working perfectly well for me).
FW:01_03_00_03
Build: 2021-10-18
(http:// (Attachment Link) )
(http:// (Attachment Link) )
(http:// (Attachment Link) )
(http:// (Attachment Link) )
Does this patch also block the calling home to Rigol, or does it just enable the license.
I would suggest persons test the new FW before they patch it to see if the FW has any bugs, if we don't test the FW then it will be difficult to report a bug to Rigol. I think there is a general resistance to report issues to support and therefore a number of issues don't get resolved or included in firmware fix. I see the Siglent guys report issues to Tautech instead of calling Siglent support, so this may be related to persons fearing support will discover they have hacked the scope. The manufactures are fully aware the scopes are hacked, if they made them un-hackable they would lose a lot of business.
Some bugs may take years to be reported as scopes have so many options that many people never use all of them and so bugs go undiscovered.
I have found a bug regarding the Recording mode in my MSO5000.I noticed this last week.
The calculated max. number of frames to be recorded decreases only with rising memory-depth but never increases again when lowering memory-depth.
I need to push Default button to get a reset, otherwise the max. frame number can not be changed anymore. |O
Do I am missing something?
Does this patch also block the calling home to Rigol, or does it just enable the license.
I would suggest persons test the new FW before they patch it to see if the FW has any bugs, if we don't test the FW then it will be difficult to report a bug to Rigol. I think there is a general resistance to report issues to support and therefore a number of issues don't get resolved or included in firmware fix. I see the Siglent guys report issues to Tautech instead of calling Siglent support, so this may be related to persons fearing support will discover they have hacked the scope. The manufactures are fully aware the scopes are hacked, if they made them un-hackable they would lose a lot of business.
Some bugs may take years to be reported as scopes have so many options that many people never use all of them and so bugs go undiscovered.
Hi normi,
I have still a non patched version and can test some features if you tell me what
to do?
regards
I have found a bug regarding the Recording mode in my MSO5000.
The calculated max. number of frames to be recorded decreases only with rising memory-depth but never increases again when lowering memory-depth.
I need to push Default button to get a reset, otherwise the max. frame number can not be changed anymore. |O
Do I am missing something?
Does this patch also block the calling home to Rigol, or does it just enable the license.
I would suggest persons test the new FW before they patch it to see if the FW has any bugs, if we don't test the FW then it will be difficult to report a bug to Rigol. I think there is a general resistance to report issues to support and therefore a number of issues don't get resolved or included in firmware fix. I see the Siglent guys report issues to Tautech instead of calling Siglent support, so this may be related to persons fearing support will discover they have hacked the scope. The manufactures are fully aware the scopes are hacked, if they made them un-hackable they would lose a lot of business.
Some bugs may take years to be reported as scopes have so many options that many people never use all of them and so bugs go undiscovered.
Hello everybody,
I apologize to everyone for the previous problems.
Here is a new patch for real fix all previous problems (finish tested it's working perfectly well for me).
FW:01_03_00_03
Build: 2021-10-18
(http:// (Attachment Link) )
(http:// (Attachment Link) )
(http:// (Attachment Link) )
(http:// (Attachment Link) )
Hi quali.pro,
thanks for all your effort and congrats ;)
"zidot" already showed me how to patch my actual firmware.
Can you tell me if you would recommend to update my firmware to yours
(if this is possible?) and afterwards patch it or should I stay and patch it as it is?
I have following data read out of mine:
Firmware: 0A.01.03.00.01
Hardware: 01.01.000
Boot: 2018.06.27
Build: 2021-05-04 15:50:32
Thanks in advance.
its these type of thing which Dave was complaining about in his initial review. when it first came out. i have been hoping for a re-review. like an update bug hunt with the newest firmware. but it has not happen yet?
but you would think so. given how many people have bought this scope. there are not others competing much close to it in the raw price / performance. once you figure out the per $ dollar value (per mhz / per msps / per channel). what with all the extra features like the signal gen, spectrum analyzer etc. included too
Most of the original bugs were related to the logic analyzer, which 99% of people never use (and should not use, unless you just need time corelation).
lol yeah... it's a core feature for me too. I am not at all sure what the other guy was talking about there...
So this is just a speculation. But maybe he meant that we should use the 4 scope channels instead of the LA channels connector, to avoid whatever that specific lag issue is that makes the LA problematic from a timings standpoint?
But how in the world is that not some major bug!?!?!?! For example what if you need more than only 4 digital channels
* Or he only meant 'scope scope its only a scope' features. Instead of the other additional side features?
* Or maybe the LA issues all is fixed now? Which was my original quesitron here and entirely my point
Because blindly assuming this stuff is fixed. Is a completely different thing from actually having somebody go back and prove / demonstrate that an issue really is fixed now, and in the latest firmware(s). The 2nd being far more reassuring for a new buyer. It also includes checking for things like regressions or newly introduced bugs etc. Which might not have existed in earlier versions. Or simply at least showing people that there really are none.
Or am I missing something else here? :-BROKE
ah ok... so can this be worked around? For example by setting up the trigger on an analog channel instead? (but to be triggering for the LA capture)
Hello,
Have anyone emulate this oscilloscope with QEMU, please share with me?
Rigol MSO5000 Firmware v00.01.03.00.03 :Thanks, puhsed those to https://gitlab.com/riglol/rigolee/firmware/ (https://gitlab.com/riglol/rigolee/firmware/)
[Updated Contents]
--------------------
v00.01.03.00.03 2021/10/18
- Optimized waveform display in XY mode.
- Optimized the DC gain calibration algorithm.
- The La channel is decoded in parallel, which solved the problem of decoding error in negative polarity.
Download:
https://www.rigolna.com/products/digital-oscilloscopes/MSO5000/ (https://www.rigolna.com/products/digital-oscilloscopes/MSO5000/)
Most of the original bugs were related to the logic analyzer, which 99% of people never use (and should not use, unless you just need time corelation).
I use the LA at the very least half the time I switch on the scope.
Hi
I'm new here.
I recently bought an MS05074. And I applied the FW from qali.pro, message 2175. It worked ok. Thankful qali.pro.
I am new to using Digital Oscilloscope. I am learning to use my MSO5074. I don't know if it's a BUG or not, as follows:
1. I want to do the Measuring the Modulation Index of AM Signal using an FFT, using the signal generated in G1 or G2 AWG, and then FFT - Math function in MSO5074.
2. For Unmodulated Signals (Sine/Square) I got a satisfactory result using the FFT function in Math of MSO5074.
3. And then, I want to measure the Deviation Meter for FM modulated signal, using the signal generated in G1 or G2 AWG, and then FFT - Math function in MSO5074.
4. For Measuring the Modulation Index of an AM Signal using an FFT, I found an application note for the SIGLENT SDS 1204X-E, here:
https://siglentna.com/application-note/measuring-the-modulation-index-of-an-am-signal-using-an-fft/?pdf=9065
And that's exactly what I want to do, but using MSO5074. I tried it in different ways, but I couldn't get a satisfactory result. Commands on both MSOs are different.
I ask for your help to find a satisfactory solution, as in the case of SIGLENT SDS 1204X-E.
5. To generate in AWG G1 or G2, Carrier Sine Signal f = 1MHz, with Vpp = 500mV, and Audio Modulator Sine f = 10 KHz, with AM Depth = 80%. I suggest the quick commands on MSO5000:
(Enter G2 SINE WAVE Signal 1 MHz with Modulation to CH-1)
(G2) (Wave Sine) (Frequency) (Set on Touch Screen 1 MHz) (Amplitude) (Set on Touch Screen 500 mV)
(AUTO) (G2)
(Settings) (Type Modulation) (Type AM) (Waveform Sine) (Frequency) (Set on Touch Screen 10 KHz) (AM Depth 80%) (Impedance 50R) (Menu off)
6. I ask to do the sequence of commands on the MSO5000, which it does as shown above. In order to be easily reproduced.
7. Congratulations to all who contribute to the topic.
Maybe we should stay a bit more at the topic in this much too long thread which is hacking the MSS5000 and not analyzing it's performance.
It's hard enough to find the related posts for the patches and co without having to scroll unrelated messages. I think another thread for discussing the MSO5000 functions would be helpful. But these are only my thoughts concerning this thread to stay a bit more at it's topic. :)
@quakeman, @Cerebus, @Megavolt, @normi.I had deleted the previous post because I felt that the conclusions I made were wrong since I later got the correct results, however I realized that the results were affected by the settings related to the impedance and therefore the conclusion could still be correct. Since the issue I doubt is related to the new firmware hack, it would require its own thread. You can raise a support question to Rigol and have them confirm if this is by design, which I suspect it is.
I understood your opinions.
That way, just like @normi, I'll delete my posts relating to this subject. Not to detract from the main purpose of the discussion on this Thread: "Hacking the Rigol MSO5000 series oscilloscopes".
Turn on the device with the left hand, while pushing the single button with the right hand.
Keep pushing it, over and over and over don't stop pushing, don't wait between pushes.
It works, I don't know why you are having problems.
After many attempts, I think I know the problem,
time1: Press the power button, the keyboard light is on, and the screen is dark;
time2: The keyboard light is off and the screen remains dark;
time3: The screen displays RIGOL, and the startup progress...
Just press single at time2, and the mysterious menu will appear.
Hello everybody,
I apologize to everyone for the previous problems.
Here is a new patch for real fix all previous problems (finish tested it's working perfectly well for me).
FW:01_03_00_03
Build: 2021-10-18
(http:// (Attachment Link) )
(http:// (Attachment Link) )
(http:// (Attachment Link) )
(http:// (Attachment Link) )
Hello everybody,
I apologize to everyone for the previous problems.
Here is a new patch for real fix all previous problems (finish tested it's working perfectly well for me).
FW:01_03_00_03
Build: 2021-10-18
(http:// (Attachment Link) )
(http:// (Attachment Link) )
(http:// (Attachment Link) )
(http:// (Attachment Link) )
Hello qali.pro, thanks for the updated patch. I had previosly applied your first patch (i think from post #2142). How can I update to this patch? Thanks in advance
Thanks!You are welcome.
Have you tried to upgrade the MSO5072 to MSO5504 (BW:500MHz) with firmware 01_03_00_03?
I'll try (BW:500MHz) as soon as possible .
Just wondering.
Has anyone from Rigol ever admitted that they design their test equipment to be hackable by the hobby community? A modified scope looses it's warranty and that saves them support costs although the original firmware can be re-flashed.
Thanks.
Thanks!You are welcome.
Have you tried to upgrade the MSO5072 to MSO5504 (BW:500MHz) with firmware 01_03_00_03?
I'll try (BW:500MHz) as soon as possible .
Hi qali.pro,
Have you try to upgrade to 500MHz and get 500ps/div?
Has anyone from Rigol ever admitted that they design their test equipment to be hackable by the hobby community? A modified scope looses it's warranty and that saves them support costs although the original firmware can be re-flashed.
The telnet, or SSH option is not enabled after upgrade..
IS there any script that enables it ? So I could Putty into it.. I searched, but can not find
Managed to get things working.
Get the Firmware
Download FW 00.01.03.00.01 from message 1810
Put DS5000Update.GEL on a USB stick.
Make sure it is the only file.
Load the Firmware
Upgrade via "Secret Menu"
(Other options failed)
Power On
Wait for lights out (Before “Rigol” and progress bar)
Press [Single]
Two options are displayed
Upgrade or Restore
Select Upgrade.
Scope should now show FW 00.01.03.00.01
Get the Patch
Download zip file from message 1665
put 01_03_00_01.bspatch
and patch.txt on a usb stick
Get DS5000Update.GEL from message 1669
Put this with the two other files
Only 3 files should be on the USB stick.
Load the Patch
Select:
Utility>System>Help>Local Upgrade>Ok
Scope should show all options:
Utility>System>Help>Option list
Self Calibration
Utility>System>Self Cal>Start
If you are checking calibration
Make sure probes are decent and are set to x1
I just put 00.01.03.00.03 on my 5074, because I couldn't find the 1.03.00.01 version. Will the patch still work? Or do I have to get the 01 version first?
:-//
I just put 00.01.03.00.03 on my 5074, because I couldn't find the 1.03.00.01 version. Will the patch still work? Or do I have to get the 01 version first?
:-//
Hello
I'm wondering how to rollback the original configuration from backup I have just made using your scripts. Just in case. Is there some kind of procedure (cli commands) or script doing it automaticly ? Did someone do it before and in the worse scenario is there a chance that Rigol service will notice the scope was patched / modified.
Did I understood correctly that the patch can unlock every feature and can "create" a MSO5354 out of an MSO5074?
Can you undo the patch with the factory reset in case something happened and it needs to be send back to Rigol?
HiI just put 00.01.03.00.03 on my 5074, because I couldn't find the 1.03.00.01 version. Will the patch still work? Or do I have to get the 01 version first?
:-//
Instructions here::
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3943042/#msg3943042 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3943042/#msg3943042)
Skip step 2 in your case.
Hi
I tried this method and it is failed. In this zip we have DS5000Update.GEL file only 130 kb is it normal? I tried to copy another one 60mb from github - it is upgrading but not patching. What am i doing wrong
FW:01_03_00_03
Build: 2021-10-18
My hacked 70MHZ MSO5702 shows all the options as permanent. Yet I measure a 3db bandwidth of 106MHZ. This sounds about right for a 70MHZ model.
The FW was 01.03.00.01 build 2020-05-18. I used the Liberator .7z archive and everything ran in with no issues. This was followed by a Self Cal. Everything else seems to work. Any ideas???
Is it just me, or maybe a more thorough overall controll of the unit after the hack... but - i've seemed to notice that a scope after a hack to full options upgrade runs way more hotter than as it was before the upgrade.
P.S. Do I understand correctly that there is NO brightness control? I have an old analog scope that has a brighter CRT...
I just liberated my new MSO5074 yesterday, FW 01.03.00.01 build 2020-05-18, easy peasy and purring like a pussy.Will this hack work with Rigol MSO5074?
I've attached the necessary files and describe below what I did for the convenience of others. Nothing new, it all comes from previous posts.
Steps I took to liberate the scope:I suppose I shiouuld recalibrate now too, which according to Olliver goes like this:
- Verified installed FW is version 01.03.00.01 build date May 18, 2020 (Utility => System => About)
- Copied three files, that can be extracted from attached .7z archive, to root of empty 8GB FAT32 USB drive
- Started up scope
- Inserted drive to front panel USB port
- Utility => System => Help => Local upgrade
- "Upgrade system firware?" => OK
- Let the scope do its thing - takes a minute or two, or five, go with the flow
- Reboot scope
- Verified all options now licensed ...forever... (Utility => System => Help => Option list)
- Bob's your uncle
I verified that all options were upgraded ...forever... (notwithstanding what the effects may be of any future official FW updates I may decide to apply). I did not verify that the patch disables the "phone home" firmware upgrade check, but I have no reason to think it doesn't. This patch does not enable the sshd daemon. To ssh as root into the scope, follow mabl's instructions - which needs to be reapplied after each scope reboot whenever you want SSH access.
- Make sure that the instrument has been operating for at least 30 minutes
- Disconnect all input channels (including probes)
- Utility => System => Self-Cal => Start
- Self calibration takes ~ 35 minutes to complete
- When complete, reboot the scope
This is not going to work for you if your installed FW is not version 01.03.00.01 and having build date May 18, 2020. In that case you will need to adjust the patch.txt file in accordance with instructions that can be found in other posts.
Where the files and info came from:
- Basic GEL file from mabl https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2704640/#msg2704640 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2704640/#msg2704640)
- Modification to disable "call home" FW updates from typoknig https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3024342/#msg3024342 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3024342/#msg3024342)
- Modification for FW version 01.03.00.01 May 2020 build from omgoleus https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3344172/#msg3344172 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3344172/#msg3344172)
Will this hack work with Rigol MSO5074?
If you meet the prerequisite FW and build versions then quite likely yes.
... with actions started by me.
How does it distinguish them?? ::) :-//
QuoteHow does it distinguish them?? ::) :-//
I'd Imagine the OS knows that a double click from the mouse is user initiated, and from there it goes down the rabbit hole until it tries to open winrar. But the red thread should remain through on the whole journey :)
sudo diskutil eraseDisk FAT32 USB MBRFormat /dev/diskX
I hack my mso5104, now all options are licensed forever, but the rise time is not god, about 3.5ns not 1.7ns
wat is your rise time after hack ? :popcorn:
I hack my mso5104, now all options are licensed forever, but the rise time is not god, about 3.5ns not 1.7ns
wat is your rise time after hack ? :popcorn:
tv84 was getting ~440ps. Seems slow, but, probably an issue with your source no? Do you have anything to verify the source is capable of 1.7ns?
Also make sure you've run the self-calibration.
So, I decided to test it using my signal generator, 1Vrms. I forgot to ............terminate into 50 Ohms.
It is terminated using a 50 Ohm feed-through terminator. The before 100MHz image only shows 665mVrms as the scope's bandwidth is only 70MHz. After the hack, the scope accurately shows 1Vrms @ 100MHz as the bandwidth has been increased.OK, sorry in the many times I have checked BW it is always with a 1V p-p signal not RMS.
Got the scope last week (MSO5074, Build 2021, Boot 2018, FW 1.03.00.03). I was also concerned about the bandwidth after the hack. So, I decided to test it using my signal generator, 1Vrms. I forgot to reset the statistics for the before images. The before images (before applying the patch) and after images (after applying the patch and selfcal). The hack works fine.
See my photo on page 78.
Hello
I also faced heat issues.
See my photo on page 78.
A USB5V powered fan was attached to the rear exhaust.
(It is installed in the direction of discharging to the outside)
This will dramatically reduce the temperature of the MSO5000.
So does this hack turn the 70MHz 4-ch scope into the 350MHz version ?
So does this hack turn the 70MHz 4-ch scope into the 350MHz version ?
Really, please tell where a 500 MHz model is advertised ?So does this hack turn the 70MHz 4-ch scope into the 350MHz version ?
No, 500MHz, somewhere between 450-500MHz real world.
Really, please tell where a 500 MHz model is advertised ?So does this hack turn the 70MHz 4-ch scope into the 350MHz version ?
No, 500MHz, somewhere between 450-500MHz real world.
Instead the max for this range is 350 MHz.
It was never sold, for various reasons.
Yep and SW code bears no relation to the models actually available. The code in these modern scopes is Cut/Paste into several models but the deeper SW commands are those that actually set the model #/BW.QuoteIt was never sold, for various reasons.
Main reason was, there is no 500Mhz bandwith avaible.
Have a nice day to everyone! I recently bought myself such an oscilloscope and hacked it as you have described everything. Everything went well. The only thing that bothers me is the heating of the oscilloscope. Is this normal? Below I attach the pictures taken with a thermal imager. Sorry for my English. (http://)
QuoteIt was never sold, for various reasons.
Main reason was, there is no 500Mhz bandwith avaible.
Yep and SW code bears no relation to the models actually available. The code in these modern scopes is Cut/Paste into several models but the deeper SW commands are those that actually set the model #/BW.
The only way to be sure what any model series is capable of is to do a full investigation of what the manufacturers actually market, be it in their own marketplace and worldwide.
Wanna know the real truth then ask the Toy Wonder tv84.
The information is already provided by tv84 and others in this thread.I have read this thread from the very beginning. And then again I specifically looked for how to make 500 MHz. I found many references to this. But there I did not find a working recipe that can be repeated :(
I am very happy to say that I was successful and it took no time at all by following the instruction provided by qali.pro in the following post: -
I specifically looked for how to make 500 MHz. I found many references to this. But there I did not find a working recipe that can be repeated
I'm guessing that references to a hacked MSO5074 being a "500MHz scope" are from measured performance.
I imagine you will find similar results for many 350MHz scopes - the vendor guarantees 350Mhz, but the scope can actually be pushed further in many cases.
I have read this thread from the very beginning. And then again I specifically looked for how to make 500 MHz. I found many references to this. But there I did not find a working recipe that can be repeated :(
After applying the liberator to my 5072 everything is forever. Has anyone tried using UltraSigma/UltraScope after doing this? and does your HDMI out work?
Thanks to everyone involved in this endeavor for all your hard work and time. I'm sure I speak for everyone that took advantage of your work. YOU ARE ALL GREATLY APPRECIATED! :clap: :clap: :clap:
found here:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/msg1190818/#msg1190818 (https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/msg1190818/#msg1190818)
With soany pages and so much information here was there ever a step by step post or document made of how to do the hack? If so can someone direct me to where it is? I've read about the first 10 pages and see lots of pieces or information but get confused because it's all broken up across multiple posts.
Self Calibration
Utility>System>Self Cal>Start
If you are checking calibration
Make sure probes are decent and are set to x1
Let's not be paranoid. The only thing that could stop (meaning: make it sufficiently difficult) an attack is activating secure boot. All other things are within reach.
@lukier, SHA1 is an hash algorithm, not a digital signing algo! The fact that the NAND blocks are hashed doesn't mean much.
I don't think we have reached the secure boot point but, if we did, this is an electronics community forum so, something like this:
How to Break Secure Boot on FPGA SoCs through Malicious Hardware (https://eprint.iacr.org/2017/625.pdf) would be possible with the right guys...
Hello everybody,
Here is new modified post with detailed instructions to patch mso5000 and most asked questions for new users.
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3866693/#msg3866693 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3866693/#msg3866693)
Have Fun :-+
+1.
Temperatures have increased since the fan noise was reduced(by lowering the rpm).
Asked the support and they answered this is OK and tested before.
Have a nice day to everyone! I recently bought myself such an oscilloscope and hacked it as you have described everything. Everything went well. The only thing that bothers me is the heating of the oscilloscope. Is this normal? Below I attach the pictures taken with a thermal imager. Sorry for my English. (http://)
Have a nice day to everyone! I recently bought myself such an oscilloscope and hacked it as you have described everything. Everything went well. The only thing that bothers me is the heating of the oscilloscope. Is this normal? Below I attach the pictures taken with a thermal imager. Sorry for my English. (http://)
It's hot.
Could you repeat your test when running FFT for ~30 minutes?
I'm trying to follow the steps to upgrade my newly-arrived MSO5074, but it keeps eating my USB drives. That is, I put a new, never-used USB thumb drive in my Mac. Copy the DS5000Update.GEL file to it, stick that in the front USB port on the Rigol. The default menu has a "local update" option, so I choose that. It says "No package found."
I pull the drive out (I see no "eject" option anywhere), stick it back in the Mac…and it doesn't mount as a drive. It also doesn't show up as a disk device in /dev or Disk Utility.app.
I figured something died with that thumb drive, so I try another new one…same issue. The Rigol is severely altering my USB thumb drives (although they still enumerate on the Mac, as "IOUSBHubDevice").
Any suggestions? Thanks!
I'm trying to follow the steps to upgrade my newly-arrived MSO5074, but it keeps eating my USB drives. That is, I put a new, never-used USB thumb drive in my Mac. Copy the DS5000Update.GEL file to it, stick that in the front USB port on the Rigol. The default menu has a "local update" option, so I choose that. It says "No package found."
I pull the drive out (I see no "eject" option anywhere), stick it back in the Mac…and it doesn't mount as a drive. It also doesn't show up as a disk device in /dev or Disk Utility.app.
I figured something died with that thumb drive, so I try another new one…same issue. The Rigol is severely altering my USB thumb drives (although they still enumerate on the Mac, as "IOUSBHubDevice").
Any suggestions? Thanks!
Did you format the USB key as FAT32?
The other two appear to be toast; I don't know how to get them recognized by macOS or Windows in Parallels (they do show up as Disk drives, but no volumes mount) in order to reformat them.
The hack worked! Thanks everybody!
Only issue now is that (I actually noticed this before the hack) I am getting some sort of sound coming from what might be my power supply. Best way to describe it is that it sounds like bugs chirping at night. Sort of a mixture of static and chirping/screeching. It might be a piezoelectric sound from a ceramic cap. The sounds pauses if I hit the “Run-stop” button and is only present when the waveforms are present on the screen. Anyways, long story short, I am probably going to contact amazon and exchange the scope.
I wanted to put the stock firmware back on. Can I just essentially repeat the hack but without the hacked firmware, use the firmware from the Rigol site?
Only issue now is that (I actually noticed this before the hack) I am getting some sort of sound coming from what might be my power supply. Best way to describe it is that it sounds like bugs chirping at night. Sort of a mixture of static and chirping/screeching. It might be a piezoelectric sound from a ceramic cap. The sounds pauses if I hit the “Run-stop” button and is only present when the waveforms are present on the screen. Anyways, long story short, I am probably going to contact amazon and exchange the scope.
I just received my new MSO5074 last Friday and did the "Update" over the weekend.After applying the liberator to my 5072 everything is forever. Has anyone tried using UltraSigma/UltraScope after doing this? and does your HDMI out work?
Thanks to everyone involved in this endeavor for all your hard work and time. I'm sure I speak for everyone that took advantage of your work. YOU ARE ALL GREATLY APPRECIATED! :clap: :clap: :clap:
Mick B has already asked it and i could not finde an answer eithe.
Does someone know whether it is safe to use Ultra Sigma and UltraScope after the "Update"
I'd like to know, is there a better way to power down the scope (the power switch appears to just cut power without giving the system any time to unmount the USB flash drive), when doing a backup or just eject the USB flash drive?
The backup scripts are obviously broken in this respect (it's explicitly stated that they will reboot the scope), can they be fixed?
I'm currently in lazy mode so you have to go with alternative ways: open a telnet session before doing the backup and use it to reboot the machine once the backup is done.So Rigol disabled SSH but left telnet running?! It's no wonder the internet has such large scale DDOS attacks.
Regarding the "explicitly stated that they will reboot": the readme.txt says explicitly "After execution, the scope should reboot, showing that the script ran successfully." The "should" indicates what is probable to happen and NOT what will happen.Which brings up the question, "Did the script run successfully if it did not reboot the scope?"
Download (attachment in the linked post) and unzip the file Patch.zip and put the three files on the USB stick, then Utility/Help/Local upgrade
Calibration - very important
- remove the input probes
- Utility/System/SelfCal
- then turn off/on
Rigol releases new firmware v00.01.03.02.02 for MSO5000 ~ 2023.01.09
Firmware v00.01.03.02.02 Release Notes:
[Supported Model] All the MSO5000 Series Digital Oscilloscopes
[Latest Revision Date] 2023/01/04
[Updated Contents]
--------------------
v00.01.03.02.02 2023/01/04
- Add shortcut button and VNC remote function
- Waveform, cursor movement, gesture operation vertical and horizontal gear switching speed optimization
- Cursor optimization: cursor jump optimization, ZOOM area and main time base cursor linkage, etc
- The color of the CH4 waveform is modified, and the brightness of the waveform is improved
- ZOOM mode optimization: mask color adjustment, switching speed, area movement optimization
- SCPI instruction response speed optimization: reset, measurement, waveform read instruction response optimization
v00.01.03.00.03 2021/10/18
- Optimized waveform display in XY mode.
- Optimized the DC gain calibration algorithm.
- The La channel is decoded in parallel, which solved the problem of decoding error in negative polarity.
Download:
https://supportcn.rigol.com/Public/Uploads/uploadfile/files/ftp/Firmware/MSO5000(ARM)Updatev00.01.03.02.02.zip
Hi there, same question. I'm located in Spain.
If I go to https://www.rigol.eu/products/oscillosopes/MSO5000%20series.html (https://www.rigol.eu/products/oscillosopes/MSO5000%20series.html) it only shows 00.01.03.00.03 version (which it's already installed in my device)
However, in this page, https://www.rigolna.com/products/digital-oscilloscopes/MSO5000/MSO5074/ (https://www.rigolna.com/products/digital-oscilloscopes/MSO5000/MSO5074/) (I assume NA stands for North America) it points to a 1.1.4.4 version file, which is different of the one you posted, but with the same publish date.
It is possible to apply a NA firmware on a EU Device? For the time being, I will keep 00.01.03.00.03 before update.
Thank you! Regards!
That's because the patch literally patches the firmware. So whenever there is a new firmware, a new patch has to be created.
OK, so it will be as easy to modify the patch.txt with the new md5 but keeping the resulting md5 file as it is?
That's because the patch literally patches the firmware. So whenever there is a new firmware, a new patch has to be created.
Is there still no solution after 5yrs the scope is on the market?
I went to the US Rigol site, and it is just the same 03.00.03 version as it has been for the past year. If they pulled it from the China site already and it is not available anywhere else, I wonder if they found some new issues with it. I would recommend those who found their scope to operate satisfactorily wait until an update is available globally so you don't end up with the extra effort of downgrading to the previous version.
I went to the US Rigol site, and it is just the same 03.00.03 version as it has been for the past year. If they pulled it from the China site already and it is not available anywhere else, I wonder if they found some new issues with it. I would recommend those who found their scope to operate satisfactorily wait until an update is available globally so you don't end up with the extra effort of downgrading to the previous version.
It is a little bit ago I had the scope but when I remember it right, having a new firmware only in china avaible is somekind of beta-status.
I wouldn´t take this...
I installed it and not have any problems. Also I saw a video (it is in spoken Spanish) https://www.youtube.com/watch?v=kGYsmTFGob0&ab_channel=NaserElectronica-Chile (https://www.youtube.com/watch?v=kGYsmTFGob0&ab_channel=NaserElectronica-Chile) with a guy installing it and working with it. I just renamed MSO5000 to DS5000 and started working. For the time being, I will revert back and apply the patch and wait until this version (and the patch) came publicly available again.
I installed it and not have any problems. Also I saw a video (it is in spoken Spanish) https://www.youtube.com/watch?v=kGYsmTFGob0&ab_channel=NaserElectronica-Chile (https://www.youtube.com/watch?v=kGYsmTFGob0&ab_channel=NaserElectronica-Chile) with a guy installing it and working with it. I just renamed MSO5000 to DS5000 and started working. For the time being, I will revert back and apply the patch and wait until this version (and the patch) came publicly available again.
I have a question : apart the hack disruption, there are other negative aspects with this upgrade ?
I installed it and not have any problems. Also I saw a video (it is in spoken Spanish) https://www.youtube.com/watch?v=kGYsmTFGob0&ab_channel=NaserElectronica-Chile (https://www.youtube.com/watch?v=kGYsmTFGob0&ab_channel=NaserElectronica-Chile) with a guy installing it and working with it. I just renamed MSO5000 to DS5000 and started working. For the time being, I will revert back and apply the patch and wait until this version (and the patch) came publicly available again.
I have a question : apart the hack disruption, there are other negative aspects with this upgrade ?
No.
If you take a careful look at the original download link for the new firmware,
https://supportcn.rigol.com/Public/Uploads/uploadfile/files/ftp/Firmware/MSO5000(ARM)Updatev00.01.03.02.02.zip
It is not the same link that you would download official firmware from the China Rigol website. It appears to be a file located in the public upload directory of the support website. My guess is it is a test firmware someone in Rigol uploaded to their support site, so the people they are working with can download it for testing, or to address a certain problem. Someone noted the existence of this file and published the link, which Rigol subsequently took down (not uncommon for test firmware).
So while this version of the firmware does deliver some additional capabilities, it may be premature to treat this as an next version of the firmware update. Depending on your intention, you may, or may not want to use it. I noticed the original link was never brought up in the discussion, and I just want everyone to be aware of it.
followed this instructions https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3869852/#msg3869852 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3869852/#msg3869852)
and got this once tried to apply the patch.. USB stick formatted in FAT32.. so any idea on what's happaning?
Rigol just released a version of the 1.03.02.02 on the US website. When you do the actual download, the file name is MSO5_FW_V1_1_4_4, the upgrade instruction.txt file is still gibberish, likely in a different language. For the actual GEL file, the checksum was exactly the same as the one in the Chinese site which disappeared earlier. They never had a professional discipline in managing firmware update when the MSO5000 came out, sadly this trend continues years later.
the upgrade instruction.txt file is still gibberish, likely in a different language.
unfortunately it's not working. It's look like I'm unable to rollback
Are you able to get to the "secret" menu and select "Upgrade Firmware" by the button just under the "Menu Off" button?
What message(s) does the oscilloscope display when you try to do the rollback update from that menu?
It's known that the oscilloscope can be picky about what USB stick is used. Make sure any USB sticks you use are FAT32 formatted and try more than one of different brands. Also I'd suggest that the .GEL file be the only file on the stick and make sure the .GEL file is named: "MSO5000Update.GEL"
The fourth one did the job (sandisk).
1. Is everyone still using patched firmware from 2021?
Has something changed in recent firmwares that breaks the current approach for unlocking the scope?
Btw, I'm slightly confused by the patches posted here - there seems to be one 'real' change and the rest is just forcing the menu screen to display 'Forever'. I don't know why this was done, probably to make people feel better when they're posting screenshots of their menus. Either way, I can't do any better since I don't have a scope to debug on, so I just made similar changes while poking around at 01.03.02.02 firmware. Once again, I have no way of testing the patch, so use at your own risk.
Btw, I'm slightly confused by the patches posted here - there seems to be one 'real' change and the rest is just forcing the menu screen to display 'Forever'. I don't know why this was done, probably to make people feel better when they're posting screenshots of their menus. Either way, I can't do any better since I don't have a scope to debug on, so I just made similar changes while poking around at 01.03.02.02 firmware. Once again, I have no way of testing the patch, so use at your own risk.
Thanks lujji tested working 100%
uploaded the patch files i've used .
When I download the firmware using the link above “official firmware” I don’t get 01.03.02.02 I get V1_1_4_4 (Rigol download page says 01.03.02.02. seems like the text does not match the file.
<root@rigol>/rigol/appEntry -run
7 2048 16 2 "/dev/fb0"
!!!rom head fail
!!!rom inl fail
!!!rom head fail
!!!rom inl fail
Could someone please check on their MSO5 if these errors appear there as well, when running "pkill -9 appEntry; /rigol/appEntry -run"? FW version doesn't matter, but would be good to know which one.Code: [Select]<root@rigol>/rigol/appEntry -run
7 2048 16 2 "/dev/fb0"
!!!rom head fail
!!!rom inl fail
!!!rom head fail
!!!rom inl fail
Could someone please check on their MSO5 if these errors appear there as well, when running "pkill -9 appEntry; /rigol/appEntry -run"? FW version doesn't matter, but would be good to know which one.Code: [Select]<root@rigol>/rigol/appEntry -run
7 2048 16 2 "/dev/fb0"
!!!rom head fail
!!!rom inl fail
!!!rom head fail
!!!rom inl fail
Could someone please check on their MSO5 if these errors appear there as well, when running "pkill -9 appEntry; /rigol/appEntry -run"? FW version doesn't matter, but would be good to know which one.Code: [Select]<root@rigol>/rigol/appEntry -run
7 2048 16 2 "/dev/fb0"
!!!rom head fail
!!!rom inl fail
!!!rom head fail
!!!rom inl fail
When sent as SCPI code here is the response I get:
* Connected to: USB0::0x1AB1::0x0515::MS5AXXXXXXXXX1::INSTR
-> *IDN?
<- (Return Count:56)
RIGOL TECHNOLOGIES,MSO5074,MS5AXXXXXXXXX,00.01.03.00.03
-> *IDN?
<- (Return Count:56)
RIGOL TECHNOLOGIES,MSO5074,MS5XXXXXXXXX,00.01.03.00.03
-> pkill -9 appEntry; /rigol/appEntry -run
<- (Return Count:0)
* Error!!!
VISA: (Hex 0xBFFF0015) Timeout expired before operation completed.
But this is above my (non)coding ability. Hopefully this is helpful, can try other things if you are willing to walk me thru it.
Well, SCPI is handled by appEntry AIUI. So, when you kill appEntry, SCPI won't work (and you won't get the response back). I guess this can be only tested via SSH.
Yes, figured that out last night, will install and use PUTTY today.
EDIT: Need help in enabling SSH. Looking thru all the posts to find the right one is getting frustrating. Will keep at it, but a guide would be helpful. Just not finding it right now.
cat <<"EOF" >fw4linux.sh.plain
#!/bin/sh
. /media/sda1/mod.sh
EOF
openssl aes-128-cbc -K BAD8CFFEBBAAB5C4C3D8D4BFCAFDBEDD -iv BAD8CFFEBBAAB5C4C3D8D4BFCAFDBEDD -in "fw4linux.sh.plain" >fw4linux.sh
tar -cf DS5000Update.GEL fw4linux.sh
#!/bin/sh
# enable ssh
echo '/usr/sbin/sshd &' >>/rigol/shell/start.sh
sync
# run ssh
/usr/sbin/sshd &
EDIT: Hmm, the SSH enabling coding "upgrade" from c0d3z3r0 now fails with the new firmware. :-//
EDIT: Hmm, the SSH enabling coding "upgrade" from c0d3z3r0 now fails with the new firmware. :-//
just reboot scope and you got perfectly working sshd, ignore error.
Hi, with that patch, ssh will remain available at next boot? I want to have it permanently. Thank you!
Excellent work. Successful permanent (ish) SSH communication with PUTTY. Thanks again! :-+
Reads quite dramatic at the end, like a computer's dying words. It made me go look at the scope in the garage to make sure it hadn't caught on fire while I was telnetting from upstairs. Of course it was fine ;)
Another successful upgrade to a MSO5074 using the 00.01.03.02.02 GEL file from RigolNA build date 2022-12-05.
Alright, here is the result of entering "/rigol/appEntry -run" at the <root@rigol> prompt while connected to MSO5000 via SSH:
<root@rigol>/rigol/appEntry -run
7 2048 16 2 "/dev/fb0"
servscpi.cpp 120 "The bound address is already in use"
Cal Data: "/rigol/data/cal_1.hex"
default setting by user set
insmod: can't insert '/rigol/drivers/libcomposite.ko': File exists
insmod: can't insert '/rigol/drivers/usbtmc_dev.ko': File exists
usbtmc.cpp 129 error:can not open /dev/usbtmc_dev,fd:-1
insmod: can't insert '/rigol/drivers/usb_gpib.ko': File exists
!!!!!!!!!!!!!!!!!!!CCU wait stop fail---------------------
Reads quite dramatic at the end, like a computer's dying words. It made me go look at the scope in the garage to make sure it hadn't caught on fire while I was telnetting from upstairs. Of course it was fine ;)
Hope this info is helpful to those that know what it means :DQuote
Here are the errors using the "pkill -9 appEntry; /rigol/appEntry _run
7 2048 16 2 "/dev/fb0"
Cal Data: "/rigol/data/cal_1.hex"
default setting by user set
insmod: can't insert '/rigol/drivers/libcomposite.ko': File exists
insmod: can't insert '/rigol/drivers/usbtmc_dev.ko': File exists
insmod: can't insert '/rigol/drivers/usb_gpib.ko': File exists
Hi,
i have a problem i installed original firmware "v00.01.03.02.02 2023/01/04"
but maybe I haven't finished upgrading, now when I start the MSO it freezes almost at the end of loading and stays block
Now I tried reinstalling the firmware with secret menu Start MSO and press Hold Single
but nothing continues to boot normally until it block
(Attachment Link)
ohhhh wow thank you so much , Now I try to reinstall the original firmware
ohhhh wow thank you so much , Now I try to reinstall the original firmware
)
1st - which color of Start/Stop button after unsucsessful boot (green or red)?
2nd - try to set defaults in hidden menu before reinstalling microcode, it can help.
I did the upgrade this morning. It did not go without hiccups so I thought I would report my findings
1. My scope HW version is 01.00.000 and was updated and patched to the previous release
2. I'm using a 4GB USB drive formatted as Fat32. The drive is empty except for the FW files or patch files (not at the same time). I'm pretty sure that I have used this drive before for updates
3. I downloaded and extracted MSO5_FW_Update to the flash drive
4. Updated using the local upgrade options feature
5. On reboot the startup gas gage goes to full and then stalls. Dang
6. Second reboot - no change
7. Enter the secret menu by pressing Single button during reboot. Two options presented: Upgrade Firmware and Restore Defaults
8. Tried Upgrade Firmware - scope reports a FW error
9. Tried Restore Defaults - the scope boots and shows FW 00.01.03.02.02(!)
10. Ran the patch using the local upgrade option. Can confirm that the patch does not reboot the scope upon completion
11. Reboot scope, all options show forever 8)
Thanks to lujji and everyone else who has worked enhancing this scope
Unlike NoisyBoy, my scope was not running using default settings
Could someone please check on their MSO5 if these errors appear there as well, when running "pkill -9 appEntry; /rigol/appEntry -run"? FW version doesn't matter, but would be good to know which one.
/rigol/appEntry _run
7 2048 16 2 "/dev/fb0"
messageExchange.cpp 172 pCurrentIntf == NULL
insmod: can't insert '/rigol/drivers/libcomposite.ko': File exists
insmod: can't insert '/rigol/drivers/usbtmc_dev.ko': File exists
insmod: can't insert '/rigol/drivers/usb_gpib.ko': File exists
Could someone please check on their MSO5 if these errors appear there as well, when running "pkill -9 appEntry; /rigol/appEntry -run"? FW version doesn't matter, but would be good to know which one.Code: [Select]<root@rigol>/rigol/appEntry -run
7 2048 16 2 "/dev/fb0"
!!!rom head fail
!!!rom inl fail
!!!rom head fail
!!!rom inl fail
with FW 00.01.03.00.01Code: [Select]/rigol/appEntry _run
7 2048 16 2 "/dev/fb0"
messageExchange.cpp 172 pCurrentIntf == NULL
insmod: can't insert '/rigol/drivers/libcomposite.ko': File exists
insmod: can't insert '/rigol/drivers/usbtmc_dev.ko': File exists
insmod: can't insert '/rigol/drivers/usb_gpib.ko': File exists
Thank you! Is there anything in your /rigol/data/vendorlog.txt?
Thank you! Is there anything in your /rigol/data/vendorlog.txt?
same text as in yours.
I made a guide to help all the users to get through the upgrade process.
v00.01.03.02.02 2023/01/04So hack disappears, like others reported?
Successful firmware update with default setting on boot (reverted from Last for the purpose of the update).
Observations:CH1 only or all channels?
1. 500uV range is no longer available on CH1
(listed under page 18, Overview of the MSO5000 Series Technical Specifications > Vertical System Analog Channel > Vertical Sensitivity Range)
2. Selecting 1mV range automatically engages 20MHz bandwidth limit, with B indicated in the channel status labelPrevious software version engaded 20 MHz limit on 0.5 mV/1 mV / 2 mV if I remember correcly. Datasheet mentions those ranges are software created from 4 mV/div (which is not directly available - as there is 5 mV/div step, so seems HW is more binary with some VGA too)
How did you get VNC to function?
v00.01.03.02.02 2023/01/04So hack disappears, like others reported?
Successful firmware update with default setting on boot (reverted from Last for the purpose of the update).Observations:CH1 only or all channels?
1. 500uV range is no longer available on CH1
(listed under page 18, Overview of the MSO5000 Series Technical Specifications > Vertical System Analog Channel > Vertical Sensitivity Range)2. Selecting 1mV range automatically engages 20MHz bandwidth limit, with B indicated in the channel status labelPrevious software version engaded 20 MHz limit on 0.5 mV/1 mV / 2 mV if I remember correcly. Datasheet mentions those ranges are software created from 4 mV/div (which is not directly available - as there is 5 mV/div step, so seems HW is more binary with some VGA too)
So are the hacks stil working with the newest hardware revisions?
And what to get as a basic model?
Rigol MSO5074 and for the LA probes Rigol PLA2216 ?
https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/ (https://www.eevblog.com/forum/testgear/low-cost-logic-analyzer-probe-for-rigol-mso5000-easyeda-project/) which seems to be based on https://eltguy.de/en/selbstbauprojekte-elektronik-technik-hobbytechnologien/logic-probe-ein-digitaler-16-kanal-tastkopf-fuer-oszilloskop/ (https://eltguy.de/en/selbstbauprojekte-elektronik-technik-hobbytechnologien/logic-probe-ein-digitaler-16-kanal-tastkopf-fuer-oszilloskop/)
Hi guys, I upgraded my oscilloscope perfectly well and smooth. I made a guide to help all the users to get through the upgrade process.
I hope you can find it useful and of course, any suggestion to improve the guide will be very welcome.
https://www.mediafire.com/folder/zh1uiu3umgoai/Documents (https://www.mediafire.com/folder/zh1uiu3umgoai/Documents)
I uploaded to mediafire because I can't share them here. The firmware.rar files contains all the files needed to work with the guide. The Word file is the guide with images.
Thanks a lot!!!!
I can't find any 1.3.2.2 FW upgrade file on the Rigol website???? :-//
Is there a way to unbrick the scope without opening it up? I took out my MSO5102 out of a box lately (it was working perfectly before), and powered it on. It hangs with a black screen without showing a boot screen now, any clues? Thanks in advance!
So pressing "single" does nothing then? Everything other than power unplugged from the unit?Thanks! It seems like the flash memory kicked the bucket. Thankfully, it was still under the warranty.
Is it still under warranty?
Hi guys, I upgraded my oscilloscope perfectly well and smooth. I made a guide to help all the users to get through the upgrade process.
I hope you can find it useful and of course, any suggestion to improve the guide will be very welcome.
https://www.mediafire.com/folder/zh1uiu3umgoai/Documents (https://www.mediafire.com/folder/zh1uiu3umgoai/Documents)
I uploaded to mediafire because I can't share them here. The firmware.rar files contains all the files needed to work with the guide. The Word file is the guide with images.
Thanks a lot!!!!
"Have an ethernet network wire to connect it directly to your computer. "
Do you connect ethernet cable to the oscilloscope through router or the connection was done directly - from oscilloscope to PC? If it is direct connection to PC without router, did you use LAN crossover cable or LAN straight through cable?
Thanks!
Hello comrades!
I want to purchase Rigol MSO5072, are there any ways to hack it before MSO5354? And will all 4 channels work?
I want to purchase Rigol MSO5072, are there any ways to hack it before MSO5354? And will all 4 channels work?
Hi guys, I upgraded my oscilloscope perfectly well and smooth. I made a guide to help all the users to get through the upgrade process.
I hope you can find it useful and of course, any suggestion to improve the guide will be very welcome.
https://www.mediafire.com/folder/zh1uiu3umgoai/Documents (https://www.mediafire.com/folder/zh1uiu3umgoai/Documents)
I uploaded to mediafire because I can't share them here. The firmware.rar files contains all the files needed to work with the guide. The Word file is the guide with images.
Thanks a lot!!!!
Hello comrades!
I want to purchase Rigol MSO5072, are there any ways to hack it before MSO5354? And will all 4 channels work?
It seem to be a legit location.
I didn't think about it, I ordered 5072.
But I would like to buy 1:10 probes on the 500MHz
https://aliexpress.ru/item/1005004828373989.html?
Succesful upgrade here! Thanks!
Hi guys, I upgraded my oscilloscope perfectly well and smooth. I made a guide to help all the users to get through the upgrade process.
I hope you can find it useful and of course, any suggestion to improve the guide will be very welcome.
https://www.mediafire.com/folder/zh1uiu3umgoai/Documents (https://www.mediafire.com/folder/zh1uiu3umgoai/Documents)
I uploaded to mediafire because I can't share them here. The firmware.rar files contains all the files needed to work with the guide. The Word file is the guide with images.
Thanks a lot!!!!
Hi! The link is no longer working, who has this information on the link?
Hi guys, I upgraded my oscilloscope perfectly well and smooth. I made a guide to help all the users to get through the upgrade process.
I hope you can find it useful and of course, any suggestion to improve the guide will be very welcome.
https://www.mediafire.com/folder/zh1uiu3umgoai/Documents (https://www.mediafire.com/folder/zh1uiu3umgoai/Documents)
I uploaded to mediafire because I can't share them here. The firmware.rar files contains all the files needed to work with the guide. The Word file is the guide with images.
Thanks a lot!!!!
Hi! The link is no longer working, who has this information on the link?
I just tried the link above. There are two files for download. A word document and a file with the patched firmware.
I checked for viruses, all clear. Now I am reading the word document. I didn't patch it until now.
Update: I just did the firmware upgrade and patch according to above. It all works. Now I have the newest firmware and all options.
Thanks a lot to everybody!
Fairly new here. Obviously, lujji was able to read through this thread and create a patch for the previous fw version even before owning the scope, so I started to read too... I'm only up to mid-2019 when the ideal of using a patch file surfaced after SSH was removed by Rigol... Surely, there's got to be a better way to summarize the knowledge of this thread and how to create patch files without having to read the entire history, right?
Hi guys, I upgraded my oscilloscope perfectly well and smooth. I made a guide to help all the users to get through the upgrade process.
I hope you can find it useful and of course, any suggestion to improve the guide will be very welcome.
https://www.mediafire.com/folder/zh1uiu3umgoai/Documents (https://www.mediafire.com/folder/zh1uiu3umgoai/Documents)
I uploaded to mediafire because I can't share them here. The firmware.rar files contains all the files needed to work with the guide. The Word file is the guide with images.
Thanks a lot!!!!
Hi faktorqm,
Great work done sorting it out and do such a detailed explanation.
Just one question to clarify from the guide at the beginning:Quote"Have an ethernet network wire to connect it directly to your computer. "
Do you connect ethernet cable to the oscilloscope through router or the connection was done directly - from oscilloscope to PC? If it is direct connection to PC without router, did you use LAN crossover cable or LAN straight through cable?
Thanks!
I did start to go down the path with Ghidra, but I didn't know which specific changes needed to be made. I'm definitely not trying the hard way. I just haven't gotten through the entire thread yet to find the most recent, easiest way, I guess.
You can't use the old bspatch with the latest firmware because one of the functions moved. Try this one. Be warned I have not tried it myself so if someone that knows what they are doing (ie. you can recover) can verify first that would be great.Tried the patch here. Seems to work OK, will report back if/when something changes, but so far everything good.
I don't know why you guys are using the hard method like objdump to figure out patches when there is Ghidra.
-----------------------------------
Tried the patch here. Seems to work OK, will report back if/when something changes, but so far everything good.
Tried the patch here. Seems to work OK, will report back if/when something changes, but so far everything good.
I finally had a chance to try it myself and I can also confirm it seems to work fine.
Okay... I've gotten as far as extracting the appEntry from the V00.01.03.03.00 GEL file.
It's got an MD5 checksum of AD018912E3D9BA19809EB3A44B63FEA0
But I don't know what to edit. Are people just patching the appEntry back to the previously patched appEntry or something?? I'm still trying to read through the whole thread.
EDIT: After a lot more reading, I found that back in 2020, omgoleus pretty much went through the same thought process and asked the same questions that I have and I'm asking today. I even started down the path of disassembling appEntry. omgoleus did write a nifty script to do partially automate the comparison process of the previously-patched appEntry. I'll attempt to try this later... it's 4:30am and I have to wake up for an 8am daily stand-up meeting for my day job soon.
Okay... I've gotten as far as extracting the appEntry from the V00.01.03.03.00 GEL file.
It's got an MD5 checksum of AD018912E3D9BA19809EB3A44B63FEA0
But I don't know what to edit. Are people just patching the appEntry back to the previously patched appEntry or something?? I'm still trying to read through the whole thread.
EDIT: After a lot more reading, I found that back in 2020, omgoleus pretty much went through the same thought process and asked the same questions that I have and I'm asking today. I even started down the path of disassembling appEntry. omgoleus did write a nifty script to do partially automate the comparison process of the previously-patched appEntry. I'll attempt to try this later... it's 4:30am and I have to wake up for an 8am daily stand-up meeting for my day job soon.
Would you mind sharing the process/tools used to unpack the scope`s firmware?
The link shows it is again their public file upload site in China, not their official firmware site. I would highly recommend folks to wait for official firmware to show up in their home country before doing upgrade. For two reasons, so you can get support from Rigol if the upgrade goes south. Second, I would never download firmware from a dubious site in China, let alone running it.
This happened once with the existing firmware 01.03.02.02, when it showed up in the exact same site, then disappeared, then it showed up on the official download site weeks later. I would wait.
> sha256sum cn/DS5000\(ARM\)Update\ v00.01.03.03.00/DS5000Update.GEL na/DS5000\(ARM\)Update\ v00.01.03.03.00/DS5000Update.GEL
f89cdf7816b0467e6ebe46d4f5da1cf0a95fffd93b83a245911026520d66b794 cn/DS5000(ARM)Update v00.01.03.03.00/DS5000Update.GEL
f89cdf7816b0467e6ebe46d4f5da1cf0a95fffd93b83a245911026520d66b794 na/DS5000(ARM)Update v00.01.03.03.00/DS5000Update.GEL
mkdir /media/sda1/calib_backup
cp -v /rigol/data/* /media/sda1/calib_backup
sync
Copy Calibration (Calibration files only)cp -v /media/sda1/calib_backup/*.hex /rigol/data/
sync
How can I restore the oscilloscope based on the files from each method?
Since you are not able to see the differences between the different procedures/backups, it's better to not attempt any restore yourself.
You should attempt restore as a last resort and, then, ask a friend to do it for you.
or do not attemp the backup yourself anyway, that's very dangerous. Please at least delete the post so no people will overwrite their cal data by doing a '' backup '' :palm:there is nothing dangerous in my message, it's all on the forum, I just collected it all in one place
Indeed, the VNC server is very fast, the screen update and also the commands response.
The menu is changed, and there is an additional operator in Math, AX+B.
Also, the touch screen response seems to be faster.
Regarding the CH4 colour, I'm not sure that it's a significant changes.
The attached pictures are from VNC.
Additionally, I've read a few threads that claim the hack is no longer workable if the firmware version is newer than "01.03.00.01."
I came to the conclusion that there are several methods for enhancing the scope's functions, each of which depends on the scope's firmware version.
To be completely honest, I'm not sure which process to use and feel a little lost.
I find it puzzling that the Rigol website lists the most recent firmware version as 00.01.00.00.01.
https://www.rigol.eu/SUPPORTS/software-firmware-download.html (https://www.rigol.eu/SUPPORTS/software-firmware-download.html)
Everything was fine here too.
I will use my previous upgrade post, updated for v00.01.03.00.03 -> v00.01.03.03.00.
Steps I've followed :
1. Backup everything just in case (optional but recommended)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2757356/#msg2757356 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2757356/#msg2757356)
- get and unzip the first script file, put DS5000Update.GEL on USB stick, then Utility/Help/Local upgrade
- wait until 100%, then turn off/on
- repeat for the second script
2. Install the official firmware v00.01.03.03.00; I have used the above link from rigol.eu
- get the official firmware and unzip
- same steps like above, with the firmware file of course
3. Hack
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4821650/#msg4821650 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4821650/#msg4821650)
- get and unzip the file 01_03_03_00.zip and put the three files on USB stick
- same steps like above
- there will be some messages on the screen. You will be asked to press a key, two times. At the end the oscilloscope will reboot, just wait.
- all the options will be activated
4. Calibration - very important
- remove the input probes
- Utility/System/SelfCal
- then turn off/on
Thanks everybody !
I'm using the v00.01.03.03.00 MSO5000 firmware and the Trixy 01.03.03.00 PATCH. and just noticed the frequency measurement does not work on any channel. BUT it works in the counter app.
any one else having this problem?
the scope stucks on boot, restarted many times, same problem, how do I proceed? Please Help!!
I did a Restore Defaults after pressing Single during the boot process, and it worked!O.K. Single not RUN/STOP. Glad to hear that it worked!
Thanks!
There's just one thing I'm wondering that I can't find an answer to using goOGLE - the width and fuzziness of the vectors on all channels feels... weird. My old (and very simple) FNIRSI scope had a much cleaner 1px thick vector. Is this a setting I can change - or is it something I'll just have to learn to live with?Hi and welcome to this forum.
01.03.03.00 is available on the MSO5000 downloads page https://www.rigolna.com/products/digital-oscilloscopes/mso5000/ (https://www.rigolna.com/products/digital-oscilloscopes/mso5000/)Ver 01.03.03.00 is not available on the download page. Does anyone have a copy or was it pulled because of being too buggy to use or something?
but on the support/firmware page still shows 01.03.02.02 ...
01.03.03.00 is available on the MSO5000 downloads page https://www.rigolna.com/products/digital-oscilloscopes/mso5000/ (https://www.rigolna.com/products/digital-oscilloscopes/mso5000/)Ver 01.03.03.00 is not available on the download page. Does anyone have a copy or was it pulled because of being too buggy to use or something?
but on the support/firmware page still shows 01.03.02.02 ...
Anyway back to my original question is there a hack for ver. 00.01.03.02.02?
I updated to FW V00.01.03.03.00 then successfully unlocked my MSO5074.How could you when that version is not out?
Wrong, 00.01.03.02.02 is the latest on the Rigol site that I just downloaded and installed. If there is another version such as 01.03.03.00 it doesn't seem to be available.
Apologies if this has been repeated too many times. I'm wondering if anyone is still selling the labels to go over the original mso5xxx sticker. I live in Canada and would make it worth their while. I'd pay shipping plus 25 usd. Or a link to a printable label if they are not being sold like I read a while back. Thanks in advance.
You guys can argue about it with Rigol if you want but the latest version they have is 00.01.03.02.02!
https://www.rigolna.com/firmware/ (https://www.rigolna.com/firmware/)
DS5000Update.GEL
MSO5000 Release Notes.txt
MSO5000 Upgrade Instructions.txt
MSO5000 升级说明.txt
MSO5000 版本说明.txt
Whay do you needed it? the original model number is still visible in the information menu... , the options listed shows upgrade to 350 bandwidth + 4 channels and thanks to all in this forum who made that possible ! :)Apologies if this has been repeated too many times. I'm wondering if anyone is still selling the labels to go over the original mso5xxx sticker. I live in Canada and would make it worth their while. I'd pay shipping plus 25 usd. Or a link to a printable label if they are not being sold like I read a while back. Thanks in advance.
This ought to help :)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4735574/#msg4735574 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4735574/#msg4735574)
lol, https://tortel.li/post/insecure-scope/
For all of those who still wonder how the hack works, that's a good sum up.
Sidenote, they went a bit too quick on the "download the gel" part, because we all know it doesn't work like that.
Finally, the conclusion confirms how rigol cares.
I updated to FW V00.01.03.03.00 then successfully unlocked my MSO5074.How could you when that version is not out?
This is starting to look like Youtube and Amazon where most of the reviews and videos are fakes!+
Using the modified 3.3 updated firmware. I have noticed sometimes it won't go into sleep mode, like it used to. Anyone else noticed this?
Everything was fine here too.
I will use my previous upgrade post, updated for v00.01.03.00.03 -> v00.01.03.03.00.
Steps I've followed :
1. Backup everything just in case (optional but recommended)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2757356/#msg2757356 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2757356/#msg2757356)
- get and unzip the first script file, put DS5000Update.GEL on USB stick, then Utility/Help/Local upgrade
- wait until 100%, then turn off/on
- repeat for the second script
2. Install the official firmware v00.01.03.03.00; I have used the above link from rigol.eu
- get the official firmware and unzip
- same steps like above, with the firmware file of course
3. Hack
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4821650/#msg4821650 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4821650/#msg4821650)
- get and unzip the file 01_03_03_00.zip and put the three files on USB stick
- same steps like above
- there will be some messages on the screen. You will be asked to press a key, two times. At the end the oscilloscope will reboot, just wait.
- all the options will be activated
4. Calibration - very important
- remove the input probes
- Utility/System/SelfCal
- then turn off/on
Thanks everybody !
What I need to do, please help.
In a rare case when scope does not boot, press "Single" key at the very beggining of the boot phase and press "Restore defaults" or "Upgrade firmware" to re-apply the original Fw.
... then I tried to load v00.01.03.03.00 once again, but I used old 4GB flash drive. At this time it's succesful. I think, this problem caused by flash drive.Yes, the scope can be a bit picky with flash drives.
Hello everyone,Hi,
I am about to buy the MSO5104, but I would like to know if there is a difference with the MSO5074...
For sure, I will then make it to 350 MHz!
You can also buy the 5072 model but you will get only 2 probes instead of 4.
Thanks for tour answers. In fact, the MSO5104 has the FREE MSO5000-BND included. Is it worth to get it or can I hack to get all the functions?
Of course there is the 50 ohm stuff as well, it looks like there might be another 50 ohm path directly into the ASIC. Not much you'd be able to do about that. It looks like it might be grounded on the 5000, need to check.Have you considered measuring output circuit of frontend(above ic on your pictures)? It seems that bw limit is not located at input. Just look at fft attached. The noise has roll off with corner freq around 500M. Noise of adc converter is uniform, so this should be frontend amp noise after low pass filter.
I don't know what RLC values are used for the MSO7000, the only one I'm sure of is is the inductor Lx is around 2-4nH (it has 4 turns). Any recommendations for values or ideas let me know.
Noise of adc converter is uniform, so this should be frontend amp noise after low pass filter.Made some additional shots. They seem coherent with what I read on different bandwidths of channels. Fastest two in my case is Ch 3 and Ch 4, and Ch 2 is crippled, Ch 1 is average ~500M.
I removed it from channel 4 (no caps and inductors replaced with 0 Ohm resistors )
Well you are way faster than me, nice work. But I don't know if completely removing it is ideal, as you could get aliasing from the front end amp noise? The MSO7000 also has a filter in this location, though Dave's photos don't show it clearly so I can't tell what component values might be.According to my measurements, you are right, 1pF+47nH. Regarding noise, there is some <1db noise rise in an area of 500-1000MHz, but this not visible on a trace, rms noise measures same values on modified and not modified channels.
From my measurements the CLC was something like 1pF -> 47nH -> 1pF? But I did not remove the components to verify yet. This might be around the 300MHz range.
Little hint, not to artificially limit it.I know several reasons why this lowpass could be there , as well as why it could be remover or used by rigol for other purposes, here little hint for you:
Why they are boosting the ~300M range I'm not sure (10p/4.6R). And the effect of 770p/560R would seem to be near nothing.Are you sure that 750p is a capacitance? I thought it is a small inductance, white caps are rare.
Why they are boosting the ~300M range I'm not sure (10p/4.6R). And the effect of 770p/560R would seem to be near nothing.Are you sure that 750p is a capacitance? I thought it is a small inductance, white caps are rare.
ADC input impedance should be ~110 Ohm.
Thanks lujji and stmcore (I didn't tried the patch yet).Log into your network router and create a DHCP reservation for the scope by mac address. Then you don't have to configure the scope manually and you always get the same ip.
Also, the IP address (I set it to manual) cannot remember the changes, and get lost every time I reboot the scope.
Thank you! Regards!
Range Bandwidth (MHz)
1V 605
500mV 610
200mV 620
100mV 630
50mV 580
20mV 590
10mV 590
- There was no difference in bandwidth with 12nH over 15nH, so the limitation does not lie there.With 0R resistors caps sould be removed, if you left them this probably explains the result.
- Using 0R resistors across the inductors gave me no significant improvement over stock (odd).
- Removing the 1pF at the front of the CLC made things either slightly worse or did nothing.
- Adding a MSO7000 style RCL filter at the front end did improve bandwidth up to ~700MHz but at the cost of ~3dB of peaking at 400MHz. Too much IMO.
With 0R resistors caps sould be removed, if you left them this probably explains the result.
Also for lower values of L, should the caps be replaced with new values so impedance of CLC filter is not changed?
I built an appEntry for MSO7000 v00.01.04.00.00 in case anybody needs it.
Yeah that could explain it as I left them in, giving a 2pF load.I tried to calculate lc filter and with 110 ohm adc load filter with 1pf & 47nH makes no sense, corner frequency should be too high. We need to guess a new value for adc input impedance.
I don't have any values less than 1pF, but, I guess I can try some 0402 0.5pF in the future. Didn't even know they were a thing.
this probably means that at 1G there is no noise from frontend, and likely BW limit lies in its configuration bits.
I'm not sure if you are doing all this stuff with a 7000 device.No, I only have an mso5k.
In that case, we can't do much more "officially" as the FW doesn't have the "5104" model.Not sure what do you mean by officially. My scope has same features as anybody elses , ie unlocked to 350mhz model.
There is no 1GHz model of course, but mso5k shares frontend ic with 7k scopes, that is why we have expectations to have at least same bw as on 7k.
Is there a way to restore the oscilloscope that has been stuck in the RIGOL display window due to an operational error? I have backed up the data, and there is a way to tell me. Thank you very much.Try "restoring defaults". Immediately after power on, wait for the power-on lights to go out (for the Single key to stop glowing orange) and press the "Single" key once. Choose the "Restore Defaults" option. Hope it helps.
You can enter the operation and prompt for recovery failure after the operation.What additional files do I need to add and what folders do I need,Can you tell me? Thank you.Is there a way to restore the oscilloscope that has been stuck in the RIGOL display window due to an operational error? I have backed up the data, and there is a way to tell me. Thank you very much.Try "restoring defaults". Immediately after power on, wait for the power-on lights to go out (for the Single key to stop glowing orange) and press the "Single" key once. Choose the "Restore Defaults" option. Hope it helps.
You can enter the operation and prompt for recovery failure after the operation.What additional files do I need to add and what folders do I need,Can you tell me? Thank you.Is there a way to restore the oscilloscope that has been stuck in the RIGOL display window due to an operational error? I have backed up the data, and there is a way to tell me. Thank you very much.Try "restoring defaults". Immediately after power on, wait for the power-on lights to go out (for the Single key to stop glowing orange) and press the "Single" key once. Choose the "Restore Defaults" option. Hope it helps.
Hello! Yep, now i have MSO5072 with full functions! Thanks a lot!
But i have a question, from what device or file rigol read information about model, serial,firmware,hardware... When we press "About" botton?
And else... How i can enable ssh permanently ? I need rewrite ssh and sshd config or \ and /etc/init.d script's?
Okay so I'm pretty new to the MSO5000 club, but I think it was a pretty good purchase. I do embedded firmware for off-highway vehicles professionally. I really would like to expand the CAN decode/trigger to the search function. An alternative goal would be to store things in the same file format (.arb/.ref/.bin etc) that it reads or have a converter on the scope. Has anybody made any serious effort for tweaking the firmware? I noticed that there was a repo on gitlab that had the appEntry file. https://gitlab.com/riglol/rigolee/firmware/-/tree/MSO5000/firmware/rootfs/rigol?ref_type=heads (https://gitlab.com/riglol/rigolee/firmware/-/tree/MSO5000/firmware/rootfs/rigol?ref_type=heads)
I popped it open in Ghidra, but before I go down the rabbit hole of teaching myself Ghidra/RE, does anybody know of an active project to reverse the source code for this?
I already have tools for analyzing CAN messages. However, there is a real benefit to having the device input signals, CAN bus analog signal shape and CAN messages all on the same device. Synchronizing the inputs/outputs and messages takes time and slows down the process. Also, 12V logic analyzers are rarer and more expensive so I need the scope for I/O even if I had a logic analyzer for the CAN bus. Basically, the scope is sometimes the best tool for the job. I'm not trying to find a new tool. I just want to improve the tool that I'm using. I want to see every trigger condition that is present in the buffer.It's unclear what you want to do. Is the CAN Decode event table not good enough? You can also export this to .csv file then import into a spreadsheet for more detailed analysis on a computer. What about the waveform recording? This can record many separately triggered waveforms ("frames") into the memory buffer, and you can then go back and view each frame, I assume with decoding if desired. The manual describes waveform recording as capturing on an interval, but you need to interpret that as re-arming the trigger on that interval. Then, when the trigger fires (which could be some condition on the CAN bus), a waveform/frame is recorded. The trigger is re-armed after the delay which can be set as low as 10 ns (effectively nil for CAN).
Is it practical to add this function to the scope, maybe not. Either way I'll learn something.
For anyone looking for the instructions/correct patch in this giant thread like I was, here is the patch for FW 01.03.02.02, taken from stmcore's post:
Thanks so much to everyone who worked on this!!! So happy to get my MSO5074 unlocked, AWESOME!
For anyone looking for the instructions/correct patch in this giant thread like I was, here is the patch for FW 01.03.02.02, taken from stmcore's post:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4685945/#msg4685945 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4685945/#msg4685945)
Instructions I followed:
-Freshly formatted 16GB Nextech USB to FAT32
-Unzipped "01.03.02.02_patch.zip" onto USB (loose files into root directory)
-put USB in scope, do local upgrade (Utility->System->Help->Local Upgrade)
-press keys when prompted on scope
-don't panic when screen goes black for a minute
-re-calibrate unit (Utility->System->SelfCal)
-reboot and enjoy all the sweet sweet bandwidth!
No, the CAN Decode table is insufficient for two reasons. 1) The CAN decode doesn't work if you zoom out very far even though the sample rate is adequate or even the waveform is saved in memory 2) The event table shows all events, not just certain events.I already have tools for analyzing CAN messages. However, there is a real benefit to having the device input signals, CAN bus analog signal shape and CAN messages all on the same device. Synchronizing the inputs/outputs and messages takes time and slows down the process. Also, 12V logic analyzers are rarer and more expensive so I need the scope for I/O even if I had a logic analyzer for the CAN bus. Basically, the scope is sometimes the best tool for the job. I'm not trying to find a new tool. I just want to improve the tool that I'm using. I want to see every trigger condition that is present in the buffer.It's unclear what you want to do. Is the CAN Decode event table not good enough? You can also export this to .csv file then import into a spreadsheet for more detailed analysis on a computer. What about the waveform recording? This can record many separately triggered waveforms ("frames") into the memory buffer, and you can then go back and view each frame, I assume with decoding if desired. The manual describes waveform recording as capturing on an interval, but you need to interpret that as re-arming the trigger on that interval. Then, when the trigger fires (which could be some condition on the CAN bus), a waveform/frame is recorded. The trigger is re-armed after the delay which can be set as low as 10 ns (effectively nil for CAN).
Is it practical to add this function to the scope, maybe not. Either way I'll learn something.
Hello, has anyone managed to make these changes as well? Did you manage to work with Fram? If someone has repeated this feat, can you write or direct me? I'll be with the device soon and want to give it a try.How does one enable this mystical 500MHz mode?
I won't go into details because the benefits are residual compared to the possible headaches when executing the procedure wrongly. I leave that as homework for the ones who are not faint of heart.
But, as general knowledge, I'll add the following:
These equipments keep their config in a FRAM memory. In that FRAM, among other possible things, usually there are the following params (specific to the unit):
- E_CFG_MODEL_RAW
- E_CFG_SN_RAW
- E_CFG_MAC
- ECC Public key of the scope
- Option's licenses
These fields are replicated in the sysvendor.bin, Key.data and the *.LIC files (for "external" consumption).
So, to change the Model, you just have to change the contents of the param E_CFG_MODEL_RAW, in the FRAM, and the scope will adjust everything else accordingly.
Thanks so much to everyone who worked on this!!! So happy to get my MSO5074 unlocked, AWESOME!
For anyone looking for the instructions/correct patch in this giant thread like I was, here is the patch for FW 01.03.02.02, taken from stmcore's post:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4685945/#msg4685945 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4685945/#msg4685945)
Instructions I followed:
-Freshly formatted 16GB Nextech USB to FAT32
-Unzipped "01.03.02.02_patch.zip" onto USB (loose files into root directory)
-put USB in scope, do local upgrade (Utility->System->Help->Local Upgrade)
-press keys when prompted on scope
-don't panic when screen goes black for a minute
-re-calibrate unit (Utility->System->SelfCal)
-reboot and enjoy all the sweet sweet bandwidth!
Everything was fine here too.
I will use my previous upgrade post, updated for v00.01.03.00.03 -> v00.01.03.03.00.
Steps I've followed :
Thanks everybody !
Everything was fine here too.
I will use my previous upgrade post, updated for v00.01.03.00.03 -> v00.01.03.03.00.
Steps I've followed :
1. Backup everything just in case (optional but recommended)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2757356/#msg2757356 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2757356/#msg2757356)
- get and unzip the first script file, put DS5000Update.GEL on USB stick, then Utility/Help/Local upgrade
- wait until 100%, then turn off/on
- repeat for the second script
2. Install the official firmware v00.01.03.03.00; I have used the above link from rigol.eu
- get the official firmware and unzip
- same steps like above, with the firmware file of course
3. Hack
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4821650/#msg4821650 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4821650/#msg4821650)
- get and unzip the file 01_03_03_00.zip and put the three files on USB stick
- same steps like above
- there will be some messages on the screen. You will be asked to press a key, two times. At the end the oscilloscope will reboot, just wait.
- all the options will be activated
4. Calibration - very important
- remove the input probes
- Utility/System/SelfCal
- then turn off/on
Thanks everybody !
I have 2 questions:
1. Where could I find procedure to recover from this backup :-//?
Which scenarios could require this?
2. How could I recover firmware to original in case when I need to send oscilloscope to service :-BROKE?
3. What about my original additional license? Could I use it after recovering to original firmware?
Thanks :-)
M.S.
Anybody have any issues with their "Scale" encoder jumping/glitching around?I think I've read about issues with the quality of the encoders. So I would rather consider it as an hardware issue of the encoders. If you ask about software de-bouncing in the firmware, you could just give a later version a try.
I have one of the earlier 5074s... Just started getting very "touchy" lately when scaling-up or down... Just wondering if the newer firmware did a better job of de-bouncing the encoder output?
BB
The encoders are no good.I change both on 1054 and 5104 and is far better the response.The stock pots is smd i by 24 clicks through hole encoders cut and bend carefully the legs and solder on place.Two years now run the scopes flawlessly.
I'm doing so, but using fram tool.
I cannot find how to write to FRAM via SCPI. Could you help?I'm doing so, but using fram tool.
Definitely not so elegant or failure proof.
I cannot find how to write to FRAM via SCPI. Could you help?
I was able to reverse-engineer and understand how the license keys check works.
I'm glad to present this Fully automatic license activator.
So, this is it! I was able to reverse-engineer and understand how the license keys check works. And I'm glad to present this Fully automatic license activator.
Use it carefully. Trying to switch off your device during activation may brick it.
Usage:
python rigol_kg.py 192.168.1.1
Is it just my problem or is anyone else unable to download this script? It gives me a 404 error.
Hoban new and I am looking to buy the Rigol, I was wondering if this code still works? I am looking into buy a Rigol 5074, and upgrade it to 5354. does it also have the software for debugging RS232, SPI, and other protocols switched free?
Are there more hidden functions?
So, this is it! I was able to reverse-engineer and understand how the license keys check works. And I'm glad to present this Fully automatic license activator.
Use it carefully. Trying to switch off your device during activation may brick it.
Usage:
python rigol_kg.py 192.168.1.1
So, this is it! I was able to reverse-engineer and understand how the license keys check works. And I'm glad to present this Fully automatic license activator.
Use it carefully. Trying to switch off your device during activation may brick it.
Usage:
python rigol_kg.py 192.168.1.1
Hello, how to use/run?
or not work for me?
Thanks
I'll check it on 5072 later, and will update the script if required.Also for 5074 does not work. It does not activate BW and Deep memory. Tried with the scope unlocked and also with original fw (locked). Also after procedure the scope sometimes does not boot, need to recover with "Single" key method.
I guess the keygen way of inserting the info into the FRAM is bad. I have suggested doing it with official SCPI way.
@DrMefistO probably is looking into it...
Anybody have any issues with their "Scale" encoder jumping/glitching around?
I have one of the earlier 5074s... Just started getting very "touchy" lately when scaling-up or down... Just wondering if the newer firmware did a better job of de-bouncing the encoder output?
BB
With this Rotary Encoder EN12HS1L code I did not find the datasheet.
With this Rotary Encoder EN12HS1L code I did not find the datasheet.
https://www.ttelectronics.com/TTElectronics/media/ProductFiles/Datasheet/EN12.pdf (https://www.ttelectronics.com/TTElectronics/media/ProductFiles/Datasheet/EN12.pdf)
Hi guys,
could anybody help me out on finding an encoder replacement part for my MSO5000?
I have a defective dented encoder which is annoying me so much |O
Many thanks! I have replaced the encoders on dz1054 and mso5104 with through hole pots from BI part numb.EN12HS1L. I just cut carefully the legs and solder on the pads.Both scops working as it should"t last two years.
It is 24 klicks pots and works perfect in booth scops 5104 and 1054 on my DHO804 don't need to replace nothing.I try to upload photo from the encoder.With this Rotary Encoder EN12HS1L code I did not find the datasheet.
https://www.ttelectronics.com/TTElectronics/media/ProductFiles/Datasheet/EN12.pdf (https://www.ttelectronics.com/TTElectronics/media/ProductFiles/Datasheet/EN12.pdf)
Okay so I'm pretty new to the MSO5000 club, but I think it was a pretty good purchase. I do embedded firmware for off-highway vehicles professionally. I really would like to expand the CAN decode/trigger to the search function. An alternative goal would be to store things in the same file format (.arb/.ref/.bin etc) that it reads or have a converter on the scope. Has anybody made any serious effort for tweaking the firmware? I noticed that there was a repo on gitlab that had the appEntry file. https://gitlab.com/riglol/rigolee/firmware/-/tree/MSO5000/firmware/rootfs/rigol?ref_type=heads (https://gitlab.com/riglol/rigolee/firmware/-/tree/MSO5000/firmware/rootfs/rigol?ref_type=heads)You'd have to 'patch' the firmware with your features, Would be a big pain, but sure, possible yes.
I popped it open in Ghidra, but before I go down the rabbit hole of teaching myself Ghidra/RE, does anybody know of an active project to reverse the source code for this?
So, this is it! I was able to reverse-engineer and understand how the license keys check works. And I'm glad to present this Fully automatic license activator.Amazing!! very cool,
Use it carefully. Trying to switch off your device during activation may brick it.
Usage:
python rigol_kg.py 192.168.1.1
I guess the keygen way of inserting the info into the FRAM is bad. I have suggested doing it with official SCPI way.can't wait for V2 which uses scpi commands instead :)
@DrMefistO probably is looking into it...
For a more high quality fan replacement, you can use the Noctua NF-A8 FLX, 80mm fan. It is dead silent and has a six year warranty.
https://noctua.at/en/products/fan/nf-a8-flx
When updating completed I reboot my MSO5000, and it "not working". The progressbar changing from 0 to 100% and nothing is changed. What I need to do, please help.
In a rare case when scope does not boot, press "Single" key at the very beggining of the boot phase and press "Restore defaults" or "Upgrade firmware" to re-apply the original Fw.A lot of time has passed.
That is very unlikely ...
Have tried pressing single button at boot without effort...
Yeah, You are right, thanks. I started pressing it before the power button repeatedly. Now it is upgraded at least... but with all options gone...
I have the 01_03_00_03.bspatch, it's 2 years old. Will navigate through the forum to see if there are any news relative to this patch.
Thank You
Does anyone know what these fields are?
Can anyone post their sysvendor.bin file for statistics?
Hi,
As I saw during RE, firmware only uses FRAM to load a key, and doesn't use sysvendor.bin, as before. Or I haven't found that. By the way, I tried to patch sysvendor.bin previously, but the oscillo doesn't load it from there.
SCPI commands don't allow to change FRAM, I haven't found any available command for that.
00000000 BLOCK0 CRC32
00000004 BLOCK0 size
00000008 BLOCK0 data (0084 - 132 bytes) Practically all zeros (0x13 - maybe "Boot times")
00000100 BLOCK1 size + checksum option: checksum: datasize: checksum: CRC32: data:
00000108 Key.dat A0 11 00 00 | 60 EE FF FF | 94 00 00 00 | 6C FF FF FF | 1F 37 29 92 | Key.dat
000001B0 lic_COMP + timer + fail counter 8A 11 00 00 | 76 EE FF FF | 04 00 00 00 | FC FF FF FF | C7 05 DB E7 | 4A 00 02 00
000001C8 lic_EMBD + timer + fail counter 8B 11 00 00 | 75 EE FF FF | 04 00 00 00 | FC FF FF FF | C7 05 DB E7 | 4A 00 02 00
000001E0 lic_AUTO + timer + fail counter 8C 11 00 00 | 74 EE FF FF | 04 00 00 00 | FC FF FF FF | C7 05 DB E7 | 4A 00 02 00
000001F8 lic_FLEX + timer + fail counter 8E 11 00 00 | 72 EE FF FF | 04 00 00 00 | FC FF FF FF | C7 05 DB E7 | 4A 00 02 00
00000210 lic_AUDIO + timer + fail counter 8D 11 00 00 | 73 EE FF FF | 04 00 00 00 | FC FF FF FF | C7 05 DB E7 | 4A 00 02 00
00000228 lic_AERO + timer + fail counter 90 11 00 00 | 70 EE FF FF | 04 00 00 00 | FC FF FF FF | C7 05 DB E7 | 4A 00 02 00
00000240 sysvendor.bin 40 08 00 00 | C0 F7 FF FF | 18 01 00 00 | E8 FE FF FF | 64 A2 39 9C | sysvendor.bin
00000800 BLOCK2 CRC32
00000804 BLOCK2 size
00000808 BLOCK2 data (0EC2 - 3778 bytes) License data most certainly... (if you erase the FRAM, the scope basically recreates most of this area)
Does each device have a unique key?
... The example is incomplete. There is also data after the model number, serial number and mac address
Has anyone tried to activate 500M option on our scopes?search this thread an you willl find your answer :p
'BW07T1', 'BW07T2', 'BW07T3' are activated by patch but the option 'BW07T5' is not
For the deviant ones that like to see how the little details go, here is a MSO5000 FRAM parsing (up to the best of my investigations in the good ol' days).
There is a Block1 with licensing, sysvendor file and key.dat and there is a Block2 composed of a bunch of zlib structures that store all the settings of the machine. I never pursued all the fieldnames inside this block, as most of them don't have any values.
I would be surprised if current DHO FRAM structures are much different from this one although, with Rigol in tha house, everything is possible...
This option mentioned twice without explanation on why whould it not work. There is a speculation that we have a bw limiting settings enabled in frontend ic, maybe activating BW07T5 even partially will disable this limit.Has anyone tried to activate 500M option on our scopes?search this thread an you willl find your answer :p
'BW07T1', 'BW07T2', 'BW07T3' are activated by patch but the option 'BW07T5' is not
This option mentioned twice without explanation on why whould it not work. There is a speculation that we have a bw limiting settings enabled in frontend ic, maybe activating BW07T5 even partially will disable this limit.
This option mentioned twice without explanation on why whould it not work. There is a speculation that we have a bw limiting settings enabled in frontend ic, maybe activating BW07T5 even partially will disable this limit.
Why do you make a question and then don't follow the answer to what you asked?I do follow. As you may have noticed, some time ago i made my measurements replacing low pass filter at ADC. This filter could explain your results even if you changed a model to 500M one. Don't you think it is worth to reconsider again?
I do follow. As you may have noticed, some time ago i made my measurements replacing low pass filter at ADC. This filter could explain your results even if you changed a model to 500M one. Don't you think it is worth to reconsider again?
How much BW you achieved? Remind me please.I got around 100ps of rise time reduction. You can start by looking near my post , where i made my conclusions https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg5175111/#msg5175111 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg5175111/#msg5175111) , there are also many actual BW measurements which are missing in your description for 500M model.
But as you can read in the thread, the 470-480 MHz are available to anyone despite not having the 5504 model configured, so I guess if you open the BW a little more you don't need any other software hack.
Of course you cant go to eyes&jitter world because the machine simply doesnt have the horsepower for it.
if ( flagInSSHDandTFTPD != 1 )
{
system("/usr/sbin/sshd");
system("tcpsvd 0:21 ftpd ftpd -w /&");
flagInSSHDandTFTPD = 1;
}
I found that the device has project mode with ssh and ftp daemonCode: [Select]if ( flagInSSHDandTFTPD != 1 )
{
system("/usr/sbin/sshd");
system("tcpsvd 0:21 ftpd ftpd -w /&");
flagInSSHDandTFTPD = 1;
}
All that remains is to find which button to launch it :-DD
I found that the device has project mode with ssh and ftp daemonCode: [Select]if ( flagInSSHDandTFTPD != 1 )
{
system("/usr/sbin/sshd");
system("tcpsvd 0:21 ftpd ftpd -w /&");
flagInSSHDandTFTPD = 1;
}
All that remains is to find which button to launch it :-DD
See Reply #2307
usage: rigol_kg2.py [-h] [-i] [-r] [-u] [-s] ip_addr
positional arguments:
ip_addr Rigol MSO5072/MSO5074 IP-address
options:
-h, --help show this help message and exit
-i, --info Print options status, model and serial then exit
-r, --regen Regenerate private key
-u, --uninstall Uninstall all options
-s, --ssh Activate SSH
What version of Python does this use? When I tried to run it, a window flashes up very quickly, and then disappears.
Excellent! Thanks to your short help, everything is now permanently activated. Even after a firmware update. This time it wasn't meant to be sarcastic
GOOD JOB! ;D
Traceback (most recent call last):
File "C:\Users\myuser\Downloads\rigol_kg2.py", line 431, in <module>
main()
File "C:\Users\myuser\Downloads\rigol_kg2.py", line 380, in main
model, ser = read_rigol_model_serial(args.ip_addr)
^^^^^^^^^^
TypeError: cannot unpack non-iterable NoneType object
No matter if I run the script on a Windows or Linux machine, and what options I use, I always get this:Ip addr is correct? Can you ping the device?Code: [Select]Traceback (most recent call last):
File "C:\Users\myuser\Downloads\rigol_kg2.py", line 431, in <module>
main()
File "C:\Users\myuser\Downloads\rigol_kg2.py", line 380, in main
model, ser = read_rigol_model_serial(args.ip_addr)
^^^^^^^^^^
TypeError: cannot unpack non-iterable NoneType object
Ip addr is correct? Can you ping the device?Yes, no problem accessing the device whatsoever.
The latest is 01.03.03.00
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4821650/#msg4821650 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4821650/#msg4821650)
This is I'm using now.
EDIT : Actually, i just remembered, This forum doesn't Auto update me when a new post is created .
Hi guys, I upgraded my oscilloscope perfectly well and smooth. I made a guide to help all the users to get through the upgrade process.
I hope you can find it useful and of course, any suggestion to improve the guide will be very welcome.
https://www.mediafire.com/folder/zh1uiu3umgoai/Documents (https://www.mediafire.com/folder/zh1uiu3umgoai/Documents)
I uploaded to mediafire because I can't share them here. The firmware.rar files contains all the files needed to work with the guide. The Word file is the guide with images.
Thanks a lot!!!!
My MSO5074 firmware is 00.01.03.02.02Hi Irishman
Please confirm if 01.03.03.00 Is the correct patch.
I'm new at this and I just got my scope and I don't want tp brick it.
Thanks for any help!!
A few weeks ago, I could hardly spell oscilloscope. I just unpacked my new MSO5074 and applied the patches. Thanks to all the excellent posts, all went very well and I was able to apply the patches, calibrations, etc. without any issues.
I'm 80 years old, and this was far easier than I had anticipated. The most challenging step was getting the SSH to unmount the flash drive. Everything else was quite straightforward. My next step is connecting the probes and start learning how to run this FB instrument. Now I can finally fix my HF linear!
In advance, also many thanks for the great tutorials available on this forum!
You guys are the greatest!!!! :clap:
It was easier to update with the original firmware from the Rigol website and then apply the patch ?
Hello, my scope has Firmware 01.03.02.02, Hardware 01.01.000. What .GEL files should I use for the hack to 01.03.03.00?You take it INCORRECTLY
I take it I can't use the .GEL files that upgrade 01.03.00.03 to 01.03.03.00?
Many thanks for your help!
In the end I just decided to try the upgrade/hack.
I've now successfully gone from Firmware 01.03.02.02 to Firmware 01.03.03.00 using the .GEL files available via: https://mega.nz/folder/OsJyFY5A#8uS0fmepgBdNrXqvnxmFfg
Simply ignore the warnings about the upgrade/hack not working on anything other than 01.03.00.03 and just follow the three steps.
I also tried using the files 01.03.02.02_patch.zip before attempting Step 2 (thinking that was necessary for FW01.03.02.02), but the scope didn't seem to like that one (but it didn't do any harm either, it just threw an error and re-started).
Anyway, I've got myself a nice 4-channel scope, so I'm extremely happy.
Thank you very much to all those who have made this possible :)
It was easier to update with the original firmware from the Rigol website and then apply the patch ?You're absolutely correct, But in saying that, to this day i've helped over 120 people upgrade the MSO5000 and i think around 200 or so when the DS2000A came out.
I have a 5072 with old firmware 00.01.01.04.08 [Hardware 01.00.000]. Yes it has everything upgraded so its really a 5074. I'm wondering since it seems I'm old, if I should not just DL from Rigol, and update to 00.01.03.00.03 then patch / update from there...
Ok,I Understand
I have a 5072 with old firmware 00.01.01.04.08 [Hardware 01.00.000]. Yes it has everything upgraded so its really a 5074. I'm wondering since it seems I'm old, if I should not just DL from Rigol, and update to 00.01.03.00.03 then patch / update from there...
Anyone with experience have a opinion?
-Stan
There's absolutely no problem for them to upgrade, I've done this over 100 times (Helped people to upgrade, Not upgraded 100 times myself)I have a 5072 with old firmware 00.01.01.04.08 [Hardware 01.00.000]. Yes it has everything upgraded so its really a 5074. I'm wondering since it seems I'm old, if I should not just DL from Rigol, and update to 00.01.03.00.03 then patch / update from there...
I don't know, if I'm above your experience threshold for that specific topic, but here is my opinion: The approach should work and if the upgrades in the 00.01.03.00.03 firmware are beneficial enough, it is probably worth the effort. If you don't see benefits in the upgrade for you, I would leave it in the actual state.
Ok,
I have a 5072 with old firmware 00.01.01.04.08 [Hardware 01.00.000]. Yes it has everything upgraded so its really a 5074. I'm wondering since it seems I'm old, if I should not just DL from Rigol, and update to 00.01.03.00.03 then patch / update from there...
Anyone with experience have a opinion?
-Stan
Just an update....THAT'S AWESOME, Well done
Went ahead and followed the process... No issues. Fully upgraded and working at v00.01.03.03.00. Thanks for the advise.
-Stan
and i'm wondering what this is
v00.01.03.03.00 2023/02/22
- Patch for MSO5000 series NAND flash
Possibly, I didn't think of that.Quoteand i'm wondering what this is
v00.01.03.03.00 2023/02/22
- Patch for MSO5000 series NAND flash
My guess is they had to replace the NAND chip for another part and updated the code to deal with the new chip.
Why not put the videos on YouTube so it can have a wider audience.Hmmm.... You tube huh ?
Ok,
I have a 5072 with old firmware 00.01.01.04.08 [Hardware 01.00.000]. Yes it has everything upgraded so its really a 5074. I'm wondering since it seems I'm old, if I should not just DL from Rigol, and update to 00.01.03.00.03 then patch / update from there...
Anyone with experience have a opinion?
-Stan
In light of your question , i approached rigol with a few questions of my own.
The first being that there are bad spelling errors in the INDEX menu of the scope (things like MARK TABEL that should have been MARK TABLE)
and in the SELF CHECK menu errros like SIGNLE when it should have been SINGLE) Anyway, that's all put forward to them and hopefull Next firmware update that'll be fixed.
Now regarding the updates,
The release notes are here
https://www.rigolna.com/firmware/ (https://www.rigolna.com/firmware/)
However the Release notes for the MS05000 are complete garble, they are using a different encoding,
they are now aware of this and they will (i imagine in the next day or 2) resolve this issue
I have attached a copy of the release notes that i was provided, in a readable format
but
HERE ARE THE RELEASE NOTES
【Supported Product Models】All models in the MSO5000 series oscilloscopes
【Latest Revision Date】2023/02/22
【Updates】
v00.01.03.03.00 2023/02/22
- Patch for MSO5000 series NAND flash
- Added query instructions for gain and offset settings in function operator AX+B
- Vertical minimum range restored to 500 microvolts
v00.01.03.02.02 2023/01/04
- Added shortcut keys and VNC remote function
- Optimized waveform, cursor movement, gesture operation vertical and horizontal range switching speed
- Cursor optimization: optimized cursor jump situation, ZOOM region and main time base cursor linkage, etc.
- CH4 waveform color modification, waveform brightness enhancement
- ZOOM mode optimization: mask color adjustment, switching speed, region movement optimization
- SCPI command response speed optimization: reset, measurement, waveform read command response optimization
v00.01.03.00.03 2021/10/18
- Optimized waveform display in XY mode
- Optimized DC gain calibration algorithm
- Parallel decoding of LA channels, resolved decoding error issue with negative polarity
v00.01.03.00.01 2020/03/27
- Fixed waveform recording function error when horizontal time base is 10ns/div
- Optimized AUTO function after analog channel zeroing
- Supported dragging MATH waveform icon to move MATH waveform
v00.01.02.00.03 2020/02/27
- Fixed error in reading LA channel memory data with SCPI command
v00.01.02.00.02 2020/02/25
- Optimized startup issue when connecting HDMI
- Optimized vertical range adjustment, channel zeroing error
- Optimized inconsistency in SPI CLK and SDA names
- Optimized square wave display under 2s time base
- Added command to obtain pass/fail count
- Removed default email account and password
- Optimized some issues in remote commands
- Optimized excessive decoding event crash issue
v00.01.01.04.08 2019/08/02
- Fixed crash issue when clicking restore default options
- Fixed inability to activate 4CH option in version 4.4 and later of version 2.3
- Fixed interference signal captured on oscilloscope screen when clicking About Oscilloscope
- Fixed slow refresh of measurement data under large time base
- Fixed lack of update in precise measurement in ROLL mode
v00.01.01.04.04 2019/02/20
- Optimized local firmware version upgrade method.
- Added 12-bit high-resolution mode.
- Extended minimum vertical range to 500uV/div.
- Added SCPI command: MEASure:STATistic:ITEM CNT,<item>[,<src>[,<src>]], used for reading
measurement statistic counts.
- Drawing a rectangle with the touchscreen can zoom in or out the waveform: drawing a rectangle from top left to bottom right enlarges the screen waveform; drawing a rectangle from bottom right to top left reduces the screen waveform.
- Added GND coupling to channel coupling.
- Expanded selectable colors for LA channel waveforms.
- When a new firmware version is detected, a red dot will appear on the online upgrade and other menus as a reminder.
- Fixed waveform not refreshing issue in slow scan mode.
- Optimized startup time to within one minute.
- Optimized responsiveness of touchscreen bottom.
- Reduced waveform baseline noise.
- Fixed decoding error caused by moving waveform.
- Fixed LA channel waveform extension error after sampling stops.
- Fixed issue with SYSTEM:SETUP command not saving and loading settings.
NOW THE QUESTION I HAVE IS.............
If you upgrade straight from 1.1.4.4 to 1.3.3.0 Do you miss the updates of everything that happened in between.
I am awaiting and answer from Rigol on this.
Because certain things like this...
v00.01.01.04.08 2019/08/02
- Fixed crash issue when clicking restore default options
Seem important
and i'm wondering what this is
v00.01.03.03.00 2023/02/22
- Patch for MSO5000 series NAND flash
so yeah, i have some pending answers that i want rigol to answer. I'll keep you posted
If these updates are implemented it will be a decent upgrade to the scope we have now. Very good work man. \m/No Kidding huh ! LOL
Tbh I agree , that's why I was asking if we need the patch again. Frankly , why need the patch since everything is already unlocked a firmware update shouldn't bother with licences and stuff.well there exists only one question in my mind.
So let's wait and see
I don't understand what you've been trying to accomplish in the last few messages but to get things straight:
1. Member DrMefistO has published a license generator that can "correctly" license the MSO5000, as long as the FRAM doesn't get corrupted by his key FRAM insertion technique. When it runs OK, this way is future proof.
2. All other app patching techniques don't license the scope eternally. They require continuous patching of FW versions as long as new FW versions come out.
Sometime ago I defied DrMefistO to correctly complete his procedure by searching the SCPI command that allows the correct insertion of the Key.data info the FRAM. If anyone wants to join that quest...
BTW, the DS2000A can also be licensed directly in the latest FW version. But the method is also another one that is not public.
so... Are you saying that if we use his procedure, then....
When future updates come out , we won't have to worry about patching,we'll just update with the upgrade file and all the options will
still be there, but.. if we use the patch then we have to repatch each time
and if that's thecase, and we have already applied the patch and have the updates.
then, How do we apply his technique if we have already patched it ?
How do we apply his technique if we have already patched it ?
I was summarizing the state of the art regarding licensing the MSO5000. My comment about "last posts" was focused on your considerations about the patching techniques being employed, nothing about you trying to summarize things for other people.
BTW, my post was not worthy of a 2-pages response, and specially the unpleasant comments. :palm:so... Are you saying that if we use his procedure, then....
When future updates come out , we won't have to worry about patching,we'll just update with the upgrade file and all the options will
still be there, but.. if we use the patch then we have to repatch each time
and if that's thecase, and we have already applied the patch and have the updates.
then, How do we apply his technique if we have already patched it ?
Yes. I was saying exactly that in a summarized way.
It was because I suspected that you hadn't understood that feature, that I decide to write it in a very simple way and not a convoluted way!
I didn't criticize your will to help others. I simply called your attention to the fact that there is a more modern way (available in this thread) to "correctly" license the scope without future patchings!
What you are doing is not called "licensing". It's called "bypassing the licensing"!How do we apply his technique if we have already patched it ?
You should have been able to answer this yourself: just flash the latest stock FW and follow his procedure which, BTW, doesn't require the electron collider that you talk about. Study his posts more carefully.
I was summarizing the state of the art regarding licensing the MSO5000. My comment about "last posts" was focused on your considerations about the patching techniques being employed, nothing about you trying to summarize things for other people.
BTW, my post was not worthy of a 2-pages response, and specially the unpleasant comments. :palm:so... Are you saying that if we use his procedure, then....
When future updates come out , we won't have to worry about patching,we'll just update with the upgrade file and all the options will
still be there, but.. if we use the patch then we have to repatch each time
and if that's thecase, and we have already applied the patch and have the updates.
then, How do we apply his technique if we have already patched it ?
Yes. I was saying exactly that in a summarized way.
It was because I suspected that you hadn't understood that feature, that I decide to write it in a very simple way and not a convoluted way!
I didn't criticize your will to help others. I simply called your attention to the fact that there is a more modern way (available in this thread) to "correctly" license the scope without future patchings!
What you are doing is not called "licensing". It's called "bypassing the licensing"!How do we apply his technique if we have already patched it ?
You should have been able to answer this yourself: just flash the latest stock FW and follow his procedure which, BTW, doesn't require the electron collider that you talk about. Study his posts more carefully.
Now, after my previous wall of text, i'm a bit tired.. I'm gonna make a coffee while you read all that ;DWise guy aren't you.
NOW IS THAT FAIR ENOUGH OR WHAT ?
Now, after my previous wall of text, i'm a bit tired.. I'm gonna make a coffee while you read all that ;DWise guy aren't you.
Daring to question the EEVblog hacking God tv84 ! :horse:
NOW IS THAT FAIR ENOUGH OR WHAT ?
Sorry to have wasted your time (and keyboard).
OAO
Hiis that the digitizer that you broke ?
I was disappointed with the display quality.I broke touch screen, by accident.
I remove it, and connected usb mouse.Logitech m310.
For picture quality, rate yourself.
BR
So to be clear
1. You're not even going to address anything
2. You're not even going to answer the questions that were asked
3. Nor consider what i asked you to consider
No ???
So to be clear
1. You're not even going to address anything
2. You're not even going to answer the questions that were asked
3. Nor consider what i asked you to consider
No ???
I'm not sure why you are stirring the pot.
tv84 clearly communicated the two licensing hack options to clear up some misinformation in your earlier posts.
You replied with a lot of long-winded nonsense that I doubt many will read in full (I didn't).
So to be clear
1. You're not even going to address anything
2. You're not even going to answer the questions that were asked
3. Nor consider what i asked you to consider
No ???
I'm not sure why you are stirring the pot.
tv84 clearly communicated the two licensing hack options to clear up some misinformation in your earlier posts.
You replied with a lot of long-winded nonsense that I doubt many will read in full (I didn't).
so... Do you have like a PTSD thing where things need to be kept brief ? Because call me crazy, but i'm sensing a theme here.
so... Do you have like a PTSD thing where things need to be kept brief ? Because call me crazy, but i'm sensing a theme here.
I’m not the guy to report any posts. But can we please just keep comments like this out of this forum... you know... please!
Also.... Quick question (and i'm not starting shit, i'm just asking a question)
You haven't been involved in this, so .. why have you jumped in all of a sudden ?
What's your motivation to be here... I'm just curious
YOU RESPONDED in a completely useless manner
Also.... Quick question (and i'm not starting shit, i'm just asking a question)
You haven't been involved in this, so .. why have you jumped in all of a sudden ?
What's your motivation to be here... I'm just curious
Huh? You are posting in a public forum with hundred if not thousands of people likely to read this. My motivation was to hopefully make you aware that you were being disrespectful.
You keep on going on about respecting each other, but I didn't spot any significant disrespect from tv84. I see repeated and clear disrespect in your postings with things likeQuoteYOU RESPONDED in a completely useless manner
I can respect your efforts in helping the community and the videos that you produced. I don't have to respect your rants.
But I will stop there, as I do want us to all get back on track. I'll wade through you prior posts and if I can answer on-topic questions I may reply further.
OK BTO, I went back and read through your last handful of posts and I didn't spot any clearly formulated on-topic questions. Maybe I missed them.already have, Read my latest post before this one
While I am not at the skill level of tv84, I am honestly happy to help clear up any technical points that I do understand.
So feel free to re-ask them ... but maybe without the excessive off-topic text... ;D
TV84 was saying that the way i was upgrading was not actually licencing the scope but instead bypassing licencing.
My point to that was, .. since the scope said licenced, obviously i drew the conclusion (as anyone would that it was) I just asked for clarification on that
He then suggested that there was a method by another member (Can't remember his name off hand) that does permanently licence the scope.
Question 2 was...
I have a JTAGulator and Arduino boards, the question was... Can i use my JTAGULATOR board to execute the process required
and lastly... My scope is currently unlocked (via patch) on version 1.3.3.0
now. if i wanted to do this process , Given that my scope is currently unlocked and up to current version, is it possible for me to do that
and if so , How (Briefly stated)
those were really the only 3 points i needed addressed
already have, Read my latest post before this one
TV84 was saying that the way i was upgrading was not actually licencing the scope but instead bypassing licencing.
My point to that was, .. since the scope said licenced, obviously i drew the conclusion (as anyone would that it was) I just asked for clarification on that
He then suggested that there was a method by another member (Can't remember his name off hand) that does permanently licence the scope.
Question 2 was...
I have a JTAGulator and Arduino boards, the question was... Can i use my JTAGULATOR board to execute the process required
and lastly... My scope is currently unlocked (via patch) on version 1.3.3.0
now. if i wanted to do this process , Given that my scope is currently unlocked and up to current version, is it possible for me to do that
and if so , How (Briefly stated)
those were really the only 3 points i needed addressed
OK, I think I can answer those in one hit as they are all related.
The "firmware hack" method of licensing the scope as mostly discussed here, and what I believe you include in your notes and videos modifies the firmware to just bypass certain license code checking and thus enables all licenses. This means that is it not permanent in the sense that it only applies to the hacked firmware. If new firmware is flashed via a restore or upgrade then the hack is lost and only saved & valid license keys are active.
The "FRAM hack" script by DrMefistO uses an extracted signing key (I think, may have the exact details wrong) to generate valid option keys for your MSO5000 serial number and saves them to the scope via direct FRAM access over a scripted SSH connection and also some SCPI commands.
This script is in post 2739 at https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg5372468/#msg5372468 (https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg5372468/#msg5372468) (and possibly earlier posts)
The comment by tv84 was that it does this in a potentially unsafe way (direct FRAM access) and there is most likely some undocumented SCPI commands to do it more safely.
No need to play around with a JTAGULATOR or Arduino stuff, but if you are at all familiar with Python code then the script is in the above linked post and you are welcome to dive into how it works.
To wrap up, if you reflash or upgrade to stock firmware you will lose your current hack and have only the licensed original options. You can then try the process by DrMefistO (if you dare) and potentially get permanent keys installed for all options that should continue through future firmware upgrades. Please report back if you do this and success or fail.already have, Read my latest post before this one
Yeah, you don't really need to respond to every post...
OK You seem to be an I.T. Guy, as am i, so its safe to say we both understand how firmware works when a new version is applied.
Also i was asking tV84 , since it's a somewhat unsafe method, what was the success rate on it, approx.
if i try this process and it doesn't work, am i still able to revert to the upgrade and patch method if it doesn't work ?
Will the new firmware go through licence checking when installed ?
OK You seem to be an I.T. Guy, as am i, so its safe to say we both understand how firmware works when a new version is applied.
Yes, I'm an IT/embedded systems guy. I spend about 50% of my time with hands-on electronics, and 50% on firmware or IT (coding/support/architecture/etc).Also i was asking tV84 , since it's a somewhat unsafe method, what was the success rate on it, approx.
Not sure if that is known. At least one person seems to have used it with success if you read the posts following #2739 (user zauberpilz had problems at first in #2742 & 2744, then reported success in #2746)if i try this process and it doesn't work, am i still able to revert to the upgrade and patch method if it doesn't work ?
No idea, which is why I included some disclaimers. I wasn't involved in the development of these, and I've only used the simple firmware hack on mine.
If I ever decide to try it, I would start by reading through the Python code to try my best to understand what it was doing. I've only scanned the code quickly so far to get a high level overview.
I would also use an SSH session to the scope and make a backup of the FRAM via dd command to a USB drive. I guess this could be done via direct hardware access to the FRAM chip, but that seems like it could cause more trouble. There is already a pseudo device available in Linux to access the FRAM.
shall we calm down, don't try to police stuff yourselves because I am not going back pages and pages through what was said.
I used the python way first and it just deleted my pischased add-ons and left the scope as it was originally. The "upgrades" way worked fine but I did dd my scope just to be safe,so I guess I can revert to previous state if something happens. If BTOs way is bypassing licencing then I guess the new firmware will.mwss up the licencing, since I haven't been involved in the process building I can't be sure though.
Will the new firmware go through licence checking when installed ?
Will the new firmware go through licence checking when installed ?The chance of a new firmware release is very low, but its good to know if one is released, not to rush out and install it since you'll lose all your options.
I think we ended up in this patch method of hacking the scope because there was a rush to unlock the scope and that was the first method that worked. I assume that there may be license key hacks out there which have not been released, not sure why the secrecy but we need a permanent fix so that persons do not have to wait on someone to create a new patch each time a new firmware is released.
As it relates to Rigol and firmware, they are very slow with that so I would not expect anything soon. I had an experience with support in the past where I complained about the X-Y feature which had a major flaw, and they offered me a firmware that fixed the issue. I thought a new firmware would soon be announced with the fix but it took 9 months before they released the fix, I had to create my own patch since the firmware I had was not released. You can asked them if they have any unreleased firmware which they can give customers.
I think we ended up in this patch method of hacking the scope because there was a rush to unlock the scope and that was the first method that worked.hmm i see
but we need a permanent fix so that persons do not have to wait on someone to create a new patch each time a new firmware is released.This is true, it does seem to be the case that the SSH method is the way to go, IT JUST DOESN'T SEEM TO BE HIGHLY RELIABLE. (at least going off what forum members are saying and how many DISCLAIMERS LOL we seem to be getting from it .
As it relates to Rigol and firmware, they are very slow with that so I would not expect anything soon.
You can asked them if they have any unreleased firmware which they can give customers.i could, but i think i'll let them get it out in their own time and properly test it
There's also stupid crap in the menu like....
it'll say, THIS OPTION ONLY AVAILABLE IN MSO7000 :-DD
Well then... Why did you put that in a MSO5000 scope. Kinda dumb isn't it ?
There's also stupid crap in the menu like....
it'll say, THIS OPTION ONLY AVAILABLE IN MSO7000 :-DD
Well then... Why did you put that in a MSO5000 scope. Kinda dumb isn't it ?
If you are talking about stuff like the Eye Diagram (that also don't work), that is because you have patched the firmware. It does not show up on unpatched firmwares. The patch just short-wires the capability check to return "I can do this" on any feature check - included the ones that are normally gated by the MSO7k/5k difference.
"If you are talking about stuff like the Eye Diagram"No i actually wasn't even remotely referring to Eye diagram.
"(that also don't work), that is because you have patched the firmware."Well, that's strange because i have patched firmware and i can use eye diagram
Try to uninstall all options first, wait for reboot, then install with regen private key flag.
Try to uninstall all options first, wait for reboot, then install with regen private key flag.
I tried as described, first uninstalled and after reboot I installed with regen private key. Tried it several times but the oscilloscope only replies with "remaining attempts" as described by zauberpilz, now only 2 attempts left. What am I doing wrong? Could you please help?
Activating: 2RL [MSO5100-2RL@100F4569E72C445C93...]... unavailable.
C:\Program Files\Python312>python C:\mPro\rigol_kg2.py 192.168.178.21
╒════════╤══════════╤═════════════════════════════════════════════════════╕
│ Code │ Status │ Description │
╞════════╪══════════╪═════════════════════════════════════════════════════╡
│ BW1T2 │ ---- │ 100MHz to 200MHz Bandwidth Upgrade Option │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ BW1T3 │ ---- │ 100MHz to 350MHz Bandwidth Upgrade Option │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ 2RL │ ---- │ 200Mpts Deep Memory Option │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ COMP │ ---- │ Computer Serial Triggering and Analysis(RS232/UART) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ EMBD │ ---- │ Embedded Serial Triggering and Analysis(IIC, SPI) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ AUTO │ ---- │ Automotive Serial Triggering and Analysis(CAN/LIN) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ FLEX │ ---- │ FlexRay Serial Triggering and Analysis │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ AUDIO │ ---- │ Audio Serial Triggering and Analysis(I2S) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ AERO │ ---- │ MIL-STD 1553 Serial Triggering and Analysis │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ DG │ ---- │ Dual Channel WaveGen 25 MHz AWG │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ PWR │ ---- │ Integrated Power Analysis │
╘════════╧══════════╧═════════════════════════════════════════════════════╛
Model: MSO5104
Serial: MS5Axxxxxxx
Version: 00.01.03.03.00
MAC: xxxxxxxxxxxx
/rigol/tools/fram is OK!
Activating: 2RL [MSO5100-2RL@3E4A0AE42A4EBA87D0D2386EA52097B212B7B4241795F2E5FAE1B334D71125ED8483193F74962BF5239CB535F4A0E8C52B10CB8D78E3DE0DDB4829E00BE3E5FB]... unavailable.
Activating: 4CH [MSO5100-4CH@465DEAE53206FBAF54DE5529965053803D26BCDCE28A4F7300F3ABB08D0ECAE05FC91B7079D36AD9BA9B75F1FE43A8F8D3E072E66BFF829FB1D3ECD80A4EDADF]... not activated.
Activating: 5RL [MSO5100-5RL@07C63D3537E61E79F37B1AF921DA1E3F702F7CFD62BD7D4DE6744126C91B3B499CCE294FF6EE91266C7AF39508C422B4547A5128771F1B3EEA676EC526BAB968]... unavailable.
Activating: AERO [MSO5100-AERO@9A5BF1A593BB6641706BF4B4FE2EACF1D674A40E9AB5A051ECABA90CBDB449B4750ACC9EF39948F82ABF09F3623E8B2F477C658409FF9BA9EED6CDA09DED5681]... not activated.
Activating: ARINC [MSO5100-ARINC@4C4625134642B3F7F6CF25A931B626127A2C4F90FBDF5C0BFE50929AED48A66418DE536513E6D118C302162CB6D9935F2E97834326D2A35DE4A501C6D6F77B56]... not activated.
Activating: AUDIO [MSO5100-AUDIO@84941C0FB778ED1E49DEDEB6845C248EE2C0A78E204C2476737313F63E2698239217282C87029FB861D4362D2CB2812D2F722F795D8C48A583CCCB92F7145083]... not activated.
Activating: AUTO [MSO5100-AUTO@40B474039C7FD62F354C1DF7485AAC4520DF35BB692736D9D9A6E17D88C8EB391422059BD47E5FBE2E54D1CFFABB44B6E8D1C75B48D3D078821F08CF20AD2A6C]... not activated.
Activating: BND [MSO5100-BND@A3E981CE398B12B619091A018179A056880A62EC0B79E51CA77A2BA1FF71FFB270C99FB9DCA45A5CB4578AB8956D3FDDC833DF299332EE4A7633EF00849D1428]... not activated.
Activating: BW07T1 [MSO5100-BW07T1@861318EBA3D06E768236C4CC79DAC8E2578500FB692CFDCF5C4B58CDD8C0D680040BFF722AB67E9AA28CB2E60BF854FB3BBF8B3C72CA9C5294A29A02D7640C66]... unavailable.
Activating: BW07T2 [MSO5100-BW07T2@67A3F6DAB880B352AAB321ED08517773A36AEB8655F96F7A89D324E240346B0297D23332D4BD529C30A8C9878460D526AC8B169CD910C6C68161400F364ABEB8]... unavailable.
Activating: BW07T3 [MSO5100-BW07T3@841055F4B6F3B08F8A1CC8DF8F103BA13AA6334577D0A72FABDB0FC4E9A1564BA7DC077A83E3A19BD48E666F9C86618AB36BD0EAEAEB73F1F7C3FDB9C34B8CE5]... unavailable.
Activating: BW07T5 [MSO5100-BW07T5@7FC62088BBAE6FB7BEF24D5F9ACDF15A993171D4BB18C869E2A83971444B7EFD2B755E1BCCF4803F6F8D32C82809B64F2BAD5BDA2A4C6AE97536E688C5AF8061]... unavailable.
Activating: BW1T2 [MSO5100-BW1T2@30C8C051F2A5C5122479DB1A9237F3FB18CE7EC9CAC0474A9F405BDA27DBC4AD324CDBB888450CAB134E49ABA1BA51ABF611A5AE6539F8F6AEB9C7475DFD4FC5]... unavailable.
Activating: BW1T3 [MSO5100-BW1T3@9B39541513B135B0E36D63C88D920A1DEB2800C63A67D2BB0C45A56837DDF71B40D270BACE358EB33BEF49D03C7A0293F881509E2369CCE9E4C5276A62D151B8]... unavailable.
Activating: BW1T5 [MSO5100-BW1T5@14A80CA48B6399A2FD0259B668962B743EE83B24C2EECA9EC23864426A514EA9A003F34E7437506D187B3B573A339A1BC3FFD15FE8C2F1CDDBC46AB774984A13]... unavailable.
Activating: BW2T3 [MSO5100-BW2T3@A163523E816C85AC70197B68FC20C7811A358ED28965D9EF286B53C3184AB9443D27C803DC4D022259F45BD0187277224292443BDAF5C9006E8683851E3BA46A]... unavailable.
Activating: BW2T5 [MSO5100-BW2T5@325FE82B891D35567A0164B596F7B84B2CED2E85D640927932140BDBA24958C32073B268EEC9449ABEFBF68A05B58C9FE9A51BCAB10E8D8E4309986D65C31CE0]... unavailable.
Activating: BW3T5 [MSO5100-BW3T5@5971AE3EF0B6EBC19B025FF2DC37A7365EA3647B33E4C38ADDEC90FA2AA6AC8A8A3B178984F93FF4C8B91479CD1006B50837B99808BC40DF532C55E96C87B8F5]... unavailable.
Activating: COMP [MSO5100-COMP@939B60C9F5D8FBAF0C680782B6DF68630F54E9ACCA3A466FD76B88244001EF3B03A0E0CE1A4A2A08D082E1647E193A0E8B4F27C600A468301578CC1B386B943B]... not activated.
Activating: CTR [MSO5100-CTR@4D6B30EA86BCA834FF0F75B5F5AF1DC6762D3B3DD8EE072B1361EDD1F337D53E7F33866FD216EC06C5E963B787912936DC1FFFE1ACECFE34BA45709E15724534]... not activated.
Activating: DG [MSO5100-DG@21147A692BFC955C514E37C4ABF2FD02FA4A73EA6AE87D9AABAD2E213D985B162B3E86A4870CB12A32235C941A034243C17E1D8B5496BD64EB0273AD32FD8CDA]... unavailable.
Activating: DVM [MSO5100-DVM@88FF659CF14AB6CC7B9585DAD2B79E2F7470770A7BF0A8D4A58DC26EDD55BBE6024A63B1EBFB28282783790779B67897A6AE55C380ED2DB264D42870F2D880A5]... not activated.
Activating: EDK [MSO5100-EDK@952C31F126219EA1391F76F60D1978EE01E863D60644A3F1158B69DEEFA7DB70A075527F54FC28227B782D196A4BA0D9FEDB95361705B54028814FB6A511ECBA]... not activated.
Activating: EMBD [MSO5100-EMBD@66C79B675A739484D2F1AE25931E57D743DB0FC6D785369129F07A47B0DF531C05BFF41E826023872F46062E5D39F7DB7564FCB062E7636ABDFDAD877FA51D67]... not activated.
Activating: FLEX [MSO5100-FLEX@A259D940749CFAE8B96DDA399D458C5AA644CC1B48BAF3A017E97E794ABB4CD34BD6F518F092C8218B249A34DF6849B2BF9350BFDAA3D131D46106A681862B3C]... not activated.
Activating: JITTER [MSO5100-JITTER@45AA3452E542DA21A3C81DB164CF35F8AB4E4E80893DCEDA674D41D1555315513BF82C21F3BBA501B3EF412AC354B87A616F9AF5C6A4E0C24D320F8A93E58EA4]... not activated.
Activating: MASK [MSO5100-MASK@390F7931353BEEABC4BF1425831F8612D86434BAF1A4E10D3DDEE918D0BD5F351F405EEF53FE29E94C8626786EE574A4FE7E59881B8BFCEBCF28B107DCFDDC22]... not activated.
Activating: MSO [MSO5100-MSO@193ED0D231141DFCB71C33A87270041321C73F0EFE0F1952ACE67C1AD73EB6332EAC4E061625B0D8F98AA55612D69133BA083BE8AED736692A896A96AB61E30B]... activated.
Activating: PWR [MSO5100-PWR@2A27DA3963D0C599C5CF9B25F819A8E90EE374C9BAE04D6316FBD56C53AAACC41E649376B6D7C5FB7A0099244929475914A9867E874E6E1EB3F381F37D8193F6]... not activated.
Activating: SENSOR [MSO5100-SENSOR@0622D1C5DF405041F4292641D9965F9CC0626EE6179150AD13A1762715462F61301B178B556C1F1A49D3755F8FB8E2DB3154AB0F14BDC510591DAB78638F0D54]... not activated.
╒════════╤══════════╤═════════════════════════════════════════════════════╕
│ Code │ Status │ Description │
╞════════╪══════════╪═════════════════════════════════════════════════════╡
│ BW1T2 │ ---- │ 100MHz to 200MHz Bandwidth Upgrade Option │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ BW1T3 │ ---- │ 100MHz to 350MHz Bandwidth Upgrade Option │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ 2RL │ ---- │ 200Mpts Deep Memory Option │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ COMP │ ---- │ Computer Serial Triggering and Analysis(RS232/UART) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ EMBD │ ---- │ Embedded Serial Triggering and Analysis(IIC, SPI) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ AUTO │ ---- │ Automotive Serial Triggering and Analysis(CAN/LIN) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ FLEX │ ---- │ FlexRay Serial Triggering and Analysis │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ AUDIO │ ---- │ Audio Serial Triggering and Analysis(I2S) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ AERO │ ---- │ MIL-STD 1553 Serial Triggering and Analysis │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ DG │ ---- │ Dual Channel WaveGen 25 MHz AWG │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ PWR │ ---- │ Integrated Power Analysis │
╘════════╧══════════╧═════════════════════════════════════════════════════╛
It shows that I have 9 remaining attempts, I can not reinstall the old keys, maybe because I have overwritten the FRAM with the option -r, which was a huge mistake.
Can someone please help me please, I'm stuck and I really do not know what to do now.
Thanks a lot, Best Regards, Seppeltronics
P.S.Code: [Select]
C:\Program Files\Python312>python C:\mPro\rigol_kg2.py 192.168.178.21
╒════════╤══════════╤═════════════════════════════════════════════════════╕
│ Code │ Status │ Description │
╞════════╪══════════╪═════════════════════════════════════════════════════╡
│ BW1T2 │ ---- │ 100MHz to 200MHz Bandwidth Upgrade Option │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ BW1T3 │ ---- │ 100MHz to 350MHz Bandwidth Upgrade Option │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ 2RL │ ---- │ 200Mpts Deep Memory Option │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ COMP │ ---- │ Computer Serial Triggering and Analysis(RS232/UART) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ EMBD │ ---- │ Embedded Serial Triggering and Analysis(IIC, SPI) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ AUTO │ ---- │ Automotive Serial Triggering and Analysis(CAN/LIN) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ FLEX │ ---- │ FlexRay Serial Triggering and Analysis │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ AUDIO │ ---- │ Audio Serial Triggering and Analysis(I2S) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ AERO │ ---- │ MIL-STD 1553 Serial Triggering and Analysis │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ DG │ ---- │ Dual Channel WaveGen 25 MHz AWG │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ PWR │ ---- │ Integrated Power Analysis │
╘════════╧══════════╧═════════════════════════════════════════════════════╛
Model: MSO5104
Serial: MS5Axxxxxxx
Version: 00.01.03.03.00
MAC: xxxxxxxxxxxx
/rigol/tools/fram is OK!
Activating: 2RL [MSO5100-2RL@3E4A0AE42A4EBA87D0D2386EA52097B212B7B4241795F2E5FAE1B334D71125ED8483193F74962BF5239CB535F4A0E8C52B10CB8D78E3DE0DDB4829E00BE3E5FB]... unavailable.
Activating: 4CH [MSO5100-4CH@465DEAE53206FBAF54DE5529965053803D26BCDCE28A4F7300F3ABB08D0ECAE05FC91B7079D36AD9BA9B75F1FE43A8F8D3E072E66BFF829FB1D3ECD80A4EDADF]... not activated.
Activating: 5RL [MSO5100-5RL@07C63D3537E61E79F37B1AF921DA1E3F702F7CFD62BD7D4DE6744126C91B3B499CCE294FF6EE91266C7AF39508C422B4547A5128771F1B3EEA676EC526BAB968]... unavailable.
Activating: AERO [MSO5100-AERO@9A5BF1A593BB6641706BF4B4FE2EACF1D674A40E9AB5A051ECABA90CBDB449B4750ACC9EF39948F82ABF09F3623E8B2F477C658409FF9BA9EED6CDA09DED5681]... not activated.
Activating: ARINC [MSO5100-ARINC@4C4625134642B3F7F6CF25A931B626127A2C4F90FBDF5C0BFE50929AED48A66418DE536513E6D118C302162CB6D9935F2E97834326D2A35DE4A501C6D6F77B56]... not activated.
Activating: AUDIO [MSO5100-AUDIO@84941C0FB778ED1E49DEDEB6845C248EE2C0A78E204C2476737313F63E2698239217282C87029FB861D4362D2CB2812D2F722F795D8C48A583CCCB92F7145083]... not activated.
Activating: AUTO [MSO5100-AUTO@40B474039C7FD62F354C1DF7485AAC4520DF35BB692736D9D9A6E17D88C8EB391422059BD47E5FBE2E54D1CFFABB44B6E8D1C75B48D3D078821F08CF20AD2A6C]... not activated.
Activating: BND [MSO5100-BND@A3E981CE398B12B619091A018179A056880A62EC0B79E51CA77A2BA1FF71FFB270C99FB9DCA45A5CB4578AB8956D3FDDC833DF299332EE4A7633EF00849D1428]... not activated.
Activating: BW07T1 [MSO5100-BW07T1@861318EBA3D06E768236C4CC79DAC8E2578500FB692CFDCF5C4B58CDD8C0D680040BFF722AB67E9AA28CB2E60BF854FB3BBF8B3C72CA9C5294A29A02D7640C66]... unavailable.
Activating: BW07T2 [MSO5100-BW07T2@67A3F6DAB880B352AAB321ED08517773A36AEB8655F96F7A89D324E240346B0297D23332D4BD529C30A8C9878460D526AC8B169CD910C6C68161400F364ABEB8]... unavailable.
Activating: BW07T3 [MSO5100-BW07T3@841055F4B6F3B08F8A1CC8DF8F103BA13AA6334577D0A72FABDB0FC4E9A1564BA7DC077A83E3A19BD48E666F9C86618AB36BD0EAEAEB73F1F7C3FDB9C34B8CE5]... unavailable.
Activating: BW07T5 [MSO5100-BW07T5@7FC62088BBAE6FB7BEF24D5F9ACDF15A993171D4BB18C869E2A83971444B7EFD2B755E1BCCF4803F6F8D32C82809B64F2BAD5BDA2A4C6AE97536E688C5AF8061]... unavailable.
Activating: BW1T2 [MSO5100-BW1T2@30C8C051F2A5C5122479DB1A9237F3FB18CE7EC9CAC0474A9F405BDA27DBC4AD324CDBB888450CAB134E49ABA1BA51ABF611A5AE6539F8F6AEB9C7475DFD4FC5]... unavailable.
Activating: BW1T3 [MSO5100-BW1T3@9B39541513B135B0E36D63C88D920A1DEB2800C63A67D2BB0C45A56837DDF71B40D270BACE358EB33BEF49D03C7A0293F881509E2369CCE9E4C5276A62D151B8]... unavailable.
Activating: BW1T5 [MSO5100-BW1T5@14A80CA48B6399A2FD0259B668962B743EE83B24C2EECA9EC23864426A514EA9A003F34E7437506D187B3B573A339A1BC3FFD15FE8C2F1CDDBC46AB774984A13]... unavailable.
Activating: BW2T3 [MSO5100-BW2T3@A163523E816C85AC70197B68FC20C7811A358ED28965D9EF286B53C3184AB9443D27C803DC4D022259F45BD0187277224292443BDAF5C9006E8683851E3BA46A]... unavailable.
Activating: BW2T5 [MSO5100-BW2T5@325FE82B891D35567A0164B596F7B84B2CED2E85D640927932140BDBA24958C32073B268EEC9449ABEFBF68A05B58C9FE9A51BCAB10E8D8E4309986D65C31CE0]... unavailable.
Activating: BW3T5 [MSO5100-BW3T5@5971AE3EF0B6EBC19B025FF2DC37A7365EA3647B33E4C38ADDEC90FA2AA6AC8A8A3B178984F93FF4C8B91479CD1006B50837B99808BC40DF532C55E96C87B8F5]... unavailable.
Activating: COMP [MSO5100-COMP@939B60C9F5D8FBAF0C680782B6DF68630F54E9ACCA3A466FD76B88244001EF3B03A0E0CE1A4A2A08D082E1647E193A0E8B4F27C600A468301578CC1B386B943B]... not activated.
Activating: CTR [MSO5100-CTR@4D6B30EA86BCA834FF0F75B5F5AF1DC6762D3B3DD8EE072B1361EDD1F337D53E7F33866FD216EC06C5E963B787912936DC1FFFE1ACECFE34BA45709E15724534]... not activated.
Activating: DG [MSO5100-DG@21147A692BFC955C514E37C4ABF2FD02FA4A73EA6AE87D9AABAD2E213D985B162B3E86A4870CB12A32235C941A034243C17E1D8B5496BD64EB0273AD32FD8CDA]... unavailable.
Activating: DVM [MSO5100-DVM@88FF659CF14AB6CC7B9585DAD2B79E2F7470770A7BF0A8D4A58DC26EDD55BBE6024A63B1EBFB28282783790779B67897A6AE55C380ED2DB264D42870F2D880A5]... not activated.
Activating: EDK [MSO5100-EDK@952C31F126219EA1391F76F60D1978EE01E863D60644A3F1158B69DEEFA7DB70A075527F54FC28227B782D196A4BA0D9FEDB95361705B54028814FB6A511ECBA]... not activated.
Activating: EMBD [MSO5100-EMBD@66C79B675A739484D2F1AE25931E57D743DB0FC6D785369129F07A47B0DF531C05BFF41E826023872F46062E5D39F7DB7564FCB062E7636ABDFDAD877FA51D67]... not activated.
Activating: FLEX [MSO5100-FLEX@A259D940749CFAE8B96DDA399D458C5AA644CC1B48BAF3A017E97E794ABB4CD34BD6F518F092C8218B249A34DF6849B2BF9350BFDAA3D131D46106A681862B3C]... not activated.
Activating: JITTER [MSO5100-JITTER@45AA3452E542DA21A3C81DB164CF35F8AB4E4E80893DCEDA674D41D1555315513BF82C21F3BBA501B3EF412AC354B87A616F9AF5C6A4E0C24D320F8A93E58EA4]... not activated.
Activating: MASK [MSO5100-MASK@390F7931353BEEABC4BF1425831F8612D86434BAF1A4E10D3DDEE918D0BD5F351F405EEF53FE29E94C8626786EE574A4FE7E59881B8BFCEBCF28B107DCFDDC22]... not activated.
Activating: MSO [MSO5100-MSO@193ED0D231141DFCB71C33A87270041321C73F0EFE0F1952ACE67C1AD73EB6332EAC4E061625B0D8F98AA55612D69133BA083BE8AED736692A896A96AB61E30B]... activated.
Activating: PWR [MSO5100-PWR@2A27DA3963D0C599C5CF9B25F819A8E90EE374C9BAE04D6316FBD56C53AAACC41E649376B6D7C5FB7A0099244929475914A9867E874E6E1EB3F381F37D8193F6]... not activated.
Activating: SENSOR [MSO5100-SENSOR@0622D1C5DF405041F4292641D9965F9CC0626EE6179150AD13A1762715462F61301B178B556C1F1A49D3755F8FB8E2DB3154AB0F14BDC510591DAB78638F0D54]... not activated.
╒════════╤══════════╤═════════════════════════════════════════════════════╕
│ Code │ Status │ Description │
╞════════╪══════════╪═════════════════════════════════════════════════════╡
│ BW1T2 │ ---- │ 100MHz to 200MHz Bandwidth Upgrade Option │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ BW1T3 │ ---- │ 100MHz to 350MHz Bandwidth Upgrade Option │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ 2RL │ ---- │ 200Mpts Deep Memory Option │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ COMP │ ---- │ Computer Serial Triggering and Analysis(RS232/UART) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ EMBD │ ---- │ Embedded Serial Triggering and Analysis(IIC, SPI) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ AUTO │ ---- │ Automotive Serial Triggering and Analysis(CAN/LIN) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ FLEX │ ---- │ FlexRay Serial Triggering and Analysis │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ AUDIO │ ---- │ Audio Serial Triggering and Analysis(I2S) │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ AERO │ ---- │ MIL-STD 1553 Serial Triggering and Analysis │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ DG │ ---- │ Dual Channel WaveGen 25 MHz AWG │
├────────┼──────────┼─────────────────────────────────────────────────────┤
│ PWR │ ---- │ Integrated Power Analysis │
╘════════╧══════════╧═════════════════════════════════════════════════════╛
It shows that I have 9 remaining attempts, I can not reinstall the old keys, maybe because I have overwritten the FRAM with the option -r, which was a huge mistake.
Can someone please help me please, I'm stuck and I really do not know what to do now.
Thanks a lot, Best Regards, Seppeltronics
QuoteIt shows that I have 9 remaining attempts, I can not reinstall the old keys, maybe because I have overwritten the FRAM with the option -r, which was a huge mistake.
Can someone please help me please, I'm stuck and I really do not know what to do now.
Thanks a lot, Best Regards, Seppeltronics
Was having the same problem. In my case, I had to setup a static IP on the scope and on the PC and connected both directly (no switch or router in between) and after that the script run flawlessly.
Il.just post here that I did the static IP thing on my scope and the script still didn't work for me. The other method with the local upgrades works fine though sood the script doesn't like your setup you can do the local upgrades as a fall backExactly, Seppletronics had the same problem he's now upgraded through the local upgrade successfully
Il.just post here that I did the static IP thing on my scope and the script still didn't work for me. The other method with the local upgrades works fine though sood the script doesn't like your setup you can do the local upgrades as a fall back
the script doesn't like your setupHowever, if it's a method that works , it shouldn't matter what the script likes or not.
Try to uninstall all options first, wait for reboot, then install with regen private key flag.
I tried as described, first uninstalled and after reboot I installed with regen private key. Tried it several times but the oscilloscope only replies with "remaining attempts" as described by zauberpilz, now only 2 attempts left. What am I doing wrong? Could you please help?