Version imprimable
A titre d'information j'avais la même idée mais j'ai vu que maintenant les dongles sont équipésCitation:
Envoyé par Paul TOTH
de processeurs qui génèrent des échanges à contenus et vitesses aléatoires. Je n'en sais pas beaucoup plus, mais cela semble démonter d'emblée, ou du moins compliquer singulièrement, l'idée d'un simple espionnage et d'une simple reproduction des échanges dongle <--> application.
:) tout à fait. Mais ça à aussi un effet intéressant: la personne pourra penser que le progCitation:
Envoyé par Caribensila
n'est pas protégé mais non fonctionnel; Et du coup ne pas essayer de le cracker.
Hmm... Ce serait concevable dans un monde presque parfait où ce serait les utilisateurs qui crackent les logiciels dont ils ont besoin.Citation:
Envoyé par Eric Beaumard
Mais le monde étant bien plus compliqué, c'est pas du tout comme cela que ça se passe.
- En fait, il y a d'un côté les crackeurs qui s'amusent à cracker, même les logiciels dont ils seraient incapables de se servir. Et plus c'est difficile, plus ils s'y acharneront, par plaisir intellectuel. Autant dire qu'ils y arrivent toujours. Evidemment, avides de reconnaissance, ces crackers mettent aussitôt leurs exploits sur Internet.
- D'un autre côté, il y a des utilisateurs potentiels qui savent exactement ce dont ils ont besoin, mais qui n'ont nulle envie de rétribuer les auteurs. Autant dire les "vrais voleurs", qui tireront profits de ces logiciels.
Les crackeurs donc, pas toujours des imbéciles, ne s'amuseront pas à cracker un logiciel non fonctionnel. Ils crackeront bel et bien ton logiciel qui fonctionne.
----------------------------
Au sujet de la protection de logiciel, je voudrais partager une petite expérience et réflexion que j'ai eu il y a quelques années.
A l'époque sortait Catia, un superbe logiciel de Dassault Systèmes, qui permet de dessiner et "calculer" aussi bien des avions de chasse que des centrifugeuses pour enrichir l'uranium (entre autres, bien sûr). Un truc pour techniciens et ingénieurs y ayant été formés; pas pour le premier péquenaud venu quoi.
J'ai été très surpris d'en trouver des versions crackées sur Internet quelques semaines plus tard (comme par hasard, c'est une amie chinoise qui m'avait prévenu). J'en ai téléchargée une... et cette version était a priori tout à fait opérationnelle !
Mais je n'ai pas pu m'empêcher de me poser quelques questions...
- Et si ces versions crackées avaient été mises sur Internet par Dassault Systèmes lui-même ?
Au cas où, par exemple, si tu voulais fabriquer une bombe atomique, qu'au final, sans message d'erreur, celle-ci te pète à la gueule au 1er essai ? :lol:
Pareil pour dessiner un "Tupolev" crasheur, bien sûr, etc...
Bref, une politique d'entreprise qui consisterait à sortir en même temps que la version officielle d'un logiciel, ses versions foireuses "pseudo-crackées".
Cela me semble être une bonne solution au piratage. Nul ne pourrait jamais avoir la certidude que sa version piratée du logiciel soit vraiment fiable.
A mon avis, la protection de logiciel passera par ce genre de méthodes, plus psychologiques que techniques.
en fait les 50 derniers octets ont toutes les chances de ne servir à rien :)Citation:
Envoyé par Eric Beaumard
la taille d'un fichier est multiple de 512 octets, tu peux donc avoir jusque 511 octets inutiles en fin de fichier. Et tu trouves là des ressources, des informations de debug et ce genre de choses qui ne sont pas vitales au programme.
et encore une fois, à chaque mise à jour du programme il faudra mettre à jour le dongle...c'est pas très intéressant...ou alors ton programme de mise à jour contiendra le code nécessaire pour lire/écrire le dongle et le pirate n'aura plus qu'à s'en servir :)
Imaginons qu'en plusieurs endroits, le programme envoie un nombre aléatoire au dongle, et que celui-ci renvoie une donnée après un traitement particulier.
Et que, d'autre part, le programme ne se lance pas si la taille de son fichier n'est pas la même que l'originale.
Le pirate se fera quand même quelques cheveux blancs, non ?
des cheveux blancs, je ne suis pas sur :)Citation:
Envoyé par Teddy
le principe est toujours le même, trouver les procédures qui font les tests et leur faire renvoyer TRUE...
en gros on remplace ceci
parCode:
2
3
4
5
après c'est plus ou moins complexe mais c'est toujours faisable...et là tu images bien qu'appeler cette procédure 15 fois dans le programme n'y change rien, il suffit d'un patch :)Code:
2
3
4
5
Bien vu, mais dans ce cas je doute que la taille et la checksum du fichier exécutable modifié soient les mêmes qu'à l'origine...
tu veux parler de la fonction function VerifierTailleduFichier:Boolean ?Citation:
Envoyé par Teddy
même punition :)
en plus tu as des astuces pour faciliter la localisation de ces méthodes...imagine que le programme affiche un message "version non valide du logiciel, veuillez contacter le support"...tu passes en debug et là surprise, le programme vient de faire appel à une procédure qui fait des trucs bizarre mais retourne un boolean :)
bref, à mon humble avis, le dongle n'est pas une protection plus coriace qu'une autre, surtout si tu passes par une bibliothèque - ou pire une DLL - pour interroger le dongle :) Même l'industrie du jeu video - qui pourtant se donne les moyens - n'a pas réussit à éviter le piratage...bon ils sont peut-être aussi plus visés que les soft d'entreprise :)
une piste serait de crypter les dfm avec une clef basé sur le checksum de l'exe tout ou parti) et de les charger en utilisant ReadComponentResFile
si le checksum n'est pas valide car l'exe est patché la dfm n'est pas correctement décryptée et la fiche ne pourra pas s'exécuter
cela se contourne mais c'est plus compliqué qu'un simple boolean à inverser
la fonction CheckSum sera patchée pour retourner le bon...Citation:
si le checksum n'est pas valide car l'exe est patché
Ce que je fais assez simplement est un peu l'inverse de ce qui a été dit ;)
Plutôt que de faire un test dans une procédure, je passe par une variable procédurale qui pointe par défaut sur une procédure qui ne fait rien !
Le test effectif est fait soit dans un thread, soit carrément dans une autre application (je l'ai même eu mis dans un service) et envoi un message à l'application uniquement si le test est ok. S'il l'est, la variable est redirigée sur la procédure réelle.
La nouvelle assignation se fait par un simple PostMessage en utilisant n'importe quel message standard. Par exemple WM_Resize avec un wParam invalide qui pourra être filtré par WndProc.
Bref, aucun test facilement accessible en pas à pas, des messages standards, une redirection invisible et impossible à résoudre sans clé :mrgreen:
Dongles font partie de la reconnaissance physique du pc et pour limiter les copies ... éviter le crack est une autre affaire
Citation:
Envoyé par Paul TOTH
J'ai vu sur le net que les Dongles de maintenant peuvent abriter des processeurs et de la mémoire. On peut alors imaginer déporter sur le dongle une partie vitale du code de l'application. Le hacker pourra toujours espionner les échanges il ne coupera pas à la nécessité de comprendre la portion de programme manquante et de la reprogrammer dans l'application. Dans mon domaine scientifique par exemple il y a des portions de calculs complexes qui peuvent très bien être déportées de cette façon et je souhaite bien du plaisir à celui qui n'aura devant lui que des échantillons d'échange de données entre l'application et le dongle pour retrouver le code de la procédure déportée. Rien d'impossible, mais rien de forcément humain non plus ...
Se pose la question de lire les données écrites sur le dongle. Là, rien d'impossible non plus. De gros moyens électroniques peuvent être utilisés pour cela. Tout dépend encore une fois du ratio:
(Technicité des hackers + argent à gagner)/(niveau de protection de l'application).