Hilo

Hilo is a set of Secure Enclave tests designed to work on internal builds of iOS for D22AP and D221AP, A.K.A. the iPhone X. It was first discovered on TigrisAni 15A93261h in AppleInternal/CoreOS/AppleSEP/unit_tests/hilo.

It connects to a hardware device known as Hilo, mentioning it as a display unit. Below is a comment that describes a function to check for Hilo support.

   # Return whether the current device supports Hilo. Uses shell values of truth,
   # i.e., 0 means true, non-zero means false.

Below that is another comment, highlighting how it checks for Hilo functionality.

   # If product name starts with D22, then we can exercise the SEP Hilo
   # functionality (though the actual Hilo display might not exist on dev
   # devices).

This would suggest that Hilo might be the codename for the TrueDepth sensor housing. If this is true, then that would also mean that earlier prototype/development devices did not include the TrueDepth sensor array.

When testing, it manipulates something called an LTH.

   # This part of the test tests that we can store and reload an LTH. It does this
   # by:
   #
   # 1) Setting the LTH to a known pattern
   # 2) Storing an LTH backup
   # 3) Clearing the stored LTH (to ensure that we're testing the results of a load)
   # 4) Loading the stored LTH backup
   # 5) Checking that the loaded LTH has the expected pattern

   # This part of the test tests end-to-end that verification of the LTH backup
   # works. We attempt to load a backup that won't verify. As an additional
   # security requirement, we want to ensure that on a failed backup load the LTH
   # in the SEP is zeroed (to avoid an attacker learning something about the
   # decryption of messages that won't verify).

A README file explains the process for compressing LTHs. The SSH server is not accessible externally. Interestingly enough, the test device is referred to as D2x, suggesting that there were multiple development boards that utilized Hilo or that the board identifier was unknown at the time.

   Here's how this compression test vector was generated (unfortunately, generating
   new test vectors, e.g., in the case of a compression algorithm change, is a
   little complicated at the moment):
   
   This uses compression tools available in
   ssh://stash.sd.apple.com/~mlindberg/lth_compression.git.
   
   1) I took a number of screenshots on my D2x and saved them as 8-bit PNG files.
   
   2) I used Martin's lth_generation_tool to convert the target PNG files into a
   16-bit PPM image file (for viewing and compression testing) and three channel
   outputs.
   
   2a) But something funny happens here: lth_generation_tool shifts the channel
   outputs by as much as it can to fill the full 32-bit range.  However, the PPM
   file is 16-bit, and can't contain that shift.  As a result, the PPM file's
   contents differ from the R, G, B channel inputs by a shift that we are later
   going to have to compensate for.
   
   3) The LTH input is a concatenation of the R, G, B channel outputs in that
   order.
   
   4) Due to 2a, I had to hack the image_compression tool to shift the values read
   in from the PPM file by the amount shifted in outputting the R, G, B channel
   outputs.  You can see the shift printed by the tool during R, G, B channel
   generation and PPM generation.
   
   5) I used the hacked image_compression tool to compress the shifted PPM values.
   
   6) I hacked the image_compression tool to output separate channel outputs on
   decode.
   
   7) I used the hacked image_compression tool to generate channel outputs for the
   decoded compressed file.
   
   8) The LTH output is a concatenation of the R, G, B channel outputs of the
   decoded file in that order.

Later, it highlights how production devices are incompatible, as they do not support insecure Secure Enclave operations like development and prototype devices do.

   # This test turns off rate limiting, and so we expect that this test will fail
   # if the SEP firmware doesn't support insecure Hilo features. However, we don't
   # want to register the lack of support for insecure Hilo features (as will be
   # the case for FACTORY SEP firmware) as a failure of this test. So, if the SEP
   # firmware doesn't support insecure Hilo features, we exit and mark the test as
   # passing.