Discussion :

[Eric Beaumard]

Bonjour,

Je me suis posé la question suivante, ceci pour mettre au point
une protection de mes programmes par dongle:

Je dispose sur mes dongles de quelques 2.5 ko octets accessibles
en R/W depuis mes programmes et pas par l'explorer de fichier
de windows.

Je voudrais déporter sur le dongle une portion du code procédural
du programme pour que, faute d'avoir ce code, un éventuel hackeur
ait à programmer ce qui manque dont à comprendre le programme
et à savoir programmer.

Et puisque je veux faire cela avec plusieurs programmes je ne voudrais pas,
idéalement, avoir à me creuser la tête pour générer de tables d'éxécution
codées sur un octet adressant des procédures/functions nécessaires
au programme.


J'ai donc pensé à amputer, par exemple, l'exécutable de ces 50 derniers octets
et de les mettre sur le dongle. Un autre programme, stocké sur le PC serait
chargé de prendre la portion majeure du programme, de la fusionner/compléter
avec les 50 octets lu sur le Dongle et de l'éxécuter.

J'ai donc essayé, "bêtement", pour voir, de prendre un toto.exe, de renomme en toto.txt
et de le séparer en deux fichiers toto1.txt (donc toto.txt amputé de ses 50 derniers octets)
et toto2.txt fait du reste. Ensuite j'ai essayé, toujours avex avec des copier-coller de reformer
toto.txt, de le renommer, et de le lancer, sans succès ...

Des idées ?

Eric;

[Caribensila]

Bonjour,

Utilise TFileStream pour segmenter/recoller ton .exe.

[Eric Beaumard]

Ok, j'avais déjà entendu parler de ces objets. Par contre, et pour ma culture personnelle, quelqu'un peut-il m'expliquer pourquoi la segmentation/refusion du .exe en passant par des copier-coller sur la version ascii de l'exe ne redonne pas un exe fonctionnel (si je ne me suis pas trompé dans la manipulation) ? Qu'est-ce qui est perdu ? j'ai utilisé le bloc note, peut-être que c'est lui omet d'afficher/copier des octets. Il faudrait peut-être essayer avec un éditeur plus professionnel, comme Uedit ou autre. Quelqu'un confirme-t-il ce que je dis ?

Eric.

Bonjour,

Utilise TFileStream pour segmenter/recoller ton .exe.

[Caribensila]

Qu'est-ce qui est perdu ?

Probablement des caractères invisibles dans le Bloc-notes.

Tu peux peut-être essayer WordPad...

[Eric Beaumard]

J'avais aussi pensé à ce que le programme à protéger soit lançable mais pas complètement fonctionnel. Et que pour qu'il le devienne il charge 50 octets du dongle et les introduise directement
en RAM dans la zone de cette RAM où est stocké l'exécutable. Est-il possible d'écrire des octets dans la RAM et de lancer l'éxécution sur cette zone ? ou, d'une manière ou d'une autre, de charger une portion de l'exécutable, pendant l'exécution ?

Je donne ma langue au chat ...

Eric.

[Caribensila]

Le plus simple, pour commencer, serait de reconstruire ton .exe sur le disque dur, de le lancer avec ShellExecute par exemple, puis de détruire aussitôt l'exe ainsi reconstruit...

[philnext]

Tu peux découper avec ça et recomposer avec la commande COPY .

[Eric Beaumard]

Tu peux découper avec ça et recomposer avec la commande COPY .

Merci Philnext, voilà un outil bien pratique. Mais peux-tu me dire comment tu verrais le problème suivant: Premièrement je dois scinder l'executable en deux fichiers. Un qui fait 50 octets (ou à peu près, je n'ai que 2.5 ko de disponibles sur la clé et j'ai plusieurs programmes à protéger) et l'autre le reste. Admettons que ton programme accepte de créer un fichier de 50 octets (je n'ai jamais vu un fichier de moins de 1 ko), il faudra que je les mette sur le dongle et que je les sorte du dongle sur le disque, sans qu'aucun octet ne soient changés ou oubliés, avant recomposition. Et là ....



Eric

[Caribensila]

Pour faire tout ça en mémoire, je pense que tu devras utiliser les fichiers paginés.
Voir :
- CreateFileMapping
- MapViewOfFile
- UnMapViewOfFile
- CloseHandle

Mais si tu amputes ton exe des 50 derniers octets à l'aveuglette, il risque fort de se crasher lamentablement au lancement en cas d'absence du dongle. Ca ne fera pas très "pro".

[Montor]

J'ai donc pensé à amputer, par exemple, l'exécutable de ces 50 derniers octets
et de les mettre sur le dongle. Un autre programme, stocké sur le PC serait
chargé de prendre la portion majeure du programme, de la fusionner/compléter
avec les 50 octets lu sur le Dongle et de l'éxécuter.

Tu peux placer ton code sur une dll ...mais les dongle très contraignants avec trop de licences si tu es électronicien tu peux utilises les PIC protégé via usb ,simple algo de hachage ....

[Paul TOTH]

alors quelques remarques

1) les dongles c'est ch**t pour l'utilisateur légal et ce n'est pas une protection efficace contre un hacker déterminé.

2) placer une partie du code sur le dongle n'a pas bcp d’intérêt, je doute que 50 octets représentent une partie cruciale de ton application, et comment compte tu gérer les mises à jours ?

3) si je puis me permettre, ta connaissance des binaires étant ce qu'elle est, tu n'es peut-être pas de taille pour inventer un système de protection efficace...peut-être devrais-tu te contenter de placer un numéro de licence sur le dongle ça sera déjà assez pénible pour les utilisateurs légaux et pas moins contraignant pour les hackers.

[Teddy]

Tu peux placer ton code sur une dll ...mais les dongle très contraignants avec trop de licences si tu es électronicien tu peux utilises les PIC protégé via usb ,simple algo de hachage ....

Bonne idée, mais pourquoi un PIC particulièrement?
N'importe quel uC verrouillé en lecture fait l'affaire.
Enfin, ça reste une solution un peu onéreuse...

[Teddy]

Le dongle a quand même un avantage: on peut utiliser le logiciel sur n'importe quel PC en déplaçant le dongle...

[Paul TOTH]

Le dongle a quand même un avantage: on peut utiliser le logiciel sur n'importe quel PC en déplaçant le dongle...

sans dongle c'est encore plus simple de le faire ^^

dans la boîte de ma femme les ports USB sont désactivés dans PolEdit afin d'interdire l'usage de clés USB (et éviter les virus)...tu fais comment avec un dongle USB ?

et si je veux faire du TSE ? je place le dongle sur le serveur ? si toute fois il a un port USB.

[Teddy]

Oui, effectivement, dans ce cas la protection par dongle est problématique!!

Tout dépend de l'environnement.

Dans mon cas, j'utilisais CodeVision, excellent compilateur C pour uC Atmel.
La licence me permettait de l'installer sur 2 postes (en l'occurence PC de bureau et portable).

Un jour mon DD s'est crashé (et je n'avais pas fait d'image de sauvegarde !).
Pour le réinstaller, il fallait que j'achète une nouvelle licence.

Depuis, je suis passé sur AVR-co (compilateur Pascal de E-LAB), qui est fourni avec le programmateur USB qui sert aussi de dongle de protection.
Je peux donc l'installer sur autant de PC que je veux.

[Caribensila]

La protection par dongle a des effets pervers inattendus mais bien connus :

1) statistiquement, on trouve plus de versions piratés des logiciels protégés par dongle que d'autres. Cela s'explique par le fait qu'outre les utilisateurs qui utilisent habituellement les logiciels piratés, on trouve aussi les utilisateurs légaux qui trouvent moins contraignantes les versions crackées.

2) du fait de la facilité de trouver des versions crackées, il devient beaucoup plus simple et commode de télécharger une version piratée que de se procurer une version légale par la poste ou par distributeur. Et ceci même pour un utilisateur qui était disposé à payer une licence !

3) à une époque où on veut tout, tout de suite et sans effort, la protection par dongle semble avoir bien des inconvénients !

[Teddy]

Certes, mis les softs protégés autrement que par dongle sont aussi crackés.
Et pour pirater un soft protégé par dongle, il faut pratiquement déjà posséder le dongle pour sniffer ses échanges avec le soft.

[Caribensila]

Peut-être...

Mais le problème est qu'un bon logiciel cracké 1 seule fois fera plusieurs fois le tour de la planète en quelques jours sans la moindre publicité. ^ ^

[Paul TOTH]

Certes, mis les softs protégés autrement que par dongle sont aussi crackés.
Et pour pirater un soft protégé par dongle, il faut pratiquement déjà posséder le dongle pour sniffer ses échanges avec le soft.

c'est possible sans cela...ceci dit, je ne sais pas ce que ça donne avec un dongle USB mais à je me souviens que sous DOS avec les dongles sur port série, il existait des petits programmes qui enregistraient les échangent entre le dongle et le soft pour pouvoir reproduire un dongle virtuel...j'imagine que la même technique est utilisable en USB et ça rend le piratage on ne peut plus simple.

[Eric Beaumard]

alors quelques remarques

1) les dongles c'est ch**t pour l'utilisateur légal et ce n'est pas une protection efficace contre un hacker déterminé.

Tout à fait. Je suis conscient de la chose, mais le public à qui s'adresse les programmes
n'est pas composé de hackers de haut niveau et de haute détermination. Je juge le rapport
(Niveau des hackers potentiels)/(Niveau de la protection que je peux produire) inférieur à 0.5 et
ça me va.

2) placer une partie du code sur le dongle n'a pas bcp d’intérêt, je doute que 50 octets représentent une partie cruciale de ton application, et comment compte tu gérer les mises à jours ?

Et bien à chaque mise à jour je prends les 50 derniers octets de l'exe et je les met sur le dongle.
L'exe ne peut pas fonctionner sans ces 50 octets, qu'ils représentent une partie importante ou pas de l'application, et les retrouver semble très difficile.

3) si je puis me permettre, ta connaissance des binaires étant ce qu'elle est, tu n'es peut-être pas de taille pour inventer un système de protection efficace...

peut-être devrais-tu te contenter de placer un numéro de licence sur le dongle ça sera déjà assez pénible pour les utilisateurs légaux et pas moins contraignant pour les hackers.

Oui c'est sans doute ce que je vais faire. Je pense aussi à placer sur le dongle des paramètres
d'affichage des objets visuels ou autre du programme. De sorte que sans eux, sans leur valeur
exacte le programme soit inutilisable.

Paul, est-il possible, à l'exécution, qu'un exécutable,
d'une manière ou d'une autre (en changeant du code machine en RAM ou en détournant
l'exécution sur du code machine écrit par l'application elle-même en mémoire vive), change son propre code machine ? Windows s'y opposera surement. Je ne sais pas.

Je pouvais faire ça avec mon ZX81 il y a très longtemps, et je m'amusais bien en assembleur Z80 ! Je crois aussi me souvenir que je faisais ça en GFA basic sur mon ATARI 520 ST et sur mon QL Sinclair aussi sur un 68008 en assembleur motorola ... Les choses se sont compliquées mais le principe de base reste le même: du code machine exécuté en RAM.