Xamarin Applications and Dotfuscator

August 14, 2015 10570 Views Michael Letterle

Note: this document is deprecated. Please see Obfuscating Xamarin Applications with Dotfuscator for up to date instructions on obfuscating Xamarin applications.

We are often asked if Dotfuscator supports protecting Xamarin applications. Given that Xamarin applications are based on Mono, a .NET compatible runtime, the answer is yes! However, applying obfuscation transformations to Mono assemblies is only one half of an effective obfuscation solution; the other half is making sure that the configuration and automation of the obfuscation process itself is straightforward and stable. We've been working hard to make Dotfuscator more Mono friendly lately, specifically with an eye towards improving Xamarin compatibility.

There are many different methods you could use to get your Xamarin assemblies processed by Dotfuscator and then packaged for deployment to devices. The steps outlined below should be the easiest to implement, while giving you a reasonable expectation of protection. Note that the below instructions are specifically for Android and iOS projects. For Windows Phone projects, we recommend building the store-ready XAP first and then running it through Dotfuscator as normal.

Obfuscating Xamarin Applications

The most consistent and secure method of obfuscating your Xamarin apps is to integrate Dotfuscator into the MSBuild pipeline. This allows you to obfuscate your project using standard build tools, and lets you test your obfuscation using Xamarin's built-in debugger workflow. In order for the obfuscated outputs to be processed properly by Xamarin, Dotfuscator's "Mono Compatible" global setting should be set to "Yes" and a project property of "controlflow.disabled_manglers" with a value of "ILSpyBreaker" should be added.

Xamarin's platform specific utilities use reflection heavily, so as a starting point it is recommended to simply exclude the input assemblies from renaming (while still allowing control-flow obfuscation). Once that is working, you can then enable renaming if desired, and take the time to determine the minimum amount of exclusions needed for your application.

In each Android or iOS csproj file you should then add a reference to the Dotfuscate task and a target for AfterBuild, like so:

<UsingTask TaskName="PreEmptive.Tasks.Dotfuscate" AssemblyFile="$(MSBuildExtensionsPath)\PreEmptive\Dotfuscator\4\PreEmptive.Dotfuscator.Tasks.dll" />

////SNIP////

<Target Name="AfterBuild">
    <PropertyGroup>
        <DotfuscatorProperties>
            <OutDir>$(OutDir)</OutDir>
            <OutputPath>$(OutputPath)</OutputPath>
        </DotfuscatorProperties>
    </PropertyGroup>
    <Dotfuscate ConfigPath="Obfuscate.Android.xml" Properties="$(DotfuscatorProperties)"/>
  </Target>

Notice that we are passing in certain properties from the build process to the Dotfuscator process. Specifically OutDir and OutPath. By using project properties with default values we can specify paths in the Dotfuscator project file to allow us to configure the project using the stand-alone Dotfuscator UI, while having the build process handle where they actually are at build time.

In order for the Xamarin platform specific build process to properly find the obfuscated assemblies, they have to be copied back into the original assembly locations after obfuscation. Android has an additional restriction in that the original obfuscated PCL must be copied back to its project specific location as well. The easiest way to accomplish this is to have a post-build event in the Dotfuscator project to do the copying:

Adding a "ObRelease" and/or "ObDebug" configuration can be useful to only obfuscate when explicitly needed and wanted. This can be accomplished by adding a Condition property to the Dotfuscate element in the csproj (for instance: Condition=" '$(Configuration)' == 'ObRelease' "). Note that when adding a new "Release" config for Android, one needs to disable "Use Shared Runtime" and "Enable developer instrumentation" in the Android Options under the Packaging tab.

Once these steps are complete, you should be able to see Dotfuscator's build output during your builds in either Visual Studio or Xamarin Studio:

This will produce output packages containing obfuscated assemblies ready for deployment and testing!

Example Dotfuscator File

This is a fully configured Dotfuscator file for an Android project as described in this post. Note especially the use of properties as well as the post-build event.


<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE dotfuscator SYSTEM "https://www.preemptive.com/dotfuscator/dtd/dotfuscator_v2.3.dtd">
<dotfuscator version="2.3">
  <propertylist>
    <property name="controlflow.disabled_manglers" value="ILSpyBreaker" />
    <property name="OutDir" value="C:\Users\ObfuscationUser\Documents\Visual Studio 2015\Projects\ObXFormsP\ObXFormsP\ObXFormsP.Droid\bin\Release" />
    <property name="OutputPath" value="\bin\Release" />
  </propertylist>
  <global>
    <option>monocompat</option>
    <option>verbose</option>
  </global>
  <input>
    <loadpaths />
    <asmlist>
      <inputassembly refid="52f75f71-2d9e-4e8a-911b-a24e252f60c6">
        <option>honoroas</option>
        <option>stripoa</option>
        <option>transformxaml</option>
        <file dir="${OutDir}" name="ObXFormsP.dll" />
      </inputassembly>
      <inputassembly refid="840c659d-7536-4ad6-9040-2f9c520a8968">
        <option>honoroas</option>
        <option>stripoa</option>
        <option>transformxaml</option>
        <file dir="${OutDir}" name="ObXFormsP.Droid.dll" />
      </inputassembly>
    </asmlist>
  </input>
  <output>
    <file dir="${configdir}\Dotfuscated" />
  </output>
  <renaming>
    <option>xmlserialization</option>
    <excludelist>
      <assembly>
        <file dir="${OutDir}" name="ObXFormsP.Droid.dll" />
      </assembly>
      <type name="ObXFormsP.App" />
    </excludelist>
    <mapping>
      <mapoutput overwrite="false">
        <file dir="${configdir}\Dotfuscated" name="Map.xml" />
      </mapoutput>
    </mapping>
    <referencerulelist>
      <referencerule rulekey="{6655B10A-FD58-462d-8D4F-5B1316DFF0FF}" />
      <referencerule rulekey="{7D9C8B02-2383-420f-8740-A9760394C2C1}" />
      <referencerule rulekey="{229FD6F8-5BCC-427b-8F72-A7A413ECDF1A}" />
      <referencerule rulekey="{2B7E7C8C-A39A-4db8-9DFC-6AFD38509061}" />
      <referencerule rulekey="{494EA3BA-B947-44B5-BEE8-A11CC85AAF9B}" />
      <referencerule rulekey="{89769974-93E9-4e71-8D92-BE70E855ACFC}" />
      <referencerule rulekey="{4D81E604-A545-4631-8B6D-C3735F793F80}" />
    </referencerulelist>
  </renaming>
  <controlflow level="high" />
  <eventlist>
    <event type="postbuild">
      <option>buildsuccessful</option>
      <program>
        <file dir="c:\windows\system32" name="cmd.exe" />
        <environment commandline="/c copy /y &quot;${configdir}\Dotfuscated\*.dll&quot; &quot;${OutDir}&quot; &amp; copy /y &quot;${configdir}\Dotfuscated\ObxFormsP.dll&quot; &quot;${configdir}\..\ObXFormsP\${OutputPath}&quot;" workingdir="" />
      </program>
    </event>
  </eventlist>
  <sos mergeruntime="true">
    <option>version:v4</option>
    <option>dontsendtamper</option>
  </sos>
  <smartobfuscation>
    <smartobfuscationreport verbosity="all" overwrite="false" />
  </smartobfuscation>
</dotfuscator>

Latest NIST publication reinforces Developer Obligations (and liability)

On June 11, NIST released Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework. While a solid piece of work in its own right, this document is noteworthy because it stands as one more proof point - in an already long list of proof points, that development processes, the developers themselves, and the organizations they belong to, ALL share some degree of responsibility (liability) for:

Untrusted Environments, Valuable Apps? Put the Protection in the App.

IT environments are evolving. Disappearing are the days of in-house, fixed-endpoint, limited access server stacks — replaced instead by a combination of private and public cloud solutions, mobile applications and IoT devices.

As noted by research firm IDC, public cloud spending now outpaces all other IT infrastructure with a growth rate topping 10 percent year-over-year, while Statista reports that users downloaded more than 178 billion apps in 2017 alone — and are on track to break 250 billion over the next few years.

What does this mean for organizations? That application environments are quickly moving beyond the purview of in-house IT, exposing both apps and network services to steadily growing risk. It creates a paradox: Companies can’t deny the benefits of third-party environments and application partnerships, but also can’t ignore the threat of app and data compromise or reverse-engineering and tampering.

In a recent developer survey, Xamarin.Android developers were 50% less likely to have included rooted device detection or anti-tamper prevention as their Java Android peers were. Yet, both sets of apps are being deployed through the same marketplaces onto the same devices and are governed by the same regulations (PCI, GDPR, HIPAA to name just a few that expect these kinds of controls).

Why are more Xamarin.Android apps going unprotected?

I recently had the opportunity to sit down with Sebastian Holst, PreEmptive’s Chief Strategy Officer, to talk about his most recent trip to Capitol Hill where the topic of the day was copyright protection for small businesses – and for development shops in particular.

The life of a security architect is rarely simple. Assessing, defending and improving corporate networks requires thorough knowledge of industry best practices designed to secure critical data, combined with real-world understanding of hacker tricks and tactics meant to undermine this purpose.

As noted by the InfoSec Institute, this is an in-demand job that often comes with high expectations, odd hours and the need for constant professional evolution to stay ahead of cybercriminal threats. Complicating matters is the breakneck pace of technological advancement. The rapid rise of cloud deployments, mobile applications and IoT devices can make even best-laid security strategies seem like flies in amber — hopelessly out-of-date and effectively immobile.

Here’s a look at what’s really bugging security architects — and how they can break the mold of static security to combat emerging threats.

Xamarin Applications and Dotfuscator

Obfuscating Xamarin Applications

Example Dotfuscator File

Latest NIST publication reinforces Developer Obligations (and liability)

Put the Protection in the App

Untrusted Environments, Valuable Apps? Put the Protection in the App.

Are Xamarin.Android app users at risk?

Changes are coming for US Copyright – Should Developers Even Care?

Fly in Amber: What’s Bugging Infosec Architects?

Latest Blog Posts

Latest NIST publication reinforces Developer Obligations (and liability)

Put the Protection in the App

Are Xamarin.Android app users at risk?

Changes are coming for US Copyright – Should Developers Even Care?

Fly in Amber: What’s Bugging Infosec Architects?

Twitter