{"id":419,"date":"2007-05-01T19:59:07","date_gmt":"2007-05-01T19:59:07","guid":{"rendered":"http:\/\/neosmart.net\/blog\/2007\/smartassembly\/"},"modified":"2013-08-26T18:16:07","modified_gmt":"2013-08-26T23:16:07","slug":"smartassembly","status":"publish","type":"post","link":"https:\/\/neosmart.net\/blog\/smartassembly\/","title":{"rendered":"{smartassembly} reviewed"},"content":{"rendered":"


\n \n<\/p>\n

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.\n<\/p>\n

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<\/em> 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.\n<\/p>\n

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<\/a> 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.\n<\/p>\n

<\/p>\n

We were originally looking for an obfuscation tool, but then we found {smartassembly}<\/a> by Cachupa (screenshots!<\/a>) is much more than that. It’s a relatively name compared to the other \u201cbig names\u201d 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.\n<\/p>\n

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.\n<\/p>\n

{smartassembly} isn’t just the best obfuscator we’ve tested,1<\/a><\/sup> 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.\n<\/p>\n

The remainder of this review is broken-up into 3 sections: Optimization<\/strong><\/a>, Obfuscation<\/strong><\/a>, and Deployment<\/strong><\/a>. And of course, there’s a Conclusion<\/strong><\/a> as well.\n<\/p>\n

<\/p>\n

{smartassembly} & Optimization
\n<\/h3>\n

<\/strong>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<\/a> through the motions, and were duly impressed.\n<\/p>\n

Memory Usage Enhancements<\/strong>\n<\/p>\n

{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:\n<\/p>\n

<\/a>            <\/a>\n<\/p>\n

{smartassembly} uses several different techniques to bring down the memory usage.\n<\/p>\n

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<\/a> for your assembly according to its requirements – “automated” GC in a sense, except that memory may or may not have ever been in use.
\n \n<\/p>\n<\/p>\n

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.\n<\/p>\n

Improved Size and CPU Requirements<\/strong>
\n \n<\/p>\n

One of the unique techniques used by {smartassembly} to improve the performance of .NET assemblies involves not loading all of the required dependencies
\n
<\/a>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.\n<\/p>\n

{smartassembly} also takes a heuristics approach with regards to detecting unused code and dependencies, then simply cutting them out of the compiled software<\/a>. 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.
\n \n<\/p>\n<\/p>\n

General Improvements<\/strong>\n<\/p>\n

{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.\n<\/p>\n

<\/p>\n

Obfuscation Techniques & Security in {smartassembly}
\n<\/h3>\n

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.\n<\/p>\n

We obfuscated EasyBCD using the maximum protection<\/a> – 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.\n<\/p>\n

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<\/a> 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.\n<\/p>\n

The most interesting obfuscation technique we saw used in {smartassembly} isn’t so much obfuscation<\/em> as it is out right deception<\/em> – 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<\/a> 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.\n<\/p>\n

Trying to Decompile EasyBCD…<\/strong>\n<\/p>\n

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:\n<\/p>\n