Protection logicielle

Le
Antoine
Salut,

Existe-t'il une solution cryptographique pour protéger du code ?
Je sais que c'est paradoxal, et donc normal qu'on n'a jamais vu de
protection qui fonctionnait..
Voilà, disons que ça me fait toujours marrer de voir les différentes
versions d'un logiciel: personal, pro, et "enterprise" avec des limites
arbitraires, et certainement pas plus de quelques octets de différence
entre eux.

AL.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mathieu SEGAUD
Le #17826001
Antoine
Salut,

Existe-t'il une solution cryptographique pour protéger du code ?



pour protéger du code source ? oui
pour protéger du code compilé ? oui

Je sais que c'est paradoxal, et donc normal qu'on n'a jamais vu de
protection qui fonctionnait..



euh, là je commence à ne plus comprendre...
a priori sur ma machine toutes les partitions sont chiffrées et si je
l'éteins, tout ce qui se trouve dessus est "protégé" (modulo la
robustesse de ma passphrase)

Voilà, disons que ça me fait toujours marrer de voir les différentes
versions d'un logiciel: personal, pro, et "enterprise" avec des limites
arbitraires, et certainement pas plus de quelques octets de différence
entre eux.



alors là, je ne comprends pas du tout où tu veux en venir.
généralement, il y a des différences sur le code distribué et installé,
des différences de comportement de l'installeur (une seule clé autorisé,
plusieurs clées autorisées, installation des outils d'administrations
serveurs...), des différences de prix.
Mais je ne vois ni le rapport à la crypto, ni à ce qui est écrit
au-dessus...

:)

--
Mathieu
Antoine
Le #17825991
On Wed, 12 Nov 2008 22:22:18 +0100, Mathieu SEGAUD wrote:

Antoine
Salut,

Existe-t'il une solution cryptographique pour protéger du code ?



pour protéger du code source ? oui
pour protéger du code compilé ? oui



Donc je précise: protéger du code compilé, et qui s'exécute sur une
machine où on est libre de scruter la mémoire, ou de désassembler
l'exécutable.
Par protéger, j'entends: empêcher qu'on change un JZ en JNZ, par exemple.
Mathieu SEGAUD
Le #17826241
Antoine
On Wed, 12 Nov 2008 22:22:18 +0100, Mathieu SEGAUD wrote:

Antoine
Salut,

Existe-t'il une solution cryptographique pour protéger du code ?



pour protéger du code source ? oui
pour protéger du code compilé ? oui



Donc je précise: protéger du code compilé, et qui s'exécute sur une
machine où on est libre de scruter la mémoire, ou de désassembler
l'exécutable.
Par protéger, j'entends: empêcher qu'on change un JZ en JNZ, par exemple.



ben a priori en mettant la page mémoire où le code se trouve en
lecture-seule... sinon, il y a de multiples et divers mécanismes de
contrôle d'intégrité de données, comme CCM (CBC Counter-Mode utilisé
dans WPA2) ou MIC (basé sur le hash Michael dans WPA). Je ne sais pas
s'ils sont applicables, mais étant fondamentalement différents (l'un
prend des blocs et l'autre un flux) et pourtant appliqués aux mêmes "flux
de données", il y a des chances que ce soit applicable.
M'est avis que c'est au hard de s'occuper de ça (genre réserver une
petite case mémoire pour stocker les hashs des différents blocs,
régulièrement sur le disque).

Enfin tu as la réponse à ta question, oui c'est possible. Est-ce que
c'est appliqué ? je n'en sais rien, je n'ai aucune idée de ce que
pouvait faire des trucs comme TCPA ou Palladium...

--
Mathieu
mpg
Le #17831111
Le (on) mercredi 12 novembre 2008 22:53, Mathieu SEGAUD a écrit (wrote) :

ben a priori en mettant la page mémoire où le code se trouve en
lecture-seule...



Euh, je ne suis pas expert, mais pour peu que l'attaquant ai un minimum de
contrôle sur la machine où le code tourne (et il me semble que c'était
l'hypothèse), ça ne tient pas du tout. Lancer le programme sous un
débogueur doit suffir à contourner ça, non ?

Manuel.
Antoine
Le #17831781
> c'était l'hypothèse), ça ne tient pas du tout. Lancer le programme sous
un débogueur doit suffir à contourner ça, non ?



C'est bien ce que je voulais dire par paradoxal au début.
Stéphane CARPENTIER
Le #17834461
mpg wrote:

Le (on) mercredi 12 novembre 2008 22:53, Mathieu SEGAUD a écrit (wrote) :

ben a priori en mettant la page mémoire où le code se trouve en
lecture-seule...



Euh, je ne suis pas expert, mais pour peu que l'attaquant ai un minimum de
contrôle sur la machine où le code tourne (et il me semble que c'était
l'hypothèse), ça ne tient pas du tout. Lancer le programme sous un
débogueur doit suffir à contourner ça, non ?



Non. Ça peut être beaucoup plus compliqué que ça.

Il est de tester le temps d'exécution du code, et d'en déduire l'existence
d'un débuggeur, et d'avoir un comportement différent avec ou sans
débuggeur. Il est aussi possible de chiffrer le code. Il est aussi possible
de rajouter plein d'instructions inutiles pour compliquer l'analyse du
code.

Je ne crois pas qu'il soit possible de vraiment empêcher l'étude du code,
mais il est possible de beaucoup compliquer la tâche d'un attaquant.

--
Stéphane

Pour me répondre, traduire gratuit en anglais et virer le .invalid.
http://stef.carpentier.free.fr/
mpg
Le #17835251
Le (on) jeudi 13 novembre 2008 20:22, Stéphane CARPENTIER a écrit (wrote) :

mpg wrote:

Le (on) mercredi 12 novembre 2008 22:53, Mathieu SEGAUD a écrit (wrote) :

ben a priori en mettant la page mémoire où le code se trouve en
lecture-seule...



Euh, je ne suis pas expert, mais pour peu que l'attaquant ai un minimum
de contrôle sur la machine où le code tourne (et il me semble que c'était
l'hypothèse), ça ne tient pas du tout. Lancer le programme sous un
débogueur doit suffir à contourner ça, non ?



Non. Ça peut être beaucoup plus compliqué que ça.

Il est de tester le temps d'exécution du code, et d'en déduire l'existence
d'un débuggeur, et d'avoir un comportement différent avec ou sans
débuggeur. Il est aussi possible de chiffrer le code. Il est aussi
possible de rajouter plein d'instructions inutiles pour compliquer
l'analyse du code.



Ok, mais on est d'accord que *juste* mettre le page-mémoire du programme en
lecture seule ne suffit pas ?

Je ne crois pas qu'il soit possible de vraiment empêcher l'étude du code,
mais il est possible de beaucoup compliquer la tâche d'un attaquant.



Vu.

Manuel.
Stéphane CARPENTIER
Le #17835981
mpg wrote:

Le (on) jeudi 13 novembre 2008 20:22, Stéphane CARPENTIER a écrit (wrote)
:

mpg wrote:

Le (on) mercredi 12 novembre 2008 22:53, Mathieu SEGAUD a écrit (wrote)
:

ben a priori en mettant la page mémoire où le code se trouve en
lecture-seule...



Euh, je ne suis pas expert, mais pour peu que l'attaquant ai un minimum
de contrôle sur la machine où le code tourne (et il me semble que
c'était l'hypothèse), ça ne tient pas du tout. Lancer le programme sous
un débogueur doit suffir à contourner ça, non ?



Non. Ça peut être beaucoup plus compliqué que ça.

Il est de tester le temps d'exécution du code, et d'en déduire
l'existence d'un débuggeur, et d'avoir un comportement différent avec ou
sans débuggeur. Il est aussi possible de chiffrer le code. Il est aussi
possible de rajouter plein d'instructions inutiles pour compliquer
l'analyse du code.



Ok, mais on est d'accord que *juste* mettre le page-mémoire du programme
en lecture seule ne suffit pas ?



Oui.

Je ne crois pas qu'il soit possible de vraiment empêcher l'étude du code,
mais il est possible de beaucoup compliquer la tâche d'un attaquant.



Vu.



C'est surtout ça que je voulais préciser, j'avais l'impression que pour toi,
ça se faisait en deux coup de cuillères à pot.

--
Stéphane

Pour me répondre, traduire gratuit en anglais et virer le .invalid.
http://stef.carpentier.free.fr/
Jack
Le #17897311
Antoine wrote:
Salut,

Existe-t'il une solution cryptographique pour protéger du code ?
Je sais que c'est paradoxal, et donc normal qu'on n'a jamais vu de
protection qui fonctionnait..
Voilà, disons que ça me fait toujours marrer de voir les différentes
versions d'un logiciel: personal, pro, et "enterprise" avec des limites
arbitraires, et certainement pas plus de quelques octets de différence
entre eux.

AL.


La protection de code est tres connue
pour info il existe des logiciels deja concu pour faire ça (appeles
packer) dont le plus connu est Armadillo
Ils rendent le reverse beaucoup plus complique (obligation de faire
appel a des unpacker specifiques en fonction de la protection)
Des logiciels comme peid sont specialisés dans la reconnaissance de ses
protections

quant aux versions personnal/pro/entreprises, cela depend des compagnies
soit les clefs sont != (même binaire)
soit elles utilisent des binaires differents (elles peuvent utiliser des
options de compile avec un joli #ifdef pour inclure du code ou non) donc
il y a beaucoup plus que quelques octets de differences (portion de code
en moins oblige)
Francois Grieu
Le #17902841
Antoine a écrit :

Existe-t'il une solution cryptographique pour protéger du code ?
[..pour faire..] différentes > versions d'un logiciel: personal,


> pro, et "enterprise" avec des limites arbitraires, et certainement
> pas plus de quelques octets de différence entre eux.

Mis à part les barrières d'ordre légal, les deux principales voies
techniques sont:

1) L'exécution du programme, ou d'une partie de celui-ci, dans un
environnement de confiance; par exemple, une carte à puce dans laquelle
certaines parties du code exécutable du programme sont en java card, et
non accessible à l'adversaire. Celui-ci peut seulement capter les
échanges entre le programme principal et l'environnement de confiance.
Il semble que les moins mauvaises techniques d'attaque sont de
comprendre ce que fait la fraction du programme s'exécutant dans
l'environnement de confiance, et de la réécrire; ou de compromettre
l'environnement de confiance.

2) L'"obfuscation" qui tente de rendre la décompilation et/ou la
modification du code exécutable difficile, bien qu'il s'exécute dans un
environnement ouvert type PC standard. Je ne crois pas que l'on sache
faire quelque chose qui corresponde aux critère cryptographiques normaux
(en particulier, algorithme d'"obfuscation" public) et qui soit vraiment
résistant, mais cela fonctionne en pratique comme stratégie de
retardement. L'augmentation de la taille du code des applications
déplace plutôt l'équilibre protection/attaque en faveur de la première.


Dans les deux cas, un obstacle pratique majeur est que c'est difficile à
automatiser d'une manière transparentes aux multiples outils en
constante évolution qui produisent du code exécutable, tout en
maintenant une protection efficace. Dans le premier cas, il y a en plus
le problème de commodité d'installation, et de rapport performance/cout,
de l'environnement de confiance.


François Grieu
Publicité
Poster une réponse
Anonyme