Programs. They start off in the IDE as nothing more than a blank page, then (with the blood, sweat, and toil of programmers and many sleepless nights) they turn into volumes of monospaced text, a standing testament to the dedication of programmers and the way they work. Then from the myriads of the source code and the magic of the compiler comes the executable file, the fruit of all the efforts. No one really sees the actual work that went into it: all they see is a file that runs and a program that works.
Well, that's the way it's supposed to go. But with Java and .NET, it doesn't really work that way. These frameworks/virtual-machines rely on the concept of virtual machines, compiling to Byte Code (Java) or MSIL (.NET). What looks like an executable file is actually source code being passed on to the framework for translation and execution. So your source code is never safe, and it's never really compiled.
We've been using .NET for our programs at NeoSmart Technologies for years now, and we've never really come across this as a problem, simply because our software's always been and always will be freeware. However, in recent months we've seen some of our more popular programs like EasyBCD being decompiled and its source-code stolen left and right by those that don't know any better. So we set off looking for the best obfuscation tool for the job, and found much more than what we were looking for.
We were originally looking for an obfuscation tool, but then we found {smartassembly} by Cachupa (screenshots!) is much more than that. It's a relatively name compared to the other “big names” in software obfuscation, but in our testing, it's the very best tool for the job; designed to impress, easy to use, incredibly powerful, and very intelligent (for lack of a better word) in the way it addresses and overcomes the various issues regarding the complete optimization and protection of .NET Assemblies.
We contacted Cachupa and were given a full license so we could test all of {smartassembly}'s features, and we have to say - we're very impressed.
{smartassembly} isn't just the best obfuscator we've tested, ((Compared with Pre-Emptive Software's DotFuscator, Remotesoft's Salamander, CodeVeil, XenoCode, and more)) but also an all-in-one optimization, deployment, and improvement tool; offering a range of nifty tools and features that contribute to performance enhancements, better error tracking, and most importantly of all: the best obfuscation we've come across.
The remainder of this review is broken-up into 3 sections: Optimization, Obfuscation, and Deployment. And of course, there's a Conclusion as well.
{smartassembly} & Optimization
Although we came across {smartassembly} while searching for the best obfuscation tool, we're most impressed in some of the amazing improvements to .NET assemblies in terms of optimization and performance in our test runs. Throughout this review, we've focused on getting a real-world look at things, and for this section, we just put our EasyBCD through the motions, and were duly impressed.
Memory Usage Enhancements
{smartassembly} has a couple of excellent features aimed at improving the memory usage of your .NET assemblies. There are a couple of options that can be enabled, but first, here's a before-and-after:
{smartassembly} uses several different techniques to bring down the memory usage.
We asked the developers of {smartassembly} for some of the specifics, and they told us that by default the CLR reserves a ton of memory for .NET assemblies - whether or not they request it. So {smartassembly} intelligently detects when the CPU is idle (or thereabout) and increases or decreases the amount of reserved memory for your assembly according to its requirements - "automated" GC in a sense, except that memory may or may not have ever been in use.
In that same vein, {smartassembly} (with the benefit of literally having access to your source code thanks to the way .NET is designed) marks any and all classes that don't have any detectable "child" classes inheriting from them as "sealed" thereby reducing the amount of memory and CPU used by the CLR during run-time to determine what functions should be made available to other classes and libraries.
Improved Size and CPU Requirements
One of the unique techniques used by {smartassembly} to improve the performance of .NET assemblies involves not loading all of the required dependencies
of the main application at once. This is similar to inline vs. external functions in C++, except the dependencies - once requested - are expanded into the memory-space and then have the same performance as the main application itself. Effectively, this is an intelligent compromise between performance and bloat, especially in large applications that rarely have all options activated at once. In our tests, it depends on the size (and quantity) of the external libraries and dependencies being used by the application in question, but by only loading the main assembly into the memory then dynamically decompressing the dependencies (packed with a mild compression algorithm) as one-time occurrence can end up with a huge performance benefit.
{smartassembly} also takes a heuristics approach with regards to detecting unused code and dependencies, then simply cutting them out of the compiled software. Depending on the exact make-up of your program, this has several improvements including securing as-of-yet unimplemented code from prying eyes (think of all those Easter Eggs!), decreasing the executable assembly's file size, and improving memory usage.
General Improvements
{smartassembly} has one more feature that can make a real difference: it can merge all dependencies and libraries that your application relies on directly into your own code. Then when the time comes to apply the above-mentioned improvements, all those bulky libraries that you only use a function or two from are suddenly subjected to intense filtering and pruning. If you're using some heavy UI libraries (like DevEx), this can be a real God-send. Besides the drastic improvements to the size of your application, this leads to snappier code and easier deployment - no need to muck around with dependencies in your package manager.
Obfuscation Techniques & Security in {smartassembly}
Obfuscation: it's what brought us to {smartassembly} in the first place. While {smartassembly} isn't in the market as just an obfuscation utility, we feel it really shines here. We've tried almost all other .NET Obfuscation utilities, from Remotesoft's Salamander, Pre-Emptive's DotFuscator, 9Rays, Spice, XenoCode, CodeVeil, .NET Reactor, and just about everything else in-between. There are tools like Salamander that are mainly decompiling utilities that give you "immunity" from themselves, stuff like DotFuscator which claim to have tons of advanced options that we just can't seem to locate, and others that do a decent all-around job. But nothing really stacks up like {smartassembly} in our testing.
We obfuscated EasyBCD using the maximum protection - which isn't really recommended because of certain possible incompatibilities especially for library authors - and set off to try to decompile the now-obfuscated code in dozens of decompiling suites and services.
But that's not all the protection {smartassembly} has to offer, so we didn't just stop right there. Anyone using secret strings (passwords, secret URIs, swear words for method names, etc.) should know the danger of having obfuscated code but fully-legible text - that's where the string encoding features come in. We're not exactly sure what encryption techniques/ciphers are being used by {smartassembly} to encode the passwords in the executable then decode them on-the-fly during runtime nor were we able to find out - but it seems secure enough for most purposes. We ran Syser Debugger (version 1.8) and tried to intercept a password we knew beforehand but weren't able to get to it - but we didn't lose any sleep over it either, so don't take this to the bank.
The most interesting obfuscation technique we saw used in {smartassembly} isn't so much obfuscation as it is out right deception - but when someone is trying to steal your source code (and the gallons of blood and sweat that come along with it), we doubt you'll spend any sleepless nights feeling guilty about the moral consequences of placing false metadata in your assemblies codebase. It seems that {smartassembly} is capable of adding a tiny bit of code to baffle ILDASM and any other ILDASM-dependant decompilers. Certain decompilers flagged the assembly as "non-.NET" though we're not sure if {smartassembly} actually adds any non-managed code to the final assembly or not.
Trying to Decompile EasyBCD...
Once we applied all these layers of security to EasyBCD 1.6 (no, you can't see it yet!), we set off trying to crack the security we just put in place. We tested {smartassembly}'s obfuscation techniques against the following tools:
- .NET Reactor
- RemoteSoft Salamander Decompiler
- .NET Reflector
- Spices
- Dis#
- Jungle Creature's Decompiler.NET
It passed. 2 of the tools failed to even recognize EasyBCD as a .NET assembly (while the others assured us it was). The rest showed weird combinations of non-letters, arrows, and other gibberish nonsense.
We've finally a found a tool that as-advertised, no beating around the bush or promising the sky. Event RemoteSoft's Salamander with it's "de-obfuscate(turn any obfuscated code into recompilable format)" [sic] feature failed to do its magic. We're duly impressed. Of course, any security tool worth its salt should feature some sort of strong-key signing - fully compatible with the .NET 2.0 Framework standard, of course.
Handling Unhandled Exceptions - The Right Way
One of {smartassembly}'s "more marketed" features is the unhandled exception handler. Confused? It does just what it's name implies!
Everyone has seen the annoying pop-up messages that appear when an application crashes in Windows XP+. It claims it's going to "inform Microsoft" and "let you know" when a solution is found. As developers, we've never been contacted by Microsoft (or even anyone claiming to be Microsoft) telling us our application crashed and asking us to fix it. So {smartassembly} lets you take matters into your own hands.
Instead of calling up Microsoft's own error-reporting agent and just wasting bandwidth all around, {smartassembly} can configure your application to use its own servers to report unhandled exceptions. When you purchase a license key, you're given an account on Cachupa server which accepts (any number of) exception reports and lets you see a log of all errors. And if you created a PDB debug file when you created your {smartassembly}-optimized program, you can use that to view a stack trace.
The {smartassembly}-optimized error-reporting client logs the exception with the remote server, and from your own PC you can use your {smartassembly} install to browse recent exceptions - just like an email client.
If you generated the PDB file (and no reason why you shouldn't), you can use the combination of the stack trace, detailed bug reports (together with the platform and configuration) to fix just about anything.
While we haven't encountered the need for this particular feature with EasyBCD and our other applications which generally don't have many issues, but when they do fail they fail at a low-level (leaving the user helpless!) and don't fire up exceptions, we can easily imagine circumstances under which this feature becomes absolutely essential - especially when dealing with millions of users running an uptime-critical application like a Instant Messaging client or a web server.
Final Thoughts on {smartassembly}
{smartassembly} is an amazing utility, and belongs in any serious programmer or organizations arsenal when it comes to proper development, deployment, and bug tracking/cyclic-feedback.
There are a couple of things that might throw off a newcomer to {smartassembly}, chief of which is the interface. It's innovative and easy-to-use, but to someone coming to {smartassembly} from another obfuscation suite or even straight out of the Visual Studio IDE, it's radically different.
It doesn't offer much control to the end user with regards exactly what gets obfuscated and what doesn't, which obfuscation techniques are used and where they're employed, but the end result is just great.
Unlike some of the other applications we tested, {smartassembly}-obfuscated programs couldn't be re-compiled from decompiled source, and it really did protect our intellectual investments - so far as we tested it at any rate. More importantly, the final obfuscated result run properly and without a hitch. When we obfuscated EasyBCD with XenoCode and CodeVeil, we were surprised to find out the executable file didn't even run - with XenoCode it errored out before the Windows Form could even be generated, and with CodeVeil it gave an unhandled exception right afterwards.
{smartassembly} is definitely competitively-priced. Not many other obfuscation and optimization suites are priced in the sub-$500 range, and certainly nothing that preforms this well. Yet for the casual developer, 400 USD can seem like a hefty price to pay for some peace of mind - but that's .NET for you... One more nice thing about the {smartassembly} pricing is that you can have up to 4 developers using the same license without paying a penny more - that's more than what we can say for most other software development suites out there. ((We misread this data in particular - it's actually $399 a user for up-to 4 users, then it's a discounted rate.))
Another quirk in {smartassembly} other than the lack of fine-control is the build times. While it optimizes applications pretty fast, if you opt to use the "Dependency Embedding" and "Dependency Merging" features with certain large libraries you'll find that your P4 can easily sit there producing the final assembly for around 30 minutes easy. ((In attempting to merge & embed the DXperience UI Library, {smartassembly} proved to take quite a bit of time. But for all other libraries the process was snappy and finished in well under 2 minutes. According to {smartassembly}'s developers this was a one-time quirk.)) But that's a small price to pay for the performance enhancements for your users, the peace-of-mind knowing your code (and gallons of sweat and blood) is safe from prying eyes and greedy hands. Hopefully future versions will feature improvements to the output engine's compiling speed.
All in all, we give {smartassembly} 9 stars out of 10. If only {smartassembly} had an extra bit of fine-tuning that give it the final push it needs to be a perfect 10/10.





My main complaint with obfuscators is that they kill working things. We have a large client/server architecture with .NET remoting in place to communicate between the 2. Obfuscators cannot change any of the contract calls between client/server, yet all of them crap out on this and force you do do "only metadata" obfuscation.
Additionally, we have run into bad IL issues with Spices, DotFuscator, Salamander, and XenoCode. With Xenocode, the developers gave us some hotfixes that eventually solved the problem.
But I wonder...is all this really worth it? What are we trying to protect? It seems to me the only thing we should be worried about protecting is connection strings, passwords, encryption keys, or activation/time bomb related code.
Yes, it's true that someone could reflect on the IL, generate functionally equivalent, although comment-less code, and build their own product from that. But honestly, who's going to do that? The software would be unmaintainable -- machine generated, no comments. Businesses would never in their right mind risk a lawsuit by stealing an entire codebase and calling it their own.
Hi Judah,
Unfortunately, your perceptions of people are rather kind! We've had this done to us with our programs by other "companies" who don't mind the extra drudge work so long as there is no thinking and innovating involved.
I know exactly the problems you are talking about - the obfuscators just break the application. Unhandled exceptions, no sync, etc. That's exactly what we experienced with both Spices and XenoCode. {smartassembly} worked for us though.
I know how you feel. We shouldn't have to protect our source code. It's ours, the program and the source alike. No one should try to steal it, it's too obvious. But unfortunately, the world isn't filled with only good people. Give {smartassembly} a try, it's a free trial download - I believe it may work well for you.
Hm, seems SA is only for single assemblies. How about several assemblies, cross-obfuscation, tamper-proofing solutions (very urgent feature for us)? I love Spices.Obfuscator with Anonymizer and antiTampering (these thhigs really work for us), cross-obfuscation (I've 15 assemblies in project), that tool is really smarter than smart-assembly and offer real solution to protect big things.
2 Judah: don't afraid to contact to vendors to solve your problem. I had runned into some problems with spices obfuscator and received some useful recommendations relating to my assemblies protection that solved all my problems.
SA does have an option to obfuscate additional assemblies, at least in the version we tested.
Spices ruined our app as well, it would hang before the Window was even created. I don't have time to contact commercial vendors whose apps don't work as advertised, that's why I'm happy we chose {smartassembly} where we didn't need to: it just worked.
Hm, but I've briefly compared SA with Spices.Obfuscator - assembly after SA is still easy to decompile (ILDASM, Spices.Decompiler, Reflector), many of members iare leaved from obfuscation (some internal and private members not obfuscated, these are usual classes don't excluded from obfuscation in single exe). Anyone can disassemble this app, make changes and assemble with ILASM with my own code - in other words, make workable copy of protected program, program is still has roundtrip vulnerabilty. You can be happy with SA, you can have no time to contact commercial vendors to take recommendations from experts/professional to REALLY protect your code, until hackers start to distribute your code. In other words - you happy because SA doesn't ruined your app, isn't it?
I've tried a lot of obfuscators - dotfuscator, xenocode, SA, salamander, Spices.Obfuscator, native protection - Codeveil. They have their own advantages and disadvantages. It's need to understand results of obfuscation, reasons of incorrect work of program after obfuscation (the main problem - serialization/reflection), what members should be obfuscated and excluded from obfuscaton, analyze results of obfuscation to understand real protection.
BTW, I've tried EasyBCD - on startup this program shows AV exception, but continue to work, and after some clicks - View Settings (shows AV), Configure Boot - shows SA exception and crashes. Are you sure that SA doesn't ruined your app?
Unfortunately, all obfuscation companies are loosing some serious customers, simply because they do not release a simple document of guidelines for writing code that works with obfuscation. I had to go through all the pain of changing my code to make it obfuscatable. I wish i could have some time to write these guidelines myself one day. I know people who already shifted from .NET to other technologies like delphi and c++ just because of the missing the right connection between .NET and obfuscation.
Well, in my experience most of the small obfuscation companies (basically all but Preemptive and Salamander) will gladly allow you to send a program that won't obfuscate, and send you a patched version of their product that works with it.
As a sidenote: in {smartassembly} 2.2, the problem we experienced with 30-minute obfuscation times was fixed.
I'm a customer of SA....and i think that SA is a good solution...in terms of moneyprotection... ok someone may say not the most unexploitable.... but i think that his protection is enough for many software companies that don't have a world-wide distribution, but a simple and more realistic pool of customers. many of us don't have hackes that try to steal our super-formulas, in the worst case we can have people that try to duplicate the installation on another machine...without even know what they are doing...and for the "little-selfmade-pro-hacker-wannabe" that our software may ancounter SA seems really enough...(considering his price remember)
The thing that SA REALLY NEED is cross-obfuscation!!!!! all the other things can go fine... Projects are very large and it is impossible to embed all in a single exe....what about upgrades???? what about maintenance in general??? if i want to change a single function in a library i need to REBUILD all the solution ?????
SA is a good choice but REALLY cross-obfuscation is a thing that we can no longer ignore when writing reviews on obfuscators!!!!! reviews are for all not only for personal-use, single-little-exe's programmers....the most part of customers of an obfuscator are software companies not peoples in their house!!!
I fully agree with you. At the time when this article was written, we neglected to try {smartassembly} on anything larger than a single exe with multiple library dependencies.
However, we've recently tried to obfuscate/optimize a much larger project with multiple executable files and share libraries between them all, and it was not a fun experience.
If you obfuscate a library, it breaks the dependencies in the exe files. For each file you need optimized, you need a seperate project (one file is obfuscated per project).
Hopefully future versions of {smartassembly} will feature improvements in the cross-obfuscation realm........
I had many issues implementing obfuscation. The main problem was that obfuscation breaks your code. As a result I've tried .NET code protection tools, CliSecure in particular worked very well for me. It's very easy to use, just feed it with your assemblies and run it, and it doesn't require any modifications or adjustements to your code like most obfuscation tool required.
Does it support cross-compilation? Because that's the big thing that {smartassembly} is missing and no one else seems to do right.
The main issue with obfuscation tools is that they often break your code. I had many issues with obfuscation and therefore decided to evaluate some .NET code protection tools. CliSecure, in particulr, worked very well for me. It's very easy to use, just feed it with assemblies and let it secure your code. It doesn't require any modification or adjustements like most obfuscation tools require.
Dan.
CliSecure is not an obfuscator, it's a code protection tool. It leaves class & method names intact but at the same time secures your .NET code not allowing it to be reflected by standard .NET tools such as reflector.
I just took a look at it, and, sorry, it's terrible.
Can you be more specific?
We actually make programs for a hacking community, and while I must say we're always fighting to keep on top of others, people are always trying to decompile our stuff. Previously, we have used Xenocode, Xheo and a few others. They all failed us. Not only faliled bad, but really faild. Xenocode could hardly produce an assembly that works, Xheo was easily decompiled.
Smartassembly was a god send. This peice of software is the absoulte best obfuscuator out there. We do have issues with MAX protection, so we tone it down slightly, and everything is amazingly perfect. The best feature alone is us not having to tweek the obfuscuation every build. The first time we set it up and got it working has been the only time we've touched it.
Moreover, once you setup one project, you learn everything really fast and setting up others is easy as pie. Also, since this review, they added alot of features. You can also tell SA to use max protection on this class but not that class. It is overall, the best working product out there.
No decompilers have been able to crack it. We've yet to see "Cracked" versions of our applications out there since SA, which cause revenue to triple.
Only downside is they charge quite a bit for smalltime developers to be able to keep using their webservice for error tracking, however this code isn't that hard to replicate, so it's not that bad.
5/5 stars.
Dave, do you use any other tools to protect your software except SA?
I am planing to launch a marketing related software product in C#. I know that there is a small cracking community and I want to add some protection to it. They failed to crack Themida but I had a look at it and it seems too troublesome for the end user. Many AV programs recognize it as a virus.
Mark, what's your program look like? A single executable? Many DLL files? Some of them not yours?
As a user of SmartAssembly for the last year and a half, I have to agree with your article... It's a really great product, and it works as advertised. The only thing I take exception to is this statement:
> It doesn't offer much control to the end user with regards exactly what gets obfuscated and what doesn't, which obfuscation techniques are used and where they're employed, but the end result is just great.
Actually, you can drill into the advanced dialogs for code pruning, obfuscation, etc and specifically tag classes or exclude your classes within an assembly. I rarely do this however, and choose instead to use the SmartAssembly.Attributes to decorate my classes/methods when special treatment is required.
For example, I've noticed that if you are a fan of Reflection in your code, and you obfuscate the code, you can kiss your reflective invoke's goodbye. I usually decorate any methods called via reflection as [DoNotPrune, DoNotObfuscate], which works perfectly. Also, you may need to do some custom decoration if you are using the Windows Presentation Foundation (WPF) and XAML. Another interesting note is that BAML (the compiled version of XAML) is not obfuscated...
Anyway, great article, and it's a great product...
:-) Geo...
Well said, finally a good report on this stuff