Xamarin Apps

Basic Information

Xamarin is an open-source platform that gives developers access to a comprehensive selection of tools and add-ons, allowing them to create modern apps for iOS, Android, and Windows using .NET and C# frameworks.

Xamarin Android Architecture

Xamarin offers .NET bindings to Android.* and Java.* namespaces. Xamarin.
Android applications operate under the Mono execution environment, with the Android Runtime (ART) virtual machine running side by side.
The Mono execution environment calls into these namespaces through Managed Callable Wrappers (MCW) and gives Android Callable Wrappers (ACW) to the ART.
Both these environments run on top of the Linux kernel and invoke various APIs to the user code. The arrangement allows developers to access the underlying system.

Xamarin iOS Project

Xamarin.iOS applications run under the Mono runtime environment and use full Ahead of Time (AOT) compilation to compile C# .NET codes to ARM assembly language.
It runs along with the Objective-C Runtime. The runtime environments run on top of a UNIX-like kernel and invoke several APIs to the user code, which lets the developers access the underlying managed or native system.
The below-given diagram depicts this architecture:

What is .Net Runtime and Mono Framework?

.Net framework is a set of assemblies, classes, and namespaces that developers can use to create applications; .Net Runtime runs the compiled code, and the process is called managed code execution. .NET Runtime provides several features that ensure platform independence and are compatible with older framework versions.
Mono Framework was started in 2005 as an implementation of the .NET Framework for Linux (Ximian/SuSe/Novell). Sponsored by Microsoft and led by Xamarin, Mono is the .NET framework's open-source implementation based on the ECMA standards for Common Language Runtime and C#.

Reverse Engineering Techniques for Xamarin Apps

Decompilation of Xamarin Assemblies

Decompilation is the process used to produce source code from compiled code. To procure information about the assemblies and executables currently in memory, Windows is a great place.
To open the Modules window, select Debug > Windows > Modules. Once you detect the module that requires decompilation, right-click and select "Decompile Source to Symbol File". This action builds a symbol file that contains a decompiled source which, in turn, lets you enter into 3rd party code directly from your source code.
Visual Studio decompiles the managed code, even in the absence of symbols, allowing you to look at the code, inspect the variables and set breakpoints. To extract source code to disk, right-click on the module with embedded source and click "Extract Embedded Source ."This will export the source files to a Miscellaneous files folder for further analysis.

JIT vs AOT Compilation of Xamarin Applications

These two options to compile C# based Xamarin code into an application, i.e, Just in time compilation and ahead of time compilation. The way of compilation affects how the application code is shipped within the apk or the ipa file. Let us quickly take a look at it below:
- Android: Xamarin allows you to compile using both the JIT and the AOT flags for android. There is also a way to go in between to get the most speed of execution using the Hybrid AOT mode. Note that the Full AOT mode is available only for the Enterprise license.
- iOS: There is only one option in the case of iOS, ahead-of-time compilation. This is due to Apple's policies which prohibit the execution of dynamically generated code on a device.
If you encounter a Full AOT compiled application, and if the IL Assembly files are removed to reduce the build size by the developer, then the reversing requires an extra step of extracting dll files from files from the lib folder or from the file. If it is a Hybrid AOT compiled app, and the IL files are still kept in the app bundle, we can use that to reverse engineer the application.

Getting the dll files from the APK/IPA

Just unzip the apk/ipa file and copy all the files present under the assemblies directory:
In case of Android APKs these dll files are compressed and cannot be directly used for decompilation. Luckily there are tools out there that we can use to uncompress these dll files like XamAsmUnZ and xamarin-decompress.
python3 -o /path/to/decompressed/apk
It is possible instead of dll files you will see assemblies.blob and assemblies.manifest in the assemblies directory. This is a Xamarin AssemblyStore and the currently recommended way to pack dlls in an Android application. The assemblies.manifest is a text file describing the contents of the binary file assemblies.blob. To unpack these you will need use pyxamstore.
pyxamstore unpack -d /path/to/decompressed/apk/assemblies/
In the case of the iOS, dll files inside the IPA files can be directly loaded into a decompiler (no need to uncompress anything).
Most of the application code can be found when we decompile the dll files. Also note that Xamarin Framework based apps contain 90% of common code in the builds of all platforms like iOS and Android etc.
From the above screenshot of listing the dll files that were present in the apk, we can confirm that it is a Xamarin app. It contains app-specific dll files along with the library files that are required for the app to run, such as Xamarin.Essentails.dll or Mono.Security.dll .
Finally you can use these recommended tools to access the C# code from the DLLs.

Dynamic Analysis

Try to check if the application has any kind of SSL pinning in place. If not, using Burp as a system, CA should work for intercepting requests. Frida with Java or ObjC runtime won’t work here, but luckily there’s a tool out there that can be used for hooking into methods.
Fridax allows you to easily modify the .NET binary inside a Xamarin application on runtime. Static analysis will help you identify different methods present within the application, which can be hooked later for dynamic analysis using Fridax. Below are a few Frida scripts that can help us bypass root detection or SSL-pinning: