Les deux dernières grosses failles de sécurité touchant le Mac, Thunderstrike et rootpipe, ont été découvertes à l'aide de Hopper Disassembler, un logiciel de rétro-ingénierie permettant de fouiller dans les entrailles de n'importe quelle application. Utilisé par des hackers hors pair, ce désassembleur a également permis de décortiquer UXKit, un nouveau framework privé d'Apple, de mettre en lumière le mode multifenêtre d'iOS 8 et de développer des logiciels modifiant le Finder, entre autres.

Hopper, vendu 89 € en licence personnelle (une version de démonstration est disponible), prend en charge les exécutables Mac, iOS, Linux et Windows. Interview de son créateur, Vincent Bénony.

MacGeneration : Qu'est-ce que permet de faire Hopper Disassembler ?

Vincent Bénony : Hopper Disassembler est un logiciel dont le but est d’étudier le fonctionnement interne d’autres applications. Il les analyse de manière automatique et les structure, un peu à la manière d'un microprocesseur. On parle d’analyse statique de code.

Hopper permet de visualiser le code assembleur, mais aussi de le manipuler de manière interactive. Il permet aussi de débugger, voire même de « décompiler » l’application sous certaines conditions.

Quelle est la différence entre désassembler une application et la décompiler ?

Le désassemblage consiste à transformer une séquence d’octets en suite d’instructions assembleur. C’est la partie la plus simple.

Si l’on regarde une application dans un éditeur hexadécimal, on peut voir qu’il ne s’agit que d’une longue suite d’octets, inintelligibles pour un être humain, où s’entremêlent du code et des données.

Le désassemblage consiste à simuler le travail de décodage du microprocesseur, afin de savoir quelle instruction il doit exécuter. Et pour ça, le microprocesseur va lire un octet à la fois, jusqu’à ce qu’il reconnaisse une instruction complète, puis exécuter l’action correspondante.

Ainsi, la séquence d’octets « 48 8B 35 07 ED 01 00 » signifiera pour lui « mov rsi, qword [ds:0x100020438] », ou encore « lis en mémoire, à l’adresse 0x100020438, un mot de 64 bits, et stocke cette valeur dans le registre rsi ».

Une fois que chaque instruction a été décodée, Hopper procède à une analyse plus poussée de l’application. Il va pour cela « suivre » le code, et essayer de déterminer tous les chemins d’exécution possibles.

Il recrée donc une partie de la structure logique de l’application, et permet de séparer les différentes instructions en méthodes, elles même découpées en blocs plus petits (appelés Basic Blocks). Il tente aussi de séparer le code des données (comme les chaînes de caractères qui sont affichées lors de l’exécution du programme, par exemple).

Grâce à cette analyse, Hopper est capable d’afficher une représentation plus graphique de l’exécution de l’application.

La décompilation est l’étape suivante : l’idée est d’essayer de retrouver ce à quoi pouvait ressembler le code « original », celui que le développeur a initialement écrit, et qui a été compilé.

En effet, aucun développeur n’écrit directement du code assembleur. Au lieu de cela, il utilise un langage de haut niveau, comme l’Objective-C par exemple, et utilise un compilateur, comme Clang, qui est livré avec Xcode, pour transformer ce langage incompréhensible pour le microprocesseur en assembleur.

Malheureusement, au passage, une grande quantité d’information concernant la structure logique de l’application est perdue, essentiellement pendant la phase d’optimisation, où le code est trituré par le compilateur pour faire en sorte de s’exécuter le plus rapidement possible, ce qui rend le travail de décompilation très compliqué.

Malgré tout, Hopper dispose en interne de nombreuses heuristiques, qui permettent, dans de très nombreux cas, de retrouver cette information. En gros, Hopper fait de manière automatique ce qu’un ingénieur en rétro-ingénierie aurait fait à la main. Pour résumer, Hopper contient des années d’expertise humaine en reverse engineering…

À l’issue d’une décompilation de méthode, Hopper est capable de transformer cette séquence d’instructions :

En ceci :

C’est ce que j’appelle du « Pseudo Code », dans le sens où il n’est pas possible de le donner directement à un compilateur, mais il y a de bonnes chances pour que le code qu’avait écrit le développeur soit très proche de celui-ci.

Notez bien que ce que vous voyez sur cette dernière capture résulte d’un processus entièrement automatisé : je n’ai fait que glisser l’application TextEdit sur la fenêtre de Hopper, et j’ai ensuite cliqué sur le bouton « Pseudo Code ».

À l'inverse, qu'est-ce que ne permet pas de faire Hopper et pour quelles raisons ?

Hopper n’est malheureusement pas magique ; il ne peut pas, à coup sûr, décompiler n’importe quelle méthode de manière lisible. Il arrive que des parties d’applications aient été écrites à la main, directement en assembleur, ou que le compilateur ait optimisé de manière agressive certaines parties. Dans ce cas-là, la version décompilée par Hopper est à peine plus lisible que la version désassemblée.

À qui s'adresse Hopper ?

Hopper s’adressait au départ aux chercheurs en sécurité. Je l’ai initialement développé lorsque je travaillais sur la mise au point d’un système de DRM, pour une application que je développais à l’époque.

Petit à petit, je me suis rendu compte que Hopper était utilisé pour d’autres tâches que je n’avais pas imaginées, et j’ai commencé à être contacté par toutes sortes de développeurs.

Sous OS X, il existe beaucoup de « tweaks », qui modifient les fonctionnalités du système, ou les étendent, comme TotalFinder par exemple, dont une des nombreuses fonctions est d’ajouter un système d’onglets au Finder, ou encore Flavours qui permet de personnaliser l’aspect d’OS X. Pour réaliser ces logiciels, il a fallu étudier le fonctionnement interne du Finder. Ce travail a été réalisé grâce à Hopper, et il y a même des gens chez Apple qui l'utilisent !

Est-ce qu'il y a des usages qui sont faits de ton logiciel qui te gênent ? Les chercheurs qui ont découvert les failles rootpipe et Thunderstrike ont prévenu Apple avant de rendre publique leur découverte, mais tout le monde ne partage pas la même éthique. Je pense aux black hats (des hackers malveillants) qui peuvent se servir de Hopper pour débusquer des failles qu'ils vont exploiter avec de « mauvaises » intentions. Autrement dit, est-ce que tu considères que tu as une certaine responsabilité par rapport à ce qui est réalisé avec ton logiciel ?

Il y a quelque temps de ça, j’ai lu sur un forum une discussion qui parlait de Hopper et de son intérêt pour cracker des logiciels. C’est effectivement un outil qui peut être redoutable pour ce type d’activité, et j’avoue que ça me gêne toujours un peu…

Il y a même des gens qui pensent que je l’ai écrit dans ce but ! C’est d’autant plus terrible qu’en tant que développeur, j’ai bien conscience du mal que peut faire le piratage à une petite boîte, et je n’ai d’ailleurs pas une seule application piratée en ma possession…

Malgré tout, je pense que dans la majorité des cas, Hopper aide à renforcer les défenses, plutôt qu’à les détruire.

Comment t'est venue l'idée de créer Hopper ?

Je suis un développeur de la vieille époque. :-) J’ai commencé à programmer sur Oric, il y a très longtemps, et à l’époque, l’assembleur était un des seuls choix si l’on souhaitait écrire des choses performantes. Je suis ensuite passé sur Amiga, où là encore, l’assembleur était la seule option crédible. On peut donc dire que lire et écrire de l’assembleur est une seconde nature pour moi. :-)

Pendant ma thèse de cryptographie, j’ai travaillé sur une preuve de concept dont le but était de mettre en avant la facilité avec laquelle il était possible à un attaquant de réduire l’entropie des générateurs pseudo-aléatoires embarqués dans les systèmes d’exploitation, dans le but d’affaiblir l’efficacité des systèmes de chiffrement, et ce, à l’insu de l’utilisateur.

Pour ce faire, j’ai désassemblé les bibliothèques cryptographiques de Windows XP. J’utilisais alors le logiciel IDA, développé par la société HexRays, et dont l’université avait une licence. Malheureusement, bien qu’il soit un logiciel incontournable, IDA souffre de deux défauts majeurs : premièrement, il coûte très, très cher (la version complète coûte plus de 3 500 $ !), mais surtout, il n’est pas du tout adapté à OS X.

Même si la situation s’est améliorée depuis leur passage à Qt, IDA reste un logiciel développé sous Windows, pour Windows, et porté tel quel sous OS X. Il souffre de nombreux défauts ; par exemple, beaucoup de raccourcis clavier ne fonctionnent tout simplement pas sur Mac, à cause de touches n’existant pas sur les claviers d’un Mac, ce qui est assez rédhibitoire pour un logiciel à ce prix…

Alors je me suis mis à écrire ma propre version d’IDA… puis, petit à petit, le logiciel a pris de l’ampleur, jusqu’à devenir une alternative crédible. Aujourd’hui, Hopper se paie même le luxe de disposer de fonctions qu’IDA n’a toujours pas, comme la visualisation graphique de l’entropie de l’exécutable, l’annuler / rétablir, etc. Aujourd’hui, la plus grande force de Hopper est qu’il a été développé sur OS X, pour OS X, et les utilisateurs sentent tout de suite la différence !

Comment on crée, techniquement, un logiciel chargé de désassembler d'autres logiciels ? Est-ce que tu t'appuies sur des technologies existantes ?

Concernant la transformation d’une séquence d’octets en une instruction, je m’appuie sur des bibliothèques libres comme Capstone, dont je fais partie des contributeurs. Mais il faut garder à l’esprit qu’il ne s’agit là que de la tâche la plus simple; la plus-value de Hopper réside dans son analyse automatisée, et sa capacité à reconstruire de la structure à partir des instructions décodées, et pour cela, tout a été écrit à la main. Il s’agit d’une quantité ahurissante d’heuristiques, construites minutieusement, année après année…

Comment gères-tu le développement ?

Au départ, je développais Hopper sur mon temps libre, essentiellement la nuit… Mais étant père de famille, et travaillant toute la journée (chez Arobas Music, où je participais au développement de Guitar Pro pour OS X et iOS, bien loin de l'univers de la sécurité), j’ai dû me résoudre à faire un choix.

Fin 2012, j’ai été contacté par Neil Ticktin et Edward Marczak pour présenter Hopper lors des conférences MacTech à Los Angeles. Ça a été pour moi un déclic : le logiciel intéressait bien plus de monde que je le pensais… je devais tenter ma chance. Alors, j'ai quitté mon emploi pour monter une EURL, Cryptic Apps (comprendront les plus mélomanes d’entre vous), entièrement consacrée à son développement.

Malgré tout, développer seul un logiciel de cette ampleur reste assez compliqué. Le volume de code est devenu très important, et j’ai parfois un peu de mal à trouver l’énergie de continuer. Mais dans le même temps, je suis « seul maître à bord » et j’ai donc une vision claire de l’architecture de l’application, ce qui me permet d’être efficace.

Je pense avoir fait le bon choix, et je ne regrette pas d’avoir tenté l’aventure en tant que développeur indépendant sur Mac. Même si l’aspect administratif de la gestion d'une EURL reste parfois… compliqué. :-)

Est-ce que tu as envisagé employer une personne pour t'épauler ?

Ce n’est pas exclu… pour l’instant, le principal problème reste de sécuriser financièrement ma société. Je m’adresse à un marché de niche, et par conséquent, je n’en vends pas des millions. Malgré tout, les choses se goupillent bien, et quand j’estimerai que la situation est parfaitement saine, j’envisagerai certainement l’embauche.

Est-ce que les utilisateurs de Hopper aiguillent en partie son développement ? Est-ce que tu reçois par exemple des demandes de nouvelles fonctions ou d'améliorations ?

Je suis en contact avec plusieurs personnes de la communauté sécurité sur OS X, mais paradoxalement, assez peu de Français… D’ailleurs, je serai à la conférence SSTIC à Rennes en juin.

Beaucoup de ces personnes utilisent Hopper au quotidien et je reçois assez régulièrement des suggestions de fonctionnalités qu’ils aimeraient voir ajoutées à Hopper. J’aime beaucoup ces retours. Ils m’ont permis de transformer Hopper en une solution complète et performante. Ainsi, quand l’idée proposée est en accord avec ma vision du produit, je l’implémente.

Quel regard portes-tu sur la sécurité du Mac aujourd'hui, toi qui baignes dans ce milieu depuis des années ?

J’avoue que la politique d’Apple concernant la sécurité de ses OS m’a toujours un peu fait sourire. :-)

L’argument du système fiable et sans virus a toujours été mis en avant, alors qu’il aurait été plus honnête de dire qu’OS X ne compte presque pas de virus… faute d’intérêt des concepteurs pour la plateforme. Pourquoi investir un tel effort pour, au final, ne toucher qu’un faible pourcentage de la population ?

Notez bien que cet argument est aussi valable pour les autres ; parlez-en donc à un utilisateur de Linux (que je suis aussi) et dans la majorité des cas, il vous rira au nez, en vous disant que son système est sûr. C’est une erreur, il existe aussi des virus sous Linux. Il y a juste peu de monde pour en développer, toujours pour les mêmes raisons…

Parallèlement à la montée en puissance d’iOS, j’ai vu OS X devenir un système à la mode. Alors qu’il y a une dizaine d’années, j’étais le seul dans mon entourage familial à avoir entendu parler du Mac, aujourd’hui, je compte sur les doigts de la main le nombre de personnes restées sous Windows. La plupart des personnes que je connais ont un iPhone et ont fini par troquer leur PC pour un MacBook.

Et petit à petit, j’ai vu mon OS adopter des mesures de sécurité « drastiques », comme le sandboxing. Car forcément, plus il y a de monde, plus la menace virus / trojan / etc. devient grande, et plus Apple a été contrainte à corriger le tir « en urgence ».

Malgré tout, j’ai aussi récemment été en contact avec des gens de chez Apple qui travaillent sur la sécurité d’OS X et iOS. Et le moins que l’on puisse dire, c’est qu’il s’agit de gens très compétents, et qu’ils sauront répondre aux différentes menaces…

Photo de une John Mitchell CC BY