New Rigol 16-bit function generators DG800/900 series

[SMB784]

Like this?

Can you dump the contents of the two files that I pulled from your ls dump or attach them here (see attached image)

[SMB784]

As an aside, it would appear from TV84's dump of the file system that the desired login name is "root".  No word on the root password yet, though I have been trying many fun combinations involving sardines.

[SMB784]

Attached dumps from the offical rigol firmware, mostly just the file structure.  There are three main firmware archives in UBIFS format: _app, _Sardine, and _rootfs, each with some interesting things in them.  I'm able to mount the rootfs archive and look around in it, but I cant get either _app or _Sardine open to look around in it yet.  I did however extract an interesting shell script using ubidump, which I have also attached.  Gives an idea of how the calibration might work, I think.

Still cant find the calibration data in the firmware files though.  Maybe its saved into the /root directory of rootfs after the unit is first calibrated?

*** EDIT ***

FInally opened the UBIFS archives and extracted the data.  No cal info, but an xml file in the Sardine UBIFS archive contained some interesting references to calibration procedure.  See attached xml
file called "msg_en"

Also I found the /etc/shadow file that contains the hashed root password. The encryption is probably unbreakable though

[bd139]

Can someone post the /etc/shadow line for root. My GPU is sitting here doing nothing at the moment and needs some hashcat exercise 

[tv84]

Can someone post the /etc/shadow line for root. My GPU is sitting here doing nothing at the moment and needs some hashcat exercise 

I'll bet it is.    But, the problem is that the line doesn't have nothing of interest. 

/etc/passwd

Code: [Select]

root:x:0:0:root:/root:/bin/sh
daemon:x:1:1:daemon:/usr/sbin:/bin/false
bin:x:2:2:bin:/bin:/bin/false
sys:x:3:3:sys:/dev:/bin/false
sync:x:4:100:sync:/bin:/bin/sync
mail:x:8:8:mail:/var/spool/mail:/bin/false
www-data:x:33:33:www-data:/var/www:/bin/false
operator:x:37:37:Operator:/var:/bin/false
nobody:x:99:99:nobody:/home:/bin/false
sshd:x:1000:1000:SSH drop priv user:/:/bin/false
/etc/shadow

Code: [Select]

root::10933:0:99999:7:::
daemon:*:10933:0:99999:7:::
bin:*:10933:0:99999:7:::
sys:*:10933:0:99999:7:::
sync:*:10933:0:99999:7:::
mail:*:10933:0:99999:7:::
www-data:*:10933:0:99999:7:::
operator:*:10933:0:99999:7:::
nobody:*:10933:0:99999:7:::
sshd:*:::::::
/etc/inittab

# /etc/inittab
#
# Copyright (C) 2001 Erik Andersen <andersen@codepoet.org>
#
# Note: BusyBox init doesn't support runlevels.  The runlevels field is
# completely ignored by BusyBox init. If you want runlevels, use
# sysvinit.
#
# Format for each entry: <id>:<runlevels>:<action>:<process>
#
# id        == tty to run on, or empty for /dev/console
# runlevels == ignored
# action    == one of sysinit, respawn, askfirst, wait, and once
# process   == program to run

# Startup the system
::sysinit:/bin/mount -t proc proc /proc
::sysinit:/bin/mount -o remount,rw /
::sysinit:/bin/mkdir -p /dev/pts
::sysinit:/bin/mkdir -p /dev/shm
::sysinit:/bin/mount -a
::sysinit:/bin/hostname -F /etc/hostname
# now run any rc scripts
::sysinit:/etc/init.d/rcS

# Put a getty on the serial port
#ttyO0::respawn:/sbin/getty -L  ttyO0 115200 vt100 # GENERIC_SERIAL
ttyO0::respawn:/sbin/getty -n -l /sbin/autologin 115200 ttyO0

# Stuff to do for the 3-finger salute
#::ctrlaltdel:/sbin/reboot

# Stuff to do before rebooting
::shutdown:/etc/init.d/rcK
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r

I'm afraid CalibrationData.dat might have ID data, so cannot share because it's not mine.

[bd139]

Ok so root should have no password if the second field is ::

[SMB784]

I can confirm that the root password is not an empty field.  It definitely requires a password.

/etc/shadow

Code: [Select]

root:<redacted>:10933:0:99999:7:::

daemon:*:10933:0:99999:7:::

bin:*:10933:0:99999:7:::

sys:*:10933:0:99999:7:::

sync:*:10933:0:99999:7:::

mail:*:10933:0:99999:7:::

www-data:*:10933:0:99999:7:::

operator:*:10933:0:99999:7:::

nobody:*:10933:0:99999:7:::

sshd:*:::::::

There is definitely a password hashed in there.

/etc/passwd:

Code: [Select]

root:x:0:0:root:/root:/bin/sh
daemon:x:1:1:daemon:/usr/sbin:/bin/false
bin:x:2:2:bin:/bin:/bin/false
sys:x:3:3:sys:/dev:/bin/false
sync:x:4:100:sync:/bin:/bin/sync
mail:x:8:8:mail:/var/spool/mail:/bin/false
www-data:x:33:33:www-data:/var/www:/bin/false
operator:x:37:37:Operator:/var:/bin/false
nobody:x:99:99:nobody:/home:/bin/false
sshd:x:1000:1000:SSH drop priv user:/:/bin/false

/etc/inittab

Code: [Select]

# /etc/inittab
#
# Copyright (C) 2001 Erik Andersen <andersen@codepoet.org>
#
# Note: BusyBox init doesn't support runlevels.  The runlevels field is
# completely ignored by BusyBox init. If you want runlevels, use
# sysvinit.
#
# Format for each entry: <id>:<runlevels>:<action>:<process>
#
# id        == tty to run on, or empty for /dev/console
# runlevels == ignored
# action    == one of sysinit, respawn, askfirst, wait, and once
# process   == program to run

# Startup the system
::sysinit:/bin/mount -t proc proc /proc
::sysinit:/bin/mount -o remount,rw /
::sysinit:/bin/mkdir -p /dev/pts
::sysinit:/bin/mkdir -p /dev/shm
::sysinit:/bin/mount -a
::sysinit:/bin/hostname -F /etc/hostname
# now run any rc scripts
::sysinit:/etc/init.d/rcS

# Put a getty on the serial port
ttyO0::respawn:/sbin/getty -L  ttyO0 115200 vt100 # GENERIC_SERIAL
#ttyO0::respawn:/sbin/getty -n -l /sbin/autologin 115200 ttyO0

# Stuff to do for the 3-finger salute
#::ctrlaltdel:/sbin/reboot

# Stuff to do before rebooting
::shutdown:/etc/init.d/rcK
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r


[tv84]

SHA512...     Only with a bit of luck.

[SMB784]

SHA512...     Only with a bit of luck.

While we are working on this, do you have the content of the files I mentioned in this message?

Like this?

Can you dump the contents of the two files that I pulled from your ls dump or attach them here (see attached image)

[bd139]

Running hashcat on my standard password corpus now. 51gb of passwords

Brute forcing salted sha-512 is unproductive unless you're the NSA so it's probably better to see if you can patch the firmware with a known password before it gets to the device. Not sure if their firmware is signed or not.

[tv84]

While we are working on this, do you have the content of the files I mentioned in this message?

My answer is in previous msg.

[SMB784]

While we are working on this, do you have the content of the files I mentioned in this message?

My answer is in previous msg.

Thanks! It's easy to miss those tiny little attachments at the end of a long post 

Running hashcat on my standard password corpus now. 51gb of passwords

Brute forcing salted sha-512 is unproductive unless you're the NSA so it's probably better to see if you can patch the firmware with a known password before it gets to the device. Not sure if their firmware is signed or not.

Another alternative is to find a way to crash the boot process (if such a method exists) and hope it drops us into root shell

[SMB784]

attached CalibrationInfo.dat in "human readable" format

Includes something with a date (October 2018) but thats probably just the calibration date (maybe could check to see if change when using SCPI :CAL:DATE command).  Not much else seems to be very useful here.

[bd139]

No luck with hashcat. 3.3 billion passwords tried 

[SMB784]

No luck here either

Looks like we will need a custom firmware or figure another way into root shell.

[SMB784]

Does anyone know what part number the FPGA on the main board is? *** EDIT *** Turns out I didnt need the exact part number, its a spartan 6 and my software doesn't care what kind.

I did a strings search for anything calibration related in the SardineMain executable program that seems to control basically every function of this unit when it is on, and found a lot of interesting information (dump attached in this message).  The first thing to say is that "/root/CalibrationData.dat" is referenced in the SardineMain program but does not exist in the firmware from Rigol's website.  This leads me to believe that as we suspected it is generated after the unit is turned on and the calibration routine has been run.  There is also a reference to a calibration routine (ServCalibration.cpp) in the dump that I have attached.  Does anyone think its possible to unpack this executable to get at these programs? (I have also attached this executable to the end of this message)

I'm going to try to read the contents of the winbond flash and hopefully extract the firmware so that I can get that CalibrationData.dat file from my unit and crack it open.

Also just as a fun note, I soldered in some leads and found that the JTAG connection is not disabled, so it is possible to reprogram the FPGA with the .bit files in the firmware (or any other bit file generated for this FPGA)

[TurboTom]

Can anyone identify the FPGA on the main board?

I did a strings search for anything calibration related in the SardineMain executable program that seems to control basically every function of this unit when it is on, and found a lot of interesting information (dump attached in this message).  The first thing to say is that "/root/CalibrationData.dat" is referenced in the SardineMain program but does not exist in the firmware from Rigol's website.  This leads me to believe that as we suspected it is generated after the unit is turned on and the calibration routine has been run.  There is also a reference to a calibration routine (ServCalibration.cpp) in the dump that I have attached.  Does anyone think its possible to unpack this executable to get at these programs? (I have also attached this executable to the end of this message)

I'm going to try to read the contents of the winbond flash and hopefully extract the firmware so that I can get that CalibrationData.dat file from my unit and crack it open.

Also just as a fun note, I soldered in some leads and found that the JTAG connection is not disabled, so it is possible to reprogram the FPGA with the .bit files in the firmware (or any other bit file generated for this FPGA)

The FPGA is a Xilinx SPARTAN6 XC6SLX9-FTG256BIV. The package marking is quite difficult to decipher since the laser marking isn't very deep and moreover, Rigol arranged the assembly so there's silicone pad touching the top of the FPGA, spilling silicone oil all over it, affecting readability even more...

Anyway, application of some brake cleaner and dry tissue and placing the illumintaion at a shallow angle, revealed the imprint. So it's the second smallest FPGA in XILINX's Spartan6 range.

Yet, I don't think that's the limiting factor that precludes the contemporary use of CH2 and the frequency counter. It rather seems that the mysterious U603, of which I guess that it's a DAC (possibly 2 channel audio type) to generate the offset voltages, is used to output the trigger threshold for the freqency counter input comparator and thus is no longer available for the offset of channel 2. I may be completely wrong, though... 

(rant on...) BTW, I consider it bad style to edit a post to completly change its meaning or to remove substantial parts of it. This puts consecutive posts out of order and may render considerable time and effort spent by other forum members futile. It's much better practice to just cross out the sections that one wants to remove from his / her post or to publish another post that explains the new motivation. In this case, I specifically added the citation of the original post that I was referring to... (rant off)

Cheers,
Thomas

[maxwell3e10]

On a slightly different topic, I found that if the generator is outputting an arbitrary waveform it cannot seem to lock to an external 10 MHz clock. I wonder of someone can confirm it.

[SMB784]

(rant on...) BTW, I consider it bad style to edit a post to completly change its meaning or to remove substantial parts of it. This puts consecutive posts out of order and may render considerable time and effort spent by other forum members futile. It's much better practice to just cross out the sections that one wants to remove from his / her post or to publish another post that explains the new motivation. In this case, I specifically added the citation of the original post that I was referring to... (rant off)

Cheers,
Thomas

My bad, sorry!  Thanks for getting me that information.

[TurboTom]

On a slightly different topic, I found that if the generator is outputting an arbitrary waveform it cannot seem to lock to an external 10 MHz clock. I wonder of someone can confirm it.

I checked the behaviour of my "improved" DG811, F/W 00.02.04, with the built-in arbitraries and found that it very well locks onto an external reference frequency. You've got to tell the instrument in the "Utility" menu to use the external clock source, though, since by default, it uses the internal source and utilizes the "EXT Ref" port to output this frequency.

[maxwell3e10]

I was using a custom uploaded waveform. I will check more, it was locking fine to external clock when outputting sine wave (after set to external) but would report a error when outputting a custom waveform.

[TurboTom]

That really surprises me. The "AWG engine" shouldn't even notice the difference whether the reference is supplied from its internal oscillator or via the external input. It's just a switch, controlled by the CPU module and (probably) a (divided) signal fed back via the FPGA to a counter so the CPU can verify that the external reference is in the right ballpark or present at all.

Maybe you used a dodgy BNC cable or adapter to supply the reference?

I'll set up a custom arbitrary and will experiment some further as well. Should this turn out to be truely a problem, this would be a vast negligence of Rigol...


Edit: Did some more testing and indeed, I found a very weird behavior when using custom arbitraries! The instrument drops out of external reference mode with an error if "interpolation" as filter mode is selected. When using "step" or "smooth" filter response, EXT Ref stays enabled and the instrument uses it. Must be a peculiar firmware bug! Rigol, you've got a job to do... 

[maxwell3e10]

Thanks for confirming it!  I was actually trying to do something with the FG (hard to believe ) so didn't investigate further. But yes, there doesn't seem to be any fundamental reason for this problem.
Edit: Unless Rigol uses the clock reference PLL to generate some kind of variable clock for waveform output?

[joeyjoejoe]

I am following steps a few pages back.

I have a DG821 with FW "00.01.08.00.01". Can anyone confirm if this IS or IS NOT considered "FW 1.08" and if I need to downgrade with Vtech's file?

[tv84]

I am following steps a few pages back.

I have a DG821 with FW "00.01.08.00.01". Can anyone confirm if this IS or IS NOT considered "FW 1.08" and if I need to downgrade with Vtech's file?

IS.