Difference between revisions of "ByteFau1t"
(Article about the new vulnerability ByteFau1t) |
(No difference)
|
Latest revision as of 05:19, 1 December 2025
Contents
ByteFau1t Vulnerability
ByteFau1t is a flaw in the IMG1 partition-type handling logic inside the SecureROM of the iPod nano (7th generation). The bug causes the integrity verification step for certain IMG1 images to be skipped, allowing modified data inside the rsrc partition to load without any signature checks.
The issue was discovered by Fong and publicly disclosed on 30 June 2025.
Affected Devices
| Device | Vulnerable? | Notes |
|---|---|---|
| iPod nano 7G (2012) | Yes | Verified working |
| iPod nano 7G (rev A)(2015) | Yes | Same SecureROM code path |
| iPod nano 6G | ? | Early tests suggest it does not work |
| Other S5L-based devices | Unknown | No confirmed evidence |
Summary
The vulnerability is triggered by modifying the *format byte* inside the IMG1 header stored within the rsrc partition. Inside the IPSW, this byte is found in the MSE file. There is only one instance of the signature:
38 37 34 30 32 2E 30 04
The final byte (04) represents an *unencrypted + signed* IMG1 image. Changing it to 03 marks the image as *encrypted + signed*.
When SecureROM processes an IMG1 image marked as encrypted (03) but whose contents are actually unencrypted, it enters an alternative decryption-handling path. This path has an unhandled condition for unencrypted data, causing the entire integrity verification step to be skipped. As a result, SecureROM accepts and loads modified IMG1 data as if it were valid.
What ByteFau1t Allows
- Modification of rsrc contents without using any previous untethered exploits And it doesn't require pressing any buttons.
ByteFau1t does **not** provide full SecureROM code execution, but it enables UI customization, resource patching, and limited modification of system content embedded in rsrc.
Technical Details
- The MSE file holds multiple IMG1 headers
- The format byte determines the SecureROM decryption/verification path
- The “encrypted + signed” path (03) expects a specific internal decoder state
- Feeding unencrypted data into this path results in an inconsistent state
- In this state, the final cryptographic integrity check is skipped entirely
- SecureROM proceeds as though the image were verified
This is a logic flaw, not a memory-corruption vulnerability.
Status / Fix
| Property | Value |
|---|---|
| Fixed in | Not fixed |
| Patched devices | None |
| Discovered by | Fong |
| Disclosed | 30 June 2025 |
Nano 6G Possibility
Attempts to apply the method to the iPod nano 6G were unsuccessful. Nano 6 SecureROM uses a probably different circuit. Current research status: incompatible.