Wpf/silverlight Deep Solution: self-protection of Silverlight source code

When a Silverlight application is published, all local resources and class library DLLs are packaged into a xap file, and the benefits are easy to deploy and desktop in Web pages, but at the same time bring a high level of exposure to source code. As we all know, the XAP file can be opened by Zip and other decompression software, inside the DLL and a variety of material resources at a glance, and then through the ****reflector and other tools to perfectly decompile these DLLs, even the content in XAML can be reflected clearly, This makes me think of Flash. The SWF in the Web page can be downloaded by a multitude of download tools, and the same resources will become obscured by the use of tools such as the Flash Wizard to decompile and even concrete to every frame.

In a country with a sound legal system, the protection of intellectual property is in every possible way, and what should we do in the age of plagiarism in China?

The ultimate goal of protecting Silverlight source code is only one: to protect the XAP file. Here are some of the protection solutions I have summed up, hoping to help you:

Method One: Disable critical file or folder page caching

In the case of IIS, we can set the site ClientBin directory where the Silverlight application is erected to prohibit page caching:

In this way, the XAP file in the Silverlight application ClientBin directory will not be cached to the C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files directory, other people will not be able to copy the XAP file from the browser cache. However, through the "View source file" and find clientbin/****.xap this code, and then use thunder and other download tools to paste the page address + this code, regardless of permissions and port restrictions, it is difficult to prevent the XAP file is downloaded bad luck; more importantly, Not caching will cause users to re-download the xap file each time they access it, not only increasing the burden on the server, but also the performance of a very unfriendly experience.

Method Two: Use JavaScript to encrypt key HTML parts of the code

In order not to expose clientbin/****.xap this code, we can do a lot of things. For example, it is forbidden to view the source file, prevent the page from being saved as, prohibit the use of certain shortcut keys and right mouse button and so on, but this is also very unfriendly, and very easy to be cracked, after all, the method is too old. At this point we might consider using some fraudulent means, such as encrypting HTML code with JavaScript. There are so many ways to Javascrpit encryption that you can search your own key sentence: "JavaScript encryption and decryption." The simplest and most straightforward way to do this is to use the Jscript.encode encryption method with Escape mode:

Then we forge a fake xap vector control, and the final page will be the following code:

You see, just a line of JavaScript code is almost identical, In order to successfully disguise the real ak47.xap file as a fake silver.xap file, even you can actually place a messy silver.xap file in the ClientBin directory, let download its friends confused, so as to achieve the perfect code camouflage.

This way you can cheat a lot of people (of course, see my article's friends except ^ ^), Even some of the. NET masters who have not yet contacted Silverlight, however, once you encounter a good JavaScript player, the word escape immediately exposes the nature of the HTML disguise, and then easy decryption is easier.

Method Three: Prevent users from reaching the critical page by Iframe+javascript

This method needs to prepare an additional page as the home page, which uses an IFRAME to load the page containing the Silverlight application, for example:

<iframe src= "mygame.aspx" width= "820" height= "580" frameborder= "no" border= "0"/>

In the same way, the same method is used to encrypt the camouflage by means of two methods. Next is the key to this method, add the following JS in the Mygame.aspx page:

<script type= "Text/javascript" >

if (self.location = = top.location) {self.location = "http://www.cnblogs.com/alamiye010"}

</script>

The principle of this approach is simple: by judging whether Mygame.aspx is a sub-page to achieve page protection. You may wish to enter the page address directly in the browser address bar, will find the page directly to a pre-set of our page: http://www.cnblogs.com/alamiye010, so as to achieve the Mygame.aspx key page is not directly opened for the purpose. In the same way, we can combine this method with method two to further the page protection, even if the client users do everything possible to disable the browser JS, we can also be <object>...</object> This section of the behind code in the Page_Load method by a similar registerstartupscript way to load dynamically, so that <object>...</object> this code with the browser JS Perfect bundle, You can do my work, you forbid me.

However, stronger and stronger in the hand, now there are many tools or plug-ins can directly extract the page in the memory of the XAP, can easily be inside the flesh and even every cell to export cleanly. The names of these guys I really don't want to mention, personally understand that this is a stain on the divine technology, their existence is not a reflection of the progress of society, is it penetrating the heart of others can make you feel the pleasure?

Method Four: Source confusion of the universe is a big diversion

In response to these vicious terrorist acts, we have to resort to the killer stream: the traditional and most defensive approach----code obfuscation.

. NET code obfuscation is a lot, and the integrated Donfuscator Community Edition in VS is a simple and useful code obfuscation tool:

But currently the latest version of the Donfuscator Community Edition is still unable to directly confuse Silverlight-published DLLs, because the XAML file resources contained within it are temporarily useless. So I'll give you two tips: 1) Try to put methods and objects in the class library, remove all comments when publishing, and use obfuscation tools to confuse each class library-generated DLL and finally re-reference the obfuscated DLL. This way, even if mainpage is recompiled, the logic code inside will remain extremely difficult to learn. 2) Self-writing a source obfuscation tool for your Silverlight project, how it can be tailored to your project, is essential for the protection of large project core code.

Here's what I see after confusing the Silverlight application DLL through the anti-compilation software:

I wonder if you can understand the framework and method logic of the whole project? ^ ^

Using method Four, the preceding 3 methods are negligible, can be described as the ultimate Silverlight source protection scheme. However, there is no readily available and mature Silverlight-based obfuscation tool, which often invisibly increases the total amount of project development work.

Wpf/silverlight Deep Solution: self-protection of Silverlight source code