Hello, au cas ou tu serais passé à coté de ces post http://groups.google.com/group/fcng/search?group=fcng&q=xor&qt_g=Rechercher+dans+ce+groupe
Je pense qu'il y a des infos qui pourrait d'intéresser. Lionel On 30 sep, 19:10, Benjamin Guillotte <[email protected]> wrote: > Hello, > > Une solution reste possible pour toi, j'essaye de mieux expliquer. > > La solution est celle du loader qui charge le swf en bytearray. > Tu me dit que tu as déjà fait le test avec un embed. Effectivement le > 'hacker' peu trouver l'information car le SWF embed est dans ton SWF. donc > si je récupère le SWF , je décompile et je prend la partie data de ton embed > et reconstruit un SWF avec. > > Par compte ma méthode pose un gros probleme au hacker. En effet, tu recoi > (par amfphp ou php simple) le bytearray du swf stocker coté serveur (mais > non récupérable car caché). Effectivement le hacker pourra toujours taper > sur l'url pour récupéré le flux mais ca complique un peu plus ca démarche. > > De toute facon, désolé d'avoir une nouvelle négative, mais il n'y a aucune > solution complettement bloquante avec flash. L'astuce reste de mettre > plusieur palier (url du php crypter, qui ensuite charge un flash en > bytearray, qui lui pourrai etre crypter avec une clef hexa d'un png charger > a la volé...... ainsi de suite) > En terme de sécurité, seule la méthode du découragement marche. > > Bon courage. Et si tu veux, envoi le résultat pour un test de sécurité :) ca > me plait les défis :) > > Skat > > Le 30 septembre 2010 19:01, Gwenn Guihal <[email protected]> a écrit : > > > > > Hello, > > > Donc déjà merci à Benjamin pour sa réponse. > > On n'utilise pas AMF, mais simplement du xml pour les échanges > > client/serveur. > > Donc déjà pas mal de tes solutions ne sont malheureusement pas exploitables > > ici. > > J'avais déjà inclu dans un swf un autre swf contenant la clé lors de la > > compilation (similaire à ta dernière solution), mais l'audit de sécurité du > > client avait réussi à choper la clé publique : > > > [Embed (source = "../cryptkey.swf", mimeType = "application/octet-stream")] > > private var MyClass:Class; > > > Donc pour zwetan (et les autre) je m'explique mieux. > > > Ce que je veux en effet, c'est qu'entre A(Client) et B(Server), C ne puisse > > pas comprendre ce que A envoie à B et ne puisse pas non plus, le renvoyer > > (validité). > > Pour ça j'imaginais que B envoie à A un token avec un délai d'expiration et > > A doit bien entendu le renvoyer. Cependant, pendant ce laps de temps, C peut > > très bien envoyé ce qu'il veut. > > > Donc à ce moment là, je pensais tout simplement crypter les échanges de A à > > B mais aussi de B à A. > > Comme ça, si C arrive à intercepter le token, il sera crypté et donc ne > > pourra pas rien en faire. En plus, une fois que A a renvoyé son score (par > > exemple) avec le token, ce même token expire donc si C renvoie le même > > message, ce dernier sera rejeté. > > > Alors dites moi si j'ai faux pour le moment ? > > > Par contre, concernant le cryptage c'est là que le bas blesse. Un SWF peut > > facilement se décompiler et donc la clé publique sera visible. Je n'ai pas > > envie d'obfusquer mon code, trop lourd à faire et j'ai eu de mauvaises > > surprises (des erreurs au runtime). > > > Donc voilà, je me demande qu'elles sont vos solutions pour ce type de > > problème ? > > > Merci, > > > Gwenn > > > Le 30 septembre 2010 18:08, zwetan <[email protected]> a écrit : > > > alors avant de répondre je vais demander ce que tu cherches a > >> sécuriser ? > > >> - juste les échange de données ? > > >> cad si A envoie un message à B, tu ne veux pas que C puisse > >> comprendre le message ? > > >> - le swf lui-meme ? > >> cad tu ne veux pas que qlqn puisse voir le code qu'il y a dans le > >> SWF ? > > >> - la validité du message envoyé au serveur ? > >> cad si A envoie un message a B, tu ne veux pas que C puisse > >> répliquer le message et/ou se fasse passer pour B ? > > >> - l'authencité ? > >> cad si A dit à B qu'il est "A", tu veux pouvoir verifier que c'est > >> bien le cas ? > > >> etc. > > >> idéalement, plutot que de rester dans le vague et de s'amuser au > >> telephone arabe, > >> il a a dit que l'autre a dit que un autre lui avait dit que c'est ca > >> qu'il faut sécuriser, > >> ce serait plus simple que tu décrive ce que tu cherches a sécuriser > >> concretement > > >> l'envoie d'un score de jeu vers le serveur ? > >> la sauvegarde d'un password pour recup des données ? > >> la code source du client SWF ? > >> etc. > > >> dans ce que tu as mis au dessus: > > >> si tu utilises du PKI, bah la clef publique est justement là pour etre > >> publique > >> donc obfusquer le SWF ca ne sert a rien, > >> cela indique aussi que tu veux proteger le contenu du message du > >> client vers le serveur, > >> donc en soit si qlqn decompile le SWF idem on s en fout aussi. > > >> bref, ce que tu cherches a protéger n'est pas tres clair > > >> zwetan > > >> -- > >> Vous recevez ce message, car vous êtes abonné au groupe Google > >> Groupes FCNG. > >> Pour envoyer un message à ce groupe, adressez un e-mail à > >> [email protected]. > >> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse > >> [email protected] <fcng%[email protected]>. > >> Pour plus d'options, consultez la page de ce groupe : > >>http://groups.google.com/group/fcng?hl=fr > > > -- > > Vous recevez ce message, car vous êtes abonné au groupe Google > > Groupes FCNG. > > Pour envoyer un message à ce groupe, adressez un e-mail à > > [email protected]. > > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse > > [email protected] <fcng%[email protected]>. > > Pour plus d'options, consultez la page de ce groupe : > >http://groups.google.com/group/fcng?hl=fr -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes FCNG. Pour envoyer un message à ce groupe, adressez un e-mail à [email protected]. Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/fcng?hl=fr
