Desnos Anthony

L'analyse des applications Android prend de plus en plus de place dans la vie d'un analyste, en raison de l'explosion de cette plateforme, du niveau des utilisateurs finaux et du nombre croissant d'applications disponibles sur le Google Play. Il est donc nécessaire de bien connaître nos outils et leurs limites possibles. Dans la suite de cet article, nous allons brièvement expliquer le format DEX où se situe le code exécutable d'une application, puis décrire les dernières techniques qui permettent de contourner les outils open source d'analyse d'application Android.

L'Android Market compte à ce jour plus de 600.000 applications et plus de 20 milliards de téléchargements, et ces résultats ne proviennent que du market « officiel ». Les applications sont disponibles en téléchargement de deux manières différentes : payantes ou gratuites. Il est donc évident qu'un tel marché va attirer des gens malintentionnés, par exemple en proposant des applications crackées. Mais de par la nature des applications Android, il est assez facile de les modifier et de les redistribuer, ce qui entraîne de nouveaux types d'actions malveillantes... ce qui pose quelques problèmes…

Les malwares sur Android ont subi une forte croissance cette année, principalement due à l'explosion de cette plateforme et donc aux gains que l'on peut espérer générer. Il est simple (et encore plus avec un coup de pouce de l'utilisateur qui ne lira pas les permissions déclarées) pour une application malveillante d'envoyer un SMS, de récupérer la liste de vos contacts, ou votre position géographique, mais comment le faire de la manière la plus discrète ?On peut donc se demander quelle a été l'évolution de ces malwares et quelles sont les techniques que ces malwares utilisent pour échapper le plus possible à une détection d'antivirus...

Les virus sont comme toutes choses vivantes, ils évoluent, ils disparaissent, mais ils apparaissent également. À travers cet article, vous allez découvrir comment faire un virus (« virus don't harm, ignorance does », herm1t), même si celui-ci n'aura aucune charge finale dangereuse (et donc il sera plus un proof of concept). Nous partirons d'une idée théorique sur une nouvelle forme de virus, les virus K-aires, et nous verrons le cheminement pour son implémentation, du chargement du virus en passant par la gestion des clés de chiffrement, jusqu'à l'exécution finale.

Dans le numéro précédent [1], nous avons détaillé le code de BluePill et montré qu'il y avait plusieurs incohérences au niveau des arguments avancés par les auteurs. C'est-à-dire qu'il ne possédait en aucun cas les caractéristiques classiques d'un rootkit. Nous allons voir dans cet article comment finalement il est possible d'avoir une détection simple de ces rootkits HVM, et ainsi mettre fin à ce buzz qui n'a eu aucun sens.

Les différents codes malveillants suivent, voire devancent, les innovations technologiques que connaît le monde informatique, mois après mois. Ainsi, au fil des évolutions techniques, les rootkits ont pu migrer facilement du niveau utilisateur vers le niveau noyau, atteignant ainsi le Saint Graal : avoir tous pouvoirs sur la machine. Ces dernières années ont vu également l'émergence de la virtualisation, en particulier matérielle, permettant de faciliter le déploiement de solutions, mais également de renforcer la sécurité. Mais, si donner les moyens au processeur d'accéder très facilement à la virtualisation a pu accroître de façon significative la rapidité des logiciels de virtualisation, cela a, en même temps, conduit à fournir de nouvelles solutions aux concepteurs de virus.