PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV Mobile 22 → WM 22 et Proguard Obfuscation
WM 22 et Proguard Obfuscation
Débuté par Jean-Philippe DEGLET, 04 mar. 2017 17:04 - 72 réponses
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 04 mars 2017 - 17:04
Bonjour,

Je déterre le sujet depuis le forum US car une APK WM se décompile très facilement en ligne et gratuitement.
Et le code décompilé est suffisamment clair pour être compréhensible !!!

Exemple :

WLangage :

Procedure setNationAPK(int_nation)
ToastAffiche("Sortie/Relance requises",toastLong,cvHaut)
Nation(int_nation)
vrsettings.CodeNation = int_nation
HLitRecherche(vrlanguage,CodeNation,vrsettings.CodeNation)
vrsettings.CodeISO = vrlanguage.CodeISO
SI HModifie(vrsettings) = Faux ALORS
Erreur(HErreurInfo)
FIN


Depuis l'APK décompilé

public static void fWD_setNationAPK(WDObjet wDObjet) {
WDCollProc.initExecProcGlobale("setNationAPK");
        try {
            WDAPIToast.toastAffiche(WDChaineMultilangue.getString("Sortie/Relance requises", "Exit/Restart required"), 1, 0);
            WDAPIVM_Commun.nation(wDObjet.getInt());
            WDAPIHF.getFichierSansCasseNiAccent("vrsettings").m3551a("codenation").setValeur(wDObjet);
            WDAPIHF.hLitRecherche(WDAPIHF.getFichierSansCasseNiAccent("vrlanguage"), WDAPIHF.getRubriqueSansCasseNiAccent("codenation"), WDAPIHF.getFichierSansCasseNiAccent("vrsettings").m3551a("codenation"));
            WDAPIHF.getFichierSansCasseNiAccent("vrsettings").m3551a("codeiso").setValeur(WDAPIHF.getFichierSansCasseNiAccent("vrlanguage").m3551a("codeiso"));
            if (WDAPIHF.hModifie(WDAPIHF.getFichierSansCasseNiAccent("vrsettings")).opEgal(false)) {
                WDAPIDialogue.erreur(WDAPIHF.hErreurInfo().getString());
            }
            WDCollProc.finExecProcGlobale();
        } catch (Throwable th) {
            WDCollProc.finExecProcGlobale();
        }
    }


Android SDK, Gradle permettent nativement d'activer Proguard...
De fait WM utilise Proguard en fonction des règles définies dans le fichier PRG.DAT

...
buildTypes {
debug {
zipAlignEnabled true
minifyEnabled true
proguardFile file('C:\\Program Files\\PC SOFT\\WINDEV Mobile 22\\Programmes\\FrameWork\\Android\\dep\\prg.dat')
        multiDexEnabled false
}
...


# NE PAS MODIFIER
-optimizations !code/simplification/arithmetic,!code/simplification/cast,!field/*,!class/merging/*,!code/allocation/variable,!class/unboxing/enum
-optimizationpasses 5
-allowaccessmodification
-dontpreverify
-dontobfuscate
-dontusemixedcaseclassnames
-dontskipnonpubliclibraryclasses
-dontwarn android.support.**
-ignorewarnings

-keepattributes *Annotation*
-keep public class com.google.vending.licensing.ILicensingService
-keep public class com.android.vending.licensing.ILicensingService
-keepclasseswithmembernames class * {
    native ;
}
-keepclassmembers public class * extends android.view.View {
   void set*(***);
   *** get*();
}
...


C'est à mon sens, loin d'être suffisant.

Alors comment faire mieux ???

--
Cdlt
JPhD
Message modifié, 04 mars 2017 - 17:05
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 06 mars 2017 - 08:08
Bonjour Jean-Philippe,

C'est affolant : je ne pensais pas qu'une appli APK puisse être aussi facilement décompilée et que le code soit si "lisible".

Est-ce que des valeurs en dur dans le code d'ini du projet sont aussi visibles ? Genre connexion à HFSQL ou genre mot de passe des fichiers ?

Par contre, je n'ai pas bien compris : est-ce que WM intègre automatiquement lors de la compilation des APK cette protection Proguard qui semble être une protection minima ?

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 06 mars 2017 - 10:16
François,

Hélas oui...

Proguard est intégré à Android/Gradle les options de "shrinke"/"opitmisation"/"obfuscation"... sont gérées par l'intermédiaire de fichiers qui décrivent les règles, sur quels éléments du code et comment les appliquer.

Pour WM22 ces règles sont décrites dans le fichier :
/PC SOFT/WINDEV Mobile 22/Programmes/Framework/Android/dep/prg.dat

Le sujet est complexe, je le découvre juste mais j'ai le sentiment que l'étape d'obfuscation n'est pas des mieux gérée par WM22.
cf. la ligne -dontobfuscate dans pgr.dat que j'ai bien entendu essayé de supprimer sans changement notable.
Option que je n'ai pas retrouvée dans le manuel proguard...
https://www.guardsquare.com/en/proguard/manual/examples#androidapplication

--
Cdlt
JPhD
Message modifié, 06 mars 2017 - 10:21
//hostimage.webdev.info/avatars/default.gif
Posté le 06 mars 2017 - 11:59
Bonjour Jean-philippe,

Des questions :

Le sujet est complexe, je le découvre juste mais j'ai le sentiment que
l'étape d'obfuscation n'est pas des mieux gérée par WM22.
cf. la ligne -dontobfuscate dans pgr.dat que j'ai bien entendu essayé


Comme il semble qu'il y ait des lignes positives et négatives dans le
fichier, as tu essayé de remplacer le -dontobfuscate par un -obfuscate ?

As tu bien supprimé toutes les options de debug dans windev mobile, et
activé l'optimisation de la taille de l'archive ?

As tu contacté le support ?

Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

A votre disposition : WXShowroom.com, WXReplication (open source) et
maintenant WXEDM (open source)

Plus d'information sur http://fabriceharari.com


de supprimer sans changement notable.
Option que je n'ai pas retrouvée dans le manuel proguard...
https://www.guardsquare.com/en/proguard/manual/examples…

--
Cdlt
JPhD
//hostimage.webdev.info/avatars/default.gif
Posté le 06 mars 2017 - 12:56
Bonjour

De l'obfuscation dépend La suppression des informations de débogage : nom des variables, numéro de lignes...

Pour une obfuscation maximum tu reçois un exception java avec un numéro sans la moindre idée d'où cela provient, pas très pratique quand on sait qu'il existe des différences de comportement entre le simulateur et la machine, bonjour pour trouver le bug qui ne se produit que sur le terminal

En ce qui me concerne je préfère comme cela, de toute façon mon code critique ne se trouveras jamais dans du code mobile

Bon dev

Marc Fastré
www.marc-fastre.be
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 06 mars 2017 - 13:47
Fabrice, Marc,

Merci de votre intérêt,

"Comme il semble qu'il y ait des lignes positives et négatives dans le
fichier, as tu essayé de remplacer le -dontobfuscate par un -obfuscate ?"
-> c'est une idée que je vais suivre.

Qu PC-SOFT, sois pro-actif et documente un peu mieux, le possible et l'impossible, ne me paraît pas déplacé.
d'autant que j'avais posé la question avant d'acheter avec comme réponse :

Bonjour Monsieur DEG...,
- vous pourrez tout à fait vous connecter à des bases externes depuis une application WINDEV JAVA :
http://doc.pcsoft.fr/fr-FR/?9000008
- Oui le code publié n'est pas en clair (il est très difficile à comprendre, de plus toutes la aprties framework WINDEV pour Java n'est pas accessible).


"As tu bien supprimé toutes les options de debug dans windev mobile..."
Où ?
- car à part ne pas définir les permissions "android.SET_DEBUG_APP", je ne sais pas !

"...et activé l'optimisation de la taille de l'archive ?"
- Oui,
-> "Réduire la taille du code généré"... ce qui d'ailleurs est réalisé par Proguard normalement.

"Contacter le support"
-> A faire il me reste.

--
Cdlt
JPhD
Message modifié, 06 mars 2017 - 13:49
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 06 mars 2017 - 14:18
Alors

-obfuscate ne fonctionne pas :

Warning: Exception while processing task java.io.IOException: proguard.ParseException: Unknown option '-obfuscate' in line 6 of file 'C:\Program Files\PC SOFT\WINDEV Mobile 22\Programmes\Framework\Android\dep\prg.dat'
:transformClassesAndResourcesWithProguardForRelease FAILED

Ce qui confirme l'utilisation du fichier prg.dat comme règles pour Proguard.

Reste la question à PCSOFT ;)

--
Cdlt
JPhD
Message modifié, 06 mars 2017 - 14:19
//hostimage.webdev.info/avatars/8i5HR9oaon42PYbUDRCg
Membre enregistré
460 messages
Popularité : +6 (6 votes)
Posté le 06 mars 2017 - 16:29
bonjour,

voici le lien pour l'option -dontobfuscate

https://www.guardsquare.com/en/proguard/manual/usage#obfuscationoptions
-dontobfuscate
Specifies not to obfuscate the input class files. By default, obfuscation is applied; classes and class members receive new short random names, except for the ones listed by the various -keep options. Internal attributes that are useful for debugging, such as source files names, variable names, and line numbers are removed.


je n'ai pas WM22 malheureusement, je ne vais pas beaucoup vous aider plus....
mais pour moi il suffirait de supprimer la ligne et ne pas la remplacer par -obfuscate
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 06 mars 2017 - 17:17
Merci Christophe,

J'ai essayé sans la ligne -dontobfuscate dés le 4 pour ne constater aucune influence, d'où remise en état de mon prg.dat,
c'est d'ailleurs ce qui a motivé ma réponse de 10:16.

J'ai ouvert une question au support technique.

--
Cdlt
JPhD
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 06 mars 2017 - 21:15
Le support m'a répondu de cocher "Configuration/Réduire la taille du code généré"
ce que j'ai fait bien avant d'écrire ici et là-bas.

Leur réponse ne tient même pas compte que dans prg.dat, l'option -dontobfuscate est définie par défaut.

--
Cdlt
JPhD
Message modifié, 06 mars 2017 - 21:15
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 07 mars 2017 - 17:51
Bonjour Jean-Philippe,

J'ai créé un projet bidon avec des variables globales, un hpasse() et une connexion à une base de données HFSQL C/S

Je l'ai compilé en apk puis j'ai soumis cet apk à http://www.javadecompilers.com en vue de sa décompilation.

J'ai exploré un peu l'arborescence des résultats mais sans trouver aucune variable de mon code source (ouf)

Ou faut-il chercher?
PS : impossible d'uploader une image jpg de 20ko !

J'ai des dossiers après décompilation: lib com android res original fr

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 07 mars 2017 - 18:15
Bonjour François,

Intéressant ton constat,

Je génère mon APK avec "Configuration avancée/Réduire la taille du code généré"

Puis je la décompile avec
http://www.javadecompilers.com/ avec l'APK Decompiler (menu à droite)
Après l'upload et la décompilation.

je vais voir dans dans l'arborescence qui correspond à mon nom de package à la génération Android
{nom.APK}>com>{nom}>WDGEN>
et là je trouve tout le code de mes fenêtres, procédures globales... tel que j'en ai recopié quelques lignes au début de ce post.

--
Cdlt
JPhD
Message modifié, 07 mars 2017 - 18:43
//hostimage.webdev.info/avatars/384GgB4ahdbQbxdRHXazQ
Membre enregistré
640 messages
Popularité : +13 (13 votes)
Posté le 08 mars 2017 - 00:34
hello,
voici quelques infos sur proguard et sur le fait qu'il n'encrypte pas les chaînes constantes :

Pour l'option -dontofuscate il faut enlever l'option pour qu'elle n'agisse plus mais attention en première ligne du fichier prg.dat c'est écrit : # NE PAS MODIFIER . Il pourrait y avoir alors des soucis avec son programme android.
Voici par exemple sur un bout de code la différence entre une compilation avec -dontobfuscate :
PUBLIC class GWDPEXPRESS_ListerAppli extends WDProjet {
PUBLIC static GWDPEXPRESS_ListerAppli ms_Project;
PUBLIC GWDFEXPRESS_LISTE_APPLI mWD_EXPRESS_LISTE_APPLI;

/* renamed from: com.masociete.express_listeApplis.wdgen.GWDPEXPRESS_ListerAppli.1 */
static /* synthetic */ class C01121 {
static final /* synthetic */ int[] $SwitchMap$fr$pcsoft$wdjava$core$application$EWDInfoPlateforme;

static {
$SwitchMap$fr$pcsoft$wdjava$core$application$EWDInfoPlateforme = new int[EWDInfoPlateforme.values().length];
try {
$SwitchMap$fr$pcsoft$wdjava$core$application$EWDInfoPlateforme[EWDInfoPlateforme.DPI_ECRAN.ordinal()] = 1;
} catch (NoSuchFieldError e) {
}

et en enlevant -dontobfuscate dans prg.dat
PUBLIC class GWDPEXPRESS_ListerAppli extends WDProjet {
PUBLIC static GWDPEXPRESS_ListerAppli f1930a;
PUBLIC GWDFEXPRESS_LISTE_APPLI mWD_EXPRESS_LISTE_APPLI;

/* renamed from: com.masociete.express_listeApplis.wdgen.GWDPEXPRESS_ListerAppli.1 */
/* synthetic */ class C03421 {
static final /* synthetic */ int[] f1883a;

static {
f1883a = new int[EWDInfoPlateforme.values().length];
try {
f1883a[EWDInfoPlateforme.DPI_ECRAN.ordinal()] = 1;
} catch (NoSuchFieldError e) {}

on peut voir que le nom des variables n'est plus explicite.


What is ProGuard?

ProGuard is a utility provided by Android to:

Optimize our APK.
Eliminate references to a code which is not used.
Obfuscate code (useful to prevent reverse engineering attacks).
Reduce the APK size.


Could a string be hidden so it is not seen when decompiling?

If you want to hide some key or url that has “hardcode” in the code, ProGuard will not hide it when obfuscating the code since it only changes names of attributes and classes, but not values.

A way of hiding sensitive information is consequently to use cryptography in the source code for keys, urls, etc.

Anyway, the best way to hide them from possible attacks of reverse engineering would be to store this information in a server and query it through a secure connection when needed from the application.


Conclusion

ProGuard helps us keep some things “hidden” and to make things a bit tougher for those willing to get data from our code. It is also very useful to reduce the number of classes and methods of the application and, thereby, to reduce the size of the APK generated. However, it is not an ultimate solution to hide sensitive data and should that be the case, we would have a more elaborated solution.



En conclusion donc Proguard n'est pas suffisant pour dissimuler seul des données sensibles incluses dans un APK si celles-ci sont à la source écrites en clair dans des chaînes.

--
Ami calmant, J.P
Message modifié, 08 mars 2017 - 01:08
//hostimage.webdev.info/avatars/default.gif
Posté le 08 mars 2017 - 09:13
Bonjour,

ce sujet m’intéresse aussi, moi qui pensais que l'apk était impossible a décompiler,
j'ai essayé de decompiler mon apk wm21 résultat on peut tout voir en clair comme dans windev,
j'ai aussi essayé avec une appli android (fait avec android studio), pareil, tout est en clair, les classes, le code ...

il n'y a vraiment pas un moyen d'encrypter les fichiers ou autre ? sinon ça pose d’énorme problèmes ...
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 08 mars 2017 - 17:01
TESTS EN VERSION 21

Bonjour,

Les failles de sécurité sont ABYSSALES !

J'ai généré un APK sans aucune option de compilation:
Avec la procédure indiquée par Jean-Philippe,

les variables d'ini sont visibles, mot de passe des fichiers, toutes les coordonnées EN CLAIR pour accéder à une base HFSQL C/S !

WDAPIHF.hPasse(new WDChaineU("*"), "11v2c1%Q");
vWD_MaConnexion.setUtilisateur("Adminss");
vWD_MaConnexion.setMotDePasse(new WDChaineU("df56w4s52q154s1xL"));
vWD_MaConnexion.setServeur("178.18.10.45705");
vWD_MaConnexion.setBaseDeDonnees("CONTSSD");
vWD_MaConnexion.setProvider("WinDevClientServeurHF");
vWD_MaConnexion.setAcces(3);


Les variables globales d'une page sont VISIBLES:
GWDPtestdecompilation.vWD_CHALIMENTEELOCALE.setValeur("essaipourtesterlad\u00e9compilation");

Faut-il modifier certaines options de compilation ????

Oui les problèmes ne sont pas seulement énormes, mais rendent la diffusion d'applications compilées pour ANDROID tout simplement impossible avec de telles failles de sécurité !

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 08 mars 2017 - 17:11
J'ai adressé un Email à Monsieur AERTS.
je pense qu'il faudrait ouvrir un nouveau post avec un titre plus lisible comme "Failles de sécurité des .apk ANDROID"

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 08 mars 2017 - 17:23
Question : est-ce qu'un .apk déployé dans le Store peut aussi être décompilé ?

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/default.gif
Posté le 08 mars 2017 - 18:25
Bonjour,

Question : est-ce qu'un .apk déployé dans le Store peut aussi être
décompilé ?


A priori oui... il est donwloadé sur ton tel pour install, et sur un
téléphone rooté, tu y as donc accès

Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

A votre disposition : WXShowroom.com, WXReplication (open source) et
maintenant WXEDM (open source)

Plus d'information sur http://fabriceharari.com
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 08 mars 2017 - 18:35
François SCHAAL a écrit :
Question : est-ce qu'un .apk déployé dans le Store peut aussi être décompilé ?

--
Cordialement
François

http://intra.fr http://intrasoftware.fr


Alors j'ai fait un test,
1) extraction d'une APK depuis mon smartphone
=> j'ai donc installé APK Extractor depuis Google Play Store, gratuit...

2) J'ai lancé APK Extractor qui donne la liste de toutes les APK installées

3) Au hasard, j'ai "cliqué" Boussole (com.devuni.compass)
=> l'APK est mise à disposition dans le dossier ExtractedAPKS

Hop.... un coup de PC pour récupérer le package et le soumettre à la décompilation.

Un extrait du code décompilé
...
    protected void onPause() {
        this.f = false;
        com.devuni.compass.c.a aVar = this.b;
        aVar.d = false;
        if (aVar.c != null) {
            com.devuni.compass.c.d dVar = aVar.c;
            if (dVar.f != null) {
                dVar.f.a();
            }
            if (dVar.b) {
                dVar.b = false;
                if (dVar.a != null) {
                    dVar.a.a();
                }
                if (dVar.g != null) {
                    i iVar = dVar.g;
                    if (iVar.b != null && iVar.b.getChildCount() > 0) {
                        for (int i = 0; i < iVar.b.getChildCount(); i++) {
                            com.devuni.compass.c.g gVar = (com.devuni.compass.c.g) iVar.b.getChildAt(i);
                            if (gVar != null) {
                                gVar.a();
                            }
                        }
                    }
                }
            }
        }
        if (aVar.e != null) {
            com.devuni.compass.c.e eVar = aVar.e;
            if (eVar.d != null) {
                c cVar = eVar.d;
                if (cVar.d != null) {
                    b bVar = cVar.d;
                    if (bVar.b != null && bVar.b.g) {
                        bVar.b.d();
                    }
                    bVar.d = false;
                }
                cVar.e = false;
            }
        }
        if (aVar.b != null) {
            com.devuni.ads.b bVar2 = aVar.b;
            if (bVar2.e && bVar2.d != null && bVar2.d.b) {
                bVar2.d.g();
            }
            bVar2.g = false;
        }
        super.onPause();
    }
...


Ou l'obfuscation est bien plus opérationnelle, ou les développeurs ont fait un sacré de travail de "neutralisation" des noms de variables.

Donc, pour répondre
- Oui, toute APK, même issue du Play Store est extractible et décompilable
et
- Oui, une APK peut être moins "lisible" que celles générées par WM... dans quelles limites, je ne sais pas encore !

Enfin, le support m'a fait une nouvelle réponse cet AM :

"Bonjour Monsieur DEGLET,
Seul le nom des variables et le nom des commandes est obfusqué. Le contenu des chaînes est quant à lui en clair.
Vous pouvez crypter les mots de passe pour qu’'ils ne soient pas directement visibles. Ce n’est pas spécifique à WINDEV Mobile."

Je pense qu'ils sont en partie dans le vrai.
... et que leur fichier prg.dat est probablement perfectible pour améliorer l'illisibilité de nos productions.

Un homme averti en vaut deux.

--
Cdlt
JPhD
Message modifié, 08 mars 2017 - 18:39
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 08 mars 2017 - 19:12
Dans la même veine de l'APK Boussole,

Dans une partie du code, on trouve :

package com.millennialmedia;

import java.util.Date;

public class UserData {
    private static final String o;
    public Integer a;
    public Integer b;
    public Integer c;
    public String d;
    public String e;
    public String f;
    public String g;
    public String h;
    public String i;
    public String j;
    public Date k;
    public String l;
    public String m;
    public String n;

    public enum Education {
        HIGH_SCHOOL("highschool"),
        SOME_COLLEGE("somecollege"),
        ASSOCIATE("associate"),
        BACHELOR("bachelor"),
        MASTERS("masters"),
        PHD("phd"),
        PROFESSIONAL("professional");
        
        public final String value;

        private Education(String str) {
            this.value = str;
        }
    }

    public enum Ethnicity {
        HISPANIC("hispanic"),
        BLACK("africanamerican"),
        ASIAN("asian"),
        INDIAN("indian"),
        MIDDLE_EASTERN("middleeastern"),
        NATIVE_AMERICAN("nativeamerican"),
        PACIFIC_ISLANDER("pacificislander"),
        WHITE("white"),
        OTHER("other");
        
        public final String value;

        private Ethnicity(String str) {
            this.value = str;
        }
    }

    public enum Gender {
        MALE("M"),
        FEMALE("F"),
        UNKNOWN("O");
        
        public final String value;

        private Gender(String str) {
            this.value = str;
        }
    }

    public enum Marital {
        SINGLE("S"),
        MARRIED("M"),
        DIVORCED("D"),
        RELATIONSHIP("O");
        
        public final String value;

        private Marital(String str) {
            this.value = str;
        }
    }

    public enum Politics {
        REPUBLICAN("republican"),
        DEMOCRAT("democrat"),
        CONSERVATIVE("conservative"),
        MODERATE("moderate"),
        LIBERAL("liberal"),
        INDEPENDENT("independent"),
        OTHER("other");
        
        public final String value;

        private Politics(String str) {
            this.value = str;
        }
    }

    static {
        o = UserData.class.getName();
    }
}


Du simple code "leurre" de remplissage ou ??? en tout cas c'est du profilage...

--
Cdlt
JPhD
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 09 mars 2017 - 06:52
Bonjour,

Il faudrait pouvoir stocker quelques variables globales stratégiques dans un coffre-fort numérique au sein de l'application.

Le cryptage est possible mais si du code décompilé il est possible de déduire la méthode de cryptage et la clé de cryptage, je n'y crois guère...
Un fichier externe? Pas sûr non plus...

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/default.gif
Posté le 09 mars 2017 - 08:10
Je me suis renseigne et en fait tous code compile peut être decompile peut importe le langage,
donc la solution est d'obscurcir les nom des variables, fonctions .. etc soit manuellement soit avec proguard, ne pas stocker de données importante en clair c'est a dire ne pas faire ça :
MotDePasse est une chaîne = "MotdePasse"


si vous voulez plus d'infos pour sécuriser votre appli et que vous parlez anglais :
http://stackoverflow.com/questions/13854425/how-to-avoid-reverse-engineering-of-an-apk-file
//hostimage.webdev.info/avatars/384GgB4ahdbQbxdRHXazQ
Membre enregistré
640 messages
Popularité : +13 (13 votes)
Posté le 09 mars 2017 - 08:22
hello,
une méthode peut-être possible ( à approfondir) c'est d'utiliser une bibliothèque de cryptage JAVA en AES pour crypter les chaînes sensibles du programme et comme clé et/ou vecteur, d'utiliser la clé de signature de l'APK ou un autre paramètre unique propre à l' APK (par lecture par code pas en "dur") . Si quelqu'un tente de décompiler le code et de le rejouer pour décrypter les chaînes cryptées, Cela risque de ne pas fonctionner.
Sinon il y a des solutions payantes comme DexProtector.

--
Ami calmant, J.P
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 09 mars 2017 - 08:50
Bonjour Jurassic Pork,

Une solution payante comme DexProtector est-elle compatible avec un APK généré par WB ?

Est-ce qu'il suffirait par exemple de traiter avec cette solution le fichier APK généré avant sa distribution dans un store ou autre ?

Merci pour ta réponse parce que je pensais qu'il n'y avait aucune ouverture à ce problème !

Je reviens sur un post précédent avec une réponse du ST:

"Seul le nom des variables et le nom des commandes est obfusqué. Le contenu des chaînes est quant à lui en clair.
Vous pouvez crypter les mots de passe pour qu’'ils ne soient pas directement visibles. Ce n’est pas spécifique à WINDEV Mobile."

Mes essais:
Code d'ini du projet:
MaConnexion..Utilisateur = "Adminss" est visible en décompilation : vWD_MaConnexion.setUtilisateur("Adminss");

Une chaine d'une procédure locale d'une fenêtre:
CHALIMENTEELOCALE = "essaipourtesterladécompilation" est visible en décompilation : GWDPtestdecompilation.vWD_CHALIMENTEELOCALE.setValeur("essaipourtesterlad\u00e9compilation");

Conclusion : à mon avis le nom des variables n'est EN AUCUN CAS obfusqué !

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 09 mars 2017 - 09:16
DexProtector est une solution... C'est 250$ à l'année ou 750$ la licence par poste de dev.

Comme je l'ai écrit au ST :
"Je remarque que dans votre fichier prg.dat, l'option –dontobfuscate empêche de toute façon une obfuscation même basique…
D'emblée, j'imagine que votre prg.dat est perfectible pour améliorer l'illisibilité de nos productions avant de nous tourner vers des outils d'obfuscation plus élaborés et payants comme "Dexguard/DexProtector"."

--
Cdlt
JPhD
Message modifié, 09 mars 2017 - 09:18
//hostimage.webdev.info/avatars/384GgB4ahdbQbxdRHXazQ
Membre enregistré
640 messages
Popularité : +13 (13 votes)
Posté le 09 mars 2017 - 09:41
hello François,
regarde mon Post #13 et la partie sur dontobfuscate pour voir que sans cette option dans le prg.dat, les noms de variables ne sont plus en clair mais PCSOFT a mis en première ligne du fichier prg.dat #NE PAS MODIFIER. Question à poser à PCSOFT Y-a-t-il des risques si on enlève l'option -dontobfuscate du fichier prg.dat.

--
Ami calmant, J.P
Message modifié, 09 mars 2017 - 09:41
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 09 mars 2017 - 11:17
Pour infos,
Mon prg.dat est sans cette ligne depuis plusieurs jours...
Les différences que j'ai observées sont minimes et pour l'instant la génération/installation de l'APK n'est pas pertubée.

--
Cdlt
JPhD
//hostimage.webdev.info/avatars/7vyeEOvcSiMztCstu48ntg
Membre enregistré
31 messages
Posté le 09 mars 2017 - 12:02
Bonjour,

Le code généré par WINDEV Mobile pour Android n’est pas obfusqué. Il n’est pas ailleurs pas possible dans sa version actuelle d’obfusquer ce code sans risquer des erreurs d’exécution dans votre application.
Un des cas qui empêche cette obfuscation est par exemple lorsque vous utilisez des indirections, l’obfuscation ne traitera pas la chaîne utilisée et la procédure ne sera pas trouvée.

Il ne faut donc pas supprimer la ligne qui empêche l’obfucation du code dans le fichier prg.dat.

Notez que la très grande majorité des applications Android n’utilise pas de code obfuqué.
Je vous conseille par contre de crypter vos mots de passe dans votre code. Ce sera d’ailleurs l’un des sujets du prochain TDF.

--
Loïc HAMEL (Twitter : @HAMELLoic)
Support Technique PC SOFT
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 09 mars 2017 - 12:15
Et la suite de la réponse du Support par email :

"...Il n’est pas non plus possible d’utiliser des solutions payantes pour obfusquer ce code.
Le sujet sera traité lors du prochain TDF..."

Ceci écrit, l'intelligence d'une APK n'est pas seulement dans ses logins/mot de passe mais aussi dans l'algorithmique.

Vivement le prochain TDF et sa LST !
--
Cdlt
JPhD
Message modifié, 09 mars 2017 - 12:16
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 09 mars 2017 - 14:30
Merci Jean-Philippe pour ta réponse et à Monsieur HAMEL. Tout est clarifié mais sans solution !

Je pense que nous avons tous dans nos applications l'obligation de masquer le contenu d'une ou plusieurs variables globales (références de Webservices , connexion HFSQL C/S; pages AWP qui fonctionnent comme un Webservice, ...).
Maintenant comment procéder ?

Je vais tester cela à l'occasion : le décryptage avec une clé de cryptage d'une chaîne cryptée avec une des méthodes de cryptage/décryptage..

Qu'est ce qui sera visible dans la décompilation ? Si tout y est visible (ce que je crains), c'est sans fin...

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 09 mars 2017 - 15:57
Rebonjour,

Une idée intéressante suite à ma discussion téléphonique avec Monsieur AERTS : ne mentionner en dur dans l'appli aucune variable du type:

MotDePasse est une chaîne = "MotdePasse" (totalement visible à la décompilation)

Lors du lancement, exécuter une requête http qui va envoyer tout le contenu des variables globales vers l'utilisateur, de préférence de manière cryptée.

Ces informations brutes peuvent être stockées à l'identique dans un fichier local. Et être lues lors de chaque lancement de l'application.

Avec cette idée, la valeur des variables globales est invisible à la décompilation. On va juste voir une adresse http:...
Je vous laisse réfléchir à cette solution qui me semble très subtile.

Maintenant je me pose une question simple : ce fichier ne peut il pas être présent dès l'installation de l'APK sur le terminal ?

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 10 mars 2017 - 07:27
Bonjour,

"Maintenant je me pose une question simple : ce fichier ne peut il pas être présent dès l'installation de l'APK sur le terminal ?"

Une possibilité évoquée sans réfléchir parce que avec ce fichier présent dans l'apk, il est possible d'en rechercher le contenu des variables. L'idéal est de le créer lors du lancement, après téléchargement. Ce fichier avec le contenu des variables se trouve alors dans un dossier à mon avis non accessible de xxx.com

Autre idée mais pas pratique : ne plus utiliser de noms de variables explicites mais des noms genre les alias dans Webdev A10, A11,..
Si base HFSQL locale, idem pour les noms de fichiers et de rubriques.

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 10 mars 2017 - 11:29
Bonjour,

De mes investigations, en mode obfuscation (contre la recommandation de PCSOFT !!!)

Code JAVA Natif
PUBLIC static string getDeviceLanguage(){
string devicelanguage;
devicelanguage = Locale.getDefault().getLanguage();
RETURN devicelanguage;
}


Décompilation
public static String c() {
        return Locale.getDefault().getLanguage();
    }


Code WL Natif
Procedure set_Settings()
EcranVersFichier(FEN_Settings, vrsettings)
SI HModifie(vrsettings) = Faux ALORS
Erreur(HErreurInfo)
FIN


Décompilation
public static void fWD_set_Settings() {
        WDCollProc.initExecProcGlobale("set_Settings");
        try {
            WDAPIFenetre_Commun.ecranVersFichier(GWDPVR_Guide_SQLite.a.mWD_FEN_Settings, WDAPIHF.getFichierSansCasseNiAccent("vrsettings"));
            if (WDAPIHF.hModifie(WDAPIHF.getFichierSansCasseNiAccent("vrsettings")).opEgal(false)) {
                WDAPIDialogue.erreur(WDAPIHF.hErreurInfo().getString());
            }
            WDCollProc.finExecProcGlobale();
        } catch (Throwable th) {
            WDCollProc.finExecProcGlobale();
        }
    }


L'optimisation de code est réalisée (cf. getDeviceLanguage)
L'obsucation des noms de Procédures/Fonctions semble appliquée sur le code natif JAVA mais pas sur le natif WL.

La décompilation d'une APK permet de tout retrouver y compris tous les fichiers de données embarqués.
La cryptage de ces fichiers de données me paraient plus que recommandable.

Le choix de la localisation de ces fichiers de données sur le device est effectivement important et facteur de complexité
pour de la rétro-ingénierie mais un device "rooté" ne cachera pas grand-chose.

Tant que le code est assez trop simplement lisible, la logique des traitements est facilement re-modélisable.

--
Cdlt
JPhD
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 10 mars 2017 - 15:55
"Tant que le code est assez trop simplement lisible, la logique des traitements est facilement re-modélisable.

--
Cdlt
JPhD"

100% d'accord avec toi : est-ce que les applis ne pourraient pas être compilées avec ce mode d'obfuscation par défaut ?

Autre problème avec les chaines cryptées (ou fichiers) : comment conserver invisible (dans le code ou dans les traitements un moment donné) la clé de cryptage/décryptage ?

Je cogite la dessus...
Si quelqu'un trouve une idée géniale !

--
Cordialement
François

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/default.gif
Posté le 10 mars 2017 - 19:02
Bonjour

une technique usuelle pour les clés/mots de passe est de les encrypter
avec un utilitaire et de les stocker encryptées...

Dans le programme à protéger, on fait une SERIE d'opération de
décryptages les unes après les autres pour décrypter la clé/mot de passe
à la volée et l"utiliser.

De cette manière, rien n'est en clair dans le source, mais bien sur, ca
reste démontable...

Avec l'astuce de récupérer un fichiers encrypté lors de la première
activation du programme, on peut se servir de ces données externes pour
faire tout ou partie des opérations en question.

A ce stade la, ca veut dire que pour lire le contenu, il faut récupérer
l'apk, le fichier de données encryptées, puis analyser l'apk décompilé
pour refaire les opérations en question par programmation pour retrouver
les mots de passes/clés...

Ca reste possible, mais ca devient plus compliqué...

Si en plus on utiliser des clés/mots de passe différents pour CHAQUE
UTILISATEUR, ce qui est très possible en passant par un webservice, on
augmente à chaque fois la difficulté à craquer les données.

Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

A votre disposition : WXShowroom.com, WXReplication (open source) et
maintenant WXEDM (open source)

Plus d'information sur http://fabriceharari.com


Le 3/10/2017 à 9:55 AM, "ÿÿÿÿÿÿÿÿÿÿ" a écrit :
"Tant que le code est assez trop simplement lisible, la logique des
traitements est facilement re-modélisable.

--
Cdlt
JPhD"

100% d'accord avec toi : est-ce que les applis ne pourraient pas être
compilées avec ce mode d'obfuscation par défaut ?

Autre problème avec les chaines cryptées (ou fichiers) : comment
conserver invisible (dans le code ou dans les traitements un moment
donné) la clé de cryptage/décryptage ?

Je cogite la dessus...
Si quelqu'un trouve une idée géniale !

--
Cordialement
François

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 11 mars 2017 - 08:11
Bonjour Fabrice et merci pour tes idées...

La problématique est celui de la décompilation des APK parce que tout spécialiste de Windev mobile à partir d'un APK va retrouver les méthodes et pouvoir les reproduire (voir messages plus haut).

J'avais pensé intégrer le mot de passe non en dur mais dans une chaine téléchargée par exemple par une requête http (awp).

Mais dans ce cas, si dans ma méthode cette clé est par exemple celle des 10 derniers caractères, il sera possible de retrouver toutes les informations même cryptées pour se connecter à une base HFSQL C/S ou des adresses URL pour passer des paramètres en Webservice à partir de l'analyse des méthodes de l'APK décompilé.

Si on utilise un Webservice dont l'adresse sera connue ou obtenue par décompilation et analyse de la méthode, aucune donnée ne restera secrète.


Quand une application en Windev Mobile utilise une base de données, il faut que l'adresse URL de passage de paramètres ou les identifiants de connexion ou autres (webservices) soient totalement VEROUILLES.

Bref je cogite toujours...
Lundi je vais adresser un email à Monsieur Loïc HAMEL.

Si une solution est présentée au TDF, tant mieux mais intellectuellement parlant je ne vois pas...

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/384GgB4ahdbQbxdRHXazQ
Membre enregistré
640 messages
Popularité : +13 (13 votes)
Posté le 11 mars 2017 - 11:11
hello,
voici une solution possible qui rend plus difficile la découverte des données sensibles dans un APK . Le problème c'est que si on encode une chaîne avec une certaine méthode avec comme paramètre une clé, il faudra utiliser cette clé pour pouvoir décoder cette chaîne dans cette appli. Si quelqu'un décompile le programme et rejoue la partie décodage de la chaîne, il pourra capturer la clé utilisée pour le décodage.
Pour que cela soit plus difficile, il faut utiliser une clé qui dépende par exemple de la signature de l'apk. Ainsi si quelqu'un décompile le programme et le rejoue, il n'aura pas pas la même signature que l'application originale et donc la clé de décodage ne sera pas bonne.
Voici en gros comment faire (sans préciser le code des fonctions utilisées dans la classe Brouilleur pour que cela reste secret ).
1 - génération des mots de passes cryptés à partir d'une clé dépendant de la signature et utilisant un algorithme de type AES.
ckey = Brouilleur.getGS(info);
            String MdPCrypt1 = Brouilleur.ecks(ckey,"Vecteur1","MonMotDePasse1");
            String MdPCrypt2 = Brouilleur.ecks(ckey,"Vecteur2","MonMotDePasse2");
            String MdPCrypt3 = Brouilleur.ecks(ckey,"Vecteur3","MonMotDePasse3");


et dans le code de son application la partie décodage :
ckey = Brouilleur.getGS(info);
           MdPCrypt1 = "NWJ7mQvaoyj6yfazzxjygw==";
           MdPCrypt2 = "4JqrRj1DDMk+3MuO8ZcxVg==";
            MdPCrypt3 = "C1fxHnI0UJb2pzs6rn8XBA==";
     String MdPDecrypt1 = Brouilleur.dcks(ckey,"Vecteur1",MdPCrypt1);
     String MdPDecrypt2 = Brouilleur.dcks(ckey,"Vecteur2",MdPCrypt2);
     String MdPDecrypt3 = Brouilleur.dcks(ckey,"Vecteur3",MdPCrypt3);


Quand j'exécute le code avec une signature égale à celle qui a générée les mots de passes cryptés, je retrouve bien mes mots de passe originaux. Avec une autre signature, les mots de passe décryptés sont égaux à null.

--
Ami calmant, J.P
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 11 mars 2017 - 13:35
Bonjour Ami calmant,

Tu as parfaitement saisi la problématique. Mais comment assurer la confidentialité de ta procédure lors de la décompilation ?

Si les mots de passe sont générés lors de l'installation de l'appli, ils le seront aussi sur le système du hacker et rien ne semblera anormal.

Est ce que ton idée ne revient pas au même que de stocker une clé de décodage ?

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 11 mars 2017 - 16:48
Bonjour,

Au risque de paraître obtus,
dans du code interprété cela passe par de la "neutralisation" des noms des variables, des procédures, des fonctions et de leur paramètres.
ce qui est la raison d'être de l'obfuscation.

Que WM ne mette pas en oeuvre l'obfuscation, c'est un fait qui déjà me gène un peu, mais que l'on ne puisse même pas mettre en oeuvre des solutions plus performantes et payantes comme dexguard le cas échéant, cela me gène beaucoup (intellectuellement avant financièrement).

Alors là, après le cryptage, j'en suis à neutraliser les noms manuellement, c'est fastidieux et demande beaucoup de test de non-régression donc de maintenir au moins deux versions de code : une explicite - référente de l'algorithme et une neutralisée.

--
Cdlt
JPhD
Message modifié, 11 mars 2017 - 16:50
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 11 mars 2017 - 18:00
Bonjour,

Non Jean-Philippe, tu ne me sembles nullement obtus !

Comme je l'ai écris plus haut, il faudrait simplement que la génération par WM des APK se fasse avec l'obfuscation par défaut...

Est ce que l'obfuscation permet aussi de masquer non seulement le nom de variable mais aussi leur contenu "en dur" dans le code ?

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 11 mars 2017 - 18:07
François,

Proguard non, François SCHAAL a écrit :
Bonjour,

Non Jean-Philippe, tu ne me sembles nullement obtus !

Comme je l'ai écris plus haut, il faudrait simplement que la génération par WM des APK se fasse avec l'obfuscation par défaut...

Est ce que l'obfuscation permet aussi de masquer non seulement le nom de variable mais aussi leur contenu "en dur" dans le code ?

--
Cordialement
François

http://intra.fr http://intrasoftware.fr


Proguard non, il faut pouvoir mettre en oeuvre du Dexguard ou Dexprotector.

--
Cdlt
JPhD
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 14 mars 2017 - 08:08
Bonjour,

Un résumé de ma conversation d'hier avec Monsieur AERTS:

- les APK générés avec WM ne sont pas compatibles avec des solutions payantes d'obfuscation;
- aucune protection du code, du contenu des variables en dur, des idées et méthodes possible !
- pour accéder à HFSQL C/S, la seule solution est de passer par un Webservice dont l'adresse URL wsdl pourra toujours être connue et donc susceptible d'attaques...
- la seule solution serait celle de jetons avec nom et mot de passe.

Une bonne douche bien glaciale !

Je lui ai suggéré par Email un Webinaire sur le thème : Utilisation sécurisée des bases HFSQL C/S dans une appli pour Android...

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 14 mars 2017 - 09:23
Merci François.

C'est effectivement un ensemble de mauvaises réponses, surtout si même Dexguard ou Dexprotector sont impossibles.

--
Cdlt
JPhD
//hostimage.webdev.info/avatars/JoZL6B7ciZNOxcqTZ6uQ
Membre enregistré
19 messages
Posté le 15 mars 2017 - 03:40
Bonjour,

Comme le disait François, une bonne douche bien glaciale à 3h30!

J'étais sur le point d'acheter le couple WD/WM 22 mais, après lecture de ce post fort intéressant, j'ai décidé de repousser mon achat.
Comme quoi, la lecture des forums, peut aussi se révéler fort judicieuse pour nos investissements financiers!

Du coup, je peux retourner finir ma nuit ;(
//hostimage.webdev.info/avatars/3p2WFxJYv5QPx7d8CbHN5A
Membre enregistré
901 messages
Posté le 15 mars 2017 - 06:42
Bonjour,

Je pense aussi que la meilleure solution reste les jetons même si cela demande du dev, une fois que c'est fait c'est utilisable à volonté, et puis le jeton peut se baser sur l'id unique de l'appareil et bouge en permanence.

--
Cordialement,

Philippe SAINT-BERTIN
Géode Informatique
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 15 mars 2017 - 08:27
Bonjour,

La contribution de A-B est très intéressante :

Je me suis renseigne et en fait tous code compile peut être decompile peut importe le langage,
donc la solution est d'obscurcir les nom des variables, fonctions .. etc soit manuellement soit avec proguard, ne pas stocker de données importante en clair c'est a dire ne pas faire ça :
MotDePasse est une chaîne = "MotdePasse"
si vous voulez plus d'infos pour sécuriser votre appli et que vous parlez anglais :
http://stackoverflow.com/questions/13854425/how-to-avoid-reverse-engineering-of-an-apk-file


Dans l'article en lien, il est question de
"NDK (https://developer.android.com/ndk/index.html) to write them natively into .so files, which are much less likely to be decompiled than apks."
Et WM sait, à priori, incorporer et utiliser des librairies natives .so.

En amont, "anonymiser" les noms de variables, de procédures... faire manuellement le boulot de "proguard".
C'est sûr, le jeton est une bonne solution, pour les APK on-line.

--
Cdlt
JPhD
//hostimage.webdev.info/avatars/384GgB4ahdbQbxdRHXazQ
Membre enregistré
640 messages
Popularité : +13 (13 votes)
Posté le 15 mars 2017 - 11:53
hello,
ne pas oublier ma solution du post #37. Je ne peux pas l'essayer véritablement sous windev mobile car je n'ai que la version express où l'on ne peut pas signer l'apk avec sa signature propre mais avec android studio cela semble fonctionner et un non spécialiste de java ne saura pas comment reconstituer les chaînes cryptées facilement ( il faut utiliser des outils compliqués de "hackers")

--
Ami calmant, J.P
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 15 mars 2017 - 13:06
Jurassic Pork a écrit :
hello,
ne pas oublier ma solution du post #37. Je ne peux pas l'essayer véritablement sous windev mobile car je n'ai que la version express où l'on ne peut pas signer l'apk avec sa signature propre mais avec android studio cela semble fonctionner et un non spécialiste de java ne saura pas comment reconstituer les chaînes cryptées facilement ( il faut utiliser des outils compliqués de "hackers")

--
Ami calmant, J.P


Comme je n'ai pas trouvé de fonction WM pour lire les signatures d'une APK, je me suis tourné vers Java.
C'est une approche jouable.
Merci J.P

--
Cdlt
JPhD
//hostimage.webdev.info/avatars/default.gif
Posté le 15 mars 2017 - 15:05
Hi. It's posible a complete sample for WM? I can't found the API for use it.

Thank you

Rubén
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 15 mars 2017 - 15:37
So,

based on https://developer.android.com/reference/android/content/pm/PackageManager.html#GET_SIGNATURES
here a basic java function to get APK signatures from inside the APK :

import android.content.Context;
import android.content.pm.Signature;
import android.content.pm.PackageInfo;
import android.content.pm.PackageManager;
import android.content.pm.PackageManager.NameNotFoundException;

public static String getSignature()
{
Context context = getApplicationContext();
PackageManager pm = context.getPackageManager();
PackageInfo pi = null;
try {
pi = pm.getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNATURES);
} catch (NameNotFoundException e1) {
e1.printStackTrace();
}
Signature[] s = pi.signatures;

String sig = new String(s[0].toChars());
return sig;
}


--
Cdlt
JPhD
Message modifié, 15 mars 2017 - 15:41
//hostimage.webdev.info/avatars/default.gif
Posté le 15 mars 2017 - 17:47
Merci, Thank you, Gracias :merci:


Rubén
//hostimage.webdev.info/avatars/384GgB4ahdbQbxdRHXazQ
Membre enregistré
640 messages
Popularité : +13 (13 votes)
Posté le 17 mars 2017 - 08:43
hello,
le fichier prg.dat pour proguard dewindev mobile préserve la plupart des classes windev. Pourquoi ne pas inverser la condition de préservation, c'est à dire n'autoriser que certaines classes à être obfusquées. Voici un exemple du fichier prg.dat qui n'autorise que les classes qui sont dans les procédures globales java de windev mobile à être obfusquées par Proguard :
# PRG.DAT EXPERIMENTAL PAR J.P - NE PAS UTILISER EN PRODUCTION
-optimizations !code/simplification/arithmetic,!code/simplification/cast,!field/*,!class/merging/*,!code/allocation/variable,!class/unboxing/enum
-optimizationpasses 5
-allowaccessmodification
-dontpreverify
-dontusemixedcaseclassnames
-dontskipnonpubliclibraryclasses
-dontwarn android.support.**
-ignorewarnings

-keepattributes *Annotation*
-keep public class com.google.vending.licensing.ILicensingService
-keep public class com.android.vending.licensing.ILicensingService
-keep,allowshrinking class !com.masociete.express_listeApplis.wdgen.GWDCPProceduresJava { *; }


Le fichier prg.dat est beaucoup plus petit. C'est le ! qui inverse la condition. attention au allowshrinking, l'enlever si cela ne fonctionne pas. J'ai testé cela avec windev mobile 21 express, à vérifier que cela fonctionne avec une version commerciale.

exemple de bout de code que l'on peut lire après passage dans un décompiler :
public static String m198b(String str, String str2, String str3) {
        try {
            AlgorithmParameterSpec ivParameterSpec = new IvParameterSpec(C0064a.m203d(str2));


Il y a aussi une autre possibilité dans windev mobile , utiliser un jar externe obfusqué.

--
Ami calmant, J.P
Message modifié, 17 mars 2017 - 08:44
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 17 mars 2017 - 09:10
Cool ! que tu investigues,

...
-keep,allowshrinking class !com.masociete.express_listeApplis.wdgen.GWDCPProceduresJava { *; }
...


sous-entend de gérer le prg.dat pour chaque APK non ?

un jar externe obfusqué ou une librairie .so (NDK).

--
Cdlt
JPhD
Message modifié, 17 mars 2017 - 09:11
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 18 mars 2017 - 10:28
Bonjour à tous,

Après une période de doute et de découragement quelques idées:

n'utiliser que des webservices dans WM

lors du lancement de l'appli demander le nom et un mot de passe (dont la combinaison sera unique) à écrire dans un fichier local

accéder au webservice avec le guid du matériel + nom mémorisé + mot de passe mémorisé donc sans demande à l'utilisateur

créer un webservice avec deux fichiers : les utilisateurs et les Ip (WebserviceAdresseIPClient() )

Ce webservice ferait office de firewall et recherche ou envoie des informations par webservices ou requête awp vers des bases dans d'autres projets afin d'isoler tous ces autres projets et ses bases de l'utilisateur d'Android.

Le fichier des IP me permet de détecter des comportements anormaux.
En cas d'attaque sur le webservice avec création multiple de comptes utilisateurs, une procédure temporisée va détecter les comptes créés (non client) sans aucune opération et les supprimer. Bien sûr dans cette base tampon, il est important de travailler sur la date et heure système pour interagir et bloquer certains comportements.
Plutôt que d'importer le webservice dans l'appli android, étudier si on peut l'appeler autrement avec par exemple une adresse du type décrypte 'fkjdkfj', "lflsdf45514") non testé mais certainement possible...

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 18 mars 2017 - 10:31
PS : j'ai oublié de dire qu'avec un accès au webservice avec le guid du matériel + nom + mot de passe, toute tentative d'usurpation est quasiment impossible. Mais en cas de tentatives multiples depuis une même adresse IP, le webservice rejette l'utilisateur frauduleux.

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/default.gif
Posté le 19 mars 2017 - 13:08
Le 3/18/2017 à 4:31 AM, "ÿÿÿÿÿÿÿÿÿÿ" a écrit :
PS : j'ai oublié de dire qu'avec un accès au webservice avec le guid du
matériel + nom + mot de passe, toute tentative d'usurpation est
quasiment impossible. Mais en cas de tentatives multiples depuis une


Ben non... si on décompile l'appli et qu'on retrouve sa logique, il
suffit ensuite d'accéder au matériel d'un vrai client, de lui piquer les
infos en question, et hop...

même adresse IP, le webservice rejette l'utilisateur frauduleux.


Donc, sur un mobile, tu veux que l'utilisateur reste fixe sur la même
adresse IP...

Ca va faire une contrainte que peu d'utilisateurs peuvent accepter, ca...

J'ai fait un système de protection sur adresse IP pour un client il y a
quelques années. Chaque utilisateur avait une IP fixe (bureau) ou 2
(bureau+maison) autorisées...

Et quand un utilisateur se déplaçait, il devait contacter un superviseur
pour lui dire qu'il essayait de se connecter d'une autre IP et avoir
l'autorisation temporaire...

Faut avoir une sacré structure en place pour un truc comme ca.

Donc, plus sécurisé, oui, usurpation quasi impossible non... Tout dépend
du niveau d'importance des données.

Par principe pour qu'un système soit sécurisé réellement, il ne doit
jamais se connecter à un internet... Ce qui est l'antithèse de ce qu'on
essaye de faire avec des applis mobiles.

Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

A votre disposition : WXShowroom.com, WXReplication (open source) et
maintenant WXEDM (open source)

Plus d'information sur http://fabriceharari.com

//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 20 mars 2017 - 08:04
Bonjour Fabrice,

Je me demande si tu lis mes messages avant de répondre n'importe quoi...

je ne parlais nullement d'un système de protection par adresse Ip mais simplement de pouvoir détecter des comportements anormaux...
j'ai écrit :" Mais en cas de tentatives multiples depuis une même adresse IP, le webservice rejette l'utilisateur frauduleux."

"Ben non... si on décompile l'appli et qu'on retrouve sa logique, il
suffit ensuite d'accéder au matériel d'un vrai client, de lui piquer les
infos en question, et hop..."
ici c'est le cas où un smartphone est par exemple volé. dans ce cas l'utilisateur bloque normalement son abonnement mobile et c'est réglé !

L'espionnage à la 007 c'est un autre problème...
Moi je parlais d'une application grand public et non secret défense!

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 20 mars 2017 - 08:11
Et je ne parle pas du GUID qui dans mon exemple n'est pas mémorisé mais calculé dynamiquement lors du lancement de l'appli (par exemple)

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/default.gif
Posté le 20 mars 2017 - 13:43
Je lis tes messages... Mais tu n'as pas l'air de te relire... ou alors
tu crois qu'on va comprendre que tu veux dire autre chose que ce que tu
écris...


!!!QUASI IMPOSSIBLE!!! c'est comme ça que tu as qualifié la sécurité de
ton système alors qu'il fallait lire, d'après tes 2 derniers messages
"SUFFISANT POUR UNE APPLI GRAND PUBLIC"

Quand on parle de sécurité, la première chose à faire est d'être précis...

Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

A votre disposition : WXShowroom.com, WXReplication (open source) et
maintenant WXEDM (open source)

Plus d'information sur http://fabriceharari.com


Le 3/20/2017 à 2:11 AM, "ÿÿÿÿÿÿÿÿÿÿ" a écrit :
Et je ne parle pas du GUID qui dans mon exemple n'est pas mémorisé mais
calculé dynamiquement lors du lancement de l'appli (par exemple)

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 20 mars 2017 - 15:46
Ce que j'expliquai CLAIREMENT c'était que avec un webservice on pouvait par exemple détecter des agissements anormaux déclenchés par une même adresse IP comme la création à la volée de comptes utilisateurs fictifs.

"Le fichier des IP me permet de détecter des comportements anormaux."
et
" Mais en cas de tentatives multiples depuis une même adresse IP, le webservice rejette l'utilisateur frauduleux."

Ou est il écrit que j'intègre une autre protection d'après l'adresse Ip ?

Ma conception du forum est le partage des idées.

Et toi, qu'as tu apporté dans tes contributions?

N'hésites pas à faire profiter tous les membres du forum de ta grande expérience et expliques nous comment créer une appli APK sûre qui peut accéder à des bases HFSQL C/S sans danger avec la possible décompilation

PS : si tu as écris un APK pour un de tes clients et que tu l'as déployé dans le store de google et qu'il utilise des bases HFSQL C/S, n'hésites pas à me donner son nom.

Je le décompilerai et te donnerai mon avis sur ton code...

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 20 mars 2017 - 16:00
Bonjour

une autre piste à évaluer pour iOS (pas présente pour Android) serait l'exécution dynamique :

https://doc.pcsoft.fr/fr-FR/?3013015&name=compile_fonction&product=WM
https://doc.pcsoft.fr/fr-FR/?1000019783&name=executecode_fonction&product=WM

Par envoi du code sur requête.

--
Cdlt
JPhD
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 22 mars 2017 - 10:44
Bonjour,

Je reviens vers mon idée d'authentification pour utiliser un Webservice.

Avec la combinaison d'un GUID calculé dynamiquement lors du lancement de l'application et la combinaison d'un mot de passe et d'un nom ou pseudo.
Pour une application grand public, on ne va pas demander à chaque lancement le pseudo et le mot de passe donc il est possible de stocker ces variables dans un fichier local du Smartphone, ce que j'avais évoqué (mais assez clairement selon certains !)

Pour une application plus sensible, il faut le demander à l'utilisateur de saisir ces variables à chaque lancement de l'appli sans qu'elles ne soient stockées en local.

Dans le Webservice je contrôle alors la cohérence des éléments envoyés pour authentifier l'utilisateur: le GUID, le pseudo ou nom et le mot de passe enregistrés sur le serveur.

Bien malin celui qui peut comprendre le code par décompilation et retrouver sur un matériel B le GUID d'un matériel A et encore plus malin celui qui pourra combiner ce GUID avec un mot de passe et un pseudo saisis lors du lancement de l'appli et non présents en local !

Comme me l'avait indiqué Monsieur AERTS, l'idéal serait en Webservice en https mais là je ne sais pas faire.

Ce sont des idées que tous pourront enrichir ou critiquer...

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/xN6M7WIUNFYU0zwsWqKzQ
Membre enregistré
443 messages
Popularité : +1 (1 vote)
Posté le 22 mars 2017 - 11:01
Bonjour François,

Inconvénient de ta solution, c'est qu'il faut impérativement avoir une connexion "correcte" au démarrage de l'application.

--
Jean-Michel
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 22 mars 2017 - 11:16
Bonjour Jean-Michel,

c'est clair...

Tout dépend des applis : il existe des applis "autonomes" sans accès au réseau. Mon utilisation est plus celle d'applis qui se connectent ponctuellement à des Webserices donc qui interagissent avec des bases HFSQL C/S

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 27 mars 2017 - 15:02
Bonjour

Message de DexProtector:

"Hello François,
Thank you for your reply. This sounds very interesting. DexProtector is compatible with all the types of Android Applications (APKs). If you have any specific questions or concerns, kindly let me know. I will be happy to help.

--
Best regards,
I.K. Customer Advocate,
Licel Corporation"

Il existe une version de démonstration de 15 jours gratuites mais je n'ai pas eu le temps de tester.
Il se peut qu'effectivement certaines commandes en W-L posent problème (les indirections)...

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/default.gif
Posté le 18 juillet 2017 - 17:24
Bonjour,

Je relance le sujet, savoir si quelqu'un a du nouveau pour obfusquer un peu mieux la gestion des mdp. Je ne suis pas concerné directement par WM mais néanmoins je propose une suggestions si ça peut permettre d'avancer le sujet.

Même si le code apparait en clair, l'utilisation de la fonction compile() (qui exécuterais récursivement une procédure de décrypatge d'une autre chaine qui refait un appel à compile() qui décrypte une variable etc... jusqu'à repasser sur une variable locale d'une procédure ou autre de manière temporaire la clé privé, l'utiliser et enfin la détruire) ne permet-elle pas de rendre bien plus inaccessible les données et process sous-jacent ?

Ca ne règle pas à 100% le problème mais comme j'ai remarqué que la fonction compile() permet déjà du sortir du débogueur intégré de windev et que l'on ne voit plus vraiment ce qu'il se passe sauf en cas d'erreur et encore (2 compile() imbriqués et c'est fini). Je me plante peut-être mais j'aurais tenté ca, si quelqu'un peut voir le résultat sous WM (pas en ma possession)

Cordialement
DM
//hostimage.webdev.info/avatars/VD6DdII098urIaoK3mZWXw
Membre enregistré
991 messages
Popularité : +9 (11 votes)
Posté le 18 juillet 2017 - 19:00
Bonjour DM333,

Je n'utilise pas compile() et cette fonction ne semble pas disponible pour Android : https://doc.pcsoft.fr/?3013015

Si une clé est obtenue par l'appli, cette clé pourra toujours être obtenue à mon avis par reproduction des méthodes.

Si tu veux tester Windev Mobile, la version gratuite WM Express existe (en version 21 et non 22) ...

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
//hostimage.webdev.info/avatars/default.gif
Posté le 19 juillet 2017 - 09:47
Hmm, effectivement il y a toujours ces petites nuances qui casse les élans... Pas de solution miracle certainement, surement des solutions au cas par cas selon les postulats de votre application.

A voir s'il y a une autre façon d’exécuter du code à l'extérieur de l'application, façon "boite noir".

J'avais pensé aux requêtes stockées mais la aussi pas disponible chez Android.

Je connais mal les possibilités en Java/WM mais puisque Android est orienté java avec la possibilité d'écrire des procédures dans ce langage directement dans WM, pourquoi ne pas déporter une partie du code sensible dans un .jar (et dans ce cas pas de problème pour lui passer un coup de Proguard Obfuscation de votre coté, WM ne sera pas concerné) et ensuite appeler ce code depuis l'application principale ?
//hostimage.webdev.info/avatars/EzodTAKHNtkCPTNfBllKDg
Membre enregistré
56 messages
Posté le 24 juillet 2017 - 19:08
Bonjour,

je ne sais pas si j'ai le droit de poster des liens ici, je tente le coup.

J'ai créé une technique d'obfuscation basique, pour les mots de passe aux bases de données par exemple.

https://www.memepasmal.ch/2017/07/24/wd-obfuscate/

Cela n'empêche bien évidemment pas de se faire hacker le code, mais ça ralentira un peu ceux qui essaient.
//hostimage.webdev.info/avatars/3p2WFxJYv5QPx7d8CbHN5A
Membre enregistré
901 messages
Posté le 25 juillet 2017 - 09:40
Bonjour,

Je suis sur ce problème depuis 2 jours et je tourne dans tous les sens pour trouver la meilleure solution possible.

Avez vous essayer de passer par le keystore android ? Je suis en train de lire et essayer de comprendre le fonctionnement exact. Ca peut être une bonne solution pour le stockage de mots de passe.

Il suffirait à la première connexion de se connecter à un WS qui renverrait une clé aléatoire et la stocker dans le keystore. Elle n'est du coup pas compilée dans l'apk et donc plus visible à la décompilation.

Qu'en pensez-vous ?

--
Cordialement,

Philippe SAINT-BERTIN
Géode Informatique
//hostimage.webdev.info/avatars/default.gif
Posté le 30 juillet 2017 - 14:16
Bonjour,

Merci du tuyau pour le Keystore. A mon humble avis tout ce qui nécessite une connexion externe est à éviter pour le cas ou "pas de réseau" et l'interception des données via Wireshark, burp...

Cordialement
//hostimage.webdev.info/avatars/RrpZpplIAjR9ZZaAh1xcw
Membre enregistré
2 632 messages
Popularité : +89 (91 votes)
Posté le 12 août 2017 - 09:07
Bonjour,

links:

https://dexprotector.com/docs

https://github.com/dexprotector/DynamicApkProtection

https://dexprotector.com/buy

DEXPROTECTOR
STANDARD

$800
one computer license with one
year support and upgrades included

Licenciamento Padrão DexProtector

O DexProtector é licenciado por assento , ou seja, você precisa de uma licença separada para cada estação de trabalho de desenvolvedor e servidor de compilação.

A própria licença é perpétua e não tem limites para o número de aplicativos (suas instalações / usuários ativos, geografia), portanto, você pode proteger tantos aplicativos diferentes quanto necessário, com uma única licença.

As licenças padrão podem ser compradas por indivíduos e micro / pequenas empresas (menos de 10 funcionários, incluindo afiliados e organizações pai).

O DexProtector não pode ser utilizado em benefício de terceiros com licenças padrão , ou seja, proteção de software de terceiros, mesmo que tenha sido desenvolvido pela sua organização.

--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/
//hostimage.webdev.info/avatars/ypistE9M7Y25O4BOsyA6dQ
Membre enregistré
113 messages
Posté le 12 août 2017 - 10:57
BOLLER a écrit :
Bonjour,

links:

https://dexprotector.com/docs

https://github.com/dexprotector/DynamicApkProtection

https://dexprotector.com/buy

DEXPROTECTOR
STANDARD

$800
one computer license with one
year support and upgrades included

Licenciamento Padrão DexProtector

O DexProtector é licenciado por assento , ou seja, você precisa de uma licença separada para cada estação de trabalho de desenvolvedor e servidor de compilação.

A própria licença é perpétua e não tem limites para o número de aplicativos (suas instalações / usuários ativos, geografia), portanto, você pode proteger tantos aplicativos diferentes quanto necessário, com uma única licença.

As licenças padrão podem ser compradas por indivíduos e micro / pequenas empresas (menos de 10 funcionários, incluindo afiliados e organizações pai).

O DexProtector não pode ser utilizado em benefício de terceiros com licenças padrão , ou seja, proteção de software de terceiros, mesmo que tenha sido desenvolvido pela sua organização.

--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/


Many thanks Adriano.
For sure probably the best solution regarding 800$ per year.
- Do you used it?
- What is your APK price consideration for your customers?

--
Cdlt
JPhD