cybernet strikes again!
Upgraded my unit in about 4 minutes.
Re. DG4000 cengen: There are several of us non Unix/Linux users here on the forum that would very much appreciate a Windows or Web application to generate the required CEN file. If someone could put one together it would be very much appreciated
Re. DG4000 cengen: There are several of us non Unix/Linux users here on the forum that would very much appreciate a Windows or Web application to generate the required CEN file. If someone could put one together it would be very much appreciated
The best would be if studio25 could integrate it in his web app RigLOL
http://riglol.3owl.com
Re. DG4000 cengen: There are several of us non Unix/Linux users here on the forum that would very much appreciate a Windows or Web application to generate the required CEN file. If someone could put one together it would be very much appreciated
---
original post removed
---
I'm editing this post to remove the link to my windows binary. Apparently it is putting extra bytes in the license file. I tried several different compilers and even tried cross-compiling for windows from my linux box. Every windows binary I make puts extra bytes into the license file. I don't have enough time to see exactly why, so I offer here an alternative solution if you only have access to windows.
1) Go to
http://www.compileonline.com/compile_c_online.php2) Replace the code in the left box with the code below.
3) Put your command line arguments in the text box at the bottom (in the form <current model> <new model> <current serial>)
4) Press "Compile and Execute" in the top left
5) Press "Download Files" in the top right (assuming everything executed properly)
6) The result tar.gz file will have the proper license.CEN file contained within it.
-Clayton
/*
** rigol DG4000 cengen / cybernet
**
** BUILD WITH:
** gcc cengen.c -m32 -o cengen
**
** RUN WITH:
**
** ./cengen <CURRENT_MODEL> <NEW_MODEL> <CURRENT_SERIAL> [<NEW_SERIAL>]
**
** <?_MODEL> = DG4062, DG4102, DG4162, DG4202(*)
** <?_SERIAL> = DG4D1XXXXXXXX
**
** if <NEW_SERIAL> is omitted the serial will not be modified
** (*) DG4202 is not an official model, but 200Mhz seems to work fine
**
**
** =================================================================================
** more info: https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/
** =================================================================================
**
** ____ ______________ ___ __
** / __ \/_ __/ ____/ |/ / / /
** / /_/ / / / / /_ / /|_/ / / /
** / _, _/ / / / __/ / / / / /_/
** /_/ |_| /_/ /_/ /_/ /_/ (_)
**
** this tool generates a new model type (DG4XXX) & serial (DG4D1XXXXXXXX) string,
** calculates a MAC and creates a .CEN file.
**
** what to do with the file ?
**
** put it on an USB stick, plug stick into DG4000, goto "Store", browse USB Stick,
** change "File Type" to "All File", navigate to your .CEN file, press "Read".
**
** You should get a Popup telling you that you successfully changed your model type and serial
**
** if *not* you:
** used a wrong current model type
** used a wrong current serial
** used an invalid new model type
** used an invalid new serial
**
**
** firmware tested:
** 00.01.06
** 00.01.03
**
**
** no warranties, if it explodes, your problem ;-)
**
*/
#include<stdio.h>
#include<stdlib.h>
#include<stdint.h>
#include<string.h>
#include<ctype.h>
#define VERSION "0.1"
char header[]="RIGOL:DG4:FIRM LICENSE FILE";
char iv[]="1000000110000001";
char static_cccc[4];
char static_zero[8];
// endianess shit
union helper {
unsigned char c[8];
unsigned int l[2];
uint64_t u;
};
// shifty
void do_cbc(char a, char b, char c, char d, char e, char f, uint16_t word1, char *buffer)
{
uint16_t bit1,bit2,bit3,bit4,u,x,y,z;
char out;
int la;
if (buffer==0) return;
u=(1<<a)-1;
z=0;
x=0;
while (a > z)
{
x=x|(1<<z);
z++;
}
y=word1&x;
if (e==0)
{
la=0;
while (u > la)
{
*(int*)(buffer+la*2)=(int)y;
if (b==0) bit1=0;
else
{
bit1=(y>>(b-1))&1;
}
if (c==0) bit2=0;
else
{
bit2=(y>>(c-1))&1;
}
if (d==0) bit3=0;
else
{
bit3=(y>>(d-1))&1;
}
if (f==0) bit4=0;
else
{
bit4=(y>>(f-1))&1;
}
out=bit1^bit2;
out=out^bit3;
out=out^bit4;
y=y*2;
y=y&x;
y=y|out;
la++;
}
}
else
{
printf("not implemented - deemed useless code ...\n");
exit(-1);
}
}
/*
** convert string to uppercase chars
*/
char * strtoupper(char *str)
{
int i = 0;
for(i = 0; str[i]; i++)
{
str[i] = toupper(str[i]);
}
return str;
}
void ascii(void)
{
printf("\n");
printf(" ________ ____ ____ ____ ____\n");
printf(" / ___/ _ \\/ __ \\/ __ `/ _ \\/ __ \\\n");
printf("/ /__/ __/ / / / /_/ / __/ / / /\n");
printf("\\___/\\___/_/ /_/\\__, /\\___/_/ /_/\n");
printf(" V%s /____/ cybernet 2013\n\n", VERSION);
}
void help(void)
{
printf("\n ./cengen <CURRENT_MODEL> <NEW_MODEL> <CURRENT_SERIAL> [<NEW_SERIAL>]\n\n");
printf(" <?_MODEL> = DG4062, DG4102, DG4162, DG4202(*)\n");
printf(" <?_SERIAL> = DG4D1XXXXXXXX\n\n");
printf(" example: ./cengen DG4062 DG4202 DG4D150400123\n");
printf(" (upgrades DG4062 to DG4202, keeps serial number)\n\n");
printf(" if <NEW_SERIAL> is omitted the serial will not be modified\n");
printf(" (*) DG4202 is not an official model, but 200Mhz seems to work fine\n\n");
exit(-1);
}
char buffer_shift(int la, uint16_t *word1, char *buf)
{
int w;
int y;
int li=0;
char x=0;
while (li > la)
{
w=*word1;
y=*(buf+li);
if (y!=li)
{
*word1=w+1;
li=0;
x=1;
}
li++;
}
return(x);
}
// dump license file
void write_file(char *nms, char *buf, uint16_t buf_len)
{
char len[8];
FILE *fd=NULL;
fd=fopen("license.CEN", "w");
if (fd==NULL)
{
printf("unable to open file 'license.CEN' for writing\n");
exit(-1);
}
memset(static_cccc, 0xcc, 4);
memset(static_zero, 0x0, 8);
memset(len,0,8);
//bzero(len,8);
len[0]=(buf_len)&0xFF;
len[1]=((buf_len)>>8)&0xFF;
fwrite(header,1,strlen(header),fd);
fwrite(len,1,4,fd);
fwrite(static_zero,1,4,fd);
fwrite(static_cccc,1,2,fd);
fwrite(iv,1,strlen(iv)+1,fd);
fwrite(nms,1,strlen(nms),fd);
fwrite(buf,1,buf_len*2,fd);
fclose(fd);
}
int main(int argc, char *argv[])
{
char secret[]="YZDHZSGCX";
char new_model[8];
char new_serial[14];
char *new_model_serial;
char cur_model[8];
char cur_serial[14];
char *cur_model_serial;
char *buffer20;
char *buffer_a2;
char *buffer_a4;
int la;
char hbuf[3];
char chr;
int duplets,bits;
int r1,d1,r2,d2;
unsigned int data1,data2;
uint16_t word1;
unsigned char lasthex;
union helper uni1;
int key_len;
int prime=13;
int len_mts;
int lc,lb,ld;
int y;
uint16_t w;
ascii();
if (argc>=4)
{
strcpy(cur_serial, strtoupper(argv[3]));
strcpy(new_model, strtoupper(argv[2]));
strcpy(cur_model, strtoupper(argv[1]));
if (strlen(cur_model)!=6) { printf("invalid <CURRENT_MODEL> len\n"); help(); }
if (strlen(new_model)!=6) { printf("invalid <NEW_MODEL> len\n"); help(); }
if (strlen(cur_serial)!=13) { printf("invalid <CURRENT_SERIAL> len\n"); help(); }
if (strncmp(cur_model,"DG4", strlen("DG4"))) { printf("invalid <CURRENT_MODEL> type\n"); help(); }
if (strncmp(new_model,"DG4", strlen("DG4"))) { printf("invalid <NEW_MODEL> type\n"); help(); }
if (strncmp(cur_serial,"DG4", strlen("DG4"))) { printf("invalid <CURRENT_SERIAL> type\n"); help(); }
if (argc==5)
{
strcpy(new_serial, strtoupper(argv[4]));
if (strlen(new_serial)!=13) { printf("invalid <NEW_SERIAL> len\n"); help(); }
if (strncmp(new_serial,"DG4", strlen("DG4"))) { printf("invalid <NEW_SERIAL> type\n"); help(); }
strcpy(new_serial, strtoupper(argv[4]));
}
else strcpy(new_serial, strtoupper(argv[3]));
}
else help();
cur_model_serial=(char*)calloc(1, strlen(cur_model)+strlen(cur_serial)+1);
new_model_serial=(char*)calloc(1, strlen(new_model)+strlen(new_serial)+1);
strcpy(new_model_serial, new_model);
strcat(new_model_serial, new_serial);
strcpy(cur_model_serial, cur_model);
strcat(cur_model_serial, cur_serial);
printf("\nCurrent settings:\n");
printf("\tModel:\t\t%s\n",cur_model);
printf("\tSerial#:\t%s\n",cur_serial);
printf("\nNew settings:\n");
printf("\tModel:\t\t%s\n",new_model);
printf("\tSerial#:\t%s\n\n",new_serial);
buffer20=(char*)calloc(1,20);
buffer_a2=(char*)calloc(4,8192);
buffer_a4=(char*)calloc(4,8192);
memset(buffer_a4,0xAA,8192);
key_len=strlen(secret);
la=0;
duplets=0;
y=0;
hbuf[2]=0;
while(la < strlen(iv))
{
hbuf[0]=iv[la];
hbuf[1]=iv[la+1];
uni1.c[duplets]=strtol(hbuf,NULL,0x10);
duplets++;
la=la+2;
}
data1=uni1.l[0];
data2=uni1.l[1];
bits=duplets<<3;
r1=bits%prime;
d1=bits/prime;
if (r1 != 0) d1++;
lasthex=uni1.c[duplets-1];
d2=64/prime;
r2=64%prime;
la=0;
while (d1>la)
{
if (d2>0)
{
word1=data1&0x1fff;
uni1.u=uni1.u>>prime;
data1=uni1.l[0];
data2=uni1.l[1];
d2--;
}
else
{
word1=(int)(((int)data1)|(lasthex<<r2))&0xffff;
}
buffer_shift(la,&word1,buffer20);
*(int*)(buffer20+la*2)=(int)word1;
do_cbc(0xd, 0x1, 0x3, 0x4, 0x0, 0xd, word1, buffer_a2);
len_mts=strlen(new_model_serial);
ld=lb=lc=0;
while (len_mts > lc)
{
chr=cur_model_serial[lc];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
if (lb > (key_len-1)) lb=0;
chr=secret[lb];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
chr=secret[lb]^cur_model_serial[lc];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
if (ld > (len_mts-1)) ld=0;
chr=new_model_serial[ld];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
lc++;
lb++;
ld++;
}
la++;
}
w=*(uint16_t*)(buffer_a4)&0xffff;
w=w&0xfffc;
*(uint16_t*)(buffer_a4)=(uint16_t)w;
*(uint16_t*)(buffer_a4)=2|(uint16_t)w;
w=*(uint16_t*)(buffer_a4+0x14)&0xffff;
*(uint16_t*)(buffer_a4+0x14)=2|(uint16_t)w&0xfff8;
write_file(new_model_serial, buffer_a4, y);
printf("license file dumped into: 'license.CEN' - have fun !\n\n");
exit(0);
}
Cool! Good work cybernet (and all others)!
So, which Rigol devices left?
The dg1032z/dg1062z?
Re. bandgap, : DG4000 - a firmware investigation
: Reply #104 on: Yesterday at 06:40:38 PM »
Thank you Clayton. This was easy to use and it worked very well. I'm sure that you have made a lot of Windows users happy!
Thanks again, Ted
I Upgraded my DG4062 to a DG4202 (200 MHz), but . . .
Issue 1. What I’m seeing is that the sine wave output is flat to 100MHz within +/- ~ 0.4 dB to 100MHz, but about -1 dB @ 120MHz, ~ -2.5 dB @ 160MHz, and ~ -4.5dB @ 200MHz. The Square Wave Rise Time is about 4.1 ns, so I’m happy about that, as I believe that the extrapolated spec would be 5ns for the DG4202. But the Sine Wave level drop above 100MHz seems way out of the ordinary with the Flatness spec for the DG4162 being +/- 0.8 up to 160 MHz. Test configuration: I have the DG4000 output impedance set for 50 Ohms, used output levels of 0 and -15dBm (with the same results), and the output measurements were made with a Spectrum Analyzer and a HP RF Power Meter.
Issue 2. I also have an issue with DG4000 Screen Saver after several minutes of no activity (not making any changes on the front panel). The DS4000 comes up with a dark screen and a Rigol logo that changes position on the screen every 5 seconds, or comes up with Rigol in a single fixed position, or comes up with a blank screen. I didn’t notice this behavior before. Hopefully this issue is simply in the version 00.01.06.00.02 of software/firmware and others with/without this upgrade patch are experiencing this also (?).
System Info: Device Model - DG4062/DG4202, Serial Number - DG4D152xxxxxx, Software - 00.01.06.00.02, FPGA - 00.01.07.09, Hard - 01.03, Keyboard - 05.01, and Enc FPGA – 06.
I was able to successfully recovery the original DG4062 configuration by using the ‘cegen’ Keygen in reverse (DG4202 to DG4062).
The Screen Saver operation is the same. And by the way it kicks in after 15 minutes of no front panel activity. Out of 8 tests the Rigol Logo froze twice. So does this mean it is due to a firmware bug and was there before using ‘cengen’? Probably. . . Has this issue been reported by anyone else?
Please, any thoughts or comments would be appreciated.
I Upgraded my DG4062 to a DG4202 (200 MHz), but . . .
Issue 1. What I’m seeing is that the sine wave output is flat to 100MHz within +/- ~ 0.4 dB to 100MHz, but about -1 dB @ 120MHz, ~ -2.5 dB @ 160MHz, and ~ -4.5dB @ 200MHz. The Square Wave Rise Time is about 4.1 ns, so I’m happy about that, as I believe that the extrapolated spec would be 5ns for the DG4202. But the Sine Wave level drop above 100MHz seems way out of the ordinary with the Flatness spec for the DG4162 being +/- 0.8 up to 160 MHz. Test configuration: I have the DG4000 output impedance set for 50 Ohms, used output levels of 0 and -15dBm (with the same results), and the output measurements were made with a Spectrum Analyzer and a HP RF Power Meter.
Issue 2. I also have an issue with DG4000 Screen Saver after several minutes of no activity (not making any changes on the front panel). The DS4000 comes up with a dark screen and a Rigol logo that changes position on the screen every 5 seconds, or comes up with Rigol in a single fixed position, or comes up with a blank screen. I didn’t notice this behavior before. Hopefully this issue is simply in the version 00.01.06.00.02 of software/firmware and others with/without this upgrade patch are experiencing this also (?).
System Info: Device Model - DG4062/DG4202, Serial Number - DG4D152xxxxxx, Software - 00.01.06.00.02, FPGA - 00.01.07.09, Hard - 01.03, Keyboard - 05.01, and Enc FPGA – 06.
I was able to successfully recovery the original DG4062 configuration by using the ‘cegen’ Keygen in reverse (DG4202 to DG4062).
The Screen Saver operation is the same. And by the way it kicks in after 15 minutes of no front panel activity. Out of 8 tests the Rigol Logo froze twice. So does this mean it is due to a firmware bug and was there before using ‘cengen’? Probably. . . Has this issue been reported by anyone else?
Please, any thoughts or comments would be appreciated.
@screensaver - no issues for me - tried with FW 03, 06 and 07 - i doubt the mod interferes with the screensaver in any way.
@flatness - you will probably have to do a manual cal -> pw is 2010 - im no expert on that matter, but a Vrms meter should be sufficient, it seems to output different sines at different offsets/frequencies and expects you to correct the values shown in the tables - some of the tables are actually called "flatness" - so i would assume thats what can be used to tune it up to 160MHZ if not 200MHZ
cybernet Re: DG4000 - a firmware investigation
« Reply #110 on: Today at 10:53:32 PM »
Quote from: ted572 on Today at 09:54:43 PM
I Upgraded my DG4062 to a DG4202 (200 MHz), but . . .
Issue 1. What I’m seeing is that the sine wave output is flat to 100MHz within +/- ~ 0.4 dB to 100MHz, but about -1 dB @ 120MHz, ~ -2.5 dB @ 160MHz, and ~ -4.5dB @ 200MHz. The Square Wave Rise Time is about 4.1 ns, so I’m happy about that
----------------------------------------------------------
@screensaver - no issues for me - tried with FW 03, 06 and 07 - i doubt the mod interferes with the screensaver in any way.
@flatness - you will probably have to do a manual cal -> pw is 2010 - im no expert on that matter, but a Vrms meter should be sufficient, it seems to output different sines at different offsets/frequencies and expects you to correct the values shown in the tables - some of the tables are actually called "flatness" - so i would assume thats what can be used to tune it up to 160MHZ if not 200MHZ.
----------------------------------------------------------
cybernet:
I installed the DG4162 patch CEN and the freq. response is the same at 100MHz, 120MHz, and 160MHz as above with the DG4202 configuration. Thank you for the information on the Calibration with the PW. I will be looking into Cal. next. And BTW I'm not worried about the Screen Saver and agree that it is a separate issue not related to Turbocharging.
Thanks again for your assistance and all you have done for us all. It is truly awesome ! Cheers, Ted
cybernet, or anyone else:
Do you know where I can get a DG4000 calibration procedure, or at least a description of the meanings for the various calibration points?
Any clues about the calibration would be helpful and appreciated. I have the resources to accomplish it after I find some details/clues about it.
The PW you provided cybernet did allow me access to the Manual Cal. pages. Thank you.
cybernet, or anyone else:
Do you know where I can get a DG4000 calibration procedure, or at least a description of the meanings for the various calibration points?
Any clues about the calibration would be helpful and appreciated. I have the resources to accomplish it after I find some details/clues about it.
The PW you provided cybernet did allow me access to the Manual Cal. pages. Thank you.
not that i know of, and i doubt rigol will share it for that purpose ;-)
but the way i understood it is u just check the tables, it will do a measurement internally - you do one externaly, fix the value - and thats it.
there is also the "factory" button which seens to reset it - i fu**ed around out of curiosity with the tables, then it was off badly, and i just reset it back to normal.
the parnoid ones could always write down the old values ... no fear
and on the heels of that - there is a calibration file format that can be loaded like the CEN files, which is probably what rigol uses to do an inital calibration. so if somebody WOULD get sane values for a 160/200MHZ upgraded one, i might look into the file format to make that available easily to the rest. (depends on time on my end) - would save some measurement and type in sessions ....
and on the heels of that - there is a calibration file format that can be loaded like the CEN files, which is probably what rigol uses to do an inital calibration. so if somebody WOULD get sane values for a 160/200MHZ upgraded one, i might look into the file format to make that available easily to the rest. (depends on time on my end) - would save some measurement and type in sessions ....
I have a DG4162, so its calibration values should be sane to at least 160MHz. I haven't compiled your code yet but thank you all the same for sharing your brilliant reverse engineering work.
and on the heels of that - there is a calibration file format that can be loaded like the CEN files, which is probably what rigol uses to do an inital calibration. so if somebody WOULD get sane values for a 160/200MHZ upgraded one, i might look into the file format to make that available easily to the rest. (depends on time on my end) - would save some measurement and type in sessions ....
I have a DG4162, so its calibration values should be sane to at least 160MHz. I haven't compiled your code yet but thank you all the same for sharing your brilliant reverse engineering work.
when u are very bored, maybe u could share that values with us ... (i know its a lot of work ...) - but i would be willing to test them on my DG4062 and see if it improves flatness/specs .. if so i'd look into file format for calibration files.
Thanks for your work cybernet. (I'm not planning to use it unless I really need more than 100Mhz)
If upgraded from 60Mhz does it also need recalibration for frequencies up to 60Mhz?
Did someone do several measurements before and after? (for below 60Mhz)
Subject: Getting a newer FPGA version for DG4000.
I have a new DG4000 that I just received a week ago, but I have been seeing posts from people with older units that have more current software/firmware.
This is my 'System Info': Device Model - DG4062, Serial Number - DG4D152xxxxxx, Software (I believe we generally refer to this as Firmware (?) ) - 00.01.06.00.02, FPGA* - 00.01.07.09, Hard - 01.03, Keyboard - 05.01, and Enc FPGA – 06
My concern is with the FPGA* version, which for me is 00.01.07.09, because I see that some other owners have version 00.01.08.xx. Is there anyway for me to upgrade to the FPGA version 00.01.08.xx? Is the FPGA Firmware every included, or is it even possible to be provided along with a newer Software/Firmware version from Rigol?
Subject: Getting a newer FPGA version for DG4000.
I have a new DG4000 that I just received a week ago, but I have been seeing posts from people with older units that have more current software/firmware.
This is my 'System Info': Device Model - DG4062, Serial Number - DG4D152xxxxxx, Software (I believe we generally refer to this as Firmware (?) ) - 00.01.06.00.02, FPGA* - 00.01.07.09, Hard - 01.03, Keyboard - 05.01, and Enc FPGA – 06
My concern is with the FPGA* version, which for me is 00.01.07.09, because I see that some other owners have version 00.01.08.xx. Is there anyway for me to upgrade to the FPGA version 00.01.08.xx? Is the FPGA Firmware every included, or is it even possible to be provided along with a newer Software/Firmware version from Rigol?
there is some fpga firmware in the GEL file, but could be for display or keyboard FPGA - and there is a dedicated file format header for FPGA only upgrades (might used in factory), but nobody has such a file.
Subject: Getting a newer FPGA version for DG4000.
I have a new DG4000 that I just received a week ago, but I have been seeing posts from people with older units that have more current software/firmware.
This is my 'System Info': Device Model - DG4062, Serial Number - DG4D152xxxxxx, Software (I believe we generally refer to this as Firmware (?) ) - 00.01.06.00.02, FPGA* - 00.01.07.09, Hard - 01.03, Keyboard - 05.01, and Enc FPGA – 06
My concern is with the FPGA* version, which for me is 00.01.07.09, because I see that some other owners have version 00.01.08.xx. Is there anyway for me to upgrade to the FPGA version 00.01.08.xx? Is the FPGA Firmware every included, or is it even possible to be provided along with a newer Software/Firmware version from Rigol?
there is some fpga firmware in the GEL file, but could be for display or keyboard FPGA - and there is a dedicated file format header for FPGA only upgrades (might used in factory), but nobody has such a file.
I installed FW update 00.01.07.00.03 with some hesitation due to it having a couple serious bugs, but I decided that it would be worth it to find out if it had a FPGA update embedded in it or not. It did, now I have Software Ver. 00.01.07.00.03, as well as FPGA Ver. 00.01.08.03. So now I'm happy to have my unit up to date. I'll just wait for Rigol to release the next version of software to correct the flaws in 07.
Thank for getting back to me, as it was what you said that helped me decide to go ahead and install the current 07 GEL knowing it has issues. By the way Rigol says that the current version is 06, and this must be because they don't want more owners to upgrade into a flawed version that they are working on to correct. This of course is my interpretation of why they say 06 is the current version.
Thanks 'cybernet'
Reference below for info on Software 07 bugs:
Re: Rigol DG4xxx ppulse and npulse
« Reply #5 on: October 22, 2013, 09:25:30 PM »
Quote
Yes, Rigol just confirmed it is a bug, I'll post here when they come up with the fix.
just reversed the crc on the firmware files for the DG4000 ;-)
its actually a packaging format, that contains multiple segments which get loaded into the flash then (the loader addresses are still a bit off) anyhow i attach a link to the splitted files.
the big 2MB file is the main code - u can load it into LDRViewer and it dismantle it without a hitch, other stuff are help system files, etc ..
so theoretically it should now be possible to modify code, stuff it back together, crc it - and flash it ;-)
http://www.filedropper.com/dumpfilestar./gelfile ./DG4000Update.GEL
hdr_buf: RIGOL:DG4:UPDATE FILE ALL
fwr: CRC:7A57 ADDR:20040000 LEN:00228EF0 00000004 00000004
-> dumped dump_20040000.bin (2264816 bytes)
fwr: CRC:8CE7 ADDR:20300000 LEN:000C3DF6 00000008 00000008
-> dumped dump_20300000.bin (802294 bytes)
fwr: CRC:8C44 ADDR:20400000 LEN:00001661 00000008 00000008
-> dumped dump_20400000.bin (5729 bytes)
fwr: CRC:0611 ADDR:20440000 LEN:00000252 00000010 00000010
-> dumped dump_20440000.bin (594 bytes)
fwr: CRC:8845 ADDR:20440400 LEN:00002855 00000010 00000010
-> dumped dump_20440400.bin (10325 bytes)
fwr: CRC:D973 ADDR:20443400 LEN:00000252 00000010 00000010
-> dumped dump_20443400.bin (594 bytes)
fwr: CRC:BDC8 ADDR:20443800 LEN:000019FE 00000010 00000010
-> dumped dump_20443800.bin (6654 bytes)
fwr: CRC:8570 ADDR:20460000 LEN:00000206 00000010 00000010
-> dumped dump_20460000.bin (518 bytes)
fwr: CRC:3CB3 ADDR:20460400 LEN:0000F081 00000010 00000010
-> dumped dump_20460400.bin (61569 bytes)
fwr: CRC:D5A9 ADDR:2046FC00 LEN:00000206 00000010 00000010
-> dumped dump_2046fc00.bin (518 bytes)
fwr: CRC:0259 ADDR:20470000 LEN:000091B6 00000010 00000010
-> dumped dump_20470000.bin (37302 bytes)
fwr: CRC:219D ADDR:205B0000 LEN:00169DE8 00000020 00000020
-> dumped dump_205b0000.bin (1482216 bytes)
fwr: CRC:A299 ADDR:207B0000 LEN:0003D6C4 00000040 00000040
-> dumped dump_207b0000.bin (251588 bytes)
fwr: CRC:63BD ADDR:20830000 LEN:0004BB9C 00000040 00000040
-> dumped dump_20830000.bin (310172 bytes)
fwr: CRC:0000 ADDR:209B0000 LEN:00480000 00000080 00000080
-> dumped dump_209b0000.bin (2097152 bytes)
-> dumped dump_20bb0000.bin (2097152 bytes)
-> dumped dump_20db0000.bin (524288 bytes)