PC SOFT

GRUPOS DE DISCUSSÃO PROFISSIONAL
WINDEVWEBDEV e WINDEV Mobile

Inicio → WINDEV Mobile 2024 → WM 22 et Proguard Obfuscation
WM 22 et Proguard Obfuscation
Iniciado por Jean-Philippe DEGLET, mar., 04 2017 5:04 PM - 88 respostas
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 04 2017 - 5:04 PM
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
Mensagem modificada, março, 04 2017 - 5:05 PM
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 06 2017 - 8:08 AM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 06 2017 - 10:16 AM
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
Mensagem modificada, março, 06 2017 - 10:21 AM
Publicado em março, 06 2017 - 11:59 AM
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
Publicado em março, 06 2017 - 12:56 PM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 06 2017 - 1:47 PM
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
Mensagem modificada, março, 06 2017 - 1:49 PM
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 06 2017 - 2:18 PM
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
Mensagem modificada, março, 06 2017 - 2:19 PM
Membro registado
939 mensagems
Popularité : +66 (68 votes)
Publicado em março, 06 2017 - 4:29 PM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 06 2017 - 5:17 PM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 06 2017 - 9:15 PM
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
Mensagem modificada, março, 06 2017 - 9:15 PM
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 07 2017 - 5:51 PM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 07 2017 - 6:15 PM
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
Mensagem modificada, março, 07 2017 - 6:43 PM
Membro registado
962 mensagems
Popularité : +183 (185 votes)
Publicado em março, 08 2017 - 12:34 AM
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
Mensagem modificada, março, 08 2017 - 1:08 AM
Publicado em março, 08 2017 - 9:13 AM
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 ...
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 08 2017 - 5:01 PM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 08 2017 - 5:11 PM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 08 2017 - 5:23 PM
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
Publicado em março, 08 2017 - 6:25 PM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 08 2017 - 6:35 PM
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
Mensagem modificada, março, 08 2017 - 6:39 PM
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 08 2017 - 7:12 PM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 09 2017 - 6:52 AM
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
Publicado em março, 09 2017 - 8:10 AM
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
Membro registado
962 mensagems
Popularité : +183 (185 votes)
Publicado em março, 09 2017 - 8:22 AM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 09 2017 - 8:50 AM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 09 2017 - 9:16 AM
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
Mensagem modificada, março, 09 2017 - 9:18 AM
Membro registado
962 mensagems
Popularité : +183 (185 votes)
Publicado em março, 09 2017 - 9:41 AM
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
Mensagem modificada, março, 09 2017 - 9:41 AM
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 09 2017 - 11:17 AM
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
Membro registado
57 mensagems
Popularité : +17 (17 votes)
Publicado em março, 09 2017 - 12:02 PM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 09 2017 - 12:15 PM
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
Mensagem modificada, março, 09 2017 - 12:16 PM
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 09 2017 - 2:30 PM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 09 2017 - 3:57 PM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 10 2017 - 7:27 AM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 10 2017 - 11:29 AM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 10 2017 - 3:55 PM
"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
Publicado em março, 10 2017 - 7:02 PM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 11 2017 - 8:11 AM
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
Membro registado
962 mensagems
Popularité : +183 (185 votes)
Publicado em março, 11 2017 - 11:11 AM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 11 2017 - 1:35 PM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 11 2017 - 4:48 PM
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
Mensagem modificada, março, 11 2017 - 4:50 PM
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 11 2017 - 6:00 PM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 11 2017 - 6:07 PM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 14 2017 - 8:08 AM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 14 2017 - 9:23 AM
Merci François.

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

--
Cdlt
JPhD
Membro registado
19 mensagems
Popularité : +1 (1 vote)
Publicado em março, 15 2017 - 3:40 AM
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 ;(
Membro registado
2.566 mensagems
Popularité : +222 (260 votes)
Publicado em março, 15 2017 - 6:42 AM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 15 2017 - 8:27 AM
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
Membro registado
962 mensagems
Popularité : +183 (185 votes)
Publicado em março, 15 2017 - 11:53 AM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 15 2017 - 1:06 PM
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
Publicado em março, 15 2017 - 3:05 PM
Hi. It's posible a complete sample for WM? I can't found the API for use it.

Thank you

Rubén
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 15 2017 - 3:37 PM
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
Mensagem modificada, março, 15 2017 - 3:41 PM
Publicado em março, 15 2017 - 5:47 PM
Merci, Thank you, Gracias :merci:


Rubén
Membro registado
962 mensagems
Popularité : +183 (185 votes)
Publicado em março, 17 2017 - 8:43 AM
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
Mensagem modificada, março, 17 2017 - 8:44 AM
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 17 2017 - 9:10 AM
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
Mensagem modificada, março, 17 2017 - 9:11 AM
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 18 2017 - 10:28 AM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 18 2017 - 10:31 AM
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
Publicado em março, 19 2017 - 1:08 PM
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

Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 20 2017 - 8:04 AM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 20 2017 - 8:11 AM
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
Publicado em março, 20 2017 - 1:43 PM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 20 2017 - 3:46 PM
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
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em março, 20 2017 - 4:00 PM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 22 2017 - 10:44 AM
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
Membro registado
474 mensagems
Popularité : +17 (19 votes)
Publicado em março, 22 2017 - 11:01 AM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 22 2017 - 11:16 AM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em março, 27 2017 - 3:02 PM
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
Publicado em julho, 18 2017 - 5:24 PM
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
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em julho, 18 2017 - 7:00 PM
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
Publicado em julho, 19 2017 - 9:47 AM
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 ?
Membro registado
151 mensagems
Popularité : +7 (7 votes)
Publicado em julho, 24 2017 - 7:08 PM
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.
Membro registado
2.566 mensagems
Popularité : +222 (260 votes)
Publicado em julho, 25 2017 - 9:40 AM
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
Publicado em julho, 30 2017 - 2:16 PM
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
Membro registado
3.651 mensagems
Popularité : +175 (223 votes)
Publicado em agosto, 12 2017 - 9:07 AM
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/
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em agosto, 12 2017 - 10:57 AM
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
Membro registado
156 mensagems
Popularité : +3 (3 votes)
Publicado em agosto, 30 2017 - 12:31 PM
Ayant posé la question au support de PCSoft au sujet des Hpasse(), login/password des connexions FTPS, accès aux werbservices, etc ... qui apparaissent en clair à la décompilation, voici leur réponse :

"Nous vous confirmons le comportement observé. Ce n'est pas un problème propre à WINDEV MOBILE mais bien à tout les langages décompilables (Java, C#, C++ dans une moindre mesure). Vous ferriez un un projet en 100% natif JAVA vous auriez exactement le même problème.
La solution préconisée pour ce genre de cas est de ne pas stocker le mot de passe en clair dans le code mais par exemple de le découper (dans des constantes, dans des fichiers de ressources, dans des variables globales) et d'écrire un code qui permette de reconstruire ce mot de passe.
C'est point sur lequel il nous est donc impossible d'intervenir, nous le regrettons."

Je me demande donc à quoi sert donc l'option d'obfuscation du code de type Proguard (coche réduire la taille du code généré) si des informations sensibles restent en clair ? Je trouve cette façon de procéder un peu légère de la part de PCSoft qui ne met nulle part en garde les développeurs sur ce problème sensible, et qui ne propose pas de solutions pour que leurs applications WM ne soient pas de vraies passoires en terme de sécurité ...

François
Publicado em agosto, 30 2017 - 3:29 PM
L'obfuscation de code par Proguard masque "l'intelligence" du code et des algorithmes en renommant entre autres variables, classes et méthodes mais les chaines de caractères ne sont jamais modifiées.

+ il y a un article sur le sujet dans la LST 109
Membro registado
3.651 mensagems
Popularité : +175 (223 votes)
Publicado em agosto, 30 2017 - 5:25 PM
Dear Pokedev

Putting the password inside the apk is the same as putting the key from your front door of your house under the doormat to clean your feet. You hope he does not see that the key is right there on the outside.

The correct my friend is to send an email or sms after the registration and accepted the terms of the application, you send in the sequence the token, that you will use this value for this user as encryption key and unique decryption for him, simple like this, okay .


--

Colocar a senha dentro do apk é igual a colocar a chave da sua porta da frente da sua casa debaixo do capacho de limpar os pés. Voce torce para que ele nao veja que a chave está ali mesmo do lado de fora.

O Correto meu amigo é enviar um email ou sms apos o cadastro e aceite dos termos do aplicativo, voce manda na sequencia o token, que voce vai usar esse valor para esse usuario como chave de criptografia e descriptografia unico para ele, simples assim, ok.

--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/
Mensagem modificada, agosto, 30 2017 - 5:26 PM
Membro registado
156 mensagems
Popularité : +3 (3 votes)
Publicado em agosto, 30 2017 - 6:07 PM
Cher wddev,
En effet, c'est en lisant la LST 109 que je ne suis rendu compte de ce gros trou de sécurité dans les applis WM.
Et l'exemple de la LST est très enfantin, il est facile en décompilant le code de retrouver le mot de passe.
Je suis très surpris qu'à aucun moment PCSoft ne nous alerte pas en nous disant qu'en faisant en HOuvreConnexion, un Hpasse, un FTPConnect ... on diffuse avec une simple décompilation les identifiants d'accès aux bases de données, FTP, etc ...
C'est un peu grave quand même ? Non ???
Je n'étais pas habitué à cela avec Windev ou Webdev ...

François.
Membro registado
156 mensagems
Popularité : +3 (3 votes)
Publicado em agosto, 30 2017 - 6:10 PM
Chez José, je suis bien d'accord, mais c'est quand même un comble d'utiliser les outils de développement de PCSOFT et de constater des failles de sécurité aussi énormes !
C'est un comble de nous demander de faire du bidouillage pour masquer les paramètres des identifiants/passwords comme ceux que j'ai cité, non ?

François
Membro registado
2.566 mensagems
Popularité : +222 (260 votes)
Publicado em agosto, 31 2017 - 5:06 AM
François:
PC Soft n'est pas responsable de la possibilité de décompilation des apk. La techologie est ainsi faite. D'ailleurs si tu crées une appli en c#, tu as exactement les mêmes risques. Tu peux même débugger une application qui ne t'appartient pas pour voir comment elle fonctionne. Les failles de sécurité ne concernent pas les application WM mais toutes les applications Android.

C'est la raison pour laquelle il existe le keystore sur android.

PC Soft a des torts mais là-dessus on ne peut pas les blâmer. Si tu veux être mécontent, tu peux, mais dans ce cas précis c'est contre Google qu'il faut crier.

--
Cordialement,

Philippe SAINT-BERTIN
Géode Informatique
Membro registado
794 mensagems
Popularité : +40 (42 votes)
Publicado em agosto, 31 2017 - 4:58 PM
Hi.

Yes, Java apps are decompilable. For this reason tools like Basic4Android or Android Studio can offuscate the code to make more dificult the access to sensible data. For example, B4A offuscate the strings located at Global code level andwhen it doesn't include an undercore ("_") character.

Which is the reasons for WM can't offuscate code or string values?

Rubén
Membro registado
2.566 mensagems
Popularité : +222 (260 votes)
Publicado em setembro, 01 2017 - 6:36 AM
Hi,

Just because they are using Proguard and proguard is just obfuscating the names of classes, fields and methods (https://www.guardsquare.com/en/proguard)

--
Cordialement,

Philippe SAINT-BERTIN
Géode Informatique
Membro registado
2.566 mensagems
Popularité : +222 (260 votes)
Publicado em setembro, 01 2017 - 9:02 AM
Membro registado
794 mensagems
Popularité : +40 (42 votes)
Publicado em setembro, 01 2017 - 12:31 PM
Hi. All Android developers tools use Proguard by default. It's free. If WM use it maybe PCSoft could use it for define secure strings.

Could we use pay options to securize the apps like DexGuard or DexProtect or this tools will break the app?

Thsank you

Rubén
Membro registado
129 mensagems
Popularité : +5 (5 votes)
Publicado em setembro, 01 2017 - 1:44 PM
Rubén Sánchez Peña a écrit :
Hi. All Android developers tools use Proguard by default. It's free. If WM use it maybe PCSoft could use it for define secure strings.

Could we use pay options to securize the apps like DexGuard or DexProtect or this tools will break the app?

Thsank you

Rubén


Hi Rubén,

Regarding DexGuard or DexProtect I've asked to PCSoft support, in march:

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..."

They don't recommend ("it's impossible...") to use external solutions to obfuscate code.
The main reason should be "indirection".

--
Cdlt
JPhD
Mensagem modificada, setembro, 01 2017 - 1:45 PM
Membro registado
794 mensagems
Popularité : +40 (42 votes)
Publicado em setembro, 01 2017 - 6:56 PM
Thank you Jean-Philippe for your response. I can understand the string offuscation could affect to code generated for the applications like indirection, but then they could define a string format ready to offuscate like i can find in other other tools like B4A. In B4A the event procedure names include underscore, then when them offuscate the code exclude strings with underscore and only offuscate the strings defined at Global code.

Rubén
Publicado em setembro, 13 2017 - 10:43 AM
Bonjour la communauté,

J'ai une question un peu basique mais qui pourrait certainement être utile à tous:

Est ce que les commentaires qui commencent par // se retrouvent dans l'APK et peuvent alors être consultés après décompilation ?

un grand merci à celui ou celle qui me répondra :merci:

Thémis
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em setembro, 14 2017 - 11:04 AM
Bonjour Thémis,

J'ai fait un essai : les commentaires précédés par // ne se retrouvent pas dans l'APK et ne sont pas visibles après décompilation.

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
Membro registado
1.603 mensagems
Popularité : +64 (70 votes)
Publicado em outubro, 09 2017 - 11:54 AM
Nouveauté 764 de VM23
Bravo !

--
Cordialement
François

http://intra.fr http://intrasoftware.fr
Membro registado
156 mensagems
Popularité : +3 (3 votes)
Publicado em janeiro, 17 2018 - 12:01 AM
Bonjour,
Avez-vous testé cette nouveauté de la 23 ? C'est vraiment plus secure qu'avant ?
Cdt,
François