Vous le savez peut-être, Orange vient de lancer une campagne marketing au doux nom de Chabal Le Duel. Visitez-donc le site si vous ne connaissez pas. L’idée est vraiment excellente : recevoir un appel personnalisé de Sébastien Chabal qui vous demande de l’aide pour marquer un but. En plus l’impression de réelle est augmentée par la synchronisation entre le mini-film que vous voyez à l’écran et ce qui se dit dans votre téléphone.

Avertissement : Je vois fleurir ce type de site (appel téléphonique + vidéo) depuis un bon moment. Cet article n’est que le résultat d’une (petite) réflexion que je me suis permis de me poser il y à maintenant 30 minutes. Mon but est de montrer comment il est possible de “dévier” (légèrement) l’utilisation d’une telle plateforme et en aucun cas de réaliser des actions malhonnêtes, je vous demanderai donc d’en faire autant.

Oui et alors ?

Alors je me suis intéressé un peu plus aux échanges client(flash)/serveur. Une fois le formulaire (où l’on doit remplir son nom, prénom, email et numéro de téléphone) envoyé ces échanges se forment et voici un résumé :

(Hypothèse) : “vérification si le numéro de téléphone est correcte”, retourne le nombre d’appels envoyés vers ce téléphone par la plateforme.

(Hypothèse) : page pour l’enregistrement de l'email, nom, prénom, numéro de téléphone et options diverses.

Paramètres :

Ce script permet d'établir l'appel avec le numéro précisé et de spécifier le prénom que le Chabal virtuel devra employer.

Retourne :

Puis, pour garder la synchronisation entre le téléphone et la vidéo, il y a un appel récurrent de :

Paramètres :

Constat après quelques tests

• La variable ord peut être vide lors de l’appel de mpc2.php la communication avec le téléphone sera quand même effectuée
• Si name n’est pas  dans la liste pré-enregistrée, ou s’il n’est pas défini, le Chabal virtuel dira “salut l’ami”
• Si ord n’est pas défini, alors l’appel ne sera plus en mode inconnu mais par un numéro en 01…

Il est donc tout à fait possible d’effectuer directement une requête POST sur mpc2.php afin de lancer un appel vers un numéro de téléphone prédéfini.

Quels déviances sont possibles ?

Sachant ce que l’on sait maintenant il nous est possible de détourner ce système de son utilisation principale, on pourrait donc :

• Flooder un ami…ou enemi
• Créer un bash ou un programme qui appelle, via Curl ou autre, à intervalle régulier, via un cron par exemple, le script mpc2.php. Ce qui pourrait permettre en pratique de faire téléphoner Chabal à minuit tout les soirs à un “amis”.
• …et sans doute d’autres détournements dont je n’ai pas l’idée à l’heure où j’écris ces lignes.

Beaucoup trop de site “full flash”, en plus du fait qu’ils ne sont vraiment pas agréable et lent (point de vue personnel) oublient l’aspect de sécurisation des données qui transitent, un simple chiffrage des valeurs serait déjà mieux.

Je suis actuellement en train de développer une application Adobe Air comme certains le savent, et j'ai besoin (ou plutôt envie) de créer moi aussi mon propre "raccourcisseur" d'url.

Apparemment la plupart des services du genre se base sur une base de données, l'objectif pour être concurrentiel est donc d'effectuer le moins de requête possible afin que le service soit le plus rapide. Après avoir soumis à la suite plusieurs urls différentes à minurl.fr, j'ai obtenu cette suite d'url :

• http://minurl.fr/12
• http://minurl.fr/13
• http://minurl.fr/14
• http://minurl.fr/15
• http://minurl.fr/16
• http://minurl.fr/17

Que peut-on en conclure ?

1. A chaque nouvelle url qui n'existe pas dans la base de données
1. On créé un identifiant, supérieur au dernier identifiant, que l'ont lie à l'url (ou plutôt un équivalent compressé de l'url).
1. Donc dans la table de notre base de données on à pour le moment les champs suivant :
1. id varchar(10) (primary) : identifiant pour l'url qui sera afficher
2. url varchar(40) (index) : champs pour l'url compressée
1. Il est préférable que le contenu de ce champs soit compressé si l'on ne veut pas une énorme base de données mais cela n'est pas obligatoire !
2. Dans cette exemple d'algorithme nous ne nous soucierons pas de la compression de l'url.
2. Si le script reçoit un identifiant
1. Chercher dans la base de données si l'id existe
1. Il existe : on retourne l'url (il faudra la décompresser si on l'a compressée)
1. On redirige vers cette url.
2. Il n'existe pas : on informe l'utilisateur.
3. Si le script ne reçoit pas d'identifiant
1. On propose le formulaire d'ajout

Maintenant, on répète l'expérience avec Tinyurl, on à donc cette suite d'url :

• http://tinyurl.com/6l74df
• http://tinyurl.com/6d8r75
• http://tinyurl.com/5o5c7d
• http://tinyurl.com/5tfegj
• http://tinyurl.com/63kjqo
• http://tinyurl.com/6ys8ym

Que peut-on en conclure ?

1. Il semble que Tinyurl utilise un système de création d'ID aléatoire, ce qui empêche toute prédiction sur le prochain ID à venir.
2. Chaque nouvelle ID créé est de la forme 5XXXXX ou 6XXXXX (d'après mes tests). Il est donc possible que les ID de la forme 4XXXXX, 3XXXXX, 2XXXXX est déjà été tous utilisé.
1. Il est donc fort probable que l'algorithme de Tinyurl, répartisse les ID fraichement créé sur deux plages qui n'ont pas encore été complètement remplie (dans notre cas 5XXXXX et 6XXXXX). Nous pouvons émettre cette hypothèse vu que les plages [4XXXXX, 3XXXXX] et [2XXXXX, 1XXXXX] on déjà été rempli.
1. Exemple, si l'on entre http://google.com l'ID de TinyUrl est http://tinyurl.com/1c2 : notre théorie est donc sans doute valide car cette adresse à été entrée dans les débuts de Tinyurl (par une personne qui souhaitait tester le service) et qu'au lancement l'algorithme devait travailler sur une plage [2XXXXX, 1XXXXX].
3. L'algorithme semble donc bien plus complexe que celui élaboré plus haut.

Nous avons donc une base d'algorithme pour créer notre service, bien sur, il est extrêmement conseillé de l'améliorer mais il reste néanmoins fonctionnel et c'est ce que l'on souhaite d'un algorithme n'est-ce pas ?

Avant de commencer cet article, je souhaite préciser plusieurs choses :

1. Je suis autodidacte, je n'ai aucune formation scolaire sur le sujet, il est donc possible que je n'emploie pas les bons termes, ne sortez pas le fouet pour autant.
2. Je montrerai dans ce poste qu'un bref aperçu de mes méthodes de R-E (Reverse-engineering), mon but n'est pas de former, mais simplement d'expliquer la démarche.
3. J'utilise la rétro-ingénierie à des fins de formation personnel et en aucun cas pour de la contrefaçon ou autre forme de piraterie.

Base d'une réflexion de rétro-ingénierie

Pour commencer, nous allons résumer rapidement le projet : Nous devons créer un équivalent à TwitterCounter mais pour Plurk (que nous appellerons PlurkCounter).

La page d'un utilisateur sur TC (TwitterCounter) est de la forme :

Maintenant l'idée consiste à chercher l'ensemble des informations dont on va avoir besoin pour réaliser un service similaire. On a donc besoin :

• De connaitre le nombre de followers actuellement.
  • Pour l'afficher dans le badge/logo.
  • Pour l'afficher dans le graphique dans la colonne de droite.
• On a besoin de connaitre le nombre de followers au jour X (dans le passé).
  • Pour afficher l'évolution du nombre de followers dans le graphique.
    • On aura donc besoin de stocker un tableau permettant une relation entre les jours et le nombre de followers pour ces jours-là.

Et c'est déjà fini ! Il ne reste plus qu'à retranscrire cela par un algorithme puis par du code, en allant du plus simple au plus complexe. L'objectif et de voir ce que vous pouvez recréer, puis, une fois vos acquis évalués, essayez de voir comment faire pour chercher les informations qui vous manquent.

Quelques pistes d'algorithme :

1. Cherchez comment retrouver le nombre de followers actuels d'un utilisateur (Plurk ou Twitter ou même autre).
2. Créez un système de cache qui permettra de ne pas aller rechercher l'information si elle n'est pas périmée :
   1. Si (un fichier cache existe pour cet utilisateur et qu'il date de plus de 24h) OU Si(le fichier cache de cette utilisateur n'existe pas)
      1. Chercher le nombre de followers de cet utilisateur et créer le fichier cache.
   2. Sinon
      1. Ouvrir le fichier cache et récupérer/afficher le nombre de followers.
3. Ensuite pour la journalisation, et permettre le suivi du nombre de followers en fonction du temps, ajoutez un test à votre algorithme :
   1. Si (le fichier cache pour cet utilisateur existe) ET (le fichier cache date de plus de 24h)
      1. On enregistre dans une base de données/fichier le nombre de followers pour la date du fichier cache.
4. Il ne vous reste plus qu'à afficher les données sous la forme que vous souhaitez.

Autre exemple : Reproduire le graphique de TC

Intéressons nous maintenant à l'affichage des données sous la forme de graphique, comme le montre TC :

Émettons que vous réussissiez à créer d'une façon ou d'une autre une base de données (ou un tableau) qui contient le nombre de followers en fonction de la date.

La question qu'il reste à vous poser est comment reproduire ce type de graphique ?

1. Vous avez forcément le nombre de followers d'aujourd'hui pour cet utilisateur, donc la colonne de droite sera toujours remplie.
2. Ensuite recherchez si hier, pour cet utilisateur, vous aviez le nombre de ses followers :
   1. si oui : vous affichez l'information.
   2. si non : vous informer l'utilisateur que vous n'avez pas de données pour ce jour-là.
3. Vous pouvez effectuer une boucle jusqu'à J-X (pour TC la boucle va jusqu'à 7 jours en arrière, pour PlurkCounter la boucle va jusqu'à 8 jours en arrière) de la même façon.

Voila j'espère que cette petite initiation vous à plu, n'hésitez pas à tester PlurkCounter si vous êtes un utilisateur de Plurk.