Interview : Hopper, le logiciel qui renverse la sécurité du Mac

Stéphane Moussie |

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.

L’application TextEdit dans un éditeur hexadécimal

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 ».

La même application dans Hopper - cliquer pour agrandir

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.

Le graphe d’une méthode (CFG) - cliquer pour afficher la suite

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 :

Cliquer pour agrandir

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 !

Hopper - cliquer pour agrandir

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.

IDA sur Mac

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.

Écran de démarrage d'un Mac compromis par Thunderstrike, une faille qui permet à un périphérique Thunderbolt malveillant de modifier l'EFI (le programme de démarrage) et qui ouvre la voie à d'autres menaces.

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

avatar x6tance | 

Très bon article

avatar Fahrenheit | 

Excellent article !

Mais je me suis toujours demandé pourquoi continuer à fabriquer des virus sur Windows dont les utilisateurs se blindent de plus en plus au lieu de faire un virus sur OSX qui marchera sur 100% des machines ? On parle de millions d'utilisateurs quand même !

avatar oomu | 

"Mais je me suis toujours demandé pourquoi continuer à fabriquer des virus sur Windows dont les utilisateurs se blindent de plus en plus"

parce que c'est faux: les utilisateurs ne se blindent pas.

Nombreux sont ceux qui ont un "antivirus" ou un "antispyware" mais qui n'est pas fonctionnel (pas payé, plus d'abonnements, pas de base de virus à jour, etc) ou est lui même un adware (harcèle l'utilisateur de pub)

Les constructeurs enseignent de très mauvaises habitudes aux nouveaux acheteurs de PC.

de fait, faire exécuter un virus par un utilisateur windows n'est pas très cher: c'est RENTABLE.

" au lieu de faire un virus sur OSX qui marchera sur 100% des machines ? On parle de millions d'utilisateurs quand même !"

parce que cela est faux aussi.

Le PC / windows XP (et maintenant 7/8) est beaucoup plus homogène qu'on le pense. Pas besoin d'écrire du CUDA ou de viser une carte son haut de gamme qui n'existe pratiquement plus de toute façon : on a une base matérielle très unifiée et le windows maintient une compatibilité délirante : le virus peut être écrit pour un nombre gigantesques de machines.

Os X est + cher pour faire exécuter du code : l'interface est + claire, les fonctionnalités d'exécutions de code + rare que sous windows.

Mais Apple sera toujours + drastique: les trojans et adware sont développés pour Mac et les sites web de + en + menteurs et truqués pour encourager les gens sur mac à installer N'IMPORTE QUOI.

ET c'est un gros soucis, ça va encourager apple à imposer l'App Store sur OS X. C'est un enjeu de société (politique) qui est en train de se préparer.

avatar bugman | 

Effectivement terriblement efficace pour faire tomber et comprendre quelques protections logiciel. Si ça peut aider Vincent à dormir, cela ne m'empêche pas de payer mes licences logiciels. Excellent produit.

avatar oomu | 

à l'inverse il permet aux auteurs de logiciels de trouver leurs failles et les corriger, donc.

avatar bugman | 

Aussi. Ce n'est pas incompatible. ;)

avatar @MathieuChabod | 

Énorme respect pour ce développeur. Bel article.

avatar garnierobin | 

Magnifique !

avatar Xap | 

Merci pour cet article très intéressant!

avatar jju17 | 

Merci énormément pour cet article très instructif pour moi!

avatar Zoupinou | 

Cryptic en référence aux Residents je suppose. Une bonne idée !

avatar bsr43 | 

@Zoupinou: tout à fait :)

avatar RoomLight | 

Ça peut permettre de retrouver des secrets de fabrication d'un logiciel ? Genre un algorithme secret de Photoshop ?

avatar RyDroid | 

Oui.
Mais ce n'est clairement pas le premier logiciel du genre. Par exemple, GDB, qui existe depuis longtemps, permet d'analyser en profondeur un programme même sans annotations de débogage. Il y aussi d'autres logiciels graphiques comme radare. http://linuxfr.org/news/sortie-de-radare2-0-9-6
De plus, on peut obfusquer du code pour le rendre moins lisible avec des opérations inutiles, des opérations inutilement plus compliqués et bien d'autres mécanismes plus sophistiqués. Il me semble que Microsoft utilise assez fortement l'obfuscation sur Skype.

avatar bsr43 | 

@RyDroid :
Le logiciel GDB n'est pas utilisé pour la même chose, ce n'est pas la même "classe de logiciel" : on utilise GDB pour debugger, ou faire de l'analyse dynamique, pas pour de l'analyse statique, ou alors, c'est qu'on aime se faire du mal :). Quant à l'obfuscation, en effet, beaucoup de développeurs font ça pour compliquer l'analyse statique, moi le premier :) Mais ça n'empêche tout de même pas l'analyse…

avatar Switcher | 

J'apprends que la rétro-ingénierie est légale... Moi qui ait toujours cru que ce n'était pas le cas.

Merci pour l'article, on se couche souvent plus cultivé avec MacGé... :)

avatar bsr43 | 

La rétro-ingénierie est légale, en France, à la condition qu'elle soit faite pour des raisons de recherche en sécurité, ou à des fins d'interopérabilité entre logiciels.

Par exemple, il est tout à fait légal de désassembler Word pour comprendre le format des fichiers DOC, pour ensuite créer un logiciel capable de lire ces fichiers. Il est même légal d'étudier la protection contre la copie d'un logiciel, ou le fonctionnement d'un système de DRM (il y a quand même des subtilités légales dans ce cas précis).

Par contre, dans tous les cas, il interdit de communiquer publiquement le résultat de son travail…

avatar Switcher | 

Un grand merci pour cet éclaircissement. :)

avatar misstique | 

Il ne manque plus que son EURL soit rachetée par Apple et son gérant embauché par Cupertino ! ^^

avatar Ginger bread | 

@misstique :
Ca leur ferait pas de mal pr boucher les failles

avatar imnothereee | 

Sûrement très intéressant mais pour un néophyte : c'est un peu du charabia

avatar Xalio | 

Super! Merci.
Je connaissais Hopper pour m'y être intéressé dans le cadre du boulot. Ce logiciel avait bel et bien l'air d'une référence dans son domaine sur OS X.

avatar san_ | 

Passionnant, merci pour cette interview

avatar ZANTAR2054 | 

merci, article passionnant

avatar Abudah (non vérifié) | 

Bravo, cet article est au top ! :-)

Pages

CONNEXION UTILISATEUR