OVH Cloud OVH Cloud

Software Protection pour Visual Basic ?

7 réponses
Avatar
Paul Sean
Bonjour,

Je cherche actuellement une solution de protection qui permet de faire une
version Demo de notre application, puis le déblocage par une clé, si
possible avec une extension Server (pour générer les clé à partir de notre
serveur web).

Je ne veux pas de Armadillio, Asprotect, ou autre type encrypteur, qui sont
déja casser juste avec un unpacker, éventuellement un ActiveX ou un DLL.

Que me conseillez-vous, protection utilisez-vous en général ?

Merci d'avance

7 réponses

Avatar
Christian Hugoud - Xtrem7
Personnellement, j'utilise un fichier qui contient le nom de
l'utilisateur (qui apparaît en clair lorsque le soft n'est plus en
démo).

Ce fichier est mis à jour au travers de mon site (interrogation d'une
page php qui sert de serveur et à laquelle je passe le nom du client) et
contient alors des dates de péremption, des données de configuration
etc... Bien sur le fichier est crypté.

Le logiciel ne fonctionne qu'en mode démo s'il ne trouve pas le fichier
ou si celui-ci est out-of-date ou s'il a été modifié à la hussarde
(contrôle de cohérence).

Voilà...

Christian


"Paul Sean" a écrit dans le message de
news:bmjg3u$odf$
Bonjour,

Je cherche actuellement une solution de protection qui permet de faire


une
version Demo de notre application, puis le déblocage par une clé, si
possible avec une extension Server (pour générer les clé à partir de


notre
serveur web).

Je ne veux pas de Armadillio, Asprotect, ou autre type encrypteur, qui


sont
déja casser juste avec un unpacker, éventuellement un ActiveX ou un


DLL.

Que me conseillez-vous, protection utilisez-vous en général ?

Merci d'avance









Avatar
Paul Sean
Merci Christian,

J'ai trouver ce qui me fallait : SerialShield Protection :
http://www.ionworx.com/serialshield.html


"Christian Hugoud - Xtrem7" a écrit dans le message de
news:bmjmjv$7dc$
Personnellement, j'utilise un fichier qui contient le nom de
l'utilisateur (qui apparaît en clair lorsque le soft n'est plus en
démo).

Ce fichier est mis à jour au travers de mon site (interrogation d'une
page php qui sert de serveur et à laquelle je passe le nom du client) et
contient alors des dates de péremption, des données de configuration
etc... Bien sur le fichier est crypté.

Le logiciel ne fonctionne qu'en mode démo s'il ne trouve pas le fichier
ou si celui-ci est out-of-date ou s'il a été modifié à la hussarde
(contrôle de cohérence).

Voilà...

Christian


"Paul Sean" a écrit dans le message de
news:bmjg3u$odf$
> Bonjour,
>
> Je cherche actuellement une solution de protection qui permet de faire
une
> version Demo de notre application, puis le déblocage par une clé, si
> possible avec une extension Server (pour générer les clé à partir de
notre
> serveur web).
>
> Je ne veux pas de Armadillio, Asprotect, ou autre type encrypteur, qui
sont
> déja casser juste avec un unpacker, éventuellement un ActiveX ou un
DLL.
>
> Que me conseillez-vous, protection utilisez-vous en général ?
>
> Merci d'avance
>
>
>
>
>
>
>




Avatar
The Ultimate Video Game Museum
Moi j'ai bien une solution que j'ai déjà utilisée ...

Il suffit de créer un petit soft (qu'on va appeler "codeur") qui génère un
code (qu'on va appeler "clé") en fonction du nom de l'utilisateur et une
date. Pour simplifier on va dire que le calcul de la clé correspond à [nom x
date].A la première utilisation l'utilisateur doit vous appeler et donner
son nom d'utilisateur.
Il suffit alors de saisir dans le "codeur" le nom ainsi que la date limite
d'utilisation.
La clé générée est alors à donner à l'utilisateur.

Le programme identifiera alors jusqu'à quelle date l'utilisateur peut
utiliser le programme ou certaines fonctions en faisant le calcul inverse à
l'aide de la clé et du nom d'utilisateur.

Dans ton cas ce système peut être gardé. pour celà il suffit qu'à la
première utilisation le programme crée la clé en fonction de sa date
d'installation qui est identifiable par les propriétés de ton exécutable
(Créé le : xx/xx/xxxx) dans un fichier. la clé indique alors la date limite
et une fois celle-ci dépassée, le programme change la clé par une autre qui
sera toujours considérée comme érronée avec par exemple toujour le même
calcul [nom x date] mais où [date = 99/99/9999]. Le programme comprendra
alors qu'il ne doit plus créer de clé valide et que celle-ci doit être
saisie manuellement. A partir de là on revient au système de l'appel
téléphonique pour obtenir le nouveau code.

Je suis pas sûr d'avoir été très clair ...


Topper

Webmastering, webdesign des sites :
The Ultimate Video Game Museum : http://www.TUVGM.com/
TUVGM Live Playing ! : http://www.TUVGM.com/liveplaying/
FreeDO France : http://www.TUVGM.com/freedo/




"Christian Hugoud - Xtrem7" a écrit dans le message de
news:bmjmjv$7dc$
Personnellement, j'utilise un fichier qui contient le nom de
l'utilisateur (qui apparaît en clair lorsque le soft n'est plus en
démo).

Ce fichier est mis à jour au travers de mon site (interrogation d'une
page php qui sert de serveur et à laquelle je passe le nom du client) et
contient alors des dates de péremption, des données de configuration
etc... Bien sur le fichier est crypté.

Le logiciel ne fonctionne qu'en mode démo s'il ne trouve pas le fichier
ou si celui-ci est out-of-date ou s'il a été modifié à la hussarde
(contrôle de cohérence).

Voilà...

Christian


"Paul Sean" a écrit dans le message de
news:bmjg3u$odf$
> Bonjour,
>
> Je cherche actuellement une solution de protection qui permet de faire
une
> version Demo de notre application, puis le déblocage par une clé, si
> possible avec une extension Server (pour générer les clé à partir de
notre
> serveur web).
>
> Je ne veux pas de Armadillio, Asprotect, ou autre type encrypteur, qui
sont
> déja casser juste avec un unpacker, éventuellement un ActiveX ou un
DLL.
>
> Que me conseillez-vous, protection utilisez-vous en général ?
>
> Merci d'avance
>
>
>
>
>
>
>




Avatar
Paul Sean
Merci pour ta proposition, honnêtement j'avais fait dans le passé un système
maison, il a été cassé en 2 minutes, maintenant je préfère investire dans
une solution plus fiable et complète.

Quand on voit le temp de développement puis le résultat, je préfère me
concentrer plus dans le développement de mon application que celle de la
protection, je laisse le soin aux spécialistes, ils connaissent mieux les
problèmes et savent (en général) y résoudrent.

Je sais qu'aucune protection n'est 100% sure, mais bon si j'ai un choix à
faire entre laisser une porte ouverte sans verrou et mettre un verrou, je
préfere mettre un verrou... ;-)



"The Ultimate Video Game Museum" a écrit dans le message
de news:3f8d706a$0$20167$
Moi j'ai bien une solution que j'ai déjà utilisée ...

Il suffit de créer un petit soft (qu'on va appeler "codeur") qui génère un
code (qu'on va appeler "clé") en fonction du nom de l'utilisateur et une
date. Pour simplifier on va dire que le calcul de la clé correspond à [nom


x
date].A la première utilisation l'utilisateur doit vous appeler et donner
son nom d'utilisateur.
Il suffit alors de saisir dans le "codeur" le nom ainsi que la date limite
d'utilisation.
La clé générée est alors à donner à l'utilisateur.

Le programme identifiera alors jusqu'à quelle date l'utilisateur peut
utiliser le programme ou certaines fonctions en faisant le calcul inverse


à
l'aide de la clé et du nom d'utilisateur.

Dans ton cas ce système peut être gardé. pour celà il suffit qu'à la
première utilisation le programme crée la clé en fonction de sa date
d'installation qui est identifiable par les propriétés de ton exécutable
(Créé le : xx/xx/xxxx) dans un fichier. la clé indique alors la date


limite
et une fois celle-ci dépassée, le programme change la clé par une autre


qui
sera toujours considérée comme érronée avec par exemple toujour le même
calcul [nom x date] mais où [date = 99/99/9999]. Le programme comprendra
alors qu'il ne doit plus créer de clé valide et que celle-ci doit être
saisie manuellement. A partir de là on revient au système de l'appel
téléphonique pour obtenir le nouveau code.

Je suis pas sûr d'avoir été très clair ...


Topper

Webmastering, webdesign des sites :
The Ultimate Video Game Museum : http://www.TUVGM.com/
TUVGM Live Playing ! : http://www.TUVGM.com/liveplaying/
FreeDO France : http://www.TUVGM.com/freedo/




"Christian Hugoud - Xtrem7" a écrit dans le message


de
news:bmjmjv$7dc$
> Personnellement, j'utilise un fichier qui contient le nom de
> l'utilisateur (qui apparaît en clair lorsque le soft n'est plus en
> démo).
>
> Ce fichier est mis à jour au travers de mon site (interrogation d'une
> page php qui sert de serveur et à laquelle je passe le nom du client) et
> contient alors des dates de péremption, des données de configuration
> etc... Bien sur le fichier est crypté.
>
> Le logiciel ne fonctionne qu'en mode démo s'il ne trouve pas le fichier
> ou si celui-ci est out-of-date ou s'il a été modifié à la hussarde
> (contrôle de cohérence).
>
> Voilà...
>
> Christian
>
>
> "Paul Sean" a écrit dans le message de
> news:bmjg3u$odf$
> > Bonjour,
> >
> > Je cherche actuellement une solution de protection qui permet de faire
> une
> > version Demo de notre application, puis le déblocage par une clé, si
> > possible avec une extension Server (pour générer les clé à partir de
> notre
> > serveur web).
> >
> > Je ne veux pas de Armadillio, Asprotect, ou autre type encrypteur, qui
> sont
> > déja casser juste avec un unpacker, éventuellement un ActiveX ou un
> DLL.
> >
> > Que me conseillez-vous, protection utilisez-vous en général ?
> >
> > Merci d'avance
> >
> >
> >
> >
> >
> >
> >
>
>




Avatar
Adam Pietrasiewicz
<<< Attention - mon adresse dans l'entete de ce message >>>
<<< est une adresse ANTISPAM - pour m'ecrire cliquez sur >>>
<<< http://www.cerbermail.com/?DQr0g2Y88R >>>
=================================================== Le 15 pa¼dziernika 2003 18:27:22 Paul Sean a ecrit dans un message
news:bmjsb1$gka$



Merci pour ta proposition, honnêtement j'avais fait dans le passé un systeme
maison, il a été cassé en 2 minutes, maintenant je préfere investire dans
une solution plus fiable et complete.



Je pense qu'il faut toujours rappeler une chose:

Il n'est pas possible de proteger son logiciel efficacement par le
programme. Un crackeur peut TOUJOURS suivre le deroulement des
operations PAS A PAS et changer les valeurs comme il veut.

On peut rendre la detection des moyens de protection difficile, mais
elle ne sera jamais sure. JAMAIS.

Il est evident, qu'une cle encodee selon un algorythme vachement
complique sera difficile a casser par quequ'un, qui essayerait de le
faire en l'approchant par la logique.

Mais ce n'est pas comme ca que cela se passe!

Pour casser la securite on regarde le programme pas a pas et on trouve
TOUJOURS l'endroit ou la securite bloque. On peut rendre cette tache
un peu plus difficile, mais c'est tout.

Quelques regles:

1.Ne pas faire de comparaisons de cle betes, dans le style

If Cle="ok" then...

car pour casser ca il suffit de faire en sorte que la cle ait TOUJOURS
la valeur "ok" et le tour est joue. C'est facile a faire.

2. Ne pas inscrire de valeurs de controle dans les registres - les
moniteurs de registres detectent CHAQUE inscription et ca ne fait que
faciliter la tache au crackeur.

3. Ne JAMAIS donner de msgbox ou autres messages au moment ou le
programme detecte les changements dans la cle ou autre tentative de
crackage.

4. Ne jamais rendre le programme operationnel de suite, apres
l'introduction du mot de passe ou de la cle. Il faut le faire au bout
de 2 ou 3 lancements, en utilisant pour ceci des procedures qui ne
font que preparer les informations qui seront utilisees au lancement
suivant, sans tout de suite rendre le programme operationnel.

Nous savons a peu pres TOUS comment marche un programme - il ne fait
qu'executer sequentiellement les ordres. Ces ordres peuvent etre
compliques et nombreux, mais peu importe - c'est du traitement
SEQUENTIEL. Un crackeur SAIT observer le deroulement du programme
comme s'il lisait dans un livre ouvert. Il SAIT intervenir sur les
valeurs de variables, donc la seule chose que l'on puisse faire c'est
de lui compliquer le travail au maximum.

Je suis auteur d'un programme qui a ete protege par une cle selon les
indications de 3 crackeurs. Ils l'ont regarde par la suite, ils ont
CASSE ma protection au bout de 8 heurs a peu pres de travail, et ils
on dit qu'on peut dire que le programme est relativement correctement
protege. Correctement, parce que les crackeurs sont des
informaticiens, donc des gens FEIGNANTS, et si casser une protection
leur prend trop de temps ils preferent parfois s'occuper de quelque
chose d'autre... PARFOIS, parce que si la protection est trop bien
faite cela peut constituer un defi, et a ce moment la, nous, les
auteurs du soft, n'avons pas de chance de gagner.

--
Adam Pietrasiewicz
Pologne


---
Ten list zosta³ wys³any przy u¿yciu Go³±bka http://www.amsoft.com.pl/golabek
Avatar
Adam Pietrasiewicz
<<< Attention - mon adresse dans l'entete de ce message >>>
<<< est une adresse ANTISPAM - pour m'ecrire cliquez sur >>>
<<< http://www.cerbermail.com/?DQr0g2Y88R >>>
=================================================== Le 15 pa¼dziernika 2003 23:36:48 Daniel Lapointe a ecrit dans un
message news:


Je suis débutant en VB6. Mais, sans vouloir te contrarier, je crois qu'il
est possible de protéger a 99 - 100% son programme.



Le fait de connaitre ou de ne pas connaitre le VB n'a rien avoir dans
cette histoire.

Avec l'encodage de clé sur un site Web, dans le registre, sur le disque et a
maintes autres places, je crois qu'il serait tres difficile de tout décoder.
On cré son propre codage/décodage, et on met les parties de la clé partout,
sur le Web dans des fichiers protégés par htaccess, bref...



Oui. Comme je l'avais dit, il est possible de creer une cle tellement
difficile a dechiffrer qu'il ne serait pas possible de la dechiffrer.
Il n'est pas difficile d'inventer un tel algorythme ou en utiliser un
existant.

Bon, il est évident qu'un bon crackeur qui s'y met pourra toujours arrivé a
percer la protection du site Web, a retrouver le bout dans le registre et
aux autres place, a trouver le codage et a réunir tous les p'tits bouts,
mais c'est plus que 8 heures qu'il lui faudra, du moins je crois.



Je bien l'impression que nous ne nous comprenons pas.

Et pour ceux qui veulent une protection sure, il y a toujours des p'tits
trucs, du genre de mettre son appli en plein écran et toujours au premier
plan, fermer toutes les applications ouvertes et empecher d'en ouvrir
d'autres, etc... Bien que ces trucs soient tres désavantageux...



Bon, je m'explique encore une fois:

Un bon crackeur ne va meme pas essayer de chercher a casser la cle -
c'est inutile.

Un programme charge en memoire PEUT etre lu, en code assembleur et
chaque ordre peut etre suivi PAS A PAS. A ce moment la la complication
de la cle n'a AUCUNE importance, car quelque part dans le programme
nous DEVONS faire une comparaison, et d'une facon ou d'une autre dire
OK - CETTE CLE EST LA BONNE. Et le crackeur intervient juste a ce
niveau la, et non pas ailleurs. Le crackeur s'en fiche pas mal des
algorythmes que nous avons invente - il est aussi utile d'encoder la
cle par PGP que par ROT 13 - de toute facon la cle ne sera jamais
dechiffree, car ce n'est pas utile ni necessaire pour un crackeur. La
complication de la cle peut etre importante pour contrer un malin qui
sans savoir utiliser le WinIce essayera de casser le chiffrage. Elle
est sans importance pour des specialistes. Et les specialistes il y en
a, je t'assure. Ce n'est vraiment pas difficile - si on apprend les
bases de l'assembleur on peut y aller.

Mettre au premier plan, fermer d'autres applications ou des
applications precises (par exemple WinIce), fermer le programme si le
debuggeur est en marche ne sert A RIEN! Il existe maintenant des
outils qui simulent le systeme et qui lancent les programmes a
l'interieur d'eux memes pour pouvoir les debugger....

La seule chose que l'on puisse faire est de compliquer la vie aux
crackeurs - ca oui, on peut le faire. Est-ce efficace? Surement pas!

--
Adam Pietrasiewicz
Pologne
---
Ce message vous a ete apporte par Le Pigeon
http://www.amsoft.com.pl/golabek
Avatar
Adam Pietrasiewicz
<<< Attention - mon adresse dans l'entete de ce message >>>
<<< est une adresse ANTISPAM - pour m'ecrire cliquez sur >>>
<<< http://www.cerbermail.com/?DQr0g2Y88R >>>
=================================================== Le 16 pa¼dziernika 2003 10:13:57 The Ultimate Video Game Museum a
ecrit dans un message news:3f8e5343$0$2782$

Je suppose que de toutes façons en ayant un code généré en fonction d'un nom
d'utilisateur ça ne doit pas être tres compliqué a casser ... ce n'est
qu'une question de logique et en ayant deux noms d'utilisateurs et leur clé
associée il suffit d'établir le rapport suivant ou "Codage" est vérifié dans
les deux cas :
Nom1 x Codage = Clé1
Nom2 x Codage = Clé2

C'est beaucoup plus compliqué que ça ou je ne suis pas loin de la vérité ?

D'ailleurs ... est-ce que quelqu'un connait un décompilateur qui permertrait
de recréer un code source a partir d'un programme compilé ?



Les decompilateurs c'est une legende.

On peut suivre le deroulement du programme en assembleur, ca oui. Mais
autrement non.

J'ai vu un programme qui se disait 'decompilateur" de vb6, mais
c'etait une cata!

Non, les decompilateurs en langage natif, ca n'existe pas pour VB - on
peut le dire haut et fort.

Et n'oublions JAMAIS une chose en preparant la protection - la
complication du codage de la cle n'a pratiquement AUCUNE importance.
La structure du programme y est beaucoup plus importante. Et, bien
sur, le plus important, c'est l'approche marketing - oui, ca, ca peut
VRAIMENT proteger un programme. Mais ce n'est pas possible toujours et
partout.

Mon client mail est disponible sur le net. Au debut j'ai voulu le
vendre, a 5 ou 10 euro piece avec un systeme de protection. Finalement
j'ai decide de prendre une auttre approche - je vais gagner en vendant
l'espace publicitaire qu'il possede. C'est plus sur.

--
Adam Pietrasiewicz
Pologne
---
Ce message vous a ete apporte par Le Pigeon
http://www.amsoft.com.pl/golabek