je cherche le moyen de générer une clé de licence pour un shareware mais je
ne suis pas un expert en sécurité. Avez-vous des indications à me donner ?
j'ai cru comprendre qu'il était préférable d'utiliser des variables
statiques dans une fonction plutôt que des variables globales ? Est-ce que
le cryptage en md5 est fiable ? comment savoir si mon "keygen" est fiable ?
si si on peut éviter par exemple en cryptant une partie de ton programme avec le numero de série, et qu'il se décrypte à l'éxecution, la fonction de décryptage rend simplement la main a la suite du programme, si le cracker a cracké seulement le je/jne de vérification du numero de série, le programme plantera lorsqu'il passera sur le morceau mal décrypté. mais bon meme ca, ca se déplombe ... moins facilement, mais ca se déplombe quand meme.
et je pense que ca serait une bonne chose que ton numero d'enregistrement sois généré à partir du nom du propriétaire, et que ce nom sois affiché dans le programme, ca réduierai certainement la diffusion sur le P2P en plus si tu le trouve sur le P2P tu pourra identifié celui qui l'a mis en partage. (si un keygen n'a pas été créé)
d'une facon théorique on peut dire que le mal que ve se donner le cracker sera proportionel à la popularité de ton programme. si c'est juste un petit programme, tu en dissuadera plus d'un avec une petite protection. sinon si c'est un programme qui va devenir populaire, alors aucune protection que tu pourra mettre en place ne résisstera ... a toi de juger de quel type de protection ton programme aura besoin
sinon j'ai déja parlé des packers, mais personne n'a fait de commentaire dessus. j'en pense personnelement que la méthode la plus simple et la plus fiable sois d'utiliser un packer (il y en a des gratuits)
Jean-François GAZET wrote:
Quasi tous les softs se craquent en remplaçant un JE par un JNE (ou inversement).
Et aprés ces modifs, comment recompile-t-on l'exe ? je vais essayer de cracker mon programme :-))
Dans le code C++, on peut pas éviter les "return true" ou "false" ? Un "if", je suppose, que c'est pareil : "si vrai, sinon"...
si si on peut éviter
par exemple en cryptant une partie de ton programme avec le numero de
série, et qu'il se décrypte à l'éxecution, la fonction de décryptage
rend simplement la main a la suite du programme, si le cracker a cracké
seulement le je/jne de vérification du numero de série, le programme
plantera lorsqu'il passera sur le morceau mal décrypté.
mais bon meme ca, ca se déplombe ... moins facilement, mais ca se
déplombe quand meme.
et je pense que ca serait une bonne chose que ton numero
d'enregistrement sois généré à partir du nom du propriétaire, et que ce
nom sois affiché dans le programme, ca réduierai certainement la
diffusion sur le P2P
en plus si tu le trouve sur le P2P tu pourra identifié celui qui l'a mis
en partage. (si un keygen n'a pas été créé)
d'une facon théorique on peut dire que le mal que ve se donner le
cracker sera proportionel à la popularité de ton programme. si c'est
juste un petit programme, tu en dissuadera plus d'un avec une petite
protection. sinon si c'est un programme qui va devenir populaire, alors
aucune protection que tu pourra mettre en place ne résisstera ...
a toi de juger de quel type de protection ton programme aura besoin
sinon j'ai déja parlé des packers, mais personne n'a fait de commentaire
dessus.
j'en pense personnelement que la méthode la plus simple et la plus
fiable sois d'utiliser un packer (il y en a des gratuits)
Jean-François GAZET wrote:
Quasi tous les softs se craquent en remplaçant un JE par un JNE (ou
inversement).
Et aprés ces modifs, comment recompile-t-on l'exe ?
je vais essayer de cracker mon programme :-))
Dans le code C++, on peut pas éviter les "return true" ou "false" ?
Un "if", je suppose, que c'est pareil : "si vrai, sinon"...
si si on peut éviter par exemple en cryptant une partie de ton programme avec le numero de série, et qu'il se décrypte à l'éxecution, la fonction de décryptage rend simplement la main a la suite du programme, si le cracker a cracké seulement le je/jne de vérification du numero de série, le programme plantera lorsqu'il passera sur le morceau mal décrypté. mais bon meme ca, ca se déplombe ... moins facilement, mais ca se déplombe quand meme.
et je pense que ca serait une bonne chose que ton numero d'enregistrement sois généré à partir du nom du propriétaire, et que ce nom sois affiché dans le programme, ca réduierai certainement la diffusion sur le P2P en plus si tu le trouve sur le P2P tu pourra identifié celui qui l'a mis en partage. (si un keygen n'a pas été créé)
d'une facon théorique on peut dire que le mal que ve se donner le cracker sera proportionel à la popularité de ton programme. si c'est juste un petit programme, tu en dissuadera plus d'un avec une petite protection. sinon si c'est un programme qui va devenir populaire, alors aucune protection que tu pourra mettre en place ne résisstera ... a toi de juger de quel type de protection ton programme aura besoin
sinon j'ai déja parlé des packers, mais personne n'a fait de commentaire dessus. j'en pense personnelement que la méthode la plus simple et la plus fiable sois d'utiliser un packer (il y en a des gratuits)
Jean-François GAZET wrote:
Quasi tous les softs se craquent en remplaçant un JE par un JNE (ou inversement).
Et aprés ces modifs, comment recompile-t-on l'exe ? je vais essayer de cracker mon programme :-))
Dans le code C++, on peut pas éviter les "return true" ou "false" ? Un "if", je suppose, que c'est pareil : "si vrai, sinon"...
AMcD®
Johann Dantant wrote:
Plutôt que du terme assez flou de lacunes, tu pourrais expliquer qu'effectivement la recherche de collisions sur MD5 occupe des chercheurs depuis de nombreuses années et que les résultats ont justifiés l'élaboration de SHA-1. Certes les "nouvelles applications" ont tout intérêt à utiliser SHA-1 préférentiellement à MD5, mais cela n'empêche pas un grand nombre d'applications existantes de démeurer "robustes" malgré le fait qu'elles utilisent MD5. Le terme "cracké" est donc un tantinet exagéré, surtout dans le contexte d'un shareware à quelques dizaines euros contre lequel très peu de puissance CPU risque d'être braquée...
Oui. Quoiqu'il ne faut pas non plus que le hacker puisse facilement ajouter ses données dans la base des hashes MD5 non plus :o). Tu n'es pas obligé forcémment d'avoir à le "cracker" le soft, c'est tellement plus simple de le "contouner" parfois :o).
Cela étant, le style de la réponse était adapté à l'intervenant. Les grandes gueules ne me dérangent pas (les habitués de ce NG te diront que j'en suis une), à la condion expresse qu'elles maîtrisent un peu leur sujet. Venir se payer ma tête sur les fonctions de hachage alors que le gars a 12 ans de retard sur le sujet, heu...
-- AMcD®
http://arnold.mcdonald.free.fr/
Johann Dantant wrote:
Plutôt que du terme assez flou de lacunes, tu pourrais expliquer
qu'effectivement la recherche de collisions sur MD5 occupe des
chercheurs depuis de nombreuses années et que les résultats ont
justifiés l'élaboration de SHA-1. Certes les "nouvelles applications"
ont tout intérêt à utiliser SHA-1 préférentiellement à MD5, mais cela
n'empêche pas un grand nombre d'applications existantes de démeurer
"robustes" malgré le fait qu'elles utilisent MD5. Le terme "cracké"
est donc un tantinet exagéré, surtout dans le contexte d'un shareware
à quelques dizaines euros contre lequel très peu de puissance CPU
risque d'être braquée...
Oui. Quoiqu'il ne faut pas non plus que le hacker puisse facilement ajouter
ses données dans la base des hashes MD5 non plus :o). Tu n'es pas obligé
forcémment d'avoir à le "cracker" le soft, c'est tellement plus simple de le
"contouner" parfois :o).
Cela étant, le style de la réponse était adapté à l'intervenant. Les grandes
gueules ne me dérangent pas (les habitués de ce NG te diront que j'en suis
une), à la condion expresse qu'elles maîtrisent un peu leur sujet. Venir se
payer ma tête sur les fonctions de hachage alors que le gars a 12 ans de
retard sur le sujet, heu...
Plutôt que du terme assez flou de lacunes, tu pourrais expliquer qu'effectivement la recherche de collisions sur MD5 occupe des chercheurs depuis de nombreuses années et que les résultats ont justifiés l'élaboration de SHA-1. Certes les "nouvelles applications" ont tout intérêt à utiliser SHA-1 préférentiellement à MD5, mais cela n'empêche pas un grand nombre d'applications existantes de démeurer "robustes" malgré le fait qu'elles utilisent MD5. Le terme "cracké" est donc un tantinet exagéré, surtout dans le contexte d'un shareware à quelques dizaines euros contre lequel très peu de puissance CPU risque d'être braquée...
Oui. Quoiqu'il ne faut pas non plus que le hacker puisse facilement ajouter ses données dans la base des hashes MD5 non plus :o). Tu n'es pas obligé forcémment d'avoir à le "cracker" le soft, c'est tellement plus simple de le "contouner" parfois :o).
Cela étant, le style de la réponse était adapté à l'intervenant. Les grandes gueules ne me dérangent pas (les habitués de ce NG te diront que j'en suis une), à la condion expresse qu'elles maîtrisent un peu leur sujet. Venir se payer ma tête sur les fonctions de hachage alors que le gars a 12 ans de retard sur le sujet, heu...
-- AMcD®
http://arnold.mcdonald.free.fr/
AMcD®
Dominique Vaufreydaz wrote:
Bonjour,
Oui, oui. Tu peux toujours rêver. Le gars dira qu'on lui a volé son matériel et que c'est le voleur qui l'a mis sur le Net. Qui plus est, faut pas prendre les hackers pour des idiots, si ton logiciel a de l'intérêt, ton algo sera reversé et patché.
De toute facon, la seule solution est celle qui va arrivee et qui commence a etre travaillee : Palladium.
À voir. Qu'est-ce qu'il n'y a pas eu comme concepts géniaux et absolument sûr depuis 1950... :o)
-- AMcD®
http://arnold.mcdonald.free.fr/
Dominique Vaufreydaz wrote:
Bonjour,
Oui, oui. Tu peux toujours rêver. Le gars dira qu'on lui a volé son
matériel et que c'est le voleur qui l'a mis sur le Net. Qui plus
est, faut pas prendre les hackers pour des idiots, si ton logiciel a
de l'intérêt, ton algo sera reversé et patché.
De toute facon, la seule solution est celle qui va arrivee et qui
commence a etre travaillee : Palladium.
Oui, oui. Tu peux toujours rêver. Le gars dira qu'on lui a volé son matériel et que c'est le voleur qui l'a mis sur le Net. Qui plus est, faut pas prendre les hackers pour des idiots, si ton logiciel a de l'intérêt, ton algo sera reversé et patché.
De toute facon, la seule solution est celle qui va arrivee et qui commence a etre travaillee : Palladium.
À voir. Qu'est-ce qu'il n'y a pas eu comme concepts géniaux et absolument sûr depuis 1950... :o)
-- AMcD®
http://arnold.mcdonald.free.fr/
AMcD®
Pai-Check wrote:
si si on peut éviter par exemple en cryptant une partie de ton programme avec le numero de série, et qu'il se décrypte à l'éxecution, la fonction de décryptage rend simplement la main a la suite du programme, si le cracker a cracké seulement le je/jne de vérification du numero de série, le programme plantera lorsqu'il passera sur le morceau mal décrypté. mais bon meme ca, ca se déplombe ... moins facilement, mais ca se déplombe quand meme.
Tu parles. 15'. Une fois décrypté, tu choppes le contenu de la mémoire, tu vires la partie de décryptage et tu crées un nouveau PE...
et je pense que ca serait une bonne chose que ton numero d'enregistrement sois généré à partir du nom du propriétaire, et que ce nom sois affiché dans le programme, ca réduierai certainement la diffusion sur le P2P en plus si tu le trouve sur le P2P tu pourra identifié celui qui l'a mis en partage. (si un keygen n'a pas été créé)
Le vol de matériel informatique ça existe. Et tu ne pourras jamais prouver que c'est bien le gars qui l'a mis en P2P. Enfin, un vrai cracker fera les choses proprement, il virera cryptage et informations vis-à-vis du propriétaire. Vous sortez de l'IUT les gars là ou quoi ;o) ?
d'une facon théorique on peut dire que le mal que ve se donner le cracker sera proportionel à la popularité de ton programme. si c'est juste un petit programme, tu en dissuadera plus d'un avec une petite protection. sinon si c'est un programme qui va devenir populaire, alors aucune protection que tu pourra mettre en place ne résisstera
Oui. Sans compter aussi ceux qui font ça pour s'amuser.
sinon j'ai déja parlé des packers, mais personne n'a fait de commentaire dessus.
Parce que ça se craque de la manière dont je t'ai dit plus haut.
j'en pense personnelement que la méthode la plus simple et la plus fiable sois d'utiliser un packer (il y en a des gratuits)
La manière la plus fiable est de faire un BON logiciel, pratique et sans bug. Il y aura toujours des gens pour l'acheter. Aucune protection n'est efficace. Même les dongles se craquent.
-- AMcD®
http://arnold.mcdonald.free.fr/
Pai-Check wrote:
si si on peut éviter
par exemple en cryptant une partie de ton programme avec le numero de
série, et qu'il se décrypte à l'éxecution, la fonction de décryptage
rend simplement la main a la suite du programme, si le cracker a
cracké seulement le je/jne de vérification du numero de série, le
programme plantera lorsqu'il passera sur le morceau mal décrypté.
mais bon meme ca, ca se déplombe ... moins facilement, mais ca se
déplombe quand meme.
Tu parles. 15'. Une fois décrypté, tu choppes le contenu de la mémoire, tu
vires la partie de décryptage et tu crées un nouveau PE...
et je pense que ca serait une bonne chose que ton numero
d'enregistrement sois généré à partir du nom du propriétaire, et que
ce nom sois affiché dans le programme, ca réduierai certainement la
diffusion sur le P2P
en plus si tu le trouve sur le P2P tu pourra identifié celui qui l'a
mis en partage. (si un keygen n'a pas été créé)
Le vol de matériel informatique ça existe. Et tu ne pourras jamais prouver
que c'est bien le gars qui l'a mis en P2P. Enfin, un vrai cracker fera les
choses proprement, il virera cryptage et informations vis-à-vis du
propriétaire. Vous sortez de l'IUT les gars là ou quoi ;o) ?
d'une facon théorique on peut dire que le mal que ve se donner le
cracker sera proportionel à la popularité de ton programme. si c'est
juste un petit programme, tu en dissuadera plus d'un avec une petite
protection. sinon si c'est un programme qui va devenir populaire,
alors aucune protection que tu pourra mettre en place ne résisstera
Oui. Sans compter aussi ceux qui font ça pour s'amuser.
sinon j'ai déja parlé des packers, mais personne n'a fait de
commentaire dessus.
Parce que ça se craque de la manière dont je t'ai dit plus haut.
j'en pense personnelement que la méthode la plus simple et la plus
fiable sois d'utiliser un packer (il y en a des gratuits)
La manière la plus fiable est de faire un BON logiciel, pratique et sans
bug. Il y aura toujours des gens pour l'acheter. Aucune protection n'est
efficace. Même les dongles se craquent.
si si on peut éviter par exemple en cryptant une partie de ton programme avec le numero de série, et qu'il se décrypte à l'éxecution, la fonction de décryptage rend simplement la main a la suite du programme, si le cracker a cracké seulement le je/jne de vérification du numero de série, le programme plantera lorsqu'il passera sur le morceau mal décrypté. mais bon meme ca, ca se déplombe ... moins facilement, mais ca se déplombe quand meme.
Tu parles. 15'. Une fois décrypté, tu choppes le contenu de la mémoire, tu vires la partie de décryptage et tu crées un nouveau PE...
et je pense que ca serait une bonne chose que ton numero d'enregistrement sois généré à partir du nom du propriétaire, et que ce nom sois affiché dans le programme, ca réduierai certainement la diffusion sur le P2P en plus si tu le trouve sur le P2P tu pourra identifié celui qui l'a mis en partage. (si un keygen n'a pas été créé)
Le vol de matériel informatique ça existe. Et tu ne pourras jamais prouver que c'est bien le gars qui l'a mis en P2P. Enfin, un vrai cracker fera les choses proprement, il virera cryptage et informations vis-à-vis du propriétaire. Vous sortez de l'IUT les gars là ou quoi ;o) ?
d'une facon théorique on peut dire que le mal que ve se donner le cracker sera proportionel à la popularité de ton programme. si c'est juste un petit programme, tu en dissuadera plus d'un avec une petite protection. sinon si c'est un programme qui va devenir populaire, alors aucune protection que tu pourra mettre en place ne résisstera
Oui. Sans compter aussi ceux qui font ça pour s'amuser.
sinon j'ai déja parlé des packers, mais personne n'a fait de commentaire dessus.
Parce que ça se craque de la manière dont je t'ai dit plus haut.
j'en pense personnelement que la méthode la plus simple et la plus fiable sois d'utiliser un packer (il y en a des gratuits)
La manière la plus fiable est de faire un BON logiciel, pratique et sans bug. Il y aura toujours des gens pour l'acheter. Aucune protection n'est efficace. Même les dongles se craquent.
-- AMcD®
http://arnold.mcdonald.free.fr/
Thierry
Bonjour,
Alexandre a écrit :
non ça n'existe pas. c'est impossible.
Pourquoi impossible ? Ca pourrait generer du code imbitable avec des fonction1 variable1 etc mais je ne vois pas l'impossibilité.
-- « Willy, j'ai mangé le chat. »
Bonjour,
Alexandre a écrit :
non ça n'existe pas. c'est impossible.
Pourquoi impossible ? Ca pourrait generer du code imbitable avec des
fonction1 variable1 etc mais je ne vois pas l'impossibilité.
Pourquoi impossible ? Ca pourrait generer du code imbitable avec des fonction1 variable1 etc mais je ne vois pas l'impossibilité.
-- « Willy, j'ai mangé le chat. »
Thierry
Bonjour,
Alexandre a écrit :
est d'effectuer PLEIN de fois le test dans le code, des fois pour rien, histoire de brouiller les pistes,
De deux choses l'une : soit le test se fait sur une variable et dans ce cas il "suffit" de modifier l'initialisation de variable, soit c'est lié a l'appel d'une fonction et il suffit de modifier la fonction. Donc dans la plupart des cas suffit de changer une instruction. Sauf en utilisant des fonctions inline mais ca doit generer une sequence de code remarquable qu'il doit être possible de remplacer de façon automatique.
-- « Willy, j'ai mangé le chat. »
Bonjour,
Alexandre a écrit :
est d'effectuer PLEIN de fois le test dans
le code, des fois pour rien, histoire de brouiller les pistes,
De deux choses l'une : soit le test se fait sur une variable et dans ce cas
il "suffit" de modifier l'initialisation de variable, soit c'est lié a
l'appel d'une fonction et il suffit de modifier la fonction. Donc dans la
plupart des cas suffit de changer une instruction. Sauf en utilisant des
fonctions inline mais ca doit generer une sequence de code remarquable
qu'il doit être possible de remplacer de façon automatique.
est d'effectuer PLEIN de fois le test dans le code, des fois pour rien, histoire de brouiller les pistes,
De deux choses l'une : soit le test se fait sur une variable et dans ce cas il "suffit" de modifier l'initialisation de variable, soit c'est lié a l'appel d'une fonction et il suffit de modifier la fonction. Donc dans la plupart des cas suffit de changer une instruction. Sauf en utilisant des fonctions inline mais ca doit generer une sequence de code remarquable qu'il doit être possible de remplacer de façon automatique.
-- « Willy, j'ai mangé le chat. »
François Müller
"AMcD®" escribió en el mensaje news:4033dee8$0$28440$ | spécialistes. Au fait, au passage, MD5 est cracked depuis des lustres.
Pardon ?
Qu'entends tu par là ?
Que quelqu'un a trouvé une solution analytique de reversibilité ? j'ai plus qu'un doute.
Sans vouloir t'offenser, je crains que ne t'emmêles les pinceaux avec autre chose
F.
"AMcD®" <arnold.mcdonald@free.fr> escribió en el mensaje
news:4033dee8$0$28440$636a15ce@news.free.fr...
| spécialistes. Au fait, au passage, MD5 est cracked depuis des lustres.
Pardon ?
Qu'entends tu par là ?
Que quelqu'un a trouvé une solution analytique de reversibilité ? j'ai plus
qu'un doute.
Sans vouloir t'offenser, je crains que ne t'emmêles les pinceaux avec autre
chose
"AMcD®" escribió en el mensaje news:4033dee8$0$28440$ | spécialistes. Au fait, au passage, MD5 est cracked depuis des lustres.
Pardon ?
Qu'entends tu par là ?
Que quelqu'un a trouvé une solution analytique de reversibilité ? j'ai plus qu'un doute.
Sans vouloir t'offenser, je crains que ne t'emmêles les pinceaux avec autre chose
F.
Dominique Vaufreydaz
Re,
À voir. Qu'est-ce qu'il n'y a pas eu comme concepts géniaux et absolument sûr depuis 1950... :o)
Ce que je voulais dire mon cher Arnold, c'est que la solution hardware bas niveau (pas un dongle pourri sur le port //) est celle qui va prevaloir dans le futur...
Pour la mise en place/perenite de Palladium, je n'ai qu'un avis mitige sur le sujet.
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Re,
À voir. Qu'est-ce qu'il n'y a pas eu comme concepts géniaux et absolument
sûr depuis 1950... :o)
Ce que je voulais dire mon cher Arnold, c'est que la solution
hardware bas niveau (pas un dongle pourri sur le port //) est
celle qui va prevaloir dans le futur...
Pour la mise en place/perenite de Palladium, je n'ai qu'un avis
mitige sur le sujet.
Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://Dominique.Vaufreydaz.free.fr/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
À voir. Qu'est-ce qu'il n'y a pas eu comme concepts géniaux et absolument sûr depuis 1950... :o)
Ce que je voulais dire mon cher Arnold, c'est que la solution hardware bas niveau (pas un dongle pourri sur le port //) est celle qui va prevaloir dans le futur...
Pour la mise en place/perenite de Palladium, je n'ai qu'un avis mitige sur le sujet.
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Pai-Check
comme les playstations ca sera patché hardware ^^
Dominique Vaufreydaz wrote:
Re,
À voir. Qu'est-ce qu'il n'y a pas eu comme concepts géniaux et absolument sûr depuis 1950... :o)
Ce que je voulais dire mon cher Arnold, c'est que la solution hardware bas niveau (pas un dongle pourri sur le port //) est celle qui va prevaloir dans le futur...
Pour la mise en place/perenite de Palladium, je n'ai qu'un avis mitige sur le sujet.
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
comme les playstations ca sera patché hardware ^^
Dominique Vaufreydaz wrote:
Re,
À voir. Qu'est-ce qu'il n'y a pas eu comme concepts géniaux et absolument
sûr depuis 1950... :o)
Ce que je voulais dire mon cher Arnold, c'est que la solution
hardware bas niveau (pas un dongle pourri sur le port //) est
celle qui va prevaloir dans le futur...
Pour la mise en place/perenite de Palladium, je n'ai qu'un avis
mitige sur le sujet.
Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://Dominique.Vaufreydaz.free.fr/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
À voir. Qu'est-ce qu'il n'y a pas eu comme concepts géniaux et absolument sûr depuis 1950... :o)
Ce que je voulais dire mon cher Arnold, c'est que la solution hardware bas niveau (pas un dongle pourri sur le port //) est celle qui va prevaloir dans le futur...
Pour la mise en place/perenite de Palladium, je n'ai qu'un avis mitige sur le sujet.
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Dominique Vaufreydaz
Re,
Pai-Check wrote:
comme les playstations ca sera patché hardware ^^
MAis contrairement a la playstation, le patch ne fait que faire croire a qqchose et ce n'est pas inclus dans le microprocesseur (plus bas niveau tu meurs). Patcher un microprocesseur devient quand meme nettement plus difficile (faut avoir de bon yeux et un fer a souder de petite facture). Pour l'instant, le probleme est qu'Intel et AMD font, a ma connaissance, partie du consortium => monde des x86 devrait faire le pas. On va tous acheter des G5 ou Gx a l'avenir. Notons que pour les Linuxien, le passage est nettement plus doux depuis OS X.
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Re,
Pai-Check wrote:
comme les playstations ca sera patché hardware ^^
MAis contrairement a la playstation, le patch ne fait que faire croire
a qqchose et ce n'est pas inclus dans le microprocesseur (plus bas niveau
tu meurs). Patcher un microprocesseur devient quand meme nettement
plus difficile (faut avoir de bon yeux et un fer a souder de petite facture).
Pour l'instant, le probleme est qu'Intel et AMD font, a ma
connaissance, partie du consortium => monde des x86 devrait faire
le pas. On va tous acheter des G5 ou Gx a l'avenir. Notons que
pour les Linuxien, le passage est nettement plus doux depuis OS X.
Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://Dominique.Vaufreydaz.free.fr/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
MAis contrairement a la playstation, le patch ne fait que faire croire a qqchose et ce n'est pas inclus dans le microprocesseur (plus bas niveau tu meurs). Patcher un microprocesseur devient quand meme nettement plus difficile (faut avoir de bon yeux et un fer a souder de petite facture). Pour l'instant, le probleme est qu'Intel et AMD font, a ma connaissance, partie du consortium => monde des x86 devrait faire le pas. On va tous acheter des G5 ou Gx a l'avenir. Notons que pour les Linuxien, le passage est nettement plus doux depuis OS X.
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
