Discussion :

[liv]

Bonjour à tous !

Voilà...dans mon appli (développé sous VC++ .NET avec les MFC) je crée des fichiers que je souhaiterais ne rendre exploitables que par mon appli elles-même.

En fait ce n'est ni plus ni moins du XML que je mets dedans, toutefois, je souhaiterais protéger le contenu de ces fichiers...de faire en sorte à ce qu'il soit de format propriétaire à mon appli. En somme, si je fais "ouvrir avec" sous Windows...le fichier est illisible et donc protégé.

J'ai déjà fais l'association de l'extension .toto avec mon programme via mon InstallShield mais il me reste cette partie de protection à traiter.

Voilà voilà....d'où ma question finale: Comment fait-on sous VC++ pour qu'un fichier *.toto créé par mon appli toto.exe, ne soit exploitable que par cette appli et uniquement par elle ?

Merci d'avance.

[mat.M]

Comment fait-on sous VC++ pour qu'un fichier *.toto créé par mon appli toto.exe, ne soit exploitable que par cette appli et uniquement par elle ?

N'importe quel fichier devient "propriétaire" à partir du moment où il est binaire et structuré de manière particulière
Faisons simple si on prend une structure en C du genre

Code :

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

1
2
3
4
5
6
7
 
typedef struct{
sommet X;
sommet Y;
sommet Z;
}
triangle;

Une fois que l'on enregistre une variable de type triangle sous forme binaire , sans la description ( déclaration ) donnée précedemment de la structure il est quasi 'impossible de savoir comment le fichier est organisé.
Ton fichier toto c'est toi seulement qui sait comment il est organisé si tu est le seul à posséder le code source...

A moins de bidouiller avec un éditeur hexa ( y'a des gens qui n'ont que ça à faire sur terre )

En fait ce n'est ni plus ni moins du XML que je mets dedans, toutefois, je souhaiterais protéger le contenu de ces fichiers...

Impossible de verrouiller un fichier .XML parce que tout simplement c'est du texte !!
Sinon c'est plus un fichier XML !

[farscape]

salut,
Si ton fichier est en XML , il sera "readable" par tout le monde ,il ne voudra pas forcément dire quelque chose pour tout le monde..
Changer l'extension évite l'association du fichier à une application.
Si tu veux vraiment protéger tes fichiers, il faudra peut être abandonné XML ou plus compliqué crypter les fichiers ...
Je vois pas trop la ..
Au pire si tu lis le fichier en une seule fois en mémoire
Moi je le zipperais avec un mot de passe
Et je le dezipperais en mémoire.

[liv]

Salut à tous les deux.

Si je comprends bien, du fait que le contenu de mon fichier soit de forme XML rien empêchera personne de le lire finalement, à part si comme dit farscape...je le crype.

Je croyais que via Visual il était possible de protéger le contenu de n'importe quel fichier...me suis gourré.
Je crois que je vais m'orienter vers un cryptage des données...ça sera plus simple.

[la drogue c'est mal]

"readable" => lisible

[tibs]

bonjour,

tu pourrais peut-être coder en vigenere avant d'écrire ton fichier et décrypter ensuite.
http://www.apprendre-en-ligne.net/crypto/vigenere/ y'a des tonne d'article, google est ton ami

C'est un codage très simple à mettre en oeuvre. Si j'ai bien compris c'est plus dissuasif qu'autre chose?

reste à savoir si tes fichier .toto (xml) ne doivent pas être exploités par quelqu'un d'autre....

@+ tibs.

[Caine]

Bonjour,
La solution d'enregistrer au format binaire est une bonne solution.

Bémole cependant, chaque enregistrement doit avoir une taille fixe, à moins de prévoir un entête de fichier contenant une table d'indexation.

Sinon, crypter les données est aussi une solution, mais n'importe quel "fan" de decryptage connaitra probablement l'algorithme que tu utilises, sauf si tu en développes un propriétaire aussi.

[mat.M]

bonjour,

tu pourrais peut-être coder en vigenere avant d'écrire ton fichier et décrypter ensuite.

Oui mais le risque de faire sauter la protection et décrypter le fichier est élevé
Crypter un fichier au moyen d'une table de Vigenere c'est pas forcément fiable

[liv]

C'est clair que de toute manière rien n'arrêtera un bon fan de cryptage...mais bon le truc est de sécuriser un minimum mes données. Il n'y a rien de véritablement confidentiel.

Je crois que vais opter pour cette solution.
Merci à tibs pour le lien c'est intéressant mais j'ai déjà une solution de cryptage qui est pas mal. Je fais du codage sur 128bits...largement suffisant pour ma soluce.

Si d'autres on une autre idée ou une tech de cryptage elle est de toute manière la bienvenue.

[farscape]

un bon zip des familles avec un password ça le fais non ?

[liv]

C'est vrai que c'est efficace mais une fois j'avais récupéré un programme capable de péter ces mots de passe...un clic et zou y'a plus mot de passe zip. J'avais aussi celui qui pétait les mots de passe excel...y'a des balèzes quand même.

Pour mon algo de cryptage, il est propriétaire et vu que mon appli risque fortement d'être commercialisée, je risque d'être emmerdé. Faudra le référencer quoi.

[r0d]

Ca me fais penser à un truc:
Dans le jeu Warcraft3 (et certainement dans d'autres), les meshes qui représentent les personnages en 3D ne sont pas dans des fichiers. Ils sont "insérés" dans l'executable il me semble. Je pense qu'ils font ça pour que l'on ne puisse pas les récupérer.
Peut-être pourrais-tu utiliser une technique équivalente?

[liv]

Huuumm...oui mais je ne vois pas trop comment. Mais finalement ça sort un peu de mon contexte puisque les fichiers peuvent être exportés où l'on veut en fait. Comme un .doc par exemple.

[r0d]

en effet...

[brainstorming]Sinon , tu crées ton propre système de cryptage. Genre quelque chose de simple qui te met les bits dans le désordre (il faudrait tout de même un CRC).[/brainstorming]

[Ti-R]

Cryptage: du moins sécurisé au plus sécurisé, de haut en bas.
-> RSA
-> DES
-> AES

[liv]

RSA c'est le moins sécurisé? Je pensais que vu que c'était basé sur l'intégrité des nombres premiers et codés sur 256 bits ça faisait de lui un code impétable ?! En même temps y'a longtemps que je n'ai plus suivi tout cela.

[delire8]

Mathématiquement parlant, le casser c'est dur (je veux dire : retrouver la clé, etc...).
Là, des gars du MIT (il me semble, peut etre un autre institut) y sont allé au bruteforce. Evidemment, ca finit par casser.

Bref, le meilleur cryptage au monde cédera toujours contre le duo :
bruteforce + temps.

Cordialement

[Ti-R]

Oui c'est du bruteforce mais quand même amélioré

AES est certifié inviolable et a été retenu par la NSA

En supposant que l'on puisse construire une machine qui pourrait cracker une clé DES en une seconde (donc qui puisse calculer 255 clés par seconde), alors cela prendrait encore 149 mille milliards d'années pour cracker une clé AES. Pour donner un ordre d'idée plus concret, l'univers est vieux de 20 milliards d'années au maximum.

Cela montre que le brute force n'a plus vraiment d'emprise sur de tel algorithme, à moins de trouver des failles dedans

source: securiteinfo

[farscape]

faut pas tomber dans le delire aussi ,il fait une applie commerciale

il y a un lien pas mal sur codeproject :
http://www.codeproject.com/samples/cryptest__mfc_style_.asp

[Ti-R]

Non faut pas tomber dans le délire

Mais c'est pas super super dur à implémenter... donc autant coder quelque chose de sur, si c'est pour avoir "un peu" de sécurité

Personnellement avant de regarder AES et DES j'avais réfléchi sur le problème et j'ai pondu un algorithme de mon cru qui fonctionne grosso modo à la manière du DES et de l'AES, mais cela doit être bien moins sécurisé car je m'appuie sur une formule qui génère du bruit via 3 nombres premiers. Donc si une personne accrochée découvre une faille dans la formule, elle peut casser mon code.

Tout dépend des besoins biensur

D'ailleurs je vois que sur ton lien farscape, c'est le DES qui est utilisé, je pense que cela suffit largement pour une application normale
Tout le monde n'a pas son doctorat de math ou de stats dans la poche pour casser de tel algorithme.

A mon avis, si un pirate veut essayer de casser un code du genre, il cherche à récupérer la clé, qui sera bien plus facile à récupérer à mon avis... donc c'est plus un problème de lack du système et non de l'algorithme de cryptage que l’on rencontre aujourd’hui.