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.
I don't have my instrument yet (mid/late January based on what TE told me), but the DATA partition (mtd1) contains some licensing and calibration information. Someone posted a dump of their NAND partitions so I am working off of that and extracted firmware. They silence the kernel while mounting this partition so it doesn't show up in kernel logs (it is UBIFS). I guess they were going for "out of sight out of mind" approach with that and user partitions.
############################################
#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
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.
Did anyone try dumping the core to obtain memory dump of appEntry? If busybox was modified to disallow core dumps, there is a version for ARMv7 that is used for Siglent scopes (Zynq platform) that one can drop into /tmp and spawn from there. Should be fairly straight forward. Assuming busybox wasn't modified to disallow the core dumps:
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.
Another option is to tap into AXI and see if DRAM can be read directly if the full DRAM dump is desired. Their AXI driver API seems fairly simple.
Been lurking around the forums and reading for a long time now, figured I'd register and see if I can contribute to hacking this thing, so Hello is in order.