Fichier Executable [Résolu]
siahmedaek
- Messages postés
- 45
- Date d'inscription
- dimanche 14 juin 2009
- Statut
- Membre
- Dernière intervention
- 29 octobre 2009
- Messages postés
- 4716
- Date d'inscription
- dimanche 26 février 2006
- Statut
- Modérateur
- Dernière intervention
- 27 mars 2018
A voir également:
- Fichier executable
- Un prog pour cacher au maximum votre fichier executable - Codes sources - Visual Basic / VB.NET (Base de Donnees)
- Manipulation fichier executable - Codes sources - Visual Basic / VB.NET (Exécution)
- Le fichier exécutable d'un projet ✓ - Forum - C++ & C++ .NET
- Execution d'un fichier executable sur le serveur ✓ - Forum - ASP / ASP3
- Fichier executable ✓ - Forum - Java
7 réponses
Meilleure réponse
- Messages postés
- 4716
- Date d'inscription
- dimanche 26 février 2006
- Statut
- Modérateur
- Dernière intervention
- 27 mars 2018
@siahmedaek:
ta dernière remarque éclaire un peu plus
et c'est plus simple..
tu ne fournis que l'exécutable et de ce fait
l'utilisateur ne peut rien modifier
et pour l'accès à la base,
il faut tout crypter.
cantador
ta dernière remarque éclaire un peu plus
et c'est plus simple..
tu ne fournis que l'exécutable et de ce fait
l'utilisateur ne peut rien modifier
et pour l'accès à la base,
il faut tout crypter.
cantador
Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire
193 internautes nous ont dit merci ce mois-ci
- Messages postés
- 3982
- Date d'inscription
- mardi 8 mars 2005
- Statut
- Modérateur
- Dernière intervention
- 7 novembre 2014
cantador ->
Bin voilà le genre de truc que l'on peut récupérer :
De ça on peut en comprendre l'algo général. On voit facilement 5 "call", qui sont des appels à des fonctions. En traçant les appels avec ntsd et les valeurs de retour, on détermine facilement que le premier appel renvoie le contenu d'un champ de texte, que le deuxième compare deux chaînes, que les deux suivant affichent une boite de dialogue, et que le dernier est sans intérêt. Après, au choix, on peut récupérer le mot de passe, "password", en regardant le deuxième argument passé à la fonction de comparaison, ou on peut supprimer le jne directement en le noppant (En écrasant le jne par des instructions no-operation).
Donc à la main, on peut retrouver ça :
Mais ce n'est en aucun cas le vrai source qui est le suivant :
Donc on ne récupère jamais le vrai source, et on ne le récupérera jamais vraiment, car des informations ont disparues à la compilation. On ne récupère que de l'assembleur que l'on peut traduire en source ou en pseudo source. Cela peut être exploité pour une étude limité d'un secteur de code ("Waouh ! Classe ! Comment ont ils fait ça ? Aaaaah, ils ont utilisé XXXX.") ou pour faire sauter une protection, mais de là à reconstituer un logiciel entier sous forme de source, il y a un boulot très long et plus ou moins proportionnel à la taille du logiciel.
Conclusion, livrer un .exe globalement sûr en ce qui concerne la récupération du source. Par contre si le logiciel a besoin d'une protection en lui même, il faut alors crypter le code machine.
Après, en plus, si on connaît le langage utilisé pour créer le .exe (Les désassembleur avancés détectent automatiquement le compilateur utilisé avec plus ou moins de précision), on peut en tirer plus facilement des informations. Pour le Delphi, on utilisera par exemple DeDe. Je ne l'ai jamais essayé, mais il a l'air capable de produire des .dfm, voir un projet Delphi complet, bien qu'avec de l'assembleur, et incompilable.
Bin voilà le genre de truc que l'on peut récupérer :
De ça on peut en comprendre l'algo général. On voit facilement 5 "call", qui sont des appels à des fonctions. En traçant les appels avec ntsd et les valeurs de retour, on détermine facilement que le premier appel renvoie le contenu d'un champ de texte, que le deuxième compare deux chaînes, que les deux suivant affichent une boite de dialogue, et que le dernier est sans intérêt. Après, au choix, on peut récupérer le mot de passe, "password", en regardant le deuxième argument passé à la fonction de comparaison, ou on peut supprimer le jne directement en le noppant (En écrasant le jne par des instructions no-operation).
Donc à la main, on peut retrouver ça :
si RecupContenu(ChampDeText) = 'password' alors
Affiche('ok');
sinon
Affiche('erreur');
fsi;
Mais ce n'est en aucun cas le vrai source qui est le suivant :
procedure TForm1.Button1Click(Sender: TObject);
begin
if Edit1.Text = 'password' then
ShowMessage('ok')
else
ShowMessage('erreur');
end;
Donc on ne récupère jamais le vrai source, et on ne le récupérera jamais vraiment, car des informations ont disparues à la compilation. On ne récupère que de l'assembleur que l'on peut traduire en source ou en pseudo source. Cela peut être exploité pour une étude limité d'un secteur de code ("Waouh ! Classe ! Comment ont ils fait ça ? Aaaaah, ils ont utilisé XXXX.") ou pour faire sauter une protection, mais de là à reconstituer un logiciel entier sous forme de source, il y a un boulot très long et plus ou moins proportionnel à la taille du logiciel.
Conclusion, livrer un .exe globalement sûr en ce qui concerne la récupération du source. Par contre si le logiciel a besoin d'une protection en lui même, il faut alors crypter le code machine.
Après, en plus, si on connaît le langage utilisé pour créer le .exe (Les désassembleur avancés détectent automatiquement le compilateur utilisé avec plus ou moins de précision), on peut en tirer plus facilement des informations. Pour le Delphi, on utilisera par exemple DeDe. Je ne l'ai jamais essayé, mais il a l'air capable de produire des .dfm, voir un projet Delphi complet, bien qu'avec de l'assembleur, et incompilable.
Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire
193 internautes nous ont dit merci ce mois-ci
- Messages postés
- 3982
- Date d'inscription
- mardi 8 mars 2005
- Statut
- Modérateur
- Dernière intervention
- 7 novembre 2014
Salut,
Un fichier exécutable ne contient pas le source.
Si tu cherches à empêcher le désassemblage, c'est peine perdue. Il n'y a aucune méthode vraiment efficace à ce niveau, car à un moment ou a un autre, il faut que le processeur soit capable de lire le code pour l'exécuter, donc le pirate peut le lire aussi à ce moment là.
Un fichier exécutable ne contient pas le source.
Si tu cherches à empêcher le désassemblage, c'est peine perdue. Il n'y a aucune méthode vraiment efficace à ce niveau, car à un moment ou a un autre, il faut que le processeur soit capable de lire le code pour l'exécuter, donc le pirate peut le lire aussi à ce moment là.
- Messages postés
- 4716
- Date d'inscription
- dimanche 26 février 2006
- Statut
- Modérateur
- Dernière intervention
- 27 mars 2018
- Messages postés
- 45
- Date d'inscription
- dimanche 14 juin 2009
- Statut
- Membre
- Dernière intervention
- 29 octobre 2009
- Messages postés
- 45
- Date d'inscription
- dimanche 14 juin 2009
- Statut
- Membre
- Dernière intervention
- 29 octobre 2009
- Messages postés
- 4716
- Date d'inscription
- dimanche 26 février 2006
- Statut
- Modérateur
- Dernière intervention
- 27 mars 2018