From 258a1371ff8ec8f6c89c7437b78b7a67ba9568cf Mon Sep 17 00:00:00 2001
From: Translator <github-actions@github.com>
Date: Sat, 5 Oct 2024 13:17:23 +0000
Subject: [PATCH] Translated
 ['mobile-pentesting/android-app-pentesting/android-applicatio

---
 .../android-applications-basics.md            | 36 +++++++++----------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/mobile-pentesting/android-app-pentesting/android-applications-basics.md b/mobile-pentesting/android-app-pentesting/android-applications-basics.md
index ea8c2ecd9..edb7c104c 100644
--- a/mobile-pentesting/android-app-pentesting/android-applications-basics.md
+++ b/mobile-pentesting/android-app-pentesting/android-applications-basics.md
@@ -33,15 +33,15 @@ Impara e pratica GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-s
 
 ### Sandboxing
 
-Il **Sandbox delle Applicazioni Android** consente di eseguire **ogni applicazione** come un **processo separato sotto un ID utente separato**. Ogni processo ha la propria macchina virtuale, quindi il codice di un'app viene eseguito in isolamento rispetto ad altre app.\
-A partire da Android 5.0(L), **SELinux** è applicato. Fondamentalmente, SELinux nega tutte le interazioni tra processi e poi crea politiche per **consentire solo le interazioni previste tra di essi**.
+Il **Sandbox delle Applicazioni Android** consente di eseguire **ogni applicazione** come un **processo separato sotto un ID Utente separato**. Ogni processo ha la propria macchina virtuale, quindi il codice di un'app viene eseguito in isolamento rispetto ad altre app.\
+A partire da Android 5.0(L) **SELinux** è applicato. Fondamentalmente, SELinux nega tutte le interazioni tra processi e poi crea politiche per **consentire solo le interazioni previste tra di essi**.
 
 ### Permessi
 
 Quando installi un'**app e chiede permessi**, l'app sta chiedendo i permessi configurati negli elementi **`uses-permission`** nel file **AndroidManifest.xml**. L'elemento **uses-permission** indica il nome del permesso richiesto all'interno dell'**attributo name**. Ha anche l'attributo **maxSdkVersion** che smette di chiedere permessi su versioni superiori a quella specificata.\
-Nota che le applicazioni android non devono chiedere tutti i permessi all'inizio, possono anche **chiedere permessi dinamicamente**, ma tutti i permessi devono essere **dichiarati** nel **manifest**.
+Nota che le applicazioni android non devono chiedere tutti i permessi all'inizio, possono anche **chiedere permessi dinamicamente** ma tutti i permessi devono essere **dichiarati** nel **manifest.**
 
-Quando un'app espone funzionalità, può limitare **l'accesso solo alle app che hanno un permesso specificato**.\
+Quando un'app espone funzionalità, può limitare l'**accesso solo alle app che hanno un permesso specificato**.\
 Un elemento di permesso ha tre attributi:
 
 * Il **nome** del permesso
@@ -49,8 +49,8 @@ Un elemento di permesso ha tre attributi:
 * Il **protection-level** che indica come vengono concessi i permessi. Ci sono quattro tipi:
 * **Normale**: Usato quando non ci sono **minacce note** all'app. L'utente **non è tenuto ad approvarlo**.
 * **Pericoloso**: Indica che il permesso concede all'applicazione richiedente un **accesso elevato**. **Gli utenti sono invitati ad approvarli**.
-* **Firma**: Solo le **app firmate dallo stesso certificato di quello** che esporta il componente possono ricevere il permesso. Questo è il tipo di protezione più forte.
-* **FirmaOSistema**: Solo le **app firmate dallo stesso certificato di quello** che esporta il componente o **app che girano con accesso a livello di sistema** possono ricevere permessi.
+* **Firma**: Solo le **app firmate dallo stesso certificato di quello** che esporta il componente possono ottenere il permesso. Questo è il tipo di protezione più forte.
+* **FirmaOSystem**: Solo le **app firmate dallo stesso certificato di quello** che esporta il componente o **app che girano con accesso a livello di sistema** possono ottenere permessi.
 
 ## Applicazioni Preinstallate
 
@@ -65,7 +65,7 @@ Queste app si trovano generalmente nelle directory **`/system/app`** o **`/syste
 Per ottenere accesso root su un dispositivo android fisico, generalmente è necessario **sfruttare** 1 o 2 **vulnerabilità** che tendono a essere **specifiche** per il **dispositivo** e la **versione**.\
 Una volta che lo sfruttamento ha funzionato, di solito il binario Linux `su` viene copiato in una posizione specificata nella variabile PATH dell'utente come `/system/xbin`.
 
-Una volta configurato il binario su, viene utilizzata un'altra app Android per interfacciarsi con il binario `su` e **elaborare le richieste di accesso root** come **Superuser** e **SuperSU** (disponibile nel Google Play store).
+Una volta configurato il binario su, un'altra app Android viene utilizzata per interfacciarsi con il binario `su` e **elaborare richieste di accesso root** come **Superuser** e **SuperSU** (disponibile nel Google Play store).
 
 {% hint style="danger" %}
 Nota che il processo di rooting è molto pericoloso e può danneggiare gravemente il dispositivo.
@@ -109,7 +109,7 @@ Una volta che un dispositivo è rootato, qualsiasi app potrebbe richiedere acces
 
 Nello sviluppo Android, **Java o Kotlin** viene utilizzato per creare app. Invece di utilizzare la JVM come nelle app desktop, Android compila questo codice in **bytecode Dalvik Executable (DEX)**. In passato, la macchina virtuale Dalvik gestiva questo bytecode, ma ora, l'Android Runtime (ART) prende il sopravvento nelle versioni più recenti di Android.
 
-Per il reverse engineering, **Smali** diventa cruciale. È la versione leggibile dall'uomo del bytecode DEX, agendo come un linguaggio assembly traducendo il codice sorgente in istruzioni bytecode. Smali e baksmali si riferiscono agli strumenti di assemblaggio e disassemblaggio in questo contesto.
+Per il reverse engineering, **Smali** diventa cruciale. È la versione leggibile dall'uomo del bytecode DEX, che agisce come un linguaggio assembly traducendo il codice sorgente in istruzioni bytecode. Smali e baksmali si riferiscono agli strumenti di assemblaggio e disassemblaggio in questo contesto.
 
 ## Intents
 
@@ -161,7 +161,7 @@ Un intent-filter deve corrispondere all'**azione**, ai **dati** e alla **categor
 
 Il processo di "risoluzione dell'Intent" determina quale app dovrebbe ricevere ciascun messaggio. Questo processo considera l'**attributo di priorità**, che può essere impostato nella **dichiarazione dell'intent-filter**, e **quella con la priorità più alta sarà selezionata**. Questa priorità può essere impostata tra -1000 e 1000 e le applicazioni possono utilizzare il valore `SYSTEM_HIGH_PRIORITY`. Se si verifica un **conflitto**, appare una finestra "choser" in modo che **l'utente possa decidere**.
 
-### Intents Espliciti
+### Explicit Intents
 
 Un intent esplicito specifica il nome della classe che sta mirando:
 ```java
@@ -181,7 +181,7 @@ Questi consentono ad altre applicazioni di **eseguire azioni per conto della tua
 
 A differenza degli intent precedenti, che sono ricevuti solo da un'app, gli intent broadcast **possono essere ricevuti da più app**. Tuttavia, dalla versione API 14, è **possibile specificare l'app che dovrebbe ricevere** il messaggio utilizzando Intent.setPackage.
 
-In alternativa, è anche possibile **specificare un permesso quando si invia il broadcast**. L'app ricevente dovrà avere quel permesso.
+In alternativa, è anche possibile **specificare un permesso quando si invia il broadcast**. L'app ricevente avrà bisogno di avere quel permesso.
 
 Ci sono **due tipi** di Broadcast: **Normale** (asincrono) e **Ordinato** (sincrono). L'**ordine** si basa sulla **priorità configurata all'interno dell'elemento ricevente**. **Ogni app può elaborare, inoltrare o scartare il Broadcast.**
 
@@ -190,15 +190,15 @@ Puoi anche utilizzare la funzione **`sendBroadcast`** dal **`LocalBroadCastManag
 
 ### Sticky Broadcasts
 
-Questo tipo di Broadcasts **può essere accessibile a lungo dopo che sono stati inviati**.\
+Questo tipo di Broadcasts **può essere accessibile molto tempo dopo che sono stati inviati**.\
 Questi sono stati deprecati a livello API 21 ed è consigliato **non usarli**.\
-**Consentono a qualsiasi applicazione di intercettare i dati, ma anche di modificarli.**
+**Consentono a qualsiasi applicazione di sniffare i dati, ma anche di modificarli.**
 
 Se trovi funzioni contenenti la parola "sticky" come **`sendStickyBroadcast`** o **`sendStickyBroadcastAsUser`**, **controlla l'impatto e cerca di rimuoverle**.
 
 ## Deep links / URL schemes
 
-Nelle applicazioni Android, **deep links** vengono utilizzati per avviare un'azione (Intent) direttamente tramite un URL. Questo viene fatto dichiarando uno specifico **URL scheme** all'interno di un'attività. Quando un dispositivo Android cerca di **accedere a un URL con questo schema**, l'attività specificata all'interno dell'applicazione viene avviata.
+Nelle applicazioni Android, **deep links** vengono utilizzati per avviare un'azione (Intent) direttamente tramite un URL. Questo viene fatto dichiarando un **URL scheme** specifico all'interno di un'attività. Quando un dispositivo Android cerca di **accedere a un URL con questo schema**, l'attività specificata all'interno dell'applicazione viene avviata.
 
 Lo schema deve essere dichiarato nel file **`AndroidManifest.xml`**:
 ```xml
@@ -212,9 +212,9 @@ Lo schema deve essere dichiarato nel file **`AndroidManifest.xml`**:
 </intent-filter>
 [...]
 ```
-Lo schema dell'esempio precedente è `exampleapp://` (nota anche il **`category BROWSABLE`**)
+Lo schema dell'esempio precedente è `examplescheme://` (nota anche il **`category BROWSABLE`**)
 
-Quindi, nel campo dei dati, puoi specificare l'**host** e il **path**:
+Quindi, nel campo dati, puoi specificare l'**host** e il **path**:
 ```xml
 <data android:scheme="examplescheme"
 android:host="example"
@@ -249,7 +249,7 @@ Questi includono: **Attività, Servizi, Ricevitori di Broadcast e Provider.**
 
 Nelle app Android, le **attività** sono come schermi, mostrando diverse parti dell'interfaccia utente dell'app. Un'app può avere molte attività, ognuna delle quali presenta uno schermo unico all'utente.
 
-L'**attività di lancio** è il principale gateway a un'app, avviata quando tocchi l'icona dell'app. È definita nel file manifest dell'app con intent specifici MAIN e LAUNCHER:
+L'**attività di lancio** è il principale gateway per un'app, avviata quando tocchi l'icona dell'app. È definita nel file manifest dell'app con intent specifici MAIN e LAUNCHER:
 ```markup
 <activity android:name=".LauncherActivity">
 <intent-filter>
@@ -362,11 +362,11 @@ Per controllare l'accesso ai file:
 
 ### **Verifica dell'App per Maggiore Sicurezza**
 
-- A partire da **Android 4.2**, una funzione chiamata **Verifica App** consente agli utenti di far controllare le app per la sicurezza prima dell'installazione. Questo **processo di verifica** può avvisare gli utenti contro app potenzialmente dannose, o addirittura prevenire l'installazione di app particolarmente dannose, migliorando la sicurezza dell'utente.
+- A partire da **Android 4.2**, una funzione chiamata **Verifica App** consente agli utenti di far controllare le app per la sicurezza prima dell'installazione. Questo **processo di verifica** può avvisare gli utenti contro app potenzialmente dannose, o addirittura prevenire l'installazione di quelle particolarmente dannose, migliorando la sicurezza dell'utente.
 
 ### **Gestione dei Dispositivi Mobili (MDM)**
 
-- Le **soluzioni MDM** forniscono **supervisione e sicurezza** per i dispositivi mobili attraverso l'**API di Amministrazione Dispositivo**. Richiedono l'installazione di un'app Android per gestire e proteggere efficacemente i dispositivi mobili. Le funzioni chiave includono **imposizione di politiche di password**, **obbligo di crittografia dello storage**, e **permissibilità di cancellazione remota dei dati**, garantendo un controllo e una sicurezza completi sui dispositivi mobili.
+- Le **soluzioni MDM** forniscono **supervisione e sicurezza** per i dispositivi mobili attraverso l'**API di Amministrazione Dispositivi**. Richiedono l'installazione di un'app Android per gestire e proteggere efficacemente i dispositivi mobili. Le funzioni chiave includono **imposizione di politiche di password**, **obbligo di crittografia dello storage**, e **permettere la cancellazione remota dei dati**, garantendo un controllo e una sicurezza completi sui dispositivi mobili.
 ```java
 // Example of enforcing a password policy with MDM
 DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);