Bene, ragazzi, bentornati.
E finora non abbiamo parlato di permessi e autorizzazioni.
Si tratta di un argomento piuttosto importante per quanto riguarda l'hacking delle app.
Quindi, facciamo questo qui.
Scopriamo come il sistema Android gestisce queste applicazioni o, meglio ancora, come le mette in sandbox.
Quindi ogni applicazione sul sistema Android viene generalmente sottoposta a sandboxing, il che significa applicazione.
Non si può semplicemente accedere ai dati dell'applicazione due e dell'applicazione tre.
E questo è un bene.
Immaginate di avere un sistema Android in cui ogni applicazione può accedere ai dati delle altre.
Questo significa che un'applicazione di terze parti potrebbe semplicemente accedere ai nostri dati bancari.
Voglio dire, sarebbe orribile.
Ad esempio, le nostre foto, l'attivazione del microfono, lo scatto di foto e cose del genere.
Si tratta quindi di una situazione che non vogliamo avere.
Come fa il sistema Android a gestire tutto questo?
Beh, potrebbe essere più facile di quanto si pensi.
Voglio dire, abbiamo un sistema Linux e il sistema Android sta semplicemente assegnando un singolo utente
per ogni applicazione.
Questa è l'intera magia che sta dietro a tutto ciò.
Quindi ogni applicazione ottiene il proprio ID utente e questo significa semplicemente che se l'utente uno vuole accedere
ai dati dello strumento utente, questo sarà semplicemente negato e questi permessi sono definiti in un file in questa
piattaforma XML che è memorizzato sotto il permesso ETSI.
Quindi abbiamo un file che contiene la maggior parte dei nostri utenti.
Impareremo che non tutti possono rientrare in questa categoria, ma ne parleremo più avanti.
Ok, questo file definisce i nostri ID utente, che sono individuali per ogni applicazione.
Va bene.
Ma ora ci troviamo di fronte a un caso in cui l'applicazione ha bisogno di scambiare dati tra loro.
Potrebbe trattarsi, ad esempio, dell'accesso alle foto o al microfono, della geolocalizzazione o, ad esempio, dello
scambio di dati tra altre applicazioni in base al fornitore di contenuti, al ricevitore di trasmissioni.
Ne parleremo più avanti.
Come si fa, dunque, in questo momento?
Possiamo semplicemente aggiungere uno strumento utente alla nostra applicazione, ad esempio in base ai gruppi.
Quindi questo strumento utente verrà aggiunto alla nostra applicazione, il che significa che ora abbiamo accesso anche ai
dati dello strumento dell'applicazione, ad esempio le foto, il microfono, la fotocamera e cose del genere.
Tutto questo viene definito nel file XML dei pacchetti dot.
Quindi, dopo aver aggiunto un utente alla nostra applicazione, questo permesso viene inserito qui e viene anche monitorato
se all'utente è stato concesso o meno questo permesso.
Va bene.
Ok.
Finora tutto bene.
Abbiamo utenti singoli e possiamo anche aggiungere utenti ad altre applicazioni.
Entrambi sono definiti in questi file.
Ma ora abbiamo alcuni utenti del sistema e questi utenti devono essere attivi prima che il sistema sia in funzione.
E questi ID utente, ad esempio quello della shell ADB, saranno codificati in un file del kernel
in questo qui.
In questo modo si definirà che alcuni utenti hanno alcuni ID predefiniti e non sono memorizzati in questi
due file.
E anche dove le applicazioni degli utenti iniziano, ad esempio, con ID 10.000.
Ma non è così importante in questo momento.
La cosa importante è il file XML di avvio del pacchetto, perché questo
file ci dà accesso o ci nega l'accesso ai permessi.
Va bene.
Ok.
Finora tutto bene.
Ma ora la domanda è: come possiamo chiedere il permesso?
Questa è la parte più importante.
Come possiamo accedere a foto, fotocamera, microfono e simili del nostro sistema Android?
La risposta è definita nel manifest XML di Android.
Abbiamo già visto questo aspetto nel manifesto di Android, ma ricapitoliamo velocemente.
Si tratta di un file di configurazione in cui vengono definiti tutti i permessi a cui vogliamo accedere nella nostra
applicazione.
Se non sono stati definiti i permessi e si vuole accedere ai dati, l'applicazione si
blocca, il che significa che non si può aggirare il problema finché non si hanno, per esempio, privilegi
di root o un exploit come la dirty pipe.
La Dirty pipe si trova in una condizione di gara in cui un yeah e un socket possono scrivere in un processo che dovrebbe essere in grado
solo di leggere.
E questo potrebbe essere un abuso per sovrascrivere alcuni file di configurazione, ad esempio il pacchetto
non è esente, ma a meno che non ci sia un exploit o privilegi di root, non possiamo aggirarlo.
Dobbiamo quindi definire i nostri permessi qui.
Va bene.
Se definiamo tali permessi, questi verranno aggiunti ai pacchetti XML.
Ad esempio, qui abbiamo la lettura del contesto Internet e la lettura dell'archiviazione esterna.
Quindi questi singoli ID utente saranno definiti lì.
Saranno semplicemente aggiunti.
E c'è anche una sorta di tracciamento se l'utente ha concesso o meno tali permessi.
Ecco come il sistema Android gestisce queste cose.
Bello, vero?
Assolutamente sì.
E finora sembra che tutto vada bene.
E per quanto riguarda i permessi del sistema centrale, è tutto a posto.
Ma ciò che gli sviluppatori talvolta sottovalutano sono le autorizzazioni personalizzate.
E questo può essere assolutamente ridicolo.
E avremo anche degli esempi relativi a questo.
Quindi, per ora, se vi siete addormentati, nessun problema.
Ma.
Ora dovete svegliarvi, perché adesso è la parte interessante.
Ok.
Quindi vi siete svegliati in modo perfetto perché ora parliamo di permessi personalizzati e questo può essere il vostro pony sotto
l'albero di Natale.
Quindi cosa non è un permesso personalizzato?
Cioè, le applicazioni possono scambiare dati tra loro.
Ad esempio, l'applicazione uno può condividere i dati con lo strumento applicativo.
Ma diciamo che questi dati sono un po' critici.
Ad esempio, potrebbe trattarsi di una password unica o di un messaggio proveniente dall'applicazione bancaria.
Pertanto, è necessario assicurarsi che questi dati siano protetti e che solo l'applicazione due sia in grado
di accedervi.
Come si fa?
Beh, con l'autorizzazione dell'utente.
Finora non abbiamo parlato di questi quattro componenti chiave: fornitore di contenuti, ricevitore di
trasmissioni o servizi.
Ma non è nemmeno così rilevante in questo momento.
Lo faremo in seguito in modo approfondito.
Per ora, è sufficiente considerare che si tratta di possibilità di scambio di dati
tra loro, definite nel manifest XML di Android.
Ok, qui abbiamo la nostra applicazione uno, che ha un permesso personalizzato e ora dobbiamo
essere molto precisi su questo.
L'autorizzazione personalizzata, se viene definita qui, non inizia con l'autorizzazione dell'utente perché non utilizza
questa autorizzazione.
Sta definendo questo.
Quindi, se si trova questa autorizzazione tag, si tratta di un'autorizzazione personalizzata
definita in questa applicazione, il che significa che questa autorizzazione sta
proteggendo qualcosa in questa applicazione.
Questo è, tra l'altro, il risultato dell'applicazione CE che, credo, abbiamo visto finora.
Altrimenti dovremo esaminare anche questo.
Ma torniamo a questo.
Quindi questo permesso qui è stato definito e ora abbiamo un'etichetta che consente di leggere la
chiave e di vedere il nome di Android.
Questo è il nome del permesso.
E poi abbiamo ottenuto la protezione.
LEMON In questo caso, pericoloso.
Anche questo è un po' fuorviante, ma se ne parlerà più avanti.
Ok, quindi abbiamo il nostro primo permesso personalizzato e questo ci dice che consente la lettura della
chiave e vediamo.
Quindi la chiave è una tabella.
Sì, è in tabella.
Questa tabella contiene le nostre password.
Se un'applicazione dispone di questa autorizzazione, può accedere alle nostre password nella nostra applicazione sicura
qui.
Va bene.
E questo permesso viene definito qui.
Quindi si tratta di qualcosa di simile, per esempio, al permesso contestuale, dove stiamo usando il permesso
di questo utente, i contatti qui, ora stiamo definendo e completando il nostro permesso.
In questo momento, sotto abbiamo un altro permesso personalizzato.
Qui abbiamo un permesso e un'etichetta ampia che consente la modifica della chiave e di C e questo significa che possiamo scrivere su questa tabella
in questo momento.
Questo è il nome che abbiamo ora, con i tasti qui a destra.
Si trattava di chiavi rosse.
Ora abbiamo le chiavi giuste.
E qui, ancora una volta, abbiamo questo livello di protezione, ok?
E questo significa l'applicazione.
È possibile fornire dati a tutte le applicazioni, ma solo a quelle che dispongono di questa autorizzazione.
Questo qui può interagire con questi dati.
Va bene.
In caso contrario, non c'è alcun problema, perché quando parleremo di fornitori di contenuti,
e lo faremo in modo piuttosto approfondito, sarà tutto un po' più chiaro.
Quindi ora la domanda è: come possiamo, come applicazione di terze parti o come applicazione attaccante, ottenere
questi permessi?
È sufficiente definirli nella nostra applicazione.
Quindi qui possiamo vedere che possiamo semplicemente dire agli utenti il permesso.
E poi, invece di contesto, foto, microfono, definiamo semplicemente le autorizzazioni personalizzate dell'applicazione
uno.
E ora, se li abbiamo definiti nel nostro strumento applicativo, possiamo semplicemente chiedere gentilmente: Posso leggere le tue chiavi?
Il che significa che le vostre password, credenziali, cose del genere, e questa applicazione sta rispondendo.
Sì, lo chiede gentilmente.
Vi è consentito farlo.
Quindi il permesso personalizzato non è una vera e propria protezione per questo.
Non è quindi possibile proteggere i dati in base a un'autorizzazione personalizzata, a meno che non si scelga il livello di protezione corretto.
Ma ora la domanda è: qual è il livello di protezione corretto?
Finora posso dire che è pericoloso.
Non lo è.
Quali sono quindi le opzioni che abbiamo a disposizione come sviluppatori?
Beh, abbiamo quanto segue.
Abbiamo un sistema di firme e firme pericolose e normali.
Ma il sistema di firme non può essere utilizzato nelle nostre applicazioni.
Per questo motivo ci concentriamo solo su pericolosi, normali e firmati.
Va bene.
Il livello di protezione pericoloso significa semplicemente che l'utente deve essere informato, ma questo è tutto.
E poi l'utente può decidere se la nostra applicazione può accedere ai contratti o meno.
Se l'utente nega tutto, non siamo in grado di leggere queste cose.
Questi contengono.
O forse le chiavi nelle autorizzazioni personalizzate, ma voglio dire, affidarsi alla decisione dell'utente se è possibile accedere
ad alcuni dati critici, credo non sia l'idea migliore.
Ma voglio dire, è anche meglio della normalità, perché la normalità significa semplicemente che non siamo informati su
questo.
Si tratta quindi di un ulteriore livello di protezione.
Ad esempio, se si utilizza l'autorizzazione Internet e questa non viene visualizzata da nessuna parte, viene semplicemente
concessa automaticamente.
Ma, naturalmente, non possiamo semplicemente utilizzare il livello di protezione normale per alcuni permessi altamente
sensibili, come la fotocamera o il microfono, ad esempio.
Ma questo è un aspetto di cui non dobbiamo preoccuparci, perché viene fatto dal sistema Android, a meno che
non definiamo un'autorizzazione personalizzata, perché in questo caso siamo noi a occuparcene.
E se scegliessimo la normalità per alcuni permessi ad alto rischio, ad esempio l'accesso ai database,
alle chiavi, alle password e cose del genere.
E allora questa sarebbe sicuramente una scoperta.
Insomma, ogni applicazione potrebbe accedere ai nostri dati senza che l'utente ne sia informato.
Questo sarebbe un male.
Pertanto, l'opzione normale non è sicuramente quella giusta per le autorizzazioni sensibili.
Ma direi anche pericoloso.
Non è proprio il caso migliore.
Cioè, stiamo esternalizzando tale compito critico all'utente.
E questo è un aspetto che dovremmo gestire come sviluppatori.
Va bene.
Quindi cosa è meglio?
L'opzione migliore sarebbe la firma, ma c'è un po' di svantaggio in questo caso.
La firma significa che ogni applicazione firmata con la stessa chiave può accedere ai dati.
Ciò significa che se si scrive un'applicazione di terze parti e si cerca di accedere, ad esempio, a questo database
di chiavi che è stato protetto con la firma del livello di protezione, è necessaria la chiave privata
del proprietario dell'applicazione SIF per accedere a questi dati.
E naturalmente questo è qualcosa che non abbiamo.
E questo è anche l'aspetto negativo, perché la firma del livello di protezione, voglio dire,
è l'approccio migliore.
Ma non possiamo condividere la nostra chiave privata.
Questo sarebbe più ridicolo in questo momento e quindi potrebbe non essere pratico nell'attività quotidiana.
Pertanto, la maggior parte delle volte abbiamo a che fare con un livello di protezione pericoloso, il che
significa che l'utente viene informato, il che è positivo, ma se l'utente fa clic qui, tutti questi dati vengono eliminati,
il che potrebbe essere assolutamente negativo per l'utente in questo momento.
Va bene.
Ecco in breve tutto quello che c'è da sapere sulle autorizzazioni.
C'era molta teoria.
Per questo motivo, suggerisco di ricapitolare questo aspetto pratico sulla nostra macchina virtuale Ubuntu.
Quindi, analizziamo il file dei permessi.
Vediamo cosa c'è dentro e ricapitoliamo un po'.
Va bene.
Ok.
Quindi capisco il tuo punto di vista.
Bene, eccoci tornati a Ubuntu VM e ora diamo un'occhiata pratica all'intero argomento.
Iniziamo quindi con gli ID utente preconfigurati nel nostro sistema Android, che vengono definiti nel conflitto
del file system di Android.
H.
Quindi, all'interno del nostro kernel, non possiamo semplicemente accedere a questo e poi archiviare qui.
Dobbiamo dare un'occhiata al codice sorgente di Android.
Quindi facciamo così.
Quindi stiamo semplicemente cercando il conflitto del file system Android h nel browser di nostra scelta nel motore di ricerca
di nostra scelta.
E qui otteniamo il codice sorgente di Android Google.
Apriamo questo ed eccolo qui.
Si tratta di un elenco predefinito nel nostro kernel che definisce alcuni ID utente.
Ad esempio, il sistema ID ha l'ID utente 1000 la radio è 1001 e così via.
Questo può cambiare a seconda del produttore e del sistema Android che stiamo utilizzando.
Quindi possiamo vedere che questo è per la versione 4 di Android. 2.
Per quanto riguarda il nostro Google Pixel, la situazione è ancora la stessa.
Quindi il Bluetooth credo abbia ancora 1002 e così via.
Tuttavia, se vogliamo essere più precisi riguardo al nostro dispositivo, dobbiamo
cercare la versione esatta e anche il modello e il produttore esatto.
Quindi, per ora, ci atteniamo a questo.
Bene, qui possiamo vedere che la telecamera ha questo ID utente e così via.
Scendiamo un po' più in basso.
Sì, ADB, Shell, questo qui.
Questa è la shell di debug ADB e questo è l'ID utente 2000.
Verifichiamo questo.
Se si apre un nuovo terminale e si effettua una connessione ADB digitando l'ID, ecco fatto.
ID utente 2000.
Perfetto.
Possiamo anche vedere, ad esempio, che la rete BT potrebbe essere bluetooth admin 3001.
Sì, esattamente.
Esattamente quello che possiamo vedere in questo caso.
Va bene.
E poi abbiamo un sacco di altre cose.
Anche questo è molto, molto bello.
Possiamo vedere che questa è la nostra prima applicazione utente.
Quindi la nostra applicazione utente ha iniziato con l'ID utente 10.000 e va semplicemente verso l'alto.
Questa è solo una definizione.
Ok, gli ID utente partono da 10.000 e ogni volta che installiamo una nuova applicazione, questo valore viene aumentato.
E vediamo.
Pertanto, sì, teniamola aperta.
Ok.
Pertanto passiamo nella directory dei dati e se si esegue un dash l LZ non abbiamo alcun permesso.
Passiamo quindi al contesto root e ripetiamo l'operazione.
Ed ecco che abbiamo questo.
Vediamo se troviamo qualche applicazione per gli utenti.
Questo, ad esempio, è l'esempio di applicazione C di com MWI e questo ha ora questo strano ID utente.
Si tratta dell'ID utente e del gruppo.
Quindi, se si tratta di un trattino basso a 129, non si tratta di una sorta di alias.
Quindi il nostro ID utente per questa applicazione è 10.129.
Quindi possiamo sostituire l'otto con il 10.000.
Possiamo anche verificarlo all'interno del gestore di pacchetti.
Il gestore dei pacchetti, quindi, credo abbia un'opzione per questo.
Vediamo.
Sì, da questa parte.
Ecco come si presenta la nuova opzione.
Possiamo anche mostrare l'uid del pacchetto se andiamo ancora una volta in alto, abbiamo parlato
dell'applicazione C che ha l'ID utente 10.129.
Questa A può essere sostituita.
Quindi facciamo così.
Quindi, vediamo se è corretto.
In questo momento stiamo utilizzando i pacchetti di elenchi p m con l'opzione trattino maiuscolo u.
Questo elenco di pacchetti con la U maiuscola è il gestore dei pacchetti, ovviamente, davanti a questo e ora abbiamo tutti
gli ID utente dietro a questo.
E se non si vuole cercare C, si può anche fare un grep su questo e poi si può fare, oh, ecco fatto.
Abbiamo già un'applicazione di hacking.
E si può anche vedere che stiamo facendo qualcosa con il bypass di registrazione.
Ma questa è la nostra applicazione C.
Allora facciamo così, il pacchetto esatto.
Ok, chiariamo questo punto ed ecco fatto.
Quindi, avete già un po' di spoiler, ma in questo corso andremo oltre.
Ma per ora possiamo vedere che, sì, abbiamo l'ID utente 10.129 e se scorriamo un po' verso l'alto, possiamo vedere
che ogni applicazione ha il suo ID utente individuale.
Va bene.
E questo è il modo in cui la sandbox viene implementata.
Ogni applicazione riceve un proprio ID utente.
Fin qui tutto bene.
Quindi ora la domanda è: dove si pensa che siano questi ID utente?
Qui possiamo vederli, ma ci possono essere o dove vengono definiti e questo file è stato visto
nella parte teorica, ma vediamo la parte pratica.
Si trattava della piattaforma di autorizzazione ETSI XML.
Sì.
Insomma, è un po' difficile da leggere, ma credo che vada bene lo stesso.
Scorriamo un po' più in alto.
Ecco fatto.
Quindi possiamo vedere, ad esempio, che l'internet dei permessi di Android ha questo ID utente, shell o OC.
Interessante.
Poi possiamo vedere la modifica delle impostazioni audio, con questo ID utente e questo server audio, che viene impacchettato
insieme.
Quindi il server audio, cioè, è una sorta di alias per l'id utente, come questo a 129, immagino per quanto riguarda la nostra
applicazione cf.
Quindi questo UID qui è una sorta di alias per questo e possiamo vedere che il server audio viene impacchettato
con tutti questi permessi, il che significa che se concediamo questo ID utente alla nostra applicazione, abbiamo
accesso a tutti questi permessi qui.
Piuttosto forte, vero?
E scorriamo un po' più in alto.
Ma sì, c'è un sacco di roba qui dentro.
Ad esempio, Red Locks.
Qui c'è il blocco dell'ID del gruppo, net admin, internet.
Ecco fatto.
È l'ID del gruppo.
E qui.
Sì, qui abbiamo l'ID utente.
Va bene.
Quindi, sì, credo che questa sia la parte interessante.
Va bene.
Questo file contiene i nostri ID utente e ID gruppo.
Va bene.
Ma ancora non abbiamo questa corrispondenza.
Quindi, qui si stanno definendo i permessi fondamentali.
Ma ora, se ne chiediamo uno, come viene aggiunto alla nostra applicazione?
Questo viene definito nel pacchetto come XML e questo è all'interno del sistema di dati.
Pacchetti esenti.
Sì.
Questo file contiene quindi tutte le informazioni necessarie per la nostra applicazione.
Ad esempio, le autorizzazioni per le chiavi di firma e cose del genere.
Ma voglio dire, diamo semplicemente un'occhiata a questo.
Ecco perché siamo qui.
Ok.
Sì.
Quindi è un sacco di roba.
Copiamo quindi un po' di cose in un formato più leggibile.
Bene, questo è l'inizio e poi apriamo il codice di studio, perché abbiamo un'evidenziazione
XML.
Sì.
Abbiamo quindi questo pacchetto come esempio e possiamo vedere che Google Authenticator utilizza molte cose.
Pertanto, non concentriamoci sulle applicazioni Android principali perché hanno molti permessi.
Rimaniamo alla nostra applicazione C.
Quindi venite e W sono un esempio.
Qui, ad esempio, possiamo vedere che questo è il permesso personalizzato che abbiamo visto nell'esempio del manifest di Android, almeno
nella parte teorica di queste diapositive.
Quindi anche questo è stato definito e autorizzato qui.
Quindi, come permesso contestuale, possiamo chiedere questo, questo qui e possiamo vedere che la protezione è stata
impostata su uno, che era il livello di protezione pericoloso.
Va bene.
Ok.
Ma per il momento, rimaniamo sul nostro o diciamo di tornare al nostro sito e vediamo se possiamo abilitare il word
wrapping in modo da non doverlo scorrere.
Ok.
Ora abbiamo tutto qui.
Ok?
E questo è il nome del nostro pacchetto, il nostro identificatore individuale per questa applicazione.
Poi abbiamo il percorso del codice.
Quindi questo è codificato in base64.
Ma non c'è alcun valore reale dietro a questo.
Possiamo semplicemente accedere a questa directory.
Forse lo faremo inserendo tutti questi strani personaggi.
Per prima cosa.
Sì.
Come potete vedere, si tratta di un vero e proprio percorso di directory.
Quindi abbiamo la nostra biblioteca.
Questo, tra l'altro, è il nostro file APK, poi abbiamo alcune librerie, altre cose, che non sono così importanti.
Qui abbiamo l'ID utente 10.129, esattamente quello che abbiamo visto nel nostro elenco.
E poi questo qui, questo è il certificato.
E voglio dire, questo deve essere incluso qui per quanto riguarda la firma del livello di protezione.
Il livello di protezione della firma significa che possiamo dare accesso ad altre applicazioni che hanno la stessa chiave
di firma e quindi questa deve essere memorizzata qui.
Se ora forniamo questo livello di protezione, questo file, questo file XML del pacchetto ha una traccia di questo
e può prendere la decisione dell'applicazione tre se questo è autorizzato ad accedere ai dati o meno.
Ok.
E poi abbiamo questi permessi che questa applicazione sta utilizzando.
Possiamo vedere il permesso, Internet, e questo è flex zero.
Questo è il livello di protezione normale, il che significa che non è richiesto alcun pop-up dell'utente
o altro, ma che viene concesso automaticamente.
Nel caso in cui siano state concesse altre autorizzazioni, queste saranno elencate anche qui.
Passiamo a un'altra applicazione.
Vediamo, credo che la nostra applicazione space pane dovrebbe essere anche qui nello space ping.
Oh, purtroppo non è così.
Banca insicura?
Sì.
Si tratta di un'altra applicazione.
È un'altra applicazione di cattura la bandiera.
E questo, voglio dire, la struttura è la stessa.
Possiamo vedere tutto il materiale qui, il percorso dell'applicazione Android, che è questo.
Il nome del pacchetto è la chiave di firma delle librerie native e questa volta possiamo vedere che l'applicazione sta usando le credenziali dell'utente, il profilo,
Internet e lo stato della rete e possiamo anche vedere se le autorizzazioni sono state concesse
o meno.
Se abbiamo i privilegi di root, possiamo aggiungere tutti i permessi e impostarli
su true o false come preferiamo.
Ma se abbiamo dei permessi, intendo dire che non è necessario accedere a determinati permessi in un'applicazione.
Allora abbiamo già accesso a tutto.
Va bene.
Quindi, se si desidera aggiungere e diciamo aggiungere tutti qui.
Sì.
Con i privilegi di root.
Questo funzionerebbe tutto, ad esempio, con l'exploit della dirty pipe.
Funzionerebbe anche questo, che potrebbe essere un po' più interessante in questo momento.
Ma credo che se si possono sovrascrivere o modificare questi file di sistema, allora si può ottenere tutto
il resto senza modificare o accedere o inserire nuovi permessi qui.
Ok.
Quindi va bene così.
Ora, per quanto riguarda due autorizzazioni.
Abbiamo visto che se torniamo a questa directory di dati, ogni applicazione sarà assegnata
a un proprio ID utente.
Questo ID utente può essere recuperato tramite il gestore di pacchetti o all'interno del pacchetto XML.
O se si parla di utenti Android di base, allora all'interno di cosa?
Sì.
La piattaforma.
Ecco come funziona il nostro concetto di sandboxing dei permessi, che significa che questa applicazione sicura
qui ha questo ID utente e quindi non può entrare nei dati di questa applicazione fino a quando non diamo questo permesso,
ad esempio per un database.
Questo potrebbe essere fatto da un fornitore di contenuti per accedere ai dati di un database.
Se si fornisce questa autorizzazione personalizzata e l'applicazione utilizza l'autorizzazione personalizzata,
è possibile accedere a questi dati.
Ecco cosa abbiamo visto qui, le Chiavi Rosse, e lo abbiamo.
Ecco fatto.
Quindi non si tratta di un'autorizzazione personalizzata definita nell'applicazione CV.
Ricordate l'esempio del manifest di Android.
Lo mescolerò e se assegniamo questo permesso alla nostra applicazione, dobbiamo controllare il livello di protezione.
Se è pericoloso e il pop-up potrebbe verificarsi sulle versioni più vecchie di questa applicazione.
Questo potrebbe non essere il caso, ma nelle versioni più recenti il pop-up apparirà sicuramente.
Ma se l'utente concede questo accesso, possiamo interagire con l'applicazione.
Va bene.
Ok.
In caso contrario, non preoccupatevi.
Se si parla di fornitore di contenuti, si fa SNAP e questa parte sarà chiarissima.
Sono abbastanza sicuro di questo.
Va bene.
Quindi questo è davvero tutto per questo video, nel caso in cui abbiate domande, lasciatemi un messaggio
sotto i commenti e altro.
Non vedo l'ora di vederti nella prossima edizione.