Rappel de contexte sur Frida

Frida est un outil d’analyse dynamique de code binaire modulaire. Le fonctionnement général de Frida est le suivant : du code est injecté dans le processus à analyser, celui-ci peut alors manipuler l’état de la cible et dialoguer avec un processus maître extérieur.

L’intérêt principal de Frida est donc de permettre l’interception d’appels à certaines fonctions, API ou méthodes. Une fois l’appel intercepté, l’utilisateur peut alors choisir d’étudier les arguments passés à l’appel, étudier l’état du processus, modifier les arguments, appeler une autre fonction, modifier la valeur de retour, etc.

L’intérêt de Frida se trouve dans sa capacité :

• Interception

Possibilité de lire/enregistrer les arguments passés à une fonction ou le résultat d’une fonction. Utile dans le cas d’opération complexe ou pour obtenir une clé de (de)chiffrement par exemple

• Injection

Possibilité de modifier des données à la volée, pratique pour le fuzz d’application ou le contournement de mesures de sécurité (détection #root, #SSLPinning, etc.)

• Tracing

En interceptant les API et en journalisant leur exécution, il est possible d’avoir une vue d’ensemble de l’exécution du programme. Cela est réalisé grâce à l’outil #fridaTrace.

Frida-trace dans toute sa splendeur

Même si la description sur le site officiel de Frida semble un peu légère, nous allons commencer avec cette dernière : « frida-trace est un outil pour tracer dynamiquement les appels de fonction. »

Voici quelques commandes simples permettant de tracer les méthodes d’un binaire iOS :

Trace de l’ensemble des méthodes (wildcard -> *)

# frida-trace -U -m «*[CLASSE METHODE] » 

Trace de l’ensemble des méthodes d’instances (instances -> -)

# frida-trace -U -m «-[CLASSE METHODE] » 

Trace de l’ensemble des méthodes de classe (classes -> +)

# frida-trace -U -m «+[CLASSE METHODE] » 

Si l’objectif de notre analyse est de comprendre le fonctionnement des requêtes envoyées par l’application (contournement de Certificate Pinning par exemple), alors, il est possible de tracer l’ensemble des méthodes de la classe NSURLRequest grâce à la commande suivante :

frida-trace -U -m « *[NSURLRequest *] » -n SecureStorev2

Une fois l’application « analysée », dès l’utilisation de l’application, l’ensemble des méthodes liées à la classe NSURLRequest sera retournée en spécifiant également les paramètres nécessaires :

From Frida-trace to Frida

Maintenant que nous disposons de l’ensemble des informations concernant nos classes et nos méthodes, il ne reste plus qu’à écrire notre script Frida permettant d’analyser nos données. Pour cela, il est possible de démarrer à partir du template https://github.com/rsenet/Frida-Templates/blob/main/Frida_iOS_Generic.js qui n’attend plus qu’à être complété :

La fonction onEnter est exécutée avant que la définition de la méthode ne soit exécutée

La fonction onLeave est exécutée lorsque la définition de la méthode est exécutée

Ainsi, en analysant le retour de Frida-trace, nous allons nous focaliser sur la fonction requestWithURL qui d’après le retour semble attendre un argument pouvant être une URL.

La documentation d’Apple nous confirme cela :

La ligne 5 est simple à modifier, il s’agit du nom de la classe, à savoir NSURLRequest, pas de piège. La ligne 6 comprend la méthode de classe (+) requestWithURL prenant un argument (:) et d’afficher dans notre fonction onEnter l’argument en question (attention, le premier argument commence à partir de args[2]) :

Finalement, il ne reste plus qu’à lancer le script Frida et d’attendre tranquillement que les données s’affichent :