Question sur la sécurité sur un fichier EXE
DOUM555
Messages postés
7
Date d'inscription
Statut
Membre
Dernière intervention
-
fiddy Messages postés 11069 Date d'inscription Statut Contributeur Dernière intervention -
fiddy Messages postés 11069 Date d'inscription Statut Contributeur Dernière intervention -
Bonjour,
J'ai une petite question sur la sécurité sur un fichier EXE compilé avec VB6.
Si j'ai des mots de passe dans le code, est-ce que quelqu'un qui a accès seulement au EXE (pas aux sources) pourrait décompiler le code et ainsi voir le mot de passe?
Disons qu'il s'agit d'un projet sensible et qu'il faut que je travaille sur la sécurité de cette application. Je veux donc en savoir plus sur les possibles façon de voir le code compilé.
Merci
DL
J'ai une petite question sur la sécurité sur un fichier EXE compilé avec VB6.
Si j'ai des mots de passe dans le code, est-ce que quelqu'un qui a accès seulement au EXE (pas aux sources) pourrait décompiler le code et ainsi voir le mot de passe?
Disons qu'il s'agit d'un projet sensible et qu'il faut que je travaille sur la sécurité de cette application. Je veux donc en savoir plus sur les possibles façon de voir le code compilé.
Merci
DL
A voir également:
- Question sur la sécurité sur un fichier EXE
- Comment réduire la taille d'un fichier - Guide
- Fichier bin - Guide
- Comment ouvrir un fichier epub ? - Guide
- Votre appareil ne dispose pas des correctifs de qualité et de sécurité importants - Guide
- Fichier rar - Guide
12 réponses
Salut
Oui, toutes les chaines seront lisibles. Projet en VB ? Hum, drôle de choix pour un projet sensible.
Cdt
Oui, toutes les chaines seront lisibles. Projet en VB ? Hum, drôle de choix pour un projet sensible.
Cdt
Et, par exemple, avec quels genre d'outils ou d'application tu peux aller lire le .EXE?
En fait, si le EXE est lisible, il faudrait que j'encrypte le mot de passe en chaine de caractère
En fait, si le EXE est lisible, il faudrait que j'encrypte le mot de passe en chaine de caractère
Et, par exemple, avec quels genre d'outils ou d'application tu peux aller lire le .EXE?
Avec un désassembleur, déboggueur par exemple (W32Dasm, OllyDbg, gdb, ...). Les programmes ne manquent pas ;)
Je pense que le meilleur moyen que tu as est de mettre la forme hachée du mot de passe en ajoutant un salt (sel).
Mais bon, sache qu'une application sensible avec un simple mot de passe, c'est pas très raisonnable.
Avec un désassembleur, déboggueur par exemple (W32Dasm, OllyDbg, gdb, ...). Les programmes ne manquent pas ;)
Je pense que le meilleur moyen que tu as est de mettre la forme hachée du mot de passe en ajoutant un salt (sel).
Mais bon, sache qu'une application sensible avec un simple mot de passe, c'est pas très raisonnable.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
J'ai essayé avec WinDASH, et à moins que je ne comprenne pas grand chose, il n'y a pas grand chose à faire avec le résultat du décompilateur. Je ne suis même pas capable de trouver une chaine de caractère du path
Alors tu dois pas comprendre grand chose ;).
Avec W32dasm tu verras facilement le mot de passe en clair si tu prends aucun précaution. D'où l'idée du hash + sel.
Et puis même avec cette précaution, ça se sautera très facilement. A moins d'implémenter des techniques du genre anti reversing, et compagnie. Mais bon c'est une autre histoire, et puis ce n'est pas fiable non plus, mais tellement plus pénible ^^.
Avec W32dasm tu verras facilement le mot de passe en clair si tu prends aucun précaution. D'où l'idée du hash + sel.
Et puis même avec cette précaution, ça se sautera très facilement. A moins d'implémenter des techniques du genre anti reversing, et compagnie. Mais bon c'est une autre histoire, et puis ce n'est pas fiable non plus, mais tellement plus pénible ^^.
Donc fiddy, ce que je comprend, c'est qu'il n'y a pas vraiment moyen que ce soit infaillible.
Mais de toute façon, ce n'est pas mon but. L'idée est de rendre les données et l'EXE le plus sécuritaire que possible. Avant d'arriver ce matin, les gens ici m'avaient dit qu'un EXE ne peut être décompiler alors qu'il n'en ait rien. C'est quand même un bon début. Il faut donc que j'essai de trouver une solution pour empêcher de voir le mot de passe dans l'EXE par le commun des mortels, pas nécessirement par le plus king des hackers.
Mais de toute façon, ce n'est pas mon but. L'idée est de rendre les données et l'EXE le plus sécuritaire que possible. Avant d'arriver ce matin, les gens ici m'avaient dit qu'un EXE ne peut être décompiler alors qu'il n'en ait rien. C'est quand même un bon début. Il faut donc que j'essai de trouver une solution pour empêcher de voir le mot de passe dans l'EXE par le commun des mortels, pas nécessirement par le plus king des hackers.
Attention, faut pas confondre décompiler et désassembler ou débugguer. Rien à voir. Décompiler du .exe c'est pas possible, quoiqu'il existe des notes à ce propos, permettant de le retrouver en partie (ce qui explique pourquoi le choix de VB pour une application sensible soit étrange). En revanche désassembler ou débugguer un programme est possible sauf cas particulier. Et dans ce cas, on verra ta jolie chaine. Donc, ce que je te conseille, c'est dans un premier temps de stocker ton mot de passe hachée avec du sel. Cela évitera de voir en clair le mot de passe. Et dans un deuxième temps une fois que ton projet sera finie, de revenir sur ce point, en y mettant des algorithmes plus fiables comme l'ajout d'un checksum pour éviter la modification du hash, comparaison avec du calcul plutôt que comparaison des mots de passe toute simple, etc ...
Cdt
Cdt
Rebonjour,
J'ai continué mes recherches sur la sécurité de mon application mais je dois dire que je m’y perds un peu.
Ce que mon application fait est qu’à l’ouverture, c’est qu’il y a du code qui décrypte (grâce à un mot de passe) un fichier (.ucc) local afin que celui-ci (.dbf) puisse être utilisé par l’application. Au unload de la form, je réencrypte le fichier .dbf avec le même mot de passe. Le problème est que le mot de passe qui sert au decrypt/réencrypt est stocké dans le code. C’est sur cet aspect que je devrais sécuriser mon affaire. Comme vous m’avez dit que quelqu’un de mal intentionné était capable de décompiler ou débugger le .EXE de l’application, il serait alors facile de récupérer le mot de passe afin de décrypter le fichier encrypté et ainsi voir les données « sensibles ».
Ce que j’ai vu jusqu’à maintenant était relié à la façon « d’hacher » un mot de passe afin de rendre celui-ci moins clair. Et ça fonctionne : on saisi un mot de passe et ce qui en ressort est une string plus ou moins claire. Mais, je ne crois pas que cette notion peut s’appliquer au stockage de mot de passe dans le code s’il n’est pas saisi par un usager externe. Le problème (et c’est peut-être ça mon problème de fond), c’est que l’usager n’a pas actuellement à saisir de mot de passe à l’ouverture de l’application. Je veux être capable de sécuriser l’application afin que les données soient illisibles en dehors de l’application (via Windows Explorer par exemple) mais les données peuvent être consultées en démarrant l’application (ça c’est tolérable). C’est peut-être ici une incohérence et il faudrait peut-être obliger l’usager à saisir un mot de passe. Le problème dans ce cas, c’est qu’il va y avoir probablement 500-600 personnes qui vont utiliser l’application et il risque fort bien que certains usagers vont oublier le mot de passe et ils ne pourront plus utiliser l’application, ce qu’on ne veut évidemment pas.
Alors, je ne sais pas s’il existe un moyen de « cacher » un mot de passe dans le code afin que celui-ci ne soit pas lisible clairement par quelqu’un qui décompilerait l’EXE, sans devoir faire saisir un mot de passe par l’usager? Si quelqu’un me dit qu’il est possible de décompiler l’EXE à un point tel que la source peut être reconstituée, alors là, je ne sais pas trop comment je peux sécuriser mon affaire sans avoir d’intervention de la part de l’usager? Mais si quelqu’un me dit que le code qui peut-être extrait de l’EXE par un décompilateur l’est seulement par portion plus ou moins clair, je pourrais alors, par exemple, décortiquer le mot de passe en deux string cachées (et chaque partie pourrait être hachées) et concaténer le mot de passe « on the fly » afin de la passer à ma fonction qui décrypte le fichier .ucc? Je pourrais même mettre les parties des strings dans des fichiers texte locaux afin que les parties ne se retrouvent pas dans le code?
Je suis tombé sur le concept de clé publique et privée avec GnuPG mais même après avoir créé la paire de clé, je ne sais pas trop comment je peux la mettre en application dans le code. Si je passe la clé privée dans le code afin de récupérer le mot de passe, la personne mal intentionnée qui va voir cette clé va être en mesure de trouver la solution à mon tour de passe passe?
En espérant que mes explications aient été assez clair, je remercie ceux et celles qui prendront le temps de répondre à ma question
J'ai continué mes recherches sur la sécurité de mon application mais je dois dire que je m’y perds un peu.
Ce que mon application fait est qu’à l’ouverture, c’est qu’il y a du code qui décrypte (grâce à un mot de passe) un fichier (.ucc) local afin que celui-ci (.dbf) puisse être utilisé par l’application. Au unload de la form, je réencrypte le fichier .dbf avec le même mot de passe. Le problème est que le mot de passe qui sert au decrypt/réencrypt est stocké dans le code. C’est sur cet aspect que je devrais sécuriser mon affaire. Comme vous m’avez dit que quelqu’un de mal intentionné était capable de décompiler ou débugger le .EXE de l’application, il serait alors facile de récupérer le mot de passe afin de décrypter le fichier encrypté et ainsi voir les données « sensibles ».
Ce que j’ai vu jusqu’à maintenant était relié à la façon « d’hacher » un mot de passe afin de rendre celui-ci moins clair. Et ça fonctionne : on saisi un mot de passe et ce qui en ressort est une string plus ou moins claire. Mais, je ne crois pas que cette notion peut s’appliquer au stockage de mot de passe dans le code s’il n’est pas saisi par un usager externe. Le problème (et c’est peut-être ça mon problème de fond), c’est que l’usager n’a pas actuellement à saisir de mot de passe à l’ouverture de l’application. Je veux être capable de sécuriser l’application afin que les données soient illisibles en dehors de l’application (via Windows Explorer par exemple) mais les données peuvent être consultées en démarrant l’application (ça c’est tolérable). C’est peut-être ici une incohérence et il faudrait peut-être obliger l’usager à saisir un mot de passe. Le problème dans ce cas, c’est qu’il va y avoir probablement 500-600 personnes qui vont utiliser l’application et il risque fort bien que certains usagers vont oublier le mot de passe et ils ne pourront plus utiliser l’application, ce qu’on ne veut évidemment pas.
Alors, je ne sais pas s’il existe un moyen de « cacher » un mot de passe dans le code afin que celui-ci ne soit pas lisible clairement par quelqu’un qui décompilerait l’EXE, sans devoir faire saisir un mot de passe par l’usager? Si quelqu’un me dit qu’il est possible de décompiler l’EXE à un point tel que la source peut être reconstituée, alors là, je ne sais pas trop comment je peux sécuriser mon affaire sans avoir d’intervention de la part de l’usager? Mais si quelqu’un me dit que le code qui peut-être extrait de l’EXE par un décompilateur l’est seulement par portion plus ou moins clair, je pourrais alors, par exemple, décortiquer le mot de passe en deux string cachées (et chaque partie pourrait être hachées) et concaténer le mot de passe « on the fly » afin de la passer à ma fonction qui décrypte le fichier .ucc? Je pourrais même mettre les parties des strings dans des fichiers texte locaux afin que les parties ne se retrouvent pas dans le code?
Je suis tombé sur le concept de clé publique et privée avec GnuPG mais même après avoir créé la paire de clé, je ne sais pas trop comment je peux la mettre en application dans le code. Si je passe la clé privée dans le code afin de récupérer le mot de passe, la personne mal intentionnée qui va voir cette clé va être en mesure de trouver la solution à mon tour de passe passe?
En espérant que mes explications aient été assez clair, je remercie ceux et celles qui prendront le temps de répondre à ma question
Rebonjour,
J'ai continué mes recherches sur la sécurité de mon application mais je dois dire que je m’y perds un peu.
Ce que mon application fait est qu’à l’ouverture, c’est qu’il y a du code qui décrypte (grâce à un mot de passe) un fichier (.ucc) local afin que celui-ci (.dbf) puisse être utilisé par l’application. Au unload de la form, je réencrypte le fichier .dbf avec le même mot de passe. Le problème est que le mot de passe qui sert au decrypt/réencrypt est stocké dans le code. C’est sur cet aspect que je devrais sécuriser mon affaire. Comme vous m’avez dit que quelqu’un de mal intentionné était capable de décompiler ou débugger le .EXE de l’application, il serait alors facile de récupérer le mot de passe afin de décrypter le fichier encrypté et ainsi voir les données « sensibles ».
Ce que j’ai vu jusqu’à maintenant était relié à la façon « d’hacher » un mot de passe afin de rendre celui-ci moins clair. Et ça fonctionne : on saisi un mot de passe et ce qui en ressort est une string plus ou moins claire. Mais, je ne crois pas que cette notion peut s’appliquer au stockage de mot de passe dans le code s’il n’est pas saisi par un usager externe. Le problème (et c’est peut-être ça mon problème de fond), c’est que l’usager n’a pas actuellement à saisir de mot de passe à l’ouverture de l’application. Je veux être capable de sécuriser l’application afin que les données soient illisibles en dehors de l’application (via Windows Explorer par exemple) mais les données peuvent être consultées en démarrant l’application (ça c’est tolérable). C’est peut-être ici une incohérence et il faudrait peut-être obliger l’usager à saisir un mot de passe. Le problème dans ce cas, c’est qu’il va y avoir probablement 500-600 personnes qui vont utiliser l’application et il risque fort bien que certains usagers vont oublier le mot de passe et ils ne pourront plus utiliser l’application, ce qu’on ne veut évidemment pas.
Alors, je ne sais pas s’il existe un moyen de « cacher » un mot de passe dans le code afin que celui-ci ne soit pas lisible clairement par quelqu’un qui décompilerait l’EXE, sans devoir faire saisir un mot de passe par l’usager? Si quelqu’un me dit qu’il est possible de décompiler l’EXE à un point tel que la source peut être reconstituée, alors là, je ne sais pas trop comment je peux sécuriser mon affaire sans avoir d’intervention de la part de l’usager? Mais si quelqu’un me dit que le code qui peut-être extrait de l’EXE par un décompilateur l’est seulement par portion plus ou moins clair, je pourrais alors, par exemple, décortiquer le mot de passe en deux string cachées (et chaque partie pourrait être hachées) et concaténer le mot de passe « on the fly » afin de la passer à ma fonction qui décrypte le fichier .ucc? Je pourrais même mettre les parties des strings dans des fichiers texte locaux afin que les parties ne se retrouvent pas dans le code?
Je suis tombé sur le concept de clé publique et privée avec GnuPG mais même après avoir créé la paire de clé, je ne sais pas trop comment je peux la mettre en application dans le code. Si je passe la clé privée dans le code afin de récupérer le mot de passe, la personne mal intentionnée qui va voir cette clé va être en mesure de trouver la solution à mon tour de passe passe?
En espérant que mes explications aient été assez clair, je remercie ceux et celles qui prendront le temps de répondre à ma question
J'ai continué mes recherches sur la sécurité de mon application mais je dois dire que je m’y perds un peu.
Ce que mon application fait est qu’à l’ouverture, c’est qu’il y a du code qui décrypte (grâce à un mot de passe) un fichier (.ucc) local afin que celui-ci (.dbf) puisse être utilisé par l’application. Au unload de la form, je réencrypte le fichier .dbf avec le même mot de passe. Le problème est que le mot de passe qui sert au decrypt/réencrypt est stocké dans le code. C’est sur cet aspect que je devrais sécuriser mon affaire. Comme vous m’avez dit que quelqu’un de mal intentionné était capable de décompiler ou débugger le .EXE de l’application, il serait alors facile de récupérer le mot de passe afin de décrypter le fichier encrypté et ainsi voir les données « sensibles ».
Ce que j’ai vu jusqu’à maintenant était relié à la façon « d’hacher » un mot de passe afin de rendre celui-ci moins clair. Et ça fonctionne : on saisi un mot de passe et ce qui en ressort est une string plus ou moins claire. Mais, je ne crois pas que cette notion peut s’appliquer au stockage de mot de passe dans le code s’il n’est pas saisi par un usager externe. Le problème (et c’est peut-être ça mon problème de fond), c’est que l’usager n’a pas actuellement à saisir de mot de passe à l’ouverture de l’application. Je veux être capable de sécuriser l’application afin que les données soient illisibles en dehors de l’application (via Windows Explorer par exemple) mais les données peuvent être consultées en démarrant l’application (ça c’est tolérable). C’est peut-être ici une incohérence et il faudrait peut-être obliger l’usager à saisir un mot de passe. Le problème dans ce cas, c’est qu’il va y avoir probablement 500-600 personnes qui vont utiliser l’application et il risque fort bien que certains usagers vont oublier le mot de passe et ils ne pourront plus utiliser l’application, ce qu’on ne veut évidemment pas.
Alors, je ne sais pas s’il existe un moyen de « cacher » un mot de passe dans le code afin que celui-ci ne soit pas lisible clairement par quelqu’un qui décompilerait l’EXE, sans devoir faire saisir un mot de passe par l’usager? Si quelqu’un me dit qu’il est possible de décompiler l’EXE à un point tel que la source peut être reconstituée, alors là, je ne sais pas trop comment je peux sécuriser mon affaire sans avoir d’intervention de la part de l’usager? Mais si quelqu’un me dit que le code qui peut-être extrait de l’EXE par un décompilateur l’est seulement par portion plus ou moins clair, je pourrais alors, par exemple, décortiquer le mot de passe en deux string cachées (et chaque partie pourrait être hachées) et concaténer le mot de passe « on the fly » afin de la passer à ma fonction qui décrypte le fichier .ucc? Je pourrais même mettre les parties des strings dans des fichiers texte locaux afin que les parties ne se retrouvent pas dans le code?
Je suis tombé sur le concept de clé publique et privée avec GnuPG mais même après avoir créé la paire de clé, je ne sais pas trop comment je peux la mettre en application dans le code. Si je passe la clé privée dans le code afin de récupérer le mot de passe, la personne mal intentionnée qui va voir cette clé va être en mesure de trouver la solution à mon tour de passe passe?
En espérant que mes explications aient été assez clair, je remercie ceux et celles qui prendront le temps de répondre à ma question
Salut
Ouh là, j'avais pas du tout compris ça comme ça moi. Je pensais juste que tu voulais mettre un mot de passe à l'entrée de ton programme et si le mot de passe entré par l'utilisateur était incorrect alors le programme ferme.
Donc pour résumer, ton programme dans son fonctionnement correct , doit pouvoir avoir accès à un fichier chiffré. Et pour cela tu caches la clé de chiffrement dans ton code VB. C'est ça ?
Ouh là, j'avais pas du tout compris ça comme ça moi. Je pensais juste que tu voulais mettre un mot de passe à l'entrée de ton programme et si le mot de passe entré par l'utilisateur était incorrect alors le programme ferme.
Donc pour résumer, ton programme dans son fonctionnement correct , doit pouvoir avoir accès à un fichier chiffré. Et pour cela tu caches la clé de chiffrement dans ton code VB. C'est ça ?
oui c'est ça essentiellement. Et l'encryption/décrypter de ce fichier dbf fonctionne bien. Le seul hic est que le mot de passe (clé) est dans le code, donc, accessible à ceux qui vont décompiler l'EXE
Ok, dans ce cas, la technique de hash ne marchera pas du tout. Par contre, tu peux chiffrer le mot de passe par un master mot de passe qui sera demandé dans ton application. Par exemple un simple Xor bit à bit.
Donc dans ton programme tu stockes ton mot de passe chiffré (Xor bit à bit avec ton master password). Lorsque tu lances ton programme, il te demande le master password, qui effectue l'opération de chiffrement et obtient le vrai mot de passe capable de déchiffrer l'autre fichier.
Si c'est pas très clair, n'hésite pas ;)
Cdt
Donc dans ton programme tu stockes ton mot de passe chiffré (Xor bit à bit avec ton master password). Lorsque tu lances ton programme, il te demande le master password, qui effectue l'opération de chiffrement et obtient le vrai mot de passe capable de déchiffrer l'autre fichier.
Si c'est pas très clair, n'hésite pas ;)
Cdt
