Describe the bug
When TC Flash Hash at Boot is enabled and user provides a wrong TC code, the device should not warn the user about Invalid Tamper Check Code, instead it should just show the image and two pair of words, the user have to always verify the images and words instead of the device validating the input and influencing users to ignore what is shown next.
The TC code is not a security PIN, the device should not be blocked, this could create a false sense of security false sensation of security while the devices are open and we don't have any form of "blocking", just as an example of how easy it is to disable this "blocking protection", if settings is stored in flash you just need to insert an SD card with a settings.json file with contents {"settings": {"persist": {"location": "sd"}}} and boom TC Flash Hash at Boot is disabled, if settings were stored in the SD already you just need to remove the SD card. So I consider the current way TC Flash Hash at Boot works as a bug as it should not "block" but show the Hash values instead.
Here’s a cleaned-up and more structured refactor that keeps the security rationale clear and avoids repetition:
When TC Flash Hash at Boot is enabled and the user enters an incorrect TC code, the device currently displays an “Invalid Tamper Check Code” warning. This behavior is misleading and undesirable.
Instead, the device should always display the image and the two word pairs, regardless of the entered TC code. The user must manually verify the displayed image and words, without the device validating the input or influencing the user’s perception of what is shown next.
The TC code is not a security PIN. The device should never be "blocked" based on an incorrect TC code. Treating it as a "blocking" or validating mechanism creates a false sense of security, especially given that the device is open and does not implement any real blocking protections.
For example, if settings are stored in flash, inserting an SD card with a settings.json containing:
{"settings": {"persist": {"location": "sd"}}}immediately disables TC Flash Hash at Boot. If settings are already stored on the SD card, simply removing the card disables it as well.
Because of this, the current behavior, showing an "invalid" warning and implying enforcement, is incorrect. TC Flash Hash at Boot should never block or validate, only display the hash-derived visuals for user verification.
Device(s) affected
Version affected
Describe the bug
When TC Flash Hash at Boot is
enabledand user provides a wrong TC code, the device should not warn the user aboutInvalid Tamper Check Code, instead it should just show the image and two pair of words, the user have to always verify the images and words instead of the device validating the input and influencing users to ignore what is shown next.The TC code is not a security PIN, the device should not be blocked, this could create a false sense of security false sensation of security while the devices are open and we don't have any form of "blocking", just as an example of how easy it is to disable this "blocking protection", if settings is stored in
flashyou just need to insert an SD card with asettings.jsonfile with contents{"settings": {"persist": {"location": "sd"}}}and boom TC Flash Hash at Boot is disabled, if settings were stored in theSDalready you just need to remove the SD card. So I consider the current wayTC Flash Hash at Bootworks as a bug as it should not "block" but show the Hash values instead.Here’s a cleaned-up and more structured refactor that keeps the security rationale clear and avoids repetition:
When TC Flash Hash at Boot is enabled and the user enters an incorrect TC code, the device currently displays an “Invalid Tamper Check Code” warning. This behavior is misleading and undesirable.
Instead, the device should always display the image and the two word pairs, regardless of the entered TC code. The user must manually verify the displayed image and words, without the device validating the input or influencing the user’s perception of what is shown next.
The TC code is not a security PIN. The device should never be "blocked" based on an incorrect TC code. Treating it as a "blocking" or validating mechanism creates a false sense of security, especially given that the device is open and does not implement any real blocking protections.
For example, if settings are stored in flash, inserting an SD card with a
settings.jsoncontaining:{"settings": {"persist": {"location": "sd"}}}immediately disables TC Flash Hash at Boot. If settings are already stored on the SD card, simply removing the card disables it as well.
Because of this, the current behavior, showing an "invalid" warning and implying enforcement, is incorrect. TC Flash Hash at Boot should never block or validate, only display the hash-derived visuals for user verification.
Device(s) affected
Version affected