Good day!
I want to distribute the c# application and want protect it.
I need:
obfuscation - protection of the source code + text resource files.
error reporting - a report on Unhandled Error.
clear view obfuscated stack trace
ensure there are no changes to source code.
What problems can get out due to the obfuscation (eg serialization / deserialization / reflection / globalization)? Appreciate the complexity of solutions this problems?
What methods / tools / approaches you recommend?
Thanks for help!
Disclaimer: I work for Red Gate.
SmartAssembly does what you're after. For your points in turn:
1) It does control flow obfuscation, method / field renaming, compression / encryption of resources and embedded strings, and separation of methods from their containing classes.
2) Automated error reporting automatically detects and reports unhandled execptions (it also grabs and sends the stack trace, values of all local variables, and some general system info).
3) The obfuscated stack trace gets decoded again on your machine so you can see it in clear view.
4) Not 100% that I know what you mean by this, but tamper protection prevents the app from running at all if any modifications are made to it. If you mean you don't want to make changes to your own source code, it is run as a post-build process so doesn't need any changes to be made to the source.
Re problems you might get with obfuscation, by far the most common are because of reflection (as a result WPF often causes problems), and data binding causes lots of issues too. Most obfuscators should let you exclude individual types and methods which have problems with reflection, though obviously that leaves those types and methods unprotected.
There are other obfuscators too - I know a couple of people who use one from PreEmptive called dotfuscator.
Crypto Obfuscator supports all the features you are looking for including obfuscation, code-protection as well as Exception Reporting (with automatic de-obfuscation as well as full values of all method parameters and local variables).
Another unique feature of Crypto Obfuscator is the Warnings tab shown after obfuscation. This lists all lines of code in your assemblies which can potentially cause the obfuscated assembly to fail. SO you don't have to shoot in the dark trying to figure out why obfuscated assemblies are not working.
DISCLAIMER: I work for LogicNP Software, the developer of Crypto Obfuscator.
Related
We recently hit a bug in our code that was caused by a subtle difference in how DevForce behaves under Silverlight compared to non-Silverlight environments. We found out the hard way that when DevForce raises an 'all properties have changed' event in Silverlight, it does so by using string.Empty in the PropertyChanged event. However, in non-Silverlight null is used instead. This wasn’t that hard of a fix on our end – we likely should have been watching out for either null or string.Empty all along. But it got us worried if there are other subtle differences like this that we should be looking out for.
Are there any other known differences between Silverlight and non-Silverlight like this? Obviously there are some differences such as Silverlight not allowing synchronous queries...but that is well documented. I'm looking for small things like this which might break code that previously worked fine in Silverlight.
Sorry you ran into the PropertyChanged issue. That divergence actually came about due to an old bug in the SL DataForm, but it's never been re-addressed in DevForce because MS documentation does say that both null and the empty string do the same thing. FWIW, DF uses the empty string here in all non-full .NET environments.
We don't have any documentation on these subtle differences. In general, most environment differences result in a different surface area, usually with a reduced API. So as you noted the synchronous methods are only found in the .NET assemblies, while you'll find XAP-related APIs in the SL assemblies. Other "missing" or changed features would be things like file I/O and .config file handling.
In general DF tries to rationalize the APIs and behaviors across environments, although there can be subtle differences or performance impacts in the underlying implementations. For example, WCF, composition (MEF), serialization and reflection are a few areas which we've found don't always work quite the same across environments, although we've tried to mitigate these within DevForce so apps don't see the issues. DF also has shim/dummy implementations for some attributes (mostly for ODATA and data annotations) in non-.NET environments, which could cause issues if you're expecting the real types.
I've scanned for a few differences which might not be obvious: 1) a parameterless constructor is required when cloning in non-.NET, 2) compile-time validation of the use of the ProvideEntityAspect and ProvideComplexAspect attributes is done only in .NET, 3) attempts to do encryption/decryption with the FIPS parameter set will throw a NotSupportedException in non-.NET.
There are differences in design-time support too. In SL weird security and serialization exceptions will be thrown by VS when using the ECS or using design-time data based on a code first model.
I should also note that if you're doing .NET unit testing of your SL code you cannot assume the code will also work in SL. You really need to test in SL too to avoid surprises.
If you have questions about any specific areas of DevForce or run into any unexpected environment differences let us know.
How can I store, for example, the body of a method in a database and later run it? (I'm using Delphi XE2; maybe RTTI would help.)
RTTI is not a full language interpreter. Delphi is a compiled language. You write it, compile it, and distribute only your binaries. Unless you're Embarcadero, you don't have rights to distribute DCC32 (the command line compiler).
However, the JVCL includes a delphi-like language subset wrapped up in a very easy to use Component, called "JvInterpreter". You could write some code (as pascal) and place it in a database. You could then "run that code" (interpreted, not compiled) that you pull from the database. Typically these should be procedures that call methods in your code. YOu have to write some "wrappers" that expose the compiled APIs that you wish to expose to the interpreter (provide access to live data, or database connection objects, or table/query objects). You're thinking that this sounds perfect right? Well, it's a trap.
Beware of something called "the configuration complexity clock". YOu've just reached 9 o'clock, and that's where a lot of pain and suffering begins. Just like when you have a problem, and you solve it with regular expressions, and "now you have two problems", adding scripting and DSLs to your app has a way of solving one problem and creating several others.
While I think the "DLL stored in a database blob field" idea is evil, and absurd, I think that wanton addition of scripting and domain-specific languages to applications is also asking for a lot of pain. Ask yourself first if some other simpler solution could work. Then apply the YAGNI principle (You Ain't Gonna Need It) and KISS (keep-it-simple-smartguy).
Think twice before you implement anything like what you're asking about doing in your question.
Your best Option, IMHO, is using a scripting engine and storing scripts in the database.
Alternatively you could put the code in a dll and put that dll in the database. There is code for loading a dll from a resource into ram and processing it so it can be used as if it was loaded using LoadLibrary, e.g. in dzlib. I don't really know whether works with any dll and in which versions of Windows, but it does with the ones I tried.
Normally, I put what I consider the constitutional root resources, such as brand colours/brushes, fonts and sizes down in the 'distrib' assembly.
The Distrib assembly|ies are designed to go out to 3rd party dev shops, so they have access our contracts, interfaces, and branding styles.
More complex resources are then built up and declared 'nearer' where they're used.
I've come along to an application that has grown organically, err, haphazardly. What's odd is that the modules use resources from the main app executable project, even though the modules don't reference the app.
I assume that because they're 'importing' all the resources into App.xaml, they're available to the psuedo-runtime designer context.
My question is
If this is how MS designed it to work, have I been doing it wrong all along by managing resources like I do a type system?
Thanks
Luke
** UPDATE **
So, it was pointed out to me that well organised resources are not the way to go in WPF due to a severe performance problem (much as I had found in a big SL4 app I worked on, but assumed it was an SL thing).
Assuming that managing resources in this highly organised way can still be done with a trick or two, and that modular systems often need to merge dictionaries, I began to look into using Christian Moser's SharedResourceDictionary solution, but I get a problem at design time only:
System.IO.Packaging.PackUriHelper
The URI prefix is not recognized.
at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
at System.Net.WebRequest.Create(Uri requestUri)
at MS.Internal.WpfWebRequestHelper.CreateRequest(Uri uri)
at System.Windows.ResourceDictionary.set_Source(Uri value)
at CompanyName.Presentation.SharedResourceDictionary.set_Source(Uri value)
It looks like it doesn't understand the pack Uris, which is odd since the SharedResourceDictionary just calls down to the original MS implementation in ResourceDictionary, and registering the pack URI scheme statically doesn't help either!! Grrr.
So I need to crack on and the second option is to smash everything into App.xaml and avoid merged dictionaries.
This means fewer controls/views, and setting up a design-time dictionary in my distributable library which I guess does the job of the app.xaml which they won't have access to.
I think that makes sense.
Interesting? Tell Microsoft
It may be for Silverlight, but I'm hoping the WPF folks might be listening, or at least it might fix one platform -- I've added an 'idea' to the UserVoice site that you can vote up.
http://dotnet.uservoice.com/forums/4325-silverlight-feature-suggestions/suggestions/2307678-fix-the-mergeddictionary-perf-problem
Yes, the App.xaml thing seems to be kind of how it's 'supposed' to work, although obviously other ways are possible as you've found. The performance problem is irritating though, and the App.xaml way is also irritating because they don't resolve at design time (at least, they don't for us, if they do for you I want to know why).
However, putting them in App.xaml is the only technique I've found anything approaching an 'official' statement about.
During localhost testing of modular Prism-based Silverlight applications, the XAP modules download too fast to get a feel for the final result. This makes it difficult to see where progress, splash-screens, or other visual states, needs to be shown.
What is the best (or most standard) method for intentionally slowing down the loading of XAP modules and other content in a local development set-up?
I've been adding the occasional timer delay (via a code-based storyboard), but I would prefer something I can place under the hood (in say the Unity loader?) to add a substantial delay to all module loads and in debug builds only.
Suggestions welcomed*
*Note: I have investigated the "large file" option and it is unworkable for large projects (and fails to create XAP with really large files with out of memory error). The solution needs to be code based and preferably integrate behind the scenes to slow down module loading in a local-host environment.
****Note: To clarify, we are specifically seeking an answer compatible with the Microsoft PRISM pattern & PRISM/CAL Libraries.**
Do not add any files to your module projects. This adds unnecessary regression testing to your module since you are changing the layout of the module by extending the non-executable portion. Chances are you won't do this regression testing, and, who knows if it will cause a problem. Best to be paranoid.
Instead, come up with a Delay(int milliseconds) procedure that you pass into a callback that materializes the callback you use to retrieve the remote assembly.
In other words, decouple assembly resource acquisition from assembly resource usage. Between these two phases insert arbitrarily random amounts of wait time. I would also recommend logging the actual time it took remote users to get the assembly, and use that for future test points so that your UI Designers & QA Team have valuable information on how long users are waiting. This will allow you to cheaply mock-up the end-user's experience in your QA environment. Just make sure your log includes relevant details like the size of the assembly requested.
I posed a question on StackOverflow a few weeks ago about something related to this, and had to deal with the question you posed, so I am confident this is the right answer, born from experience, not cleverness.
You could simply add huge files (such as videos) to your module projects. It'll take longer to build such projects, but they'll also be bigger and therefore take longer to download locally. When you move to production, simply remove the huge files.
I am developing an application in WPF / .Net 3.5 that will be available for download on the internet. I am - to the best of my ability - writing bug free code, and using exceptions only where necessary. However my experience with software development has shown that users always manage to do something strange which causes an exception to be thrown in a way you could never imagined possible. I would like to gather additional information when I have to catch an unhandled exception. So far I am capturing the following:
Standard Exception fields (message, type, stacktrace etc)
OS Version
.Net version
Versions of the Applications DLLs loaded into the AppDomain
App licence information
Instrumentation of the last few commands executed by the user.
I am very concious that I do not want to capture any 'personal' information about the user as I just don't believe in that sort of thing. Hence not bothering with the username/domain/ip address (although as the exception information is delivered to a webservice I will inherently get ip information but it may be of a proxy machine).
My Question
Anyone who has released an application into the public domain (i.e. onto computers not in a controlled corporate environment) - can you suggest anything else that would be useful in tracking down the causes of errors?
Particularly I do not want to collect information that I cannot manage/code for - I.e. the amount of memory available on the PC, or type of printers attached - These things are handled by the .net framework and I shouldn't really (read: don't want to) have to alter my code to cope with the variations out there!
Thanks!
I think that should be enough. You have information about the environment, what the user was trying to do, and one of the most important debugging tools: the stack trace.
Unless you are talking about a printer management application or something, then printer information would not be worth it.
There is always that remote chance that you will encounter an error that results from a strange combination of hardware, running services, installed applications and moon phase. I don't think it is worth to rabidly collect information about the user environment just to deal with those rare errors.
Just remember to have a way that you can be contacted for bug reports, in case a user really needs his particular problem fixed, so that he can provide more information about it and help you reproduce it. Depending on your target audience you have to decide between something like a bug tracker or a simple e-mail address.