2008-09-22 13 views
3

Je me demande comment cacher notre code Silverlight. Je sais qu'il y a quelques obfuscators disponibles mais il semble que les gens peuvent pirater cela aussi. Quelqu'un a-t-il du succès sur ce front?Obscurcir Silverlight XAP

Répondre

4

Pragma No-cache sur la page d'accueil de l'application silverlight empêchera le navigateur de la mise en cache du XAP, au lieu qu'il lira en streaming à partir du serveur Web. Cela rendra plus difficile pour les peeps d'obtenir le xap. L'obscurcissement le rendra encore plus difficile.

Assurez-vous également que l'application est hébergé dans https, ont authentification lieu en dehors de l'application principale. De cette façon, le flux xap est codé à la baisse.

+2

mais l'attaquant obtiendra le XAP en utilisant Firebug, la mise en cache et Https activé ou non. Il ne verra même pas tes efforts, n'est-ce pas? – Eilistraee

2

Non. Le navigateur client doit être capable de lire le code, donc il est piratable.

4

Vous ne pouvez vraiment pas cacher tout ce qui est transmis au client. Si les gens veulent le comprendre, ils le feront.

Vous devez mettre tout code propriétaire dans votre back-end où les machines clientes ne peuvent pas obtenir à elle.

0

Vous ne pouvez pas cacher (du moins pas non trivialement) fichiers XAP. Mais vous pouvez les obscurcir. L'obfuscation n'est pas une réponse définitive, mais c'est un début et peut donner une assez bonne protection.

1

Vous pouvez compliquer le travail du pirate potentiel en téléchargeant des fragments brouillées de votre application lors de l'exécution, en utilisant par exemple MEF. Inutile de dire que c'est intéressant si votre application est assez grande pour que cette astuce accélère le temps de démarrage plutôt que d'entraver l'expérience de l'utilisateur. Cela n'empêchera pas un hacker valeureux d'obtenir votre code (dans la main aucune méthode ne peut l'empêcher, car le plugin Silverlight doit être capable de l'exécuter), mais l'astuce compliquera grandement sa tâche. Empêcher le navigateur de mettre en cache le XAP est inutile, comme utiliser HTTPS, car il est beaucoup plus facile pour l'attaquant d'utiliser quelque chose d'aussi compliqué que firebug pour obtenir le XAP que de le chercher dans le cache du navigateur ou d'utiliser un homme dans le Middle Attack.

J'imagine que si vous avez eu beaucoup de motivation, vous pouvez:

  • Occultation tous les ensembles
  • utilisation XAPs chargés dynamiques
  • chiffrer le Serverside XAP chargé dynamique et les déchiffrer côté client à l'aide d'un dynamicly clé générée envoyée par un service Web (pas dans la même demande et ne pas réutiliser la clé.)

Cela n'empêchera pas l'attaquant d'obtenir votre code, mais il aura Ve pour analyser votre xap initial (obscurci) pour comprendre le code de décryptage, obtenir la clé, obtenir le XAP chargé (brouillé) dynamiquement, le décrypter, puis réussir à le désobéir, puis comprendre comment il se branche dans l'application. Ce n'est pas la même chose que d'utiliser HTTPS, car ici le processus de cryptage et de décryptage est fait dans l'application afin que les outils comme firebug ou fiddler deviennent inutiles.

Hem. Rien ne peut empêcher quiconque de lire votre code. MAIS vous pouvez le faire ne vaut pas son temps.Vous n'avez pas à utiliser toutes les idées ici et je suis sûr que vous pouvez en trouver d'autres, mais assurez-vous que la mise en œuvre de telles mesures vaut également votre temps.

Quoi qu'il en soit, il était assez drôle d'écrire ceci: p