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+
--
Yves Martin