Thanks Greg, I will give this thing a try to see how it comes out.

P.S.

I miss RexFox

Edhy Rijo

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...

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!

Edhy Rijo

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…

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 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

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...

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.

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…

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