Eazfuscator.NET Blog

Reading Environment Variables from Another Running Process

2011-06-06T00:37:00.008+03:00

Recently I was working on some changes aimed to achieve better usability experiences for Eazfuscator.NET.

One of the common pitfalls is the requirement to restart Microsoft Visual Studio after the first Eazfuscator.NET installation. This requirement is commonly addressed by a message box during installation asking user to restart the running instances of Visual Studio. While it is a technically simple solution, it adds one additional screen (a message box) to the user interface and user should react to that message box by pressing OK button. This can worsen the user experience as this stands out of the expected installation workflow.

So I decided to implement another solution. Whenever user tries to protect a project the following screen appears:

As you can see, there is a large amount of space where the desired message can reside. And it computes pretty well to the user workflow, unobtrusively suggesting to restart Visual Studio to complete the installation of Eazfucator.NET. Of course, there is nothing to complete; the restart of Visual Studio is required just to apply an updated set of environment variables Eazfuscator.NET integration relies on.

The next thing to decide is when to show that message.
And here comes the most interesting part, actually directly reflecting the topic.

The only reliable way to detect the necessity of Visual Studio restart is to analyze its current environment variables. Visual Studio generally runs as devenv.exe process, so we have to retrieve its environment variable values.

The first implementation, I naively thought it had to work out:

    class Program
    {
        static void Main(string[] args)
        {
            var processes = Process.GetProcessesByName("devenv");
            foreach (var process in processes)
            {
                var env = process.StartInfo.EnvironmentVariables;
 
                string path = env["PATH"];
                Console.WriteLine(path);
            }
        }
    }

While it runs without errors, the retrieved value of PATH environment variable is wrong. It corresponds to the current running process, not that remote devenv.exe process it supposed to be. How does this happen? Well, this is a flaw in System.Diagnostics.Process class from .NET Framework. While it seems like it has to work out, actually it does not, giving you the wrong values without raising exceptions.

After investigation, it became evident that Windows has no API to retrieve the environment variables of another running process in the system.

But there is a good workaround which allows to retrieve the desired values with the help of ntdll.dll API and ReadProcessMemory function.

The technical details and sample C++ code can be found here. Unfortunately, I did not find a decent implementation for .NET which would handle both 32 bit and 64 bit scenarios. That's why I created the component for reading the environment variables of a running process from scratch.

So, let me introduce the interface part of the component. It is very simple and everything is implemented inside one class:

    using System.Collections.Specialized;
    using System.Diagnostics;
 
    static class ProcessEnvironment
    {
        public static StringDictionary GetEnvironmentVariables(this Process process)
        {
            // The implementation goes here.
        }
 
        public static StringDictionary TryGetEnvironmentVariables(this Process process)
        {
            // The implementation goes here.
        }
    }

As you can see, ProcessEnvironment is a static class with two extension methods.

And this is how it can be used:

    class Program
    {
        static void Main(string[] args)
        {
            var processes = Process.GetProcessesByName("devenv");
            foreach (var process in processes)
            {
                var env = process.GetEnvironmentVariables();
 
                string path = env["PATH"];
                Console.WriteLine(path);
            }
        }
    }

Neatly done, isn't it?

The full sources of the component and sample usage can be found in the sample project.

Download sample project

Resource Encryption and Speed Improvements

2011-04-17T04:53:00.003+03:00

Eazfuscator.NET 3.1 has been released just a few minutes ago, so I’m here to spread some words about it!

This release includes highly demanded features and improvements.

Resource encryption
This highly demanded feature allows to encrypt and optionally compress the embedded resources of an assembly.

Out of the box support for Managed Extensibility Framework (MEF)
Reflection analysis engine in Eazfuscator.NET was improved to automatically handle the semantics implied by MEF. This feature is a decent addition to the product, given that MEF is becoming more and more widespread nowadays thanks to its excellent design and robustness.

Code control flow obfuscation produces fully verifiable code
The code produced by control flow obfuscation was unverifiable in previous versions of Eazfuscator.NET. Unverifiable code is out of .NET standard and control flow obfuscation was treated almost as a hack before. New Eazfuscator.NET guarantees that produced code is always verifiable and thus can be validated by PEVerify tool for a full conformance to .NET standard. This also means that code control flow obfuscation is safe and compatible with Mono and other alternative .NET runtimes now.

Better reflection analysis engine
Eazfuscator.NET now understands even more about LINQ, Web services, component designer and serialization. This allows to achieve better, non-intrusive obfuscation results.

Improved multi-core performance
New Eazfuscator.NET is a lot faster on multiprocessor systems than the previous versions, so it is definitely worth a try if you have large projects and long builds.

Some other improvements and fixes are included in the release as well.
You can download the new version right now or whenever you find it suitable.

Thank you!

Eazfuscator.NET 3.0 Released

2011-01-16T00:21:00.001+02:00

I just want to say that Eazfuscator.NET 3.0 has been released just a couple of minutes ago.

This release includes a great set of the new features:

Assemblies embedding with encryption and compression. Assembly's dependencies can be embedded into the assembly itself, this is a great way for creating single-file deployed applications
Debugging. Eazfuscator.NET now handles .pdb files, so you can debug your code after obfuscation
String compression. Large strings are compressed during obfuscation. Compressed strings are decompressed on demand during the run time. The decompression algorithm is incredibly fast, so there is no performance penalty observed — the actual decompression speed comes very close to the speed of a simple memory copy. String compression and the corresponding decisions are the parts of an automatic process, so you don't have to put any efforts here; Eazfuscator.NET does this all for you.

The release contains a set of other improvements as well.

There is a lot of ongoing work for better WPF, Silverlight and Windows Phone support, plus some other new great features are being developed and evaluated and will find their ways in new Eazfuscator.NET releases.

I would like to thank all those who made a feedback on Eazfuscator.NET and helped to make it better. Thank you!

Get your copy right now!

XML Documentation Filter

2010-10-30T01:35:00.015+03:00

XML Documentation Filter is a feature that arrived in Eazfuscator 2.8.

Ok, let me start the show.

    public class DS1307
    {
        /// <summary>
        /// Gets a value indicating whether clock is in halt state.
        /// </summary>
        /// <value><c>true</c> if clock is in halt state; otherwise, <c>false</c>.</value>
        public bool IsClockHalted
        {
            get
            {
                byte data = I2CBus.Transfer(Address, 0x00);
                return (data & 0x80) != 0;
            }
        }
    }

I know that every .NET developer saw such comments for a code entity at least once in his life :) That kind of comments allows to provide a quick documentation for a class, property or method.

Code documentation is used by Visual Studio to show IntelliSense hints:

So, as you can see, code documentation is a nice and useful feature.

If you write a class library then it’s always a good idea to provide code documentation. Visual Studio gives such ability by enabling XML Documentation generation for your project:

Whenever you build your project with XML documentation enabled you will get two main files in the output folder – assembly file and corresponding XML documentation file:

As you can see, there is MyLib.XML file in the output folder. Let’s take a look on its content:

<?xml version="1.0"?>
<doc>
    <assembly>
        <name>MyLib</name>
    </assembly>
    <members>
        <member name="P:MyLib.DS1307.IsClockHalted">
            <summary>
            Gets a value indicating whether clock is in halt state.
            </summary>
            <value><c>true</c> if clock is in halt state; otherwise, <c>false</c>.</value>
        </member>
    </members>
</doc>

MyLib.XML file contains documentation for the public property IsClockHalted of the class DS1307 from MyLib assembly. That’s exactly what you might expect. File contains minimal and sufficient amount of information.

A Security Problem

Let’s add some private members to our class (marked with yellow):

    public class DS1307
    {
        /// <summary>
        /// Gets a value indicating whether clock is in halt state.
        /// </summary>
        /// <value><c>true</c> if clock is in halt state; otherwise, <c>false</c>.</value>
        public bool IsClockHalted
        {
            get
            {
                byte data = I2CBus.Transfer(Address, 0x00);
                return (data & 0x80) != 0;
            }
        }
 
        /// <summary>
        /// An I2C bus instance.
        /// </summary>
        private II2CBus I2CBus;
 
        /// <summary>
        /// Device address at I2C bus.
        /// </summary>
        private byte Address;
    }

Rebuild the project and here is the corresponding content of MyLib.XML file:
<?xml version="1.0"?>
<doc>
    <assembly>
        <name>MyLib</name>
    </assembly>
    <members>
        <member name="F:MyLib.DS1307.I2CBus">
            <summary>
            An I2C bus instance.
            </summary>
        </member>
        <member name="F:MyLib.DS1307.Address">
            <summary>
            Device address at I2C bus.
            </summary>
        </member>
        <member name="P:MyLib.DS1307.IsClockHalted">
            <summary>
            Gets a value indicating whether clock is in halt state.
            </summary>
            <value><c>true</c> if clock is in halt state; otherwise, <c>false</c>.</value>
        </member>
    </members>
</doc>

As you can see, the documentation for private class members was generated and stored in MyLib.XML (marked with yellow).

Let’s stop at this point and analyze the consequences of this in terms of obfuscation. Obfuscation is the process of hiding information about inner structure of the system from the prying eyes of reverse-engineer.

And now we have information about private assembly items right in MyLib.XML file... This is shocking from security point of view.

It is worth to mention that XML documentation files are often distributed together with product assemblies, so you can estimate an amount of possible intellectual property leakage that can be brought by XML documentation files.

Solution

XML Documentation Filter built in Eazfuscator.NET comes to the rescue.

Let’s protect MyLib project with Eazfuscator.NET by drag’n’dropping the project from Solution Explorer of Visual Studio onto the green zone of Eazfuscator.NET Assistant:

Then rebuild the project in Release configuration with Visual Studio and take a look on MyLib.XML file content:

<?xml version="1.0"?>
<doc>
  <assembly>
    <name>MyLib</name>
  </assembly>
  <members>
    <member name="P:MyLib.DS1307.IsClockHalted">
      <summary>
        Gets a value indicating whether clock is in halt state.
      </summary>
      <value>
        <c>true</c> if clock is in halt state; otherwise, <c>false</c>.</value>
    </member>
  </members>
</doc>

Voila. What we see is that all private documentation is gone. The only documented item is a public property in terms of inter-assembly visibility. Exactly what’s expected without security compromises.

That was just a simple sample, but I assure you that XML Documentation Filter gives a considerable effect on bigger assemblies. XML documentation for non-public assembly items is automatically pruned so that essential knowledge about component internals does not leak to the rest of the world.

How It Works

As many things in Eazfuscator.NET, XML Documentation Filter works behind the scene to ease your life. No special options should be given to Eazfuscator.NET. All required actions are automatically performed on obfuscation stage:

XML documentation file location is extracted from the project file (.csproj, .vbproj)

If step 1 fails then Eazfuscator.NET tries to find a corresponding XML documentation file by heuristic search

XML documentation file is processed according to obfuscation information to prune non-public items

Conclusion

XML Documentation Filter is a step toward better obfuscation results. This feature is essential for component developers and publishers, by whom XML documentation files are published on every release.

Eazfuscator 2.8 Arrived

2010-04-13T03:26:00.009+03:00

Phew! After Visual Studio 2010 arrival I spent several hours on integrating things, polishing documentation and making triple-testing of the new release. And it seems it is April 13 on my local time now.

This release brings some new cool features:

XML documentation filter (← this guy is the most prominent one!)
Signing key auto-discovery
Support for .NET 4.0 and Microsoft Visual Studio 2010
Fail-safe MSBuild project integration
Guaranteed CLS-compliance of the resulting assemblies

Unfortunately I had to postpone several features and bug fixes that could enter in 2.8. I did that for the sake of stability — version 2.8 has the biggest changeset ever that were packed in one version during the whole history of Eazfuscator.NET.

I will describe all the new features one by one in my next articles. I hope you'll enjoy 2.8!

Eazfuscator.NET 2.8 Release Announcement

2010-03-30T21:06:00.011+03:00

New version of Eazfuscator.NET will be available on April 12, 2010. It is synced to .NET 4.0 and Microsoft Visual Studio 2010 release on the same day.

Version 2.8 brings some new cool features and quality improvements.

New features and ideas will be described in details right after release on April 12. Stay tuned!

P.S. Please note that it's not always possible to process all feedback reports in a real-time fashion, however they are really helpful! Thank you for your feedback and support!

Three Tools Every Project Should Use

2009-09-01T06:59:00.021+03:00

If you want to get things go smoothly during your software development process then this post can be useful for you.

As you know, writing the code is not the main force for a development of delicious software. It sounds quite paradoxical, but the main things are planning and support.

Let me show an example about the planning. A few smart and accurately implemented features can easily overweight the tons of clunky code. The code is nothing by itself. It can be useful only when it flawlessly implements some useful features.

Support allows to achieve bug-free operation of your software. Support makes your customers happy. Support gives you hints for the further project development.

Those approaches require frequent, small, incremental code changes. And your project must be ready for this. You have to go out and prepare three basic aspects:

Automated tests. They allow to be sure about the quality of produced software. Make sure they are easy to launch and then just press the button from time to time; after every bug fix and before each release to the public, as for example

Creation of the final installation package with one or a few button clicks. It makes code changes really cheap and effortless for you. Just fix, build and deliver. Don't think about how the installation must be built every time you need to build it. Let complex things become simple. Just press the button

Publishing and delivery with one or a few button clicks. Ok, installation package is ready, but how are you going to publish? FTP-copy to webserver, fix some HTML, write about some changes, ..., etc.
Do not do it like that.
Create a single-click solution. Just press the button

So, if you curious about how it's done in Eazfuscator.NET project, let me show.

Testing suite is built with Visual Studio test project. The test project contains a bunch of tests. Every test just references the corresponding .exe file. Every .exe file for every test is created by a separate project, depending on requirements for the test. It may be C# project for .NET, VB.NET project for Compact Framework and so on. Every .exe is launched in a separate AppDomain at the beginning of a test. During .exe execution its stdout output is grabbed and recorded to the memory. After that, the .exe file is processed with Eazfuscator.NET obfuscator. Then it launched again in a new AppDomain and its output is then grabbed and compared to the original output of non-obfuscated .exe. If the outputs differ, then “Ooops, something went wrong” and test fails.

The test suite works really great being dumb and simple. Screenshot of the window with the tests being executed after some small bug fix today:

And then, bingo!, code changes are ok, everything works as expected:

Installation builds and publishing are controlled by a tool called “Eazfuscator.NET Production Board”. Actually I've created it in a form of a kit and it can be attached and customized to any project within a minute. Screenshot:

Buttons for the most frequent operations are color-marked for a greater associativity and scan-ability by the eye; it speedups the game. The tool allows to orchestrate the whole manufacturing process of your product within several button clicks. Simple and dumb at the face, but super smart behind the scene. The real time saver.

P.S. Section below was added to show the functionality of Production Board in details.

Production Board does several important things. First of all, it allows you to modify the version information for a product. It can be done by pressing “Change version” button:

As you can see, you are informed about the current version and you can define the new one. By default, the dialog just increments the build number of a version and generates the new revision number based on the current time, so it gives the new version for a product. It can be overridden by the user if necessary. Also it's possible to select several predefined version descriptions from a drop-down list, such as Release and Beta.

When the user presses OK button, the new version is delivered to the project files. Behind-the-scenes magic begins right here. There are several places in the project to put the new version in. Obviously, AssemblyInfo.* files are patched to correspond to the new version. Installation project file (.vdproj) is also patched to define the new version for an installation package. The new GUID for installation UpgradeCode is automatically generated too. Changelog XML file is patched to include the latest version number and a fresh time stamp. And the last patched place is an update manifest file which allows customers to potentially receive an update for that new version through the Internet.

“Rebuild solution” button just rebuilds the code base and installation package by invoking corresponding tools. For Eazfuscator.NET, the windowless Visual Studio instance is created with COM automation interface. That instance builds the code and installation package.

“Publish” button gathers and delivers product output files to the predefined folder on the file system. During this step the file name for an installation package is renamed to eye-candy name which includes the current product name and version: setup.msi becomes Eazfuscator.NET 2.6.20 Beta Setup.msi.

After the publish step, the product can be played and tested at the local machine. That's why there are “Install”, “Uninstall” and “Open publish folder” buttons. If the product passes the last manual test(s) then it can be published on the web.

“Publish on Web” button copies files to the web-server via secured FTP channel. These files are placed at the special locations on the web-server, so the web site application catches them and generates the new content about the new available version.

Change version, rebuild solution and publish are common actions being executed one-by-one at most of the times. So that's why there is a yellow button with a long arrow on the dialog. This button aggregates those three frequent actions in one click.

Future Development

2009-05-14T19:39:00.012+03:00

I am going to cover some future directions of Eazfuscator.NET development in this article.
There are three main milestones planned for this year:

~~Flexible tuning~~ ✓done
Eazfuscator works great for 90% of applications now. The rest of applications require some gentle obfuscation tuning. That's why such ability as namespace obfuscation control will be added.
~~Encryption of embedded resources~~ ✓done
This is useful feature which allows to hide all embedded resources of an assembly from prying eyes.
Custom virtual machine
Custom virtual machine uses custom bytecode which is unknown to existing decompilation tools. Some parts of obfuscated .NET application can be translated from Common Intermediate Language (CIL) to the custom bytecode. The resulting code is then executed during runtime by embedded custom virtual machine which works on top of .NET runtime. Furthermore, the grammar of the custom virtual machine is randomly generated on every run of Eazfuscator.NET, so it's guaranteed that it will be nearly impossible to create a stable decompiler. This technique has some drawbacks, and the most outstanding one is performance degradation. So this means that custom virtual machine must be applied just to the most precious algorithms you want to hide.

If you have some other ideas then please don't hesitate to share, I'm always open to hear from you.

Making a Product

2009-04-20T18:42:00.016+03:00

Writing an application is just a half of the road. Another half is to make a product which can be used by other people.

The most important aspect of a product is that it must be ready to be consumed by the customers. If a product is not consumable by an average customer then product is considered as unfeasible.

In software world it means that your application must be well-tested, documented and be ready for a wide deployment on divergent set of customer machines and platforms. Also product must be easy to start with. Average customer should enter its comfort zone within the first 20 minutes of product usage. Otherwise the product will be abandoned by a customer.

Another thing manufacturer should think of is to provide quick feature-tour of a product to a customer. The most efficient way to do that is to use visual signs, text and colors. Take a look at two pictures below:

I often see those two kinds of juice packages when I go to a market every weekend. The picture on the left shows strict white package with some green text on it. The picture on the right shows colorful package with some text and nice attractive photo of the pineapple.

Obviously, most of the customers prefer colorful package shown at the right. There are two factors which have impact on a customer decision:

Colorful things take more customers' attention
Pineapple photo gives a better feature set to a customer comparing to the blank package at the equal amount of time

So, let's return to Eazfuscator.NET.
I wrote the core part of Eazfuscator from September 2007 to the end of November.

Knowing all those tricks about products I additionally spend two months to make a product from just a written application. I wrote documentation, designed user interface of Assistant, created MSI installation package. The result of all these efforts was the first public release on February 6, 2008.

This article is the last one in the history series. Further articles will be mostly dedicated to the current development of Eazfuscator.NET.

Concept

2009-02-25T02:07:00.004+02:00

The concept of Eazfuscator.NET was born in early autumn of 2007. It became clear to me that there were no decent products available at that time.

Most of the obfuscators for .NET were quite hard to use as for me. First of all, they all required significant efforts to make them just start working. Many of them required too much of manual guidance through obfuscation transformation decisions so I had to set tons of check boxes against class members tree. And many of them were extremely unfriendly in terms of build process integration.

The only obfuscator I was fascinated about was {smartassembly} which is commercially available product. It was easy to use and it worked very well. However I was disappointed with significant performance degradation of encrypted strings. Another concerning issue was a lack of x64 platform support at that time and I was working on x64 since mid of 2005. Keeping in mind that then was 2007, it is 2 years distance and not so positive signal for the product.

* Please keep in mind that information above may be outdated now.

The final contributing factor to start own project was indescribable fusion sparkle in my head. It's hard to describe without fear to be blamed in madness but it was a very new feeling to me. The feeling of thousands of parallel thoughts that go through my head. So this was a starting point for Eazfuscator.NET. The whole product concept was born within several seconds somewhere at September 2007.
The main principles of Eazfuscator.NET are:

Ease of use. Yes, things must be simple because this is the only way for a human to manage them
Automatic obfuscation and integration without manual work. Manual work is a waste of time and money, so no waste anymore
Painless build process integration. Integration must take several seconds and not countless hours
Stability. I know that a lot of people might be using Eazfuscator.NET to create their own products. So Eazfuscator.NET must be bullet-proof stable to be able to do its best job
Free availability

User interface prototype appeared at the same time as the whole concept did. I drew the following picture:

Given user interface is primarily designed to be used in conjunction with drag-and-drop. The picture above consists of two zones: red zone to the left and green zone to the right. Right side and green color are obviously associated with safety, at least in European cultures. So the green zone is responsible for protection (obfuscation). Left side and red color are obviously associated with potential danger. So the red zone is responsible for removal of previously applied protection. Protection removal does not mean reverse-obfuscation, it just means that given .NET project will not be obfuscated anymore. Whenever user wants to change protection settings of .NET project he drags and drops the project onto corresponding zone.

So that was a brief history of concept birth for Eazfuscator.NET obfuscator.

Introduction

2009-02-24T03:40:00.000+02:00

Dear Readers,

This blog is dedicated to Eazfuscator.NET. Such a strange name was given to a special application which obfuscates .NET applications. Facts, motivations, history, thoughts and other aspects of Eazfuscator.NET obfuscator will be covered in this blog.

First of all I would like to make some short introduction to the .NET world and domain of obfuscation.

.NET is a technology from Microsoft which allows to create quality and reliable software. .NET platform is similar to Java platform but has many unique features. I would say that .NET inherits the best achievements of Java and adds some new superior concepts such as support of multiple programming languages.

Applications that were written in one of .NET languages (C#, VB.NET, etc.) are often called managed applications. The word managed means that those applications work under control of .NET Runtime. It is worth to mention that there is another kind of applications which do not use .NET Runtime; these applications are called native ones.

Application development with .NET is much more easier and productive comparing to native application development and brings many benefits to developers and product quality. However .NET has some weak points. The most concerning one is an ability to easily reverse-engineer an application after compilation. It is possible because managed applications are compiled to Common Intermediate Language (CIL) which contains a lot of additional meta data. So it's a piece of cake for decompiler tool to reverse the source of an application. You may take a look at .NET Reflector tool as a proof of concept.

Eazfuscator.NET allows to minimize the risks of possible decompilation. It uses several techniques to prevent reverse-engineering of applications. The short description of obfuscation process is: sensitive data are hashed or encrypted, superfluous meta data are removed.

It is possible to find a lot of flaming forum threads on the Internet where people debate about obfuscators and their applicability. However if you value your intellectual property then I would say that obfuscation is a must-have for your precious software products.