When I was investigating this, one option that I thought was very interesting was to use licensing, rather than obfuscation. I'm guessing the Microfour medical product takes this approach, as it is very specialized and with very known customers. Wouldn't work for me and likely not for you, but I thought it was an interesting approach.



Thinstall is very nice, just too expensive for the budget I have to work with. If it is in your budget, I think it looks very nice.



The thing that blows me away is how to keep anything private within the application, like connection strings. In my case, the users don't have any idea where the database is, so the connection information had to be within the app some how (well, there were other options, like a secured web service, but that was way beyond what I could do initially). So string encryption is really important. Now I'm using Enterprise Server, so the connection strings aren't on the client anymore...that is very nice.

Oh, I remember Thinstall now...waaay out of my budget

Greg,

I found a FAQ about updating a .NET app with “Thinstall” and you can update the app as you do by just updating the needed DLL only.

https://thinstall.com/help/index.php?applicationupdates.htm

So I guess updating the app is not an issue...

But protecting my app from easily getting pirated is my biggest concern right now.

JC

Hi Greg,

Believe me I’m still bewildered that .Net apps can be so easily reversed engineered; you’d think that this alone would be a deterrent for using .NET to make commercial apps or that MS would have made something to make it more secure. Anyway from what I have read Obfuscation is more of a hassle then a real deterrent for hackers or any developer for that matter to reverse engineer a .Net app. So what is the best way to stop this from happening?

Looked at Xenocode and it looks like Thinstall with some differences like its licensing model although I like some of the extras in Thinstall like its licensing API and its licensing manager that takes care of the licensing development hassle.

On the deployment side you have a point but you could have two options one with the .Net framework included and one without it if the client already has the framework installed which could be the majority of the cases or you could always pre install the framework and just keep the app in its protected virtualized EXE.

On the issue of updating the app I was considering Byte-Level Differencing like “Pocket Soft” or “Patch Factory” thus only downloading a minimal update if the whole app was just too big.

In playing with some “Thinstall” demos like firefox (20Mb) and OpenOffice (100Mb) I was impressed with how quick the app started with NO INSTALL…I like that!

Plus virtualization gives me other options like putting the app in a USB drive or CD and have it run from there…

At this point I’m just trying to learn VB.Net development and make a running app that won’t get pirated much less thinking about packaging the application for deployment and everything that entails.

So anything I can use to cut down on my development process is welcomed.

JC

Ah, I remember this realization. Cried like a baby for two days.



I ended up using Xenocode's PostBuild. They also can do virtualization and they have a code profiler (which I haven't used yet). I actually can't remember why I chose it over others, except that I couldn't get Dotfuscate to work. It works well now. I'm actually using it to encrypt all the strings in the app and haven't noticed any performance hit. It takes a while to figure out what you can and can't obfuscate, but eventually things calmed down.



I haven't used virtualization yet because while you simplify deployment, you also make it more complicated if you have a somewhat sophisticated app. I.e. By putting everything into one gigantic exe, you have now made the requirement that EVERY change to the application requires this gigantic Exe (of course, if it isn't gigantic, then this doesn't apply...of course, since the .NET stuff is included, this will likely be larger rather than smaller). By leaving the app as separate dlls, you at least have the possibility to update just one dll. My app is about 20mb, in an exe and 9 dlls. I have a base dll, a businessobjects dll, a UI dll, and the rest are in support of modules of the program. Often an update will be just 1 or 2 dlls. Since all of my users are remote (OK, I think 1 is inside the network), smaller updates is very important for my app.



This does required that you understand how .net handles assembly references. This is why SF is on 1.6.1, but I believe the dlls all say 1.6.0. By doing this they don't break anything.



Anyway, just some food for thought. Good luck on your quest!



Greg

The Other Former Access User

Hi guys,

 

In my painful transition to .NET from MS Access I once again find myself looking at another tool that I seem to need in this never ending tool list to make a viable commercial product in .NET.

 

In reading the daily posts and just about any post to ease my painful learning curve I was confounded to find out that .NET assemblies are easily reversed engineered and thus the need for an Obfuscating tool.

 

While further researching and reading bewildered as to the fact that an obfuscator is needed and that this alone does not stop reverse engineering I found out about a couple of tools that seem to achieve true protection against reverse engineering and wanted to know if anyone has used “Thinstall’s Virtualization Suite” or “Remotesoft’s Salamander .Net Protector”?

 

I think that SF developers use Dotfuscator so you guys may have more info on these alternatives and why you guys don’t seem to use them…

 

Not to sound like a sales pitch for this product but I’m impressed with “Thinstall’s Virtualization Suite” since it seems to be the perfect tool for several reasons beyond an alternative to an obfuscating tool and really protecting against reverse engineering. For one it also seems to resolves the need for a deployment tool thus eliminating an installation process and all the issues this brings like admin and restricted install issues to deal with (good for the client and me) and also eliminates the need to install the .Net framework on the client and the issues this entails since its all in the resulting executable thus easing the deployment issue, no need to create a licensing scheme since it has its own licensing API, runs on its own protected sanbox so it protects the client even further from potential blowouts (as a .Net newbie this is very possible), and also has a licensing manager to help you track your licenses. So besides the cost (which is relative) can anyone tell me if this tool sounds like a fallacy or is this tool really worth it’s seemingly weight in gold?

 

Thanks in advance for any info on these products…

 

JC