Retour au blog

Rien de tel qu’une astuce WinDev Mobile pour commencer la semaine, non?

Publier une application Android sur le Play Store cache une faille de sécurité non-négligeable, les chaines de caractères sont en effet brutes dans le code, et une simple décompilation de l’APK permet de les voir.

La plupart du temps cela ne pose aucun problème, sauf quand la chaîne en question est un mot de passe codé en dur, comme c’est par exemple parfois le cas pour le mot de passe d’une base de données.

Il n’existe à ce jour pas de solution fiable pour contourner le problème, et celle qui est présentée ci-après ne permettra que de compliquer un peu la tâche aux hackers qui voudraient tenter de récupérer tes données codées en dur dans ton fichier APK décompilé.

Cela va se faire en deux étapes simples.

La première étape consiste à créer une procédure « deobfuscate » dans ton projet WinDev Mobile, tu recopies simplement le code ci-dessous.

Cette procédure va déchiffrer un texte selon certains paramètres, avec une complexité légère basée sur les nombres premiers. Je te laisse analyser la technique, l’expliquer serait imbuvable.

Pour la deuxième étape, tu vas suivre ce lien (c’est une page interne à ce blog, pas de panique), et dans le champ texte tu rentres le mot de passe ou la chaîne quelconque que tu désires complexifier. Pour réutiliser notre exemple du début, ce sera « helloworld1234 » .

Tu vas obtenir un code prêt à l’emploi, qui utilise la procédure WinDev « deobfuscate » .

Après exécution, la variable contiendra bien « helloworld1234 » .

Tu remplaces ton code critique par celui généré, tu l’adaptes un peu au besoin, et le tour est joué. Tu peux répéter cette deuxième étape pour chaque chaîne en dur que tu veux cacher.

Une fois décompilé, ton code Java généré par WinDev sera un tout petit peu moins exposé.


    lundi 24 juillet 2017

  6 commentaires

  1. *Il existe à ce jour des solutions fiable* – qu’on appelle « la cryptographie ».
    Et ça marche très bien (pour autant que ça soit bien fait), sauf dans des cas où l’énoncé du problème lui-même est complètement idiot.

    (exemple : la protection de contenu genre DVD, BlueRay, etc. où il faut donner le mot de passe de manière sécurisée à l’utilisateur final, mais où il faut aussi protéger le mot de passe d’un potentiel adversaire pirate… qui est également l’utilisateur final lui-même.
    En schéma d’exemples cryptographique, Alice ne peut pas transmettre quelque chose de manière sécure à Bob sans que Eve ne le lise si Bob et Eve sont la même personne)

    Si on envisage « comment est-ce que je pourrais cacher un truc dans mon code », il faut se poser la question :
    – de qui je veux le cacher ?
    – pourquoi je veux le cacher ?
    – comment est-ce que je peux entrer en contact avec mes utilisateurs ? par opposition aux attaquants (pour autant que Bob et Eve sont 2 personnes distinctes).

    Dans l’example, il faut se poser la question de qui sont les personnes qui peuvent avoir accès à l’APK de l’app (à peu près n’importe qui) mais qui ne doivent pas voir le secret – probablement limité aux seuls utilisateurs du service avec le quel l’app communique (donc ceux qui ont un compte par exemple).

    Et en général on va réussir à obtenir un solution, composée de primitives cryptographique classique comme : des négociations de clé secrètes éphémères (p.ex.: DHE – Diffie-Hellman), des clé publiques (RSA), du cryptage par mot de passe (p.e.: AES), des hash (par exemple SHA256) et plus précisément des des messages authentication codes (HMAC-SHA256) et des key-derivation function (p.ex.: Scrypt ou Argon2).
  2. Merci pour tes explications! 🙂

    Je ne voulais pas rentrer justement dans un tel procédé, qui serait clairement plus efficace. Je voulais garder les choses relativement simples, dans le cas où un amateur décompilerait l’APK, afin qu’il ne tombe pas directement sur des clés codées en dur.

    Encore une fois, ma solution est légère et complique juste un peu la tâche d’une véritable personne mal intentionnée, qui réussira à avoir les informations recherchées en quelques dizaines de minutes.
  3. « Au cas ou un amateur décompilerait l’APK »

    – au lieu de dumper la mémoire une fois la dé-obfuscation faite ?
    (= comment certains BluRays se font pirater)

    – ou de laisser tomber et directement regarder – p.ex. – le trafique HTTP entre l’app et le serveur ?
  4. Dumper la mémoire demande des connaissances qu’un amateur n’a pas, mon cas protège vraiment du gamin qui veut s’amuser à décompiler.

    Si la connexion est sécurisée, ce qui est souvent le cas, alors analyser le trafic sera sans intérêt.
  5. Bonjour Gaël,

    Merci pour ton travail et pour ton brillant code. Je vais l’utiliser simplement pour rediriger l’adresse xxx.awws d’un même Webservice sur un autre serveur pour les utilisateurs payants d’une appli. J’ai subdivisé le texte à coder en deux chaines de caractères.

    Cordialement
    François S.
  6. Merci pour le compliment! Ca fait plaisir de savoir qu’un bout de code a servi. 🙂

  Tu peux même laisser ton avis

Prends juste note que tout commentaire désobligeant, illégal, publicitaire, agressif, mal écrit ou tout simplement ennuyeux sera cruellement supprimé sans préavis, sans explication et sans excuse par le dictateur autoproclamé actuellement au pouvoir.

  Sur le même thème