Xamarin Applications and Dotfuscator

August 14th, 2015 by Michael Letterle

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.

Screenshot of project-properties

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:

Screenshot of post-build event

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:

Screenshot of VS build output

Screenshot of Xamarin build output

This will produce output packages containing obfuscated assemblies ready for deployement 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 "http://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>

Available Exclusively to Visual Studio 2015 Users

August 13th, 2015 by Sebastian Holst

Live technical support from PreEmptive’s (world class) product support team plus an application protection white paper

The fine print… Visual Studio 2015 users who register Dotfuscator CE (it’s inside Visual Studio 2015 already) will receive immediate access to the recent white paper, Application Protection. Why bother? AND receive a credit to open one (1) support ticket with PreEmptive’s product support team any time in (you guessed it) 2015.

So, you think you just might want to protect your applications against reverse engineering and tampering sometime in the not too distance future? Perhaps inject feature monitoring? Register your copy of Dotfuscator CE NOW to

a) “bank” a credit to open a support ticket at no cost to you and

b) to download a white paper that just might give you the insight you need to answer that question about whether or not your app needs protection (and no - the answer is not always yes).

What’s the catch?
Other than the requirement that you register with your company’s domain email – and that the support credit be used before the end of 2015 – there are no catches.

How do you register? Open up Visual Studio 2015 (any version other than Express) and open Dotfuscator from the tools menu. Once you’re in Dotfuscator CE, simply click on the “Register now” link on the first screen (as illustrated below).

Fill out the form (be sure to use a valid business email address) and you’ll be sent a link and your 1 support ticket credit will be secured.

Who would use Dotfuscator CE to obfuscate their applications? We don’t know! (Unless you register - but we still don’t know what you’re doing) We do collect some anonymous usage information assuming you first opt-in (that’s distinct from the product registration) – but even then, we collect no PII (your registration on our website does NOT change this). For some early insight into how Dotfuscator CE is being used in VS 2015, check my earlier post Visual Studio 2015 Dotfuscator CE Adoption: the first 500 users.

Are these users doing anything serious with Dotfuscator CE? We can’t be sure, but what I CAN tell you is that among the first 1,000 unique users of Dotfuscator CE 2015, users were obfuscating applications with as many as 44 unique assemblies and 3,145 classes – and these Dotfuscator CE 2015 users’ applications were targeting .NET Assembly Runtime Versions 1.1, 2.0, 3.0, 3.5, 4.0, and (of course) 4.5.

What are you waiting for?
Register Dotfsucator CE 2015– we haven’t really decided when we’ll discontinue this offer of free support (seriously) so don’t wait until its too late.

Visual Studio 2015 Dotfuscator CE Adoption: The first 500 users

August 10th, 2015 by Sebastian Holst

For the first time since its launch in 2003, Dotfuscator Community Edition (CE), the no cost obfuscator included with Visual Studio, can send anonymous usage data for analysis (only after opt-in of course). …and after one week and 500 users, the resulting application analytics is already proving its worth.

Before I share some of the insights, let me also point out that the instrumentation now inside Dotfuscator CE is the very same as what Dotfuscator CE has been able to inject into .NET apps for Visual Studio users since VS2010. In other words, you can use Dotfuscator CE to achieve these same kinds of results inside your own applications.

Opt-in: of course we collect no information without a user’s informed consent. Happily, 93% of all of our users opted-in (thank you Dotfuscator CE users!). Note, Dotfuscator can inject opt-in policy enforcement too.

Visual Studio SKUs: One important data point we were keen to know was the distribution of our users across the new Visual Studio 2015 SKU’s (Enterprise, Professional and Community Edition). One important historical note: Dotfuscator CE was never included in Visual Studio Express – only the paid SKU’s. For the first time, Dotfuscator CE is now available inside the new (free) Visual Studio CE SKU – and over half of our initial users are coming from this new community. Does this suggest that our total Dotfuscator CE community will double as Visual Studio users migrate to VS 2015? We sure hope so! …and how does this tie back to user registrations? You can bet that we will be tracking this closely.

.NET Runtimes: We can infer quite a bit about the kinds of development our users are focused on by the .NET runtimes their apps target (not the .NET runtime installed with VS2015 which his 4.5 of course). While everyone is excited by the promise of modern development and universal apps, many development organizations’ current projects are still grounded in earlier .NET generations. Clearly, our application protection and analytics will need to support these runtimes for some time to come.

Equipment Manufacturers: In much the same vein, when looking at the underlying devices of these early VS2015 users, we see that they are mostly running on-prem (note, we are looking exclusively at VS2015 Dotfuscator CE users). While everyone is excited about Windows 10 and embracing Azure; early use is still mostly on-prem and, it is for this exact scenario, that our application protection and analytics support on-prem dev environments (and app deployments).

Follow links for:
A comparison of Dotfuscator CE and our other Dotfuscator versions
General information on PreEmptive Analytics

Stay tuned for more Visual Studio 2015 insights via Dotfuscator CE.

6 Signs That You May be Overdue for a Mobile Application Risk Review

June 24th, 2015 by Sebastian Holst

Every organization must ultimately make their own assessment as to the level of risk they are willing to tolerate – and mobile application risk is no exception to this rule.

Yet, given the rapidly changing mobile landscape (inside and outside of every enterprise), organizations need to plan on regular assessments of their mobile risk management policies – especially as their mobile applications grow in importance and complexity.

Here are 6 indicators that you may be overdue for a mobile application risk assessment.

  1. Earlier PC/on-premises equivalents ARE hardened and/or monitored. Perhaps these risks need to be managed on mobile devices too – or, conversely, the risks no longer need to be managed at all.
  2. Enterprise mobile apps are distributed through public app marketplaces like Google Play or iTunes. Using public marketplaces exposes apps to potentially hostile users and can be used as a platform to distribute counterfeit versions of those very same apps.
  3. Mobile apps are run within a BYOD infrastructure alongside apps and services outside of corporate control. Access to a device via third-party software can lead to a variety of malicious scenarios that include other apps (yours) installed on the same device.
  4. Mobile apps embed (or directly access) proprietary business logic. Reverse engineering is a straight forward exploit. Protect against IP theft while clearly signaling an expectation of ownership and control – which is often important during a penalty phase of a criminal and/or civil trial.
  5. Mobile apps access (or have access to) personally identifiable information (or other data governed by regulatory or compliance mandates). Understanding how services are called and data is managed within an app can readily expose potential vulnerabilities and unlock otherwise secure access to high-value services.
  6. Mobile apps play a material role in generating or managing revenue or other financial assets. High value assets or processes are a natural target for bad actors. Piracy, theft, and sabotage begins by targeting “weak links” in a revenue chain. An app is often the first target.
  7. Below is an infographic identifying leading risk categories stemming from increased reliance on mobile applications. The vulnerabilities (potential gaps) call out specific tactics often employed by bad actors; the Controls identify corresponding practices to mitigate these risks.

    The bottom half of the infographic maps the capabilities of PreEmptive Solutions Mobile Application Risk Portfolio across platforms and runtimes and up to the risk categories themselves.

    For more information on PreEmptive Solutions Enterprise Mobile Application Risk product portfolio, check out: PreEmptive Solutions’ mobile application risk management portfolio: four releases in four weeks.

PreEmptive Solutions’ Mobile Application Risk Management Portfolio: Four Releases in Four Weeks

June 23rd, 2015 by Sebastian Holst

Preventing IP theft, data loss, privacy violations, software piracy, and a growing list of other risks uniquely tied to the rise of enterprise mobile computing.

Enterprise Mobile Application Risk

Mobile computing’s impact on society, our economy and the workplace is – and will continue to be – profound; there’s nothing controversial about that.

Yet, mobile technology – like the Internet and the PC “revolutions” that came before – cannot change everything.

Governance, risk, and compliance obligations will continue to frame – for better or for worse – every organization’s operational and strategic roadmaps.

Successful organizations innovate within these frameworks – effectively embracing new technology while preserving their standards for risk management, operational transparency, scale and resilience.

It is for these organizations – our traditional enterprise client-base – that PreEmptive Solutions offers, for the first time, its Mobile Application Risk Product Portfolio. The Mobile Portfolio includes preventative and detective controls – across both mobile applications and the backend services they rely upon – in a modular and extensible format.

Enterprise Mobile Application Risk Management

The infographic below identifies leading risk categories stemming from increased reliance on mobile applications. The vulnerabilities (potential gaps) call out specific tactics often employed by bad actors; the Controls identify the corresponding practices to mitigate these risks.

The bottom half of the infographic maps the capabilities of PreEmptive Solutions Mobile Application Risk Portfolio across platforms and runtimes and up to the risk categories themselves.

What’s new?

In the past four weeks, PreEmptive Solutions has filled out its mobile application portfolio with the following:

  1. PreEmptive Protection for iOS (PPiOS) – the first enterprise obfuscation solution for iOS applications fully integrated into Xcode, application performance optimizations, and our usual live technical support and continuously improving releases. The PPiOS User Guide can be seen here.
  2. Dotfuscator Professional Update – enhancements include deeper support for Windows 8.1, Windows Phone, and Xamarin obfuscation. Stay tuned for Windows 10 updates as they become available. You can see the latest change log here.
  3. DashO Update - enhancements include support for the latest Android releases and frameworks. The DashO change log is here.
  4. PreEmptive Analytics for Linux – extending feature and exception analytics from your IoT devices to your back office servers. Contact us for immediate access to our Linux SDK.

The result is a comprehensive mobile application risk management and monitoring platform for the enterprise – extending across (and beyond) the mobile applications themselves.

Not sure if your organization needs to better manage mobile application risk? Check out 6 Signs That You May be Overdue for a Mobile Application Risk Review.