CODEWITHSUNDEEP
.netencryptionobfuscation.net-assembly
palm snow
palm snow

Reputation: 2392

obfuscation vs unmanaged assembly

I have recently attended a presentation where guy showed that .NET obfuscated code can be cracked. He suggested that a better way to get real security is by either encrypt an obfuscated assembly or even better have your intellectual property in an unmanaged assembly. The obvious drawback going with unmanaged assembly path is that assemly will be platform specific. Are there any advantages or disadvantages you see with above two approaches.

Upvotes: 2

Views: 866

Answers (4)

Hoi
Hoi

Reputation: 1

Compared to machine code, .NET code is much more structured and less flexible to transform. So one technical challenge to protecting .NET code is to sufficiently scramble the code (using obfuscation, encryption, or other techniques) yet not break its verifiability imposed by the .NET runtime.

That said, there are still a number of things you could do to secure .NET code (besides the techniques already mentioned):

  • Apply anti-disassembly tricks that make the code hard to disassemble correctly
  • Encrypt string literals used in the code
  • Rename function and data symbols to meaningless names
  • Intentionally damage some of the code at the file level, but repair it only at runtime
  • Checksum important logic in order to foil tampering
  • Apply protection in layers (e.g., checksum and repair obfuscated code and other protection logic) so it's harder to defeat the protection as a whole

Of course, doing these by hand is difficult and error-prone. But there're commercial, professional-grade tools out there that you can use to automate such protection.

Upvotes: 0

HTTP 410
HTTP 410

Reputation: 17608

There are advantage and disadvantages to both models. But these will primarily depend on your specific threat model, which is where I suggest you start. Which groups of people present security threats to your product, and what are those threats?

In general, the advantage of using managed code is speed to market, but it's more susceptible to certain attacks and IP theft. The advantage of using native code is that it's less susceptible to certain attacks, but the speed to market is slower. These are very generic advantages and disadvantages that should be tuned based on your threat model.

EDIT to answer your comment. If you do have IP that you need to protect, I would (in the generic case) go for a native code executable rather than an encrypted obfuscated assembly. Native code is harder to crack open than encrypted obfuscated managed code, and the additional complications of encryption and obfuscation will add a significant amount of design and testing to your product.

EDITED again to point out that there's another option: you can use a packer like MPress. This doesn't have the performance and complexity implications of obfuscation and/or encryption, but still provides reasonable protection against IP theft by non-professional crackers. If you look at a packed .NET assembly with Reflector, you just see a single Main call.

Upvotes: 3

Sean U
Sean U

Reputation: 6850

A third option is encrypting your executables. The option I'm most familiar with puts the encrypted code inside a wrapper that can only decrypt it if a dongle is present.

Dongles and encryption are theoretically stronger, since one can't even begin to poke around at the program until the executable is decrypted. That said, it has to be decrypted every time the program runs, so all you really have to do is run the program and pull the clear code from memory. But that option won't be available to someone who doesn't have access to one of your dongles, so that gives you some opportunity to exercise judgement about who you're willing to ship a dongle to.

The downside is cost support hassle. Software can't be delivered electronically, since there's now a piece of physical hardware that the customer needs. Some countries might have rules about importing or exporting dongles, since they're cryptographic devices. And some hypervisor systems don't support USB pass-through and, while some dongle manufacturers still offer parallel port dongles, computer hardware doesn't necessarily come with parallel ports nowadays. You might find yourself in a tight spot if the customer needs to run your software on a virtual server. And they're surprisingly easy to break. Your customers will break them.

Upvotes: 1

David M
David M

Reputation: 72870

What is your motivation for this level of code security?

If your code really is sufficiently valuable IP in its own right, then perhaps you should consider not distributing it at all but hiding it behind some sort of SaaS offering. Obfuscation is exactly what it says, it is not encryption, and since the runtime has to be able to read your code to run it, it has inevitably to be readable. Even an unmanaged DLL can be decompiled, if only to assembler code, so your IP isn't wholly safe there.

Incidentally, the obvious drawback to unmanaged code is not what you say, IMHO, but everything you sacrifice in moving from a managed to an unmanaged language.

Upvotes: 4

Related Questions