By Jc Martinez - 12/10/2007
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
|
By Greg McGuffey - 12/10/2007
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 
|
By Jc Martinez - 12/10/2007
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
|
By Jc Martinez - 12/10/2007
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
|
By Greg McGuffey - 12/10/2007
Oh, I remember Thinstall now...waaay out of my budget
|
By Greg McGuffey - 12/10/2007
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.
|
By Trent L. Taylor - 12/11/2007
Jc, you mentioned that .NET is easily reversible, but really so has most any other platform in the past as well. We had some tools that would reverse an VFP EXE into source code the same way that many of the .NET reflectors will do. Also, you mentioned that Dotfuscator can be reversed. This is true depending upon the settings that you use. If you just have the variables converted into an alphanumberic character then this type of thing is very easy to break down. But if you use unicode unreadable characters and really tighten down the hatches, the reversal of an assebmly is pretty much not going to happen. Let me put it this way, if someone wants to dedicate their profession to stealing your product anyway, there is a good chance that it is going to happen. Dotfuscator is a very good tool and we have been very pleased with it. Installations and deployment are a whole different story. I do not know what your end-user may be, but in our medical product, we have a very sophisticated installation that has a phenominal number of checks and scans trying to prevent the end-user from themselves as best as possible. I can tell you one thing, that when you rely to heavily on a platform that leans away from the grain it is not a matter of if, but when how great the carnage will be when the train goes off of the track. That is why we try to take a more realistic approach when it comes to distribution. One final thought on the obfuscation...lets say that you left your source code totall open, the odds that someone could piece your application with a number of tools is next to impossible anyway, so by taking a strong tool and placing obfuscation on top of it anyway practically seals the deal. We have a very large medical application and a number of competitors that I am sure would love to have our source...but we feel more than comfortable releasing our product with Dotfuscator. Just my two cents
|
By Jc Martinez - 12/11/2007
Greg,Yep “thinstall” is a little expensive and not necessarily within my budget either but the way I look at it is that if it protects my app from reverse engineering, eliminates deployment issues, helps eliminate another facet of my development with their licensing management API then the cost is a relative term especially since the cost of Dotfuscator, InstallAware, and the time to develop and implement my licensing and deployment scheme adds up and that’s doesn’t include deployment support issues that I will have to deal with…. I’m not quite sure what you meant by licensing vs. obfuscation but the reason for protecting the code in my app is to protect my licensing scheme. Currently my MS Access app uses 2 licensing schemes to avoid pirating the app thus the extra appeal for “Thinstall”… less work on my part. Sounds like I’m trying to sell myself into “thinstall” The connection string thing will be another bridge to cross when the time comes since currently my App is a Client/Server but hopefully it will become a SaaS model and the connection will be stated. I’ve seen you post on this subject and I’m sure I’ll revisit it again. I’m counting on the encryption API from SF to handle storing the connection data encrypted in an encrypted file or encrypted and stored in the registry somewhere…don’t know yet since this is the least of my problems and I don’t think this will be a problem when the time comes…I hope!  Trent, Thanks for the heads up on your confidence and reliance of Dotfuscator to protect your intellectual property this really helps to ease my concerns and your two cents have value and since their community edition is part of VS then I’ll have a chance to play with it. Maybe between my paranoia and several internet post that claimed how easy it is to reverse engineer an obfuscated .Net app did not help. Like I said my biggest concern is protecting the licensing scheme to avoid my app being pirated. I understand that any app can be pirated and in reality you only have to be worried when you reach the big leagues like Microfour Deployment is a big concern and I’m avoiding even thinking about it until the time comes and then anything that can ease the fear and the pain will be considered thus my current interest in the virtualization concept like “Thinstall”.  Like I said before, my app is currently a client/server model thus the deployment, licensing and pirating concern but eventually if all goes well it will be a SaaS model with the help from SF’s ES and I’m sure that will have its own set of issues and concern. Unfortunately for now this is a one man shop and so far the learning curve and all the facets of transferring my MS App to a commercially viable .Net App is daunting and sure to take its toll so anything that cuts my learning curve and development time and cost like SF or "thinstall" is welcomed. Thanks again guys…
|
By Greg McGuffey - 12/12/2007
JC,
Here is a How-to-select guide to .net obfucators, with the link pointing to the piece concerned with licenses:
http://www.howtoselectguides.com/dotnet/obfuscators/#section-related-cats
This might be of help otherwise too, if nothing else, there are some somewhat objective reviews of a few products.
|
By Jc Martinez - 12/12/2007
Thanks Greg, great resource… I’ve seen some of your early post when you started down the same road from MS Access to .Net … I now feel your pain and then some Too much to take in in a short time I guess...
|
By Jc Martinez - 12/12/2007
By the way here is a book that may help those going through the same painful transition from MS Access to .Net.: Programming Microsoft Visual Basic .NET for Microsoft Access Databases. http://www.amazon.com/gp/product/0735618194
|
By Greg McGuffey - 12/12/2007
Nice find. In my case it wouldn't have been very helpful, as I was mostly using SQL Server databases with Access front ends. However, for anyone who is using Access databases (as opposed to the UI), this looks like a really good book. Thanks!
And yes, the pain in the beginning was quite extreme (about a year ago now). I can't really imagine going back anymore and don't miss Access at all. I believe Nietzsche said "That which does not kill us makes us stronger". I'm a lot 'stronger' than I was a year ago!
|
By Jc Martinez - 12/13/2007
My MS Access Apps are also just front ends to a SQL database.Here is another book that can help someone in the transition from jet to SQL: From Access to SQL Server
http://www.amazon.com/Access-SQL-Server-Russell-Sinclair/dp/1893115240/ With “Programming Microsoft Visual Basic .NET for Microsoft Access Databases” and “From Access to SQL Server” and SF’s framework one can definitely break away from the MS Access playpen  and play with the big boys…
|
By Edhy Rijo - 2/6/2009
Greg McGuffey (12/10/2007)
I ended up using Xenocode's PostBuild. They also can do virtualization and they have a code profiler (which I haven't used yet).Hi Greg, It is time for me to get into the obfuscator stuff, I noticed you are using Xenocode's PostBuild, or where using it I have Postbuild 2007, but I am not been able to make it work for me. Could it be possible for you to list the steps needed to suscesfully protect an SF project with Postbuild? Thanks!
|
By Greg McGuffey - 2/6/2009
Edhy,
I was using PostBuild 2007Pro also. A while ago (many months) we stopped using it. In our case, there wasn't a compelling need to use it, verses the hassle of getting it right. However, here are some things I found.
First, be careful what you obfuscate! The important thing here is to know what SF serializes as text. It is pretty unsafe to obfuscate any BO or any enum as these are used to fill listbox/comboboxes and they serialize the names as text. Thus if you obfuscate the name or fill methods of the BO, it breaks.
I also was doing this with ClickOnce, so it was more complicated. I'm hoping you don't have that pain.
I believe the process I used was:
1. build a release version
2. Select the files to obfuscate
3. I used aggressive I think
4. I would then deselect BOs and Enums that were likely to end up serialized.
5. I seem to remember something about needing to allow IDLASM tools, but that was probably for ClickOnce.
6. Set flow control settings to 4 I think
7. I typically would encrypt strings also. I was encrypting any sql strings embedded within the app. If I was really concerned, I'd just use sprocs for all access to db though and have no sql embedded. This was a pain as you'd basically have to set this up every single time you do the build (i.e. your saved setting would likely need to be updated).
8. I don't remember much of the other options, except I did multiple assemblies (for ClickOnce).
I'd also recommend looking into using attributes to control the obfuscation process. I think you mark types that aren't obfuscated. This allows better control and simplifies the obfuscation process.
I would recommend that when you are coding to NEVER use a string to indicate a type. I.e. you'd never use something like MyBOType = "MyProject.BusinessObject.MyBO". Instead, you'd use MyBOType = GetType(MyProject.BusinessObject.MyBO).FullName (or whatever the property is that returns the fully qualified name of a type).
I made a request way back that SF consider changing how they serialize BO names and enum names because of this. I'd be nice if they stopped serializing the names as strings and instead serialized them as the GetType().FullName instead. Of course, this might not be possible. But is would sure be nice if it was (and not just for obfuscation, but for normal refactoring).
Let me know if you have more questions and I'll try to answer them... 
|
By Edhy Rijo - 2/6/2009
Thanks Greg, I will give this thing a try to see how it comes out. P.S. I miss RexFox
|
|