Plus globalement, il y aussi une solution assez radicale de proposer
l'application déployée dans l'OS qui va bien sous forme de CD bootable
installable (Knoppix fashion ...) ou image virtuelle (Vmware fashion
...) ; le seul exemple qui me vient c'est
http://www.trixbox.org/ mais
j'en ai vu d'autres.
A+
Aimé
Poize Michel a écrit :
> Yves
>
> Effectivement c'est bien pour essayer de mettre en place un sytème de
> licence qui permet de verrouiller une appli
> sur un ordi : c'est pas du libre ( mais c'est quand même linux :-) )
> De toute façon ce n'est pas moi qui en décide mais c'est le client ....
>
> Pour identifier la machine j'utilise ;
> -les adresse MAC s'il y en a
> -/dev
> -/bin
> -/sbin
> -/usr
>
> Comme tu le dis , le but n'est pas de faire un truc super sur mais de
> contôler un minimum la diffusion de l'appli.
> L'appli est elle même en java (obscurci quand même ...)
>
> Merci à tous pour toutes les infos : je comprends mieux ce qui se
> passe et je vais adapter la procédure
>
> A+
>
> Michel
>
> ----- Original Message ----- From: "Yves Martin" <ymartin59@???>
> To: <guilde@???>
> Sent: Thursday, September 06, 2007 12:23 PM
> Subject: Re: inode et /dev
>
>
> Selon Poize Michel <michel.poize@???>:
>
>> Le changement apparait aprés un reboot.
>>
>> A l'origine du problème : pour une appli client j'ai fait une clè
>> soft qui
>> permet d'identifier l'ordi sur
>> lequel l'appli tourne : cette clé contient les infos suivantes :
>> adresse des
>> carte réseaux s'il y en a , host name
>> plus quelques infos que je pensais non modifiables aprés installation
>> comme
>> le inode de /dev
>>
>> Jusqu'a présent il n'y avait jamais eu de problème mais dernièrement un
>> utilisateur a eu sa clé invalidée aprés un reboot
>> et l'origine du problème provient apparemment d'une modification de
>> inode de
>> /dev
>
> Original. Ça sent la vérification de licence ;) Tu ne fais pas du libre ?
>
> Avec des vieux Linux où le /dev est un répertoire normal contenant des
> fichiers
> spéciaux, c'est OK.
> Comme je l'ai constaté, udev et tmpfs s'attribue un inode au
> montage... et (très
> probablement) différente à chaque boot.
>
> Comme l'inode d'une racine de fs est toujours "2", "/" ne convient
> pas, "/var"
> non plus si c'est une autre partition.
>
> Je te propose d'utiliser l'inode de /bin ou /boot dont on fait
> rarement une
> partition séparée.
>
>
> Sinon l'adresse MAC peut être modifiée (mais difficile d'en avoir deux
> identiques sur le même réseau, j'en conviens)...
>
> Tu pourrais utiliser l'UUID du FS root:
> dumpe2fs /dev/sdX | grep "Filesystem UUID"
> mais ça se change aussi par tune2fs et c'est limité à un type de fs.
>
>
> Ma boîte a essayé de protéger son code d'un déploiement multiple de la
> sorte -
> évidemment avec une lib native en C appelée depuis une JVM - le code
> Java étant
> plus facile à analyser et modifier mais le C n'assure que peu de
> protection
> supplémentaire si on sait y faire.
>
> Pour casser ce genre de prélèvements d'information pour "répliquer" une
> installation à partir d'une licence unique sans modifier
> l'application, il
> suffit de ldd et strace pour voir quels sont les fichiers lus et les
> informations prélevées pour contrôler la licence.
> Et ensuite de faire des bibliothèques "wrapper" (pas trop dur avec un
> générateur
> de code et le source des bibliothèques d'origine) qui fournit les
> informations
> attendues par le code de licence à la place de celles présentes sur le
> système
> mais laisse passer les autres appels à la version originale.
> On insère ensuite ces .so avec un LD_LIBRARY_PATH et l'affaire est jouée.
>
> Cela m'a été inspiré par le fonctionnement de "fakeroot" qui redirige
> les appels
> à la libc vers une version modifiée pour permettre des opérations que
> seul root
> a le droit de faire.
>
> J'aurai plus confiance dans un dispositif hardware dont le
> fonctionnement est
> obscure ou repose sur de la cryptographie (défi/réponse) pour prévenir
> d'un
> court-circuitage logiciel qui peut se faire à tout niveau de toute façon.
>
> En conclusion, la seule chose que l'on gagne par ces protections - c'est
> d'allonger le temps nécessaire au contournement - et dans ce cas, le
> temps c'est
> l'argent (des autres). Si la protection semble plus longue à casser, que
> l'argent nécessaire pour la payer c'est gagner. Reste à ce que la
> conception de
> la protection ne demande pas plus de temps que l'argent que l'on peut
> y gagner
> ;)
>
> Mais cette logique "capitaliste" n'est pas valable pour les crackers qui
> passeront des mois à casser une licence et à diffuser le résultat...
> surtout
> quand il s'agit de produits provenant d'entreprises qui se vantent des
> soit-disant protections mises en place !
>
> A+
