Translated ['src/mobile-pentesting/android-app-pentesting/android-applic

src/mobile-pentesting/android-app-pentesting/android-applications-basics.md

@@ -11,22 +11,22 @@
 
 ### Separazione UID
 
-**A ciascuna applicazione viene assegnato un ID Utente specifico**. Questo avviene durante l'installazione dell'app, in modo che **l'app possa interagire solo con i file di proprietà del suo ID Utente o con file condivisi**. Pertanto, solo l'app stessa, alcuni componenti del OS e l'utente root possono accedere ai dati delle app.
+**Ogni applicazione è assegnata a un ID Utente specifico**. Questo avviene durante l'installazione dell'app in modo che **l'app possa interagire solo con i file di proprietà del suo ID Utente o con file condivisi**. Pertanto, solo l'app stessa, alcuni componenti del OS e l'utente root possono accedere ai dati delle app.
 
 ### Condivisione UID
 
-**Due applicazioni possono essere configurate per utilizzare lo stesso UID**. Questo può essere utile per condividere informazioni, ma se una di esse viene compromessa, i dati di entrambe le applicazioni saranno compromessi. Questo è il motivo per cui questo comportamento è **sconsigliato**.\
+**Due applicazioni possono essere configurate per utilizzare lo stesso UID**. Questo può essere utile per condividere informazioni, ma se una di esse viene compromessa, i dati di entrambe le applicazioni saranno compromessi. Ecco perché questo comportamento è **sconsigliato**.\
 **Per condividere lo stesso UID, le applicazioni devono definire lo stesso valore `android:sharedUserId` nei loro manifest.**
 
 ### 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**.
+A partire da Android 5.0(L), **SELinux** è applicato. Fondamentalmente, SELinux nega tutte le interazioni tra i processi e poi crea politiche per **consentire solo le interazioni previste tra di essi**.
 
 ### Permessi
 
-Quando installi un'**app e richiede 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 **richiedere permessi dinamicamente**, ma tutti i permessi devono essere **dichiarati** nel **manifest**.
+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**.
 
 Quando un'app espone funzionalità, può limitare l'**accesso solo alle app che hanno un permesso specificato**.\
 Un elemento di permesso ha tre attributi:
@@ -37,7 +37,7 @@ Un elemento di permesso ha tre attributi:
 - **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.
-- **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 ricevere permessi.
+- **SignatureOrSystem**: 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.
 
 ## Applicazioni Preinstallate
 
@@ -49,17 +49,17 @@ Queste app si trovano generalmente nelle directory **`/system/app`** o **`/syste
 
 ## Rooting
 
-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**.\
+Per ottenere accesso root su un dispositivo android fisico, generalmente è necessario **sfruttare** 1 o 2 **vulnerabilità** che di solito sono **specifiche** per il **dispositivo** e la **versione**.\
 Una volta che l'exploit 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, 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).
+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).
 
 > [!CAUTION]
 > Nota che il processo di rooting è molto pericoloso e può danneggiare gravemente il dispositivo.
 
 ### ROMs
 
-È possibile **sostituire il sistema operativo installando un firmware personalizzato**. Facendo ciò, è possibile estendere l'utilità di un vecchio dispositivo, bypassare restrizioni software o accedere all'ultima versione del codice Android.\
+È possibile **sostituire il sistema operativo installando un firmware personalizzato**. Facendo ciò, è possibile estendere l'utilità di un vecchio dispositivo, bypassare le restrizioni software o accedere all'ultima versione del codice Android.\
 **OmniROM** e **LineageOS** sono due dei firmware più popolari da utilizzare.
 
 Nota che **non è sempre necessario rootare il dispositivo** per installare un firmware personalizzato. **Alcuni produttori consentono** lo sblocco dei loro bootloader in modo ben documentato e sicuro.
@@ -93,9 +93,9 @@ Una volta che un dispositivo è rootato, qualsiasi app potrebbe richiedere acces
 
 ### **Dalvik & Smali**
 
-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.
+Nello sviluppo Android, **Java o Kotlin** vengono utilizzati 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, 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.
+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.
 
 ## Intents
 
@@ -126,7 +126,7 @@ Inoltre, gli sviluppatori hanno la possibilità di garantire ulteriormente l'acc
 <!-- Intent filters go here -->
 </activity>
 ```
-### Intents Impliciti
+### Intent impliciti
 
 Gli intent vengono creati programmaticamente utilizzando un costruttore di Intent:
 ```java
@@ -145,11 +145,11 @@ Questo intento dovrebbe essere dichiarato all'interno del manifest come nel segu
 ```
 Un intent-filter deve corrispondere all'**azione**, ai **dati** e alla **categoria** per ricevere un messaggio.
 
-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**.
+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**.
 
-### Explicit Intents
+### Intents Espliciti
 
-Un intent esplicito specifica il nome della classe che sta mirando:
+Un intent esplicito specifica il nome della classe a cui è destinato:
 ```java
 Intent downloadIntent = new (this, DownloadService.class):
 ```
@@ -161,11 +161,11 @@ context.startService(intent);
 ```
 ### Pending Intents
 
-Questi consentono ad altre applicazioni di **eseguire azioni per conto della tua applicazione**, utilizzando l'identità e i permessi della tua app. Costruendo un Pending Intent, dovrebbe essere **specificato un intent e l'azione da eseguire**. Se l'**intent dichiarato non è Esplicito** (non dichiara quale intent può chiamarlo), un'**applicazione malevola potrebbe eseguire l'azione dichiarata** per conto dell'app vittima. Inoltre, **se un'azione non è specificata**, l'app malevola sarà in grado di fare **qualsiasi azione per conto della vittima**.
+Questi consentono ad altre applicazioni di **eseguire azioni per conto della tua applicazione**, utilizzando l'identità e i permessi della tua app. Costruendo un Pending Intent, deve essere **specificato un intent e l'azione da eseguire**. Se l'**intent dichiarato non è Esplicito** (non dichiara quale intent può chiamarlo), un'**applicazione malevola potrebbe eseguire l'azione dichiarata** per conto dell'app vittima. Inoltre, **se un'azione non è specificata**, l'app malevola sarà in grado di fare **qualsiasi azione per conto della vittima**.
 
 ### Broadcast Intents
 
-A differenza degli intent precedenti, che sono ricevuti solo da un'app, i broadcast intents **possono essere ricevuti da più app**. Tuttavia, dalla versione API 14, è **possibile specificare l'app che dovrebbe ricevere** il messaggio utilizzando Intent.setPackage.
+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 avrà bisogno di avere quel permesso.
 
@@ -178,13 +178,13 @@ Puoi anche utilizzare la funzione **`sendBroadcast`** dalla **`LocalBroadCastMan
 
 Questo tipo di Broadcasts **può essere accessibile a lungo dopo che sono stati inviati**.\
 Questi sono stati deprecati a livello API 21 ed è consigliato **non usarli**.\
-**Consentono a qualsiasi applicazione di sniffare i dati, ma anche di modificarli.**
+**Consentono a qualsiasi applicazione di intercettare 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 uno specifico **schema URL** 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
@@ -256,7 +256,7 @@ Il ciclo di vita di un'attività **inizia con il metodo onCreate**, impostando l
 
 ### Sottoclasse dell'Applicazione
 
-Nello sviluppo Android, un'app ha l'opzione di creare una **sottoclasse** della [Application](https://developer.android.com/reference/android/app/Application) classe, anche se non è obbligatorio. Quando tale sottoclasse è definita, diventa la prima classe a essere istanziata all'interno dell'app. Il metodo **`attachBaseContext`**, se implementato in questa sottoclasse, viene eseguito prima del metodo **`onCreate`**. Questa configurazione consente un'inizializzazione anticipata prima che il resto dell'applicazione inizi.
+Nello sviluppo Android, un'app ha la possibilità di creare una **sottoclasse** della [Application](https://developer.android.com/reference/android/app/Application) classe, anche se non è obbligatorio. Quando tale sottoclasse è definita, diventa la prima classe a essere istanziata all'interno dell'app. Il metodo **`attachBaseContext`**, se implementato in questa sottoclasse, viene eseguito prima del metodo **`onCreate`**. Questa configurazione consente un'inizializzazione anticipata prima che il resto dell'applicazione inizi.
 ```java
 public class MyApp extends Application {
 @Override
@@ -276,7 +276,7 @@ super.onCreate();
 
 [Servizi](https://developer.android.com/guide/components/services) sono **operativi in background** capaci di eseguire compiti senza un'interfaccia utente. Questi compiti possono continuare a funzionare anche quando gli utenti passano ad altre applicazioni, rendendo i servizi cruciali per **operazioni a lungo termine**.
 
-I servizi sono versatili; possono essere avviati in vari modi, con **Intents** che sono il metodo principale per lanciarli come punto di ingresso di un'applicazione. Una volta che un servizio è avviato utilizzando il metodo `startService`, il suo metodo `onStart` entra in azione e continua a funzionare fino a quando il metodo `stopService` non viene esplicitamente chiamato. In alternativa, se il ruolo di un servizio dipende da una connessione client attiva, il metodo `bindService` viene utilizzato per legare il client al servizio, attivando il metodo `onBind` per il passaggio dei dati.
+I servizi sono versatili; possono essere avviati in vari modi, con **Intents** che sono il metodo principale per lanciarli come punto di ingresso di un'applicazione. Una volta che un servizio è avviato utilizzando il metodo `startService`, il suo metodo `onStart` entra in azione e continua a funzionare fino a quando il metodo `stopService` non viene chiamato esplicitamente. In alternativa, se il ruolo di un servizio dipende da una connessione client attiva, il metodo `bindService` viene utilizzato per legare il client al servizio, attivando il metodo `onBind` per il passaggio dei dati.
 
 Un'applicazione interessante dei servizi include la riproduzione di musica in background o il recupero di dati di rete senza ostacolare l'interazione dell'utente con un'app. Inoltre, i servizi possono essere resi accessibili ad altri processi sullo stesso dispositivo attraverso **l'esportazione**. Questo non è il comportamento predefinito e richiede una configurazione esplicita nel file Android Manifest:
 ```xml
@@ -284,9 +284,9 @@ Un'applicazione interessante dei servizi include la riproduzione di musica in ba
 ```
 ### Broadcast Receivers
 
-**I Broadcast receivers** fungono da ascoltatori in un sistema di messaggistica, consentendo a più applicazioni di rispondere agli stessi messaggi dal sistema. Un'app può **registrare un ricevitore** in **due modi principali**: attraverso il **Manifest** dell'app o **dinamicamente** nel codice dell'app tramite l'API **`registerReceiver`**. Nel Manifest, le trasmissioni sono filtrate con permessi, mentre i ricevitori registrati dinamicamente possono anche specificare permessi al momento della registrazione.
+**I broadcast receivers** fungono da ascoltatori in un sistema di messaggistica, consentendo a più applicazioni di rispondere agli stessi messaggi dal sistema. Un'app può **registrare un ricevitore** in **due modi principali**: attraverso il **Manifest** dell'app o **dinamicamente** nel codice dell'app tramite l'API **`registerReceiver`**. Nel Manifest, le trasmissioni sono filtrate con permessi, mentre i ricevitori registrati dinamicamente possono anche specificare permessi al momento della registrazione.
 
-**I filtri di Intent** sono cruciali in entrambi i metodi di registrazione, determinando quali trasmissioni attivano il ricevitore. Una volta inviata una trasmissione corrispondente, viene invocato il metodo **`onReceive`** del ricevitore, consentendo all'app di reagire di conseguenza, ad esempio, modificando il comportamento in risposta a un avviso di batteria scarica.
+**I filtri di Intent** sono cruciali in entrambi i metodi di registrazione, determinando quali trasmissioni attivano il ricevitore. Una volta inviata una trasmissione corrispondente, viene invocato il metodo **`onReceive`** del ricevitore, consentendo all'app di reagire di conseguenza, come modificare il comportamento in risposta a un avviso di batteria scarica.
 
 Le trasmissioni possono essere **asincrone**, raggiungendo tutti i ricevitori senza ordine, o **sincrone**, dove i ricevitori ricevono la trasmissione in base a priorità impostate. Tuttavia, è importante notare il potenziale rischio per la sicurezza, poiché qualsiasi app può dare priorità a se stessa per intercettare una trasmissione.
 
@@ -298,7 +298,7 @@ Per comprendere la funzionalità di un ricevitore, cerca il metodo **`onReceive`
 
 La convalida dell'input è fondamentale per prevenire vulnerabilità, come l'iniezione SQL. I Content Providers supportano operazioni di base: `insert()`, `update()`, `delete()` e `query()`, facilitando la manipolazione e la condivisione dei dati tra le applicazioni.
 
-**FileProvider**, un Content Provider specializzato, si concentra sulla condivisione sicura dei file. È definito nel manifest dell'app con attributi specifici per controllare l'accesso alle cartelle, indicato da `android:exported` e `android:resource` che puntano alle configurazioni delle cartelle. Si consiglia cautela quando si condividono directory per evitare di esporre involontariamente dati sensibili.
+**FileProvider**, un Content Provider specializzato, si concentra sulla condivisione sicura di file. È definito nel manifest dell'app con attributi specifici per controllare l'accesso alle cartelle, indicato da `android:exported` e `android:resource` che puntano alle configurazioni delle cartelle. Si consiglia cautela quando si condividono directory per evitare di esporre involontariamente dati sensibili.
 
 Esempio di dichiarazione del manifest per FileProvider:
 ```xml
@@ -327,7 +327,7 @@ WebViews sono come **mini browser web** all'interno delle app Android, che estra
 
 Android offre due principali tipi di WebView:
 
-- **WebViewClient** è ottimo per HTML di base ma non supporta la funzione di avviso JavaScript, influenzando il modo in cui gli attacchi XSS possono essere testati.
+- **WebViewClient** è ottimo per HTML di base ma non supporta la funzione di avviso JavaScript, influenzando il modo in cui possono essere testati gli attacchi XSS.
 - **WebChromeClient** si comporta più come l'esperienza completa del browser Chrome.
 
 Un punto chiave è che i browser WebView **non condividono i cookie** con il browser principale del dispositivo.
@@ -340,7 +340,7 @@ Consentire l'accesso ai contenuti (`setAllowContentAccess(true)`) consente ai We
 
 Per controllare l'accesso ai file:
 
-- Disabilitare l'accesso ai file (`setAllowFileAccess(false)`) limita l'accesso al filesystem, con eccezioni per alcuni asset, assicurando che vengano utilizzati solo per contenuti non sensibili.
+- Disabilitare l'accesso ai file (`setAllowFileAccess(false)`) limita l'accesso al filesystem, con eccezioni per alcuni asset, assicurando che siano utilizzati solo per contenuti non sensibili.
 
 ## Altri Componenti dell'App e Gestione dei Dispositivi Mobili
 
@@ -350,11 +350,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 impedire l'installazione di quelle particolarmente malevole, 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 impedire 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 sulle password**, **obbligo di crittografia dello storage** e **permissività 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 Dispositivo**. Richiedono l'installazione di un'app Android per gestire e proteggere efficacemente i dispositivi mobili. Le funzioni chiave includono **l'applicazione delle politiche di password**, **l'obbligo di crittografia dello storage** e **la possibilità di 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);
@@ -365,4 +365,104 @@ if (dpm.isAdminActive(adminComponent)) {
 dpm.setPasswordMinimumLength(adminComponent, 8);
 }
 ```
+## Enumerare ed Sfruttare i Servizi AIDL / Binder
+
+Android *Binder* IPC espone molti **servizi di sistema e forniti dal venditore**. Questi servizi diventano una **superficie di attacco** quando vengono esportati senza un adeguato controllo dei permessi (il livello AIDL stesso non esegue *nessun* controllo degli accessi).
+
+### 1. Scoprire i servizi in esecuzione
+```bash
+# from an adb shell (USB or wireless)
+service list               # simple one-liner
+am list services           # identical output, ActivityManager wrapper
+```
+1. Traduzione del testo in italiano.
+2. Mantenimento della sintassi markdown e html.
+3. Non tradurre nomi di tecniche di hacking, parole comuni di hacking, nomi di piattaforme cloud/SaaS.
+4. Non tradurre link o percorsi.
+5. Non modificare tag o riferimenti.
+```
+145  mtkconnmetrics: [com.mediatek.net.connectivity.IMtkIpConnectivityMetrics]
+146  wifi             : [android.net.wifi.IWifiManager]
+```
+* L'**indice** (prima colonna) viene assegnato a runtime – **non** fare affidamento su di esso tra i riavvii.
+* Il **nome del Binder** (ad es. `mtkconnmetrics`) è ciò che verrà passato a `service call`.
+* Il valore all'interno delle parentesi quadre è l'**interfaccia AIDL** completamente qualificata da cui è stato generato lo stub.
+
+### 2. Ottenere il descrittore dell'interfaccia (PING)
+Ogni stub Binder implementa automaticamente il **codice di transazione `0x5f4e5446`** (`1598968902` decimale, ASCII "_NTF").
+```bash
+# "ping" the service
+service call mtkconnmetrics 1    # 1 == decimal 1598968902 mod 2^32
+```
+Una risposta valida restituisce il nome dell'interfaccia codificato come una stringa UTF-16 all'interno di un `Parcel`.
+
+### 3. Chiamare una transazione
+Sintassi: `service call <name> <code> [type value ...]`
+
+Specificatori di argomento comuni:
+* `i32 <int>` – valore intero firmato a 32 bit
+* `i64 <long>` – valore intero firmato a 64 bit
+* `s16 <string>` – stringa UTF-16 (Android 13+ utilizza `utf16`)
+
+Esempio – avviare il monitoraggio della rete con uid **1** su un dispositivo MediaTek:
+```bash
+service call mtkconnmetrics 8 i32 1
+```
+### 4. Forzatura di metodi sconosciuti
+Quando i file di intestazione non sono disponibili, puoi **iterare il codice** finché l'errore non cambia da:
+```
+Result: Parcel(00000000 00000000)  # "Not a data message"
+```
+a una normale `Parcel` risposta o `SecurityException`.
+```bash
+for i in $(seq 1 50); do
+printf "[+] %2d -> " $i
+service call mtkconnmetrics $i 2>/dev/null | head -1
+done
+```
+Se il servizio è stato compilato **con proguard**, la mappatura deve essere indovinata – vedere il passo successivo.
+
+### 5. Mappatura codici ↔ metodi tramite onTransact()
+Decompila il jar/odex che implementa l'interfaccia (per gli stub AOSP controlla `/system/framework`; gli OEM spesso usano `/system_ext` o `/vendor`).
+Cerca `Stub.onTransact()` – contiene un enorme `switch(transactionCode)`:
+```java
+case TRANSACTION_updateCtaAppStatus:      // 5
+data.enforceInterface(DESCRIPTOR);
+int appId  = data.readInt();
+boolean ok = data.readInt() != 0;
+updateCtaAppStatus(appId, ok);
+reply.writeNoException();
+return true;
+```
+Ora il prototipo e i **tipi di parametro** sono cristallini.
+
+### 6. Rilevare controlli di autorizzazione mancanti
+L'implementazione (spesso una classe `Impl` interna) è responsabile dell'autorizzazione:
+```java
+private void updateCtaAppStatus(int uid, boolean status) {
+if (!isPermissionAllowed()) {
+throw new SecurityException("uid " + uid + " rejected");
+}
+/* privileged code */
+}
+```
+L'assenza di tale logica o di una whitelist di UID privilegiati (ad es. `uid == 1000 /*system*/`) è un **indicatore di vulnerabilità**.
+
+Studio di caso – *MediaTek* `startMonitorProcessWithUid()` (transazione **8**) esegue completamente un messaggio Netlink **senza** alcun gate di permesso, consentendo a un'app non privilegiata di interagire con il modulo Netfilter del kernel e di riempire il log di sistema.
+
+### 7. Automazione della valutazione
+Strumenti / script che accelerano il riconoscimento di Binder:
+* [binderfs](https://android.googlesource.com/platform/frameworks/native/+/master/cmds/binderfs/) – espone `/dev/binderfs` con nodi per servizio
+* [`binder-scanner.py`](https://github.com/adenflare/binder-scanner) – attraversa la tabella binder e stampa le ACL
+* Scorciatoia Frida: `Java.perform(()=>console.log(android.os.ServiceManager.listServices().toArray()))`
+
+---
+
+## Riferimenti
+
+- [Android Services 101 – Pentest Partners](https://www.pentestpartners.com/security-blog/android-services-101/)
+- [Android Developer Docs – AIDL](https://developer.android.com/guide/components/aidl)
+- [Android Developer Docs – IBinder](https://developer.android.com/reference/android/os/IBinder)
+- [Understanding Binder, Talk @ Google](https://www.youtube.com/watch?v=O-UHvFjxwZ8)
+
 {{#include ../../banners/hacktricks-training.md}}