ByteFau1t

From freemyipod.org
Revision as of 05:19, 1 December 2025 by TISFMiP (talk | contribs) (Article about the new vulnerability ByteFau1t)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.