Forum Programmation.c++ texte visible dans une librairie dynamique

Posté par eric le 18 décembre 2007 à 12:03.

Étiquettes : aucune

déc.

2007

Bonjour,

je viens de compiler un librairie dynamique, celle ci fonctionne sans souci .
Là ou je suis embêté et étonné , c'est qu'en éditant ma librairie avec un éditeur de texte , apparaît en clair les valeurs de certain tableau de caractères( des char *).

comment puis-je éviter cela??

merci de vos réponses

ps : ces tableau de caractères sont des sous programmes qui sont compilé à la volée , et ces codes ne sont pas ouvert... d'où ma question

quelqu'un a une idée???

# strip

Posté par left le 18 décembre 2007 à 12:21. Évalué à 2.

Essaye peut etre de stripper les .o
- [^] # Re: strip
  
  Posté par eric le 18 décembre 2007 à 12:33. Évalué à 1.
  
  merci de ta réponse
  
  Cependant, je suis un débutant , je sais même pas ce que veut dire stripper
  c'est une option de compilation de gcc?
  comment mettre cela en place ?
  - [^] # Re: strip
    
    Posté par eric le 18 décembre 2007 à 13:17. Évalué à 1.
    
    j'ai essayer en ajoutant -s à g++ (g++ -s -shared -o"test.so" ./Source/test.o -lacml -lGLEW -lglut -lgfortran)mais c'est la même chose , tout mes char* sont lisible en éditant le .so...
    - [^] # Re: strip
      
      Posté par Anonyme le 18 décembre 2007 à 13:54. Évalué à 1.
      
      Comment veux tu qu'il en soit autrement: si tu as besoin de ce morceau de code pour le compiler a la volee, il faut bien qu'il se trouve qqpart dans ta bibliotheque...
      L'utilitaire strip suggeré plus haut ne fera qu'eliminer les chaines de caracteres inutiles pour l'execution du code: ton tableau de caracteres constitue des donnees que strip ne touchera pas.
      
      La question à se poser si tu veux conserver ce code fermé, c'est pourquoi le compiler à la volée ? Si il dépend de certaines entrées de l'utilisateur de l'application utilisant ta bibliotheque, est ce qu'il ne vaudrait pas mieux le compiler comme une bibliotheque dynamique qui contiendra une fonction à laquelle tu passeras tes parametres.
      - [^] # Re: strip
        
        Posté par eric le 18 décembre 2007 à 14:51. Évalué à 1.
        
        malheureusement c'est impossible.
        ce sont des fragment program, qui sont compilé par la carte graphique, je ne peut pas les précompiler
        
        [^] # Re: strip
        
        Posté par GeneralZod le 18 décembre 2007 à 15:47. Évalué à 2.
        
        Plusieurs solutions qui me viennent à l'esprit :
        * obsfuquer le code. http://www.ioccc.org/
        * chiffrer le code et le déchiffrer à la volée.
# Savoir où agir.

Posté par Obsidian le 18 décembre 2007 à 17:52. Évalué à 2.

comment puis-je éviter cela ? ps : ces tableau de caractères sont des sous programmes qui sont compilé à la volée , et ces codes ne sont pas ouvert... d'où ma question

Il s'agit là encore, comme bien souvent, d'un problème initial de conception et pas d'une limitation du compilateur. Si l'accès à ces codes doit être restreint, alors il doivent être explicitement protégés. L'une des manières de faire est d'utiliser une clé de cryptage, mais cela signifie également que le programme doit contenir la clé pour les lire.

Ca veut donc dire que si l'ordinateur peut (et doit) le faire, alors une personne quelquonque peut le faire aussi.

Reste à savoir quel niveau de protection tu comptes atteindre. S'il s'agit juste de masquer le code à la vision du premier utilisateur venu, un bête XOR pourrait presque suffir (à écarter quand même pour le principe). Si l'accès à ces codes ne doit EN AUCUN CAS être révélé, alors il faut les déporter dans un *.so distinct, et utiliser les droits d'accès du système (comme pour les mots de passe). Sachant qu'en tous les cas, un administrateur motivé pourra toujours les retrouver en quelques minutes.
- [^] # Re: Savoir où agir.
  
  Posté par eric le 19 décembre 2007 à 11:13. Évalué à 1.
  
  bonjour ,
  merci de vos réponses.
  
  je voudrait utiliser une protection correct, comment déporter les codes dans un .so distinctif et utiliser les droits d'accès système?
  les personnes qui ouvrirons ce .so distinctif , auront-elle accès au codes?
  avez vous une doc à m'indiquer qui me permettrai une tel protection ?
  - [^] # Re: Savoir où agir.
    
    Posté par Nicolas Boulay (site web personnel) le 19 décembre 2007 à 12:32. Évalué à 2.
    
    Je ne connais de protection tel que tu en veux qui ne se casse pas facilement.
    
    Cela existe sous windows, c'est payant. Sous Linux, je ne sais pas.
    
    Ce que tu cherches c'est empecher le reverse engeenering de ton code, pour cela tu dois crypter tes chaines dans ton binaire.
    
    si tu ne peux le faire avec un outils externe, tu peux le faire toi meme en chiffrant tes strings puis en les dechiffrant au besoin en changeant de clef de preference et en utilisant un vrai algo type AES ou DES et pas une bidouille genre rot-13...
    
    Il faut s'ecrire une moulinette qui te crypt tes strings et ecrire la fonction qui va relire ses strings et les clefs associes.
    "La première sécurité est la liberté"
  - [^] # Re: Savoir où agir.
    
    Posté par Obsidian le 20 décembre 2007 à 19:01. Évalué à 2.
    
    En fait, il faut bien se rendre compte que ton propre code C++, celui même que tu vas compiler, ne sera pas protégé non plus. Le fait qu'il soit sous forme de langage machine ne le rend pas en lui-même indéchiffrable. Ceci est vrai, d'ailleurs, pour tous les exécutables, sous Windows comme sous Linux, ou ailleurs.
    
    Il faut donc bien savoir quel genre de protection tu comptes apporter. S'il s'agit juste de complexifier la lecture de manière à ce que l'on ne puisse pas voir le code en clair avec un bête éditeur de texte, alors un codage type DES avec la clé de ton choix fera parfaitement l'affaire. Cela obligera les gens à la chercher au sein de ton code compilé et à aller décrypter tes chaînes directement, ce qui réserve cette tâche aux programmeurs.
    
    S'il s'agit de masquer le code même aux utilisateurs les plus avertis et motivés, là par contre, il n'y a pas de solution miracle. Il faut mettre ton code dans un fichier spécial qui va être lu par ton application principale (soit directement, soit par l'intermédiaire du mécanisme des bibliothèques partagées *.so) et là, tu mets des droits d'accès dessus. Tu te débrouilles ensuite (via des bits setgid par exemple, mais pas root) se lance sous une identité qui te permette d'y accéder.
    
    Ca veut donc dire que l'utilisateur moyen d'un système d'entreprise ne pourra jamais y accéder. Par contre, l'administrateur et toute personne sudoer pourra toujours le faire s'il en a la motivation.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.