[re3dyb0y]

dvscreen

Has anyone noticed that the .sup files provided by Snap are text files of some kind of Intel Hex dump (starting with colon ?

Can they be used to rebuilt an image without assist?

I have a Snap 1000 that is drive-less and I would like to use it some day and I can't find an image for it.


Ok, got a bit further.

The .SUP file (support files) are some kind of uncompressed archives. Assist uses them to upload to the Snap Server. I have looked at .SUP files for SnapOS V3 and V4.

The files contains 3 areas:

1. Hex dump of binary files .HEX
2. Resource files .RES
3. HTML files (.HTML, .CSS, and .GIF)

The hex section contains one binary file for each model of Snap Server:
MOAI110.HEX
MOAI200.HEX
MOAI300.HEX
MOAI20X.HEX
MOAI400.HEX

Those are Intel HEX records and the clue is that they begin with a colon. There are four types of records, but only 3 are used here. Here's how each row is decoded:

:nnaaaattdddddddddddddddddddddddddddddd ... cc

Where:
- nn is the record-length field that represents the number of data bytes (dd) in the record.

- aaaa is the address field that represents the starting address for subsequent data in the record.

- tt is the field that represents the HEX record type, which may be one of the following:
00 - data record
01 - end-of-file record
02 - extended segment address record
04 - extended linear address record

- dd is a data field that represents one byte of data. A record may have multiple data bytes. The number of data bytes in the record must match the number specified by the ll field.

- cc is the checksum field that represents the checksum of the record. The checksum is calculated by summing the values of all hexadecimal digit pairs in the record modulo 256 and taking the two's complement.

Example: in the SnapOS v3 file, the first two lines are:

:02 0000 04 0004 F6
:nn aaaa tt dddd cc

0x02 + 0x00 + 0x00 + 0x04 + 0x00 + 0x04 = 0x0A
0x100 - 0x0A = F6 (ok)

:20 0000 00 2600B0C1870070912D00FF0770892D001800FFFFFFFF300010 00236B10006092 84
:nn aaaa tt dddddddddddddddddddddddddddddddddddddddddddddddddd dddddddddddddd cc

0x20 + 0x00 + 0x00 + 0x00 + 0x26 + 0x00 + 0xB0 + 0xC1 + 0x87 + 0x00 + 0x70 + 0x91 + 0x2D + 0x00 + 0xFF + 0x07 + 0x70 + 0x89 + 0x2D + 0x00 + 0x18 + 0x00 + 0xFF + 0xFF + 0xFF + 0xFF + 0x30 + 0x00 + 0x10 + 0x00 + 0x23 + 0x6B + 0x10 + 0x00 + 0x60 + 0x92 = 0xB7C

0x100 - 0x7C = 0x84 (ok)

Note: you can cut and paste the equation (before the =) in Google if you don't have a Hex calculator.

The records used are:
- 1 Type 04 record (address).
- 2048 Type 00 records (data).
(this sequence of two is repeated repeated 25 to 30 times)
- 1 Type 01 record (EOF) with data.

This file is quite small, around 1.7 MB once converted to binary.

I can not read any ASCII text after converting the dump to a binary. However, I don't believe these are from compressed files because they are padded with hundreds zeroes. The last character, after the zeroes, is 0xEB.

Then the resource files are:
UK\Snap_00_UK.Res
Fr\Snap_00_Fr.Res
Ge\Snap_00_Ge.Res
Sp\Snap_00_Sp.Res

There is no US file, so the resource must be contained in the .RES files. I can read ASCII text in these files, but some binary data is also present. It must be possible to compare the .RES to the .HEX to find if any binary shit has been used to hide the OS in the .HEX file.

Finally, the html files follow:
US\AccessGuideFolderSend.html
US\AccessGuideDriveSend.html
US\AccessGuideMenu.html
etc.

Some .GIFs are present and a single .CSS file.

Conclusions:
1. Most of the OS must be in the .HEX files and that's where we need to investigate.
2. The .CSS could be easily modified and uploaded to customize the look of the server.
3. Same is true with the .HTML files to change the layout and the functions.
4. There must be a reason why the .HEX files are not in plain binary. Possible clues are: the need to hide the OS, the need to upload the data to the Snap Server in a special way.
5. My findings supports other poster's observations that one .SUP file contains all server models and all supported languages.

Requests:
1. I would need an ISO file from a Snap 1000 or 1100 to go any further. Mine is toasted, and that is why I am doing this work. I would love to run the SnapOS on a regular PC.
2. Has anyone found information about hardware? I know it revolves around an embedded x86 compatible "PC on a chip" and that has a built-in video card. It would be great to put Linux on it and to attach monitor.


scottz

Nice to see someone is thinking along the same line.
I went through the same manuvers last month but had to give up on it due to time.

What I found:

It looks like after the .SUP file is uploaded it is broken out by the SnapOS upgrade process.

If you look at the end of the .sup file you will find html code for minimal help screens. So there are sections to the .sup file that the upgrade process knows how to break out.

From what I found, the .HEX file seems to be either:

1) a Patch (not a full image) for the current BIOS/OS and isn't in a contigious format.

2) a compressed image.

3) Combination of both.

With the padded 0's being there, it could be a section that isn't being used, OR what I'm guessing is that these are sections that is used for saving settings when you switch off the power (i.e. you need some room in flash to store IP address, disk shares, passwords, etc) so you don't want to put code there. They could be ignored by the upgrade utility, but are there for continuity.

I started going through some of the PC BIOS and Flash utils/hacks to see if there is any related format that has a similar process and can give us a clue as to how this one maybe setup. I did find a case where a flash was upgraded with a .HEX file where the data was compressed and then decompressed on the fly during the upgrade process, so one theory is there.

The E28F016S5 Intel Chip is a 16Mbit (2MB) Flash Memory though, so I'm leaning towards it being a compressed image that decompresses on boot. Gives more room for the modified BSD OS to to fit in memory rather than disk.

Again, on the 4100 the majority of the OS lives on the Flash rather than disk.
You can boot up a 4100 with no disks installed and it will function.
Java and help/language files live on the disks, but it doesn't need them to operate.

If I could get my hands on a boot partition from a system that has it's OS on the drives, then I could do some comparisons to how the 4100 is broken out and how to modify it.

Scott

I found these posts about decompiling sups, anyone know how they did it?

I believe 3.4.830 also works for upgrading from v2. Look on the snap ftp site above