Dotfuscator and Analytics

Although Dotfuscator can be launched from the Tools menu within Visual Studio 2017, it is a separate product with its own licensing. The Community Edition (CE) contains only a subset of the functionality of the commercial edition of the product, the Dotfuscator Suite. If you are serious about trying to hide the functionality embedded in your application, you should consider upgrading. You can find more information on the commercial version of Dotfuscator at http://www.preemptive.com/products/dotfuscator/compare-editions.

Dotfuscator CE uses its own project format to keep track of which assemblies you are obfuscating and any options that you specify. After starting Dotfuscator from the Tools menu, it opens with a new unsaved project. Select the Inputs node in the navigation tree, and then click the button with the plus sign under the Inputs listing to add the .NET assemblies that you want to obfuscate. Figure 34-4 shows a new Dotfuscator project into which has been added the assembly for the application from earlier in this chapter.

On the right side of the interface, make sure that Library mode is unchecked. Then you can select Build Project from the Build menu, or click the Build button (fourth from the left) on the toolbar, to obfuscate this application. If you have saved the Dotfuscator project, the obfuscated assemblies will be added to a Dotfuscated folder under the folder where the project was saved. If the project has not been saved, the output is written to c:Dotfuscated.

If you open the generated assembly using JustDecompile, as shown in Figure 34-5, you can see that the GenerateMagicNumber method has been renamed, along with the input parameters. In addition, the namespace hierarchy has been removed, and classes have been renamed. Although this is a rather simple example, you can see how numerous methods with similar, nonintuitive names could cause confusion and make the source code difficult to understand when decompiled.

The previous example obfuscated the public method of a class, which is fine if the method will be called only from assemblies obfuscated along with the one containing the class definition. However, if this were a class library or API that will be referenced by other unobfuscated applications, you would see a list of classes that have no apparent structure, relationship, or even naming convention. This would make working with this assembly difficult. Luckily, Dotfuscator enables you to control what is renamed during obfuscation. Before going ahead, you need to refactor the code slightly to pull the functionality out of the public method. If you didn’t do this and you excluded this method from being renamed, your secret algorithm would not be obfuscated. By separating the logic into another method, you can obfuscate that while keeping the public interface unchanged. The refactored code would look like the following:

C#

namespace ObfuscationSample
{
    public class MathematicalGenius
    {
        public static Int32 GenerateMagicNumber(Int32 age, Int32 height)
        {
            return SecretGenerateMagicNumber(age, height);
        }

        private static Int32 SecretGenerateMagicNumber(Int32 age, Int32 height)
        {
            return (age * height) + DateTime.Now.DayOfYear;
        }
    }
}

VB

Namespace ObfuscationSample
    Public Class MathematicalGenius
        Public Shared Function GenerateMagicNumber(ByVal age As Integer, _
                                                ByVal height As Integer) As Integer
            Return SecretGenerateMagicNumber(age, height)
        End Function

        Private Shared Function SecretGenerateMagicNumber(ByVal age As Integer, _
                                                ByVal height As Integer) As Integer
            Return (age * height) + Today.DayOfWeek
        End Function
    End Class
End Namespace

After rebuilding the application, you need to reopen the Dotfuscator project by selecting it from the Recent Projects list. You have several different ways to selectively apply obfuscation to an assembly. First, you can enable Library mode on specific assemblies by selecting the appropriate check box on the Inputs screen (see Figure 34-4). This has the effect of keeping the namespace, class name, and all public properties and methods intact, while renaming all private methods and variables. Second, you can manually select which elements should not be renamed from within Dotfuscator. To do this, open the Renaming item from the navigation tree, as shown in Figure 34-6.

The Renaming dialog opens on the Exclusions tab where you can see the familiar tree view of your assembly with the attributes, namespaces, types, and methods listed. As the name of the tab suggests, this tree enables you to exclude certain elements from being renamed. The GenerateMagicNumber method (refer to Figure 34-6), as well as the class that it is contained in, is excluded. (Otherwise, you would have ended up with something like b.GenerateMagicNumber, where b is the renamed class.) In addition to explicitly choosing which elements will be excluded, you can also define custom rules that can include regular expressions.

After you build the Dotfuscator project, click the Results item in the navigation tree. This screen shows the actions that Dotfuscator performed during obfuscation. The new name of each class, property, and method displays as a subnode under each renamed element in the tree. You can see that the MathematicalGenius class and the GenerateMagicNumber method have not been renamed, as shown in Figure 34-7.

The SecretGenerateMagicNumber method has been renamed to a, as indicated by the subnode with the Dotfuscator icon.

Obfuscation Attributes

In the previous example you saw how to choose which types and methods to obfuscate within Dotfuscator. Of course, if you were to start using a different obfuscating product, you must configure it to exclude the public members. It would be more convenient to annotate your code with attributes indicating whether a symbol should be obfuscated. You can do this by using the Obfuscation and ObfuscationAssemblyAttribute attributes from the System.Reflection namespace.

The default behavior in Dotfuscator is to override exclusions specified in the project with the settings specified by any obfuscation attributes. Refer to Figure 34-4 to see a series of check boxes for each assembly added to the project, of which one is Honor Obfuscation Attributes. You can change the default behavior so that any exclusions set within the project take precedence by unchecking the Honor Obfuscation Attributes option on a per-assembly basis.

Words of Caution

In a couple of places it is worth considering what can happen when obfuscation — or more precisely, renaming — occurs, and how it can affect the workings of the application.

Strongly Named Assemblies

One of the purposes behind giving an assembly a strong name is that it prevents the assembly from being tampered with. Unfortunately, obfuscating relies on taking an existing assembly and modifying the names and code flow before generating a new assembly. This would mean that the assembly no longer has a valid strong name. To allow obfuscation to occur, you need to delay signing of your assembly by checking the Delay Sign Only check box on the Signing tab of the Project Properties window, as shown in Figure 34-8.

After building the assembly, you can then obfuscate it in the normal way. The only difference is that after obfuscating you need to sign the obfuscated assembly, which you can do manually using the Strong Name utility, as shown in this example:

sn -R ObfuscationSample.exe ObfuscationKey.snk

Tamper Defense

Tamper defense provides a way for you to detect when your applications have been modified in an unauthorized manner. Whereas obfuscation is a preventative control designed to reduce the risks that stem from unauthorized reverse engineering, tamper defense is a detective control designed to reduce the risks that stem from unauthorized modification of your managed assemblies. The pairing of preventative and detective controls is a widely accepted risk management pattern, for example, fire prevention and detection.

Tamper defense is applied on a per-method basis, and tamper detection is performed at run time when a protected method is invoked.

To add tamper defense to your application, select the Analytics node under the Configuration Options portion of the navigation menu and then select the Attributes tab. You see a tree that contains the assemblies you have added to the Dotfuscator project with a hierarchy of the classes and methods that each assembly contains. Navigate to the HiddenGenius.GenerateMagicNumber function, right-click it, and select Add Attribute. This displays the list of available Dotfuscator attributes, as shown in Figure 34-9.

Select the InsertTamperCheckAttribute attribute, and click OK. The attribute is added to the selected method. You can now build the Dotfuscator project to inject the tamper defense functionality into your application.

To help you test the tamper defense functionality, Dotfuscator ships with a simple utility that simulates tampering of an assembly. Called TamperTester, you can find this utility in the same directory in which Dotfuscator is installed (by default at C:Program FilesMicrosoft Visual Studio 15.0PreEmptive SolutionsDotfuscator and Analytics Community Edition). This should be run from the command line with the name of the assembly and the output folder as arguments:

tampertester ObfuscationSample.exe c:	amperedapps

By default, your application immediately exits if the method has been tampered with. You can optionally configure Dotfuscator to generate a notification message to an endpoint of your choosing. The commercial edition of Dotfuscator includes two primary extensions to the CE version; it enables you to add a custom handler to be executed when tampering is detected, supporting a custom real-time tamper defense in lieu of the default exit behavior; and PreEmptive Solutions offers a notification service that accepts tamper alerts and automatically notifies your organization as an incident response.

Application Instrumentation and Analytics

As a developer, the goal is to build an application that meets your users’ needs while reducing any issues that might be encountered. To meet this aim, it is important to be able to gain an understanding of what your users are experiencing, both good and bad, in your application. That’s where analytics come into play. Analytics are capable of providing a full view of your application. This includes not only any exceptions or other unexpected behavior, but also which parts of the application are being used.

For analytics to be useful, there needs to be a mechanism to both capture and report on them. As part of the Azure platform, Microsoft provides the Application Insights platform. Application Insights is not new; it was part of Visual Studio Online. Now it has been integrated into Azure and is available through the Azure portal.

For your application to participate, you need to instrument your application appropriately. Fortunately, Visual Studio 2017 includes a couple of tools to make this easier.

Depending on the type of project that you created, the Application Insights SDK is automatically included in your reference list. For existing projects (and, in general, Application Insights is anticipated to be used with web or UWP applications), you can add the Application Insights SDK by selecting Add Application Insights from the context menu for the project from within Solution Explorer. Once the SDK is available, you’ll need to configure Application Insights. Again, through the context menu in the project, select Configure Application Insights. This shows a screen similar to what you see in Figure 34-10.

One you have logged in to your Azure subscription, there are two additional options available to you. If your account is associated with multiple Azure subscriptions, select the subscription you want used for this project. Also, you can specify the resource to which the Application Insights telemetry should be sent. If you are creating a new resource, clicking the Configure Settings link reveals the dialog that appears in Figure 34-11. Through this, you can specify the Resource Group (which corresponds to the region in which the telemetry will be gathered), the name of the resource, and the region in which the service will be hosted.

If you look at the difference that adding Application Insights to your project made, you’ll find that it’s not significant. There is a configuration file (called ApplicationInsights.config) that contains information about the telemetry modules and the classes that are used to generate the data. It also includes the secret key that is used to communicate with your Azure account.

The second addition is dependent on the type of application that you created. In the example, it was an ASP.NET MVC Web application. To allow for telemetry to be sent, a small JavaScript script is added to the _Layout.cshml file. This script instantiates an appInsights object and invokes the tracePageView method. This sends a page view event to the Application Insights resource.

For different types of applications, the mechanism for sending the telemetry details will change. The ApplicationInsights.config file is consistent across the different projects. However, whereas ASP.NET web applications have an obvious place to put the tracePageView call, that is not the case with a Universal Windows Platform application. Instead, these applications create a property named TelemetryClient at the Application level. Then you can instrument your application with calls to the TrackPageView, TrackEvent, or other methods to push different metrics from your application to the Application Insights resource.