I'm not sure how to start it though. The start command is close to other UI stuff, and the string "Enter Project mode" is used close to it. I could imagine there is something like a maintanance menu we don't know about yet.
Notice, that rigol/resource/menu/msg.h defines a rather complete set of command messages. Say for example
#define MSG_HISTO_STATISEN 17670
For example rigol/resource/scpi/HISTogram.xml
<TotalItem>
<head>^(:?HISTogram|:?HIST)(:STATic|:STAT)\?$</head>
<service>histo</service>
<cmd>17670</cmd>
<minSize>-1</minSize>
<indexes>
<i>1</i>
</indexes>
<unit>
</unit>
</TotalItem>
One of these codes is
#define MSG_APP_UTILITY_PROJECT 12073
which is unfortunately not mapped, but might be somewhere in appEntry.
I believe you are right. I did not notice earlier, but rootfs/etc/init.d/rcS was modified such that sshd is not run.
-/usr/sbin/sshd
+#/usr/sbin/sshd
So we just unpack the GEL, edit that file, repack it, back to business as usual?
Welcome! May I ask what tools you use for disassembly?
Thank you! I'm using Binary Ninja right now.
I believe the license checking function is at 0x0041801c. It seems to set r0 to #0x1 if the user owns the requested license.
At least that's what the -fullopt flag did in the previous versions.
I believe the license checking function is at 0x0041801c. It seems to set r0 to #0x1 if the user owns the requested license.
At least that's what the -fullopt flag did in the previous versions.
It should be easy to mod that to "ld r0,#1; ret;" (or whatever the local assembly language is) to get all options.
Hacking an MSO5000 would then be as easy as inserting a USB stick and pressing "OK".
I would guess so. Still waiting for the scope to be delivered. You can also use oliv3r's packer I think: https://gitlab.com/riglol/rigolee/#gel-packer
But I'm not sure if this is tested at all.
If there is any packer that works, it's this one! Older ones will not work because this .GEL is completely different.
Thank you! I'm using Binary Ninja right now.
I believe the license checking function is at 0x0041801c. It seems to set r0 to #0x1 if the user owns the requested license.
At least that's what the -fullopt flag did in the previous versions.
Thanks for the hint, that is indeed a nice tool! I believe you are right and it makes it is super easy to patch it such that it only ever returns 1.
Patch for 01.01.04.04 to always return 1
Superseeded by later work.
EDIT: Just got my scope from Batronix. Comes with firmware 00.01.01.02.03. I would have expected them to ship with the new "unhackable" firmware. However, ,aybe they did not want everyone to return them directly.
EDIT2: I tried an intermediate update to 00.01.01.02.06, and now ssh is gone?! Strange....
EDIT3: Darn, that firmware also already kills sshd, even though it is from December last year! So I effectively shut myself out for now. BTW, the build script is not far enought to repackage the modified file system.
I tried an intermediate update to 00.01.01.02.06, and now ssh is gone?! Strange....
Yes, 00.01.01.02.06 was the first version having the the start of the ssh daemon commited away in /etc/init.d/rcS
You could try an earlier version or be the first person to try oliv3r's packer
Or did someone already test the packaging function?
EDIT: Oh okay, I guess downgrading is not possible?
Yes, 00.01.01.02.06 was the first version having the the start of the ssh daemon commited away in /etc/init.d/rcS
You could try an earlier version or be the first person to try oliv3r's packer
Or did someone already test the packaging function?
Anyways. I don't know if downgrading is a good idea with calibration data and such. I think i also saw a check against it in fw4linux.sh.
oliv3r's packer will only do the firmware flash encryption (so i could batch out the downgrade stop). It will not generate the image files etc.
Why downgrade??? Don't you want to upgrade with a hacked version?
Worry about repacking the new GEL and your problems will be over.
Since none of these versions change the bootloader, you can do all the harm that you want and there will always be a safe exit.
I wanted to first backup the calibration data. I have patched 01.01.02.04 such that it will downgrade now. I'm back in
@Oliv3r, I had to add --owner=rigolee --group=rigolee to the tar commands.
I'm back in
congratulation
So next step is to pack the rootfs/rigol folder as an UBIFS image
Very nice job!!
Did you change anything else for the licenses to also appear in the options list?
Btw, the appEntry also seems to have support for (jitter) eye diagrams..
I just changed the option list view to always show forever
. Easy to find when looking for "Forever". So its just a visual thingy. I also noticed eye diagrams, but I thought it is just that different color scheme.
A patch for the current version, which makes it look and feel like full options. Obviously untested until we can pack the GEL files:
superseded by later work
EDIT: Note, that there is also a BW07T5 option in the file, while the highest option shown is BW07T3....
Anyways. I don't know if downgrading is a good idea with calibration data and such.
I wanted to first backup the calibration data.
Ummm... isn't that what self-cal is for - to generate some
new data?
In fact I just did the quivalent patch to the old appEntry as mentioned before - and behold, all features are there without -fullopt Many thanks go to piskers for finding the function and pointing me to the right direction.
This means hacking is now as easy as inserting a USB key and pressing "Go!" (or whatever it says on screen).
No need to mess around with SSH or Vi.
Since none of these versions change the bootloader, you can do all the harm that you want and there will always be a safe exit.
And an easy way to de-hack it if it ever has to go back under warranty.
This means hacking is now as easy as inserting a USB key and pressing "Go!" (or whatever it says on screen).
No need to mess around with SSH or Vi.
Once we can create the update files. I'm not the best in shell scripts, so somebody else might be faster. Oliv3r?
Since none of these versions change the bootloader, you can do all the harm that you want and there will always be a safe exit.
And an easy way to de-hack it if it ever has to go back under warranty.
That actually true? I was not aware we can run the u-boot flash script without soldering, can we? Also, it flashes the current version numbers into u-boot configuration, which we can obviously disable for our package.
Could someone run mtdinfo /dev/mtd0
on the device so that we know the parameters for packing of the UBI image?
EDIT: Actually /dev/mtd6 and /dev/mtd10 just to be sure
Could someone run mtdinfo /dev/mtd0
on the device so that we know the parameters for packing of the UBI image?
EDIT: Actually /dev/mtd6 and /dev/mtd10 just to be sure
Sure, if it existed... Need to find some binary first....
EDIT:
Used an arml library from debian.
<root@rigol>/user/mtdinfo --all --ubi-info
Count of MTD devices: 13
Present MTD devices: mtd0, mtd1, mtd2, mtd3, mtd4, mtd5, mtd6, mtd7, mtd8, mtd9, mtd10, mtd11, mtd12
Sysfs interface supported: yes
mtd0
Name: Env
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 2 (262144 bytes, 256.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:0
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd1
Name: DATA
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 512 (67108864 bytes, 64.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:2
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd2
Name: Bmp
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 32 (4194304 bytes, 4.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:4
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd3
Name: Bmp1
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 32 (4194304 bytes, 4.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:6
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd4
Name: Bit1
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 64 (8388608 bytes, 8.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:8
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd5
Name: Sys1
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 256 (33554432 bytes, 32.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:10
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd6
Name: App1
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 800 (104857600 bytes, 100.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:12
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd7
Name: Bmp2
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 32 (4194304 bytes, 4.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:14
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd8
Name: Bit2
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 64 (8388608 bytes, 8.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:16
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd9
Name: Sys2
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 256 (33554432 bytes, 32.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:18
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd10
Name: App2
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 800 (104857600 bytes, 100.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:20
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd11
Name: Reserved
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 536 (70254592 bytes, 67.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:22
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
mtd12
Name: User
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 4800 (629145600 bytes, 600.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 2048 bytes
OOB size: 64 bytes
Character device major/minor: 90:24
Bad blocks are allowed: true
Device is writable: true
Default UBI VID header offset: 2048
Default UBI data offset: 4096
Default UBI LEB size: 126976 bytes, 124.0 KiB
Maximum UBI volumes count: 128
EDIT2: Rerun with --ubi-info
Thank you!
So packaging should be possible with:
mkfs.ubifs -m 2048 -e 128KiB -c 800 -r /rootfs/rigol app.img
Not sure about the compression type (-x param)..
Then gzip it and run oliv3r's script. Can't try it till tomorrow though..
Thanks! There is also
https://github.com/jrspruitt/ubi_reader which claims to be able to provide the proper information based on the image.
This results in:
ubireader_utils_info app.img
Volume app
alignment -a 1
default_compr -x lzo
fanout -f 8
image_seq -Q 329026723
key_hash -k r5
leb_size -e 126976
log_lebs -l 5
max_bud_bytes -j 8388608
max_leb_cnt -c 825
min_io_size -m 2048
name -N app
orph_lebs -p 1
peb_size -p 131072
sub_page_size -s 2048
version -x 1
vid_hdr_offset -O 2048
vol_id -n 0
#ubinize.ini#
[app]
vol_name=app
vol_size=98660352
vol_flags=autoresize
vol_type=dynamic
vol_alignment=1
vol_id=0
Which they claim maps to
/usr/sbin/mkfs.ubifs -m 2048 -e 126976 -c 825 -x lzo -f 8 -k r5 -p 1 -l 5 -r $1 img-329026723_0.ubifs
/usr/sbin/ubinize -p 131072 -m 2048 -O 2048 -s 2048 -x 1 -Q 329026723 -o img-329026723.ubi img-329026723.ini
The attached fill looks like an update but just executes sshd
So it will enable SSH on all scopes, but will never break anything.
Forum does not allow GEL, so remove the .txt file ending.
EDIT: Note, it will look like the upgrade failed, but no worries you will have ssh. The change is not permanent and ssh will be gone after reboot.
My previous patch works for the latest firmware
So we could even build a small upgrade script, which checks for the currently installed version, and applies a binary patch to appEntry.
Wow
I understand nothing about, but.....wow