Discussion :

[pierre987321]

bonjour, suite a un grand débat sur un post plus bas j'ai une question.

alors en faite on ne peu pas vraiment sécuriser un logiciel.

j'ai un truc du style : (pour la vérification du passe).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
if (verif <> Edit1.Text) then
begin
//pas bon
end
else
begin
//passe ok
ShowMessage();
end

-quesqu'un "saut" en haking supprime tout le IF ?
-esque le premier 'begin - end" lors d'un saut est évité ?
-ya t'il moyen de cacher le "showmessage" lors d'un saut ?
(si saut, plus de message).
-exist'il un moyen de vérifier que la comparaison "le IF" a bien était faite
sinon on réalise une autre action ? (style Bombe logique sur c:\ LOL)

tous commantaires est le bien venue :-)

[Okaryn]

Tu as toutes les réponses dans le fameux post qui a un peu dérivé.

En résumé :

- Non (voir réponse #15 du précédent post)
- Oui
- Non
- Non

[Clorish]

-quesqu'un "saut" en haking supprime tout le IF ?

en general on remplace If MegaTest Then par un If True Then

-esque le premier 'begin - end" lors d'un saut est évité ?

Oui car test toujours vrai (du moins on se debrouille pour)

-ya t'il moyen de cacher le "showmessage" lors d'un saut ?
(si saut, plus de message).

Jamais faire de showmessages ... trop facile a demasquer.
Ferme bien proprement l'application sans rien dire.

-exist'il un moyen de vérifier que la comparaison "le IF" a bien était faite
sinon on réalise une autre action ? (style Bombe logique sur c:\ LOL)

Oui Si tu met a jour une variable globale dans ton test. (appele une procedure)
Si la variable est activé, c'est que l'on est entree dans ta procedure donc a priori test corect, sinon la fonction a ete squizzée.
Par contre .... rien n'empeche de shunter le test qui va varifier si la variable de controle est a true ou false ....

Petits conseils : Si erreur de code, tu peux peut etre mettre a jour une variable et lancer un timer (200ms) qui aura pour but de clore l'applciation si la variabel n'est pas valide.
Differer dans le temps l'action liée au resultat du test est souvent parait il plus chaud a gerer .....

D'ailleur ca me fait penser a un truc : Si test vrai creer instance de obj : TObject sinon non.
Dans le constructeur de la fenetre principale, faire appel a Obj.UneMethodeQuelconqueMaisPasMEthodeDeClasse Si Obj est valide, alors tout se deroule comme prevu.
Sinon cela genere une exception qui a pour effet de fermer l'application (exception dans constructeur = liberation de l'objet en cours de creation = fermeture de l'application dans le cadre de la fenetre principale).
Encadrer d'un try exception l'appel a la creation de la form principale (application.createForm) permet de ne pas faire ressortir l'exception tout en beneficiant de son effet.

Bref plus tu est tordu et plus tu te base sur des subtilitées de codages pouvant etre apparente a du vrai code ... plus tu perdras ton hacker.

[Paul TOTH]

j'avais lu un article très intéressant aussi sur ... comment s'appelait donc ce site...j'ai des trous de mémoire

enfin bref, il disait que les langages haut niveau comme Delphi (et le C++) sont très simples à suivre en assembleur...et que quand on s'amuse à faire un code assembleur compliqué pour protéger le soft...ben tout de suite il saute aux yeux, et il suffit de concentrer ses efforts sur celui-ci pour faire sauter la protection

je me suis amusé comme ça une fois a faire sauter les protections d'un jeu DOS des années 80...il avait pas moins de 3 ou 4 protections, mais en une soirée tout avait sauté C'était un jeu de poupées russes, le programme non protégé avait été passé à la moulinette pour produire un exe "crypté" avec en entête le programme de décryptage. Ce programme simpliste (un XOR du fichier suivant une clé fixe) a été simple à décoder. Par dessus un petit bout de code s'amusait avec la pile et l'INT03 pour faire déconner les débugger..pas grave j'ai travaillé avec le listing d'un désassembleur une autre des protections calculait le checksum du programme pour s'assurer qu'il n'avait pas été modifié...donc au final en dépliant comme ça les protection j'ai obtenu le programme tel qu'il sortait du compilateur avant protection

c'est toujours possible de faire sauter les protections, encore plus aujourd'hui avec des outils de débuggage bien plus efficaces que ce qu'on trouvait sous DOS

enfin bon voila, le piratage c'est pas bien, mais protéger un programme ça ne marche pas

[Clorish]

Pour la petite anecdote, j'ai connu un prof a la fac qui lisait l'ASM comme un code source .....