the last post was about a fuse filesystem which provides a read-only access to the proprietary bluecoat filesystem. After some further investigations based on the possibilities this offered us, I started to implement a tool which allows to modify parts of the filesystem.
Protection Mechanisms
Since last time, the discovered filesystem structures still had unknown fields. Some of those fields could be reconstructed and their purpose in the whole construct. The format of the Partition-Header for example could now be described as
struct cp_hp_entry {
struct cp_xx_entry hdr;
int header_checksum;
int data_checksum;
char header_hmac[20];
char still_unknown[44];
char data_hmac[20];
char still_unknown2[2964];
};
Those header_* and data_* fields represent most of the integrity protection mechanisms used by the SGOS for the main filesystem. The following picture shows the layout of the filesystem together with the integrity protected areas. The data offsets might vary between different versions of the SGOS.
As you can see, the integrity protection is implemented through 5 values. First, there is a SHA256 value computed over (almost) all data except of the Partition-Header and the pkcs7 signature inside the SubPartition-Header. This SHA256 value is itself protected by the mentioned pkcs7 signature. Second, a CRC32 and a HMACSHA1 are computed over the main headers (except the Partition-Header) and the remaining data, respectively. Those values are checked afterwards against the values stored in the Partition-Header.
Boot Process
As already described in the last post, the SGOS consists of several files on a FAT32 partition. Current investigations showed that the boot process works like this:
- Bootloader of the MBR loads the boot.exe from the FAT32 filesystem
- boot.exe loads the starter.si filesystem
- Integrity of the starter.si filesystem is checked by using the CRC32 and HMACSHA1 values
- boot.exe starts the boot kernel from the starter.si filesystem
- This kernel sets up the cache filesystem and starts starter.exe
- starter.exe loads the system1 filesystem
- Integrity of the system1 filesystem is checked by using the CRC32 and HMACSHA1 values and by checking the signature against a CA included in the starter.exe
- starter.exe starts the main kernel
The Tool
This is were the tool [2] published with this blogpost comes into play. The tool allows to view and calculate and reset the different checksums (CRC32, HMACSHA1 and SHA256). It also updates the starter.exe according to the new signature. Additionally, it provides a way to modify the (static) configuration settings described by Raphaël Rigo [1] (for example kernel flags, serial baudrate, process limits, …). Based on the research, the naming of the configuration values should be correct, but I may have overlooked something regarding the order of the lists.
During the application start, you will be prompted to select a root directory. This directory is the root of the FAT32 partition (the tool requires that the FAT32 partition is already mounted). In case different SGOS filesystems were found, the information tab of the boot partition will be shown. Besides the content of the currently stored values of the integrity protection mechanisms, you will also be able to get the actual checksums by performing double clicks on the fields next to a loaded checksum. If both values are the same, the field will be shown with a green background, red otherwise.
Another view is in the configuration tab, which contains the configuration values mentioned before. The actual settings are shown in decimal and hexadecimal. Those values can be modified by double clicking onto them (again, as decimal or hexadecimal).
The last tab is a readonly view of the the filesystem layout. Reading the file content is currently not supported, please use the fuse filesystem from the last post for that.
If you’ve modified something on the filesystem (either through the configuration tab or via a hexeditor) and recalculate the checksums on the info tab, you’ll notice that you get a lot of red fields. To fix this, go into the File menu and then select Patch.
After the checksum calculations were done, you should be able to boot the SGOS with the modified content.
Best,
Timo
| [1] | https://www.blackhat.com/docs/eu-15/materials/eu-15-Rigo-A-Peek-Under-The-Blue-Coat.pdf |
| [2] | https://github.com/ernw/bcfs-manager |