Resource encryption bug
GandalfTheWhite
Posts: 3
Hey all,
I'm trying Smart Assembly V5.5 Build 153 to protect a silverlight 4 project I'm working on. It seem to be working nice for the most part. The issue I am seeing is that my resource file is not encrypted.
If I load the protected dll file from my xap into Reflector, under the resources area, there are 2 entries (compared to 1 before the protection). 1 is a jumble of binary it looks like but the other resource line shows all my images & xaml files. I am able to view & save all the files onto my desktop, which from what I understand should not be possible.
I also noticed when using SA to protect my xap file, it generates a 2nd AppManifest file with the exact same information as the original file so I now have 2 of them in my xap.
When loading the protected file into reflector, should it state that the object reference is not set to an instance of an object when enabling the fake metadata stream. I'm guessing that is how the option works based on getting that msg in reflector when viewing code protected through .net reactor & some other protector demos I've tried.
I'm not sure if this is an included feature or not, but I noticed my assigned names in my silverlight xaml files do not get renamed after to hide what my cs code is calling.
The product seems nice but unless I am doing something wrong, it appears to have a couple of bugs in it still for silverlight projects.
I'm trying Smart Assembly V5.5 Build 153 to protect a silverlight 4 project I'm working on. It seem to be working nice for the most part. The issue I am seeing is that my resource file is not encrypted.
If I load the protected dll file from my xap into Reflector, under the resources area, there are 2 entries (compared to 1 before the protection). 1 is a jumble of binary it looks like but the other resource line shows all my images & xaml files. I am able to view & save all the files onto my desktop, which from what I understand should not be possible.
I also noticed when using SA to protect my xap file, it generates a 2nd AppManifest file with the exact same information as the original file so I now have 2 of them in my xap.
When loading the protected file into reflector, should it state that the object reference is not set to an instance of an object when enabling the fake metadata stream. I'm guessing that is how the option works based on getting that msg in reflector when viewing code protected through .net reactor & some other protector demos I've tried.
I'm not sure if this is an included feature or not, but I noticed my assigned names in my silverlight xaml files do not get renamed after to hide what my cs code is calling.
The product seems nice but unless I am doing something wrong, it appears to have a couple of bugs in it still for silverlight projects.
Comments
In regards to the 2nd AppManifest file being generated, will that be corrected? If I directly read in the silverlight dll file I build, then just the protected version is created. Reading the actual xap file & then building the protected version has the program put 2 AppManifests in the xap file.
For the fake metadata feature, have you been able to verify if it works properly with silverlight because of what I explained above. If that feature has not been setup to work with silverlight yet (compared to .net reactor for instance, which does prevent viewing the file in reflector) will it be fixed to disable itself for silverlight apps?
The last thing, which I didn't mention last time, is there are a few typos when selecting the project options. There are sentences that have words that run into each other instead of having a space between them.
We're considering removing the fake metadata stream feature altogether because it doesn't provide any protection against the people that matter (crackers and people who want your intellectual property), it only ever stopped the casual observer (usually the developer) seeing inside the assembly.
Developer,
Red Gate .NET Tools