We need a file in the stateful partition of a USB-recovery image to act as a placeholder for the config file for USB-enrollment data. Since from the web, we do not have access to mount a partition in the image, the other method is to keep a small placeholder file in the stateful partition and modify this file when writing the image into the USB without the need for mounting the partition. However, we need first to find where the file is located in the recovery image. That can be done by searching for a deterministic pattern in the recovery image. The placeholder file will have that pattern.

Be careful about:
- The pattern cannot change in the future.
- The pattern should be deterministic and re-createable from any programming language.
- The process should consider the block size of the filesystem.

 

We need a file in the stateful partition of a USB-recovery image to act as a placeholder for the config file for USB-enrollment data. Since from the web, we do not have access to mount a partition in the image, the other method is to keep a small placeholder file in the stateful partition and modify this file when writing the image into the USB without the need for mounting the partition. However, we need first to find where the file is located in the recovery image. That can be done by searching for a deterministic pattern in the recovery image. The placeholder file will have that pattern.

Details to consider:
- The pattern cannot change in the future.
- The pattern cannot be stored as a constant.
  Apart from being clunky, it could end up in the image as part of e.g. Chrome, causing false positives when scanning the disk image.
- The pattern should be deterministic and re-createable from any programming language.
- The process should consider the block size of the filesystem.

 

Short background:
   Currently, when admins go through a recovery procedure (oftentimes yearly), they have to go through a tedious process of selecting the same options (WiFi, EULA acceptance, enterprise enrollment, etc.) on dozens of Chromebooks. We can add these options into some form of the USB recovery media creation tool, and insert them into the pre-built recovery image. Then, we can have the recovery procedure skip over the respective OOBE screens.

   For this, we need a file in the stateful partition of USB recovery images that the USB media creation tool can modify to include user-specific information. Since we cannot mount the stateful partition in the tool, an alternative is to pre-allocate a file of fixed length containing a random string during the recovery image building procedure, then scan for and replace the corresponding bytes in the recovery media creation tool (without having to mount the partition).

Design doc: https://docs.google.com/document/d/15STe5urdjWCONYE7ivmXxNlTKAtH0gqvAnoT1YZ2kII/edit#

Details to consider:
- The pattern cannot change in the future.

- The pattern cannot be stored as a constant.
  Apart from being clunky, it could end up in the image as part of e.g. Chrome, causing false positives when scanning the disk image. If it's generated at runtime through some seeded PRNG, this detail is taken care of. The chance of a collision on a 4K random string is very small.

- The pattern should be deterministic and re-createable from any programming language.
  We can't use any built-in random utility since ensuring the underlying algorithm never changes across different languages and runtime versions is impractical). An straightforward solution is to implement a simple linear congruential generator inline, and use the same starting parameters in all implementations.

- The process should consider the block size of the filesystem.
  It looks like all(?) the images we produce use a 4K block size for the stateful partition, but it's probably not a good idea to rely on this. Furthermore, the file we are allocating is larger (16K) than a single block, so it will span multiple, possibly non-contiguous blocks (in some tests, it appears ext4 always places the blocks beside each other, but again it's probably not a good idea to rely on this).

   We can get around this by creating a random string of length $block_size - 4 (e.g. 4092), and for each block, writing the string, followed by an incrementing block number in the last 4 bytes. For a 16K file, the data might look something like:

   0x0000: [ 4092 random bytes ][1]
   0x1000: [ same random bytes ][2]
   0x4000: [ same random bytes ][3]
   0x7000: [ same random bytes ][4]

   So, any code patching the image later can search for the random string, then use the following 4 bytes to determine which part of the file that block belongs to.

   It's possible that for some disk layouts we'll be generating less than 4K bytes of randomness, but even e.g. 512 bytes should be sufficiently random to not collide with random compiled code.
 

Short background:
   Currently, when admins go through a recovery procedure (oftentimes yearly), they have to go through a tedious process of selecting the same options (WiFi, EULA acceptance, enterprise enrollment, etc.) on dozens of Chromebooks. We can add these options into some form of the USB recovery media creation tool, and insert them into the pre-built recovery image. Then, we can have the recovery procedure skip over the respective OOBE screens.

   For this, we need a file in the stateful partition of USB recovery images that the USB media creation tool can modify to include user-specific information. Since we cannot mount the stateful partition in the tool, an alternative is to pre-allocate a file of fixed length containing a random string during the recovery image building procedure, then scan for and replace the corresponding bytes in the recovery media creation tool (without having to mount the partition).

Design doc: https://docs.google.com/document/d/15STe5urdjWCONYE7ivmXxNlTKAtH0gqvAnoT1YZ2kII/edit#

Details to consider:
- The pattern cannot change in the future.

- The pattern cannot be stored as a constant.
  Apart from being clunky, it could end up in the image as part of e.g. Chrome, causing false positives when scanning the disk image. If it's generated at runtime through some seeded PRNG, this detail is taken care of. The chance of a collision on a 4K random string is very small.

- The pattern should be deterministic and re-createable from any programming language.
  We can't use any built-in random utility since ensuring the underlying algorithm never changes across different languages and runtime versions is impractical. A straightforward solution is to implement a simple linear congruential generator inline, and use the same starting parameters in all implementations.

- The process should consider the block size of the filesystem.
  It looks like all(?) the images we produce use a 4K block size for the stateful partition, but it's probably not a good idea to rely on this. Furthermore, the file we are allocating is larger (16K) than a single block, so it will span multiple, possibly non-contiguous blocks (in some tests, it appears ext4 always places the blocks beside each other, but again it's probably not a good idea to rely on this).

   We can get around this by creating a random string of length $block_size - 4 (e.g. 4092), and for each block, writing the string, followed by an incrementing block number in the last 4 bytes. For a 16K file, the data might look something like:

   0x0000: [ 4092 random bytes ][1]
   0x1000: [ same random bytes ][2]
   0x4000: [ same random bytes ][3]
   0x7000: [ same random bytes ][4]

   So, any code patching the image later can search for the random string, then use the following 4 bytes to determine which part of the file that block belongs to.

   It's possible that for some disk layouts we'll be generating less than 4K bytes of randomness, but even e.g. 512 bytes should be sufficiently random to not collide with random compiled code.