Xamarin Applications and Dotfuscator

August 14, 2015 12045 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 Blog Posts

No Contact Normal: Solving the Payment Security Gap

The coronavirus crisis is changing human behavior. From the persistent need for social distancing to the potentially permanent adoption of work-from-home mandates, the “new normal” is uncharted territory.

But the growing priority of public health also has knock-on effects in other fields, such as credit and debit payments. While the United Stated has historically lagged behind other countries such as Canada, the United Kingdom and Australia when it comes to the adoption of contactless card transactions, the demand for physical distance now trumps the functional familiarity of swipe-and-signature or chip-and-PIN interactions.

Facilitating “no contact normalcy”, the PCI Security Standards Council (PCI SSC) includes guidance for both commercial deployments and software applications to help solve potential payment security gaps. Here’s what you need to know.

Localization is often a key ingredient when building Xamarin Forms applications with a global audience. There are different ways to approach app localization, but most of these leverage the built-in tools provided by the .NET Framework. These include RESX files to configure localized strings and an auto-generated resource class which provides strongly-typed access to the string translation at runtime. This mechanism has been available since .NET 1.1, and is used for localization of WinForm, WPF, ASP.NET, and Xamarin applications.

In the months since we released the Dotfuscator 6 beta, we’ve been hard at work finishing the feature set, fixing issues, and putting on the final touches in preparation for the full release. Now, we are happy to announce the full availability of Dotfuscator 6!

It’s official. COVID-19, more commonly known as the Coronavirus, has been declared a global pandemic by the World Health Organization (WHO) with hundreds of thousands of cases worldwide. In the United States, restrictions are ramping up as case numbers soar — New York governor Andrew Cuomo has ordered all nonessential workers to stay home, and my own state’s governor Mike DeWine has issued a statewide shelter-in-place order.

Along with disruptions to daily life, the expanding impact of COVID-19 has forced businesses to rapidly pivot and adopt remote-work models — even if they have no experience with mobile connections and on-demand collaboration. The result is a surge in remote everything, from team chats to primary school education to project management and even healthcare delivery. See my previous blog on our customer commitment during the age of Coronavirus.

And while efforts to bridge the digital divide are having a positive impact for both workplace productivity and the mental health of those in isolation, there’s a potential pitfall: Cybersecurity. As noted by CNBC, there’s already been a significant uptick in scam and phishing emails — but what happens if malicious actors breach critical apps and services?

At PreEmptive, we’re closely following the evolving Coronavirus (COVID-19) public health emergency, and our thoughts are with those affected and their families during this difficult time.

We are taking precautionary steps to continue normal operations without affecting our customers. At the same time, ensuring the health and safety of our customers, partners, and employees is our highest priority.

We have provided application protection software to the world's top organizations for more than 20 years. Although, this case is somewhat unique, it is not the first time we have been confronted with economic disruptions and uncertainties. Prior critical lessons have helped shape us into the company we are today: a robust organization with layers of contingency plans in place, a strong balance sheet, and an experienced team that values long-term relationships with our customers and partners above all else.

Xamarin Applications and Dotfuscator

Obfuscating Xamarin Applications

Example Dotfuscator File

No Contact Normal: Solving the Payment Security Gap

Protecting Localized Xamarin Forms Applications

Dotfuscator 6: The Next Era of Dotfuscator

Going the Distance — Remote Work and Effective Cybersecurity in the Age of Coronavirus

Our Commitment to Customers During the COVID-19 Outbreak

Latest Blog Posts

No Contact Normal: Solving the Payment Security Gap

Protecting JavaScript Code: The Making of JSDefender

Protecting Localized Xamarin Forms Applications

Dotfuscator 6: The Next Era of Dotfuscator

Going the Distance — Remote Work and Effective Cybersecurity in the Age of Coronavirus

Twitter