Xamarin and Dotfuscator: Do you believe in magic?

I am not a superstitious person and don’t believe in magic, but even still, I have to confess that the way Xamarin spits out Android and iOS apps (along with all the other platforms) feels magical to me. Of course, when something breaks, I am reminded all too quickly that there is no magic happening here. Xamarin has just encapsulated a lot of complex steps into a neat and tidy black box.

For me, and I bet I am not alone here, I am very happy to leave that black box alone—and I am also happy to ignore as many of the platform-specific details as I can.

Unfortunately, there are platform-specific issues that cannot be ignored when it comes to security.

For example, C# developers know all too well that .NET assemblies can be easily reverse-engineered, yielding code as complete as the original.

This is not unique to C# and .NET. Android apps are just as easily reverse-engineered (true for all of Java – not just for Android).

Fortunately, easy reverse engineering of Android is also common knowledge – as is the availability of a free obfuscator, ProGuard (like Dotfuscator CE).

Unfortunately, ProGuard can’t obfuscate Xamarin.Android apps (it can shrink them, though).

Fortunately, Dotfuscator CE (and Professional) CAN obfuscate both Xamarin.Android and Xamarin.iOS apps.

Unfortunately, (but not surprisingly), the fidelity between the original source code and the code extracted from the Xamarin.Android app is striking and clearly demonstrates that, as with all managed code, executable == source.

This particular code example was taken from the sample app used in the May MSDN Magazine article: Security – Detect and Respond to Rooted Android Devices from Xamarin Apps, highlighting a second security issue unique to Android. In Android, preventing reverse engineering is often not enough to secure your app or its data. Increasingly, standards bodies, regulators, and lawmakers are recommending and sometimes even requiring that Android apps detect and defend against risks stemming from running apps on a rooted device.

Rooting is the process of allowing users of smartphones and other devices running Android to attain privileged control (known as root access) over various Android subsystems. Rooting an Android device gives similar access to administrative (superuser) permissions. 

Further complicating matters, there is no guaranteed way to detect if an Android device has been rooted. This makes coding rooted device detection controls non-trivial for a native Android developer – and for those of us relying on Xamarin Magic, it is quite likely just an SDK too far.

What is a Xamarin.Android app developer to do?

Fortunately, Dotfuscator can also inject rooted device detection logic and response logic at the same time as a Xamarin.Android app is being obfuscated. This frees the Xamarin developer from having to develop Android skills to detect a rooted device and automates the implementation of the control itself.

Further, the logic of the control is further concealed from the potential attacker through Dotfuscator’s obfuscation, making it especially difficult to defeat the rooted device control.

Figure 2 shows the output results after Dotfuscator Professional applied renaming, control flow, and string encryption transforms after first injecting rooted device detection and (in this case) the developer’s custom response—all post-compile.

In addition to the automation and auditability of the rooted device control implementation, the results of the reverse-engineering process are significantly more difficult for an attacker to analyze and exploit.

A closer inspection of the reverse-engineered code shows:

1. Most names defined by the app are now meaningless letters – the method is named “i” (line 5) in a class named “a” (line 1). There’s no way for an attacker to ascertain the meaning of this method by looking at these names.
2. The body of the method is non-obvious (line 7 and onward). The simple if statement and for loop have exploded into a mess of nested switch statements and while loops, making the code’s printed order different from the execution order. This makes an attacker’s job even harder.
3. The “AppStatus” string is gone. In its place is a seemingly meaningless string (line 55), preventing an attacker from searching the decompiled code for this key. This key is only turned into “AppStatus” at runtime.
4. This class no longer has a constant field, preventing an attacker from gaining additional meaning for the string.

The app as a whole is protected against reverse engineering, securing the developers’ intellectual property and offering another line of defense against unauthorized use of an emulator or debugger with the injected rooted device control.

What is available with Dotfuscator Community Edition (CE)?

Unfortunately, control flow and string encryption are not included with Dotfuscator CE.

Fortunately, renaming and rooted device detection and response for Xamarin.Android is included.

Figure 3 shows comparable results after Dotfuscator Community Edition applied renaming after first injecting its own rooted device detection algorithm and the developer’s custom response—post-compile.

Unfortunately, if you’re developing Xamarin apps or Android apps that handle PII, process payments, manage medical records, or any of the thousands of sensitive scenarios that may be subject to regulatory or statutory obligations, you will most likely have to address the risks stemming from rooted Android devices.

Fortunately, with the combined capabilities of Xamarin and Dotfuscator, this does not have to turn into a massive science project. You will have more time, energy, and resources to build better apps and fantastic user experiences.

“Any sufficiently advanced technology is indistinguishable from magic.” Arthur C. Clarke