Pro/Forums - View Single Post

dvscreen · 10-19-2004, 06:30 AM

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.

10-19-2004, 06:30 AM	#308
dvscreen Cooling Neophyte Join Date: Jan 2003 Location: New York Posts: 3	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. Last edited by dvscreen; 10-19-2004 at 10:59 AM.