Discussion :

[Kurisu]

Bonjour,

Je cherche une solution software, voire même juste des informations pour signer/marquer du code source C++. Je pense notamment à des techniques de filigrane (watermarking) ou stéganographiques pour pouvoir identifier un fichier ou un ensemble de fichiers de code source.

Pour le contexte, mon entreprise veut permettre à nos clients d'avoir accès au code source, et biensûr, prevenir toute potentielle faille de sécurité du côté du client. Il nous faut surtout pouvoir répérer des leaks potentiels et savoir de quel client ca vient.

Bien sûr, il faut que ce soit suffisamment subtil pour passer inapercu, mais aussi solide pour éviter que le client efface (sciemment ou pas) ce marquage.

Est-ce que vous avez des idées ou connaissez des solutions complètes pour cela ?

Merci pour vos réponses.

Kurisu

[dourouc05]

Salut,

Pour le code assembly, tu peux utiliser le Dotfuscator. Il y a un onglet PreMark, qui permet d'appliquer un filigrane sur un assembly. Je ne sais pas comment ça fonctionne, mais ça ne va pas convenir à tes besoins (C++, et non C++/CLI).

Par contre, cela donne une piste : il existe des obfuscateurs. Peut-être y en a-t-il un qui accepte le C++ et qui propose la même fonctionnalité.

Tu peux aussi faire des modifications aléatoires à chaque appel de fonction, l'aléatoire contenant une référence à ton client. Évidemment, la partie ajoutée doit être différente pour chaque symbole, sinon un simple Rechercher/Remplacer dans la solution, et c'est parti... C'est plus dans le domaine de l'obfuscation, mais je ne sais pas si c'est automatisable quand on veut faire de telles modifications...

[Mac LAK]

Rendre le binaire compilé "indécompilable", c'est à peu près facile bien qu'aucune technique ne soit parfaite.

Par contre, côté fichiers source, c'est une autre paire de manches : comment insérer quelque chose alors que chaque caractère est visible à l'écran ?? Le marquage va forcément se voir !!! C'est différent, là, d'une légère variation de pixels sur plusieurs centaines de milliers, et où surtout la couleur "exacte" du pixel ne modifie pas l'aspect général de l'image (c'est même la base du codage JPEG)... Avec un fichier texte, mettre "E" à la place de "e", ça peut changer beaucoup de choses.

Tu as bien la solution d'insérer, en lieu et place d'espaces / tabulations, des caractères invisibles, mais ça pose un souci sous Windows : la police/encodage utilisés... Sous DOS, ça allait, le caractère 127 pouvait jouer ce rôle. Sous Windows, plus difficile, car tu ne peux pas présumer de la configuration de celui qui va lire ton code...

Reste la solution de n'utiliser QUE des espaces dans le code, et de mettre parfois des tabulations suivant un encodage précis afin de valider un "1" ou un "0" (ex : une tabulation = 0, deux tabulations = 1), et donc recomposer un chiffre binaire ayant un sens au final.

Problème, certains éditeurs de texte convertissent d'office les tabulations en espace et réciproquement, ce qui peut faire disparaître le watermark construit de cette manière... Je te passe le fait d'utiliser un "beautifier" de code, qui remanierait toute organisation spatiale des éléments de code au sein du fichier source et ferait disparaître là aussi n'importe quel marquage.

Au final, la seule solution (presque) viable que je vois, c'est de ne montrer les sources que sous une forme non copiable facilement, notamment binaire : soit un PDF avec saisie/copie interdite, soit une image binaire (N&B pour un gain de place) avec des systèmes anti-OCR dessus de type filigrane, fond strié, etc. afin d'empêcher leur conversion automatique.


Quoi qu'il en soit, distribuer les sources, c'est s'exposer à la possibilité qu'on le vole / détourne, et c'est strictement impossible à empêcher : un humain pourra toujours, au pire, recopier le code "à la main" en le lisant.

[Kurisu]

C'est bien ca le problème, la distribution sous forme de code source. (Bon, nos clients payent pas mal d'ailleurs juste pour cela).
C'est pour ca que je cherchais des solutions subtiles.
Mais bon, j'ai déjà quelques pistes, mais effectivement, il n'y a pas beaucoup de papiers techniques et/ou scientifiques à ce sujet. (Contrairement aux signatures binaires et bien sûr aux filigranes digitales appliquables aux fichiers media).

[Mac LAK]

Ce qui est parfaitement normal, hélas... Comme je te l'ai dit, contrairement à un format binaire qui peut être plus ou moins protégé en fonction de sa nature, il n'est guère possible de protéger un fichier où chaque octet est "visible", et où en plus sa valeur possède une signification lourde ne permettant pas une modification mineure contrairement aux pixels d'une image.

[Kurisu]

Bon, petite mise-à-jour: comme il n'y a visiblement aucun soft, il faudra y aller avec une solution en plusieurs parties:
- 1 signature visible visant à prevenir la redistribution inautorisée du source (clairement, un message du genre "hého mon petit gars, ce source est signé et nous saurons le retrouver s'il est redistribué!")
- 1 signature moins visible (espaces, tabs) plus subtilement cachée (mais fragile, je l'avoue)
- et plusieurs niveaux de "fonctionalité" subtile qui représente aussi une signature, fonctionalité unique à chaque client, par exemple.

...vous comprendrez que je ne peux pas m'étaler sur ce dernier plan.

Tout de même, si vous avez des idées de fonctionalité "subtile" à ajouter à un programme, je suis preneur.

(L'ironie à toute cette affaire, c'est que je suis un fervent adhérent à la mentalité OpenSource... sauf que mon salaire vient d'un middleware closed source en ce cas précis.)

[jabbounet]

sur un copie tu peux partir du principe que les algos ne vont pas trop bouger contrairemeaux commentaire (en tete notament)

donc tu peux imaginier un traitement sur les fichiers suspect virant les commentaire et qui leur donnera un format précis (indentation, tabulation, mise en forme, ...) et ou il ne reste que les algos

tu applique la même technique a ton code et tu compare.

apres tu peux etre plus fin car il peu y avoir des renomage de methodes/objets