Android e iOS

El presente libro es una recolección mía y personal de utilidades y tutoriales para Android e iOS.

Se incluyen tanto temas de seguridad como tutoriales e información sobre la arquitectura de los sistemas.

Toda la información contenida es mi completa autoria, así como las imágenes.

Copyright

La información acá presentada es libre, podes bajarla y hacer lo que quieras.

El conocimiento es libre.

Android - Introducción

Android es un sistema operativo, con soporte para ARM y x86, que utiliza el kernel Linux, librerías en Rust/C y la JVM (Java Virtual Machine) para hacer funcionar todo el sistema operativo.

Android fue desarrollado originalmente por Google, ahora siendo desarrollado por la Open Handset Alliance que la conforman; HTC, Sony, Dell, Intel, Motorola, Qualcomm, Texas Instruments, Google, Samsung, LG, T-Mobile, Nvidia, entre muchos otros.

Licenciamiento

Android está licenciado en “Apache License”, una licencia de fuente abierta (“open source”). Por lo que es normal encontrar en diversos lugares (Github, Gitlab, XDA Developers, etc) versionados (llamados ROMs) de distintas fuentes.

Distribuciones

Una distribución es todo sistema empaquetado y distribuido (de ahí el nombre) de diferentes formas, cada una con sus propias características. Generalmente se suelen encontrar diferencias pequeñas, aunque es normal (pero menos común) encontrar distribuciones con modificaciones tan profundas que a primera imagen parecen sistemas diferentes.

Acá un listado de distribuciones de Android, cada una con sus características;

AOSP (Android Open Source Project)

https://android.com/

Es la distribución original de Android, la creada por el consorcio “Open Handset Alliance” y sin productos internos de compañia alguna.

Así mismo, esta distribución es la considerada la “versión pura” debido a que no tiene; personalizaciones, productos internos de compañias, modificaciones internas, etc.

Se debe tener en cuenta que el kernel de esta distribución no tiene driver alguno, por lo que para ser compatible con un dispositivo se debe encontrar una modificación adaptada a ese dispositivo.

Su código se encuentra en este repositorio;
- https://android.googlesource.com/platform/
Lineage OS

https://www.lineageos.org/

Anteriormente conocido como “CyanogenMod”.

Distribución nacida en el 2016 cuando “CyanogenMod” finalizó como proyecto. A diferencia del primero, este proyecto es comunitario de forma completa, por lo que no lo domina ninguna compañía.

Se basa en AOSP para aplicar modficaciones que le dan muchísima más personalización y poder de control al usuario propietario del dispositivo (overclocking, control de root, etc) sin incluir bloatware (software basura; publicidad, etc) que viene con teléfonos con distribuciones modificadas por compañías.

Así mismo aplica modificaciones en el código de AOSP, en donde generalmente se encargan de hacer modificaciones de performance (optimizaciones a todo nivel) como AudioFX, etc.

Su código se encuentra en estos repositorios;
- https://github.com/LineageOS/android
- https://gitlab.com/LineageOS/android/android_system_core
Android x86

https://www.android-x86.org/

Es una distribución de AOSP, pero se enfoca en dar soporte para la arquitectura x86_64.

Hay que tener en consideración que no todas las apps de la Play Store tienen soporte para x86, ya que la mayoría están para ARM64. Por lo que puede ser que algunas aplicaciones no se encuentren disponibles.

Su código se encuentra en este repositorio;
- https://git.osdn.net/view?a=project_list;pf=android-x86

Android - Arquitectura

Todas las distribuciones de Android siguen la misma arquitectura (para mantener la compatibilidad de aplicaciones).

Bootloader

Los dispositivos ARM tienen una característica; dependen de una implementación externa para tener un bootloader funcional.

De esta manera nos podemos encontrar diferentes bootloaders dependiendo del fabricante, cada uno tiene su propia implementación. Sumale que al ser propietarios, la mayoría son de código cerrado, sin documentaciones y de extrema dificultad para acceder (es parte del firmware embebido).

El bootloader es el encargado de (en este orden); ver e inicializar la memoria, verificar que los certificados del sistema operativo Android sean del fabricante (que está intrinsicamente relacionado al uso de UEFI y el bloqueo OEM), verificar las particiones “boot”, “dtbo”, “init_boot” y “recovery”, verificar si existen actualizaciones aplicar en el sistema o si al fallar el sistema (o si el usuario mantiene los botones correctos) debe iniciar el modo recovery.

Por último, carga las imágenes de inicio; “boot.img”, “vendor_boot.img”, “init_boot.img” y otras imágenes propietarias del fabricante. Al igual que que u-boot, grub, lilo y demás cargadores carga el kernel y el “initramfs” en memoria.

A partir de Android 12 el bootloader soporta pasar configuraciones al kernel para modificar el inicio por defecto.

En el archivo; system/core/mkbootimg/bootimg.h está la configuración de inicio.

En sistemas Android hablamos del modo “fasboot” cuando podemos interactuar con el bootloader. Sus estados son “LOCKED” ó “UNLOCKED”, dependiendo uno u otro va impedir la instalación de otro SO o no (respectivamente). Por defecto en encuentra en modo “LOCKED”, permitiendo cargar una distribución Android firmada digitalmente por el fabricante. Ese certificado digital es lo que se conoce como “Root of Trust”, y en el dispositivo solamente se encuentra la parte pública de esa llave, el fabricante se queda con la privada. Algunos dispositivos permiten que el usuario indique su propia llave, pero no es la norma.
Kernel

Utilizan el kernel Linux con algunas modificaciones para alivianar el mismo.

Android posee de forma nativa habilitado SELinux (Security Enhanced Linux), entre otros componentes a nivel de kernel.
Android ART / Dalvik

Tanto Dalvik como ART (Android Runtime) son entornos de ejecución (véase, presenta y contiene todo para que aplicaciones se puedan ejecutar apropiadamente arriba) que se utilizan para hacer andar las aplicaciones en el sistema operativo.

Desde hace un tiempo ART ya remplaza a Dalvik.

Como ART y Dalvik usan Java para funcionar, ocurria un problema; como Java (no confundir con JavaScript, son dos cosas diferentes) es un lenguaje interpretado, cada vez que la aplicación se iniciaba había que esperar a que la aplicación se compile para luego poder ejecutarla (lo que se conoce como “JIT”: “just-in-time”) cuando se usaba Dalvik. Esto no es así con el uso de ART, en donde se usa un esquema de “AOT”; “ahead-of-time” que compila la aplicación apenas es instalada en el dispositivo.

Así mismo ART trae mejoras en rendimiento, el recolector de basura (característica de los lenguajes interpretados), depuración de la aplicación, etc. Y empezó a estar disponible a partir de Android 4.4.

Dalvik usa archivos “.dex” cuando la aplicación es compilada e iniciada (“DEX”; “Dalvik EXecutable”). El archivo APK contiene un solo archivo “dex” llamado “classes.dex”, por temas de compatibilidad esto se mantiene en ART.

Dalvik usa archivos “.odex” cuando cachea (véase; procesar y almacenar cosas que no cambian) la aplicación, para hacer más rápido su inicio. Muchas veces esto también se usaba para segmentar la aplicación hasta tal punto que sí o sí parte de la misma estaba solamente en el archivo “.odex”, haciendo tremendamente dificil su ingenieria inversa ya que se tenía que realizar el proceso inverso y empaquetar todo correctamente dentro del apk. Esto no se mantiene en ART, si no que utiliza el formato ejecutable nativo del kernel Linux; “ELF”: “Executable and Linkable Format” el cual permite una mayor optimización en muchos sentidos (la librería estándar, las dependencias externas, el “LTO”: “Link Time Optimization”, etc) y un menor consumo de recursos en todo sentido.

Copyright; Wikipedia

Si hasta ahora vas entendiendo te darás cuenta de una cosa si queres realizar ingeniería inversa a un programa; como desde Android 4.4 KitKat se usa principalmente ART vas a tener que urgar en el apk los archivos “dex” y tener conocimiento de Java o Kotlin para poder entender que hace la aplicación leyendo el código.


Copyright; Wikipedia

Android - Seguridad

Android - Correr un Linux ARM nativo dentro

Acá describo los pasos necesarios para poder ejecutar una distribución Linux dentro de Android sin necesidad de root. Yo elegí la distribución Alpine pero ustedes pueden usar la que quieran, dentro del catálogo disponible claro.

Instalar Fdroid

Fdroid es una tienda de aplicaciones opensource (tanto las apps que almacena como la tienda en sí misma) con repositorio de código en;

https://github.com/f-droid

Para instalarlo van al siguiente enlace y instalan el archivo “apk”; https://f-droid.org/F-Droid.apk
Instalar Termux

Desde FDroid instalen Termux, un emulador de terminar con algunas utilidades de sistemas GNU/Linux. No recomiendo la versión que está en la Play Store, ya que esta tiene un teclado mucho peor, la versión proveniente de FDroid tiene un teclado con las teclas de; “tab”, “ctrl”, flechas de dirección (arriba, abajo, izquierda, derecha), “home”, “end”, “/”, “ESC”, “pgup” y “pgdown”
Instalar Andronix

Desde la Play Store instalen “Andronix - Linux on Android”
- https://play.google.com/store/apps/details?id=studio.com.techriz.andronix&hl=es_419&gl=US
Instalar una distribución

Abren “Andronix” y selecionan “Linux Distribution”

Les va aparecer el listado de distribuciones disponibles, yo voy a usar Alpine Linux (se encuentra debajo de todo).

Luego tienen que instalarlo, recomiendo que usen el “CLI Only” ya que a veces el Android no dejará que se inicien aplicaciones gráficas (por falta de memoria o por el contexto de seguridad de SELinux o Knox).

Luego en la pestaña “Termux Execution” seleccionan “Open Termux” y mantienen apretado sobre la shell para darle a “Pegar”/“Paste” y que les aparezca el comando para instalar el entorno de la distribución.

pkg update -y && pkg install wget curl proot tar -y && wget https://raw.githubusercontent.com/AndronixApp/AndronixOrigin/master/Installer/Alpine/alpine.sh -O alpine.sh && chmod +x alpine.sh && bash alpine.sh://raw.githubusercontent.com/AndronixApp/AndronixOrigin/master/Installer/Alpine/alpine.sh && chmod +x alpine.sh && bash alpine.sh
Entorno Linux

Con el comando que les da Andronix se instala todo lo necesario y luego se inicia el entorno de la distribución (en un chroot).

Pero no se puede hacer eso cada vez que quieren iniciar el Linux ya instalado, simplemente abren Termux y ejecutan;

./start_X.sh

Siendo X la distro que seleccionaron. Luego ya estarán dentro como usuario root;
Utilidades y adicionales
1. Pueden abrir puertos sin problemas siempre y cuando sean del 1024 para arriba
2. Creense un usuario no root para que puedan usarlo con una sesión remota de ssh.
3. Instalen y configuren openssh para que; use un puerto por arriba de 1024, prohiba el usuario root y otras hardenizaciones que quieran realizar
  
  Primero hay que configurar las llaves internas de ssh;
  
  ssh-keygen -A
  
  Luego ya podemos configurar sshd (/etc/ssh/sshd_config);
```
Include /etc/ssh/sshd_config.d/*.conf

Port 2280
AddressFamily any
ListenAddress 0.0.0.0
ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

PermitRootLogin no
AuthorizedKeysFile	.ssh/authorized_keys
PasswordAuthentication yes
PermitEmptyPasswords no
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTTY yes
PrintMotd yes
```
  Una vez finalizado, se debe ejecutar por terminal (ya que no tenés un sysinit iniciado correctamente) con path absoluto;
  
  /usr/sbin/sshd
  
  Si no tira nada en la pantalla es que se inició bien.
4. Instalen “sudo” (en Alpine no conseguí que ande “doas”) y configurenlo (/etc/sudoers)
```
root ALL=(ALL:ALL) ALL
[tu_usuario] ALL=(ALL:ALL) ALL

@includedir /etc/sudoers.d
```

Android - Hacking/Pentesting

Bootloader

Hay que verificar si el dispositivo se encuentra con el bootloader desbloqueado (“UNLOCKED”) y si tiene (o no)

Ing. Inversa

El proceso de ingeniería inversa es tomar un producto/activo ya terminado y funcional, para luego estudiar su composición interna para detectar, entender y comprender como fue creado, así como su funcionamiento interno.

Objetivos;

Entender como funciona la aplicación que estamos analizando
Detectar la utilización de algoritmos criptográficos vulnerables (como; SHA1, md5, SSLv3, TLSv1.0, etc).
Detectar errores lógicos en la aplicación a nivel de seguridad (como que se compare una llave con otros valores ya internos en la aplicación).
Detectar los lugares donde guarda la información, su codificación (si no se usa UTF-8 o ASCII ya vamos mal), sus metadatos que guarda, etc.
Detectar falencias en la resiliencia de la seguridad operacional; no verifica datos y tipos antes de leerlos, etc.

En Android los archivos apk son, desde hace bastantes versiones, compiladas en binario (archivos; .dex, .bundle, etc). Por lo que no se puede abrir el apk, descomprimirlo y leerlo en texto plano.

Hay que decompilarlo, véase; convertir de binario a texto UTF-8.

Podemos usar dos herramientas;

apktool https://github.com/ibotpeaches/apktool/
jadx https://github.com/skylot/jadx

Ambos requieren como dependencia a java (java-openjdk):

apktool d [archivo_apk]

En Android una vez devuelto la decompilación hay que revisar los archivos con extensión “smali”, el código ahí tiene el byte-code del código Java original. Es el equivalente a leer el ensamblador en un programa compilado.

Secretos

Se deben buscar, tanto en los archivos “smali” como en el código claro accesible variables de tipo string y str que tengan nombres como; “key”, “passwd”, “pass”, etc. Acá limpie un poco la salida para que no incluya cosas internas del SO o de Google (firebase, androidx, etc)

grep -Eirl “key|pass|crypt” * | grep -Eiv “google|firebase|androidx|lib|drawable”

Así mismo debemos verificar si la firma del desarrollador fue utilizado para firmar el instalador, de esta manera nos aseguramos si fue correctamente o no creada.

Se requiere del programa “apksigner” (viene dentro del programa android-sdk-build-tools en los repositorios de Kali, BlackArch, etc)

apksigner verify [archivo].apk

Si no devuelve nada es que no está firmado.

Ubicación de los archivos

La ubicación de los archivos corresponde a los de la aplicación y sus datos se encuentran separados.

Sistema; /data/app/[app_name_id]
Datos; /data/data/[app_name_id]

Instalación de la aplicación

Solamente con “adb” estamos:

Primero nos conectamos al dispositivo (debe estar el debug habilitado por usb)

adb connect [IP]:5555

Luego instalamos remotamente en el dispositivo el apk

adb install [Archivo].apk

Si tira un error del tipo “Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113” quiere decir que la arquitectura que estás usando en el Android (arm64, armehb, x86_64, etc) no es compatible con el de la aplicación.

Man in the middle (MITM) - Red

Recomiendo usar mitmproxy, ya que permite ver todo mucho más claramente y automatizar todo con python.

Primero se instala en el host mitmproxy.
Luego lo iniciamos con los siguientes argumentos;

-k -p8080 –anticomp –anticache

-k = indica que no verifique la autenticidad del certificado remoto del servidor

-p8080 = indica que el servidor mitmproxy debe usar el puerto 8080 para las conexiones entrantes

–anticomp = indica que la conexión con el servidor remoto no debe usar archivos comprimidos

–anticache = indica que la conexión con el servidor remoto no debe usar caché
Conectamos el dispositivo Android al servidor proxy;
1. “Ajustes” -> “Wifi” -> [Conexión] -> “Proxy”
Vamos a mitm.it
Clickeamos en “Android”, bajamos el certificado y luego lo importamos para todas las apps.
Si la aplicación objetivo no tiene “certificate pinning” vamos a empezar a ver su tráfico, si lo tiene veremos en mitmproxy un error de TLS handshake.

Hacking con Frida

Frida es un framework de escucha y respuesta instrumental para sistemas móbiles de Android y Linux

Dependencias

Host;
- Paquetes; Python, adb, python-setuptools
- Infraestructura; Android con usb-debug habilitado y conectado (adb connect [IP]:5555)

Instalación

En el linux, en un usuario NO root;

pip install frida-tools

En sistemas como Arch pip está bloqueado a los repositorios oficiales. En ese caso remplazar “pip” por “pipx” (previa instalación de python-pipx).

Descargar el frida-server;

https://github.com/frida/frida/releases

Luego ejecutar;

adb root

adb push frida-server /data/local/tmp/

adb shell “chmod 755 /data/local/tmp/frida-server”

adb shell “/data/local/tmp/frida-server &”

Y comprobar que se esté ejecutando;

adb shell “ps -A | grep -i frida “

Comprobar su funcionamiento (se obtiene el ID con; adb devices -l)

frida-ps -D [ID]

Instrumentación

Frida se basa en interceptar llamadas.

Por lo que se debe primero saber qué se quier hacer; ¿querés evadir las detecciones y medidas de seguridad de antiroot? Eso es lo que describiré a continuación.

Debes saber que siempre tenés que tener algún archivo javascript, eso es lo que interpreta el engine de Frida para modificar la app en tiempo real.

Aplicación objetivo

Primero hay que detectar cual es la aplicación objetivo que se quiere vulnerar mediante Frida

adb shell “ cmd package list packages -U -i -f“

El comando anterior mostrará los paquetes con esta sintaxis;

package:[ruta_al_archivo_apk]=[app_name_id] installer=[aplicación_que_la_instaló] uid:[uid_numérico_de_la_app]

Ejecución en un dispositivo

Frida puede conectarse por; usb, adb remoto IP, ID dispositivo, etc.

Ergo; recomiendo que sea por USB (en caso de iOS y Android) con “-U”, y/o por adb (en caso de Android) con “-D [device_ID]”.

En el caso de “-D” se obtiene con “adb devices -l”

frida -D [device_id] -f ‘[app_name_id]’ -l [archivo_js]

También se puede ejecutar un script directamente desde la web de Frida

frida -D [device_id] -f ‘[app_name_id]’ –codeshare [usuario]/[código]

ByPass root

Generalmente las apps o librerías de detección de root como “rootbeer” (entre otros), que funcionan detectando archivos en el filesystem u otras llamadas simples, ergo la forma es interceptar tales llamadas e indicarles que todo esta como si nunca se hubiera hecho root.

Uno debe buscar (“frida bypass root detection” en google) que el funcione para la aplicación que está deseando auditar y usar alguna de las dos ejecuciones anteriormente indicadas.

Por ejemplo;

frida –codeshare dzonerzy/fridantiroot -f [app_name_id] -D [device_id]

Seguimiento de actividades

Podes hacer un seguimiento a bajo nivel de que está haciendo la aplicación objetivo, y descubrir cosas nuevas sobre ella con;

frida-trace -D [device_id] -f [app_name_id]

El comando superior no hará mucho, o hará todo (dependiendo como lo veas y lo que necesites). Es mejor filtrar que necesitamos;

frida-trace -D [device_id] -f [app_name_id] -i “[funciones]”

El filtrar por funciones (’ -i “[funciones]” ’) es muy útil. Pero teniendo en cuenta que las apps en Android usan ART

iOS - Seguridad

iOS - Proceso de jailbreak

Para hacer jailbreak en iOS 16 vamos a usar; palera1n.

Se debe tener en consideración que no siempre se soporta la última versión, cada método tiene consideraciones.

Consideraciones previas

Usaremos un sistema Linux Live basado en Alpine para el proceso, por lo que necesitarás estar cómodo con la línea de comandos y saber como plasmar un archivo “iso” (una imagen de disco) en un pendrive.
El jailbreak no va a funcionar si antes ya fue toqueteado internamente el iOS. Hagan una restauración de fábrica ya que si no se corrompe y no funciona el FakeFS (Fake File System) que se usa como remplazo del verdadero sistema de archivos del iOS.
No deben iniciar sesión con el Apple ID hasta que lo indique en la siguiente sección.
Al momento de escribir esto se soporta hasta iOS 16.5.1.
Este es un método “semi thered”, lo que significa que si el dispositivo se apaga o reinicia (por que se quedó sin bateria o por que vos lo reiniciaste) se pierde el jailbreak pero el sistema seguirá funcionando.
En el caso de perder el jailbreak, por apagado o reinicio, deben repetir todo el proceso desde cero.

Proceso de Jailbreak

Una vez restaurado de fábrica el dispositivo, bajarás la ISO desde el github propio de palera1n; https://github.com/palera1n/palen1x/releases

Es la aplicación de palera1n en forma de una distro basada en Alpine, así se evitan problemas de kernel o customizaciones de sus linux.

Descargada la iso, la plasman en un pendrive.

dd if=palen1x-amd64.iso of=/dev/[pendrive]
Reinician y bootean desde ese pendrive.
Entran en la opción; “palera1n”
Van a “switch” y seleccionan “Rootful”
Van a “Options” y selecciona “Fake FS”
Fíjense (arriba a la izquierda) que les debe quedar los argumentos ; “-f -c -v”
Le dan a “Start” y siguen el procedimiento que aparece en la terminal. La creación del “Fake FS” suele tomar 10 minutos aproximadamente.
Una vez finaliza y bootea el iOS lo dejan así como está.
Apretan “Ctrl”+“C” en el palera1n y tipean “exit” para volver al menú de TUI (Terminal User Interface).
Vuelven a hacer el paso 4, pero no el 5, quedando sin el “Fake FS” y con los argumentos; “-f -v”
Le dan a “Start” y siguen el procedimiento que aparece en la terminal. Aproximadamente 5 minutos después ya tienen el iOS booteado y con jailbreak.
Ahora sí, se loguean con el Apple ID.
En el homescreen van a ver la aplicación de “palera1n” (es una gota con color parecido a petróleo).
Entran en la app e instalan “Sileo”, es una de las pocas tiendas que siguen funcionando en iOS 16. Cydia no funciona desde hace algunas generaciones.
Buscan el paquete; “openssh”. Es un meta paquete que instala “openssh-client” y “openssh-server”.
Al instalar los anteriores les pide una contraseña para “sudo”.
Pueden instalar;
- “Terminal” para tener un acceso a terminal
- “Filza” para poder navegar por todo el sistema sin límite.
- “TrollStore” y “TrollStore Helper” para desde ahí poder instalar archivos “ipa”.
- “Antoine” para poder ver todos los logs (registros) del sistema y aplicaciones en ejecución.
Terminal;
- Hay repos que no tienen la gpg key en el propio repo keyring, si al hacer “sudo apt update” (en la Terminal o por ssh) se tiene esos errores se debe hacer (por ejemplo);
wget -qO - https://repo.palera.in/palera1n.gpg | sudo apt-key add -

iOS - Hacking/Pentesting

Acá es requisito casi indispensable tener jailbreak, ni yo ni vos somos expertos que podemos encontrar zero days en un dispositivo sin eso.

En iOS se utiliza el lenguaje Swift para programar las aplicaciones. Es un lenguaje compilado por lo que no se puede leer así no más.

Para realizar el proceso de ingeniería inversa en iOS se debe utilizar algún desamblador (‘disassembler’ en inglés) que permita leer el código en ensamblador. Hay muchos o pocos, dependiendo de tu experiencia y capacidades así como de lo que necesites, pero acá una lista;

Una vez abierto el desamblador, se abre el ipa (o su archivo binario interno si da error) y a ponerse analizar, acá dependes de tus conocimientos en ensamblador.

Ubicación de los archivos

La ubicación de los archivos corresponde a los de la aplicación y sus datos, en ambas plataformas (Android e iOS) se encuentran separados.

Datos; /var/mobile/Containers/Data/Application/[app_name_id]
Sistema; /Applications
App ID; /var/mobile/Containers/Bundle/Application/[app_name_id]

Hacking con frida

Frida es un framework de escucha y respuesta instrumental para sistemas móbiles de Linux y BSD (entra iOS ahí).

Dependencias

Host;
- Paquetes; Python, python-setuptools
- Infraestructura;
  1. iOS con jailbreak
  2. El sistema iOS debe tener instalado frida-server de la tienda “pirata” que se esté utilizando.
  3. Se recomienda también que esté openssh-server funcionando.

Instalación

En el linux, en un usuario NO root;

pip install frida-tools

En sistemas como Arch pip está bloqueado a los repositorios oficiales. En ese caso remplazar “pip” por “pipx” (previa instalación de python-pipx).

Toda la conectividad se realiza sí o sí por el cable usb que debe estar conectado al sistema linux.

frida-ps -U

Instrumentación

Frida se basa en interceptar llamadas.

Por lo que se debe primero saber qué se quier hacer; ¿querés evadir las detecciones y medidas de seguridad de antiroot? Eso es lo que describiré a continuación.

Debes saber que siempre tenés que tener algún archivo javascript, eso es lo que interpreta el engine de Frida para modificar la app en tiempo real.

Aplicación objetivo

Primero hay que detectar cual es la aplicación objetivo que se quiere vulnerar mediante Frida

Recomiendo realizar una verificación de que programas están ejecutandose en el iOS y ahí determinar el nombre del proceso que queremos vulnerar:

firda-ps -U

Ejecución en un dispositivo

frida -U -f ‘[app_name_id]’ -l [archivo_js]

También se puede ejecutar un script directamente desde la web de Frida

frida -U -f ‘[app_name_id]’ –codeshare [usuario]/[código]

ByPass root

Uno debe buscar (“frida bypass root detection” en google) que el funcione para la aplicación que está deseando auditar y usar alguna de las dos ejecuciones anteriormente indicadas.

Por ejemplo;

frida –codeshare dzonerzy/fridantiroot -f [app_name_id] -U

Seguimiento de actividades

Podes hacer un seguimiento a bajo nivel de que está haciendo la aplicación objetivo, y descubrir cosas nuevas sobre ella con;

frida-trace -U -f [app_name_id]