Et voilà, le SSTIC 2012 c'est fini depuis hier soir. Cette année nous avons eu droit à quelques conférences mémorables et à plusieurs évènements retentissants à tout niveau de l'actualité. Ci-dessous ce que je retiendrait :

Jour 1

20 years of Pax : Pour débuter le SSTIC on attaque sur les chapeaux de roues avec une présentation en anglais par un speaker de prestige sur un sujet d'un haut niveau technique. Globalement sympa mais, perso, je dirai "sans plus" à caude de l'équation suivante : (speaker qui ne parle pas dans le micro + place au fond de l'amphi) + anglais + contenu très technique que je ne maitrise pas = pas tout suivi :-/

SSL/TLS: état des lieux et recommandations par Olivier Levillain : Conf sympathique (sans plus) qui fait un état des lieux sur SSL/TLS (comment c'est déployé, quelles options existent, quelles sont les différentes versions, etc.). Pas grand chose à apprendre mais une jolie remise à niveau quand même. Il parait que le papier (le plus gros de cette année avec plus de 40 pages) contient beaucoup plus d'informations sur les attaques possibles sur SSL/TLS (volet assez absent de la présentation). A relire à tête reposée donc :)

Netzob : un outil pour la rétro-conception de protocoles de communication par Frédéric Guihery, Georges Bossert, et Guillaume Hiet (absent à la présentation :( ) : La conf débute par le constat qu'à l'heure actuelle l'ingénierie inverse de protocoles de communication est pénible et manuelle, puis elle enchaine sur la présentation de l'outil "netzob" qui est censé faciliter la démarche. L'outil a l'air assez stable et donne bien envie d'être testé si l'occasion se présente. Pour la forme de la conf : Les slides étaient amusant mais la conf manquait peut-être un peu de rythme et en tout cas, 3 jours plus tard, elle me laisse un peu le même sentiment que la conf précédente : sympa (mais sans plus).

Sécurité de RDP par Arnaud EBALARD, Aurélien Bordes et Raphaël Rigo : J'attendais cette conférence qui ne m'a pas (trop) déçu. Comme pour SSL/TLS c'était une bonne remise à niveau sur l'état de l'art RDP. Il y avait un peu plus d'informations sur les attaques (ce qui n'est pas plus mal), par contre le symptome ANSSI était bien présent : les outils présentés lors de la conf ne sont pas disponibles.

WinRT par Kévin Szkudlapski et Sébastien Renaud : Les speakers ont présenté les fonctionnalité du runtime "WinRT" présent dans windows 8 et qui est à la base des applications compatibles avec la nouvelle interface graphique Metro. Intéressant si on veut développer des applications pour "Metro" mais à part ça...

L'information, capital immatériel de l'entreprise par garance mathias : c'était, là encore, une conférence que j'attendais de pied ferme (tout en conservant une petite crainte) et le verdict est sans appel : j'aurai préféré être ailleurs qu'à cette conférence. Le message de fond (celui que j'ai retenu en tout cas) n'a rien de nouveau et pourrait se résumer ainsi : "le droit français a des décennies de retard sur l'évolution technologique du monde et il n'y a actuellement pas de texte pour traiter proprement les problématiques liés à l'information, donc en cas de litige c'est le magistrat qui décide". Mais le plus ch*ant n'est pas tant qu'on n'avait pas grand chose à retirer de cette conférence, c'était plutôt la forme : élocution lente, pas de référence pratique, et un déploiement outrancier de techniques rhétoriques grosses comme des maisons (on a eu droit à une dizaine de "vous le savez bien", "vous l'avez compris", "vous en êtes bien conscient", et à une vingtaines de questions rhétoriques bidons dont le seul but semblait être de ralentir la présentation plutôt que d'introduire le paragraphe¹ suivant). Bref : pas aimé.

Audit des permissions en environnement Active Directory par Géraud De Drouas et Pierre Capillon : Plusieurs idées très intéressantes dans cette présentation qui se penche sur l'audit offline des permissions qu'ont les objets d'un Active Directory afin de détecter une éventuelle compromission. On a droit à plusieurs exemples concret d'audits des permissions des utilisateurs dans un AD de taille "professionnelle", c'est sympa et pleins d'astuces. Petit bémol : passé la première moitié de la conférence les speakers ne présentaient quasiment plus que l'interface graphique de leur outil d'audit mais, syndrome ANSSI oblige, l'outil n'est pas disponible :-/

Windows 8 et la sécurité : un aperçu des nouvelles fonctionnalités par Bernard Ourghanlian : Présentation commerciale des fonctionnalités de sécurité de Windows 8. Pour tenter de résumer à l'arrache : boot sécurisé, TPM à gogo, et "carte à puce virtuelle" (celle là fait bien réver...). Ce qu'il faut retenir c'est surtout deux réponses aux questions de fin de conférences : "oui, un ordinateur certifié compatible Windows 8 pourra tout de même booter sur un autre OS malgré le boot sécurisé de bout en bout", et "faire tourner énormément de code pré-boot (anti-malware, longue chaine de boot sécurisé, etc.) dans un contexte ultra-privilégié (ce qui pourrait sembler à l'opposé de toutes les bonnes pratiques en terme de sécurité) ne pose pas de problème à Microsoft parce qu'il peuvent/vont prouver ce code mathématiquement².

10 ans de SSTIC : très agréable présentation revenant sur l'histoire du SSTIC, sur les anecdotes les plus marquantes, les speakers les plus présents, etc.

Jour 2

Compromission d'une application bancaire JavaCard par attaque logicielle par Julien Lancia : Retour du speaker un an plus tard sur le même domaine mais avec une présentation bien différente. L'auteur explique cette année comment, en ayant les clefs permettant d'uploader du Java sur une Javacard bancaire, il est parvenu à totalement compromettre l'application bancaire présente de base. Très jolie présentation, même si les conditions de réalisation des attaques les rendent actuellement hautement délicate à mettre en oeuvre IRL. Petite remarque perso : ça me fait plaisir de voir, en 2012, que le monde Java se prend des vulnérabilité du type "j'accède à la mémoire au delà des limites normale de mon tableau et je l'écrase" et PAN dans tes dents langage pourri soit disant ultra-secure et portable :p.

IronHide: Plate-forme d'attaques par entrées-sorties par Fernand LONE SANG, Vincent Nicomette, et Yves Deswarte : Encore des revenants pour cette conférence. Ils présentent ici une plateforme matérielle permettant de lire et envoyer des trames PCI Express arbitraires (keylogger à la clef par exemple). Quelques vidéos de démonstrations d'attaques réelles. On est dans de l'étude de laboratoire, mais c'est sympa quand même, les speakers sont agréables à écouter, et les perspectives sont vastes :)

La qualité d'hébergeur en 2012 par Romain Beeckman : Comme quoi on pouvait faire une conférence orienté juridique au SSTIC 2012 sans être chiant. Le directeur juridique d'OVH explique clairement la notion "d'hébergeur" dans la Loi actuelle ainsi que les évolutions passées et potentiellement à venir de cette notion. On a des anecdotes concrètes démontrant bien les différents cas (hébergement mutualisé, dédibox, etc.) et un rythme normal sans artifice oratoire ou tour de manche. Bref : conf très agréable où aucune questions n'a été esquivée, que celà soit sur Megaupload ou sur Wikileaks.

Résultats du challenge par Axel Tillequin, Fabien Perigaud, et Florent Marceau (concepteurs du challenge) puis Julien Perrot (vainqueur du classement qualité) : Enorme claque. Forcément j'avais discutté du challenge avec quelques amis qui s'étaient penchés dessus avant cette conf et je savais donc un peu comment le challenge démarrait (réparation d'une partition ext, reverse d'un binaire elf/MIPS et analyse d'un algo dérivé de DES contenu dedans). Ce niveau d'avancement du challenge (que les gens avec qui j'avais discutté avaient mis entre une semaine et un mois à atteindre) a été dépassé en "un jour, un jour et demi" par le vainqueur (le reste lui ayant pris plus de deux semaines :D ). Je ne vais pas rentrer dans les détails que vous trouverez bien mieux expliqués sur le wiki du SSTIC mais, en gros, ça se termine par le flash du firmware d'une webcam USB pour faire tourner une VM sur son chipset CY16 afin de bruteforcer des softs embarqués dans l'efl/MIPS ce qui permet, finalement, de récupérer des bouts de clefs de chiffrement :-D Bref, pour citer Wayne's World, voilà à quoi quoi ça m'a fait penser d'être dans le même amphi que ces 4 personnes : "On mérite pas ! On est tout p'tits ! On est à chier !"

Présentation courte 1 Anthony Desnos présente deux outils (Elsim et Androguard) qui lui permettent, par mesure de similarité, d'identifier des reprises de code entre applications Android. Entre autres choses celà lui permet d'identifier les librairies de pub qu'on retrouve dans les jeux android. C'est amusant, ça semble efficace, et ça fait bien mal en mettant sous les yeux qu'on télécharge en très grandes quantité de la pub quand on télécharge certains jeux (de mémoire : plus d'un tiers du code d'Angry Bird c'est de la librairie publicitaire). Présentation vraiment agréable à suivre mais je soupçonne quand même l'auteur de nous avoir crapulé³ sur des petits détails. En effet les résultats bruts de ses mesures de similarité ressemblent à ça : "Dans tel jeu on retrouve 80% du code de cette librairie de pub, 20% de telle autre librairie de pub, et 90% de cette troisième" or l'auteur nous présente ensuite, sans transition, le découpage de jeux en pourcentage de code "propre", de code provenant de librairies de pub, et de code provenant d'autres librairies. Le "crapulage" c'est que ces dernières mesures ne peuvent être que des estimations issues de décisions arbitraires type "on retrouve 79% du code de cette librairie de pub, donc on va dire qu'elle est présente et pèse environ autant que si je la télécharge seule; on retrouve 33% du code de cette autre librairie de pub, on va donc supposer qu'elle n'est pas présente", du coup le découpage présenté au final n'est qu'issu d'une estimation dont la recette n'a pas été expliquée. M'enfin je chipote ^_^

Présentation courte 2 Davide Canali présente un projet de honeypot web grande échelle. Ils ont achetés 100 noms de domaine, ont créé 5 sous-domaine pour chacun, et mis à disposition à ces 500 urls plusieurs CMS vulnérables et webshells, ensuite ils monitorent le comportement des attaques :) Ils ont actuellement générés plus de 10Go de données, mais leur analyse est en cours. Bon teaser donc, mais rien à se mettre sous la dent tant que l'analyse n'a pas été faite :-(

Présentation courte 3 Pierre Karpman parle de durcissement de programmes C avec SIDAN. Perso j'ai eu un peu de mal à suivre la présentation et à comprendre ce que voulait faire l'auteur...de ce que j'ai suivi il instrumente du code C pour rajouter des vérification d'invariant entre un appel de fonction et son retour (pour détecter d'éventuelles attaques s'étant déroulée dans l'appel et ayant modifié des bouts de mémoire imprévu); m'enfin ça ne m'a pas plus convaincu que ça. J'espère qu'il y aura un petit papier publié pour que je relise tranquillement ce qu'il voulait faire.

Contrôle d’accès mandataire pour Windows 7 par Christian Toinard, Damien Gros et Jérémy Briffaut : En résumé des 20~30 premières minutes "on tente de porter SELinux sur Windows 7 (mais on n'y arrive pas totalement)". Devant une telle déviance j'ai décroché ^_^

Expert judiciaire en informatique par Zythom : S'étant fait pwner le matin même son blog, et son compte twitter ( + on soupçonnait à ce moment là que le compte mail y était passé aussi) Zythom fait tout de même sa présentation, chapeau ! D'ailleurs il n'y avait pas à s'y tromper : c'est avant qu'il ne commence sa conférence qu'est parti le premier tonnerre d'applaudissement unanime de la salle. Pour le contenu on a eu droit à une petite explication de son piratage puis à la conférence telle qu'elle avait été prévue initialement. Ca parle des sujets qu'on retrouve sur le blog, mais en live : Qu'est ce qu'un expert judiciaire, comment on le devient, comment on le reste, quelques exemples de missions et des contextes dans lesquels elles se déroulent. On a également eu le droit à une liste des outils qu'il utilise, le tout ponctué de nombreux traits d'humour tout au long de la conf dispensée avec beaucoup d'humilité. Bref : conférence très agréable, et plus qu'impressionante quand on considère le contexte ! Monsieur Zythom vous avez tout mon respect⁴

Forensics iOS par Jean Sigwald et Jean-Baptiste Bédrune : On commence par un panorama complet des méthodes d'acquisition d'un dump mémoire d'un iOS avec leurs avantages et inconvénients respectifs (nécessité du code pin ou non, modification de la mémoire lors du dump ou non, etc.) puis on enchaine avec l'utilisation du chiffrement omniprésent dans iOS. Impression d'un prophane : c'est touffu et ça chiffre de partout mais les bougres arrivent quand même à déchiffrer tout ce qu'ils veulent étape par étape. Présentation d'un haut niveau technique, sur un sujet complexe, avec une démo, et réalisée par des spécialites du domaine, mais j'ai trouvé que c'était quand même un poil difficile à digérer.

Rump session : Super passage que ces rumps sessions ! On a eu du très très très bon mais également le petit plaisir sadique d'applaudir un présentateur plus de 30s avant la fin théorique de son temps⁵. Dans les mémorables on a Biondi qui, lui, a explosé son compteur de temps en présentant les pipes dans scappy et qui s'offre un magnifique "c'est dans scappy depuis un an" lorsqu'un membre de l'assistance lui demande si c'est disponible :D

Jour 3

Source Address Validation Improvements (SAVI) par Jean-Michel Combes et Maryline Laurent : je l'ai raté, social event oblige ^_^

Utilisation malveillante des suivis de connexions par Eric Leblond : Très bonne présentation de l'implémentation du suivi de connexions dans netfilter (permettant de gérer "proprement" les protocoles ouvrant dynamiquement d'autres canaux de communication, type FTP, IRC, ou SIP). Et le plat de résistance : un outil qui permet d'abuser ces fonctions pour ouvrir des trous dans les implémentations vulnérables (sous réserve que vous partagiez sur le même réseau ethernet que le FW cible, que le FW cible soit vulnérable, et que le serveur ciblé propose légitimement un protocol adéquat via le FW). Je reste impressionné que de tels bugs existent encore en 2012, mais c'est comme ça :) La présentation était en tout cas très bien, et l'auteur se paie le luxe de commiter son outil en live pour anticiper la question "est-ce-que le code est disponible ?", joli show :) !

Influence des bonnes pratiques sur les incidents BGP par Francois Contat, Guillaume Valadon et Sarah Nataf : Présentation à trois voix très bien menées pour ceux qui, comme moi, n'y connaissent rien en BGP. On nous explique ce que c'est, comment c'est utilisé pour soutenir internet entre les "grand acteurs de routage" possédant leur AS, quelles sont les bonnes pratiques, et comment ces bonnes pratiques répondent (ou auraient pu répondre) à des incidents (exemples concrets et réels à l'appui). Décidément cette troisième journée commence par deux très bonnes présentations, c'est bien parti pour être la meilleure journée du SSTIC :) !

Présentation courte 1 Clément Lecigne présente netusse. C'est un outil de fuzzing des implémentation socket ayant pour but de débusquer du 0day kernel. Le tool a commencé il y a plusieurs années lors d'un Google Summer of Code puis Clément l'a poursuivi. Après avoir présenté l'outil on passe à la dissection d'un bug kernel découvert sur FreeBSD puis sur l'impressionante explication du code d'exploitation. C'est d'un très haut niveau pourtant le speaker donne l'impression d'être aussi à l'aise que s'il était en train de faire une rump expliquant la recette de la pate à crèpe o_O ! En espérant le revoir en présentation longue l'an prochain :) !

Présentation courte 2 Étienne Millon nous parle de sa passion : l'analyse statique de code. Présentation vraiment sympa et qui s'enchainait bien avec la précédente. Clairement il y a des limitations à son outil qui demande encore pas mal d'aide manuelle, mais ça fonctionne et ça trouve du bug.

Présentation courte 3 Ronan Mouchoux nous parle de détection de nom de domaine "bizarre". Le concept de base c'est qu'un botnet doit contacter son C&C et que, souvent, les noms de domaine utilisés par les botnet sautent aux yeux des humains comme n'étant "pas normal" ("asbguocezbgiudzeujopnryeuocnbyo.ru", ce n'est pas "normal" :-D). Le principe de détection s'appuie sur 4 moteurs distincts (dont seulement 2 sont codés à l'heure actuelle) afin d'augmenter le taux de détection sans monter le taux de faux positifs grace à la diversification fonctionnelle⁶. Cette présentation ne m'a malheureusement pas convaincu; d'une part parce que les 4 outils présentés avaient l'air "relativement" simples mais que seulement deux avaient été codés (du coup on se demande un peu s'il n'a pas commencé ses recherches la veille ?), et d'autre part parce que le concept même est potentiellement bancal (l'auteur reconnait lui-même ne pas être capable de détecter des dns type "concaténation de plusieurs vrais mots" comme ceux qui sont utilisés par les tout derniers botnets, et qu'en plus il remonte des faux positifs avec les sous-domaines légitimes mais funkys type "grosrandom.updates.sitelegitime.com"). Bref pour moi l'idée est très intéressante mais c'est un truc à coder en une semaine grand max et dont l'utilité reste conditionnée par la confidentialité des méthodes de notation utilisées⁷.

Successes (and limitations) of (static) binary analysis par Halvar Flake : Du lourd ! Un grand monsieur qui nous explique, en anglais, les obstacles qui restent à surmonter dans le domaine de l'analyse statique de code. Les exemples sont clairements expliqués et s'appuient sur de vrais vulnérabilités. Bref la conférence est très bonnes et ça suffit ça tenir éveillé malgré le coup de barre post-social-event :)

Miasm: Framework de reverse engineering par Fabrice Desclaux : J'attendais impatiemment cette conférence et cette fois je n'ai pas été déçu ! Je pèse mes mots en disant que cette conférence était exceptionnelle. L'auteur était à 200% mais restait compréhensible (ce qui n'est vraiment pas simple quand on parle aussi vite) du coup l'audience s'est pris un torrent sans interruption d'informations ultra pointue et de blagues mélangées tout au long de la conférence. Du très très très lourd qui aurait mérité une standing ovation. On a eu droit à la présentation "torchée"⁸ de l'architecture du framework python d'ingénierie inverse smiasm composé de miasm, grandalf, et elfesteem. Ensuite on a une présentation du langage intermédiaire utilisé par miasm qui permet de s'abstraire du matériel sous-jacent, et tout au long de la présentation on est accompagné par des exemples de-la-vraie-vie type exécution symbolique⁹ identification de gadgets pour ROP, désobfuscation, etc. Vraiment ZE conf de ce SSTIC 2012.

Rétroconception et débogage d'un baseband Qualcomm par Guillaume DELUGRE : Pas de chance pour cet orateur, il passe après Fabrice DESCLAUX. Le rythme est plus posé, mais en comparaison il apparait carrément lent :-/ Le contenu est néanmoins intéressant avec l'activation des canaux de communication série prévue pour débuggage dans une clef 3G qualcomm, l'utilisation de ce canal pour dumper l'ensemble du firmware, puis son analyse par ingénierie inverse. L'impression que j'en garde c'est que le firmware est assez "crado" (pour citer le speaker) et qu'il y a donc potentiellement pas mal de choses à aller regarder par là...

Protéger et défendre le cyberespace militaire : la démarche nationale par le contre-amiral Arnaud COUSTILLIERE : le premier élément qui saute aux yeux ce sont les slides, clairement issus d'un windows 95 ou antérieur. Les couleurs sont criardes, les images déformées, et les schémas semblent tout droit issus des bouquins d'enseignements de la biologie des années 90. M'enfin on va passer outre ^^ Concernant le fond du discours c'est une présentation sur la stratégie de défense informatiquecyber mise en place au niveau étatique. Dommage qu'il n'ai justement parlé que d'organisation de la défense et qu'il ai esquivé les questions offensives lors de la séance de questions¹⁰.

Conclusion : je dirai que ce SSTIC était moyen jusqu'à l'entame de la troisième journée qui a remonté le niveau pour rendre cette édition mémorable. Je rentre de Rennes avec des heures de sommeils de retard, trois grammes dans chaque bras, mais également PLEINS d'idées de nouveaux terrains de jeux à explorer. Et puis si jamais je présente à nouveau au SSTIC un jour j'essaierai de garder à l'esprit qu'une conférence peut avoir un contenu techniquement super mais ne pas décoller du "mouaif" dans le ressenti du public si le speaker n'est pas à 200%.

1. et je dit bien "paragraphe", pas "idée" ↩
2. Celle là c'est quand même ma citation préférée du SSTIC Q:"ça ne vous semble pas à l'opposé de toutes les bonnes pratiques?" R:"Et si on le prouve mathématiquement le code ?!" ...mais oui bien sur :-D ↩
3. j'aime décidément cette expression ↩
4. Et j'ai eu l'honneur de lui serrer la main en plus ! Youhouuuuuu !!! Même si pour ça je l'ai intercepté un peu comme un goujat alors qu'il quittait le social event (probablement pour la rue St Michel). Si vous me lisez un jour : désolé :-/ ↩
5. En même temps c'est un peu gonflé de commencer une rump SSTIC par "ça c'est une photo des produits qu'on vend" puis d'enchainer 2mn plus tard par "le code est libre mais on a tout fait pour que vous ne puissiez pas l'utiliser sans nous acheter de prestation de toute façon" ↩
6. Même si ça reste à prouver sérieusement... ↩
7. Et encore...on pourrait pousser la mise à mort en s'interrogeant comment son outil va être utile pour les botnets qui utilisent des C&C alternatifs type Skype, Facebook, pastebin, etc. ↩
8. Mais super bien torchée ! ↩
9. Quote : "là je suis en train de vous expliquer que j'ai recodé qemu" ↩
10. Parce que répondre "attaquer c'est illégal donc on ne fait pas" c'est au mieux pas crédible du tout et au pire inquiétant à la lumière de Flame/STUXNET/etc. ↩

Monsieur Soleil peut tout faire. Retour de l'être aimé, prédiction des résultats du loto, choix infaillible de la couleur de la cravatte, conjuration des problèmes d'impuissance, etc... Bon plus sérieusement je ne vais pas parler de ce type de guérisseur là, rassurez-vous. Je vais vous parler de Jason, figure de la mythologie grecque connu sous le surnom "le guérisseur"...bon non plus, ça c'était juste pour le jeu de mot (bien pourri). En fait je vais vous parler de JSON et, plus précisément, des JSON-RPC que j'ai eu la surprise de découvrir accessibles sur mon serveur...

Pour poser le cadre donc : j'ai un serveur multimédia (allumé H24¹, comme tout bon serveur qui se respecte) et l'autre jour alors que je faisais le petit nmap routinier de mon réseau local apparait une nouveauté sur ce serveur :

PORT     STATE SERVICE     VERSION
9090/tcp open  zeus-admin?

Autant vous dire que, sur le moment, j'ai un peu fait la gueule :-D Après enquête rapide il s'avère que c'est en fait le XBMC qui tourne sur mon serveur qui expose là l'une de ses nouvelles interfaces de commande... Dans les anciennes versions, XBMC exposait uniquement (pour autant que je sache) une interface de commande HTTP accessible après authentification et qui permettait ainsi de controller les lectures multimédia via le réseau (super pratique pour transformer votre téléphone android en télécommande wifi). Dans les dernières version l'interface HTTP est deprecated, et c'est l'interface JSON-RPC qui devrait la remplacer.

Pour ceux qui l'ignorent (comme moi il y a quelques semaines), le JSON-RPC c'est une méthode de RPC qui utilise la syntaxe JSON (on ne s'en douterai pas hein ?). Et pour la conclure l'explication : le JSON c'est une méthode de formatage de données dont l'esprit est de se rapprocher de la syntaxe....javascript. Je ne plaisante pas, JSON c'est même l'acronyme de "JavaScript Object Notation" si vous voulez tout savoir. Du coup une requête JSON-RPC ça ressemble à ça :

{"jsonrpc": "2.0", "method": "subtract", "params": {42, 23}, "id": 1}

Bon...c'est pas très joli mais ça reste compréhensible :) Du coup je me suis dit "voyons ce que l'on peut faire avec ça", mais avant d'exposer les résultats je dois faire un disclaimer : "j'ai peut-être été trop permissif dans ma configuration d'xbmc (même si j'en doute), donc ne blamons pas trop les réglages qu'on peut/doit faire pour utiliser une télécommande, c'est peut être ma faute". Maintenant répondons à "que peut on faire avec ça ?" :

Première chose : survoler la liste des procédures accessibles. La première qui a une tête sympa c'est "JSONRPC.Ping". Aussitôt identifiée aussitôt testée :

echo '{"jsonrpc": "2.0", "method": "JSONRPC.Ping", "id":"5"}' | nc serveurmultimedia 9090

Et réponse immédiate :

{
   "id" : "5",
   "jsonrpc" : "2.0",
   "result" : "pong"
}

Cool ça marche :-D !!!...Pas cool : j'ai pas eu besoin de m'identifier :-/

La paranoïa aidant la seconde procédure que je teste c'est "Files.GetDirectory"...forcément.

echo '{"jsonrpc": "2.0", "method": "Files.GetDirectory", "id":"peur", "params":{"directory":"/"}}' | nc serveurmultimedia 9090

Ah bah....ça marche :

{
   "id" : "peur",
   "jsonrpc" : "2.0",
   "result" : {
      "directories" : [
         {
            "fanart" : "special://masterprofile/Thumbnails/Video/Fanart/cfb24076.tbn",
            "file" : "/var/",
            "label" : "var"
         },
         {
            "fanart" : "special://masterprofile/Thumbnails/Video/Fanart/b1fe6366.tbn",
            "file" : "/usr/",
            "label" : "usr"
         },
         {
            "fanart" : "special://masterprofile/Thumbnails/Video/Fanart/dafd2084.tbn",
            "file" : "/tmp/",
...ETC...

Et vous savez le mieux ? Y'a une procédure Files.Download :-D !...Après l'avoir testé dans tout les sens il semblerait qu'en fait cette procédure ne soit, pour l'instant, pas implémentée (ouf !) et que de toute façon elle ne permette de télécharger que des ressources générées par XBMC (vignettes, etc.). M'enfin déjà le simple Files.GetDirectory c'est pas très joli²...Du coup une seule chose à dire : faites attentions aux permissions que vous mettez sur votre XBMC si vous voulez utiliser une télécommande réseau, il se peut que vous ouvriez des portes à n'importe qui ayant accès au port TCP.

Ceci étant dit, on va considérer que ça cloture la partie "sécu" de ce billet, et on va voir si on peut jouer avec ça sans vilaines pensées, par exemple essayons de faire les requêtes en python :

>>> import json, socket, random
>>> req = {'jsonrpc':'2.0', 'id':str(random.randint(0,100)), 'method':'JSONRPC.Ping'}
>>> s =  socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(("serveurmultimedia",9090))
>>> s.send(json.dumps(req))
>>> reponse = s.recv(1024)
>>> print reponse
{
   "id" : "82",
   "jsonrpc" : "2.0",
   "result" : "pong"
}

Intéressant...Du coup si jamais un script python sur android qui est en train d'exécuter time.sleep() ne consomme pas de CPU (donc de batterie) je pourrai m'écrire un script, utilisable sur mon téléphone, qui me réveille à l'heure de mon choix en jouant le média de mon choix sur mon serveur !!! Intéressant non ?

Pour que ça soit intéressant j'ai envie de lire un mp3 aléatoire. La logique de XBMC étant ce qu'elle est³ je dois d'abord récupérer les "sources" de music :

>>> req = {'jsonrpc':'2.0', 'id':str(random.randint(0,100))}
>>> req['method'] = "Files.GetSources"
>>> req['params'] = {'media':'Music'}
>>> s.send(json.dumps(req))
>>> reponse = s.recv(10*1024)
>>> shares = json.loads(reponse)['result']['shares']
>>> for s in shares:
>>>    print s['file']
/mnt/raid0/musiquelegalementachetee/
...

Une fois les sources récupérées (et surtout les répertoires associées, dans l'attribu bien nommé "file"...) on peut utiliser Files.GetDirectory dont on parlait plus haut afin de récupérer l'ensemble des morceaux directement à la racine de notre source (j'ai la flemme de coder le récursif pour l'instant) :

>>> req = {'jsonrpc':'2.0', 'id':str(random.randint(0,100))}
>>> req['method'] = "Files.GetDirectory"
>>> req['params'] = {'directory':shares[0]['file']}
>>> s.send(json.dumps(req))
>>> reponse = s.recv(100*1024)
>>> musics = json.loads(reponse)
>>> random.shuffle(musics['result']['files'])
>>> musique = musics['result']['files'][0]["file"]
>>> print musique
/mnt/raid0/musiquelegalementachetee/rickroll.mp3

Maintenant j'aurai adoré utilisé AudioPlaylist.Insert pour insérer la chanson à l'endroit de mon choix dans la playlist courante puis en lancer la lecture, sauf que quand je fais appel à AudioPlaylist.Insert j'ai une réponse Method not found....On va donc supposer que ce n'est pas encore implémenté :-( Résultat il ne me reste plus qu'à me rabattre sur AudioPlaylist.Add puis prier le guérisseur pour que lors de l'appel à AudioPlaylist.Play ce soit le bon morceau qui soit joué...Je l'ai donc fait :

>>> req = {'jsonrpc':'2.0', 'id':str(random.randint(0,100))}
>>> req['method'] = "AudioPlaylist.Add"
>>> req['params'] = {"item": {"file":musique}}
>>> s.send(json.dumps(req))
>>> reponse = s.recv(1024)
>>> print reponse
{
   "id" : "2",
   "jsonrpc" : "2.0",
   "result" : "OK"
}
>>> req = {'jsonrpc':'2.0', 'id':str(random.randint(0,100))}
>>> req['method'] = "AudioPlaylist.Play"
>>> s.send(json.dumps(req))

Et là ça ne joue pas le bon morceau :-S ... Vérification de la playlist : mon morceau n'a même pas été ajouté en fait... Heureusement la communauté des dev de XBMC est plutôt très active et j'ai rapidement trouvé le problème :

The current playlist implementation/representation in json rpc has many (design) flaws and there are lots of unsupported things and it will hopefully be completely rewritten for the next release (if there's enough time). Until then it might be the safest approach not to use the Playlist methods (except SkipPrevious, SkipNext, GetItems, Clear, Shuffle and UnShuffle which should work as expected).

We're sorry for the inconvenience and hope to provide a much better solution in the next version

Donc voilà : actuellement il est impossible de faire ce que je voulais :-( ..Snif. La suite peut-être à un prochain numéro :) !

1. Que les amis de la planète se rassurent : c'est une machine à base d'atom qui consomme moins en H24 qu'une seule heure de jeu sur les dernières cartes graphiques à la mode ↩
2. Même si, comme moi, vous faites tourner votre XBMC avec des droits minimalistes ↩
3. et comme je n'utilise pas les fonctionnalitées "library" d'XBMC ↩

Avec l'été qui revient le soleil se fait de plus en plus présent et c'est donc le moment de ressortir...son android ! Bah oui, avec le beau temps on se retrouve plus souvent à glander en plein air et pour geeker il n'y a alors rien de plus pratique/portable qu'un android :)

J'avais déjà expliqué dans un vieux billet comment installer un environnement d'émulation Android¹, et bien cette fois je vais parler de SL4A. SL4A c'est une application qui vous permet d'utiliser des langages de scripts populaires (LUA, ruby, python, etc.) sur votre android. Pour en profiter il suffit d'installer SL4A (soit depuis le market soit en téléchargeant l'APK directement depuis leur site. Pour l'installer sur emulateur ca fera donc adb install ~/droid/sl4a_r4.apk), de le lancer, de choisir "ajouter" dans le menu de l'application, puis de choisir l'interpretteur du langage de votre choix (pour ma part j'ai choisi Python ;) ).

Une fois SL4A installé et les interpretteurs de votre choix téléchargés et installés depuis SL4A vous avez accès à toute une API qui vous permet d'interragir, depuis vos scripts, avec le terminal Android. Vous pouvez par exemple accéder à la liste des contacts enregistrés, lire les capteurs divers et variés, utiliser l'apareil photo, envoyer/lire des sms, etc. Par contre, coder sur son téléphone ça devient vite fatiguant, donc un tout petit peu de préparation est utile pour coder à son aise.

Tout d'abord nous décidons de coder sur émulateur, ça évitera de mettre trop la grouille sur notre téléphone. Ensuite il faut savoir que les scripts que SL4A est capable de lancer sont stockés par défaut dans /mnt/sdcard/sl4a/scripts. Enfin il faut savoir un petit peu se servir de l'outil adb qui est fourni avec le SDK Android (mais vraiment juste "un peu" je vous rassure).

Pour coder à notre aise donc, nous allons commencer par lancer un AVD² (je vous conseille de lui accorder au moins 512Mo de mémoire vive, sinon ça rame vraiment trop !). Ensuite nous choisissons un répertoire sur notre machine hote qui servira de répertoire de développements³. Enfin, on va y coder notre premier petit script python pour android (avec VIM bien entendu) :

import android
droid = android.Android()
droid.makeToast("Bonjour le monde")

Pour info on aurait pu se contenter de print "Bonjour le monde" mais dans ce cas nous n'aurions pas eu d'interfaçage avec l'UI android et donc nous n'aurions pas pu afficher "Bonjour le monde" dans une petite info-bulle stylée en bas de l'écran. Bref, une fois le script écrit il faut le pousser sur l'AVD adb push bonjour.py /mnt/sdcard/sl4a/scripts/bonjour.py, il apparait alors dans le répertoire "scripts" de SL4A et en cliquant dessus ça fait bien apparaitre une mini info-bulle contenant "Bonjour le monde" :)

Maintenant on peut se pencher sur une amélioration de tout ça. Par exemple optimiser le push. Pour cette étape j'ai bêtement fait un Makefile :

all:
    ls *.py | xargs -I 'X' ../tools/adb push X /mnt/sdcard/sl4a/scripts/X
    ls *.py | xargs -I 'X' ../tools/adb shell rm /mnt/sdcard/sl4a/X.log

Grâce à cette "astuce" il me suffit de faire un "make" avant chaque test pour que l'ensemble de mes scripts soient poussés sur l'AVD, et ça ne me change pas trop des habitudes prises en C/CUDA⁴.

Une fois qu'on sait afficher du texte dans une info-bulle on peut se pencher sur toutes les autres fonctions de l'API et laisser courir notre imagination. Pour les besoins de la cause je conclue d'ailleurs ce billet par quelques exemples de scripts inutiles mais drôles (et donc indispensables) qui m'ont servi de tests :

IRC-like :

import android
droid = android.Android()

victime = droid.pickPhone()
droid.smsSend(victime.result , "I slap you with a large trout")

IRC-like++:

import android
droid = android.Android()

armes = ['Truite', 'Chaussette', 'Andouillette']
droid.dialogCreateAlert("Choix des armes")
droid.dialogSetItems(armes)
droid.dialogShow()
response = droid.dialogGetResponse().result['item']
try:
  response = armes[int(response)]
except:
  response = armes[0]

victime = droid.pickPhone()
message =  "Je viens de te baffer avec une "+response
droid.smsSend(victime.result , message)
droid.makeToast("ENVOYE : "+message)

1. si tant est que quelqu'un aurait eu besoin d'explications pour ça... ↩
2. AVD = instance d'android virtuel ↩
3. Répertoire dans lequel vous pourrez faire un petit bzr init && bzr add * && bzr commit si le coeur vous en dit. ↩
4. Pour en savoir plus sur ce que j'ai fais récemment en C/CUDA (et pourquoi j'ai délaissé ce blog pendant des mois) je vous invite à aller suivre le SSTIC puisque j'ai l'immense honneur d'y donner une conférence mercredi prochain :) ! ↩

Avec tous ces androids qui fleurissent un peu partout dans mon entourage ces derniers temps il fallait bien que je craque un jour ou l'autre... Première étape du craquage : je me replonge (légèrement) dans le Java¹ pour jouer un petit peu avec le SDK et les émulateurs android fournis par Google. Et comme je sens que les étapes d'initialisations d'un projets ou d'une VM sont du genre à disparaitre de ma mémoire en moins de temps qu'il n'en faut à Windows ME pour planter je me suis dit que j'allais en faire un petit billet pour ce blog, à moitié sous forme de mémo donc, histoire de conserver une trace de toutes les étapes à mener pour jeter les premières fondations d'une appli android²

Téléchargement de l'environnement

Première étape : récupérer le SDK chez Google. Jusque là : facile ;) Ensuite on décompresse l'archive tar xvzf android-sdk_r3-linux.tgz. Toujours rien de compliqué jusqu'à présent. Pas d'improvisation, soyons discipliné cd android-sdk-linux && cat "SDK Readme.txt", la ligne suivante nous est donnée directement par le petit texte du Readme, ./tools/android update sdk. Ca ouvre un GUI...bon, c'est l'heure d'improviser. Visiblement le GUI permet de télécharger des composants essentiels qui ne sont pas inclus dans l'archive, par exemple ce qu'il faut pour créer des android virtuels (je me disait bien que 15M pour le tout ça faisait léger...). Je choisis un SDK pour Android 2.0 (la version la plus récente), et j'espère que ça suffira pour commencer (le bébé pèse tout de même plus de 40M et je suis en train de faire un gros emerge world à coté donc ma bande passante est assez limitée ;) )

Préparation de l'environnement

Une fois le téléchargement et l'installation (automatique) terminés on a toutes les briques de bases. Préparons tout ça pour que ça soit en état de fonctionner. Dans la fenêtre de GUI que je n'ai pas encore fermée (mais qu'on peut retrouver aisément en lançant juste ./tools/android sans arguments) je choisis le menu "Virtual Devices" et hop je clique sur "New", rien de super compliqué là, je prend les valeurs par défaut puis je clique sur "Create AVD" (Android Virtual Device). Ca a l'air d'avoir marché puisque ma VM (pardon, "mon AVD" ) apparait maintenant dans une liste de choix qui était auparavant vide. Je la sélectionne, je clique sur "Start" et là la magie s'opère : l'android virtuel démarre bien.

• Première constatation : je n'aurai peut-être pas du laisser le skin par défaut, il est vraiment laid (mais au moins il a l'air fonctionnel, je vais sans doute m'y habituer, et rien ne dit que les autres sont mieux lol).
• Seconde constatation : le démarrage est lent, mais alors vraiment lent ! Je pensais que sur émulateur ça irait plus vite que sur les vrais téléphones mais non (ceci dit mon pc n'est pas une machine de guerre...mais quand même). Je suppose que c'est la faute de Java, de toute façon quand quelque chose rame c'est forcément la faute de Java ;) !

Hello World

Démarrer le projet

Bien, maintenant qu'on arrive à faire tourner des android virtuels, il est temps de sacrifier à l'éternelle tradition du "Hello World". Seulement voilà : je n'aime pas le Java³, et je n'aime pas Eclipse non plus, donc je ne vais pas pouvoir suivre à la virgule près le tutoriel officiel...qu'à celà ne tienne, je vais essayer d'y coller au mieux et au moins je comprendrai sans doute un peu mieux comment ça se passe que ceux qui se contentent de cliquer sur des gros boutons Eclipse "Auto Write Code And Compile And Debug And Deploy And Become Rich" ;)

Première étape : démarrer un nouveau projet android. Pour ce faire j'aurai besoin de :

• Connaitre ma plateforme cible (i.e. la version d'android pour laquelle je veux écrire un programme). Comme je n'en ai téléchargé qu'une (pour android 2.0, souvenez vous) je suis prêt à parier que ma cible porte le numéro "1", mais bon, vérifions tout de même : ./tools/android list targets Gagné : l'indice 1 (le seul présent) correspond bien à l'API level 5, android 2.0 :)
• Un nom pour mon application. Je vais faire original : Hello
• Un répertoire pour stocker mon projet (s'il n'existe pas il sera créé en même temps que le projet). Encore une fois soyons original : ~/android_hello
• Le nom de la classe d'Activité par défaut de mon projet. Alors là ça demande une petite explication de texte : d'après ce que j'ai compris en survolant les site parlant d'android une "Activity" serait, en gros, l'équivalent d'un thread. Donc là il me demande plus ou moins le nom de la classe à lancer au démarrage de mon appli. Continuons dans l'originalité : HelloActivity
• Le namespace du package de mon projet, comme en Java. Hop : fr.ozwald.android.hello

Une fois ces éléments décidés, plus qu'à taper la commande magique :

./tools/android create project --target 1 --name Hello --path ~/android_hello --activity HelloActivity --package fr.ozwald.android.hello

Voilà, ça semble avoir marché. En tout cas il m'a créé tout pleins de fichiers dans ~/android_hello (qu'il a créé pour l'occasion) et ne m'a sorti aucun message d'erreur. J'aime quand un plan se déroule sans accroc !

Modifier le squelette de projet

Petit coup d'oeil dans le répertoire ~/android_hello/src/fr/ozwald/android/hello/, on y trouve un fichier Java qui correspond à priori au squelette de ma toute nouvelle application (et qui est le même que celui trouvé dans le tuto officiel avec Eclipse, elle est pas belle la vie ;) ?). Plus qu'à suivre les modifications proposées par le tuto officiel afin d'obtenir le code suivant :

package fr.ozwald.android.hello;

import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;

public class HelloActivity extends Activity {
   /** Called when the activity is first created. */
   @Override
   public void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       TextView tv = new TextView(this);
       tv.setText("Hello, Android");
       setContentView(tv);
   }
}

Normalement ça devrait suffire pour le Hello World.

Compiler le projet

Compilons donc la chose, en mode debug (ce qui simplifie un peu le déploiement en zappant l'étape de signature du jar mais en interdit l'exécution hors des environnement virtuels) cd ~/android_hello && ant debug. Bon...bug. M'étonnes pas venant de Java -_- Il s'emmèle les pinceaux entre les JRE et les JDK que j'ai sur mon poste. Après 5mn à trifouiller je m'en sort avec un petit emerge -uv --oneshot java-config. suivi d'un java-config -S 2 afin de redéfinir ma JAVA_HOME actuelle pour pointer sur l'un des JDK que j'ai, plutôt que sur un JRE. Reprenons : ant debug. Le script semble content puisqu'il me parle de façon polie (i.e. pas de gros "FAIL" et autres "ERRORS") et effectivement dans le répertoire ~/android_hello/bin je trouve bien un Hello-debug.apk⁴. Youpi :) !

Tester l'appli

Plus qu'à installer notre appli sur notre android virtuel, et le tour sera joué. Pour ce faire je redémarre mon AVD et, depuis le répertoire "tools" du SDK android, je lance l'incantation magique qui devrait installer l'appli dessus pendant qu'il fonctionne ./adb install ~/android_hello/bin/Hello-debug.apk. Je regarde à présent dans l'AVD et, miracle, une nouvelle application est là : HelloActivity (bon, pas très joli tout ça, mais on s'en fout pour l'instant). Je la lance...Ca marche :) !

Voilà, finalement ça a presque été facile et ce post ne me servira peut être jamais tellement avoir un trou de mémoire là dessus semble peu probable, mais "sait-on jamais"... Et d'ailleurs pour conclure voici une mini astuce : à la place de compiler (ant debug) puis d'installer (adb install ~/android_hello/bin/Hello-debug.apk), vous pouvez (à condition qu'il n'y ai qu'un AVD en route) remplacer ces deux commandes par un unique ant install qui fera la compilation en debug puis l'installation à la volée. Vachement pratique ^_^ !

1. Le Python est supporté depuis peu via le "Android Scripting Environment" mais, hélas, il ne permet pas (encore ?) de réaliser des applications complètes déployables via le market :( ↩
2. Oui, je ne suis pas le premier, et certainement pas le meilleur auteur, mais comme prévenu : ce billet a pour premier but de me servir d'aide mémoire pour une fois ^_^ ↩
3. Oui je sais : ça ne se voit pas trop ;) ↩
4. apk c'est l'extension des applications pour android...à priori c'est des JAR ;) ↩