D'après de vagues souvenirs, je crois qu'il est possible de crypter/comp
resser les sources C d'un programme pour que le fichier binaire généré a
près compilation puisse être quasiement indécompilable...
Quelqu'un a-t-il plus d'info sur ce sujet ?
D'avance merci
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Article poste via Voila News - http://www.news.voila.fr
Le : Fri Jun 27 17:40:02 2003 depuis l'IP : alyon-206-1-3-229.w80-14.abo.wanadoo.fr [VIP 5430053]
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Emmanuel Delahaye
In 'fr.comp.lang.c', nico wrote:
D'après de vagues souvenirs, je crois qu'il est possible de crypter/comp resser les sources C d'un programme pour que le fichier binaire généré a près compilation puisse être quasiement indécompilable...
<HS>
Hum... Un programme compilé est traduit en langage machine binaire (suite de 0 et de 1) dont le sens réel n'est connu que du processeur pour lequel il a été ciblé. Je te rassure, il n'y a aucune trace de code source dans le code binaire. Même en mode debug, il y a peut être des références genre nom de fichier ou numéro de ligne, mais c'est tout. Pas de source, ni même de mnémoniques.
Pour ce qui est de retransformer la viande hachée en boeuf, je souhaite du courage...
Il existe des outils simples qui permettent de desassembler le code machine pour en visualiser le code machine sous forme litéralle, voire de l'exécuter pas à pas etc. Mais impossible de voir le source C originel.
Il existe bien des 'décompilateurs', qui vont /essayer/ de générer un code source plus ou moins lisible et plus ou moins exploitable, mais ce ne sera jamais le code original, bien sûr, surtout si l'optimiseur est passé par là...
Pour se protéger du reverse ingeneering, il n'y a pas grand chose à faire que de compter sur la complexité du code binaire créé pour empécher les éventuels décompilateurs de s'y retrouver.
</>
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-library: http://www.dinkumware.com/htm_cl/index.html FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', nico <nicolas_tougouchi@voila.fr> wrote:
D'après de vagues souvenirs, je crois qu'il est possible de crypter/comp
resser les sources C d'un programme pour que le fichier binaire généré a
près compilation puisse être quasiement indécompilable...
<HS>
Hum... Un programme compilé est traduit en langage machine binaire (suite de
0 et de 1) dont le sens réel n'est connu que du processeur pour lequel il a
été ciblé. Je te rassure, il n'y a aucune trace de code source dans le code
binaire. Même en mode debug, il y a peut être des références genre nom de
fichier ou numéro de ligne, mais c'est tout. Pas de source, ni même de
mnémoniques.
Pour ce qui est de retransformer la viande hachée en boeuf, je souhaite du
courage...
Il existe des outils simples qui permettent de desassembler le code machine
pour en visualiser le code machine sous forme litéralle, voire de l'exécuter
pas à pas etc. Mais impossible de voir le source C originel.
Il existe bien des 'décompilateurs', qui vont /essayer/ de générer un code
source plus ou moins lisible et plus ou moins exploitable, mais ce ne sera
jamais le code original, bien sûr, surtout si l'optimiseur est passé par
là...
Pour se protéger du reverse ingeneering, il n'y a pas grand chose à faire que
de compter sur la complexité du code binaire créé pour empécher les éventuels
décompilateurs de s'y retrouver.
</>
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-library: http://www.dinkumware.com/htm_cl/index.html
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
D'après de vagues souvenirs, je crois qu'il est possible de crypter/comp resser les sources C d'un programme pour que le fichier binaire généré a près compilation puisse être quasiement indécompilable...
<HS>
Hum... Un programme compilé est traduit en langage machine binaire (suite de 0 et de 1) dont le sens réel n'est connu que du processeur pour lequel il a été ciblé. Je te rassure, il n'y a aucune trace de code source dans le code binaire. Même en mode debug, il y a peut être des références genre nom de fichier ou numéro de ligne, mais c'est tout. Pas de source, ni même de mnémoniques.
Pour ce qui est de retransformer la viande hachée en boeuf, je souhaite du courage...
Il existe des outils simples qui permettent de desassembler le code machine pour en visualiser le code machine sous forme litéralle, voire de l'exécuter pas à pas etc. Mais impossible de voir le source C originel.
Il existe bien des 'décompilateurs', qui vont /essayer/ de générer un code source plus ou moins lisible et plus ou moins exploitable, mais ce ne sera jamais le code original, bien sûr, surtout si l'optimiseur est passé par là...
Pour se protéger du reverse ingeneering, il n'y a pas grand chose à faire que de compter sur la complexité du code binaire créé pour empécher les éventuels décompilateurs de s'y retrouver.
</>
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-library: http://www.dinkumware.com/htm_cl/index.html FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Bertrand Mollinier Toublet
nico wrote:
Bonjour,
D'après de vagues souvenirs, je crois qu'il est possible de crypter/comp resser les sources C d'un programme pour que le fichier binaire généré a près compilation puisse être quasiement indécompilable...
Quelqu'un a-t-il plus d'info sur ce sujet ?
A mon avis, c'est pipo. En C, je ne pense pas que la nature du source
influe sur le resultat d'une eventuelle decompilation de ton programme. Il est notoire que de toute facon, le resultat de la decompilation d'un executable est a peu pres imbitable, et tres probablement sans rapport avec le source original.
Tu confonds peut-etre avec d'autres langages (je pense en particulier a Java)
-- Bertrand Mollinier Toublet Currently looking for employment in the San Francisco Bay Area http://bmt-online.dapleasurelounge.com/
nico wrote:
Bonjour,
D'après de vagues souvenirs, je crois qu'il est possible de crypter/comp
resser les sources C d'un programme pour que le fichier binaire généré a
près compilation puisse être quasiement indécompilable...
Quelqu'un a-t-il plus d'info sur ce sujet ?
A mon avis, c'est pipo. En C, je ne pense pas que la nature du source
influe sur le resultat d'une eventuelle decompilation de ton programme.
Il est notoire que de toute facon, le resultat de la decompilation d'un
executable est a peu pres imbitable, et tres probablement sans rapport
avec le source original.
Tu confonds peut-etre avec d'autres langages (je pense en particulier a
Java)
--
Bertrand Mollinier Toublet
Currently looking for employment in the San Francisco Bay Area
http://bmt-online.dapleasurelounge.com/
D'après de vagues souvenirs, je crois qu'il est possible de crypter/comp resser les sources C d'un programme pour que le fichier binaire généré a près compilation puisse être quasiement indécompilable...
Quelqu'un a-t-il plus d'info sur ce sujet ?
A mon avis, c'est pipo. En C, je ne pense pas que la nature du source
influe sur le resultat d'une eventuelle decompilation de ton programme. Il est notoire que de toute facon, le resultat de la decompilation d'un executable est a peu pres imbitable, et tres probablement sans rapport avec le source original.
Tu confonds peut-etre avec d'autres langages (je pense en particulier a Java)
-- Bertrand Mollinier Toublet Currently looking for employment in the San Francisco Bay Area http://bmt-online.dapleasurelounge.com/
Marc Boyer
In article <bdhogi$ds0$, nico wrote:
Bonjour,
D'après de vagues souvenirs, je crois qu'il est possible de crypter/comp resser les sources C d'un programme pour que le fichier binaire généré a près compilation puisse être quasiement indécompilable... Quelqu'un a-t-il plus d'info sur ce sujet ?
Voic ce que j'avais sous la main.
En ce qui concerne l'encryptage de source C, je n'ai pas de pointeur sous la main, mais je sais qu'il existe des choses. En ce qui concerne le "nettoyage" du binaire, sous Unix, il existe "strip". Pour voir ce qui existe en décompilation automatique, voire par exemple http://www.itee.uq.edu.au/~cristina/dcc.html
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
In article <bdhogi$ds0$1@news.x-echo.com>, nico wrote:
Bonjour,
D'après de vagues souvenirs, je crois qu'il est possible de crypter/comp
resser les sources C d'un programme pour que le fichier binaire généré a
près compilation puisse être quasiement indécompilable...
Quelqu'un a-t-il plus d'info sur ce sujet ?
Voic ce que j'avais sous la main.
En ce qui concerne l'encryptage de source C, je n'ai pas de pointeur
sous la main, mais je sais qu'il existe des choses.
En ce qui concerne le "nettoyage" du binaire, sous Unix, il existe
"strip".
Pour voir ce qui existe en décompilation automatique, voire
par exemple
http://www.itee.uq.edu.au/~cristina/dcc.html
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
D'après de vagues souvenirs, je crois qu'il est possible de crypter/comp resser les sources C d'un programme pour que le fichier binaire généré a près compilation puisse être quasiement indécompilable... Quelqu'un a-t-il plus d'info sur ce sujet ?
Voic ce que j'avais sous la main.
En ce qui concerne l'encryptage de source C, je n'ai pas de pointeur sous la main, mais je sais qu'il existe des choses. En ce qui concerne le "nettoyage" du binaire, sous Unix, il existe "strip". Pour voir ce qui existe en décompilation automatique, voire par exemple http://www.itee.uq.edu.au/~cristina/dcc.html
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Wlv
glop,
Hum... Un programme compilé est traduit en langage machine binaire (suite de
0 et de 1) dont le sens réel n'est connu que du processeur pour lequel il a
été ciblé. Je te rassure, il n'y a aucune trace de code source dans le code
binaire. Même en mode debug, il y a peut être des références genre nom de fichier ou numéro de ligne, mais c'est tout. Pas de source, ni même de mnémoniques.
Quel est ton besoin en fait ? il y a peut etre des moyens plus simples...
Pour ce qui est de retransformer la viande hachée en boeuf, je souhaite du courage...
Cela me rapelle l'histoire du mec qui voulait remettre le dentifrice dans le tube :-)
Il existe des outils simples qui permettent de desassembler le code machine
pour en visualiser le code machine sous forme litéralle, voire de l'exécuter
pas à pas etc. Mais impossible de voir le source C originel.
Il me semble qu'il existe des "sourcer" C (code binaire vers C) mais je ne pense pas que cela tres tres au point...
Il existe bien des 'décompilateurs', qui vont /essayer/ de générer un code source plus ou moins lisible et plus ou moins exploitable, mais ce ne sera jamais le code original, bien sûr, surtout si l'optimiseur est passé par là...
Cela reste largement utilisable suivant ce que tu veux faire...
Pour se protéger du reverse ingeneering, il n'y a pas grand chose à faire que
de compter sur la complexité du code binaire créé pour empécher les éventuels
décompilateurs de s'y retrouver.
Le code automodifiant est pas mal dans ce genre, il y a quelques annees j'avais vu du code sur Atari ST venant d'un groupe de coders legerement psychopathes sur les bord qui s'automodifié en fonction de la position du faisceau de la cathode du moniteur. L'idee etait que toutes les machines ayant le meme hard, lorsque la demo tournait, alors tout le monde executait la meme instruction au meme moment, donc a certain moment du code ils allaient recuperer la position courante du faisceau et s'en servaient comme clé pour decoder la serie d'instruction suivante, la modifier au vol et la transformer en code executable... l'interet etait que leur code etait insourcable et meme intracable sous debugger.
Bien sur pour faire cela il faut le meme hard pour tous, passer des nuits blanches a vouloir debugger un truc absolument imbitable, et surtout "juste montrer qu'on sait le faire", et peut etre en vouloir un peu a la vie aussi...
Pour en revenir a teon probleme, de cherche tu a te proteger ?
@+W.
glop,
Hum... Un programme compilé est traduit en langage machine binaire (suite
de
0 et de 1) dont le sens réel n'est connu que du processeur pour lequel il
a
été ciblé. Je te rassure, il n'y a aucune trace de code source dans le
code
binaire. Même en mode debug, il y a peut être des références genre nom de
fichier ou numéro de ligne, mais c'est tout. Pas de source, ni même de
mnémoniques.
Quel est ton besoin en fait ? il y a peut etre des moyens plus simples...
Pour ce qui est de retransformer la viande hachée en boeuf, je souhaite du
courage...
Cela me rapelle l'histoire du mec qui voulait remettre le dentifrice dans le
tube :-)
Il existe des outils simples qui permettent de desassembler le code
machine
pour en visualiser le code machine sous forme litéralle, voire de
l'exécuter
pas à pas etc. Mais impossible de voir le source C originel.
Il me semble qu'il existe des "sourcer" C (code binaire vers C) mais je ne
pense pas que cela tres tres au point...
Il existe bien des 'décompilateurs', qui vont /essayer/ de générer un code
source plus ou moins lisible et plus ou moins exploitable, mais ce ne sera
jamais le code original, bien sûr, surtout si l'optimiseur est passé par
là...
Cela reste largement utilisable suivant ce que tu veux faire...
Pour se protéger du reverse ingeneering, il n'y a pas grand chose à faire
que
de compter sur la complexité du code binaire créé pour empécher les
éventuels
décompilateurs de s'y retrouver.
Le code automodifiant est pas mal dans ce genre, il y a quelques annees
j'avais vu du code sur Atari ST venant d'un groupe de coders legerement
psychopathes sur les bord qui s'automodifié en fonction de la position du
faisceau de la cathode du moniteur. L'idee etait que toutes les machines
ayant le meme hard, lorsque la demo tournait, alors tout le monde executait
la meme instruction au meme moment, donc a certain moment du code ils
allaient recuperer la position courante du faisceau et s'en servaient comme
clé pour decoder la serie d'instruction suivante, la modifier au vol et la
transformer en code executable... l'interet etait que leur code etait
insourcable et meme intracable sous debugger.
Bien sur pour faire cela il faut le meme hard pour tous, passer des nuits
blanches a vouloir debugger un truc absolument imbitable, et surtout "juste
montrer qu'on sait le faire", et peut etre en vouloir un peu a la vie
aussi...
Pour en revenir a teon probleme, de cherche tu a te proteger ?
Hum... Un programme compilé est traduit en langage machine binaire (suite de
0 et de 1) dont le sens réel n'est connu que du processeur pour lequel il a
été ciblé. Je te rassure, il n'y a aucune trace de code source dans le code
binaire. Même en mode debug, il y a peut être des références genre nom de fichier ou numéro de ligne, mais c'est tout. Pas de source, ni même de mnémoniques.
Quel est ton besoin en fait ? il y a peut etre des moyens plus simples...
Pour ce qui est de retransformer la viande hachée en boeuf, je souhaite du courage...
Cela me rapelle l'histoire du mec qui voulait remettre le dentifrice dans le tube :-)
Il existe des outils simples qui permettent de desassembler le code machine
pour en visualiser le code machine sous forme litéralle, voire de l'exécuter
pas à pas etc. Mais impossible de voir le source C originel.
Il me semble qu'il existe des "sourcer" C (code binaire vers C) mais je ne pense pas que cela tres tres au point...
Il existe bien des 'décompilateurs', qui vont /essayer/ de générer un code source plus ou moins lisible et plus ou moins exploitable, mais ce ne sera jamais le code original, bien sûr, surtout si l'optimiseur est passé par là...
Cela reste largement utilisable suivant ce que tu veux faire...
Pour se protéger du reverse ingeneering, il n'y a pas grand chose à faire que
de compter sur la complexité du code binaire créé pour empécher les éventuels
décompilateurs de s'y retrouver.
Le code automodifiant est pas mal dans ce genre, il y a quelques annees j'avais vu du code sur Atari ST venant d'un groupe de coders legerement psychopathes sur les bord qui s'automodifié en fonction de la position du faisceau de la cathode du moniteur. L'idee etait que toutes les machines ayant le meme hard, lorsque la demo tournait, alors tout le monde executait la meme instruction au meme moment, donc a certain moment du code ils allaient recuperer la position courante du faisceau et s'en servaient comme clé pour decoder la serie d'instruction suivante, la modifier au vol et la transformer en code executable... l'interet etait que leur code etait insourcable et meme intracable sous debugger.
Bien sur pour faire cela il faut le meme hard pour tous, passer des nuits blanches a vouloir debugger un truc absolument imbitable, et surtout "juste montrer qu'on sait le faire", et peut etre en vouloir un peu a la vie aussi...
Pour en revenir a teon probleme, de cherche tu a te proteger ?
@+W.
nicolas_tougouchi
Bon, pour être plus explicatif :
Je souhaite créer un programme qui me permette de crypter/décrypter une chaine de caractère. Qui dit cryptage/décryptage, dit clef de cryptage (ou "phrase"). Or si je stocke ma clef de cryptage dans mon programme C, que je compile le tout sans protection, n'importe quel petit hacker pourra convertir mon binaire en assembleur et lire ma clef de cryptage (ce type de donnée étant stockée en tant que constante en assembleur, donc très bien identifiable...)
Mon problème ne vient donc pas de la protection d'un algorithme, mais d'une donnée critique dans mon programme..
J'ai retourné le problème dans tous les sens, je ne vois actuellement pas d'autres solutions que celle-ci.. Mais d'après vos réponses, j'ai l'impression qu'elle n'est pas facile à mettre en oeuvre !
Bon, pour être plus explicatif :
Je souhaite créer un programme qui me permette de crypter/décrypter
une chaine de caractère.
Qui dit cryptage/décryptage, dit clef de cryptage (ou "phrase").
Or si je stocke ma clef de cryptage dans mon programme C, que je
compile le tout sans protection, n'importe quel petit hacker pourra
convertir mon binaire en assembleur et lire ma clef de cryptage (ce
type de donnée étant stockée en tant que constante en assembleur, donc
très bien identifiable...)
Mon problème ne vient donc pas de la protection d'un algorithme, mais
d'une donnée critique dans mon programme..
J'ai retourné le problème dans tous les sens, je ne vois actuellement
pas d'autres solutions que celle-ci.. Mais d'après vos réponses, j'ai
l'impression qu'elle n'est pas facile à mettre en oeuvre !
Je souhaite créer un programme qui me permette de crypter/décrypter une chaine de caractère. Qui dit cryptage/décryptage, dit clef de cryptage (ou "phrase"). Or si je stocke ma clef de cryptage dans mon programme C, que je compile le tout sans protection, n'importe quel petit hacker pourra convertir mon binaire en assembleur et lire ma clef de cryptage (ce type de donnée étant stockée en tant que constante en assembleur, donc très bien identifiable...)
Mon problème ne vient donc pas de la protection d'un algorithme, mais d'une donnée critique dans mon programme..
J'ai retourné le problème dans tous les sens, je ne vois actuellement pas d'autres solutions que celle-ci.. Mais d'après vos réponses, j'ai l'impression qu'elle n'est pas facile à mettre en oeuvre !
Martinez Jerome
nico wrote:
Bon, pour être plus explicatif :
Je souhaite créer un programme qui me permette de crypter/décrypter une chaine de caractère. Qui dit cryptage/décryptage, dit clef de cryptage (ou "phrase"). Or si je stocke ma clef de cryptage dans mon programme C,
enorme erreur de conception!!! Tu la stocke ou tu veux, sauf dans ton programme! Un logiciel de cryptage doit permettre de mettre la "phrqase qu'in veut :)
nico wrote:
Bon, pour être plus explicatif :
Je souhaite créer un programme qui me permette de crypter/décrypter
une chaine de caractère.
Qui dit cryptage/décryptage, dit clef de cryptage (ou "phrase").
Or si je stocke ma clef de cryptage dans mon programme C,
enorme erreur de conception!!!
Tu la stocke ou tu veux, sauf dans ton programme!
Un logiciel de cryptage doit permettre de mettre la "phrqase qu'in veut :)
Je souhaite créer un programme qui me permette de crypter/décrypter une chaine de caractère. Qui dit cryptage/décryptage, dit clef de cryptage (ou "phrase"). Or si je stocke ma clef de cryptage dans mon programme C,
enorme erreur de conception!!! Tu la stocke ou tu veux, sauf dans ton programme! Un logiciel de cryptage doit permettre de mettre la "phrqase qu'in veut :)
Emmanuel Delahaye
In 'fr.comp.lang.c', (nico) wrote:
Bon, pour être plus explicatif :
Je souhaite créer un programme qui me permette de crypter/décrypter une chaine de caractère. Qui dit cryptage/décryptage, dit clef de cryptage (ou "phrase"). Or si je stocke ma clef de cryptage dans mon programme C, que je compile le tout sans protection, n'importe quel petit hacker pourra convertir mon binaire en assembleur et lire ma clef de cryptage (ce type de donnée étant stockée en tant que constante en assembleur, donc très bien identifiable...)
Il est assez simple de créer un petit programme en C qui va encoder la clé selon une loi pas trop complexe, mais suffisante pour la rendre illisible. Ce programme génère un bout de code du genre :
Il suffit d'utiliser la procédure inverse pour décoder la clé.
Rien n'empêche de noyer cette sequence au milieu d'une autre genre pseudo aléatoire, ce qui fait que la lecture du code binaire sera peu révélatrice, si ce n'est qu'il existe une clé codée cachée dans un fatra de données bidons. Rien n'est inviolable, mais ça devrait retarder le voleur un certain temps...
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', nicolas_tougouchi@voila.fr (nico) wrote:
Bon, pour être plus explicatif :
Je souhaite créer un programme qui me permette de crypter/décrypter
une chaine de caractère.
Qui dit cryptage/décryptage, dit clef de cryptage (ou "phrase").
Or si je stocke ma clef de cryptage dans mon programme C, que je
compile le tout sans protection, n'importe quel petit hacker pourra
convertir mon binaire en assembleur et lire ma clef de cryptage (ce
type de donnée étant stockée en tant que constante en assembleur, donc
très bien identifiable...)
Il est assez simple de créer un petit programme en C qui va encoder la
clé selon une loi pas trop complexe, mais suffisante pour la rendre
illisible. Ce programme génère un bout de code du genre :
Il suffit d'utiliser la procédure inverse pour décoder la clé.
Rien n'empêche de noyer cette sequence au milieu d'une autre genre pseudo
aléatoire, ce qui fait que la lecture du code binaire sera peu révélatrice,
si ce n'est qu'il existe une clé codée cachée dans un fatra de données
bidons. Rien n'est inviolable, mais ça devrait retarder le voleur un certain
temps...
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Je souhaite créer un programme qui me permette de crypter/décrypter une chaine de caractère. Qui dit cryptage/décryptage, dit clef de cryptage (ou "phrase"). Or si je stocke ma clef de cryptage dans mon programme C, que je compile le tout sans protection, n'importe quel petit hacker pourra convertir mon binaire en assembleur et lire ma clef de cryptage (ce type de donnée étant stockée en tant que constante en assembleur, donc très bien identifiable...)
Il est assez simple de créer un petit programme en C qui va encoder la clé selon une loi pas trop complexe, mais suffisante pour la rendre illisible. Ce programme génère un bout de code du genre :
Il suffit d'utiliser la procédure inverse pour décoder la clé.
Rien n'empêche de noyer cette sequence au milieu d'une autre genre pseudo aléatoire, ce qui fait que la lecture du code binaire sera peu révélatrice, si ce n'est qu'il existe une clé codée cachée dans un fatra de données bidons. Rien n'est inviolable, mais ça devrait retarder le voleur un certain temps...
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Michel BILLAUD
"temujin" writes:
Les logiciels sont protégés par les lois sur la propriété intellectuelle, pourquoi s'acharner à la protection au niveau de l'exécutable ? Toutes les protections des productions de Krosoft sont des vraies passoires, cela n'empêche pas Bill Gates d'être toujours l'homme le plus riche du monde.
C'est meme d'ailleurs grâce à ça qu'il a ce bonheur.
Sachant qu'il y a deux catégories, ceux qui achètent et ceux qui piratent, il préfère que les gens piratent ses logiciels à lui plutot que d'acheter ceux des autres. Ca ne lui coute pas un sou, ça n'en rapporte pas aux concurrents, et ça habitue les clients à utiliser ses produits. Le jour où ils achèteront (avec l'argent de la boite),...
La position dominante a quelques avantages...
MB -- Michel BILLAUD LABRI-Universite Bordeaux I phone W: 05 4000 6922 / 05 4000 5792 351, cours de la Liberation http://www.labri.fr/~billaud 33405 Talence (FRANCE) http://dept-info.labri.fr/~billaud
"temujin" <u-mma@wanadoo.fr> writes:
Les logiciels sont protégés par les lois sur la propriété intellectuelle,
pourquoi s'acharner à la protection au niveau de l'exécutable ? Toutes les
protections des productions de Krosoft sont des vraies passoires, cela
n'empêche pas Bill Gates d'être toujours l'homme le plus riche du monde.
C'est meme d'ailleurs grâce à ça qu'il a ce bonheur.
Sachant qu'il y a deux catégories, ceux qui achètent et ceux qui
piratent, il préfère que les gens piratent ses logiciels à lui plutot
que d'acheter ceux des autres. Ca ne lui coute pas un sou, ça n'en
rapporte pas aux concurrents, et ça habitue les clients à utiliser ses
produits. Le jour où ils achèteront (avec l'argent de la boite),...
La position dominante a quelques avantages...
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Universite Bordeaux I phone W: 05 4000 6922 / 05 4000 5792
351, cours de la Liberation http://www.labri.fr/~billaud
33405 Talence (FRANCE) http://dept-info.labri.fr/~billaud
Les logiciels sont protégés par les lois sur la propriété intellectuelle, pourquoi s'acharner à la protection au niveau de l'exécutable ? Toutes les protections des productions de Krosoft sont des vraies passoires, cela n'empêche pas Bill Gates d'être toujours l'homme le plus riche du monde.
C'est meme d'ailleurs grâce à ça qu'il a ce bonheur.
Sachant qu'il y a deux catégories, ceux qui achètent et ceux qui piratent, il préfère que les gens piratent ses logiciels à lui plutot que d'acheter ceux des autres. Ca ne lui coute pas un sou, ça n'en rapporte pas aux concurrents, et ça habitue les clients à utiliser ses produits. Le jour où ils achèteront (avec l'argent de la boite),...
La position dominante a quelques avantages...
MB -- Michel BILLAUD LABRI-Universite Bordeaux I phone W: 05 4000 6922 / 05 4000 5792 351, cours de la Liberation http://www.labri.fr/~billaud 33405 Talence (FRANCE) http://dept-info.labri.fr/~billaud
