Va bene, ragazzi.
Ricevitore broadcast.
Ne abbiamo parlato un po', ma ora scopriamo cosa sono, come funzionano e,
soprattutto, come sfruttarli.
Bene, diamo un'occhiata.
I ricevitori broadcast su un sistema Android sono davvero straordinari.
È una sorta di sistema di notifica per le applicazioni.
Supponiamo di avere molte applicazioni in esecuzione sul nostro smartphone.
Forse non dobbiamo dare per scontato questo, perché nella maggior parte dei casi è così.
Abbiamo quindi una posta, una calcolatrice e anche un'applicazione musicale.
Ora stiamo ascoltando della musica all'interno della nostra applicazione musicale e stiamo collegando
delle cuffie al nostro smartphone.
Si tratta di un evento che lo smartphone riceve e trasmette a tutte le applicazioni.
Si tratta di un messaggio di trasmissione, quindi ogni applicazione verrà informata che è stata collegata una cuffia: l'applicazione
e-mail, l'applicazione calcolatrice, l'applicazione musicale e l'applicazione SMS.
Alcuni di loro potrebbero dire: "Che diamine, non me ne frega niente di questo e semplicemente lo ignorano".
Ma la nostra applicazione musicale si prende cura di questo evento perché ora possiamo reagire a questo evento.
Se non stiamo collegando delle cuffie, possiamo reagire a questo evento nel metodo on receive.
Quindi, all'interno del metodo di ricezione, stiamo dicendo: "Ok, se vengono collegate delle cuffie, allora fai
qualcosa".
Possiamo, ad esempio, mettere in pausa la musica, abbassare il volume o sintonizzarla in modo da renderla
molto alta, il che non ha assolutamente senso.
Ma potremmo.
Va bene.
Questo è in sintesi il ricevitore broadcast.
Sullo smartphone si verifica un evento.
Lo smartphone sta informando ogni applicazione di questo evento.
E all'interno della nostra applicazione, possiamo reagire a questo nel metodo on receive.
Va bene.
Ok.
Perfetto.
La finestra temporale di cui disponiamo è, credo, di circa 5 secondi.
Ma non citatemi su questo punto.
Dopo un certo periodo di tempo, questo evento di trasmissione scompare come se non fosse mai accaduto nelle versioni più recenti.
Possiamo estendere questa finestra temporale perché possiamo creare eventi broadcast asincroni.
Ma questo non è nulla di cui dobbiamo preoccuparci come attaccanti.
È un aspetto di cui lo sviluppatore deve occuparsi.
Quindi la domanda potrebbe essere: quali altri tipi di eventi stiamo vivendo sul nostro smartphone?
Ma lo smartphone informa ogni applicazione in merito.
Beh, abbiamo un sacco di altri eventi.
Un altro potrebbe essere, ad esempio, se la batteria si sta scaricando, questo è l'evento di sistema che
viene trasmesso a tutte le applicazioni.
Anche questo è piuttosto importante.
Cioè, se ora siete uno sviluppatore e nella nostra applicazione abbiamo un enorme stack che non è stato salvato
e lo smartphone sta esaurendo la batteria.
È meglio salvarlo subito, perché se lo smartphone viene spento, potremmo perdere alcune informazioni della nostra
applicazione.
E questo è qualcosa che non vogliamo assolutamente avere.
Quindi, anche l'esaurimento della batteria è un evento che verrà inviato a tutte le applicazioni.
Oltre a questo, abbiamo molte altre cose.
Ad esempio, se si attiva la modalità aereo, se cambia la connessione Wi-Fi, se si cambia il fuso orario
nello smartphone, se si collega qualcosa tramite USB, se si fa qualcosa con la fotocamera, se si distribuisce
un pacchetto sullo smartphone, se si ha a che fare con il Bluetooth.
Quindi, se stiamo facendo una richiesta di accoppiamento, ci sono molte trasmissioni
in giro.
Si tratta quindi di eventi trasmessi dal sistema.
Ma possiamo anche definire il nostro evento di broadcast personalizzato, in modo da definire il nostro metodo di invio e di ricezione
e quindi possiamo usarlo per inviare il nostro evento di broadcast.
Cioè, le altre applicazioni potrebbero non reagire a questo evento perché non conoscono questo evento personalizzato,
ma questo può essere usato per scambiare informazioni tra le applicazioni.
Tra poco daremo un'occhiata a questo e ai ricevitori broadcast personalizzati.
Per ora parliamo prima di tutte le trasmissioni, perché anche questo aspetto è piuttosto importante.
Gli eventi broadcast hanno una sorta di priorità, il che significa che abbiamo queste tre
applicazioni, il nostro sistema, l'applicazione SMS e la nostra applicazione che vuole
leggere gli SMS.
Questo è assolutamente perfetto se l'utente dà il permesso e se abbiamo un'applicazione bancaria
che aspetta quei dieci numeri, ora possiamo definire una certa priorità per queste applicazioni.
Cioè, questo è stato fatto dallo sviluppatore.
Quindi lo sviluppatore attribuisce una certa priorità a un determinato file.
Il file di cui stiamo parlando è l'esempio di manifest di Android.
Quindi, stiamo definendo la priorità del nostro ricevitore di trasmissione.
Ok.
Quindi la domanda è: dov'è la differenza?
Supponiamo che un SMS arrivi allo smartphone e che anche questo sia un evento di trasmissione.
Questa volta, però, non tutte le applicazioni vengono informate, ma solo quella con la
priorità più alta, ovvero l'applicazione SMS di sistema.
Quindi a questo punto qui e ora c'è questa parte complicata in questa applicazione, che riceve questo evento
per primo può decidere se vuole inoltrare questo evento a tutte le applicazioni privilegiate inferiori.
In questo caso, ad esempio, la nostra applicazione.
In caso affermativo, la decisione spetta a noi.
Inoltrare o meno l'evento all'applicazione bancaria.
L'applicazione bancaria non si accorge che è stato ricevuto un SMS in questo momento.
Ecco come funziona la trasmissione di un ordine.
Abbiamo ottenuto una certa priorità.
Lo sviluppatore assegna la priorità da solo e poi l'applicazione può decidere di inoltrare questo evento
a tutti i privilegiati inferiori o meno.
Quindi questo può essere assolutamente ridicolo.
E in passato era perché un Android 4. 3.
Sì, è molto vecchio, credo del 2010 11, ma c'era una vulnerabilità enorme, enorme riguardo
a questo perché all'interno di Android 4. 3, è possibile creare un'applicazione e impostare la priorità a 999, superiore
a quella dell'applicazione SMS di sistema.
E oggi questa parte assolutamente ridicola, se lo smartphone sta ricevendo questo SMS, l'aggressore sta avendo
questo SMS per primo, e l'aggressore può decidere di informare l'applicazione SMS di sistema di questo
evento in modo che l'aggressore possa questa linea.
Lo smartphone non mostra alcuna prova della ricezione di un SMS.
Non c'era nessun segnale, nessun audio e nessun pop-up per quanto riguarda questo.
E ora immaginate cosa era possibile fare in quel momento?
Insomma, l'attaccante potrebbe leggere un SMS e decidere di inoltrarlo.
Supponiamo di aver ottenuto un'applicazione bancaria e che l'applicazione bancaria stia aspettando il numero di transazione
estera in dieci.
L'attaccante sta ricevendo questo tempo proprio ora.
E poi l'attaccante può decidere se l'applicazione bancaria deve ricevere questo stordimento
o meno.
Insomma, assolutamente ridicolo, no?
Se l'aggressore ha compromesso anche il conto bancario di questa persona, allora l'aggressore può
usare questo ton e l'utente non si rende nemmeno conto di cosa sta succedendo.
Quindi l'utente potrebbe ordinare un secondo turno che l'attaccante potrebbe semplicemente inoltrare all'utente.
E l'utente pensa che ci sia qualcosa di strano, ma ora ho la mia tonalità.
Ma questo non funziona più e i soldi sono finiti.
Si trattava quindi di una vulnerabilità assolutamente enorme, che è stata risolta in Android 4. 4.
Questo tipo di vulnerabilità potrebbe non verificarsi più così spesso, almeno per le applicazioni di sistema,
ma può essere abbastanza probabile o curare le applicazioni personalizzate.
Quindi, se l'applicazione personalizzata imposta una priorità finale nel centro degli Stati Uniti, un utente malintenzionato potrebbe
essere in grado di impostare una priorità più alta e quindi di manometterla.
Credo che ora sia limitato a 100, ma non sono sicuro al 100% nemmeno di questo.
Almeno non è più il 999.
Ok, fin qui tutto bene.
Credo che in questo momento ci sia una buona sensazione per quanto riguarda gli eventi di trasmissione.
Sappiamo che se un evento si verifica sullo smartphone, quest'ultimo informa le applicazioni di questo
evento.
Può essere tutto in una singola applicazione e possiamo avere un ordine di trasmissione, il che significa
che c'è una sorta di priorità in questa catena di notifica.
Va bene.
Ok.
La domanda principale in questo momento potrebbe essere: dove dobbiamo cercare questi eventi di trasmissione?
Quindi, come attaccante, come possiamo scoprire quale evento sta ascoltando l'applicazione?
Ad esempio, l'applicazione di posta elettronica potrebbe non preoccuparsi del collegamento di alcune cuffie.
Dove possiamo trovare queste informazioni?
La risposta è qui, nel manifest XML di Android, almeno per le applicazioni Android fino alla versione
otto.
Quindi, nella versione otto di Android, c'è stato un enorme cambiamento per quanto riguarda questo progresso e questo mi ha colto assolutamente
alla sprovvista.
Quindi questo è stato sì, è stato un po' un dolore.
Ma non preoccupatevi, stiamo facendo entrambe le cose.
Stiamo adottando il vecchio approccio che è stato definito nel Manifest XML di Android, e stiamo anche adottando
il nuovo approccio che è ben preparato per le applicazioni moderne in questo momento.
Va bene.
Ok, perfetto.
Esaminiamo le applicazioni che sono inferiori alla versione otto di Android.
Dobbiamo quindi dare un'occhiata al manifest XML di Android, perché qui non abbiamo la definizione
di ricevitore.
Quindi abbiamo il nostro testo del ricevitore all'interno del testo del ricevitore.
Abbiamo, ad esempio, il nome Android, il mio ricevitore broadcast.
Questa è la classe Java in cui è stato definito il ricevitore broadcast.
Se diamo un'occhiata a questo, troveremo il codice dell'applicazione relativa a questo ricevitore
broadcast.
Anche il metodo del ricevitore, che è il metodo più importante se stiamo analizzando e trasmettendo un ricevitore.
Va bene.
Ok, perfetto.
Poi ci sono gli alimentatori di intenti, che sono molto importanti per molti aspetti.
La prima cosa importante è che avere questi filtri per i contenuti significa avere un'esportazione implicita.
Quindi questo ricevitore broadcast viene ora esportato e naturalmente deve essere esportato perché altrimenti non
potrebbe raggiungere o ricevere quegli intenti, quindi non riconoscerebbe nemmeno che è accaduto un evento.
Questo è anche il caso della maggior parte o quasi.
Tutti i ricevitori di trasmissione vengono esportati all'esterno, il che potrebbe renderli vulnerabili agli attacchi.
Ecco perché i ricevitori broadcast sono molto importanti nella nostra applicazione e analisi.
Quindi il filtro degli intenti sta esportando questo ricevitore di broadcast verso il mondo esterno, in modo che possa reagire
a questi intenti.
Sta ascoltando lo smartphone e ora è in attesa delle tre azioni che abbiamo.
Ha acquistato lock boot completato e quick boot power on.
Tutti riguardano il processo di avvio dello smartphone.
Quindi, una volta terminato l'avvio, lo smartphone informa di questo processo le applicazioni
che sono in ascolto di questo evento.
Quindi lo smartphone invia uno dei tre, solo due di essi a queste applicazioni.
La domanda potrebbe essere: perché avere tre azioni per un solo compito?
La risposta è: produttori.
I produttori possono definire i propri eventi di trasmissione.
E se vogliamo avere un'applicazione compatibile con molti produttori, dobbiamo includerli
tutti.
Quindi potrebbe essere solo uno su dieci, ad esempio, l'intento di questo avvio che viene inviato.
Ma sì, potrebbe dipendere dal produttore.
Quindi, come attaccante, non ci preoccupiamo troppo di questo aspetto perché è anche, di nuovo, la parte dello sviluppatore.
Lo sviluppatore deve assicurarsi che l'applicazione sia compatibile con altri produttori e
deve occuparsi di tutte queste diverse finalità.
Va bene.
Ok.
Noi, in qualità di aggressori, li consultiamo semplicemente e sappiamo che cosa sta ascoltando questa applicazione.
Va bene.
E sì, questo è tutto.
Quindi abbiamo la classe Java, il mio ricevitore broadcast, abbiamo il filtro intent,
il che significa che la nostra classe viene esportata e stiamo ascoltando tre azioni in questo momento.
Ok.
Oltre a queste azioni, potremmo avere ancora una volta le seguenti.
Potremmo avere categorie e dati inclusi in questa cartella di intenti.
Ma il più delle volte si tratta semplicemente di azione.
Quindi l'azione è la parte più importante.
OC L'invio e la ricezione di questi intenti possono essere combinati con le autorizzazioni.
Quindi, all'interno della nostra applicazione, se vogliamo ascoltare questo intento, dobbiamo avere l'autorizzazione
nel nostro manifest Android a ricevere l'avvio completato, perché questo è qualcosa di cui l'utente deve essere informato, perché
potrebbe essere facilmente utilizzato in un'applicazione dannosa.
Non significa che se un'applicazione utilizza questa autorizzazione sia automaticamente dannosa.
Ma si tratta di una sorta di attività automatica per eseguire la nostra applicazione dopo un rapporto di sistema.
Quindi, se abbiamo un'applicazione di attacco, non dobbiamo aspettare che l'utente apra l'applicazione.
Potremmo definire un servizio che viene avviato quando viene ricevuto l'evento di trasmissione e che viene eseguito
silenziosamente in background, in modo che l'utente non si accorga che l'applicazione è stata avviata.
È come eseguire l'attività automatica su un sistema Windows.
Quindi, ogni volta che si riavvia il sistema, l'altra attività viene avviata o eseguita automaticamente nel programma.
E anche qui ci possono essere casi d'uso assolutamente validi, ma ovviamente questo può essere usato anche per le minacce informatiche
e quindi dobbiamo avere questa autorizzazione.
Un altro esempio potrebbe riguardare le chiamate in arrivo, se non si dispone di questa autorizzazione
nella nostra applicazione Android, ma si ha la possibilità di manometterla negli eventi broadcast.
Voglio dire, sarebbe assolutamente esilarante, no?
Quindi un utente malintenzionato potrebbe creare un'applicazione che non richiede l'autorizzazione alla chiamata, ma che potrebbe manomettere
questa autorizzazione.
Pertanto, ciò non è ovviamente possibile.
Dobbiamo impostare questa autorizzazione e poi potremo ricevere e interagire con gli eventi di trasmissione
relativi alle chiamate in entrata e in uscita.
Va bene.
Finora abbiamo tenuto presente che abbiamo la nostra cartella degli intenti all'interno della cartella degli intenti,
abbiamo le nostre azioni e queste sono quelle intense in cui ascoltiamo gli intenti che possono avere determinati permessi.
Potrebbe trattarsi di permessi di sistema, ma anche di permessi utente legati ad essi.
Quindi, se si desidera utilizzarli, dobbiamo richiedere tali autorizzazioni.
Va bene.
Ma questo approccio è purtroppo superato dalla versione otto.
Quindi non funziona più.
Si ottiene un errore, l'esecuzione in background non è consentita e quindi dobbiamo definirla
direttamente nel codice Java e si presenta così.
Quindi nel codice Java abbiamo questo ricevitore registrato che accetta due argomenti.
Il primo è il nome, il nome del ricevitore broadcast che vogliamo registrare.
In questo caso si tratta della mia trasmissione.
Il secondo parametro è un filtro di intento.
Quindi le cose che abbiamo definito nel manifest di Android saranno ora definite nel codice Java.
Quindi forniamo come parametro il nome della nostra azione, in questo caso l'avvio.
Se si desidera avere più azioni, si possono applicare altre azioni.
Poi abbiamo il nostro ricevitore broadcast, il mio broadcast, che definisce un nuovo ricevitore broadcast e poi
abbiamo di nuovo il nostro metodo ricevitore che contiene il codice.
Quindi questo è il nuovo approccio e dobbiamo affrontare molte cose in questo momento.
Il primo è che l'applicazione deve essere eseguita, perché se l'applicazione non è in esecuzione,
non c'è il codice Java che registra il ricevitore broadcast.
Quindi l'esecuzione in background non è più consentita.
La seconda sfida è che se si utilizzano strumenti automatizzati, questi potrebbero non essere stati aggiornati in base
a questo approccio.
Quindi, se cercano di identificare i ricevitori broadcast, potrebbero semplicemente dare un'occhiata all'esempio
del manifest di Android, ma non al codice dell'applicazione, il che significa che potrebbero sfuggirci alcune cose ed è per questo che
siamo qui.
Perché qui impareremo i retroscena di questa situazione e ora potremo affrontarla da soli.
Quindi, nel caso in cui lo strumento automatico manchi qualcosa, possiamo cercarlo manualmente, almeno nella sezione
di reverse engineering.
Impareremo a decompilare le applicazioni e a dare un'occhiata al loro codice.
E poi saremmo in grado di identificare i metodi come il ricevitore registrato o i metodi di ricezione.
Va bene.
Ok.
Quindi, se utilizzate strumenti automatizzati, assicuratevi che funzionino con gli approcci più recenti.
Voglio dire, la più recente per quanto riguarda Android 8.
Ma sì, questo potrebbe non essere il caso di tutti gli strumenti presenti in questo momento e alcuni di essi potrebbero non
essere sviluppati ulteriormente.
Pertanto, utilizzando strumenti automatizzati, non c'è assolutamente alcun problema.
Ma assicuratevi che funzionino correttamente.
Va bene.
Ok.
Ora sappiamo come identificare i ricevitori di trasmissione e come fornire un'applicazione.
Dobbiamo dare un'occhiata all'esempio del manifest di Android o direttamente al codice Java per vedere
quali azioni sono state definite e quali azioni sono in ascolto dell'applicazione.
Qual è la domanda?
Come possiamo sfruttarli?
La risposta è: dipende.
Quindi, se state dando un'occhiata a questo, l'attivazione e la trasmissione del ricevitore possono essere effettuate
da un'applicazione dannosa in esecuzione sullo smartphone o direttamente dalla shell ADB.
Quindi, per i test, la shell ADB va assolutamente bene.
Ma per quanto riguarda il vettore di attacco pratico, presumo che debba trattarsi di un'applicazione dannosa perché se si dispone
dell'accesso ADB, potrebbe non essere necessario attivare e trasmettere l'evento.
Va bene.
Ok.
Quindi, se si attiva un evento di trasmissione, la domanda è: cosa può andare storto?
Una risposta a questa domanda è se applichiamo alcune informazioni sensibili nel nostro intent, in modo che un evento
broadcast venga inviato da un intent, il che significa che possiamo anche applicare dati a questo evento, come questo qui.
Quindi possiamo inserire alcune stringhe in questo evento di broadcasting e poi inviarlo a ogni applicazione
che può essere ascoltata da un utente malintenzionato e che riceve questo intento.
In questo caso, l'aggressore potrebbe semplicemente recuperare il token che è stato trasferito tramite questo evento di trasmissione.
Quindi dobbiamo verificare se in questi intenti vengono memorizzate informazioni sensibili.
L'abbiamo visto nella parte relativa al fiuto per le intenzioni.
Questo è esattamente ciò che stiamo vivendo.
Anche in questo caso, un altro problema potrebbe riguardare le autorizzazioni.
Quindi, se gli sviluppatori definiscono un'autorizzazione personalizzata, necessaria a un'applicazione per ricevere o inviare
eventi di trasmissione, noi, in qualità di aggressori, potremmo semplicemente rivendicare questa autorizzazione se non è stata protetta in
modo adeguato.
È stato protetto correttamente solo se utilizza la firma del livello di protezione.
Tutto il resto non è più sotto il controllo dello sviluppatore.
Parliamo di questo livello di protezione della firma nella sezione dedicata alla firma.
Poi analizzeremo il significato di tutto ciò.
Finora significa semplicemente che entrambe le applicazioni devono essere firmate con la stessa chiave, e questo è qualcosa che l'aggressore
non può falsificare, quindi un aggressore non può falsificare questa autorizzazione.
Quindi l'attaccante non può semplicemente affermare che l'applicazione attaccata è stata firmata con la stessa chiave
privata.
Questo non è il caso, e quindi l'attaccante non potrebbe nemmeno manomettere questi eventi
di trasmissione, a meno che non abbia i privilegi di root.
Ma poi abbiamo altri problemi.
Ok.
In sintesi, se l'attaccante non ha i privilegi di root e il livello di protezione è in fase di firma,
non può interagire con il ricevitore broadcast.
Ma se si tratta semplicemente di un'autorizzazione personalizzata come questa qui, l'aggressore può includere questa
autorizzazione nella propria applicazione.
E quindi l'attaccante sarebbe di nuovo in grado di ricevere e inviare questi eventi di trasmissione.
Quindi la vulnerabilità potrebbe essere la seguente.
Lo sviluppatore ha incluso questa autorizzazione personalizzata nella propria applicazione e si affida a questa che
nessun altro può rivendicare.
Questo qui.
Si tratta quindi di un malinteso che si verifica ancora oggi.
Questa autorizzazione personalizzata può ora essere rivendicata da un utente malintenzionato.
Dipende dal livello di protezione.
A volte viene impostato come pericoloso, il che significa che l'utente deve accettarlo.
Ma anche in questo caso non ci farei affidamento.
L'utente si rende conto di ciò che sta accadendo e non concede mai all'aggressore il permesso di eseguire questa operazione.
Se l'aggressore ha rivendicato questa autorizzazione, può attivare l'evento di trasmissione
e causare l'interazione sensibile.
Ad esempio, per quanto riguarda un sistema di allarme, questo braccio o braccio e sistema, o per quanto riguarda
questo qui, lettura e gettone sensibile.
Quindi la vulnerabilità dipende dal codice dell'applicazione dello sviluppatore.
Ancora una volta, basta dare un'occhiata al metodo on receive per scoprire
cosa viene attivato e quale ingresso viene utilizzato da questo evento broadcast.
Ad esempio, se si utilizzano alcuni token memorizzati in una stringa come questa qui.
Va bene.
Ok.
Infine, ma non meno importante, potremmo avere qualcosa di simile a un gestore di trasmissioni locali.
Questo è un evento broadcast che si verifica solo nell'applicazione interna.
Quindi questo non raggiunge il mondo esterno.
Può essere utilizzato per.
Scambio di informazioni tra determinate classi, attività, servizi e simili.
Possiamo quindi utilizzare gli eventi broadcast per scambiare dati all'interno della nostra applicazione o per scambiare dati con altre
applicazioni al di fuori del nostro contesto applicativo.
Dal nostro punto di vista di attacco, saltiamo semplicemente il gestore delle trasmissioni locali perché non possiamo
interagire con loro dal mondo esterno.
Quindi questi ricevitori broadcast sono all'interno della sandbox di questa applicazione.
Non possiamo interagire con loro.
Va bene.
Ok.
Quindi, per riassumere, si trattava di molta teoria e di molti input.
Sarà velocissimo.
Tutto ciò che dobbiamo sapere è quanto segue.
L'unico metodo con cui possiamo interagire è il metodo on receive.
E lì dobbiamo valutare cosa possiamo fare.
Il fatto di avere un ricevitore broadcast non significa automaticamente che ci sia un qualche tipo di exploit o vulnerabilità.
Se questo metodo di ricezione è semplicemente la stampa di hello world, possiamo attivare hello world.
Ma questa non è una vulnerabilità.
Dobbiamo osservare quale codice viene definito nel metodo on receive e dobbiamo anche prestare
attenzione all'input che questo metodo riceve.
Tutto questo verrà illustrato in seguito in un esempio pratico, quindi non preoccupatevi se ora è un po' confuso.
Tutto quello che dovete sapere se analizzate, analizzate, trasmettete il ricevitore, date un'occhiata
al metodo del ricevitore, è l'unico metodo di cui dovete occuparvi.
Va bene.
Infine, per identificare i ricevitori broadcast, dobbiamo dare un'occhiata al Manifest
XML di Android.
Se non è stato definito un ricevitore broadcast, non significa che l'applicazione non utilizzi un ricevitore
broadcast.
Dobbiamo anche esaminare il codice Java.
Possiamo riassumere il tutto dando un'occhiata al codice Java, al metodo on receiver.
Questo è tutto ciò che dovete fare.
Nella sezione dedicata al reverse engineering di un'applicazione Android parleremo della compilazione
e dell'applicazione, del ripristino del codice Java, dell'identificazione del metodo del ricevitore e di altre
cose del genere.
Ok, questo è tutto per questo video.
Come già detto, si è trattato di molta teoria, ma riassumeremo il tutto con qualche esempio pratico.
Poi identificheremo i ricevitori broadcast e vedremo anche come attivare determinate azioni
e come sfruttare la mobilità.
Va bene.
Ok.
Quindi non vedo l'ora di vedervi lì.