[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. »


Je documente ici une attaque ciblée sur mon MacBook Air M4. Je développe le Projet Ibis et j'ai identifié le malware persistant sous le nom de Centauri. On est sur une compromission de bas niveau qui survit aux réinstallations classiques.

Preuves techniques (ifconfig) :

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
anpi1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether 56:9c:50:12:06:e8
media: none
status: inactive
anpi0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether 56:9c:50:12:06:e7
media: none
status: inactive
en3: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether 56:9c:50:12:06:c7
nd6 options=201<PERFORMNUD,DAD>
media: none
status: inactive
en4: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether 56:9c:50:12:06:c8
nd6 options=201<PERFORMNUD,DAD>
media: none
status: inactive
en1: flags=8922<BROADCAST,SMART,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=460<TSO4,TSO6,CHANNEL_IO>
ether 36:bd:66:e0:b1:00
media: autoselect <full-duplex>
status: inactive
en2: flags=8922<BROADCAST,SMART,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=460<TSO4,TSO6,CHANNEL_IO>
ether 36:bd:66:e0:b1:04
media: autoselect <full-duplex>
status: inactive
bridge0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
options=63<RXCSUM,TXCSUM,TSO4,TSO6>
ether 36:bd:66:e0:b1:00
Configuration:
id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
ipfilter disabled flags 0x0
member: en1 flags=3<LEARNING,DISCOVER>
        ifmaxaddr 0 port 8 priority 0 path cost 0
member: en2 flags=3<LEARNING,DISCOVER>
        ifmaxaddr 0 port 9 priority 0 path cost 0
nd6 options=201<PERFORMNUD,DAD>
media: <unknown type>
status: inactive
ap1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
ether 96:9b:76:25:40:15
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (none)
status: inactive
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
ether 92:70:2e:0e:5d:c3
inet6 fe80::c02:33df:c031:14d0%en0 prefixlen 64 secured scopeid 0xb 
inet 192.168.1.153 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fd68:a03e:86b2:8c00:43f:4f85:656d:fe60 prefixlen 64 autoconf secured 
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
awdl0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
ether 72:89:be:8b:88:32
inet6 fe80::7089:beff:fe8b:8832%awdl0 prefixlen 64 scopeid 0xd 
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
llw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether 72:89:be:8b:88:32
inet6 fe80::7089:beff:fe8b:8832%llw0 prefixlen 64 scopeid 0xe 
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (none)
utun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500
nd6 options=201<PERFORMNUD,DAD>
utun1: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::3fe7:f34d:8818:3be3%utun1 prefixlen 64 scopeid 0x10 
nd6 options=201<PERFORMNUD,DAD>
utun2: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 2000
inet6 fe80::5f96:bb7b:6bdb:980b%utun2 prefixlen 64 scopeid 0x11 
nd6 options=201<PERFORMNUD,DAD>
utun3: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1000
inet6 fe80::ce81:b1c:bd2c:69e%utun3 prefixlen 64 scopeid 0x12 
nd6 options=201<PERFORMNUD,DAD>

"Les logs de NetStat montrent des tentatives de connexion persistantes vers des IP localisées dans le 4ème arrondissement de Paris (secteur Mairie du 4e/Marais), ce qui confirme le caractère ciblé et local de l'agression. »
"Je défie quiconque de m'expliquer comment, sur un M4 avec FileVault activé et SIP verrouillé, un processus non-signé peut maintenir un bridge0 actif au boot. On est sur une vulnérabilité de la Secure Enclave ou un bypass de l'iBoot."

le pôrt ZERO et le bidge zero LOL .

Le malware Centauri a créé quatre tunnels utun pour fragmenter l'exfiltration de mes données Ibis.

Il a forcé le mode PROMISC pour sniffer mon réseau.

Il a généré un bridge0 sur un Port 0 inexistant pour bypasser la pile réseau standard de macOS.

Le support Apple (Case ID 20000113648213) est totalement dépassé. Un superviseur de niveau 2 m’a même demander un simple partage d’écran quand je lui ai mis le bridge0 sous le nez. preuve de l’incompétance des service du support Apple au senegal ou au Maroc ?

Est-ce que quelqu'un a des infos sur le comportement de Centauri sur puce M4 ? Je vais à l'Apple Store de Bordeaux demain pour un DFU forcé.

Ce message a été modifié par Usernet bis - 10 May 2026, 11:21.

Fichier(s) joint(s)

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

 

[ide508]

🥴