Building in the Cloud with Dotfuscator Community Edition

February 23, 2017 6259 Views Bill Leach

Most of our previous blogging about Dotfuscator Community Edition (CE) assumes you are doing local builds, or have a dedicated build server—but what if you want to use Dotfuscator CE within a distributed build system such as Visual Studio Team Services (VSTS) or Team Foundation Server (TFS) on-premises? Until now, you've had to do extra work to install and provision Dotfuscator CE on each build agent host in your pool. Now, we're pleased to announce a VSTS build extension for Dotfuscator CE, available in the VSTS Marketplace. It does the extra work for you, making it easy to get Dotfuscator CE into your distributed build.

Let's walk through an example, using a sample project. The overall process is:

Stage a local build of the project and verify that Dotfuscator CE is configured correctly.
Push it to a VSTS hosted project.
Automate the build using the new Dotfuscator CE build extension.

Setup the Local Sample Project

Download the "hello world" sample application and unzip it to a directory on your file system. The zip file contains two versions of the sample: one tailored for Visual Studio 2015 and up, and one tailored for Visual Studio 2017. For this exercise, choose the "Visual Studio 2015" version of the sample (even if you are using Visual Studio 2017 locally), since that is what we will be using on the build agent hosts. You can review the included Readme.txt file to learn more about the sample application.
Open the DotfuscatorCommunityEditionSample.sln file in Visual Studio and build the release configuration. The solution should build with no errors or warnings.

Setup your Local Environment

Get and verify that you have Dotfuscator CE. You should see it on Visual Studio's Tools menu. If it is not there, you can always find the latest version on the Dotfuscator Downloads Page.
The "hello world" sample ships with a ready-made Dotfuscator configuration file that exercises many of Dotfuscator CE's capabilities, such as renaming and tamper detection. To test that you have the environment setup correctly, run the Dotfuscator CE GUI from the Tools menu and open the sample's configuration file (dotfuscator_config.xml).
Build the project in the Dotfuscator UI and verify that it builds without errors, and that the output assembly is located in the "Dotfuscated" directory.
If your copy of Dotfuscator CE is unregistered, now is a good time to register it, because you will need your serial number in a later step.

Push to VSTS

Once you have a successful local build, the next step is to push the project to the remote repository. We will use VSTS, but the same procedure will also work if you are using on-premises TFS 2015 (Update 3 and above).

Create a local git repository for the project, along with an associated team project in VSTS. This tutorial will help you if you are not already familiar with the process.
Before syncing your local repository with the remote:
- Delete the local Dotfuscated directory (if it exists from previous builds), and any files in it. We do not want to store the obfuscated outputs in the git repository.
- Exclude that directory from future commits by adding the following to the .gitignore file:
```
Dotfuscated/
```
Commit the above changes, and sync the local repository to the remote. At this point you should be able to see the sample code in the VSTS portal, like this:

Create a Build and Add the Dotfuscator CE Extension

Create a build definition, using the .NET Desktop template. This tutorial will help you if you are not already familiar with the process. When complete you should see something like this in the VSTS portal:
If you queue the build as-is, it will succeed, but the output assembly won't be protected. Let's fix that by Getting the Dotfuscator CE extension from the Marketplace. Click the install button to add it to your VSTS account.
Once installed, add the Dotfuscator CE Provisioner Task to your build by editing the build definition, and adding the task from the Utility category.
The Provisioner task must run before Dotfuscator CE runs, so after adding the task to your build definition, move it above the "Visual Studio Build" task.
Configure the Provisioner task:
- In the Dotfuscator Community Serial Number field, enter the serial number you received when you registered your local version of Dotfuscator CE. For reference, it is located on Dotfuscator CE's "About" box.
- Select the Dotfuscator Version you wish to use, by selecting the associated Visual Studio version from the dropdown. As of this writing, the build agents in the hosted pool do not yet have Visual Studio 2017, but that is expected to change very soon. The Dotfuscator CE extension will support Visual Studio 2017 when that happens; but for now, choose Visual Studio 2015.
- The last field, User Specified Environment Variable is not required in this case. If you have a custom build agent host with Dotfuscator CE installed in a non-default location, you can use this field to provide the name of an environment variable on the build host that contains the path to the Dotfuscator CE command line executable. Since we will be using build agents in the hosted pool, which already have Dotfuscator CE in the default locations, setting this is unnecessary.
- Save your changes to the task configuration.
Next, add a Dotfuscator Community Edition Task to your build definition. It is available in the Build category.
Move it below the "Visual Studio Build" task, so it runs after code compilation.
Configure the Dotfuscator CE task:
- In the Relative Path to Configuration File field, enter the name of the Dotfuscator configuration file (you can also browse for it in the project tree).
- In the Additional Command Line Arguments field, you can also pass command line arguments to Dotfuscator CE. For this example, none are necessary, so we will leave it blank.
- Save your changes to the task configuration.
Now, if you queue a build, it should pass. You should see output from Dotfuscator CE in the logs from the "Run Dotfuscator" step.
We aren't finished yet, because we still need to capture the obfuscated output assembly and the renaming map file as build artifacts. Do this by modifying the Copy Files task to include everything in the Dotfuscated directory.
Now if you do a build, not only should it pass, but the obfuscated outputs will be included with the other build artifacts.

Other Scenarios

We've covered a basic end-to-end scenario, using a simple Visual Studio solution, building with VSTS. There are additional ways to use the Dotfuscator CE build extension, and it supports many other scenarios:

As mentioned, it is supported with on-premises TFS versions 2015 Update 3 and higher. The configuration steps are the same.
You can use it with custom build agent hosts, so long as Dotfuscator CE itself is installed on them.
If you want to run Dotfuscator CE directly inside of a solution build (e.g. as an Exec task in a project's AfterBuild target), you can. To do so, you only need the Provision step before the solution build task in your build definition. The Provision task sets a build variable called DotfuscatorCEDir that you can reference in your MSBuild scripts. For example:
```
<Target Name="AfterBuild" Condition="'$(Configuration)' == 'Release'">
  <Exec Command="&quot;$(DotfuscatorCEDir)\dotfuscatorCLI.exe&quot; ..\dotfuscator_config.xml" />
</Target>
```

Conclusion

You now have an idea of what's possible with Dotfuscator CE in the cloud. You can use the VSTS build extension to easily protect your application from reverse engineering, tampering, and unauthorized debugging.

Dotfuscator Community Edition is free for experimental and non-commercial use. For commercial use, Dotfuscator Professional Edition offers advanced obfuscation and code protection capabilities, and also can be run in distributed build environments. You can try Dotfuscator Professional Edition for free, with support, by signing up for an evaluation.

Latest Blog Posts

Dotfuscator 6.0 Beta: Entering the Next Era of Dotfuscator

Today we're announcing the first new major-version release of Dotfuscator in thirteen years: Dotfuscator Professional 6.0 Beta. It's an exciting new release with major new capabilities, but before we get into that, let's take a look at why it's been so long since we had a major release and why we're choosing to do one now.

For development teams, adding Dotfuscator to a build pipeline can often seem like a challenge; the value it adds is mostly gained by the surrounding business, and the cost of adding it is mostly borne by the development team. We understand that constraint, which is why we focus on making Dotfuscator as easy to integrate and maintain as possible. If you're a long-time user of Dotfuscator, you've probably experienced that - release after release of painless upgrades. That's our "first do no harm" philosophy in action.

The dynamic type in C# provides flexibility that is not available in other statically-typed languages. Since its introduction in C# 4.0 (.NET 4.5), we have worked with customers who wanted to know more about how dynamic types are impacted by the obfuscation process.

Malicious actors — like any thieves — live by a simple rule: If the front door is locked, break the window.

It’s why threats like fileless malware and crypto-jacking have seen substantial gains over last few years. It’s why — despite increasing employee education and IT training — hackers are still hooking phish by developing more sophisticated and authentic-looking email spoofs. Cybercriminal communities, meanwhile, continue to grow on the dark web, allowing attackers to share info, purchase exploit kits and identify potential targets.

What does this mean for CISOs? That typical defense efforts are being outpaced as familiar attack vectors are replaced with non-traditional threats. But it’s not all bad news; here are three questions every CISO needs to ask to help close the doors, bolt the windows and leave hackers out in the cold.

Gabriel, you have been in the security industry for over 2 decades. You have seen many different tools and services. Why create a company around something as specific as obfuscation and in-app protection?

Our customers build a lot of really innovative apps that enable their users and customers to do new and cool things. These apps frequently run on untrusted client computers/devices and they control access to customer’s sensitive data or critical devices.

And after all the effort of designing, building, debugging, and deploying their applications, the last thing they want is for an attacker to steal their work or use it to look for vulnerabilities to break into their system.

Long ago, we built a Java code optimizer, but it became clear to us that our customer cared more about the obfuscation effects of the optimization than the actual performance improvement. That is when we really began to focus on app protection. First with Java, then .NET, Android, iOS, Xamarin, JavaScript, etc.

Gartner calls In-App Protection “crucial” in their July 2019 Market Guide for In-App Protection In-App Protection. The guide’s summary advises security and risk management leaders to “take due care in protecting their application clients” in order to avoid “security failure.”

This raises the question – what constitutes “due care?” Obviously, no development organization looks to recklessly expose their applications or sensitive data to attack or compromise. On the other hand, over-engineered (or poorly engineered) security controls can quickly lead to excessive development costs, performance and quality issues, and, ultimately, unacceptable user experiences. While terms and terminology may vary, there is broad consensus on how to best define “due care” for any given application/user scenario.

Building in the Cloud with Dotfuscator Community Edition

Setup the Local Sample Project

Setup your Local Environment

Push to VSTS

Create a Build and Add the Dotfuscator CE Extension

Other Scenarios

Conclusion

Dotfuscator 6.0 Beta: Entering the Next Era of Dotfuscator

Protecting C# Applications That Use Dynamic Types

Non-Traditional Attack Vectors: Three Questions Every CISO Needs to Ask

Q&A With PreEmptive CEO Gabriel Torok

Gabriel, you have been in the security industry for over 2 decades. You have seen many different tools and services. Why create a company around something as specific as obfuscation and in-app protection?

The Secret to Effective In-App Protection

Latest Blog Posts

Dotfuscator 6.0 Beta: Entering the Next Era of Dotfuscator

Introducing JSDefender: PreEmptive Protection now includes JavaScript

Protecting C# Applications That Use Dynamic Types

Non-Traditional Attack Vectors: Three Questions Every CISO Needs to Ask

Q&A With PreEmptive CEO Gabriel Torok

Twitter