Protecting your Xamarin Applications with Dotfuscator
This is a translation of a story by Joe Sewell, a developer from the Dotfuscator team, at PreEmptiveSolutions.
Let's be honest: releasing a library, desktop application, or mobile application can be a bitter experience. As soon as you put your program in the public domain for the whole world, you will to some extent lose control over how it is used. In particular, developers often face the threat of reverse engineering.
On many platforms and in many languages, code obfuscation tools are a well-known defense against reverse engineering. For example, if you are an Android developer, you may already be using ProGuard to shorten and obfuscate Java code.
Xamarin developers now have access to the same type of protection across all major families of mobile devices, from Android and iOS to Universal Windows (UWP). The tool for working is called Dotfuscator, the Community Edition of which is available in Visual Studio.
Today we look at how obfuscation can protect a Xamarin application. Android from reverse engineering, and how you can apply the same protection to your own Xamarin apps in just a few simple steps.
Obfuscation is the process by which compiled application code is transformed into functionally identical code that is more difficult to reverse engineer. This is usually done using an automatic obfuscation tool or an obfuscator. The following is a simple example to illustrate how code obfuscation protects applications from reverse engineering.
Consider the following C # method in the source code for the game Xamarin.Android:
When the developers of this game are ready to embed it in the device or upload it to the application store, they compile the source code into libraries and then pack these libraries into an application package. In this example, the developers packaged the libraries into an APK file for distribution on Android devices.
However, as soon as the application is uploaded to the application store, the “bad person” can easily get and open the APK, generating a decompiled code that is almost identical to the original code in the original:
Please note that the type, method and identifiers of the elements are the same as in source code, even if code elements are usually not available outside the project (for example, are labeled internal ("internal")). Also note that the flow of general method commands, for example, the order of the if statements (“if”), is clearly visible.
If, before the distribution of the APK, developers already launched libraries through the Dotfuscator Community Edition, the results of the reverse development will be different:
The code is protected by obfuscation when renaming - the main form of obfuscation of the code. Properties with simple names, for example,
Now let's move on to how to integrate obfuscation when renaming the Community Edition version of Dotfuscator into the build process of your Xamarin application. As an example, we will use the Xamarin.Android application mentioned in the previous section. You can repeat everything with your own Xamarin app, including iOS and UWP versions.
We will use Dotfuscator PreEmptive Protection, an obfuscator and .NET protection tool that now also supports Xamarin.
Note: These steps assume that you are developing your application in VisualStudio 2017 for Windows.
First of all, you need to install Dotfuscator on your development machine. Since we use the Dotfuscator command line interface, you will also need to register your copy and record the path to the interface.
1. Go to the Dotfuscator Downloads page on the PreEmptive Solutions website.
2. Download the latest version of Dotfuscator Community Edition (CE) for Visual Studio 2017.
3. Open the VSIX file that you downloaded and follow the instructions.
4. Open Visual Studio 2017 and select Tools - PreEmptive Protection - Dotfuscator to launch the Dotfuscator Community Edition user interface
5. You will need to register your copy of Dotfuscator before you can use the command line interface. Dotfuscator will ask you to register when you open it for the first time; follow these instructions.
6. You need to know the path to the command line interface in order to later configure assembly integration. To find this way:
To simplify the integration process, the Dotfuscator team created an MSBuild targets target file that your Xamarin projects can reference. You can download it here.
Save the file PreEmptive.Dotfuscator.Xamarin.targets to the directory with your solution, under version control.
Modify the project to use assembly integration. Next, you need to modify the project file for the project in Visual Studio that you want to obfuscate.
Now you can build the application with Dotfuscator protection. To do this:
For more information on continuing development with established obfuscation, see “Continuing Development” in the Dotfuscator User Guide.
There are some cases where an application assumes that the name of a code element at compile time will be the same as during application operation. This is particularly true for XAMarin-based XAML and reflection applications. Renaming obfuscation can violate this premise and cause the application to behave differently after obfuscation.
Although newer versions of Dotfuscator are more capable of working with such scripts automatically, in some cases manual configuration may be required. For instructions and examples, see the “Identify Exclusions from Renaming” page in the Dotfuscator User Guide.
Instead of the free version of Dotfuscator Community Edition, you can also obfuscate your Xamarin apps in Dotfuscator Professional Edition. Professional Edition is licensed for use in commercial products; free probes are available on request.
To see the difference between the Community and Professional versions, consider the example game mentioned above. If developers passed their directories through Dotfuscator Professional Edition instead of Community Edition, the reverse development results would look something like this:
In addition to obfuscation by renaming, this code is also obfuscated by changing the control flow. The source code operators are interspersed with “perception” blocks that are difficult to read in seemingly arbitrary order, which greatly complicates the execution of commands. This and other advanced forms of obfuscation are exclusively found in the Dotfuscator Professional Edition.
In this post, we saw how you can use Dotfuscator to protect Xamarin directories and applications from reverse engineering. Although we used an Android-based application as an example, the same steps can be performed for projects based on iOS and UWP, so you can protect your application no matter what platform it runs on.
For more information on how to protect Xamarin projects with Dotfuscator, see the Xamarin page in the Dotfuscator User Guide. There you will also find a git repository demonstrating how to integrate Dotfuscator into the Xamarin app for all three platforms.
Let's be honest: releasing a library, desktop application, or mobile application can be a bitter experience. As soon as you put your program in the public domain for the whole world, you will to some extent lose control over how it is used. In particular, developers often face the threat of reverse engineering.
On many platforms and in many languages, code obfuscation tools are a well-known defense against reverse engineering. For example, if you are an Android developer, you may already be using ProGuard to shorten and obfuscate Java code.
Xamarin developers now have access to the same type of protection across all major families of mobile devices, from Android and iOS to Universal Windows (UWP). The tool for working is called Dotfuscator, the Community Edition of which is available in Visual Studio.
Today we look at how obfuscation can protect a Xamarin application. Android from reverse engineering, and how you can apply the same protection to your own Xamarin apps in just a few simple steps.
How obfuscation protects applications
Obfuscation is the process by which compiled application code is transformed into functionally identical code that is more difficult to reverse engineer. This is usually done using an automatic obfuscation tool or an obfuscator. The following is a simple example to illustrate how code obfuscation protects applications from reverse engineering.
Consider the following C # method in the source code for the game Xamarin.Android:
When the developers of this game are ready to embed it in the device or upload it to the application store, they compile the source code into libraries and then pack these libraries into an application package. In this example, the developers packaged the libraries into an APK file for distribution on Android devices.
However, as soon as the application is uploaded to the application store, the “bad person” can easily get and open the APK, generating a decompiled code that is almost identical to the original code in the original:
Please note that the type, method and identifiers of the elements are the same as in source code, even if code elements are usually not available outside the project (for example, are labeled internal ("internal")). Also note that the flow of general method commands, for example, the order of the if statements (“if”), is clearly visible.
If, before the distribution of the APK, developers already launched libraries through the Dotfuscator Community Edition, the results of the reverse development will be different:
The code is protected by obfuscation when renaming - the main form of obfuscation of the code. Properties with simple names, for example,
ArrowsOnHandare replaced by naming methods that are not intuitive, such as b and g. Other code elements are also similarly renamed. This makes reading and generating decompiled code very difficult, since there are no important contextual keys provided by names.How to subject your application to obfuscation
Now let's move on to how to integrate obfuscation when renaming the Community Edition version of Dotfuscator into the build process of your Xamarin application. As an example, we will use the Xamarin.Android application mentioned in the previous section. You can repeat everything with your own Xamarin app, including iOS and UWP versions.
We will use Dotfuscator PreEmptive Protection, an obfuscator and .NET protection tool that now also supports Xamarin.
Note: These steps assume that you are developing your application in VisualStudio 2017 for Windows.
Install and configure Dotfuscator
First of all, you need to install Dotfuscator on your development machine. Since we use the Dotfuscator command line interface, you will also need to register your copy and record the path to the interface.
To install and configure Dotfuscator:
1. Go to the Dotfuscator Downloads page on the PreEmptive Solutions website.
2. Download the latest version of Dotfuscator Community Edition (CE) for Visual Studio 2017.
- Although Dotfuscator is included with Visual Studio, PreEmptive Solutions periodically releases important Dotfuscator updates between Visual Studio update releases. Installing Dotfuscator in this way ensures that you get the latest version.
3. Open the VSIX file that you downloaded and follow the instructions.
4. Open Visual Studio 2017 and select Tools - PreEmptive Protection - Dotfuscator to launch the Dotfuscator Community Edition user interface
5. You will need to register your copy of Dotfuscator before you can use the command line interface. Dotfuscator will ask you to register when you open it for the first time; follow these instructions.
- To register later (register later) or check your registration status, find the text Registration status in the upper right corner of the Dotfuscator Community Edition start page.
6. You need to know the path to the command line interface in order to later configure assembly integration. To find this way:
- Change to the installation directory for your installation of Visual Studio 2017. For example, the default installation directory for Visual Studio 2017 Professional is C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Professional.
- This directory contains the Dotfuscator Community Edition extension files in * \ Common7 \ IDE \ Extensions \ PreEmptiveSolutions \ DotfuscatorCE.
- The dotfuscatorCLI.exe file is the Dotfuscator Community Edition command line interface.
- Record the full path to the .exe file for future reference.
Download assembly integration file
To simplify the integration process, the Dotfuscator team created an MSBuild targets target file that your Xamarin projects can reference. You can download it here.
Save the file PreEmptive.Dotfuscator.Xamarin.targets to the directory with your solution, under version control.
Modify the project to use assembly integration. Next, you need to modify the project file for the project in Visual Studio that you want to obfuscate.
To modify your project file:
- Determine which project build configurations you want to protect. Usually these are all configurations except Debug configurations (debugging). For more detailed instructions, see the “Choose What to Protect” section of the full documentation.
- Open the project file in a text editor. An example project file for C # would be `YourProjectName.csproj`.
- Determine the relative path from this file to the assembly integration file that you downloaded.
- Import the assembly integration file by adding the following line to the file immediately before the / Project fragment:
- Import Project = ".. \ .. \ PreEmptive.Dotfuscator.Xamarin.targets" /, replacing the relative path defined in Step 3.
- Under the PropertyGroup fragment without the Condition attribute, add the following fragments:
- DotfuscatorXamarinCliPathC: \ pathto \ dotfuscatorCLI.exe / DotfuscatorXamarinCliPath, replacing the full path to the Dotfuscator Community Edition command line interface that you wrote down earlier.
- DotfuscatorXamarinConfigFileNameDotfuscatorConfig.xml / DotfuscatorXamarinConfigFileName
- DotfuscatorXamarinGenerateNewConfigFiletrue / DotfuscatorXamarinGenerateNewConfigFile
- For each assembly integration configuration selected in Step 1, find the corresponding PropertyGroup and add the following snippet:
- DotfuscatorXamarinEnabledtrue / DotfuscatorXamarinEnabled
- After the last fragment of ItemGroup, add the following:
- ItemGroupNone Include = "DotfuscatorConfig.xml" // ItemGroup
- Save and close the file.
Build the application
Now you can build the application with Dotfuscator protection. To do this:
- Open or reload your project in Visual Studio
- Select the solution assembly configuration that verifies the project assembly configuration that you want to protect
- Build a project
- After this first build, determine if the build result contains the following lines for the Dotfuscator:
- Adding the DotfuscatorConfig.xml file to your project. This is the Dotfuscator configuration file that tells Dotfuscator how to obfuscate your code. It is recommended to check it in the version control system.
- In the directory and file structure, find the new DotfuscatorReports directory in your project directory. This directory contains information on how the obfuscation of the project went, including information on how to deploy the renaming process back. You should process this directory similar to the build result and make sure that the version control system ignores it.
- Test your application. If you see errors, you may need to further configure Dotfuscator to get the correct behavior, see the next section for reference.
- Continue to develop your application, building it as usual. When Dotfuscator is used during build, the build result will contain the following lines:
For more information on continuing development with established obfuscation, see “Continuing Development” in the Dotfuscator User Guide.
Rename Configuration
There are some cases where an application assumes that the name of a code element at compile time will be the same as during application operation. This is particularly true for XAMarin-based XAML and reflection applications. Renaming obfuscation can violate this premise and cause the application to behave differently after obfuscation.
Although newer versions of Dotfuscator are more capable of working with such scripts automatically, in some cases manual configuration may be required. For instructions and examples, see the “Identify Exclusions from Renaming” page in the Dotfuscator User Guide.
Advanced Obfuscation
Instead of the free version of Dotfuscator Community Edition, you can also obfuscate your Xamarin apps in Dotfuscator Professional Edition. Professional Edition is licensed for use in commercial products; free probes are available on request.
To see the difference between the Community and Professional versions, consider the example game mentioned above. If developers passed their directories through Dotfuscator Professional Edition instead of Community Edition, the reverse development results would look something like this:
In addition to obfuscation by renaming, this code is also obfuscated by changing the control flow. The source code operators are interspersed with “perception” blocks that are difficult to read in seemingly arbitrary order, which greatly complicates the execution of commands. This and other advanced forms of obfuscation are exclusively found in the Dotfuscator Professional Edition.
findings
In this post, we saw how you can use Dotfuscator to protect Xamarin directories and applications from reverse engineering. Although we used an Android-based application as an example, the same steps can be performed for projects based on iOS and UWP, so you can protect your application no matter what platform it runs on.
For more information on how to protect Xamarin projects with Dotfuscator, see the Xamarin page in the Dotfuscator User Guide. There you will also find a git repository demonstrating how to integrate Dotfuscator into the Xamarin app for all three platforms.