À l'heure où flash disparaît progressivement de la plupart des sites internet, remplacé par le savoureux et puissant HTML5 ... il existe toujours d’irrésistibles Gaulois pour lutter encore et toujours contre l'envahisseur.

Aussi, lorsque je navigue sur des sites internet qui utilisent encore flash, j'aime  prendre 5 minutes pour récupérer les fameuses applications SWF (flash) et en extraire le code "Action Script"

Dans le contexte de TF1, je suis tombé par hasard sur le jeu "Money Drop"
Bien entendu mon navigateur récent, m'a dit

ATTENTION mon p'tit gars ! Si tu as envie d'utiliser ce magnifique jeu
Il te faudra installer Flash !

 

Alors clairement, lorsque je vois ce mot, j'ai comme une vision d'horreur ...

 

 

Il existe des dizaines et des dizaines de vulnérabilités qui continue de toucher flash ...
Et des milliers d'utilisateurs qui clairement ne mettent jamais à jour leurs systèmes, s'exposant alors, aux dangereuses griffes des pirates !

Bref, là je me suis dit, qu'il fallait "contre mauvaises fortunes, faire bon cœur".

D'autant que le jeu proposé par TF1, permet de gagner des lots !

 

 

Donc vous imaginez bien, qu'une personne qui pourrait trouver une faille dans le jeu, de manière à gagner tout le temps ...
Pourrait se faire de l'argent (ou des cadeaux) facilement ...

Avant toutes choses j'ai regardé les différentes requêtes envoyées par le jeu ...

Lorsque j'étais en mode "tutoriel", toutes les questions et les réponses "multiples" avec l'indicateur "bonne ou "mauvaise" réponse, étaient récupérées en clair dans un formatage que l'on appelle "JSON"

 

Mais lorsqu'il s'agissait du mode "normal" ...
Les questions-réponses étaient envoyées en chiffré ... et donc non lisible ...

 

J'ai pris mon courage à deux mains, et j'ai téléchargé un outil "Open Source", largement recommandé par la communauté, pour décortiquer la fameuse application flash ...

JPEXS Free Flash Decompiler

 

 

Et pour les curieux qui voudraient savoir ce que contient ce logiciel c'est par ici :
https://github.com/jindrapetrik/jpexs-decompiler

 

 

Bref, en explorant le code source de l'application, accessible depuis le code source :

J'y ai découvert pas mal de petite pépite, mais je vous avouerais, la plus inattendue, fut la première piste ...

 

 

Une première piste pour récupérer les réponses aux questions ...

 

 

La clé publique et la clé privée (RSA) de l'application !
Il faut savoir qu'il est fortement déconseillé de laisser traîner dans son application ce genre d'information ...
C'est comme si vous mettiez la clef du coffre de votre compte aux îles Caïmans  sous votre tapis d'entrée ...
Pour vous faire mieux comprendre :
La "PUBLIC KEY" (clé publique) permet d'envoyer du contenu chiffré.
La "RSA PRIVATE KEY" (clé privée) permet de déchiffrer le contenu chiffré.

En général, on utilise ce système, pour s'envoyer des mails.
Vous partagez votre clé publique à vos contacts, afin que ceux-ci puissent vous envoyer des messages que vous seul pourriez lire à l'aide de votre clé privée ....

 

Là c'est tout pareil ...
Cependant pour mieux nous en assurer, regardons donc davantage le code ...

 

Okey, donc là, en naviguant dans le code je suis tombé sur la fameuse fonction "encryptedResponseHandler" ...
Traduction littérale, "lorsque tu reçois une réponse chiffrée" ...
Donc dès qu'on rentre dans cette fonction ... hmmm comme par hasard on évoque du JSON ^^
Okey, allons donc à cette fonction ... qui avant de s'occuper du JSON, fait un petit traitement pour déchiffrer le charabia (chiffrement des questions) que j'ai pu vous montrer dans une des captures ci-dessus ...

Et ... pour finir ... on voit bien que le déchiffrement passe par la clé privée !

 

Ahahaha ...

Vous commencez enfin à saisir !

Nous avons donc tous les outils pour déchiffrer nos réponses ...

 

Une seconde piste ...

 

 

Dans l'hypothèse où cette première piste ne fonctionnerait pas.
Car rien n'est écrit, il est possible que cela ne fonctionne pas ^^

Aussi, j'ai poussé le vice, et j'ai cherché toute forme possible de déchiffrement !

Je suis alors tombé sur une autre fonction de déchiffrement !

 

 

 

Okey, donc il existe une fonction "decryptData", et qui utilise un code de déchiffrement s'appelant protectedKey ...

J'ai donc investigué ...

 

 

Alors la fameuse clé de déchiffrement n'est autre que votre memberId (Id utilisateur) ...
Et le hasard fait bien les choses, celui-ci est récupéré par votre application ... via les différentes requêtes dans votre console développeur (F12)

 

 

Donc nous avons la fonction et le code utilisé pour déchiffrer nos réponses (dans le cas où ce serait celle-ci qui serait utilisée) !

 

A vos claviers

 

Vous avez donc ici la possibilité de vous entraîner à décortiquer des applications flash sur un cas concret !
Vous pourrez ensuite faire l’apologie du HTML5 et vanter les mérites d'un code source visible et non dissimulé derrière des applications flash pour "protéger"  de manière inefficace des données sensibles !

 

Le conseil pour TF1

 

Pour un cas pareil, il ne faut surtout pas envoyer l'information de bonne ou mauvaise réponse, celle-ci doit être traitée directement depuis le serveur, lorsqu'un utilisateur choisit une réponse...
Ainsi vous pourriez tranquillement envoyer vos données en clair (à condition d'utiliser du https)
J'évoque le cas du https, car aujourd'hui les données sont échangées en http, permettant ainsi aux personnes qui seraient connectées au même réseau qu'un joueur de lui dérober à son insu, ses données, et de se connecter sur son compte.

 

 

Le conseil du vieux singe  (ou Sage)

 

Si vous ne voyez pas apparaitre les requêtes figurant dans mes captures d'écran et que vous êtes sur Google Chrome.
Ouvrez votre console (F12)

Allez dans les settings

 

Ensuite, cochez la case "Log XMLHttpRequests"

Là, vous devriez voir un peu plus de requêtes apparaître !

 

 

 

 

Conclusion

 

Euh c'est vous les pros !
Donc à vous de jouer et impressionnez-moi avec votre talent !!!