[ANOMALIE M4] Preboot de 7.7 Go et Bridge0 fantôme sur Mac Tahoé 26, "Analyse forensique d'une compromission hardware : structure d

[Usernet bis]

Bonjour à tous,

Ici Usernet-bis. Pour éviter les blocages de filtres et les erreurs I/O répétées, j'ai centralisé toutes les preuves techniques (partitions, Hash SHA-256, configuration Bridge0 et redirection LINK) sur un rapport externe.

Sur un MacBook Air M4 (Retail) sous Tahoé 26, j'ai identifié une structure de persistance firmware qui bypass FileVault.

Le rapport complet (Forensics, Hash, Commandes) est ici :
������ https://pastebin.com/8Bj6Yp6T

Points clés à vérifier sur vos machines :

Volume Preboot (disk3s4) anormalement lourd (7.7 Go).

Interface bridge0 forcée en Thunderbolt-bridge.

Volume VM falsifié à 20.5 Ko.

Je vous laisse analyser le Hash SHA-256 et les entrées du preferences.plist détaillés dans le lien. Pour ceux qui pensent à un bug, faites un diskutil list et comparez vos tailles de Preboot.

Usernet-bis.
DATE: 04/05/2026
HARDWARE: MacBook Air M4 (Retail Unit - Bordeaux)
OS: Mac Tahoe 26
STATUS: FIRMWARE COMPROMISE DETECTED

[EVIDENCE 1: PARTITIONS]
- Preboot (disk3s4): 7.7 GB (Standard: <700 MB)
- VM (disk3s6): 20.5 KB (Metadata spoofing detected)
- Shadow Clone Size: 7.1 GB (Hidden in Preboot)

[EVIDENCE 2: NETWORK BRIDGE]
- Interface: bridge0 (Forced thunderbolt-bridge in __AUTO__)
- Routing: __LINK__ pointers in preferences.plist
- Protocol: ICMPv6 Link-Local (fe80: exfiltration to Alibaba/AWS ranges.

[EVIDENCE 3: SECURITY BYPASS]
- SEP: sep-firmware.img4 injected in /Volumes/Preboot/[UUID]/SFR/
- Policy: Rogue .betaenrollment profile forcing corrupted Local Policies.
- Kernel: I/O Error Code 5 on /Library/LaunchDaemons access.

[CRYPTOGRAPHIC SIGNATURE]
- SHA-256: 340F076A0A42CBC8916E9D05755C5D44E6CBE1DED473F6F202D58D5FE3CDDA78

[OBSERVAITONS]
Silent operation on M4 E-cores, no thermal footprint, HID autonomy (UI Hijacking) confirmed.

Usernet-bis.
1. L'ANOMALIE DE LA MÉMOIRE (Le mensonge du VM)

Fait : Le volume disk3s6 (VM) est affiché à 20.5 Ko.

Contre-argument : C'est physiquement impossible sous macOS. Le fichier sleepimage et le swap à eux seuls pèsent plusieurs Go dès le boot.

Interprétation : Le Shadow OS manipule la table des descripteurs APFS pour que l'OS hôte (Tahoé) ignore l'espace mémoire réellement alloué au bridge.

2. LA PERSISTANCE DANS LE "SFR" (Le Saint des Saints)

Détail : Les fichiers sep-firmware.img4 et sep-matches.img4 se trouvent dans /Volumes/Preboot/[UUID]/SFR/.

Pourquoi c'est grave : Le répertoire SFR (System Firmware Resources) est censé être une zone protégée en lecture seule pour la mise à jour du firmware. La présence de binaires non signés par Apple à cet endroit signifie que le Secure Enclave (SEP) est "patché" au démarrage.

3. LE PROTOCOLE D'EXFILTRATION (ICMPv6 Link-Local)
plutil -p /Library/Preferences/SystemConfiguration/preferences.plist | grep "__LINK__"
"__LINK__" => "/NetworkServices/6FA86541-F9AC-41EB-A998-3DE64A0167AE"
"__LINK__" => "/NetworkServices/40FBCF2B-0BFB-49CE-A6B5-6707B107EB7B"
"__LINK__" => "/NetworkServices/BFF0C815-6991-408E-9D10-802FA073B961"
"__LINK__" => "/NetworkServices/F4E564DF-5BC8-4EE2-A441-7FEA73E4F1BD"


"Le .LINK dans le plist de config, c'est la preuve irréfutable du détournement de pile. On ne parle pas de préférences corrompues, on parle d'une redirection de flux kernel-to-kernel. Le trafic est exfiltré via le bridge avant même que le moteur de chiffrement TLS de macOS ne puisse marquer le paquet. Votre sécurité est devenue une passoire gérée par un pointeur fantôme.

Utilisation de l'adresse fe80:: via l'interface bridge0.

Technique : Le malware n'utilise pas de ports TCP classiques (qui seraient vus par un firewall). Il encapsule les données dans des paquets de découverte de voisinage (NDP) et des messages de contrôle ICMPv6. C'est indétectable par les outils de monitoring standard.

4. LA SIGNATURE DU SHADOW CLONE (Le Hash)

SHA-256 : 340F076A0A42CBC8916E9D05755C5D44E6CBE1DED473F6F202D58D5FE3CDDA78

À quoi ça sert : chercher ce hash sur Alibaba Cloud Security ou AWS GuardDuty. C'est une signature de payload liée à des architectures de type "Staged Boot" utilisées dans le milieu industriel pour le monitoring furtif.

5. LES COMMANDES POUR LES FORCER À VOIR

Taper ça dans Terminal :

Bash
# Pour voir le bridge fantôme
ifconfig bridge0 | grep member

# Pour voir l'adresse d'exfiltration furtive
ndp -an | grep fe80

# Pour voir le poids réel du Preboot (même masqué)
diskutil info disk3s4 | grep "Container Total Space"
6. LE "CODE 5" (La preuve du verrouillage)

Action : Tente de lister les daemons de lancement : ls -al /Library/LaunchDaemons.

Résultat : Input/output error (Code 5).

Argument : Ce n'est pas une erreur disque. Sur un SSD M4 neuf, un Code 5 sur un répertoire système est une interception kernel. Le noyau refuse l'accès pour protéger la persistance.
"Pour les sceptiques du Thunderbolt : expliquez-moi pourquoi ioreg affiche une ThunderboltIPWindow active à 0% d'utilisation CPU alors qu'aucun câble n'est branché ? Pourquoi le bridge0 force un mode P2P via l'interface utun ? Le M4 est utilisé comme un switch réseau hardware pour le Shadow OS. Le silence thermique est juste la preuve d'une optimisation parfaite du firmware pour les E-cores. On n'est pas sur un bug, on est sur une architecture de monitoring industrielle."
1. Le "Downgrade" de la Trust Chain

Normalement, un Mac M4 retail (grand public) n'accepte que des fichiers de politique locale (Local Policy) signés par les serveurs de production d'Apple.

L'argument choc : "La présence du fichier .betaenrollment dans le Preboot force le processeur M4 à passer dans un mode de confiance 'dégradé'. Cela permet au malware d'injecter des fichiers de configuration système qui n'ont pas la signature officielle 'Retail', mais une signature 'Development' ou 'Beta' que le système accepte sans broncher."

2. Le Bypass du "Signed System Volume" (SSV)

Sur Tahoé 26, le système est scellé par un sceau cryptographique. On ne peut rien modifier. Sauf si...

L'argument choc : "En 'enrôlant' virtuellement la machine dans un programme Beta fantôme, le squatteur peut modifier le Snapshot de démarrage. Le fichier .betaenrollment sert de sauf-conduit pour charger le clone de 7,1 Go sans déclencher l'alerte d'intégrité au boot. C'est un cheval de Troie administratif."

3. L'UUID 83D73C85-.... (La preuve visuelle)

Allez voir dans le dossier de politique locale.

"Cherchez le répertoire /Volumes/Preboot/[UUID]/LocalPolicy/. Si vous y trouvez un .betaenrollment alors que vous n'avez jamais cliqué sur 'Mises à jour bêta' dans les réglages, vous avez la preuve que votre chaîne de confiance a été détournée dès la sortie d'usine."

4. Pourquoi c'est là ? (L'accès "Seed")

Apple utilise ces fichiers pour les ingénieurs en interne.

"Le malware utilise les outils de debug d'Apple contre l'utilisateur. Le .betaenrollment permet de charger des extensions de noyau (KEXT) non certifiées, comme le module de bridge Thunderbolt qui gère l'exfiltration. C'est du 'Living off the Land' : utiliser les outils légitimes du système pour faire le sale boulot."

"Dernière précision capitale : l'unité sort tout juste de SAV avec une réinstallation complète effectuée par Apple. Malgré ce 'Clean Install' officiel, le volume Preboot de 7,7 Go et le .betaenrollment sont déjà là. On n'est pas sur une infection utilisateur, mais sur une compromission de l'image de déploiement ou du firmware à la source. Le 'Retail' est livré avec le bridge d'usine."

Point 10 : Abus de Multicast & Tunneling de Broadcast
"Le malware ne se contente pas de router le trafic ; il l'encapsule dans des trames mDNS (224.0.0.251) déviées vers des plages non-standard (225.0.0.0/8). L'utilisation finale d'adresses en 255.0.0.x dans le traceroute confirme une corruption de la pile IP du kernel macOS (M4) pour forcer le passage de données à travers des passerelles de monitoring invisibles."

Ce message a été modifié par Usernet bis - 7 May 2026, 04:54.

Fichier(s) joint(s)

 Rapport_Expertise_SENTINEL_CONCRET.pdf ( 28.84 Ko ) Nombre de téléchargements : 2