Xamarin Applications and Dotfuscator

August 14, 2015 10928 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>

The Secret to Effective In-App Protection

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.

If you don’t follow application security closely, you might think of application obfuscation and symbol renaming as being synonymous – and with good reason. Many platforms and languages, like .NET, Java, and JavaScript have popular obfuscators that do little else--our own Dotfuscator Community Edition for .NET and ProGuard for Java are good examples. However, obfuscation is far more than symbol renaming – and in-app protection is far more than obfuscation. Much of this expansion has been driven by new security requirements, shifting attack vectors, the rise of mobile and IoT computing and, lastly, the growing recognition inside regulations and legislation of the exposure that can result from inadequately protected software.

PreEmptive has partnered with Microsoft for 16 years and we’ve been involved with .NET since before version 1.0 shipped. From that perspective, it’s hard for us to pinpoint a time where the energy and enthusiasm in the .NET community has been higher than it is now. Over the past few years, Microsoft has put together the annual .NET Conf, completely online with viewers, participants, and local events all over the world. The event is virtual and streamed live over three days.

The big news at this year's .NET Conf was the launch of .NET Core 3, the next step in the continued evolution of .NET. .NET Core 3 is a huge effort, with many moving parts, and Microsoft announced many related releases to support it. Highlights for us included:

Search for lockpicking and you’ll see that there’s no shortage of suppliers ready to serve locksmiths and hobbyists, each community having a perfectly legitimate need. Is there any reason to believe that burglars don’t shop the same sites?

Hackers are developers and they have a long history of enthusiastically embracing and adapting development (and DevOps) innovations to speed their work, extend their reach, and ship software – the only difference is that they’re more likely to use those development tools and platforms on YOUR software rather than on their own. Static code analysis tools, debuggers, and even public bug tracking databases are all go-to hacker resources.

Can you tell the difference? Exception or the norm?

Of course, everyone is “for security” in principle. The hard question that each organization has to answer for themselves is “how much is enough?” Over-engineering is (by definition) excessive, and over-engineering application security can, in fact, be devastating as overly-complex algorithms, architectures and processes can compromise user experience, degrade performance and slow development velocity. On the other hand, punishment is swift for organizations that cut corners and do not effectively secure their applications, their data and, most importantly their users and business stakeholders. Finding and maintaining that balance can be time consuming and, because you can never be sure you’ve gotten it exactly right, it can also be a thankless job.

Xamarin Applications and Dotfuscator

Obfuscating Xamarin Applications

Example Dotfuscator File

The Secret to Effective In-App Protection

Symbol Renaming: App Security’s Maginot Line?

Highlights from .NET Conf 2019

Tools don’t hack apps, hackers do: Securing Android apps against Frida

Trusted Computing: Panacea or Magical Thinking?

Can you tell the difference? Exception or the norm?

Latest Blog Posts

The Secret to Effective In-App Protection

Symbol Renaming: App Security’s Maginot Line?

Highlights from .NET Conf 2019

Tools don’t hack apps, hackers do: Securing Android apps against Frida

Trusted Computing: Panacea or Magical Thinking?

Twitter