›

protection des ressources

devulderdevulder Membre
dans API AppKit #1
Bonjour,



Pour un projet, j'ai besoin de mettre des images dans les ressources.



Je voudrais eviter que l'utilisateur puisse les récupérer en fouillant dans le bundle de l'application.



Comment je pourrait faire pour les cryptés ?



Merci
Mots clés:

Réponses

  • yoannyoann Membre
    #2
    Il y plusieurs méthode pour chiffrer des informations, ou éventuellement les masquer.



    Pour le chiffrement ça entend qu'il te faille la clef de déchiffrement au sein de l'application, donc coté sécurité on repassera. Tu peux éventuellement appliquer un truc bidon (ROT 13, inversion bit à  bit) juste pour ralentir les mauvais sans perdre trop d'heure de boulot sur un truc qui sera simple à  casser.



    Pour les masquer, tu as la commande chflags pour les mettre réellement en hidden sur le file system ou tu peux aussi fournir toutes tes images sous forme de plist avec les ImageData en valeur d'un dictionnaire...



    Encore une fois tout dépend du temps que tu veux y passer...
  • devulderdevulder Membre
    #3
    Merci pour la réponse, je vais voir du coté de la rotation.
  • AliGatorAliGator Membre, Modérateur
    #4
    Si tu ne cherches pas de grosse sécurité et que le but c'est juste que l'utilisateur qui fouile ton bundle ne puisse pas voir les images et double-cliquer dessus direct pour les ouvrir, il y a plus simple qu'un ROT13 (qui en plus à  l'origine est pour les textes ;-))



    Un XOR en effet par exemple mais quitte à  aller au plus simple, juste rajouter quelques octets bidons au début de tes fichiers (ou faire un XOR juste sur genre les 4 premiers octets des donnes de ton image suffira à  la rendre illisible par double-clic ou autre, tout en restant simple pour toi dans l'application à  récupérer les NSData d'origine sans avoir à  déchiffrer tous les octets dans le sens inverse.
  • devulderdevulder Membre
    mai 2012 modifié #5
    Merci pour vos réponses, je vais faire une rotation compléte.



    j'ai trouvé une méthode:


    <br />
// The magic and power of ROT13 encryption, now available via Cocoa&#33;&#33;&#33;<br />
@interface NSString (NSString_Additions)<br />
-(NSString *) rot13String;<br />
@end<br />
@implementation NSString (NSString_Additions)<br />
-(NSString *) rot13String<br />
{<br />
const char *_string = [self cStringUsingEncoding:NSASCIIStringEncoding];<br />
int stringLength = [self length];<br />
char newString[stringLength+1];<br />
<br />
int x;<br />
for( x=0; x&lt;stringLength; x++ )<br />
{<br />
  unsigned int aCharacter = _string[x];<br />
<br />
  if( 0x40 &lt; aCharacter &amp;&amp; aCharacter &lt; 0x5B ) // A - Z<br />
   newString[x] = (((aCharacter - 0x41) + 0x0D) % 0x1A) + 0x41;<br />
  else if( 0x60 &lt; aCharacter &amp;&amp; aCharacter &lt; 0x7B ) // a-z<br />
   newString[x] = (((aCharacter - 0x61) + 0x0D) % 0x1A) + 0x61;<br />
  else  // Not an alpha character<br />
   newString[x] = aCharacter;<br />
}<br />
<br />
newString[x] = &#39;\0&#39;;<br />
<br />
NSString *rotString = [NSString stringWithCString:newString encoding:NSASCIIStringEncoding];<br />
return( rotString );<br />
}<br />
@end<br />
<br />




    Par contre, j'ai un doute concernant


    <br />
char newString[stringLength+1];<br />




    Si je testes avec une grande image d'une taille d'un mégaoctect, ca risque pas de deborder de la pile ?



    Faudrais pas mieux faire une allocation via malloc par exemple ?
  • tabliertablier Membre
    mai 2012 modifié #6
    Je viens d'essayer un truc rigolo pour protéger une image.

    dans les ressources j'ai "fond1.png" que dans le projet xcode je renomme ".fond1.png"

    Puis je corrige son utilisation en ajoutant le point:

    NSImage *aufond = color=#4B0082]NSImage imageNamed:[/color][color=#FF0000]@&quot;.fond1&quot;[/color ;

    Je recompile et je constate que tout marche comme avant et que dans les ressources du bundle l'image n'est plus visible.

    Bien sur c'est très simple à  contourner, mais c'est très facile à  faire.

    Donc, ça plus une bidouille sur deux ou trois octets devraient en décourager plus d'un.
  • AliGatorAliGator Membre, Modérateur
    #7
    @devulder : comme je te l'avais annoncé, et comme tu peux le voir dans le code que tu as cité (et que j'espère tu as un peu regardé, faire un bête copier/coller sans comprendre n'est jamais bon) :



    1) L'algo de ROT13 n'intervient que sur les lettres A-Z/a-z et sur aucun autre octet. Pour une image, ce n'est pas trop adapté, tu interprètes des octets comme des lettres alors qu'ils n'en sont pas (et risque de perdre des octets si tu ne choisis pas un bon encodage de texte pour ta conversion NSData/NSString, ce qui d'ailleurs est le cas dans ton algo puisqu'il choisit l'encodage ASCII rien que pour travailler sur la chaà®ne C)... Bref, tout ce qu'il faut pour risquer de perdre des données en route.

    Pourquoi ne pas plutôt directement intervenir sur les NSData, et choisir un algo de chiffrage plus adapté aux données binaires que ROT13 qui chiffre des messages textes



    2) En effet le code alloue un buffer de la taille de ta NSString. Si en lieu de NSString tu as les octets représentants ton images, interprétés en NSString (avec le risque de perte), cette taille risque d'être conséquente, et ton empreinte mémoire risque de faire un sacré bond !



    Donc là  encore, je répète qu'un ROT13 est vraiment inadapté, et que travailler avec des NS(Mutable)Data directement serait quand même 10x mieux, et qu'en plus pour éviter les pics de mémoire, ne travailler que les premiers octets peut amplement suffir (cela suffit pour rendre l'image illisible, tout en évitant de s'obliger à  travailler avec la totalité des données de ton image en mémoire)
  • devulderdevulder Membre
    #8
    merci pour ces précisions
  • muqaddarmuqaddar Administrateur
    #9
    Salut,



    Cette discussion m'intéresse.



    Quelle serait la meilleure méthode (et assez simple si possible) pour protéger un PDF et non une image ?

    (sans passer par un mot de passe intégré au PDF, et sachant que ces PDF vont être téléchargés "en clair")



    Bref, juste le rendre illisible par double-click.
  • yoannyoann Membre
    #10
    Bah exactement ce qu'on vient de dire... Chargement en NSMutableData, XOR sur les premiers segments et hop. Ou sur l'intégralité si tu veux éviter qu'un curieux comprenne ce que tu as fait.



    Tu pensais à  quoi de plus ?
  • muqaddarmuqaddar Administrateur
    #11
    Je ne pensais à  rien de plus, je posais la question comme le PDF est un format différent d'une image...

    Je ne m'y connais pas du tout dans ce genre de protection (XOR), je vais essayer de trouver de la doc.
  • CéroceCéroce Membre, Modérateur
    mai 2012 modifié #12
    Y'a pas besoin de doc.



    Tu as un bloc d'octets, tu le parcours, et pour inverser tous les bits d'un octet, tu écris:
    octet = ~octet;




    L'opérateur ~ (NON) complémente les bits de l'opérande, c'est à  dire qu'il met les 0 à  1, et les 1 à  0.

    De fait, en inversant les bits, le fichier est illisible, mais on peut facilement revenir à  l'origine en appliquant le même traitement.



    Consulte la table de vérité de l'opérateur OU exclusif. Tu verras que lorsque deux bits sont à  1, le résultat est complémenté.

    De fait, tu peux rendre la chose plus difficile à  déchiffrer:


    octet = 0x55 ^ octet;




    55 h = 0101 0101 b

    Ainsi, seul un bit sur deux est complémenté. Tu peux évidemment choisir une autre valeur que 0x55.



    Ensuite, on peut imaginer plein de trucs: travailler sur plus d'un octet, faire des décalages de bits, etc.

    ça n'arrêtera pas un hacker expérimenté, mais le couillon moyen, si.
  • muqaddarmuqaddar Administrateur
    #13
    Merci Céroce.



    Oui, c'est ça je veux arrêter le "couillon moyen", pas le hacker. ;-)
Connectez-vous ou Inscrivez-vous pour répondre.