Discussion :

[Morgatte]

Il semble kue (ma lettre KU est HS désolé) kue rolKa confonde Hacking et Cracking. Bon pas grâve... (on ne parle pas de l'intrusion d'un réseau)



Je confirme ku'il n'y a aucun moyen d'empêcher kuelku'un de modifier un programme si il a vraiment les compétences pour le faire.

Cependant on peut lui mettre pas mal de batons dans les roues. Un petit tour d'horizon pourra peut-être t'aider à mieux comprendre ce kui peut être fait.
Je pense en particulier à :

- du code détectant les débuggers (facile à péter cependant)
- du code CCA (Code Changeant d'Apparence = une sorte de polymorphisme) c'est très simple à faire, un simple jmp sautant au dessus d'un byte inutilisé mais ayant une signification pour le processeur et le tour est joué.
ex:

Code :

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

1
2
3
4
EB01       jmp SautLeByte
0F         leByte db 0Fh
SautLeByte:
E807000000 CALL MaProcedure

Le processeur va l'interpréter ainsi car 0F+... a une signification propre :

Code :

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

1
2
3
EB01      jmp SautLeByte
0FE807    psubsb MM0, [edi]
0000      add [eax], al

Le truc c'est ku'en traçant, on voit le code changer, ça permet de cacher des points clefs et ça peut être superchiant à tracer.
Mais avec un peu de pratikue on peut facilement anéantir ça. Pour ma part je patch tous les bytes kue saute le jmp par des 90h.
puiskue 90h (un NOP) est interprété sans suite, 90h+AUTRECHOSE ne peut rien donné d'autre kue ça. UPX l'utilise beaucoup...

- Bon plus puissants sont les cryptage/décryptage PE. Un programme cypté possède une partie non crypté (un loader) kui sert à décrypté le reste du programme une fois ku'il a été mappé en mémoire.
Du coup avec un débugger on ne voit plus rien car le code crypté n'a plus une signification réelle. Cependant c'est toujours possible de le reconstituer. Il suffit pour ça de laisser le loader décrypter le vrai programme et une fois u'on se trouve sur la première ligne du programme décrypté, de faire un dump (copie d'une zone de mémoire, ici le prog décrypté). On en refait un *.exe et ensuite on fait repointer OEP (Original Entry Point) sur la première ligne du prog décrypté, Le tour est joué.
La seule difficulté c'est de retrouver l'OEP (surtout si les BPR ont été mis hors d'état de fonctionnés par le loader).
C'est le niveau ultime utilisé par UPX.

- Toujours plus puissant, ce serait évidemment de crypter le programme mais en plus de faire en sorte d'empêcher le DUMP. Et c'est possible, mais ce serait trop long à explikuer en détail. En résumé, L'IAT kui est une section de ton programme où se trouvent écrits tous les noms des fonctions ku'il utilise. Le truc c'est ku'il est possible de faire en sorte kue le programme s'exécute normalement avec les bonnes fonctions, mais en plus de modifier son IAT en mémoire pour kue toutes les fonctions soient remplacées par ExitProcess par exemple. On s'en fout de modifier, l'IAT par la suite car il a servit au début mais plus jamais ensuite. Par contre un DUMP du programme en mémoire va faire en sorte u'une fois reconstitué en un *.exe, tout son IAT n'aura u'une seule fonction, ExitProcess.
C'est bien joué ça, 1 : Le programme est Cypté donc on ne voit rien. 2 : Si on le dump pour faire en sorte de retrouver sa version décrypté, il ne marche plus.
Seule solution, tout faire soit même à la main. C'est à dire laisser le loader décrypter le programme MAIS en prenant garde aux passage du loader kui modifient l'IAT. Ecraser ces passages pour l'empêcher d'agir. Evidemment, ça suppose de tracer le programme en comprenant ce ku'il fait, et c'est plus du niveau des premiers crakers. Ca suppose de connaitre intimement l'IAT.

- Dans un autre genre, tout aussi efficace, le cas des dernières versions d'ASPROTEC.
En décortikuant ses entrailles on s'aperçoit kuil remplace par exemple :

CALL BFF70000 kui pourrait correspondre à l'appelle de la fonction MessageBoxA par exemple.

Code :

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

1
2
3
PUSH ESP
MOV ESP, EBP
CALL BFF70003

Pourkuoi ?

En fait kuand il appelle une fonction et bien il saute "au-debut de cette fonction + 3 bytes" et justement ces 3 bytes ku'il ne va pas exécuter dans la fonction même, il le recopie directement dans le programme pour kue rien ne mankue lors de l'exécution globale.
Du coup les débuggers ne reconnaissent plus les Noms des fonctions puisku'elles ne pointent plus sur leur début. En plus après un Dump en mémoire, on se retrouve avec des petits bouts de code supplémentaires (PUSH ESP...) dans le programme kui le font planter car la pile reçoit des données en trop.
Bien entendu le remède existe, un simple bout de papier et un cerveau, ou bien le vraiment excellent programme Revirgin de +Tsehp (mais pas évident à aborder)


Donc voilà, tu vois kue tant ku'un debugger pourra lire la première ligne d'un programme, la possibilité d'abbattre les différentes protections sera toujours possible pour peu kue le savoir et l'acharnement suivent. Cependant faut pas nier kue ça se pête pas comme ça les doits dans le nez, comme c'était le cas y a encore 7 ou 8 ans.


(Je différencie clairement Cracking et Reverse, dans le premier cas de simples bases en programmation peuvent suffir dans les cas simples. Dans le second cas de réelles compétences en programmation sont indispensables)

[SKZ81]

Pour l'IAT, je veux pas trop m'avancer pcq je connaissait même pas son existance... (à moins que ce soit encore un autre nom pour un truc que je connais : bref...)
Un truc que je me disait tout de même... Ok normalement on peut lui faire confiance (seul un prog protégé modifira le contenu) mais si une protection peut l'écraser impunément, c'est qu'elle doit être recopiée qqpart à disposition du prog... On devrait pouvoir la retrouver :

[rolkA]

Par reverse engineering, j'entend désassembler un programme.
Haypo

Je comprends donc mieux la divergence: pour moi ce n'est pas çà. pour moi le désassemblage est une étape du reverse engineering seulement. Exemple concret: photoshop utilise un certain algo pour réaliser la fonction ajustements->correction automatique du contraste. pour moi le reverse-engineering consiste à découvrir cet algorithme... et pas seulement décompiler les plug-ins en assembleur !!!

[Morgatte]

Pour répondre à SKZ8un (Mon chiffre un est HS lui aussi)

Pour l'IAT, je veux pas trop m'avancer pcq je connaissait même pas son existance... (à moins que ce soit encore un autre nom pour un truc que je connais bref...)
Un truc que je me disait tout de même... Ok normalement on peut lui faire confiance (seul un prog protégé modifira le contenu) mais si une protection peut l'écraser impunément, c'est qu'elle doit être recopiée qqpart à disposition du prog... On devrait pouvoir la retrouver.

Non, L'IAT est propre au programme (.idata parfois .rdata), tout comme l'est sa section code (.text).
Pour être un peu plus précis, l'IAT contient d'autres choses kue les noms des fonctions utilisées par le prog. en particulier pour chakue nom de fonction un
- DWORD Original_First_Thunk (Son vrai nom c'est THUNK_DATA)
- DWORD First_Thunk (Son vrai nom est aussi THUNK_DATA)
- et un DWORD Time_Date_Stamp
lui sont associés.

kuand un PE File (un *.exe) est exécuté sous windows, la première chose kue fait windows c'est récopier le programme en mémoire, ensuite d'après les noms des fonctions présents dans l'IAT, Il remplace les membres fait une copie comforme des membres First_Thunk à partir des membres Original_First_Thunk, ainsi chakue CALL NomDeFonction sait où pointer à l'intérieur des APIs en se référent aux membres First_Thunk, car NomDeFonction vient d'être remplacé par une adresse.
Les Original_First_Thunk sont toujours fixés lors de la compilation du programme et resteront toujours invariables, Ils sont seulement recopiés dans le First_Thunk kui seuls eux comptent, et c'est une étape rapide. C'est le seul but de ce méchanisme, vite retrouver les adresses des fonctions à partir des OFT. Donc à priorie, les noms des fonctions présents dans l'IAT sont complètement inutiles.
Là où le bas blesse, c'est kue les versions des DLL évolues et donc les adresses d'une version à l'autre peuvent différer (méchant plantage).
Pour résoudre ça le membre Time_Date_Stamp pour chakue fonction dans le programme est comparer à un autre membre lui aussi appelé Date_Time_Stamp se trouvant dans la DLL exportant la fonction, Comme ça si pour une même fonction Time_Date_Stamp dans le programme et dans la DLL sont égaux alors c'est kue la DLL utilisée actuellement par le programme est de la même version kue celle kui à servit au moment de sa compilation. Du coup tout baigne. Le méchanisme est celui vue ci-dessus.
Par contre si les deux Time_Date_Stamp sont différents alors c'est kue la DLL actuelle n'est pas de la version de celle d'origine. Dans ce cas le loader de Windows (toujours lui) réactualise les Membres First_Thunk non plus en recopiant les Original_First_Thunk mais en appelant la fonction GetProcAddress en lui passant les noms des fonctions trouvées dans l'IAT. Le First_Thunk redeviennent correctent. Mais c'est un peut plus lent. Cependant dans tout les cas le programme fonctionne.
Kuand Windows en à finit avec la reconstitution d'un IAT approprié en mémoire il passe le controle au programme kui peut alors exécuter pour la toute première fois sa première instruction de code.

Maintenant en gardant ce méchanisme en tête, revenons au principe de l'Anti-Dump :

Imaginons un crypteur kui ait vidé l'IAT d'origine sauf les Original_First_Thunk, et l'a récrit ailleurs dans la partie loader de décryptage du programme, Il a aussi crypté la section .code.
On exécute notre programme. D'abord c'est Windows kui a la main et puiskue les Original_First_Thunk sont à leurs places, la copie vers le First_Thunk se fait, les call sont bons, et une fois décrypté le programme fonctionnera. Mais le loader de décryptage ne s'en tien pas ku'a ça... Windows à fait son boulot OK, mais lui il va en plus recopier dans le vrai IAT (prekue vide) le nom d'une seule fonction ExitProcess et mettre tous les membres Time_Date_Stamp à 0FFFFFFFFh.
Du coup bien kue le programme s'exécute, si on fait un dump et ku'on l'exécute, puiskue les Time_Date_Stamp sont incorrectes (aucune date peut être FFFFFFF) alors ils réactualise les First_Thunk en retrouvant les noms des fonctions dans l'IAT, Et tous pointent sur ExitProcess. Et, et... après un Dump y a rien d'autre de disponible kue cette fonction, les autres ont été perdues en chemin.




(Je ne vous ai pas parlé des fonctions exportées BY_ORDINAL là c'était le cas des BY_NAME. Ca complikue juste un peu l'affaire.)

Désolé d'être si long, mais en réalité c'est encore plus complikuer kue ça. (Il y a d'autres Structures telle kue IMAGE_IMPORT_DESCRIPTOR, IMAGE_IMPORT_BY_NAME ...).

[Didier Derain]

Pour info je suis un peut dans le meme cas, (ca ne marche pas encore mais bientot) pour camoufler une routine critique je la crypte dans un premier temps puis au moment de l'executer je la decrypte par l'intermediare de l'int de debbugage a savoir je decode l'instruction suivante puis je recode la precedente de telle sorte qu'a aucun moment ma routine n'est entierement visible meme sous un debuggeur qui ne peut voir ce que je fait puisque je suis caller sur son int. (l'astuce consiste a utiliser le code (le code asm de la routine) de decryption plus le contenue de la pile et aussi le contenue des registre DR0... code clef de decriptage..

[Blustuff]

Si je comprends bien la logique, un désasm/débugueur suffisement puissant pour lequel tout marcherait par scripting, du désassemblage, au tracage, en passant par la recherche des symboles viendrait a bout de n'importe quoi non ? Si un script était éxécuté après chaque instruction, il y aurait moyen de détecter chaque appel de fonction, chaque accès en mémoire etc.

Pourquoi après avoir dumpé la mémoire rétablir l'IAT originale ?

[Morgatte]

Désolé de répondre après X temps je n'avais pas vu la kuestion ci-dessus. Mais un Post récent faisant référence à celui-ci m'a dirigé de nouveau ici et je viens de voir cette dernière kuestion.

donc...

>> Pourquoi après avoir dumpé la mémoire rétablir l'IAT originale ?

Il est impératif d'avoir un IAT valide pour ku'un *.exe fonctionne. L'unikue destinée de l'IAT est de remplir correctement ses propres membres First_Thunk. Leurs valeurs sont attribués dynamikuement et représentent les adresses des API telles kue BFF0xxxx pour ExitProcess par exemple.
Kuand on écrit un programme, les 'CALL fonctions' ku'il utilise ne pointent jamais directement sur les adresses de ses fonctions à l'intérieur des dll.

Kuand on tombe sur :
- Call MessageBoxA
En fait ce n'est jamais un call du type :
- Call BFF0xxxx
Mais bien un call du type suivant :
- Call 004........
Où l'adresse fait bien partie de l'IAT (sur un des membre First_Thunk)

Donc si votre IAT n'est pas valide (ou au stricte minimum si les First_Thunk ne sont pas valides) alors les call ne peuvent pas appeler les fonctions et votre programme échoue.


C'est pour ça kue faire un travail sur l'IAT pour protéger un programme est intéressant.
Si vous réussissez juste avant l'exécution de la première ligne de code à avoir des first_thunk valides et kue le loader ait décrypté la section .text (code) du programme alors ce programme est fonctionnel.
Mais en même temps si tout le reste de l'Iat est non valide, alors si vous faite un dump du programme pour laisser le loader décryter la section code, il ne fonctionnera pas. Car l'IAT étant reconstruit dynamikuement à chakue ouverture du programme, les first_thunk valides (au moment du dump) auront été remplacés par des first_thunk corrompus lors de la nouvelle réactualisation).


Une kuestion bête pour finir..... Pourkuoi donc se sevir d'un IAT plutôt kue d'appeler directement les fonctions dans les dll ?

Parce kue si vous changer de version de dll, leurs adresses peuvent être différentes et du coup votre programme peut fonctionner chez vous, mais pas chez votre copin. L'iat à pour rôle de retrouver dans tous les cas les bonnes adresses des fonctions.


J'avais codé deux crypteurs sur ce principe ici : http://membres.lycos.fr/w32assembly/...atte/Crypt.ace
et un tut inclus explikant plus abilement ce pincipe. (le second crypteur ne fonctionnera pas sous XP) car il possède d'autres principe ku'XP n'apprécie pas, en particulier une routine en Ring0 détectant SoftIce et autres débuggeur) Il suffira de la supprimer pour ku'il redeviennet fonctionnel sous cet OS.
Le fonctionnement complet de l'IAT est décrit dans ce tut ci http://membres.lycos.fr/w32assembly/...rgatte/Iat.ace kui est en réalité la première partie du précédent.

[BigTick]

Hello,

Ma petite contribution sur le sujet (C++ et asm):
http://bigtick.pastnotecut.org/tutorials/cp.html

'Tick

[doccpu]

on ne peux pas empercher un désassemblage fait par un être humain !
Même en faisant des leurres ou des ocde un type qui a 20 ans d'assembleur dans les doigts vous feras tout péter sans grandes difficultés. Il saura quoi faire avec quel code et il décompressera les données cryptés. On ne peux pas empercher le désassemblage parce que si on l'empêche le processeur sera incapable de l'exécuter. En bref ce que peux faire un processeur un cerveau humain peux le faire, il y mettra le temps mais il le fera.

Cordiallement

[doccpu]

Hello,

Ma petite contribution sur le sujet (C++ et asm):
http://bigtick.pastnotecut.org/tutorials/cp.html

'Tick

Pas mal ton site et la protection expliqué mais t'a oublié le plus simple des hack en brute force :
Tu cherche les test et/ou les comparaisons suivis d'un jz ou jnz (ou équivalent) 1 par 1 et tu les inverse 1 par 1 jusque à ce que le logiciel te laisse entrer à se moment la tu vien de générer un programe yes (sauf pour le bon code pour lequel il répondra non)un hackeur peut faire ca même sans débugueur avec un éditeur hexa (je te l'accorde, il faut être chevronné pour le faire en hexa).

[doccpu]

Si je comprends bien la logique, un désasm/débugueur suffisement puissant pour lequel tout marcherait par scripting, du désassemblage, au tracage, en passant par la recherche des symboles viendrait a bout de n'importe quoi non ?

Non un script n'est pas intelligent ! En tout cas pas autant que nous, et il faut le mettre sans cesse à jour pour qu'il fonctionne sur (presque) tout !

Si un script était éxécuté après chaque instruction, il y aurait moyen de détecter chaque appel de fonction, chaque accès en mémoire etc.

Oui dans la théorie c'est possible mais il y aura toujours un ingénieur qui sera capable de faire en sorte que le désassembleur se mette à tourner en rond dans le processus de désassemblage et donc plantera le désassembleur ou le fera s'arrêter si le désassembleur est équipé d'un whatchdog cependant un humain sera beaucoup plus lent à faire le travail mais il ne se laissera pas prendre à ce piège. Du moins pas éternellement.

[Smortex]

Salut

Sans même chercher plus profondément: si le CPU peut l'exécuter, ça peut être désossé.

C'est complètement stupide mais ça se résume ainsi.
C'est comme la musique-pleine-de-DRM-anti-copie... Pas escence, si on peut l'écouter, on peut le copier.

Je pense que le commun des mortels croit dur comme fer en la magie Le seul moyen d'avoir un programme qui soit impossible à désosser, c'est de le mettre sur un serveur auquel personne n'a un accès autre que pour y faire entrer ses données et récupérer ses résultats... et n'avoir aucune faille de sécurité dans le code (on sait jamais, un utilisateur mal intentionné qui récupère des bout de mémoire en passant des données un peu louches)!

[Juju_41]

Sans même chercher plus profondément: si le CPU peut l'exécuter, ça peut être désossé.

C'est complètement stupide mais ça se résume ainsi.
C'est comme la musique-pleine-de-DRM-anti-copie... Pas escence, si on peut l'écouter, on peut le copier.

+1 il n'y a pas de protection infaillible

Le seul moyen d'avoir un programme qui soit impossible à désosser, c'est de le mettre sur un serveur auquel personne n'a un accès autre que pour y faire entrer ses données et récupérer ses résultats... et n'avoir aucune faille de sécurité dans le code

Même si il n'y a aucune faille de sécurité dans le code, il reste les attaques "physiques" qui permettent de récupérer du code/des données sans pour autant avoir accès au matériel. Par exemple, les attaques DPA (Differential Power Analysis) sur les cartes à puce : en analysant la consommation électrique aux bornes de certains contacts de la carte, on peut en déduire l'instruction en cours d'exécution sur le micro-processeur de la carte.

[millie]

Même si il n'y a aucune faille de sécurité dans le code, il reste les attaques "physiques" qui permettent de récupérer du code/des données sans pour autant avoir accès au matériel. Par exemple, les attaques DPA (Differential Power Analysis) sur les cartes à puce : en analysant la consommation électrique aux bornes de certains contacts de la carte, on peut en déduire l'instruction en cours d'exécution sur le micro-processeur de la carte.

Les attaques physiques sont délicates à réaliser si le serveur est à 10.000 km.

[Neitsa]

Bonjour,

Même si il est vrai que au final le code doit être exécuté sur le processeur (et que forcément, à ce moment précis, on y a accès) certaines techniques anti-RE sont viables à presque 100%.

In fine le but d'une protection est de gagner du temps face aux attaquants, plus le temps pris à retrouver la logique du programme est long, plus l'attaquant à des chances d'abandonner.

Aujourd'hui la "norme" des protections est de multiplier les couches ("layers") de protections en utilisant différents mécanismes et en imbriquant solidement chaque couches.

La protection en "vogue" en ce moment - parce qu'elle a fait ses preuves - est la "virtualisation" d'instructions au travers d'une machine virtuelle insérée dans le programme protégé.
Une partie (souvent la partie critique) des instructions du programme sont récrites dans un langage (bytecode) que seule la machine virtuelle est à même de comprendre. L'attaquant doit alors analyser la machine virtuelle - qui agit comme un processeur dont aucune spécification ne serait disponible - afin de comprendre le flot du programme. Plus la machine virtuelle est complexe plus il faudra de temps pour comprendre son fonctionnement.

Couplé à d'autres protections (cryptage, anti-debugger ring 3 / ring 0, anti file / registry monitor, junk code, anti-dump, hardware lock, drivers, dongle, etc.) et le jeu est quasiment gagné.

Certaines protections sont très fortes à ce jeu là (Themida, Synchrosoft, etc.).

Il avait fallut 1500 heures d'analyse à l'équipe (très expérimentée) qui avait réussie à bypasser la protection de Cubase 3. A ce jour Cubase 4 n'a toujours pas été déplombé et ne le sera "probablement" jamais.

Il reste encore possible à l'heure actuelle de proposer des protections qui freinent le RE et soient sûres à, disons, 99.99%. Le problème étant qu'il faut des équipes entières pour programmer ces protections et que ça coûte forcément cher à l'achat.

Le programmeur seul dans son coin et sans une solide expérience du RE n'a aucune chance face à l'armada de déplombeurs... Il lui faudra nécessairement penser à un "budget" protection si il ne veux pas voir son application déplombée en moins de deux...

[Smortex]

La protection en "vogue" en ce moment - parce qu'elle a fait ses preuves - est la "virtualisation" d'instructions au travers d'une machine virtuelle insérée dans le programme protégé.
Une partie (souvent la partie critique) des instructions du programme sont récrites dans un langage (bytecode) que seule la machine virtuelle est à même de comprendre.

Pas applicable pour les applications intensives en calcul (je parle de jours de calculs, voir d'années en distribuant les données et les calculs)... Bon, en même temps ce genre de calcul sont fait dans le milieu scientifique et grosso-modo tout est ouvert...

Pour une entreprise, la possibilité du "on déplombe le logiciel" est exclue d'office ... Il ne reste donc à protéger au final que des logiciels qui font quelque chose de complexe, qui n'ont pas réellement de concurrence et qui sont destiné au grand public... Ce dernier n'étant généralement pas compétant en informatique (et je ne parle pas forcément de désassembler un programme), je me demande vraiment comment les sociétés qui payent des équipe pour faire ces logiciels de "protection" arrivent à les commercialiser... le marché est nul à mes yeux

[smyley]

l ne reste donc à protéger au final que des logiciels qui font quelque chose de complexe, qui n'ont pas réellement de concurrence et qui sont destiné au grand public... Ce dernier n'étant généralement pas compétant en informatique (et je ne parle pas forcément de désassembler un programme), je me demande vraiment comment les sociétés qui payent des équipe pour faire ces logiciels de "protection" arrivent à les commercialiser... le marché est nul à mes yeux

Je ne suis pas tout à fait d'accord, car plus le publique est large, plus les chances qu'il y ai un hacker dans ce publique sont forte. Aujourd'hui presque tous les gros logiciels grand publique sont cracké et celà peut inclure les Jeux mais aussi Office, Acrobat ... Windows et en cherchant sur google on s'aperçoit qu'il existe une quasi-infinité de cracks disponibles et celà est surement le signe qu'une importante partie des utilisateurs de logiciels grands publique ne l'ont peut être pas payé. Celà doit surement faire un manque à gagner important pour les entreprises et surement supérieur aux investissements que ces mêmes entreprises doivent faire sur la sécurité de leurs applications ...
Longue vie aux entreprises commercialisant des logiciels de protection

[Smortex]

Certes, mais je reste personellement intimement persuadé que ce qui peut rapporter de l'argent à une société commerciale, c'est les PME... A mes yeux, les particuliers ne sont pas une cible.

Tu cite des logiciels grand publique, permet moi de commenter:

• Abrobat: combien de particuliers font de la retouche de pdf ? Toutes les applications permettent d'enregistrer en pdf de nos jours, donc je ne parle même pas de distiller.
• Office: combien de particuliers exploitent réllement MS Office (pas juste pour faire quelque chose de faisable avec write (le machine, pas bloc note, l'autre truc avec windows)
• Google: tu as pas encore ressenti le fait que toutes les pages Internet au presque aient de la pub adsence et que tes emails gmail soit parsés automatiquement pour t'associer avec un cookie qui expire dans plusieurs dizaines d'années "pour mieux te servir" ? Ha non, c'est justement du "service gratuit"... Le particulier à passé le stade de cible, c'est un pigeon, et une mine d'information

Les jeux sont effectivement un problème à part... car destinés au grand public. Mais il n'y aura je pense jamais de solution miracle (et ça s'applique aussi au piratage de logiciels par les particuliers selon ton point de vue) : les gens qui jouent ne sont pas les gens qui craquent... et parfois même avec une licence ! Juste pour le fun. J'ai des amis qui font des rootkits pour modifier le comportement de jeux vidéos en réseau (grimper aux murs, headshot sur le prochain énemie, etc...). C'est pour eux l'éternel contournement des contremesure qui sont mises en place les unes après les autres pour les empécher de jouer...

L'OS aussi est un problème à part car il est nécessaire pour utiliser le PC. Du fait du monopole de micros~1, 90% des ordinateur sont sous Windows... Lorsque le quidam de base achète une machine, il ne sais généralement pas faire la différence entre le logiciel et le hardware, et comme on est dans un état de droit où la vente liée est interdite, ben il achète les deux de manière liée (moi j'aime mon pays). 7 ans plus tard la nouvelle version de leur système sort, et ils comprennent qu'il vont devoir le payer en plus, et qu'en traverssant l'océan par avion le prix a grimpé de manière foutagedegeulistique... C'est donc un juste retour des choses, pour un particulier de pirater son OS.

A mes yeux, mettre des protections c'est prendre l'utilisateur pour une quiche. Je classe ça dans la même catégorie que les logiciels de contrôle parental: "pas le peine de vous éduquer / d'éduquer vos enfants, on pense à votre place"... Si tu ne distribue pas tes logiciels propriétaires aux gens qui te les demandent (amis, famille, ...) tu les responsabilise. Ensuite, soit ils décident de s'acheter leurs logiciels, soit il s'orientent vers des alternatives moins onéreuses.

Le problème n'est ni le particulier, ni le type qui s'éclate à contourner les protections, c'est les intermédiaires entre ces deux...

On disgrèsse du problème initial...

[Blustuff]

Mais ça s'appelle pas Write, ça s'appelle Wordpad : p

C'est difficile de mesurer le manque à gagner. Si les entreprises prennent des mesures, c'est vraissemblablement qu'elles ont étudiée le problème et qu'elles ont conclu que oui. Mais il y a une bonne partie de logiciels piratés qui ne seront jamais payés. Leur prix n'est pas forcément dans les moyens de ceux qui les piratent. Plus généralement, vu le nombre de programmes piratés par un particulier qui a cette pratique courante, il est parfois évident qu'il n'aurait pas pu tout acheter, mais peut être une partie. De l'autre coté, si pirater devient tellement facile, on se sert de ces arguments comme prétexte pour ne jamais rien acheter. Et avec l'argent économisé, on s'achète autre chose... j'sais pas moi, un PC, une machine à glaçons, etc. Donc je suppose que néanmoins, le piratage fait perdre suffisement d'argent pour mettre des petites protections, ce qui a du être révélé par des études quelconques des entreprises concernées.

[Smortex]

Mais ça s'appelle pas Write, ça s'appelle Wordpad : p

Ha oui, c'est ça ... Je m'incline humblement ! write.exe c'est bien Wordpad

C'est difficile de mesurer le manque à gagner. Si les entreprises prennent des mesures, c'est vraissemblablement qu'elles ont étudiée le problème et qu'elles ont conclu que oui. Mais il y a une bonne partie de logiciels piratés qui ne seront jamais payés. Leur prix n'est pas forcément dans les moyens de ceux qui les piratent. Plus généralement, vu le nombre de programmes piratés par un particulier qui a cette pratique courante, il est parfois évident qu'il n'aurait pas pu tout acheter, mais peut être une partie. De l'autre coté, si pirater devient tellement facile, on se sert de ces arguments comme prétexte pour ne jamais rien acheter.

Qu'est ce qui rapporte le plus à une entreprise ? 10 particuliers qui achètent chacune une licence d'un logiciel ou une PME qui achète les 10 licences pour ces employés, avec un contrat de maintenance, les MAJ, etc ... et si tout va bien de nouvelles licences régulièrement ?

Et avec l'argent économisé, on s'achète autre chose... j'sais pas moi, un PC, une machine à glaçons, etc. Donc je suppose que néanmoins, le piratage fait perdre suffisement d'argent pour mettre des petites protections, ce qui a du être révélé par des études quelconques des entreprises concernées.

... ou on achète une machine à barbes a papa Bref, j'ai bossé dans une PME où le-super-logiciel-proprio-de-la-mort-qu'on-développe-depuis-10-années-homme doit maintenant être en train de se faire surprotéger de partout avec des tas de trucs anti-reverse engineering... La raison ? Ben je suis pas sûr de savoir: ils ont embauché une personne qui se débrouille pas mal pour faire ça... mais le soft est en client serveur et toute l'inteligence est côté serveur... donc a part violer la GPL (hahummm ... c'est peut être de ça qu'ils ont peur), le client n'a rien de bien particulier... Cas isolé de paranoïa ?