-
In my oppinion, the colours are not very well chosen concerning the combination of RGB pixel appearance to the human eye.
They appear too uneven in brightness when deactivated.
The combination i'd love to see is the font of the DP832A mode but other colours - even monochrome as in the DP832 mode would be ok.
Maybe the RGB values can be found and replaces in the binary.
-
The combination i'd love to see is the font of the DP832A mode but other colours - even monochrome as in the DP832 mode would be ok.
Maybe the RGB values can be found and replaces in the binary.
I'm quite sure the color values can be found. The problem is that the firmware seems to be checksummed or signed. Earlier in this thread a simple string replacement of model names was tried, and the modified firmware would not be flashed. Even the checksum for flashing could probably be figured out, but if the bootloaded has an another check, your PSU might become bricked. Does anyone know if the firmware is flashed by the bootloader or the main firmware itself? It might be done by the bootloader based on the upgrade instructions. -
tossu, I think it's the bootloader since the .GEL reference only appears in BL.
From my code analysis you discovered the USB_vendor_disk string that must be present in order for the commands to change MODEL and/or SN to work, right? -
From my code analysis you discovered the USB_vendor_disk string that must be present in order for the commands to change MODEL and/or SN to work, right?
What's a USB_vendor_disk? It don't recognize that indentifier. The only usb vendor disk thing I could find with Google was a reference in the MSO5000 hacking thread. I'm not at all familiar with that.
But yes, I discovered the value that must be present on a USB drive. Finding the value was easy. I spend more time than I'd like to admit decompiling the firmware before I took a look at MQX RTOS sources and found out that the value had to be on a USB drive. -
There is another specimen of USB_vendor_disk that is recognized by other Rigol equipments. It possesses a specific XXTEA encrypted sector.
You've discovered a simpler one used on other equipment models. That was a big reversing job since the code is not obvious at all (I've just looked into it)!
Now, let's try and see which other models recognize this USB_disk.
Again, great job!
Edit: Just by looking at the .GEL file types, I would say that this method works, at least, for all
DP800 , DL3000 and DG1000(Z)
-
Could someone eager to hack (or brick) their DG1032Z send these commands to it, preferably via USB, and post the results here? The keyfile.bin I made for DP832 should work.
Would like to check it on DG1022Z as soon as it arrives. -
I managed to reverse engineer the firmware and found a hidden command which can be used to change the model. Huge thanks to volkimel and tv84 for descrambling and parsing the firmware!
First, create a USB drive with magic value "80 DF 20 10 90 20 62 80" in sector 0x58E0. You can format a drive as FAT and copy keyfile.bin from the attached zip to it. The keyfile is filled with the magic pattern, and the chances are that it gets placed over the right sector.
After that, insert the drive to your DP832 and send the following SCPI command to it.Code: [Select]:PROJ:SET MODEL,DP832A
Reboot, and you should be greeted with a colorful display.
Tossu and TV84, I cannot thank you guys enough for your help with this project, along with everyone else who provided insight and tried helping in hacking this! This was something I wanted for a very long time and just found out today that it was finally hacked! THANK YOU GUYS SOOOOOO MUCH!!!!!!!! -
In my opinion, the colors are not very well chosen concerning the combination of RGB pixel appearance to the human eye.
They appear too uneven in brightness when deactivated.
The combination I'd love to see is the font of the DP832A mode but other colors - even monochrome as in the DP832 mode would be ok.
Maybe the RGB values can be found and replace in the binary.
THIS! As much as I like the DP832A font it would probably take some time to get used to the new yellow, purple and blue colors. A firmware hack with a different palette would be fantastic. What colors would you guys prefer to have instead? IMO plain white for all three channels would be nice
-
Actually, the choice of the color palette like it's been on the "non-A-configuration" but with the fonts / layout of the "A-classic" would be my favorite. Anyway, I'm happy the way it is right now.
P.S. I've also been playing around with my DG4102 and the prepared USB disk. Same result as @RoGeorge. Also somewhat strange behavior of the LXI interface via telnet but that's probably the result of the completely different underlying hardware (BlackFin) compared to the DP800 series (i.MX28 processor). -
What colors would you guys prefer to have instead? IMO plain white for all three channels would be nice
White would be my favourite too. -
P.S. I've also been playing around with my DG4102 and the prepared USB disk. Same result as @RoGeorge. Also somewhat strange behavior of the LXI interface via telnet but that's probably the result of the completely different underlying hardware (BlackFin) compared to the DP800 series (i.MX28 processor).
Tom, I've got no indication that this might work on that BF machine. But, maybe there is a similar one...
-
Just confirmed that the DL3000 is exactly as the DP800 (the disk sector is also 0x58E0). And same byte sequence.
Can anyone try a DL3000 to DL3000A conversion?
-
Just confirmed that the DL3000 is exactly as the DP800 (the disk sector is also 0x58E0). And same byte sequence.
Can anyone try a DL3000 to DL3000A conversion?
There is a DL3000 at work which is rarely used. I may try applying the hack on Monday. Same procedure and SCPI command as on the DP832?
Should I update to the latest firmware version before applying the hack? And is there a real chance of bricking it?
EDIT:
It seems like a stock DL3021 can't use the LAN port without buying an upgrade. Is it possible to apply the SCPI command using RS-232? -
OK, I promised a write-up of my hacking process earlier. I've left out some things I did if they didn't end up anywhere, but feel free to skip the first part still. It's night already and I'm tired and writing in English. Not much can be expected. I finally got to it so here it comes!
Premilinary work
I started with a firmware version 1.14 descrambled with the method previously discovered in this thread. The first thing to do was of course to run binwalk and strings on it. Binwalk found a lot of ARM instructions and the entropy plot seemed sensible. I read the list of strings carefully and found some interesting: MODEL, FACTORYON, FACTORYOFF, MANUFACTUREON, MANUFACTUREOFF. They looked a lot like SCPI commands.
I tried a lot of plausible combinations like :SYSTEM:FACTORYON programmatically. I got just a bunch of false results because the SCPI server crashes easily and starts to do weird things.
I wanted to disassemble the firmware, and luckily the loading address had already been figured out. Search for references to those interesting string constants found something. One function, insted of it's normal thing, sets a variable to 1 if parameter FACTORYON is passed to it while some condition is true. The function usually takes ON, 1, OFF or 0 as a parameter. The DP800 programming manual list only a few of those. I tried all of them them but those returned errors. That was very much expected. Following functions calls for the condition would just find more and more complex code with indirect references.
At this point, I figured out I had been living under a rock, and there's a new decompiler called Ghidra. I wanted to try it so I redid all of my previous work with it. It didn't take much time at all, but neither did it help me any further. I started to look for other commands. I found a one which can set a MODEL or SN, but it checks for the same condition before it does anything.
A dump of RAM would've helped me a lot, and there was a command for it. To use it, I had to get it's name. The names were stored in a tree-like structure which had to be parsed. By chance I came across a simple Perl script for printing DS1054Z command structure. I quickly rewrote it in Python and had a list of commands on the first try. I modified it to print command IDs and conditional parts properly. The command list is attached if you want to have a look.
Now I could start dumping the memory with command :PROJect:MEMOry:READ?. Figuring out it's parameters was easy with a help of a decompiler. The first kilobyte of the flash could be read with :PROJ:MEMO:READ? FLASH,0,1024 and it was sensible. To test it I dumped the flash. There was just the firmware I already had. Luckily the command could also read RAM by changing the first parameter. I tried to read the RAM but the output made no sense. I read the decompiled source again and was sure I was using the command right. Instead, the command either had a placeholder implementation or was missing a call to atoi. It read from the address of the second parameter instead of the numeric value and would just echo back the parameters. I had to do more static analysis without a memory dump.
Decompilation and a hack
The offset and the loading address of the firmware are known thanks to previous efforts in this thread. The array of pointers to command handlers is easy to find. Just find one handler with a known string and follow the cross references. Names of the commands are stored in an another large structure which can be parsed with a script made for DS1054Z. It has pointers to all the command names and is easily found with xrefs.
The command handler which can change the model references strings MODEL an SN. The former is long enough to be found with any string search. The handler calls a function which does the USB drive check. Unless it returs zero, the handler does nothing and returns an error. A pointer to the command can be found by following xrefs back to the command handler array. Based on it's index, name :PROJect:SET can be found from the command name structure.
The USB drive check function has many arbitary values. By calling a second function, it does a memcpy-like operation of 8 bytes from 0x58E0 to an array in the stack and compares those against hard coded constants. The second function has a pattern which looks very much like "allocate, read something, memcpy, free". At least the vectorized memcpy is easy to recognize.
The function which does the reading is unfortunately the most difficult to understand. I uses a lot of pointers and arbitary values. It also has a slightly different style to it. This hints that it might be a part of an OS driver. Strings reveal that the firmware contains version 3.7 of MQX RTOS. It's sources are available, and they contain symbolic values for some of the immediate values used in the fuction. One, MFS_READ_FAULT, is used only in three places. One of those is function MFS_Read_device_sector. It's source matches the decompiler output perfectly. The last thing to do with the code is go back and get the 8 byte value from the disassembly. Some mental math has to be done to get endianness right.
When the value is written to the start of sector 0x58E0 of a USB drive, the command :PROJect:SET will work. I took the easy route and did the file copy trick. Mainly because I didn't bother to check if a valid file system is required or if it's sector 0x58E0 of the drive or a partition or something.
Afterthoughts
I think it took me three or four evenings of messing around with my DP832 in total. Most of it was spend trying to dump the memory and trying some things I've left out. I didn't help that I had never read ARM assembly or used Ghidra before. I think Ghidra is an excelent tool and in some ways better than a, um, free version of another interactive disassembler.
I've decompiled some of the other commands. The unit can be set to some factory mode with command :SYST:BEEP FACTORYON if the magic USB drive is inserted. In that mode the model can be set with :SYST:LOCK DP832A$, but I don't think it enables anything else. :DIGItal:IO commands seemed somewhat interesting by their name, but they don't seem to be doing anything.
The :PROJ:SET command should return OK but crashes the command line if it's send via LAN. I think it safer to test it via USB on other Rigol models. However, on DP832 it seems to be working quite well.
-
There is another specimen of USB_vendor_disk that is recognized by other Rigol equipments. It possesses a specific XXTEA encrypted sector.
You've discovered a simpler one used on other equipment models. That was a big reversing job since the code is not obvious at all (I've just looked into it)!
It seems you got a hang of my hack pretty quickly before any explanation. I assume you got figured it out completely as you were able to check it for other models. Did the magic values help? What's the another specimen? Could you tell how did you thought I did it? I haven't really read other Rigol hacking threads so I might be asking some stupid questions. If that's the case, please point me to the right direction. -
tossu, how do you look into DG1000Z firmware? I tried the python version of descrambler, but output is a complete mess, not anyting readable in strings output at all.
-
thanks for the hack.
quick hint for linux users: if you connect it via USB it will be detected as an usbtmcX device:Code: [Select][38355.860413] usb 5-1.2: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 80, changing to 10
[38355.860415] usb 5-1.2: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[38355.860417] usb 5-1.2: config 1 interface 0 altsetting 0 bulk endpoint 0x3 has invalid maxpacket 64
[38355.861908] usb 5-1.2: New USB device found, idVendor=1ab1, idProduct=0e11, bcdDevice= 0.02
[38355.861909] usb 5-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38355.861910] usb 5-1.2: Product: DP800 Serials
[38355.861912] usb 5-1.2: Manufacturer: Rigol Technologies.
[38355.861913] usb 5-1.2: SerialNumber: DP8C163953058
[38355.939460] usbcore: registered new interface driver usbtmc
it's a simple char device -> you can use echo and cat to access it:Code: [Select]# echo ":SYSTem:VERSion?" > /dev/usbtmc3
# cat /dev/usbtmc3
1999.0
^C^C^C^C
# echo ":PROJ:SET MODEL,DP832A" > /dev/usbtmc3
it works with a FAT16 partition on a newer USB stick - just make it the first partition on the stick -
It seems you got a hang of my hack pretty quickly before any explanation. I assume you got figured it out completely as you were able to check it for other models. Did the magic values help? What's the another specimen? Could you tell how did you thought I did it? I haven't really read other Rigol hacking threads so I might be asking some stupid questions. If that's the case, please point me to the right direction.
You took advantage of my parsings but you deserve full credit for this discovery!
(the main reason of my parsings is to allow the kind of work you did)
In the meantime, the method has been confirmed to work on DG1000Z (as expected, even with a different sector). Of course, I was only able to somewhat understand what you did based on the magic values that you published. Even after your explanation is not something very easy to recreate without diving into the MQX toolchain.
The other specimen can be used, for example, in the DS1054Z and also in the MSO5000/7000 (it's for ARM only)
You can have a taste of it, here:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1473517/#msg1473517
Based on known Rigol's way of doing things, it was not hard to figure out what you had accomplished (even if you were not fully aware at the time). Without previous knoweledge of Rigol hacks it's even more amazing!
Even the "brute-force" method of the file in the disk is poetry. BTW , it wouldn't work in the other specimen because the sector is one of the disk reserved sectors.
-
In the meantime, the method has been confirmed to work on DG1000Z (as expected, even with a different sector).
Does DG1000Z work with same magic sector as DP800 or it is another one.. Syntax for a model command is the same I presume?
Thks! -
In the meantime, the method has been confirmed to work on DG1000Z (as expected, even with a different sector).
Does DG1000Z work with same magic sector as DP800 or it is another one.. Syntax for a model command is the same I presume?
Thks!
It's a different sector but tossu file works also with that sector. Syntax should be the same. -
Would this sort of hack work on the Rigol DG1022 (non Z) as well? I have a DG1022 on my bench and would love to turn it into a DG1022A.
-
Would this sort of hack work on the Rigol DG1022 (non Z) as well? I have a DG1022 on my bench and would love to turn it into a DG1022A.
The FW is the same, right? If so, I think it would but you are all on your own. I've done no tests since I don't have the equipment.
The test done was DG1022Z -> DG1062Z. -
DG1000Z doesn't work over telnet.. It hangs the AWG completely (not responsive to buttons)..
Will try over USB, installing UltraSigma.. -
Over USB on the first try all went well.. Even got OK\n response..
Reboot and it works..
And now only Arb16M
@tossu premium work kudos.. thanks a bunch
and as always thanks to tv84..
-
tossu, how do you look into DG1000Z firmware? I tried the python version of descrambler, but output is a complete mess, not anyting readable in strings output at all.
It uses the same scrambling algorithm but a different starting value. I took advantage of the fact that firmwares usually have long strings of zeroes and those make distinctive patterns of increasing numbers. If the right value of just one byte is known, the offset can be calculated.The FW is the same, right? If so, I think it would but you are all on your own. I've done no tests since I don't have the equipment.
DG1022 is the old, DS1052E era function generator. I don't think it's going to work.