// La Iena Parla nel Sonno
Sezione 01. L'antefattoLa iena parla nel sonno. Da 26 anni. Borbotta frasi incomprensibili, a volte nomi, a volte lamentele. Una volta ha detto chiaramente "le galline". Un'altra volta "non hai comprato il latte". Io mi sveglio, ascolto, e dopo un po' ho capito che anche nel sonno la iena comunica. Non sa di farlo. Non lo controlla. Ma se stai attento, capisci tutto: con chi ce l'ha, cosa la preoccupa, cosa ha dimenticato di dirti da sveglia.
Il telefono sta sul comodino. Schermo spento. Dorme anche lui. Nel dormiveglia il cervello fa quello che fa sempre: collega cose che non c'entrano niente. Se la iena parla nel sonno senza saperlo... il telefono lo fa anche lui?
Mi alzo. Prendo un muletto dal cassetto. Un iPhone senza SIM, connesso al WiFi di casa. Nessuna app installata, nessun account di terze parti, solo iCloud. Lo appoggio sul tavolo, lancio bettercap e torno a dormire. Domattina guardo.
// L'Ascolto
Sezione 02. bettercap setup
Lo strumento è bettercap, una delle tante chicche che ha regalato al mondo il mio amico Simone (@evilsocket). Non seguo il calcio, ma TikTok ogni tanto mi propone quei video dove i più forti difensori italiani di sempre (Maldini, Cannavaro, Nesta) parlano di Ronaldo. Ti senti forte, ma lui è molto più forte. Ti senti veloce, ma lui ha un altro passo. Ecco, Simone è quel tipo di fenomeno lì. Il concetto di bettercap è semplice: con l'ARP spoofing dico al telefono "il router sono io" e al router "il telefono sono io". Tutto il traffico passa dal mio desktop. Io lo registro in un file .pcap e lo analizzo con calma. Il telefono non se ne accorge. Come la iena non si accorge che la ascolto parlare nel sonno. Differenza: la iena, se scopre che la registro, mi ammazza. Il telefono non può fare niente.
La iena dorme già. Il cane dorme. Il telefono sul tavolo sembra morto. Lo schermo è nero. Nessuna notifica, nessun suono, nessuna vibrazione. Silenzio.
bettercap, invece, registra.
// La Prima Notte
Sezione 03. I dati grezziLa mattina. Apro il pcap. Mi aspettavo silenzio. Trovo 1314 pacchetti.
Il telefono, a schermo spento, senza SIM, senza app, senza nessuno che lo toccasse, ha comunicato con internet per 16 ore (lo so, nessuno dorme 16 ore, un articolo vuole la sua narrativa). Ha avuto picchi di traffico alle 19:41 (52KB), alle 02:03 (22KB), alle 03:17 (65KB, il più grosso). Alle 3:17 di notte il telefono si sveglia e scarica 65 kilobyte da un server Apple in 40 millisecondi. Io dormivo. La iena dormiva (e parlava). Il telefono scaricava.
I grafici parlano chiaro. Il traffico non è costante. Ha un ritmo. Ha picchi e valli. Di sera è più attivo (il telefono sincronizza), poi cala, poi riparte alle 2-3 di notte con burst pesanti. Non è rumore casuale. È un organismo che respira.
58 MB di pcap, di cui 1314 pacchetti dal target (il resto è broadcast di rete, ARP, traffico del router). Il muletto ha generato circa 200 KB di traffico in uscita e scaricato circa 200 KB di dati in entrata. Senza che nessuno lo toccasse. Per 16 ore.
// I Tre Che Bussano di Notte
Sezione 04. Classificazione del trafficoChi parla col telefono di notte? Tre attori.
mDNS. Il chiacchierone. Ogni 10 minuti, tutta la notte, il telefono grida alla rete: "Sono un iPhone, cerco il Mac Pro, supporto HomeKit, cerco companion-link, cerco sleep-proxy." 1691 broadcast in 16 ore. Come la iena che anche dormendo fa sapere a tutti la sua posizione nel letto con gomitate strategiche.
APNs. Il postino che non molla. Apple Push Notification Service, porta 5223. Il server Apple bussa al telefono ogni 10 minuti. Se il telefono non risponde, Apple ribatte con backoff esponenziale: 0.2s, 0.5s, 1s, 2s, 4s, 8s. Come quando chiami la iena e non risponde: richiami dopo 30 secondi, poi dopo un minuto, poi dopo due. Apple fa uguale ma in millisecondi.
iCloud. Il ladro silenzioso. Porta 443, server Apple. I burst grossi: 52KB alle 19:41, 65KB alle 3:17, 29KB alle 3:27. Download bulk a pacchetti da 1448 byte (MTU). Sync iCloud? Aggiornamento configurazione? Telemetria? Non lo sappiamo, è cifrato. Ma sappiamo che succede, quando, e quanto pesa.
| Servizio | Protocollo | Pacchetti | Bytes | Ruolo |
|---|---|---|---|---|
| mDNS | UDP :5353 | 1691 | ~340 KB | Broadcast identità e servizi |
| APNs | TCP :5223 | 412 | ~48 KB | Push notifications / keepalive |
| iCloud | TCP :443 | 386 | ~195 KB | Sync, config, telemetria |
| DNS | UDP :53 | 87 | ~12 KB | Risoluzione nomi (in chiaro) |
| Altro | vario | 52 | ~8 KB | NTP, NetBIOS, ARP |
// L'Orologio Biologico del Telefono
Sezione 05. Analisi temporale e FFTIl telefono ha un ritmo. Come un organismo vivente. L'mDNS batte ogni ~10 minuti (periodicità quasi perfetta). L'APNs ogni ~10 minuti. Ma i burst iCloud sono irregolari, arrivano in cluster.
Per estrarre la periodicità dominante, usiamo la stessa matematica dell'articolo su Shazam: la Fourier Transform. Se Shazam trova le note in una canzone, qui troviamo il "battito cardiaco" del telefono. Prendiamo gli intervalli tra broadcast mDNS consecutivi, applichiamo la FFT, e cerchiamo il picco dominante.
Il picco è a ~600 secondi (10 minuti). Il telefono ha un orologio biologico.
| Servizio | Periodo dominante | Regolarità |
|---|---|---|
| mDNS | ~600s (10 min) | Quasi perfetta, jitter < 5s |
| APNs keepalive | ~600s (10 min) | Regolare con backoff occasionale |
| iCloud sync | Aperiodico | Cluster tra le 2 e le 4 di notte |
La iena ha il suo ritmo nel sonno: ogni 40 minuti circa cambia posizione e borbotta qualcosa. Il telefono ogni 10 minuti. Entrambi prevedibili. Entrambi inconsapevoli.
// Quanto sa il Postino?
Sezione 06. Information theory e classificazione bayesianaShannon, Bayes, mutual information. Il telefono spento trasmette informazione senza volerlo. Quantifichiamo.
Il classificatore bayesiano
Abbiamo visto che le dimensioni dei burst sono diverse per mDNS, APNs e iCloud. Ma quanto è affidabile questa classificazione? Possiamo quantificarlo con il teorema di Bayes.
Definiamo le classi: $C \in \{\text{mDNS}, \text{APNs}, \text{iCloud}, \text{DNS}, \text{altro}\}$. La feature osservabile è la dimensione del burst $X$ in byte. Il classificatore calcola:
Teorema di Bayes: la probabilità a posteriori del tipo di servizio data la dimensione del burst
Le probabilità a priori le estraiamo direttamente dalla cattura di 16 ore:
| Classe $C$ | Pacchetti | $P(C)$ | Dimensione tipica |
|---|---|---|---|
| mDNS | 1691 | 0.643 | $150\text{ - }250\text{ B}$ |
| APNs | 412 | 0.157 | $90\text{ - }500\text{ B}$ |
| iCloud | 386 | 0.147 | $1\text{ KB - }65\text{ KB}$ |
| DNS | 87 | 0.033 | $60\text{ - }150\text{ B}$ |
| Altro | 52 | 0.020 | variabile |
I range di dimensione sono quasi disgiunti. Un burst da 65KB non è mai un mDNS broadcast. Un pacchetto da 200 byte verso 224.0.0.251 non è mai un download iCloud. Questo significa che la probabilità a posteriori converge rapidamente a 1.
Esempio concreto. Osserviamo un burst da 1448 byte verso un IP nel range 17.x.x.x su porta 443. Quanto siamo sicuri che sia iCloud?
99% di probabilità: porta + IP + dimensione identificano il servizio senza ambiguità
99% a posteriori, 93% di information leakage. Se lo quantifichi con l'entropia di Shannon, i metadati (porta, IP, dimensione) rivelano il 93% dell'informazione sul tipo di servizio. La crittografia protegge il restante 7%. È come mettere una porta blindata su una casa con le finestre aperte.
L'information leakage dell'mDNS
Ma l'information leakage più grave è nell'mDNS. Ogni singolo broadcast rivela:
| Informazione | Bit stimati | Come la ottieni |
|---|---|---|
| Nome dispositivo | ~10 bit | iPhone.local nel campo mDNS |
| UUID | ~128 bit | UUID univoco nel broadcast |
| MAC address | ~48 bit | Header Ethernet del frame |
| Servizi supportati | ~8 bit | HomeKit, companion-link, sleep-proxy, ecc. |
| Timing (attività) | ~4 bit/ora | Periodicità e burst |
| Relazioni | ~12 bit | Cerca il Mac Pro, cerca dispositivi specifici |
Il telefono spento leaka più informazione della iena addormentata. La iena nel sonno rivela al massimo l'argomento delle preoccupazioni del giorno. Il telefono rivela: identità (nome, UUID, MAC), capacità (HomeKit, companion-link), timing (quando è attivo), relazioni (cerca il Mac Pro), e volumi di sync (iCloud).
Il paradosso: il telefono "spento" (schermo nero, nessuna interazione) rivela più informazione identificativa di una persona addormentata. L'mDNS da solo trasmette ~200 bit di informazione unica per broadcast, 1691 volte in 16 ore. Sono 338.200 bit di informazione identitaria sparati in broadcast sulla rete locale. Per un telefono che "non fa niente".
// Il Download delle 3:17
Sezione 07. Anatomia di un burst
Zoomiamo sul burst più grosso. 03:17:01, 48 pacchetti, 65KB, 40 millisecondi. Tutto da 17.248.179.231 porta 443.
Pacchetti da 1448 byte (MTU) in raffica. Pattern classico di bulk download TLS. Il server manda, il telefono riceve. Non c'è handshake, la connessione era già aperta. Il telefono si è svegliato, ha chiesto qualcosa a iCloud, e iCloud ha risposto con 65KB di dati.
Cosa c'è in quei 65KB? Non lo sappiamo. TLS. Ma la dimensione parla: non è un keepalive (26 byte), non è una notifica push (500 byte). È un download. Configurazione? Sync di un database locale? Aggiornamento del modello ML on-device? 65KB alle 3 di notte, mentre il proprietario dorme.
Il pattern è classico del bulk download: raffica di pacchetti MTU, zero gap inter-pacchetto, ACK finale. Lo vedresti identico scaricando una foto su WhatsApp o un allegato su Gmail. Solo che qui non c'è WhatsApp. Non c'è nessuno. È Apple che parla con il tuo telefono alle 3 di notte. E il telefono risponde.
// Il Telefono è Come la Iena
Sezione 08. Pattern matchingA questo punto il parallelo è strutturale.
| La Iena | Il Telefono | |
|---|---|---|
| Periodicità | ~40 min cambia posizione | ~10 min mDNS broadcast |
| Contenuto | Borbottii incomprensibili | Pacchetti cifrati |
| Metadati | Tono, volume, frequenza | Dimensione, timing, destinazione |
| Burst notturni | "Le galline!" (2-3 per notte) | iCloud sync (3-4 per notte) |
| Consapevolezza | Zero | Zero |
Ma possiamo andare oltre il parallelo qualitativo. I tre flussi di traffico (mDNS, APNs, iCloud) sono sincronizzati o indipendenti? Calcoliamo la cross-correlazione:
Cross-correlazione tra flussi di traffico: APNs vs iCloud
Scoperta: i burst iCloud sono spesso preceduti da un APNs push (~0.7s prima). Il postino bussa (APNs), il telefono apre (iCloud scarica). Apple usa questo meccanismo per tutto: il push notification service sveglia il dispositivo, e il dispositivo poi apre la connessione iCloud per scaricare i dati. Lo stesso pattern che WhatsApp usa per consegnare i messaggi.
Correlazione di Pearson tra burst APNs e burst iCloud: 0.84 con lag di 0.7 secondi
Il meccanismo è universale: sia WhatsApp che iCloud usano APNs come trigger. Il push arriva, il dispositivo si sveglia, la connessione dati si apre. La firma temporale (lag ~0.7s) è la stessa in entrambi i casi. Se vedi un burst APNs seguito da traffico porta 443 con un ritardo di 0.7 secondi, sai che il telefono ha appena scaricato qualcosa. Non serve sapere cosa.
// 43 Indirizzi, Zero Permessi
Sezione 09. La mappa dei serverIl telefono senza SIM, senza app di terze parti, parla con 43 IP diversi. Tutti Apple (range 17.x.x.x) più Akamai e Fastly (CDN di Apple).
Nessun server non-Apple. Questo telefono è un muletto pulito. Zero app installate. E parla comunque con 43 server.
| Categoria | Server | Esempi |
|---|---|---|
| Push notification | 7 | courier-push-apple.com, eu-central-courier-4.push-apple.com |
| iCloud content | 12 | p51-content.icloud.com, p13-ckdatabase.icloud.com |
| Apple config | 5 | configuration.apple.com, mesu.apple.com |
| Apple auth | 3 | gsa.apple.com, setup.icloud.com |
| Apple analytics | 2 | xp.apple.com, idiagnostics.apple.com |
| CDN (Akamai + Fastly) | 3 | a1887.dscq.akamai.net, apple.com.edgekey.net |
| Time (NTP) | 2 | time.apple.com, time.euro.apple.com |
| Router locale | 1 | 192.168.1.254, interroga via NetBIOS :137 |
Il DNS in chiaro grida tutto: courier-push-apple.com, eu-central-courier-4.push-apple.com, p51-content.icloud.com. Il DNS rivela dove vanno i pacchetti prima ancora che il TLS li cifri.
E c'è un dettaglio curioso: il router Fastweb (192.168.1.254) interroga il telefono via NetBIOS (porta 137): "come ti chiami?" Anche il router è curioso. Il telefono risponde. Senza che nessuno glielo abbia chiesto.
43 server per un telefono che "non fa niente". Se installi WhatsApp, Instagram, Gmail, entrano Facebook, Google, Cloudflare, AWS, e decine di tracker. Il traffico di un telefono in uso è ordini di grandezza superiore. Questo è il minimo sindacale. Lo scheletro. E già parla con 43 server.
// E Se lo Svegli?
Sezione 10. Da sonno a megafonoQuesto era il telefono a schermo spento. Senza SIM. Senza app. Il minimo sindacale. Il telefono è come la iena: parla nel sonno senza saperlo. Ma la iena quella notte aveva detto anche un'altra cosa.
Stavo quasi per addormentarmi quando si è girata e ha borbottato: "i pacchi della Sere... devo stare a casa domani...".
La Sere è nostra figlia. Compra roba online con una frequenza che farebbe invidia a un processo cron senza rate limiting. Vestiti, creme, aggeggi, cose che non sapevo esistessero e che probabilmente non esistevano fino a quando un algoritmo di Instagram non gliele ha messe davanti. Il problema è che vive da sola, e non è mai a casa. Mai. Una presenza quantistica: esiste, ma se provi a osservarla nel suo appartamento la funzione d'onda collassa e lei è altrove. Quindi si fa spedire tutto qui, perché qui c'è sempre qualcuno. Noi. La iena, io, il cane. La logistica inversa della generazione Z: produci ordini da casa tua, falli consegnare a casa dei tuoi genitori.
Risultato: il corriere suona il campanello tre volte a settimana. A volte quattro. A volte cinque. A novembre, a ridosso del Black Friday, ho smesso di contare. E io, senza aprire un singolo pacco, so tutto. So che ha comprato da Amazon lunedì perché il pacco ha il sorriso stampato sopra. So che mercoledì era Zalando perché la scatola è arancione. So che venerdì è arrivata una busta imbottita da un sito coreano di skincare con un nome impronunciabile. So che il pacco lungo e sottile è un treppiede perché nessun essere umano spedisce bastoni per altri motivi. So che la busta morbida è una cover per il telefono. So che quando arrivano tre pacchi lo stesso giorno c'è stato un momento di debolezza emotiva, probabilmente correlato a un lunedì difficile al lavoro. So che prima di Natale il ritmo raddoppia, e dopo Natale c'è il picco dei resi, che è l'equivalente logistico del rimorso.
Non ho aperto niente. Leggo le etichette. Peso le scatole. Conto la frequenza. Correlo i pattern. So tutto della Sere senza aprire una busta.
E la Sere non manda solo pacchi fisici. Manda messaggi su WhatsApp. Cifrati end-to-end. Pacchi chiusi. Ma se lo capisco io dai pacchi di cartone, posso capirlo anche dal traffico di rete?
Accendi lo schermo. Apri WhatsApp. Mandi un messaggio. Il traffico esplode. I server non sono più solo Apple, entrano Facebook, Cloudflare, analytics, tracker. I burst passano da 65KB a megabyte. Le connessioni simultanee da 3 a 30.
20 minuti di cattura con WhatsApp attivo. 21 eventi distinti. La classificazione per dimensione è banale:
| Dimensione burst | Tipo contenuto | Pacchetti tipici |
|---|---|---|
< 500 B |
Keepalive / ACK | 1-2 pkt da 107 byte |
1 - 8 KB |
Messaggio di testo | APNs burst + 3-5 pkt da 418 byte |
40 - 80 KB |
Foto | 30-80 pkt da 1514 byte (MTU) |
100 - 200 KB |
Video breve | 60-100 pkt da 1514 byte |
La sequenza è sempre la stessa. Un messaggio WhatsApp non arriva diretto. Passa per tre mani:
Il reverse DNS non lascia dubbi: whatsapp-chatd-edge-shv-01-mxp2.facebook.com, datacenter MXP2, Milano Malpensa. Sai dove passano i tuoi dati.
Il DNS grida tutto in chiaro: resolve whatsapp-chatd-edge-shv-01-mxp2.facebook.com, resolve media.fcdn.whatsapp.net. Nomi, ruoli, provider. Il DNS è il postino che grida ad alta voce l'indirizzo del destinatario prima ancora di prendere in mano la busta.
Non ho letto un singolo messaggio. Non ho decifrato niente. Ho solo guardato le dimensioni delle buste. Un burst da 75KB da Cloudflare è una foto (probabilità bayesiana: 97%). Un burst da 418 byte dopo un push APNs è un messaggio di testo. 188KB è un video. Il classificatore è banalmente accurato: non perché il modello sia sofisticato, ma perché i dati sono così ben separati che non serve sofisticazione.
Il telefono che parla nel sonno è già loquace. Da sveglio è un megafono. E il postino sorride.
// Cosa sa il Postino
Sezione 11. Il riassuntoRicapitoliamo. 16 ore di ARP spoofing sulla mia rete di casa. Nessuna decifratura. Nessun exploit. Nessuna vulnerabilità. Solo osservazione del traffico che passa. Ecco cosa so:
| Informazione | Come la ottengo |
|---|---|
| Che dispositivo hai | mDNS broadcast: iPhone, UUID, MAC |
| Cos'altro c'è in casa | mDNS: altri Apple, Chromecast, HomeKit |
| Quando il telefono è attivo | Periodicità mDNS e APNs (ogni 10 minuti) |
| Quando scarica dati | Burst iCloud su porta 443: dimensione, timing |
| Quanto scarica | Conteggio pacchetti da 1448 byte (MTU) |
| Dove vanno i dati | DNS in chiaro: courier-push-apple.com, p51-content.icloud.com |
| Quando dormi e quando sei sveglio | Pattern dei burst: cluster notturni tra le 2 e le 4 |
| Se il telefono è in uso | Volume traffico: 200KB dormendo, megabyte da sveglio |
| Quali server contatti | 43 IP: APNs, iCloud, config, auth, analytics, CDN |
| Che app usi (da sveglio) | DNS: whatsapp-chatd-edge-shv-01-mxp2.facebook.com |
Con una settimana di cattura ricostruisci la routine di chiunque. Quando si sveglia, quando va a dormire, quanto è attivo durante il giorno, se ha un picco di messaggi la sera. Il postino non sa cosa sogni, ma sa esattamente quando smetti di comunicare e quando ricominci.
E tutto questo senza toccare la crittografia. Senza exploit. Senza zero-day. Solo guardando le buste passare.
// E Allora Che si Fa?
Sezione 12. MitigazioniIl problema lo abbiamo visto. La domanda è: si può fare qualcosa? La risposta breve è: sì, in parte. La risposta lunga è che ogni contromisura copre un pezzo del problema, nessuna li copre tutti.
| Contromisura | Cosa protegge | Cosa non protegge |
|---|---|---|
| VPN | Nasconde il traffico al tuo ISP e a chi è sulla tua rete locale | Il provider VPN vede tutto. Sposti il problema, non lo risolvi |
| Tor | Nasconde origine e destinazione del traffico con routing a cipolla | Latenza alta, molti servizi non funzionano bene, l'exit node vede i metadati |
| DNS over HTTPS / DNS over TLS | Cifra le query DNS, il postino non grida più l'indirizzo | L'IP di destinazione resta visibile. Sai comunque dove vanno i pacchetti |
| Disabilitare mDNS | Ferma i 1691 broadcast che gridano nome, UUID, MAC | Rompe AirDrop, Handoff, HomeKit, e tutto l'ecosistema Apple |
Stewart Baker, ex consigliere generale della NSA, l'ha detto meglio di me: "I metadati ti dicono assolutamente tutto sulla vita di qualcuno. Se hai abbastanza metadati, non hai bisogno del contenuto."
La verità scomoda: non esiste una soluzione completa. Puoi cifrare il contenuto, cifrare il DNS, nascondere il mittente, instradare su Tor. Ma finché mandi pacchetti su una rete, quei pacchetti hanno una dimensione, un timing e una destinazione. E quei tre numeri raccontano quasi tutto. L'unico modo per non far sapere niente al postino è non spedire la lettera.
E io l'ho fatto su un muletto, in una sera, con un tool gratuito. Ma il tuo ISP lo fa da sempre. Fastweb, TIM, Vodafone, chiunque ti porti internet a casa: loro sono il postino permanente. Non hanno bisogno dell'ARP spoofing perché il traffico passa già da loro. Vedono tutto quello che ho visto io, 24 ore su 24, 365 giorni l'anno. E la normativa europea sulla data retention gli impone di conservare i metadati delle comunicazioni per mesi. Quello che per me è stato un esperimento di una notte, per loro è il mestiere.
// Non Dorme. Parla nel Sonno.
Sezione 13. ConclusioneIl telefono è come la iena. Parla nel sonno. Non sa di farlo. Non lo controlla. Ma se metti bettercap sul comodino (metaforicamente), senti tutto: con chi parla, quando, quanto, e con che ritmo.
In 16 ore, a schermo spento:
- 1314 pacchetti dal target
- 43 server Apple contattati
- 1691 broadcast mDNS ("sono qui, sono qui, sono qui")
- ~200 KB scaricati di notte
- Il burst più grosso alle 3:17: 65 KB in 40 ms
- Periodicità dominante: 10 minuti (mDNS e APNs)
- Correlazione APNs → iCloud: ρ = 0.84 con lag 0.7s
La crittografia protegge il contenuto. Ma il postino (che sia il router Fastweb, il tuo ISP, o il pirata con bettercap) vede tutto il resto. E il resto racconta tutto.
La prossima volta che metti il telefono sul comodino e pensi che sia spento, ricordati: non sta dormendo. Sta parlando. Come la iena. Solo che il telefono parla con Cupertino, e la iena parla delle galline.
Come tutti, in questa casa."
16 ore. 1314 pacchetti. 43 server. 1691 broadcast. 200 KB scaricati nel buio.
Il telefono non dormiva. Parlava con Cupertino.
La iena parlava delle galline.
Io stavo in mezzo, come sempre. Solo che stavolta registravo.