Protecting Localized Xamarin Forms Applications

June 4, 2020 805 Views Johnny

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.

Dotfuscator can usually process localized apps without issue. We’ve built smarts into Dotfuscator to handle resource classes and seamlessly process satellite assemblies. However, recently we worked with a customer for whom this was not the case. After obfuscation, their localized Xamarin Forms application remained in the default language (English), regardless of the OS language setting. In this post, I’ll describe how this happened, and how to properly configure Dotfuscator for this scenario.

Please consider the following example. This basic Xamarin Forms app displays a flag image for the country, as well as a few localized strings for the UI controls.

The default locale is English (en-US), with the ability to change different languages based on OS language preferences. The localization strings are configured via RESX files, along with an auto-generated “AppResources” class file to access the translated strings at runtime:

I’ve protected this app with the default Dotfuscator settings. After doing so, when I change the default OS to a different language, notice the image (flag) will correctly update, but the text strings remain in the default English:

This happened because Dotfuscator renamed the auto-generated AppResources class. Normally, Dotfuscator’s Xaml Analysis automatically matches the Xaml to the corresponding class name. However, in this case, the compiled Xaml still looks for the original AppResources class name when displaying the localized strings.

In order to prevent the UI from displaying the wrong localized strings, I open the DotfuscatorConfig.xml in the Dotfuscator Professional Config Editor, and exclude the auto-generated AppResources class from the Rename transform:

After configuring this rename exclusion and re-deploying the APK, the localized strings are properly displayed:

In most instances, Dotfuscator handles app localization without issue. But If you notice that the strings do not follow the OS language settings after protecting your localized Xamarin Forms app, you may need to exclude the auto-generated resource class from renaming.

The full example can be downloaded here.

This example is based on the ResX Localization demo found here.

If you have any feedback on this topic, or other topics you would like us to discuss in the Support Corner, please feel free to contact us at support [at] preemptive [dot] com.

Latest Blog Posts

Protecting Utilities and Infrastructure with PreEmptive's .NET Solution, Dotfuscator

Protecting Industrial Internet Applications

Bayshore Network Case Study

Today’s utilities, factories and other infrastructure are exposed to high risk. The software that controls many of these entities is not protected. In the last 20 years, the way industrial environments operate has completely changed. Many industrial systems were designed with permissive set-ups that assume only the “right people” in the “right place” would ever give instructions. Past systems were not built with exposure to the internet in mind, and as a result they relied on this “air gap” to limit access to only authorized personnel within the organization. The rate of innovation within technology and wireless systems has outpaced the rate of development in security features. Control centers have gotten better - high tech displays and more capability, but this has led to an exposure to untrusted environments… and in many cases this threat has not been addressed.

Application security can often be viewed by development teams as a time-consuming barrier to finishing a project. In a world where "time equals money", the rush to ship functional applications can overshadow the need to ensure those applications are secure. It is true --- features are what sell software and fixing bugs retains customers and loyalty. Both actions can be directly linked to revenue and profitability. So, what effect does an investment in application security have on a company's bottom line?

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.

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!

Protecting Localized Xamarin Forms Applications

Protecting Utilities and Infrastructure with PreEmptive's .NET Solution, Dotfuscator

Mobile Application Protection Increases Profits

No Contact Normal: Solving the Payment Security Gap