Hacking the Rigol DHO800/900 Scope

[AndyBig]

i imagine its something like DLL or drv? i have free ed IDA, so i can open a little bit exe or dll, but since its Linux/android i'm pretty much zero about how things work in those system.

Yes, .ko files are the Linux analogue of Windows .dll files, that is, dynamic libraries. IDA understands these files without problems, as does Ghidra.

[shapirus]

Yes, .ko files are the Linux analogue of Windows .dll files, that is, dynamic libraries.

.so.
.ko are kernel modules.

[norbert.kiszka]

Yes, .ko files are the Linux analogue of Windows .dll files, that is, dynamic libraries.

.so.
.ko are kernel modules.

Exactly. .so are libs, and .ko are kernel modules.

it shouldnt be that hard to modify that module

Why You want to detonate already opened door? I posted HW number hack without module earlier. This module reads GPIO pins and creates char file with one byte. If You get rid of that module and create this file by hand, then You can have any HW number between 0 and 255.

[AceyTech]

Anyone following the config bits topic:  I don't know what they were thinking early times, but the RK3399 doesn't have Pin numbers like 4, 8, 11, 12 as shown in this early post:

It has BGA row/column naming.  Note: I notated the 0-3 bit pins(in pink) on this pic.

From the RK3399.  Those pins are pretty hard to get to, due to solder mask, etc on the back side., but I'm trying.  I need my zoom microscope!! (in storage, in another city)

@Mechatrommer  I measured those config resistors at 10k(in circuit).  Blank locations read 14-15k, IIRC.  Add.  BTW, those pins aren't any of the onboard ADCs, either. 
I haven't yet desoldered the resistors to confirm values.

Edit:;
As a good primer -- Take a look back to page 3 of this thread for the early GPIO bit discussions, including disassembly of the .ko files.
 Nothing much has really changed.  https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078335/#msg5078335

[AndyBig]

Yes, .ko files are the Linux analogue of Windows .dll files, that is, dynamic libraries.

.so.
.ko are kernel modules.

Yes, I could have made a mistake with the type of these files. So this is an analogue of Windows drivers? In any case, they can be disassembled as .dll or .exe

[norbert.kiszka]

Yes, .ko files are the Linux analogue of Windows .dll files, that is, dynamic libraries.

.so.
.ko are kernel modules.

Yes, I could have made a mistake with the type of these files. So this is an analogue of Windows drivers? In any case, they can be disassembled as .dll or .exe

Some Linux modules are hardware drivers and some are doing other stuff.

[AceyTech]

The steps to modify your scope to remove your SDCard without breaking the seal, or removing any screws. 
Upper left side, looking through the vent slots.

Flush cutters for snipping the slot ribs.  These are flat on one side, and it's pretty important for this mod.


Yours should have tape covering your card. FYI: I doubt this would work if it's hot glued like early units.


Cut a piece of thin "blister packaging" plastic that products are often packed in.  I cut mine 25mm or 1" long, and a little smaller than the card width.


Count the ribs and snip the three ribs shown with the first cut on the bottom of each rib(flat side down, against the metal frame).  Then turn cutters over and cut 2mm up(flat side up), and discard the waste clipping. -you probably don't want it inside your scope, clip it slowly!

You need to take the tape off your card.  Xacto knife, maybe?  My tape was gone already, but you can cut it against the metal part, then flick it up over the card and card holder, and/or remove with tweezers.  Don't cut into the PCB or card.  Be careful.


Attach the plastic tab to the card with double sided tape(thin and really sticky, preferred) I used UV glue 'cuz it's awesome.  I've also tried gluing the tab to the bottom of the card, and it works well because of the flat side. (you'll see.)
You may also use a tiny amount of "crazy" cyanoacrylate glue. (hint: start small, and apply to plastic part first, before attaching to card.)
BTW: please do not use your original card


Mine sticks out 5mm, or slightly less than 1/4".  You could probably trim it more if you use tweezers.

Notes:
  A:  The plastic has to be stiff enough to actuate the push in/out mechanism of the card reader, but thin enough to go in the card reader
  B:  If you do this mod, do so at your own risk., yada yada.  This might void your Warranty.
  C:  You're working with a backup card, right?
  D:  Don't cut your Card, PCB or yourself(-it makes your work area messy) with xActo.
  E:  You might be able to "cut the ribs" with a blade tip on your soldering iron

Final view:


Stay tuned, I have a few more of these types of projects in mind.

[Mechatrommer]

Why You want to detonate already opened door? I posted HW number hack without module earlier. This module reads GPIO pins and creates char file with one byte. If You get rid of that module and create this file by hand, then You can have any HW number between 0 and 255.

iirc you mentioned anyone can put it in any file we like. can i put it in autoexec.bat and push to rigol/shell? my point is your instruction was not clear enough.

Anyone following the config bits topic:  I don't know what they were thinking early times, but the RK3399 doesn't have Pin numbers like 4, 8, 11, 12 as shown in this early post:

i traced the pins from datasheet to be underside of RK3399

From the RK3399.  Those pins are pretty hard to get to, due to solder mask, etc on the back side., but I'm trying.  I need my zoom microscope!! (in storage, in another city)

do you see exposed vias on the back? if yes how would you know this via for what pin? you'll need xray to make sure of that. if they use blind via, traces could go somewhere else from inside layer.

As a good primer -- Take a look back to page 3 of this thread for the early GPIO bit discussions, including disassembly of the .ko files.
 Nothing much has really changed.  https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078335/#msg5078335

why hasnt much changed? because it is difficult to do? btw as i understand, in gpio_hdcode_drv_read, the module is reading actually HW pin right? why hasnt somebody modified it to read from a file let say in rigol/shell/autoexec.bat? create a simple guide to do so, push the modified gpio_hdcode_drv_read, make autoexec.bat with number 8 inside and push it again... rather than "you could make any file anywhere?" that will open up a can of puzzless for newbies like me

[AceyTech]

Anyone following the config bits topic:  I don't know what they were thinking early times, but the RK3399 doesn't have Pin numbers like 4, 8, 11, 12 as shown in this early post:

i traced the pins from datasheet to be underside of RK3399

From the RK3399.  Those pins are pretty hard to get to, due to solder mask, etc on the back side., but I'm trying.  I need my zoom microscope!! (in storage, in another city)

do you see exposed vias on the back? if yes how would you know this via for what pin? you'll need xray to make sure of that. if they use blind via, traces could go somewhere else from inside layer.

Yes, I've been following your work, tracing those signals.  I have not seen any vias/signals with exposed copper.  They have soldermask over almost everything.  However, I have some very nice, sharp probes to scratch thru it. 
After looking at the PCB last night in person, it looks pretty difficult, but it's only 4 GPIO pins.   It would be much easier with a microscope.

Side note: How many layers do you think this PCB is?   

As a good primer -- Take a look back to page 3 of this thread for the early GPIO bit discussions, including disassembly of the .ko files.
 Nothing much has really changed.  https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078335/#msg5078335

why hasnt much changed? because it is difficult to do? btw as i understand, in gpio_hdcode_drv_read, the module is reading actually HW pin right? why hasnt somebody modified it to read from a file let say in rigol/shell/autoexec.bat? create a simple guide to do so, push the modified gpio_hdcode_drv_read, make autoexec.bat with number 8 inside and push it again... rather than "you could make any file anywhere?" that will open up a can of puzzless for newbies like me

I made that statement, because in September last year, everyone on page 3 was discussing the GPIO pins, HDCODE, *.ko files, how it was being called, and they even disassembled the code.

(Important: I don't want to sound ungrateful)
Nothing became of the discovery or discussion., for whatever reason. 
And in human nature things tend to be cyclical., -and here we are almost 6 months later talking about it again.  I've noticed that several topics here get "re-hashed" when someone with bright ideas comes along that genuinely wants to make a difference.

I've been at this for 3 months, learning from the greats here(you are one of them) and I am not a coder, other than PIC micros.  I know better than try to disassemble & reassemble a big any sized software project.  So, I can't help in that regard., but I am trying to help where I can.

[AndyBig]

Side note: How many layers do you think this PCB is?   

I think at least 8. Maybe more. And it is unrealistic to reliably track which processor contacts these resistors go to without removing the processor.
Pin numbers (4, 8, 11, 12) are conditional numbering; it is converted into an indication of a physical pin by the gpio_to_desc() function. As far as I understand, when building the kernel, somewhere in the source code there is a file with a list of these numbers and the corresponding real pins, where the comparison comes from. Is it possible to somehow get this list from an already assembled kernel - I don’t know.

[norbert.kiszka]

Why You want to detonate already opened door? I posted HW number hack without module earlier. This module reads GPIO pins and creates char file with one byte. If You get rid of that module and create this file by hand, then You can have any HW number between 0 and 255.

iirc you mentioned anyone can put it in any file we like. can i put it in autoexec.bat and push to rigol/shell? my point is your instruction was not clear enough.

This is not a Windows and not a DOS. Put it into /rigol/shell/start_rigol_app.sh

Side note: How many layers do you think this PCB is?   

I think at least 8. Maybe more. And it is unrealistic to reliably track which processor contacts these resistors go to without removing the processor.
Pin numbers (4, 8, 11, 12) are conditional numbering; it is converted into an indication of a physical pin by the gpio_to_desc() function. As far as I understand, when building the kernel, somewhere in the source code there is a file with a list of these numbers and the corresponding real pins, where the comparison comes from. Is it possible to somehow get this list from an already assembled kernel - I don’t know.

Decompiled hdcode_gpio.ko:

Code: [Select]

int init_module(void * name, void * image) {
    r0 = name;
    saved_fp = r29;
    stack[-24] = r30;
    r31 = r31 + 0xffffffffffffffe0;
    r29 = &saved_fp;
    saved_regs_10 = r19;
    if ((misc_register(gpio_hdcode_dev, image) & 0xffffffff80000000) != 0x0) {
            r19 = gpio_hdcode_dev;
            r0 = printk("register spi2k7_gpio device failed!\n");
            r0 = 0xffffffff;
    }
    else {
            r0 = *0x958;
            r0 = devm_kmalloc(r0, 0x100, 0x24080c0);
            r0 = gpio_request(0x4, "hd_code0");
            r0 = gpio_to_desc(0x4);
            r0 = gpiod_direction_input();
            r0 = gpio_to_desc(0x4);
            r0 = gpiod_get_raw_value();
            r0 = printk("hd_code0 = %d\n", r0);
            r0 = gpio_request(0x8, "hd_code1");
            r0 = gpio_to_desc(0x8);
            r0 = gpiod_direction_input();
            r0 = gpio_to_desc(0x8);
            r0 = gpiod_get_raw_value();
            r0 = printk("hd_code1 = %d\n", r0);
            r0 = gpio_request(0xb, "hd_code2");
            r0 = gpio_to_desc(0xb);
            r0 = gpiod_direction_input();
            r0 = gpio_to_desc(0xb);
            r0 = gpiod_get_raw_value();
            r0 = printk("hd_code2 = %d\n", r0);
            r0 = gpio_request(0xc, "hd_code3");
            r0 = gpio_to_desc(0xc);
            r0 = gpiod_direction_input();
            r0 = gpio_to_desc(0xc);
            r0 = gpiod_get_raw_value();
            r0 = printk("hd_code3 = %d\n", r0);
            r0 = printk(" gpio_hdcode_dev register successfully\n");
            r0 = 0x0;
    }
    r19 = gpio_hdcode_dev;
    r19 = saved_regs_10;
    r29 = saved_fp;
    r30 = stack[-24];
    r31 = r31 + 0x20;
    return r0;
}

GPIO pins cant be read directly from app player. It has to be driver (kernel module) between.

Dmesg from my scope after loading hdcode_gpio.ko:

Code: [Select]

[ 1649.263220] hd_code0 = 0
[ 1649.263282] hd_code1 = 0
[ 1649.263300] hd_code2 = 0
[ 1649.263319] hd_code3 = 1
[ 1649.263327]  gpio_hdcode_dev register successfully

[norbert.kiszka]

Speaking of decompilation...

spi2pll_gpio.ko:

Code: [Select]

int spi_pll_write(int arg0, int arg1, int arg2) {
    r2 = arg2;
    r0 = arg0;
    saved_fp = r29;
    stack[-56] = r30;
    r31 = r31 + 0xffffffffffffffc0;
    r29 = &saved_fp;
    saved_regs_10 = r19;
    stack[-40] = r20;
    saved_regs_20 = r21;
    stack[-24] = r22;
    saved_regs_30 = r23;
    stack[-8] = r24;
    r22 = arg1;
    r19 = r2;
    r0 = _mcount(r30, arg1, r2);
    r20 = pll_read_write_data;
    asm { mrs        x0, sp_el0 };
    r1 = *(r0 + 0x8);
    r0 = r22 + r19;
    if (r0 < 0x0) {
            r20 = pll_read_write_data;
            asm { ccmp       x0, x1, #0x2, lo };
    }
    r20 = pll_read_write_data;
    if (CPU_FLAGS & BE) {
            r20 = pll_read_write_data;
            if (CPU_FLAGS & BE) {
                    r20 = pll_read_write_data;
                    r2 = 0x1;
            }
            r20 = pll_read_write_data;
    }
    r21 = *pll_read_write_data;
    if (r2 != 0x0) {
            r20 = pll_read_write_data;
            r0 = __check_object_size(r21, r19, 0x0);
            r1 = __arch_copy_from_user(r21, r22, r19);
    }
    else {
            r20 = pll_read_write_data;
            r0 = memset(r21, 0x0, r19);
            r1 = r19;
    }
    r20 = pll_read_write_data;
    r0 = 0xfffffffffffffff2;
    if (r1 == 0x0) {
            r0 = 0xfffffffffffffff2;
            r20 = pll_read_write_data;
            r21 = 0x0;
            r0 = printk("spi_pll_write : from user write: ");
            r22 = "%02x ";
            do {
                    r22 = "%02x ";
                    r20 = pll_read_write_data;
                    asm { sxtw       x0, w21 };
                    if (r19 <= r0) {
                        break;
                    }
                    r21 = r21 + 0x1;
                    r0 = printk("%02x ", *(int8_t *)(*pll_read_write_data + r0));
            } while (true);
            r22 = "%02x ";
            r21 = 0x0;
            r0 = printk("\n");
            r23 = *pll_read_write_data;
            r0 = _raw_spin_lock(0xa7c);
            r0 = loc_27c(0x6);
            r0 = __const_udelay(0x10c7);
            do {
                    r20 = spi_pll_master;
                    if (r19 <= r21) {
                        break;
                    }
                    r0 = *(int32_t *)dword_a74;
                    r22 = 0x7;
                    r24 = *(int8_t *)(r23 + r21);
                    r0 = loc_27c(r0);
                    do {
                            r20 = spi_pll_master;
                            if ((SAR(r24, r22) & 0x1) != 0x0) {
                                    r0 = *(int32_t *)dword_a78;
                                    r0 = _spi_pll_set_gpio_high();
                            }
                            else {
                                    r0 = *(int32_t *)dword_a78;
                                    r0 = loc_27c(r0);
                            }
                            r0 = *(int32_t *)dword_a74;
                            r22 = r22 - 0x1;
                            r0 = loc_27c(r0);
                            r0 = __const_udelay(0x10c7);
                            r0 = *(int32_t *)dword_a74;
                            r0 = _spi_pll_set_gpio_high();
                            r0 = __const_udelay(0x10c7);
                    } while (r22 != -0x1);
                    r0 = *(int32_t *)dword_a74;
                    r21 = r21 + 0x1;
                    r0 = loc_27c(r0);
            } while (true);
            r0 = __const_udelay(0x10c7);
            r0 = 0x6;
            r0 = _spi_pll_set_gpio_high();
            r0 = __const_udelay(0x10c7);
            r0 = loc_27c(0x6);
            r0 = __const_udelay(0x10c7);
            r0 = _raw_spin_unlock(0xa7c);
            r0 = 0x0;
    }
    r19 = saved_regs_10;
    r20 = stack[-40];
    r21 = saved_regs_20;
    r22 = stack[-24];
    r23 = saved_regs_30;
    r24 = stack[-8];
    r29 = saved_fp;
    r30 = stack[-56];
    r31 = r31 + 0x40;
    return r0;
}

libscope-auklet.so:

Code: [Select]

int DevAcquireSPU_SetSampleRate(int arg0, int arg1) {
    r0 = arg0;
    *(r31 + 0xffffffffffffffe0) = r19;
    var_20 = r29;
    stack[-8] = r30;
    r29 = &var_20;
    r19 = arg1;
    if (arg1 >= 0x3b9aca1) {
            r8 = 0x3b9aca1;
            r0 = sub_17f630();
            asm { udiv       x8, x0, x19 };
            r1 = 0x8000;
            asm { bfxil      w1, w8, #0x0, #0x8 };
            r19 = 0x1;
    }
    else {
            r8 = 0x3b9aca1;
            r8 = 0x3b9aca0;
            r1 = 0x0;
            asm { udiv       w19, w8, w19 };
    }
    r0 = 0x10d0;
    r0 = sub_176e80();
    r0 = 0x10d8;
    r1 = r19;
    r0 = sub_176e80();
    r29 = var_20;
    r30 = stack[-8];
    r0 = 0x10d4;
    r1 = 0x0;
    r19 = var_30;
    r0 = sub_176e80();
    goto .l1;

.l1:
    r1 = 0x0;
    return r0;
}
0x3b9aca0 = 62500000.

[Mechatrommer]

step by step guide which screws to unscrew to open dho pcb: see attached... i guess some people still afraid to do this? to snap photo, to mod etc...

if you want to remove heatsink, do unscrew as in picture 2.jpg/ if you dont want to remove heatsink, only access to the underside of pcb, only unscrew as in 2b.jpg

about heat pads.. while lifting heatsink, dont remove heat pads, leave them be where they are, if they stick to the IC, leave them like that, if they stick to heatsink, leave them like that. attaching heatsink again, will attach them all back together... if you really need to lift the heatpads, do it carefully as they are soft and easily broken... there is no glue or paste sticking them to the IC, only oil... fwiw..

tools needed T10 head screwdriver and a plier (to unscrew BNC hex nut) fwiw...

[Mechatrommer]

As a good primer -- Take a look back to page 3 of this thread for the early GPIO bit discussions, including disassembly of the .ko files.
 Nothing much has really changed.  https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5078335/#msg5078335

if souldevelop's report is correct... i just did some photoshop fun (attached) to find where are the 25AA, 28U, 30U, 26V pins are, somewhere in red circle... based on possible closest route, another candidate for config resistor could be in yellow circle.. we went through the blue circle fun be warned you could damage something if not careful...

otoh i dont tend to do your sd card mod. possibly one day this thing is fixed whether in HW or SW, so we dont need to switch sd card anymore, so you'll be left with irreversible cutted top enclosure for no good reason. not a big deal really.

edit: another possible trap is that by modding HW ver from 12 (DHO800) to 8 (DHO900) its possible FW will activate reading the unpopulated DDR3 RAM, another mess if its really happens. ymmv.

[norbert.kiszka]

If those GPIO pins are 0/1, then it will be easier to solder thin wire, put outside, connect some dip-switch and test combinations (dmesg or/and app).

[Mechatrommer]

based on possible closest route, another candidate for config resistor could be in yellow circle.. we went through the blue circle fun be warned you could damage something if not careful...

edit: another possible trap is that by modding HW ver from 12 (DHO800) to 8 (DHO900) its possible FW will activate reading the unpopulated DDR3 RAM, another mess if its really happens. ymmv.

udało się! will try next what will happen to LA probing..

[ebastler]

Nice! Can you trigger on digital signals now?

[Randy222]

If those GPIO pins are 0/1, then it will be easier to solder thin wire, put outside, connect some dip-switch and test combinations (dmesg or/and app).

They are 0 or 1 . But bigger question is, are they OUT or IN pins ? They show as IN pins, which to me suggests those pins are internally pulled down and the resistors connect to 3.3v to provide the "1" in the 4bit code for HW number.

I can't seem to direct data into the hdcode gpio char device, because when I unload the ko module the kernel remove hdcode_gpio from device tree.

However, with the ko module in kernel, I get arg error when trying to direct hex 8 to the hdcode char device in /dev

The two pics are with ko module, and without ko module. It appears the ko module reads those gpio.
My 804 is 1100 = 12

After unload ko module I then did a "am restart" and rigol scope showed "0" as HW number.

I suspect it's truly hardware config bound.

[norbert.kiszka]

udało się!

Is this Polish language?

Did You test my way of changing HW number?

If those GPIO pins are 0/1, then it will be easier to solder thin wire, put outside, connect some dip-switch and test combinations (dmesg or/and app).

They are 0 or 1 . But bigger question is, are they OUT or IN pins ? They show as IN pins, which to me suggests those pins are internally pulled down and the resistors connect to 3.3v to provide the "1" in the 4bit code for HW number.

I can't seem to direct data into the hdcode gpio char device, because when I unload the ko module the kernel remove hdcode_gpio from device tree.

However, with the ko module in kernel, I get arg error when trying to direct hex 8 to the hdcode char device in /dev

The two pics are with ko module, and without ko module. It appears the ko module reads those gpio.
My 804 is 1100 = 12

After unload ko module I then did a "am restart" and rigol scope showed "0" as HW number.

I suspect it's truly hardware config bound.

Because its one byte file. I told it before. Its a binary number - unsigned char. Why You are doing research which I have done it and posted it here before?

[norbert.kiszka]

If somebody wants to play with HW number, there is simpler way, than I wrote before.

Code: [Select]

printf '\x8' > /dev/hdcode_gpio
Of course, get rid of hdcode_gpio module first, by unloading it (rmmod hdcode_gpio) and commenting it out in /rigol/shell/start_rigol_app.sh - above command can go into this file (personally I did it at very beginning).

I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?

[Mechatrommer]

I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?

because we dont have a clue where to put it... maybe later as we gain comprehension. i guess what you meant is editing start_rigol_app.sh and pushing it back again? will sure try later.

[Mechatrommer]

for HW mod from 12 to 8 by luck and brainstorming in this thread... i found a way.. there's another place on the side for config resistor (see attached), before modding, i measure resistance, exactly same thing as before, parallel resistor measured 6Kohm, single resistor measured 10Kohm, so it seems coincidence, why not try? i tried 3 combinations to get what i want (see attached) most significant bit is the topmost resistor in pcb picture below (pcb shows original HW 12 resistor setup).

and in this video, i now can trigger on digital channel (on original HW 12 i cant) so the conclusion is, there is/are differences in FW execution based on HW number. fwiw...
edit: done doing scope's CH calibration on the hacked HW ver scope showing no offset issue... 



cheers.

[norbert.kiszka]

I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?

because we dont have a clue where to put it... maybe later as we gain comprehension. i guess what you meant is editing start_rigol_app.sh and pushing it back again? will sure try later.

You can put it into start_rigol_app.sh or execute it manually in a shell and after that execute /rigol/shell/restartScope.sh

Dont forget to comment out insmod to prevent loading this module.

In my case changing this value doesnt change anything. Or I didnt catch the change.

BTW. chmod can be changed to 444 (read only) and it still works. Most likely some Rigol developer was lazy and (s)he put just 777...

[Mechatrommer]

I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?

because we dont have a clue where to put it... maybe later as we gain comprehension. i guess what you meant is editing start_rigol_app.sh and pushing it back again? will sure try later.

You can put it into start_rigol_app.sh or execute it manually in a shell and after that execute /rigol/shell/restartScope.sh

Dont forget to comment out insmod to prevent loading this module.

In my case changing this value doesnt change anything. Or I didnt catch the change.

BTW. chmod can be changed to 444 (read only) and it still works. Most likely some Rigol developer was lazy and (s)he put just 777...

sounds easy for you, but not for me... i'll cope with this later. cheers.

[norbert.kiszka]

I dont get it why all of You like to waste time, if I posted easier way to hack exactly same thing?

because we dont have a clue where to put it... maybe later as we gain comprehension. i guess what you meant is editing start_rigol_app.sh and pushing it back again? will sure try later.

You can put it into start_rigol_app.sh or execute it manually in a shell and after that execute /rigol/shell/restartScope.sh

Dont forget to comment out insmod to prevent loading this module.

In my case changing this value doesnt change anything. Or I didnt catch the change.

BTW. chmod can be changed to 444 (read only) and it still works. Most likely some Rigol developer was lazy and (s)he put just 777...

sounds easy for you, but not for me... i'll cope with this later. cheers.

Adding one line and removing other one (or commenting it via # at beginning) into text file is not that difficult.

Speaking of beginning. Dont touch first line:

Code: [Select]

#!/system/bin/bash
Because its a magic data to tell kernel or shell, which app should execute this script. Add any code anywhere after that.

BTW. We can see how crazy changes (including /system folder) was made to make Android from GNU/Linux. In GNU for many years it was good & simple and they changed that - because they can...