obfuscator

Microsoft's Software Licensing and Protection and Dotfuscator

At Microsoft’s Worldwide Partner Conference, Microsoft announced their new Software License and Protection Services (SLP Services). SLP Services includes powerful licensing, activation and code protection services (that complement obfuscation). The new offering allows application developers a means to effectively protect and monetize their applications and we are very excited about it.

So excited, that in fact we integrated our protection solution (Dotfuscator) and our application analytics solutions (SO-signal) with Microsoft’s Licensing and Protection Services. The integrated solution is called Dotfuscator Gold and will be generally available with the launch of Microsoft SLP Services. The integrated solution may be used entirely within Visual Studio and requires minimal coding to get laywered code protection, application analytics, and licensing and activation services.

In the meantime, if you would like to try an evaluation of Dotfuscator Gold which includes Microsoft’s Licensing and Protection Services please contact PreEmptive Solutions.

The fourth dimension of enterprise obfuscation is tamper notification

If you invest in fire prevention – don’t you also want fire detection? This begs the question “if an organization cares enough to invest time and resources into reverse engineering prevention, wouldn’t that same organization benefit from reverse engineering detection?”

Those who lose sight of the fact that the organizing principle behind obfuscation is the requirement to manage risk also undervalue the importance of the obfuscation process. The result is a one dimensional view of obfuscation as a finite set of technology limited to the transformation of application binaries. However, the emergence of Service Oriented Architecture (SOA) and Software as a Service (SaaS) combined with a growing recognition that the most effective IT controls must bridge the development lifecycle and operations management has made it possible, for the first time, to prevent reverse engineering and to detect tampering when it should occur.

Attend Free Webinar on Enterprise Risk Management and Obfuscation

Sign up for the Event: Obfuscation, IT Governance and Enterprise Risk Management  

Date and Time: Monday, April 24, 2006 1:00 pm
Eastern Daylight Time (GMT -04:00, New York)

Duration: 30 minutes

Description: Attendees will leave with a clear understanding of:
-the role of obfuscation as an effective control for application security, access control, IP protection in the context of broader IT governance and enterprise risk management frameworks.
-a basis to assess the cost/benefit of including obfuscation as a component of your ongoing governance, risk and compliance programs.

For more general info on see: Java and .NET obfuscation and IP Protection

Register for a free Webinar

Register for a webinar on the "Essential Characteristics of an Effective Obfuscation Process".

https://preemptive.webex.com/mw0202l/mywebex/default.do?siteurl=preemptive

Date and Time:     Monday, March 27, 2006 1:00 pm
Eastern Standard Time (GMT -05:00, New York) Change time zone
Panelist(s) Info:     Sebastian Holst and Gabriel Torok
Duration:     30 minutes
Description:     Attendees will leave with a clear understanding of:

    * Benefits and potential consequences inherent in the variety of obfuscation transformations available today.
    * Development lifecycle opportunities and process requirements for integrating obfuscation with special attention given to continuous integration, distributed development, quality and manufacturing and patch management.

Obfuscation: Algorithm or Process?

Is Obfuscation an algorithm or process? Just like encryption, obfuscation should not be viewed in terms of just an algorithm. The Encryption process requires key management, decryption, etc. Similarly, the obfuscation process should address issues such as debugging, patch management, distributed development, support and QA functions.
An obfuscation solution addresses all of these issues by embedding the obfuscation algorithm into a process that is itself integrated into the broader application development lifecycle. An obfuscation solution should include

An integrated and distributed “lucidator”

A lucidator can reverse much of the obfuscation process to support debugging. Of course it must be a secure process that cannot run outside of its environment or on unauthorized code. Integration with the obfuscator supports unit testing and distribution enables debugging and support outside of the developer community that uses the obfuscator.

Declarative obfuscation

Developers are able to markup their code using attributes that define the level of obfuscation to be applied at a granular level maximizing developer control.

Incremental obfuscation

Obfuscate patches ensuring that they can be applied in the field against previously obfuscated code.

Integration into your IDE

Managing and automating the obfuscation process within your common IDE simplifies and secures this process within the broader development lifecycle supporting continuous integration.
Make sure that when you look for an obfuscator, you are really looking a complete obfuscation solution.

The Software Security Summit

If you are going to the Software Security Summit stop by PreEmptive's booth and attend our talk: TITLE: Binary protection: alignment with IT Governance, IP policies and effective risk management

The role of source code protection is well-understood in the context of IP management and security. Assuming that a reasonable set of controls are in place as a function of an effective IT governance program, most organizations are under the impression that they are managing risks associated with the loss of intellectual property, loss of revenue due to piracy, malicious attacks on operations and, by extension, reputation.

However, the richness and flexibility of modern runtime platforms such as Java and .NET have the side effect of simplifying the reconstruction of source code via access to associated binaries. As a result, organizations must either extend source code controls to their executables or establish an alternate set of compensating controls to mitigate these risks. Typically, it is not practical to manage executables in the same fashion as source due to the obvious difference in use. Therefore, an alternate strategy is required to provide a reliable mitigation of risk. Program obfuscation offers one such strategy. This session will discuss the different types of obfuscation technologies available, some of the issues that arise when using an obfuscator, and steps you can take to make obfuscation a seamless part of a secure development cycle.

 

 

Thoughts on .NET Obfuscation, Encryption and Coverting to Native

Tools that rely on encryption to protect an application suffer from has a critical flaw:  the app needs to be decrypted on the client before being fed to the runtime.  A hacker can potentially recover a decrypted version of the image, and that image (even though it's native) still contains the metadata.

With obfuscation, critical information (useful to human readers of the code), is removed before the app is delivered to unsecured clients.  You can't crack it if it isn't there.

Tools that convert a .NET app into native code defeat the main ideas behind .NET.
The idea of .NET is that applications will be able to run on any platform.
Have you tried to run one a native app on a 64-bit version of the .NET framework? I don t think it will work. I do not think it is even possible for native code to work cross platform. Any what about PocketPCs?

Also, this code is no longer managed because managed means 100% IL. And there may be a big difference in security between this code, and managed code.

Lastly, please, please test a tool that claims to turn your .NET app into a native on your application before buying it. I have had many people tell me that their app does not work exactly the same after being run through a tool that converts it to a native one.

.NET Obfuscation is a safer and more robust solution. It does not violate the intent of .NET and properly applied, it significantly raises the bar against reverse engineering.

Visual Studio 2005 is ready to launch

There is lots of excitment surrounding the VS 2005/SQL Server 2005 launch in San Francisco on November 7, 2005.
A link to the event is here http://www.microsoft.com/events/2005launchevents/default.mspx

We will be at the event and of course are happy that Dotfuscator Community Edition is shipping inside Visual Studio 2005.

Because, we are in the box -
Dotfuscator Professional Edition has had support for .Net Framework version 2.0 (beta) and Visual Studio 2005 (beta) since April and
Support for the final release of .Net Framework version 2.0 and Visual Studio 2005 over a month ago.

Welcome to the Obfuscator Blog -- So what is it?

An Obfuscator is the business of shrouding the facts. It is not encryption, but in the context of .NET code, it might be better. Although encryption can make your assembly completely unreadable, this methodology suffered from a classic encryption flaw, it needed to keep the decryption-key with the encrypted data. So, an automated utility could be created to decrypt the code and put it out to disk. Once that happens the fully unencrypted, unobfuscated code is in clear view.

As another comparison, we could compare encryption to locking a ten item meal into a lockbox. Only the intended diner (i.e. the CLR) has the key and we don't want anyone else to know what he or she is going to eat. Unfortunately, if someone can pick the lock (or find the key hidden on the bottom of the box), the food is in plain view. Obfuscation works more like putting the six-item meal into a blender and sending it to the diner in a baggie. Sure everyone can see the food in transit, but besides a lucky pea pod or some chicken-colored goop, they don't know what the original meal consists of. The diner still gets the intended delivery and the meal still provides the same nutritional value as it did before (luckily, CLRs aren't picky about taste). The trick of an obfuscator is to confuse observers, while still giving the CLR the same delivery.

Without argument, obfuscation (or even encryption) is not 100 percent protection. Even compiled C++ is disassembleable. If a hacker is perseverant enough, they can find the meaning of your code. The goal of obfuscation is to make the reverse engineering process extremely time consuming and painful so that it not worth the effort. The goal is to stop all casual hackers and as many serious hackers as possible.

Obfuscation removes context from compiled code that humans (and reverse-engineering tools) would use to decipher the code's meaning. The trick is to remove this context from evil intentions while retaining complete execution integrity with the original program.

Want to try obfuscation...

Fire up Visual Studio, click on the tools menu and select Dotfuscator Community Edition.

Dotfuscator is available in three editions and you can learn more about the differences here.