Author Topic: Rigol DSXXXX .GEL firmware file format (Read 64135 times)

Macbeth · « **Reply #100 on:** July 26, 2016, 12:28:34 am »

It's amusing to see this firmware .GEL cracking. I don't have a DSXXXX but I do have a DM3058 and its firmware is in an unencrypted format.

Much like this thread I have memory mapped lots of plain text strings, private storage for calibration data, found plenty of instances of obvious IEEE floating points. I've also found all the large and small character maps for English and Chinese characters.

I have an unhealthy reason for this, because I used Rigols Ultrasensor software and it bricked my DM3058. Long story, but I didn't trust sending it back to them for unbricking and then using Ultrasensor again and bricking it all over.

I learned how to JTAG program it myself. Now I want to use it as a testbed to learn IDA with Blackfin. But then again I keep finding something better to do!

laj · « **Reply #101 on:** July 26, 2016, 09:57:40 am »

Quote from: smithnerd on July 23, 2016, 04:33:05 pm

I've been looking at SparrowBootloader.sb with this:

https://github.com/eewiki/elftosb

Code: [Select]
$ ./sbtool SparrowBootloader.sb ---- Boot image header ---- Signature 1: STMP Signature 2: sgtl Format version: 1.1 Flags: 0x0000 Image blocks: 19764 First boot tag block: 9 First boot section ID: 0x00000000 Key count: 1 Key dictionary block: 7 Header blocks: 6 Section count: 1 Section header size: 1 Timestamp: 446216079000000 Product version: 999.999.999 Component version: 999.999.999 Drive tag: 0x0000 SHA-1 digest of header: 0x00000000: 2d 5c 14 b8 10 81 fe 5f ee e2 09 ee 75 55 fe 80 0x00000010: bb 35 50 44 Header digest is correct. ---- Section table ---- Section 0: Identifier: 0x0 Offset: 10 blocks (160 bytes) Length: 19752 blocks (316032 bytes) Flags: 0x00000001 0x1 = ROM_SECTION_BOOTABLE ---- Key dictionary ---- error: the image is encrypted but no key was provided
It should be encrypted with AES-128, the key for which is burned into the OTP area of the i.MX28. Hopefully though, it might only be using 'encrypted boot' mode and not the 'high assurance boot' mode.

Have a look at sbtool's "-z" option (Zero-Key)
As in "sbtool -V -d -z SparrowBootloader.sb" or "sbtool -V -d -b -x 0 -z SparrowBootloader.sb >sp.bin"

smithnerd · « **Reply #102 on:** July 26, 2016, 10:49:27 am »

Crikey.

janekivi · « **Reply #103 on:** July 26, 2016, 06:46:13 pm »

Of course You can use all the tools available in here, made by all of us.
(Yes, I forgot paper and pencil, I'm a big paper user overall)
I compiled with C this sbtool for windows, if anyone need.

~~win_sbtool.zip~~
It is acting funny and outcome is not correct.

laj · « **Reply #104 on:** July 27, 2016, 12:43:30 am »

Another alternative (on *nix) to sbtool from elftosb, is mxssb from uboot (at denx.de/mxssb.git)
below is a patch to let it extract the individual csf parts into raw bin dump's

Userli · « **Reply #105 on:** July 30, 2016, 12:17:16 pm »

I found that the version number in the individual file headers is not used.
One can change them without any effect.
I also exchanged the 2nd part of the footer, which was found identical in two versions by janekivi, by another one and the installation failed.
This shows that it is used when checking the file integrity.

Furthermore I managed to disassemble the ELF file in SparrowApp using Hex-Rays IDA demo.
It would be helpful to find the installation routine and maybe the integrity check.
Seeing the size of the code, this is by far not obvious.
Interesting is the string:
An older software version detected. Update?

smithnerd · « **Reply #106 on:** July 30, 2016, 09:40:36 pm »

The bootloader looks less daunting. It's only ~300k and it has much of the same upgrade functionality. Trouble is, the IDA demo can only read ELF files...

My current theory is that the second part of the footer is a cryptographic nonce or just an obfuscation (e.g. it gets XORed with the other half for the actual hash).

Edit:

Which is this (for 4.4.0.7):

Code: [Select]

$ hd footxor 
00000000  11 5a 11 39 f5 d6 0c d7  fd 99 26 24 7b 94 7c 52  |.Z.9......&${.|R|
00000010  1a b9 17 d0 c7 19 5f f2  2d 8a d4 8e 13 2f 54 05  |......_.-..../T.|
00000020  34 fd f8 c1 a5 0c 46 3f  4d df 23 e2 da 03 00 a4  |4.....F?M.#.....|
00000030  20 15 62 9a 98 7d 14 18  0d 90 c7 9b 9b 91 9d e6  | .b..}..........|
00000040  44 6a 90 2d 77 9a 1f 2e  4c 2c 9a 35 81 aa 62 40  |Dj.-w...L,.5..b@|
00000050  ff 17 55 f3 0b 52 0c af  ed a6 98 4c e9 88 1c a9  |..U..R.....L....|
00000060  a1 d4 a0 3a 3a b1 d5 12  9f 17 dd a7 ec cf c1 1c  |...::...........|
00000070  9b 4b 54 03 bc 7f 4b 8b  76 9d 0f 6a 38 ac c1 29  |.KT...K.v..j8..)|

janekivi · « **Reply #107 on:** July 31, 2016, 12:13:26 pm »

No no no
I think first 20 bytes is header and last 4 is footer and then You have 256 bytes to play with.
Where first 128 is something and last 128 is the same in at least two firmware files.

80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00 04 00 00 00
128 bytes
128 bytes
01 00 01 00

Or of course there is some other explanation...

Userli · « **Reply #108 on:** July 31, 2016, 05:25:42 pm »

I had a look at the bootloader binaries exported by sbtool.exe.
The 6 code parts are concatenated and each has the following format:
16byte header:
- uint8 checksum
- uint8 command type
- uint16 flags
- uint32 memory address
- uint32 length
- uint32 additional data
payload as given by length.

Looking at the 5th part, however, the length in the header says 0x49acc .
This would make that part end in the middle of a string section.
The next header starts at 0x04DFF1, which makes it more probable, that the part ends just before.
The first part shows the same: length given 0x3C, according to header position 0x40 .
Maybe a bug in sbtool?

Userli · « **Reply #109 on:** August 03, 2016, 05:43:05 pm »

I added the possibility to see the boot loader details to RigolPacker.
Furthermore you can now convert it to an ELF file, which you can then disassemble with IDA.
To do so, open the GEL file containing the bootloader.
Double click on /sys/SparrowBootloader.sb
In the new window click on "Convert to ELF"
In the next window click "save to file".
Now you can open this file in IDA.
Ignore the warning about invalid sections.

The new version is attached.

Userli · « **Reply #110 on:** August 04, 2016, 10:03:56 pm »

Cybernet refers in his post
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg265156/#msg265156
several times to AD.
Does anybody know what AD stands for?

smithnerd · « **Reply #111 on:** August 04, 2016, 10:40:31 pm »

Quote from: Userli on August 04, 2016, 10:03:56 pm

Cybernet refers in his post
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg265156/#msg265156
several times to AD.
Does anybody know what AD stands for?

Analog Devices.

janekivi · « **Reply #112 on:** August 06, 2016, 06:21:54 pm »

This is a notepad tutorial time again. Maybe in another thread this time.

Let's open latest DS1000Z-00.04.04.00.07 or DS1000Z-00.04.03.01.05 update file footer and start
analyzing it. File compare is good thing, so we put both of them side by side. After scrolling them
quickly up and down we see some pattern. If we concentrate our look into it we start seeing...
OK... nothing.
Let's take hex view from one of them. So, first 20 bytes are header I think:
80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00
04 00 00 00
Then comes 128 bytes strange code:
64 29 7F D9 1A C9 9B D5 74 5C 2B 8E A3 5E 57 7A
62 DF 99 D4 BA DC 33 FE F2 37 40 E8 78 71 12 E6
10 E9 B4 B4 B5 54 17 47 73 65 9D EB 5D 4F A1 10
3E CF 7E 43 35 A9 0B A8 28 1F A3 8D 26 F2 A4 0E
44 2B 67 F0 BE E1 A3 63 CA 9F 17 56 53 32 7A F4
F8 07 7F 8C 0D 91 A7 C9 8E 99 8B 22 A9 6D 4E 0D
BE 89 A2 56 A7 58 B6 C7 99 39 48 54 91 5A 11 39
F4 D6 0C D7 7D 99 26 24 7A 94 7C 52 1E B9 17 D0
Next is another not too strange 128 bytes:
A3 30 20 2B 37 43 4F 5B 67 73 7F 8B 97 A3 AF BB
C7 D3 DF EB F7 03 10 1C 28 34 40 4C 58 64 70 7C
88 94 A0 AC B8 C4 D0 DC E8 F4 00 0D 19 25 31 3D
49 55 61 6D 79 85 91 9D A9 B5 C1 CD D9 E5 F1 FD
4F 79 6B 5F 53 47 3B 2F 23 17 0B FF F2 E6 DA CE
C2 B6 AA 9E 92 86 7A 6E 62 56 4A 3E 32 26 1A 0E
02 F6 E9 DD D1 C5 B9 AD A1 95 89 7D 71 65 59 4D
41 35 29 1D 11 05 F9 EC E0 D4 C8 BC B0 A4 98 8C
At the end is footer:
01 00 01 00

Today we looking at the second part here:
A3 30 20 - 30 is "0" and 20 is "space" in ASCII but what is the next row of data?
A3 30 20 2B 37 43 4F 5B 67 73 7F 8B 97 A3 AF BB C7 D3 DF EB F7
03 10 1C 28 34 40 4C 58 64 70 7C 88 94 A0 AC B8 C4 D0 DC E8 F4
00 0D 19 25 31 3D 49 55 61 6D 79 85 91 9D A9 B5 C1 CD D9 E5 F1 FD
If we start from 20 - add 0B - you got next, then add 0C - got next and next and next...
Next row 03 is 0103 if we add 0C to F7 and maybe 01 is added to the next, so:
now we add 0D to the 03 - got 10, then add 0C - got next and next and next...
Next row 00 is 0100 if we add 0C to F4 and maybe 01 is added to the next, so:
now we add 0D to the 00 - got 0D, then add 0C - got next and next and next...

And now what... there is 4F 79 6B
4F 79 6B 5F 53 47 3B 2F 23 17 0B
FF F2 E6 DA CE C2 B6 AA 9E 92 86 7A 6E 62 56 4A 3E 32 26 1A 0E 02
F6 E9 DD D1 C5 B9 AD A1 95 89 7D 71 65 59 4D 41 35 29 1D 11 05
F9 EC E0 D4 C8 BC B0 A4 98 8C

If we start from 79 - subtract 0E - you got next, then subtract 0C - got next and next and next...
Next row FF is right if we subtract 0C from 010B and maybe 01 is subtracted from next, so:
now we subtract 0D from the FF - got F2, then subtract 0C - got next and next and next...
Next row F6 is right if we subtract 0C from 0102 and maybe 01 is subtracted from next, so:
now we subtract 0D from to the 9C - got EC, then subtract 0C - got next and next and next...

So, half of 128 bytes next byte is 0C bigger than previous and in middle is turning
point from where next byte is 0C smaller than previous. Very hi-tech code.
(Sometimes I use excel for help and visualization... to get sharper look for hacking)

That's all. Long story, short question - what pattern is this?

janekivi · « **Reply #113 on:** August 06, 2016, 08:10:08 pm »

It reminds me something like crypted data.
In Sparrow(ARM)update_00.04.00.00.00 pattern is more visible
and the same only other updates have different step.
I rearrange the columns for You:

79 8A 99 49 FE B2 67 1C D1 85 3A EF A3 58 0D C2 76 2B E0 94
49 FE B2 67 1C D1 85 3A EF A3 58 0D C2 76 2B E0 94
49 FE B2 67 1C D1 85 3A EF A3 58 0D C2 76 2B E0 94
49 FE B2 67 1C D1 85 3A EF A3
48 4C 94 DF 2A 76 C1 0C 58 A3 EE 39 85 D0 1B 67 B2 FD 48
94 DF 2A 76 C1 0C 58 A3 EE 39 85 D0 1B 67 B2 FD 48
94 DF 2A 76 C1 0C 58 A3 EE 39 85 D0 1B 67 B2 FD 48
94 DF 2A 76 C1 0C 58 A3 EE 39 85

RhymeMess · « **Reply #114 on:** August 06, 2016, 08:57:33 pm »

I tried to apply the same scheme to the first 128 bytes, but nothing meaningful appeared. Also subtracting 0x0c resulted in this:

7e 53 6a 54 5c 89 71 7f 88 20 f0 22 ae 10 93 7d ~SjT\.q.. ."...} 44 95 91 e7 d9 bc 76 a6 31 7b 76 cc 65 9e 73 33 D.....v.1{v.e.s3 c7 77 8a cd a0 cb 1d d4 25 67 41 16 d9 40 2e fd .w......%gA..@.. e3 19 e6 2a 8d 2f ce d6 79 a1 b3 95 74 71 63 cf ...*./..y...tqc. cc 8c d7 49 26 d2 50 00 d6 37 7f f6 bd d7 b3 67 ...I&.P..7.....g a2 d6 bb 02 6f 7e dc 7c d6 df 29 a1 94 1b 08 10 ....o~.|..)..... e7 df 96 e6 fb d4 a3 8a ee f9 35 09 7f 6d d9 e6 ..........5..m.. 3c 60 32 e9 1d cb 3f b0 35 69 8f 80 f3 2d a2 8a <`2...?.5i...-.. 5a 81 e4 ff 00 00 00 00 00 00 00 00 00 00 00 00 Z............... 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ a2 ca 02 00 00 00 00 00 00 00 00 00 01 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 ................

Still not meaningfull, but the lower 128 bytes are not empty. 0x0c was chosen to zero out most of the lower half. "5a 81 e4 ff " might be a checksum¹⁾, "a2 ca 02 00" translates to 182946, but that doesn't mean anything to me... maybe I should check more footers...

*edit*
1) looking into more footers, it doesn't look like a checksum.

RhymeMess · « **Reply #115 on:** August 06, 2016, 09:37:47 pm »

Here are a few more:

Code: [Select]

DS1000Z-00.04.00.00.00-7/footer
93  9b  52  47  96  e8  8e  d5  84  37  fa  bf  c7  ba  87  5a   ..RG.....7.....Z
85  ad  f6  db  b1  7b  bd  9c  00  1c  a4  ab  69  3e  7f  1f   .....{......i>..
02  7e  b3  49  10  eb  6b  06  6d  d5  c8  64  1c  34  6d  a9   .~.I..k.m..d.4m.
9f  ad  b0  22  0d  d5  54  5d  cc  19  f2  19  30  50  6b  96   ..."..T]....0Pk.
a1  de  19  3e  3d  8d  89  c0  ae  14  d8  b9  a4  f2  a9  f4   ...>=...........
05  76  75  ea  de  ad  99  8e  af  cf  29  b9  e4  21  0e  4a   .vu.......)..!.J
46  d2  60  39  07  47  d5  3e  28  24  50  e9  fd  e3  e1  db   F.`9.G.>($P.....
5e  eb  c0  2b  6e  94  c4  21  f0  5e  3c  5f  ef  40  30  6f   ^..+n..!.^<_.@0o
ee  5d  5b  fc  01  00  01  01  01  00  01  01  00  01  01  01   .][.............
00  01  01  00  01  01  00  01  01  01  00  01  01  00  01  01   ................
01  00  01  01  00  01  01  00  01  01  01  00  01  01  00  01   ................
01  01  00  01  01  00  01  01  00  01  01  01  00  01  01  00   ................
a7  48  04  01  01  00  01  01  00  01  01  01  00  01  01  00   .H..............
01  01  01  00  01  01  00  01  01  00  01  01  01  00  01  01   ................
00  01  01  01  00  01  01  00  01  01  00  01  01  01  00  01   ................
01  00  01  01  01  00  01  01  00  01  01  00  01  01  01  00   ................

DS1000Z-00.04.01.02.00-7/footer
3d  84  28  8c  01  05  50  51  bd  72  d2  e6  98  6c  8b  38   =.(...PQ.r...l.8
8b  b7  8f  6e  fe  3b  4c  c5  60  ba  78  43  18  d9  c8  81   ...n.;L.`.xC....
08  b8  bb  8a  f0  65  9a  a4  f2  ed  e5  b3  41  bb  7b  f7   .....e......A.{.
33  42  7a  bb  77  27  3d  91  09  e8  81  02  dc  4c  7a  65   3Bz.w'=......Lze
ef  a8  e5  cb  b0  65  8d  52  0d  ee  b5  b9  9b  22  96  3e   .....e.R.....".>
d4  eb  d0  23  87  6e  46  54  22  f7  40  b0  32  4a  a9  26   ...#.nFT".@.2J.&
24  64  34  25  a9  81  f7  73  63  74  9b  3e  4d  5c  88  18   $d4%...sct.>M\..
27  4c  03  1d  9a  8e  cd  ce  4f  ea  83  85  c0  41  43  56   'L......O....ACV
a0  03  5c  00  00  00  00  00  00  00  00  00  00  00  00  00   ..\.............
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  c0  08  91  91  90  91  91  90  91  90  91  90  91  91  90   ................
6f  3e  01  00  00  00  00  00  00  00  00  00  00  00  00  00   o>..............
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  00  90  91  90  91  90  91  90  91  91  90  91  90  91  90   ................

DS1000Z-00.04.02.04.07-7/footer
c0  59  10  67  65  49  50  96  a6  1b  47  42  3e  2a  b5  87   .Y.geIP...GB>*..
0d  56  87  48  4b  c6  a3  76  8d  9c  ca  84  34  98  32  2a   .V.HK..v....4.2*
f0  d9  08  8f  f7  bd  18  04  04  84  49  36  7b  51  36  2b   ..........I6{Q6+
d1  5e  a3  3f  f8  96  ea  5d  61  64  53  14  24  ad  d8  50   .^.?...]adS.$..P
93  84  5e  75  ff  9a  af  76  01  30  e8  9d  4e  cc  ac  23   ..^u...v.0..N..#
0a  30  00  85  30  59  67  da  02  91  bb  a2  15  e8  03  c0   .0..0Yg.........
48  58  a2  06  84  a7  42  9d  f5  79  f7  b3  00  4b  2d  41   HX....B..y...K-A
eb  dc  a9  b8  4c  08  d7  ca  f6  73  72  dd  97  9f  7d  95   ....L....sr...}.
f6  cc  bf  00  00  00  01  00  00  01  00  00  00  01  00  00   ................
01  00  00  01  00  00  01  00  00  00  01  00  00  01  00  00   ................
01  00  00  01  00  00  01  00  00  00  01  00  00  01  00  00   ................
01  00  00  01  00  00  00  01  00  00  01  00  00  01  00  00   ................
5a  4f  02  00  00  01  00  00  01  00  00  01  00  00  00  01   ZO..............
00  00  01  00  00  01  00  00  01  00  00  00  01  00  00  01   ................
00  00  01  00  00  01  00  00  00  01  00  00  01  00  00  01   ................
00  00  01  00  00  01  00  00  00  01  00  00  01  00  00  01   ................

DS1000Z-00.04.03.01.05-7/footer
7e  53  6a  54  5c  89  71  7f  88  20  f0  22  ae  10  93  7d   ~SjT\.q.. ."...}
44  95  91  e7  d9  bc  76  a6  31  7b  76  cc  65  9e  73  33   D.....v.1{v.e.s3
c7  77  8a  cd  a0  cb  1d  d4  25  67  41  16  d9  40  2e  fd   .w......%gA..@..
e3  19  e6  2a  8d  2f  ce  d6  79  a1  b3  95  74  71  63  cf   ...*./..y...tqc.
cc  8c  d7  49  26  d2  50  00  d6  37  7f  f6  bd  d7  b3  67   ...I&.P..7.....g
a2  d6  bb  02  6f  7e  dc  7c  d6  df  29  a1  94  1b  08  10   ....o~.|..).....
e7  df  96  e6  fb  d4  a3  8a  ee  f9  35  09  7f  6d  d9  e6   ..........5..m..
3c  60  32  e9  1d  cb  3f  b0  35  69  8f  80  f3  2d  a2  8a   <`2...?.5i...-..
5a  81  e4  ff  00  00  00  00  00  00  00  00  00  00  00  00   Z...............
00  00  00  00  00  00  01  00  00  00  00  00  00  00  00  00   ................
00  00  00  00  00  00  00  00  00  00  00  01  00  00  00  00   ................
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
a2  ca  02  00  00  00  00  00  00  00  00  00  01  00  00  00   ................
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  00  01  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  00  00  00  00  00  00  01  00  00  00  00  00  00  00  00   ................

DS1000Z-00.04.00.00.00-15/footer
da  5a  4d  70  5c  55  15  22  b8  df  f1  ef  3b  36  ad  aa   .ZMp\U."....;6..
26  db  84  b8  5d  db  26  06  ee  af  b4  a4  2e  04  a9  35   &...].&........5
4a  98  d4  d2  5b  56  73  18  ae  d1  34  3a  24  4c  01  f1   J...[Vs...4:$L..
e9  41  df  4b  56  93  fc  ed  99  62  c5  51  b1  3a  f3  20   .A.KV....b.Q.:. 
a6  69  c9  56  7d  17  2d  fd  82  6f  eb  2d  d4  53  2d  72   .i.V}.-..o.-.S-r
c7  4e  41  c4  e2  e5  5c  b0  f1  6f  cc  c3  d3  47  aa  a0   .NA...\..o...G..
40  d0  09  9f  76  8c  7f  f5  dd  5a  7a  93  a6  c9  7f  6c   @...v....Zz....l
73  fa  a3  c9  85  e9  aa  0b  9d  cb  07  80  79  1a  49  5e   s...........y.I^
31  90  f5  00  00  01  00  00  01  00  00  00  01  00  00  00   1...............
01  00  00  01  00  00  00  01  00  00  00  01  00  00  01  00   ................
00  00  01  00  00  00  01  00  00  01  00  00  00  01  00  00   ................
00  01  00  00  01  00  00  00  01  00  00  01  00  00  00  01   ................
c0  69  01  00  00  01  00  00  00  01  00  00  01  00  00  00   .i..............
01  00  00  00  01  00  00  01  00  00  00  01  00  00  01  00   ................
00  00  01  00  00  00  01  00  00  01  00  00  00  01  00  00   ................
00  01  00  00  01  00  00  00  01  00  00  00  01  00  00  01   ................

The first 20 and last 4 bytes are always the same. The value I substracted is not and I have no real clue where to look for it. I just used the difference between bytes 160 and 161 because that kinda worked.

Userli · « **Reply #116 on:** August 06, 2016, 09:39:07 pm »

Very interesting!

Look at it like this:

Code: [Select]

A3 30 20

2B 37 43 4F 
5B 67 73 7F 
8B 97 A3 AF 
BB C7 D3 DF 
EB F7 03 
         10
1C 28 34 40 
4C 58 64 70 
7C 88 94 A0 
AC B8 C4 D0 
DC E8 F4 00 

0D 19 25 31 
3D 49 55 61 
6D 79 85 91 
9D A9 B5 C1 
CD D9 E5 F1 
FD 

4F 79

6B 5F 53 47 
3B 2F 23 17 
0B FF F2 E6 
DA CE C2 B6 
AA 9E 92 86 
7A 6E 62 56 
4A 3E 32 26 
1A 0E 02 F6 

E9 DD D1 C5 
B9 AD A1 95 
89 7D 71 65 
59 4D 41 35 
29 1D 11 05 
F9 

EC E0 D4 C8 
BC B0 A4 98 
8C

RoGeorge · « **Reply #117 on:** October 20, 2016, 05:04:52 pm »

This post is just to easily follow the subject.

janekivi · « **Reply #118 on:** November 23, 2016, 06:57:27 pm »

After reading some memory dumps thru the jtag I didn't find there anything helpful.
In one point was license code and serial number did end there with DSER. Before
was some 7 byte keys, like from RIGLOL source: 7A3E808599A525
and 46C5B8D451045C which is not from there.
I didn't find any other keys used in RIGLOL.
When it reads the SD, I saw there all my deleted files too in TOC.
During update there was full previous GEL file and next from SD card. In one point
it reads last 486 bytes from update file where at the end is 280 bytes footer.
But how it checking this footer and what's there inside I don't know yet.
Somehow the last part is having strange pattern and there are probably zeros
with 3 byte and 2 byte data. Then it can be crypted with RC5 and 8 bit buffer.
But I don't know... there are probably some more algorithms for key and data.

smithnerd · « **Reply #119 on:** November 24, 2016, 12:09:41 am »

Quote from: janekivi on November 23, 2016, 06:57:27 pm

there are probably some more algorithms for key and data.

I've made quite a bit of progress with this. I'll try to spend a couple of hours tomorrow documenting what I've found...

smithnerd · « **Reply #120 on:** November 25, 2016, 12:40:55 am »

I started to approach this from the other direction, by doing some bottom up reverse engineering of the OS.

We already know that SparrowAPP.out is a statically linked ELF binary containing the field upgradeable 'application' part of the scope firmware. While it is only part of the complete system, it provides some insight into how the whole system is built. Memory segments are from the ELF file:

Code: [Select]

$ readelf  -S SparrowApp.out
There are 12 section headers, starting at offset 0x3c1eec:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 3c1e40 000000 10      0   0  4
  [ 1] .shstrtab         STRTAB          00000000 3c1e40 000069 00      0   0  4
  [ 2] A1 rw             PROGBITS        00000000 000034 000040 01  AX  0   0  4
  [ 3] Absolute sections NOBITS          00007ff4 000074 000004 01  WA  0   0  1
  [ 4] Absolute sections NOBITS          00007ffc 000074 000004 01  WA  0   0  1
  [ 5] P2 zi             NOBITS          00010000 000074 0004c4 01  WA  0   0  4
  [ 6] P3 zi             NOBITS          00018000 000074 0011a0 01  WA  0   0  4
  [ 7] P4 rw             PROGBITS        40000000 000074 3c1dcc 01  AX  0   0 16
  [ 8] P5 ui             NOBITS          40600000 3c1e40 001900 01   A  0   0 32
  [ 9] P6 rw             NOBITS          40601900 3c1e40 2b9444 01  WA  0   0 32
  [10] P9 zb             NOBITS          40b00000 3c1e40 200000 01  WA  0   0 32
  [11] P8 ui             NOBITS          43ee0000 3c1e40 020000 01   A  0   0  8

(Physical RAM starts at 0x40000000)

At power up the i.MX283's ARM core (ARM926EJ-S, ISA is arm5TE) enters into the bootloader, SparrowBoot.sb, which is loaded into RAM at 0x41000000 (it's about 0x50000 long depending on version). During normal boot, the bootloader opens the NAND flash device as a UFFS filesystem, loads logo.hex and displays it. It then loads /sys/SparrowAPP.out into RAM and passes control to its entry point in segment 7 (P4 rw): 0x40293738 (according to readelf -h). The bootloader remains in RAM, but is not referenced again, so one can copy it from a RAM dump using:

Code: [Select]

$ dd if=ramdump.bin of=bootloader.bin bs=1 skip=16777216 count=327680
SparrowBoot.sb is a self-contained MQX 3.7.0 instance which contains UFFS and MFS (the native MQX FAT32 library) plus USB host support.

SparrowAPP.out is a separate MQX 3.7.0 instance which contains UFFS, MFS, RTCS (TCP/IP stack), USB host and device stack, TFS (Trivial filesystem, a RAM disk essentially), the GUI toolkit (not identified yet, possibly homegrown). libpng, zlib etc. plus the rest of the scope application code.

SparrowAPP.out was compiled using the IAR ARM compiler (one can tell from the segment names) and so is probably linked against IAR's DLIB and runtime libraries. MQX 3.7.0 does not natively support i.MX parts, so the Board Support Package (BSP) and Processor Support Package (PSP) are, most likely, provided by Embedded Access Inc:

http://embedded-access.com/products/mqx-rtos/

However, if one hunts around the NXP site, it is possible to download the MQX 3.7.0 source code (which is fairly ancient) and compile it for the nearest supported ARM part, which turns out to be a Freescale Kinetis K60 (ARM Cortex M4 core). Compiled with symbols and debug info, this can be used to identify large amounts of OS code, with a high degree of confidence. Cortex M4 is thumb only (16-bit) while SparrowAPP.out is mostly/solely arm (32-bit), so the usual signature based analysis tools wouldn't be of any help - I had to do it by hand, which was time consuming, but educational and quite good fun.

I would estimate that I've identified 75-80% of the OS code, as follows:

UFFS (100%)
TFS (100%)
MFS (95+%)
RTCS (90+%)
USB (host 90+%, device ~75%)
BSP (<10%)
PSP (<10%)
MQX (80+%*)

* Difficult to estimate, as it depends on build configuration.

I also found the MQX 3.7.0 source here (not official, but convenient to browse):

https://github.com/gxliu/MQX-3.7.0

UFFS source is available here:

https://sourceforge.net/projects/uffs/

I identified the version as 1.3.6 (the latest version), using typos and ideosynchrocies in the strings.

TFS is used to serve web content out of RAM, from the built in httpd, which is provided with RTCS. There are also strings for a 'GoAhead' Web server, which I haven't investigated yet. Similarly libpng and zlib are easy to find, but not terribly interesting or helpful.

So, what is the point of this?

Say for example, one is interested in examining how the SCPI service on tcp/5555 works. It is now a fairly easy task to search for function calls to RTCS_socket, choose one with the number 0x15b3 (5555) nearby, then follow the function calls down to the handler routine. The API details for how sockets work in RTCS are well documented. Obviously one can learn a lot about interfacing with the scope hardware from this point.

Knowing more about the filesystem is interesting, particularly calls to uffs_open(), I believe the missing MIRACL crypto API stuff is probably in one of the files in the internal flash, and most likely it is loaded and unloaded on demand. We really need to dump the flash to find out...

I've been working on firmware version 04.03.02.03, as that was current when I started. It doesn't look like anything much changed with later firmware revisions, as far as the OS is concerned. Similarly, the differences between the MQX parts of the earliest bootloader (from the .GEL) and recent ones are minimal, as far as I can tell.

I have to figure out how to share what I've done so far. As it currently stands the data is in a format which is very specific to my workflow. It would be nice to create a symbol table which could be linked back into the existing ELF file, then the free/demo version of IDA could read it directly.

I also want to investigate the DLIB, DLPP, RT and M libraries supplied with IAR. I believe it should be possible to identify any linked functions using signature techniques, but it is not as straight forward as I first assumed. It would be great to identify all the string functions in particular.

janekivi · « **Reply #121 on:** November 25, 2016, 05:19:17 pm »

RAM seems to be there like in other scopes, what about other addresses

device start length
-----------------------------------------------------
RAM 0x4000 0000 0x3FF FFFF
FLASH
SD
...

At one point I see
F r e e s c a l e , I n c . R O M R e c o v e r y R e c o v e r y C o n f i g u r a t i o n
R e c o v e r y I n t e r f a c e 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0

Enabling of DCDC failed at setting of 5VCTRL ENABLE_DCDC. We need power down device.

But not much readable stuff, no matter if I scroll it up or down or fast or slow : (

smithnerd · « **Reply #122 on:** November 25, 2016, 07:07:33 pm »

Quote from: janekivi on November 25, 2016, 05:19:17 pm

RAM seems to be there like in other scopes, what about other addresses

device start length
-----------------------------------------------------
RAM 0x4000 0000 0x3FF FFFF
FLASH
SD
...

At one point I see
F r e e s c a l e , I n c . R O M R e c o v e r y R e c o v e r y C o n f i g u r a t i o n
R e c o v e r y I n t e r f a c e 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0

Enabling of DCDC failed at setting of 5VCTRL ENABLE_DCDC. We need power down device.

But not much readable stuff, no matter if I scroll it up or down or fast or slow : (

See p.125-127 of the i.MX28 Applications Processor Reference Manual:

http://www.nxp.com/assets/documents/data/en/reference-manuals/MCIMX28RM.pdf

It shows the memory map for the processor. I believe that the internal NAND flash chip is addressed via APBH DMA at 0x80004000-0x80005FFF. Not sure what you mean by SD.

Data transfers to/from NAND flash are done with the AHB-to-APBH Bridge. I have mapped some of that stuff out while looking through the BSP/PSP code. <- edit: DCP just provides an efficient memcpy function.

smithnerd · « **Reply #123 on:** November 25, 2016, 07:43:05 pm »

Interestingly, the DCP (see ch.13) also has a memory blitting capability, which is used extensively for drawing bitmaps to the frame buffer. I discovered this while looking to see if the firmware uses the DCP's hardware crypto features - it doesn't, at least not in SparrowAPP.out.

400E0800 raster_blit
400CF644 start_dcp_blit

janekivi · « **Reply #124 on:** November 28, 2016, 05:07:05 pm »

There is 90 MB internal memory. How it accessing this?

So far I only found from memory dumps how to generate trial keys for DS1000Z
with http://www.gotroot.ca/rigol/riglol/
For this you can use V for first option character like
VSER for all options 36 hours trial key


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Rigol DSXXXX .GEL firmware file format (Read 64135 times)

Share me