Español - Ht
HackTricks Training Twitter Linkedin Sponsor

Android Applications Basics

Aprende a hackear AWS desde cero hasta convertirte en un experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Grupo de Seguridad Try Hard

Modelo de Seguridad de Android

Hay dos capas:

  • El SO, que mantiene las aplicaciones instaladas aisladas entre sí.

  • La aplicación en sí, que permite a los desarrolladores exponer ciertas funcionalidades y configurar las capacidades de la aplicación.

Separación de UID

A cada aplicación se le asigna un ID de usuario específico. Esto se hace durante la instalación de la aplicación para que la aplicación solo pueda interactuar con archivos propiedad de su ID de usuario o archivos compartidos. Por lo tanto, solo la aplicación en sí, ciertos componentes del SO y el usuario root pueden acceder a los datos de las aplicaciones.

Compartir UID

Dos aplicaciones pueden configurarse para usar el mismo UID. Esto puede ser útil para compartir información, pero si una de ellas se ve comprometida, los datos de ambas aplicaciones se verán comprometidos. Por eso este comportamiento es desaconsejado. Para compartir el mismo UID, las aplicaciones deben definir el mismo valor android:sharedUserId en sus manifiestos.

Aislamiento

La Sandbox de Aplicaciones de Android permite ejecutar cada aplicación como un proceso separado bajo un ID de usuario separado. Cada proceso tiene su propia máquina virtual, por lo que el código de una aplicación se ejecuta de forma aislada de otras aplicaciones. A partir de Android 5.0(L) se aplica SELinux. Básicamente, SELinux denegó todas las interacciones de procesos y luego creó políticas para permitir solo las interacciones esperadas entre ellos.

Permisos

Cuando instalas una aplicación y solicita permisos, la aplicación está solicitando los permisos configurados en los elementos uses-permission en el archivo AndroidManifest.xml. El elemento uses-permission indica el nombre del permiso solicitado dentro del atributo de nombre. También tiene el atributo maxSdkVersion que deja de solicitar permisos en versiones superiores a la especificada. Ten en cuenta que las aplicaciones de Android no necesitan solicitar todos los permisos al principio, también pueden solicitar permisos dinámicamente pero todos los permisos deben estar declarados en el manifiesto.

Cuando una aplicación expone funcionalidades puede limitar el acceso solo a aplicaciones que tengan un permiso específico. Un elemento de permiso tiene tres atributos:

  • El nombre del permiso

  • El atributo permission-group, que permite agrupar permisos relacionados.

  • El nivel de protección que indica cómo se otorgan los permisos. Hay cuatro tipos:

  • Normal: Se utiliza cuando no hay amenazas conocidas para la aplicación. No se requiere que el usuario lo apruebe.

  • Peligroso: Indica que el permiso otorga a la aplicación solicitante cierto acceso elevado. Se solicita a los usuarios que los aprueben.

  • Firma: Solo las aplicaciones firmadas por el mismo certificado que la que exporta el componente pueden recibir permiso. Este es el tipo de protección más fuerte.

  • FirmaOSystema: Solo las aplicaciones firmadas por el mismo certificado que la que exporta el componente o las aplicaciones que se ejecutan con acceso a nivel de sistema pueden recibir permisos

Aplicaciones Preinstaladas

Estas aplicaciones generalmente se encuentran en los directorios /system/app o /system/priv-app y algunas de ellas están optimizadas (es posible que ni siquiera encuentres el archivo classes.dex). Vale la pena verificar estas aplicaciones porque a veces están ejecutándose con demasiados permisos (como root).

  • Las que se envían con el ROM de AOSP (Proyecto de Código Abierto de Android)

  • Agregadas por el fabricante del dispositivo

  • Agregadas por el proveedor de telefonía celular (si se compró a través de ellos)

Rooting

Para obtener acceso root en un dispositivo Android físico generalmente necesitas explotar 1 o 2 vulnerabilidades que suelen ser específicas para el dispositivo y la versión. Una vez que la explotación ha funcionado, generalmente se copia el binario su de Linux en una ubicación especificada en la variable de entorno PATH del usuario como /system/xbin.

Una vez configurado el binario su, se utiliza otra aplicación de Android para interactuar con el binario su y procesar solicitudes de acceso root como Superuser y SuperSU (disponibles en Google Play Store).

Ten en cuenta que el proceso de rooting es muy peligroso y puede dañar gravemente el dispositivo

ROMs

Es posible reemplazar el SO instalando un firmware personalizado. Haciendo esto es posible extender la utilidad de un dispositivo antiguo, evadir restricciones de software o acceder al código Android más reciente. OmniROM y LineageOS son dos de los firmwares más populares para usar.

Ten en cuenta que no siempre es necesario rootear el dispositivo para instalar un firmware personalizado. Algunos fabricantes permiten el desbloqueo de sus cargadores de arranque de manera documentada y segura.

Implicaciones

Una vez que un dispositivo está rooteado, cualquier aplicación podría solicitar acceso como root. Si una aplicación maliciosa lo obtiene, podrá acceder a casi todo y podrá dañar el teléfono.

Fundamentos de Aplicaciones Android

  • El formato de las aplicaciones de Android se denomina formato de archivo APK. Es esencialmente un archivo ZIP (al cambiar la extensión del archivo a .zip, se pueden extraer y ver los contenidos).

  • Contenidos de APK (No exhaustivo)

  • AndroidManifest.xml

  • resources.arsc/strings.xml

  • resources.arsc: contiene recursos precompilados, como XML binario.

  • res/xml/files_paths.xml

  • META-INF/

  • ¡Aquí se encuentra el Certificado!

  • classes.dex

  • Contiene bytecode de Dalvik, que representa el código Java (o Kotlin) compilado que la aplicación ejecuta de forma predeterminada.

  • lib/

  • Contiene bibliotecas nativas, segregadas por arquitectura de CPU en subdirectorios.

  • armeabi: código para procesadores basados en ARM

  • armeabi-v7a: código para procesadores basados en ARMv7 y superiores

  • x86: código para procesadores X86

  • mips: código solo para procesadores MIPS

  • assets/

  • Almacena archivos diversos necesarios para la aplicación, potencialmente incluyendo bibliotecas nativas adicionales o archivos DEX, a veces utilizados por autores de malware para ocultar código adicional.

  • res/

  • Contiene recursos que no se compilan en resources.arsc

Dalvik & Smali

En el desarrollo de Android, se utiliza Java o Kotlin para crear aplicaciones. En lugar de utilizar el JVM como en las aplicaciones de escritorio, Android compila este código en código de bytes Dalvik Ejecutable (DEX). Anteriormente, la máquina virtual Dalvik manejaba este código de bytes, pero ahora, en las versiones más recientes de Android, el Android Runtime (ART) se encarga de ello.

Para ingeniería inversa, Smali se vuelve crucial. Es la versión legible por humanos del código DEX, actuando como lenguaje ensamblador al traducir el código fuente en instrucciones de bytes. Smali y baksmali se refieren a las herramientas de ensamblaje y desensamblaje en este contexto.

Intents

Los Intents son el principal medio por el cual las aplicaciones de Android se comunican entre sus componentes o con otras aplicaciones. Estos objetos de mensaje también pueden transportar datos entre aplicaciones o componentes, de manera similar a cómo se utilizan las solicitudes GET/POST en las comunicaciones HTTP.

Entonces, un Intent es básicamente un mensaje que se pasa entre componentes. Los Intents pueden ser dirigidos a componentes o aplicaciones específicas, o pueden ser enviados sin un destinatario específico. Para simplificar, un Intent se puede utilizar para:

  • Iniciar una Actividad, típicamente abriendo una interfaz de usuario para una aplicación

  • Como difusiones para informar al sistema y a las aplicaciones de cambios

  • Para iniciar, detener y comunicarse con un servicio en segundo plano

  • Para acceder a datos a través de ContentProviders

  • Como devoluciones de llamada para manejar eventos

Si son vulnerables, los Intents pueden ser utilizados para llevar a cabo una variedad de ataques.

Filtro de Intents

Los Filtros de Intents definen cómo una actividad, servicio o Receptor de Difusión puede interactuar con diferentes tipos de Intents. Básicamente, describen las capacidades de estos componentes, como las acciones que pueden realizar o los tipos de difusiones que pueden procesar. El lugar principal para declarar estos filtros es dentro del archivo AndroidManifest.xml, aunque para los Receptores de Difusión, también es una opción codificarlos.

Los Filtros de Intents están compuestos por categorías, acciones y filtros de datos, con la posibilidad de incluir metadatos adicionales. Esta configuración permite a los componentes manejar Intents específicos que coincidan con los criterios declarados.

Un aspecto crítico de los componentes de Android (actividades/servicios/proveedores de contenido/receptores de difusión) es su visibilidad o estado público. Un componente se considera público y puede interactuar con otras aplicaciones si está exported con un valor de true o si se declara un Filtro de Intent para él en el manifiesto. Sin embargo, los desarrolladores pueden mantener explícitamente privados estos componentes para asegurarse de que no interactúen con otras aplicaciones involuntariamente. Esto se logra configurando el atributo exported en false en sus definiciones de manifiesto.

Además, los desarrolladores tienen la opción de asegurar aún más el acceso a estos componentes al requerir permisos específicos. El atributo permission se puede configurar para hacer cumplir que solo las aplicaciones con el permiso designado puedan acceder al componente, agregando una capa adicional de seguridad y control sobre quién puede interactuar con él.

<activity android:name=".MyActivity" android:exported="false">
<!-- Intent filters go here -->
</activity>

Intenciones implícitas

Las intenciones se crean programáticamente utilizando un constructor de Intenciones:

Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));

El Action del intent previamente declarado es ACTION_SEND y el Extra es un Uri de mailto (el Extra es la información adicional que el intent espera).

Este intent debe ser declarado dentro del manifiesto como en el siguiente ejemplo:

<activity android:name="ShareActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>

Un intent-filter necesita coincidir con la acción, datos y categoría para recibir un mensaje.

El proceso de "resolución de intenciones" determina qué aplicación debe recibir cada mensaje. Este proceso considera el atributo de prioridad, que se puede establecer en la declaración del intent-filter, y se seleccionará el que tenga la prioridad más alta. Esta prioridad se puede establecer entre -1000 y 1000 y las aplicaciones pueden usar el valor SYSTEM_HIGH_PRIORITY. Si surge un conflicto, aparece una ventana de "selector" para que el usuario pueda decidir.

Intenciones Explícitas

Una intención explícita especifica el nombre de la clase a la que apunta:

Intent downloadIntent = new (this, DownloadService.class):

En otras aplicaciones, para acceder al intent previamente declarado, puedes usar:

Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);

Intenciones Pendientes

Estas permiten que otras aplicaciones realicen acciones en nombre de tu aplicación, utilizando la identidad y permisos de tu aplicación. Al construir una Intención Pendiente, se debe especificar una intención y la acción a realizar. Si la intención declarada no es explícita (no declara qué intención puede llamarla), una aplicación maliciosa podría realizar la acción declarada en nombre de la aplicación víctima. Además, si no se especifica una acción, la aplicación maliciosa podrá realizar cualquier acción en nombre de la víctima.

Intenciones de Difusión

A diferencia de las intenciones anteriores, que solo son recibidas por una aplicación, las intenciones de difusión pueden ser recibidas por múltiples aplicaciones. Sin embargo, a partir de la versión 14 de la API, es posible especificar la aplicación que debe recibir el mensaje utilizando Intent.setPackage.

Alternativamente, también es posible especificar un permiso al enviar la difusión. La aplicación receptora necesitará tener ese permiso.

Existen dos tipos de Difusiones: Normales (asincrónicas) y Ordenadas (sincrónicas). El orden se basa en la prioridad configurada dentro del receptor. Cada aplicación puede procesar, retransmitir o descartar la Difusión.

Es posible enviar una difusión utilizando la función sendBroadcast(intent, receiverPermission) de la clase Context. También se puede utilizar la función sendBroadcast del LocalBroadCastManager para asegurar que el mensaje nunca abandone la aplicación. Al hacer esto, ni siquiera necesitarás exportar un componente receptor.

Difusiones Pegajosas

Este tipo de Difusiones pueden ser accedidas mucho tiempo después de ser enviadas. Estas fueron desaprobadas en el nivel de API 21 y se recomienda no utilizarlas. Permiten que cualquier aplicación husmee los datos, pero también los modifique.

Si encuentras funciones que contienen la palabra "pegajoso" como sendStickyBroadcast o sendStickyBroadcastAsUser, verifica el impacto e intenta eliminarlas.

Enlaces Profundos / Esquemas de URL

En las aplicaciones de Android, los enlaces profundos se utilizan para iniciar una acción (Intención) directamente a través de una URL. Esto se hace declarando un esquema de URL específico dentro de una actividad. Cuando un dispositivo Android intenta acceder a una URL con este esquema, se inicia la actividad especificada dentro de la aplicación.

El esquema debe ser declarado en el archivo AndroidManifest.xml:

[...]
<activity android:name=".MyActivity">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="examplescheme" />
</intent-filter>
[...]

El esquema del ejemplo anterior es exampleapp:// (nota también la categoría BROWSABLE)

Luego, en el campo de datos, puedes especificar el host y path:

<data android:scheme="examplescheme"
android:host="example"
/>

Para acceder desde la web es posible establecer un enlace como:

<a href="examplescheme://example/something">click here</a>
<a href="examplescheme://example/javascript://%250dalert(1)">click here</a>

Para encontrar el código que se ejecutará en la aplicación, ve a la actividad llamada por el enlace profundo y busca la función onNewIntent.

Aprende cómo llamar a enlaces profundos sin usar páginas HTML.

AIDL - Android Interface Definition Language

El Lenguaje de Definición de Interfaz de Android (AIDL) está diseñado para facilitar la comunicación entre el cliente y el servicio en aplicaciones de Android a través de la comunicación entre procesos (IPC). Dado que en Android no está permitido acceder directamente a la memoria de otro proceso, AIDL simplifica el proceso al convertir objetos en un formato entendido por el sistema operativo, facilitando así la comunicación entre diferentes procesos.

Conceptos Clave

  • Servicios Vinculados: Estos servicios utilizan AIDL para IPC, permitiendo que actividades o componentes se vinculen a un servicio, realicen solicitudes y reciban respuestas. El método onBind en la clase del servicio es crítico para iniciar la interacción, por lo que es un área vital para la revisión de seguridad en busca de vulnerabilidades.

  • Messenger: Funcionando como un servicio vinculado, Messenger facilita el IPC con un enfoque en el procesamiento de datos a través del método onBind. Es esencial inspeccionar este método detenidamente en busca de un manejo inseguro de datos o la ejecución de funciones sensibles.

  • Binder: Aunque el uso directo de la clase Binder es menos común debido a la abstracción de AIDL, es beneficioso entender que Binder actúa como un controlador a nivel de kernel que facilita la transferencia de datos entre los espacios de memoria de diferentes procesos. Para una mayor comprensión, hay un recurso disponible en https://www.youtube.com/watch?v=O-UHvFjxwZ8.

Componentes

Estos incluyen: Actividades, Servicios, Receptores de Difusión y Proveedores.

Actividad de Inicio y otras actividades

En las aplicaciones de Android, las actividades son como pantallas que muestran diferentes partes de la interfaz de usuario de la aplicación. Una aplicación puede tener muchas actividades, cada una presentando una pantalla única al usuario.

La actividad de inicio es la puerta de entrada principal a una aplicación, se inicia cuando se toca el icono de la aplicación. Se define en el archivo de manifiesto de la aplicación con intenciones MAIN y LAUNCHER específicas:

<activity android:name=".LauncherActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

No todos las aplicaciones necesitan una actividad de lanzamiento, especialmente aquellas sin una interfaz de usuario, como los servicios en segundo plano.

Las actividades pueden estar disponibles para otras aplicaciones o procesos marcándolas como "exportadas" en el manifiesto. Esta configuración permite que otras aplicaciones inicien esta actividad:

<service android:name=".ExampleExportedService" android:exported="true"/>

Sin embargo, acceder a una actividad desde otra aplicación no siempre es un riesgo de seguridad. La preocupación surge si se comparten datos sensibles de manera inadecuada, lo que podría llevar a fugas de información.

El ciclo de vida de una actividad comienza con el método onCreate, configurando la interfaz de usuario y preparando la actividad para la interacción con el usuario.

Subclase de Aplicación

En el desarrollo de Android, una aplicación tiene la opción de crear una subclase de la clase Application, aunque no es obligatorio. Cuando se define dicha subclase, se convierte en la primera clase que se instancia dentro de la aplicación. El método attachBaseContext, si se implementa en esta subclase, se ejecuta antes del método onCreate. Esta configuración permite una inicialización temprana antes de que el resto de la aplicación comience.

public class MyApp extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// Initialization code here
}

@Override
public void onCreate() {
super.onCreate();
// More initialization code
}
}

Servicios

Los servicios son operativos en segundo plano capaces de ejecutar tareas sin una interfaz de usuario. Estas tareas pueden seguir ejecutándose incluso cuando los usuarios cambian a diferentes aplicaciones, lo que hace que los servicios sean cruciales para operaciones de larga duración.

Los servicios son versátiles; pueden iniciarse de varias formas, siendo los Intents el método principal para lanzarlos como punto de entrada de una aplicación. Una vez que un servicio se inicia utilizando el método startService, su método onStart entra en acción y sigue ejecutándose hasta que se llama explícitamente al método stopService. Alternativamente, si el rol de un servicio depende de una conexión activa con el cliente, se utiliza el método bindService para vincular el cliente al servicio, involucrando el método onBind para el paso de datos.

Una aplicación interesante de los servicios incluye la reproducción de música en segundo plano o la obtención de datos de red sin obstaculizar la interacción del usuario con una aplicación. Además, los servicios pueden hacerse accesibles a otros procesos en el mismo dispositivo a través de la exportación. Este no es el comportamiento predeterminado y requiere una configuración explícita en el archivo Android Manifest:

<service android:name=".ExampleExportedService" android:exported="true"/>

Receptores de difusión

Los receptores de difusión actúan como oyentes en un sistema de mensajería, permitiendo que múltiples aplicaciones respondan a los mismos mensajes del sistema. Una aplicación puede registrar un receptor de dos formas principales: a través del Manifiesto de la aplicación o dinámicamente dentro del código de la aplicación mediante la API registerReceiver. En el Manifiesto, las difusiones se filtran con permisos, mientras que los receptores registrados dinámicamente también pueden especificar permisos al registrarse.

Los filtros de intención son cruciales en ambos métodos de registro, determinando qué difusiones activan el receptor. Una vez que se envía una difusión coincidente, se invoca el método onReceive del receptor, lo que permite a la aplicación reaccionar en consecuencia, como ajustar el comportamiento en respuesta a una alerta de batería baja.

Las difusiones pueden ser asincrónicas, llegando a todos los receptores sin orden, o sincrónicas, donde los receptores reciben la difusión según las prioridades establecidas. Sin embargo, es importante tener en cuenta el riesgo de seguridad potencial, ya que cualquier aplicación puede priorizarse a sí misma para interceptar una difusión.

Para comprender la funcionalidad de un receptor, busque el método onReceive dentro de su clase. El código de este método puede manipular la Intención recibida, resaltando la necesidad de validación de datos por parte de los receptores, especialmente en Difusiones Ordenadas, que pueden modificar o eliminar la Intención.

Proveedor de contenido

Los proveedores de contenido son esenciales para compartir datos estructurados entre aplicaciones, enfatizando la importancia de implementar permisos para garantizar la seguridad de los datos. Permiten que las aplicaciones accedan a datos de diversas fuentes, incluidas bases de datos, sistemas de archivos o la web. Los permisos específicos, como readPermission y writePermission, son cruciales para controlar el acceso. Además, se puede otorgar acceso temporal a través de la configuración grantUriPermission en el manifiesto de la aplicación, aprovechando atributos como path, pathPrefix y pathPattern para un control de acceso detallado.

La validación de entrada es fundamental para prevenir vulnerabilidades, como la inyección SQL. Los proveedores de contenido admiten operaciones básicas: insert(), update(), delete() y query(), facilitando la manipulación y el intercambio de datos entre aplicaciones.

FileProvider, un Proveedor de Contenido especializado, se centra en compartir archivos de forma segura. Se define en el manifiesto de la aplicación con atributos específicos para controlar el acceso a carpetas, indicadas por android:exported y android:resource que apuntan a configuraciones de carpetas. Se recomienda precaución al compartir directorios para evitar exponer datos sensibles inadvertidamente.

Declaración de ejemplo en el manifiesto para FileProvider:

<provider android:name="androidx.core.content.FileProvider"
android:authorities="com.example.myapp.fileprovider"
android:grantUriPermissions="true"
android:exported="false">
<meta-data android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/filepaths" />
</provider>

Y un ejemplo de cómo especificar carpetas compartidas en filepaths.xml:

<paths>
<files-path path="images/" name="myimages" />
</paths>

Para obtener más información, consulta:

WebViews

Los WebViews son como mini navegadores web dentro de las aplicaciones de Android, que muestran contenido ya sea desde la web o desde archivos locales. Enfrentan riesgos similares a los navegadores regulares, pero existen formas de reducir estos riesgos a través de configuraciones específicas.

Android ofrece dos tipos principales de WebViews:

  • WebViewClient es ideal para HTML básico pero no admite la función de alerta JavaScript, lo que afecta la forma en que se pueden probar los ataques XSS.

  • WebChromeClient actúa más como la experiencia completa del navegador Chrome.

Un punto clave es que los navegadores WebView no comparten cookies con el navegador principal del dispositivo.

Para cargar contenido, se pueden utilizar métodos como loadUrl, loadData, y loadDataWithBaseURL. Es crucial asegurarse de que estas URL o archivos sean seguros de usar. La configuración de seguridad se puede gestionar a través de la clase WebSettings. Por ejemplo, deshabilitar JavaScript con setJavaScriptEnabled(false) puede prevenir ataques XSS.

El "Bridge" de JavaScript permite que los objetos Java interactúen con JavaScript, lo que requiere que los métodos estén marcados con @JavascriptInterface para seguridad a partir de Android 4.2.

Permitir el acceso al contenido (setAllowContentAccess(true)) permite que los WebViews accedan a los Proveedores de contenido, lo cual podría ser un riesgo a menos que las URL de contenido se verifiquen como seguras.

Para controlar el acceso a archivos:

  • Deshabilitar el acceso a archivos (setAllowFileAccess(false)) limita el acceso al sistema de archivos, con excepciones para ciertos activos, asegurando que solo se utilicen para contenido no sensible.

Otros Componentes de la Aplicación y Gestión de Dispositivos Móviles

Firma Digital de Aplicaciones

  • La firma digital es imprescindible para las aplicaciones de Android, asegurando que estén autenticadas correctamente antes de la instalación. Este proceso utiliza un certificado para la identificación de la aplicación y debe ser verificado por el administrador de paquetes del dispositivo al instalarla. Las aplicaciones pueden ser auto-firmadas o certificadas por una CA externa, protegiéndose contra accesos no autorizados y asegurando que la aplicación permanezca intacta durante su entrega al dispositivo.

Verificación de Aplicaciones para una Seguridad Reforzada

  • A partir de Android 4.2, una función llamada Verificar Aplicaciones permite a los usuarios verificar la seguridad de las aplicaciones antes de la instalación. Este proceso de verificación puede advertir a los usuarios sobre aplicaciones potencialmente dañinas, o incluso prevenir la instalación de aquellas particularmente maliciosas, mejorando la seguridad del usuario.

Gestión de Dispositivos Móviles (MDM)

  • Las soluciones de MDM proporcionan supervisión y seguridad para dispositivos móviles a través de la API de Administración de Dispositivos. Requieren la instalación de una aplicación de Android para gestionar y asegurar dispositivos móviles de manera efectiva. Las funciones clave incluyen imponer políticas de contraseñas, exigir cifrado de almacenamiento, y permitir el borrado remoto de datos, asegurando un control y seguridad completos sobre los dispositivos móviles.

// Example of enforcing a password policy with MDM
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName adminComponent = new ComponentName(context, AdminReceiver.class);

if (dpm.isAdminActive(adminComponent)) {
// Set minimum password length
dpm.setPasswordMinimumLength(adminComponent, 8);
}

Grupo de Seguridad Try Hard

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

AnteriorAndroid Applications PentestingSiguienteAndroid Task Hijacking

Última actualización