protéger nos programmes

bjr jack

j'aimerai pour une prochaine version de panoramic
un system afin de protéger nos programmes
contre "Recover_Source" ceci évitera le piratage
de nos création
merci pour une réponse de ta part

Impossible. Voir ma réponse ici.

PS

Evite de poser la même question à deux endroits différents...

@ Pascal 10000,

Ce serait remettre en question la philosophie même de ce langage
et du forum.

Mais, ceci n' est que mon avis.

Pas d'accord Ygeronimi. Ca ne remet pas en cause l'esprit du forum: sur el forum on partage ce que l'on veut, mais on a tout à fait le droit de ne pas vouloir partager certaines sources.

Panoramic peut servir à faire des programme commerciaux et la demande de Pascal1000 et légitime, même si comme l'indique Klaus cela n'est pas possible tant que le compilateur ne sera pas fini.

Après c'est le contraire qui ne sera plus possible et certains demanderont sans doute s'ils peuvent récupérer leurs sources depuis un programme compilé et quelqu'un se lancera peut être dans la création d'un décompilateur (un programme qui recréait le code source depuis une suite d'instructions compilées mais c'est un gros travail et certaines informations (noms de variables, commentaires, etc ... ne peuvent de toute façon plus être récupérés)

Là, Jicehel, tu rentres dans le vaste domaine des désassembleurs... S'il est relativement aisé, avec des outils librement disponibles sur le net, de recréer le code source assembleur (en ASM), cela reste tout de même très peu lisible. C'est utilisable uniqement dans une perspecive de "crackage" d'une protection par code licence, afin de trouver l'endroit à la licence est testée, puis de patcher cela de telle façon que la réponse sera toujours "licence valide".

C'est une toute autre paire de manches pour reconstruire le code source d'un langage évolué. J'ai essayé cela avec Delphi, utilisant des décompilateurs spécialement conçus pour Delphi. Et je peux te dire que le résultat est plus que décevant, si toute fois l'outil est capable de trouver quoi que ce soit. ET encore, souvent le programme demande la table de symboles issue de la phase de link, et quelques fois d'autres fichiers annexes. Autant dire que c'est impossible dans le cadre d'une application distribuée.

Non, je pense que reconstituer le code Panoramic à partir d'un EXE issu du futur compilateur de Panormic sera mssion impossible.

@Pascal1000,

Source_recovery à été crée par Jack, suite à une question que j'avais posé il y a bien longtemps.
( https://panoramic.1fr1.net/t218-source-bas-ecrase-par-erreur?highlight=source )
Je ne vois pas bien comment Jack pourrait défaire ce qu'il a lui-même créer. Mais bon, c'est lui le décisionnaire.

Que tu souhaites protéger un exécutable Panoramic est à mon avis légitime, mais là tu fais une demande pour toi et  elle n'a pas forcément l’agrément des autres Panoramiciens.

Donc la question est plutôt comment protéger un exe Panoramic sans rendre Source_recovery inefficace. En clair est-il possible que Jack ajoute à l'éditeur une option d'un cryptage supplémentaire, ou qu'un Panoramicien nous fournisse un moyen ???.

A+

Je me demande si en passant par un compresseur d'exécutables, ça ne protège pas defacto le code source.
Il me semble que Klaus avait mis le nom d'un compresseur d'exe. Klaus avait fournit le nom du compacteur d'executable il me semble. A tester. Je pense que c'est une piste

je vous remerci a tous de vos reflections
et a vos commentaires
tout compte fait j'ai poste mon source
nouveau pour des concours
et oublié ce post

Pour rappel :

Si nous distribuons nos programmes sur internet en EXE, il faut ensuite que les utilisateurs devinent dans quel langage on les a programmés.
Personne ne vous oblige a citer vos sources, même si c'est plus sympa pour Jack (on lui fait un peu de pub !)
Déjà, c'est pas forcément évident...
Ensuite, il faut qu'ils trouvent le programme adéquat sur le forum. Ce qui n'est pas évident non plus.

Donc je pense que l'on peut distribuer nos programmes sans trop de peur qu'il soit modifier.
Et puis pour ma part, je ne fais pas de calculs de ce genre !

Si je développe un programme c'est pas dans un but commercial !
De plus si quelqu'un peut l'améliorer, tant mieux !
C'est tout l'intérêt d'un logiciel libre, et au passage un grand merci a Jack !

Bonsoir,
Une question comme cela!
Lorsque je faisais de l'assembleur avec les microprocesseur 6502, il y avait l'instruction NOP, qui ne servait à rien, seulement pour occuper une mémoire en passant dessus. Utile lors de modification.

Je ne sais pas si les fichier exe ont un entête, si ce n'est pas le cas, on devrait pouvoir ajouter devant des NOP au programme. Reste à savoir si on peut encore décompiler Panoramic. Normalement si l'entête n'existe pas, cela ne devrait pas empêcher le programme de fonctionner.
Surement que je me plante., c'est juste une idée.
En y réfléchissant depuis, ça me parait une absurdité. Je sors

cosmos70

pourquoi absurde? je ne crois pas non
ce n'est pas absurde si un jour tu trouve
une de tes création dans les chareware tu sera
peut être pas contend alors que tu aura passé
bcp de temps pour rien
je ne dis que ça c mon point de vu

minibug
n’oublie pas que il y a des voleurs même s'ils ne sont
pas parmi nous ils ont tout pour faire nos code d'acces
a webdev et de se servir comme bon leurs semble!!

Le plus c..., c' est celui qui va payé pour une appli
que tu auras publié en freeware.

C' est bon, je sors.

jack bloque ce post je bien avoir mis la zinani
dsl

Citation :

pourquoi absurde? je ne crois pas non
ce n'est pas absurde si un jour tu trouve
une de tes création dans les chareware tu sera
peut être pas contend alors que tu aura passé
bcp de temps pour rien

Il y a erreur. Je ne parle pas de ton idée de pouvoir protéger ta création. Je parlais du principe que j'ai énuméré. Je m'étais dis qu'en ajoutant un entête au fichier exécutable généré, le programme qui recréé le source ne saurait pas le lire. Comme les instructions machines devant qui serait une série de NOP, cela n’empêcherait pas son exécution. Comme il n'y avait pas d'intervention, je me suis dit ensuite que j'avais du mettre une connerie. C'est surement le cas. Mes idées souvent sont comme le bonhomme, ça ne vaut pas grand chose.

c'est peut être faisable de ce que tu dit
mais moi ce j'ai pensé c'est du fait que recover
utilisait shell32.dll si il n'y avait pas moyen de bloquer
la dll mais l'inconvénient c'est que ça risque de compromettre
windows lui même et de saturé le système