In addition to merging user assemblies, can you include system assemblies and even the runtime itself? I've always wanted to distribute C# apps as a single executable file that didn't depend on any runtime at all. I think there are some products out there that can do this, but last I checked none of them seemed very good.
It's certainly possible, although I'm not certain of the legalities there. I'll look into it once I get merging of assemblies working. Combined with the dead code analysis I'm working on, it may end up working out pretty well. Thanks for the suggestion.
Won't this break XML serialzation? At least, several years ago, XML serialization used to go compile code (call csc on files) at runtime or something crazy like that. We were never able to make our dynamically loaded assemblies work well with XML serialization. I tried a commercial product a while later and it too had that issue.
Kudos on LMZA - I wish Silverlight would have used that instead of just zip. It'd make a pretty big impact on size.
Nope, this works fine with reflection generally. That sort of introspection, however, will be incompatible with the obfuscation done in the future. I aim to detect where it happens, and at least say "hey, this flag is being ignored since it's going to break things".
As for LZMA, it has a huge impact for sure, but until assembly merging and dead code analysis are in place, the impact on Silverlight assemblies is going to be pretty slim.
Dotpack does wonders on standalone binaries as it stands (compresses NVidia FX Composer to just over 20% of its original size, for instance), but most Silverlight assemblies only get a 10-20% decrease right now. I'm looking forward to getting the Silverlight side stable and as high quality as the standalone side.
Redgate (owner of SmartAssembly) and Remotesoft in general. Yes. Their tools don't work worth a damn and they sell way, way too many licenses. I'd love to take a large chunk out of their market.
In fairness to Redgate, their tools have always worked for me. SmartAssembly worked pretty well when I used it too. They're just ridiculously expensive. So I would love to see some good competition for them.
They 'work', but they don't protect your code in any way. Beyond removing names from your code, they really don't do anything useful. It really seems to me like the people working on these obfuscators have never looked at unmanaged code obfuscators used in the wild -- with the amount of data available with .NET assemblies, you can do a whole, whole lot.
That's true, but at a $500 price point, you're also reducing your market substantially due to price elasticity. Be sure to lower the price quickly if you feel like you're not getting traction.
Sorry, but bashing your competition doesn't make you look "cool."
I reviewed {smartassembly} back in 2007 (http://neosmart.net/blog/2007/smartassembly/) and till now it remains hands-down the best obfuscation and post-release-processing tool for .NET applications.
For larger projects the obfuscation can break the product. It's tedious work, but you can manually exclude functions from the obfuscation procedure until you can find out where things went wrong.
I'm not terribly concerned about looking "cool", I'm simply stating what everyone who's reverse-engineered such obfuscated assemblies knows. These tools simply don't protect your code at all. I think it's a travesty that these tools sell as well as they do while doing nothing to hinder reverse-engineering.
Edit: For the record, I performed quite a bit of reverse-engineering on Magic: The Gathering Online, which uses SmartAssembly for obfuscation. Despite it being heavily obfuscated, an hour with Mono.Cecil got me a clean binary with placeholder names. That is simply unacceptable.
A binary packer such as Dotpack, UPX, or PEtite compresses an executable and adds an unpacker to the beginning of it. In this way, you have a self-standing application that is a fraction of its original size. What sets Dotpack apart from the popular packing tools is that it works on .NET binaries rather than general Windows/Linux/Mac binaries.
If you'd like to take a look at a packed binary, Dotpack itself is packed. Feel free to peek around at it. For what it's worth, there's little to no protection as it stands; the unpacker stubs are obfuscated for space reasons, but the actual assembly is unchanged at this time. Obfuscation will be coming soon, although I'm unsure of how far I'm going to take it for the release version.
UPX and other binary packers out there don't support .NET binaries in any way. There's only one other .NET packer that I'm aware of, and it seems to be dead (the only traces of it are on shady shareware sites) and quite old.
Because if they do similar things, they must use the same code? Better tell Microsoft that Apple's ripping them off. I mean, they're both x86-based graphical operating systems, right?
Don't accuse people without evidence, especially long-standing members of the community like Daeken, of stealing. The fact that you spammed Daeken's blog with comments promoting exepack (forcing him to disable comments) doesn't help either.
Then again, some of your comments were pure gold. For example:
"Your product" name is DotPack and open source ExePack ;
Pack part of the name the same . coincidence ? To much coincidence in this case .
(FYI, I've worked on a portion of DotPack's code, specifically optimizing the LZMA unpacker module, and while that portion was not original code, the original source was a public domain LZMA unpacker. We ended up rewriting practically the whole thing anyways because of how badly it was written. The end result was something like half the size of the original.)
The extent of this accusation stems from the fact that both names contain 'Pack', much like every other packer on the planet. One of his many trollish comments on my blog was this:
"Your product" name is DotPack and open source ExePack ;
Pack part of the name the same . coincidence ?
To much coincidence in this case .
NM Moscow, Russia
At least a dozen HN readers can attest to the fact that I've been working heavily on this, and two have seen the source first-hand and can confirm that it's original.
It's offensive to say the least to have such an accusation come up on your own blog, but eh, such is the internet.
The idea is one that's been around for many decades and implemented thousands of times over the years. It's not mine, and it's certainly not from Exepack. People may buy it because it works very well and is improving by the day, and if they don't, that's ok -- competition is good. But accusing me repeatedly of stealing code when the only thing our projects have in common is that we're .NET packers with names ending in 'pack' is just downright offensive.
Don't worry about repeated acquisitions. I know it is hard to filter unjustified negatives but sometimes, like this time around, you simply need to ignore.
