Page 40 - MSDN Magazine, May 2018

This strategy aligns with the recommendations made by the PCI guidelines quoted earlier:
• The app monitors the device for rooting.
• The app quarantines the device by disabling itself if
rooting is detected.
• This security control operates even when the device is offline.
When the app disables itself, the error message alerts the user that the device is unsafe. While not used in the sample, an app using this scenario could also “phone home” to an analytics plat­ form such as Visual Studio App Center (bit.ly/2pYMuk5).
In addition to following the PCI guidelines, this strategy also lines up with the OWASP recommendation to shut down the app in a rooted environment to prevent reverse engineering. I config­ ured the Root Check to activate at other parts in the code, not just the Login process, so that if an attacker produces a tampered ver­ sion of the app with the Login process’s root detection removed, other parts of the app can still react to rooting. Dotfuscator also obfuscated the code, adding another layer of protection to the app and the Root Check.
Not all apps have the same security requirements, and thus not all apps should react to rooting in the same way. I chose a strict approach for the sample, but a more lenient strategy could allow the app to run on rooted devices in certain circumstances. For an example, see “An Alternate Protection Strategy” included with the Web version of this article at msdn.com/magazine/mt814987.
Protected Sample: You can view the Protected­TodoAzure­ Auth sample using the GitHub link supplied earlier. On the default master branch, I’ve already configured Dotfuscator CE to protect TodoAzure.Droid with a Root Check so that the app meets the strategy explained earlier. You can follow the Git history, starting with the before­checks branch, to see how I applied the steps in this article to the sample.
Not all apps have the same security requirements, and thus not all apps should react to rooting in the same way.
Please see the sample’s README for details on how to set up, build and run the sample. The README also includes details on other branches present in the repository that demonstrate different protection strategies than the one used for this article, such as the strategy detailed by the aforementioned Web version of this article.
Integrating Dotfuscator into Xamarin Builds
Because Dotfuscator operates on .NET assemblies (.dll and .exe files), not mobile platform formats like Android Packages (.apk files), I had to integrate Dotfuscator into the Xamarin build process. Setting up the integration requires installing and registering Dotfuscator CE, downloading a specialized MSBuild targets file and modifying the project file to include those targets. I’ve written on how to perform
these integration steps for the Xamarin Blog, so please see those instructions at bit.ly/2w9em6c.
Important Note: Root Checks require Dotfuscator CE version 5.35 or later for Visual Studio 2017. You can always get the latest version at bit.ly/2fuUeow.
I followed the Xamarin Blog instructions to protect the TodoAzure.Droid project file’s Release | AnyCPU build configura­ tion. This article only concerns this Android project because Root Checks are an Android­specific feature, but you can also follow the Xamarin Blog instructions to protect iOS and Universal Windows Platform (UWP) projects with code obfuscation.
Configuring the Dotfuscator Protection
Once I integrated Dotfuscator into the TodoAzure.Droid project’s build process, I configured the protection through the Dotfus­ cator CE UI. The protection settings for a project are saved in a specialized Dotfuscator config file, which the build integration adds to your project the first time it builds.
Creating the Dotfuscator Config File: Using Visual Studio 2017, I built the TodoAzure.Droid project in the Release build con­ figuration for the AnyCPU platform, which is the configuration I had set up to use Dotfuscator. This produced a new Dotfuscator config file, DotfuscatorConfig.xml, in the project’s directory. I added this new file to source control so I could later customize and reapply the protection based on that customization.
The build also created a DotfuscatorReports directory in my project directory, which is where Dotfuscator writes various report files when it runs as part of the integration. Because this directory's contents update every build, I had my source control ignore this directory.
Opening Dotfuscator: To customize the Dotfuscator config file, I opened the Dotfuscator CE UI from Visual Studio 2017 by choosing Tools | PreEmptive Protection ­ Dotfuscator. In the Dot­ fuscator UI that appeared, I chose File | Open Project, navigated to the TodoAzure.Droid project’s directory and selected Dotfus­ catorConfig.xml, the Dotfuscator config file. The Dotfuscator UI updated to display the two assemblies this Dotfuscator config file protects: TodoAzure.Droid.dll itself and the portable class library (PCL) assembly TodoAzure.dll.
Keep in mind that the Build Project option in the Dotfuscator UI doesn’t perform Xamarin packaging steps. To ensure the Android Package contains the protected assemblies, build the proj­ ect from Visual Studio or MSBuild instead.
Enabling Code Injection: Checks are part of the Dotfuscator code injection features. To enable code injection, I right­clicked the Injection node in the Dotfuscator navigation bar and checked the Enable option. The Injection node’s text color changed from gray to black, indicating that injection was enabled.
Viewing Configured Checks: The Dotfuscator Checks page displays a list of all configured Checks for a loaded config file, in this case DotfuscatorConfig.xml in the TodoAzure.Droid project. To view this page, I selected the Injection node and switched to the Checks tab.
When I first visited this list, it was empty. Once I configured a new Root Check, as I explain in the next section, the list updated
36 msdn magazine
Security