• Noser.com
facebook
linkedin
twitter
youtube
  • NOSERmobile
    • Android
    • HTML 5
    • Hybrid Apps
    • iOS
    • Windows Phone
  • NOSERembedded
    • Medizintechnik
  • NOSERprojektmanagement
  • NOSERtesting
  • NOSERlifecycle
    • .NET Allgemein
    • Application Lifecylce Management
    • Apps
    • Architektur
    • ASP.NET
    • Azure
    • Cleancode
    • Cloud
    • Silverlight
    • Visual Studio / Team Foundation Server
    • Windows 8
    • Windows Presentation Foundation
  • NOSERinnovation
    • Big Data
    • Cloud
    • IoT
    • Operations Research
    • Augmented Reality
    • RFID, NFC, Bluetooth LE

Xamarin.Android Code Obfuscation

20. November 2015
Rehmann Christoph
6
Mobile, Xamarin.Android

Xamarin Android Apps werden mit C# entwickelt. Beim Kompilieren wird der C# Code in die Intermediate Language übersetzt und mit der Android Mono-Runtime zusammengepackt. Ein solches Assembly lässt sich relative leicht mit einem Tool wie ILSpy dekompilieren. Dabei kann praktisch der ganze Source Code wiederhergestellt werden. Es lassen sich Klassen-, Methoden- und Variablennamen einsehen.
Möchte man ein solches Reverse Engineering erschweren, wird oftmals zur sogenanntem Code Obfuscation gegriffen.

Dabei werden verschiedenste Methoden eingesetzt, um die das Reverse Engineering zu erschweren. Zu den gängigsten Methoden gehören zum Beispiel:

  • Äquivalente Formeln und konstante Transformationen:
    Konstanten werden anders kodiert und verschleiert.
  • Veränderung des Kontrollflusses:
    Etwa durch Hinzufügung von Jumps oder Switch-basierten State Machines wird versucht den Kontrollfluss der Applikation zu verschleiern.
  • Umbenennung:
    Durch Umbenennung von Klassennamen, Methoden- und Variablennamen wird erschwert den Zweck eines Code-Teils zu erkennen.

 

Allerdings kann mit Code Obfuscation ein Reverse Engineering nicht verhindert werden sondern lediglich zeitaufwändiger gemacht werden.

Einbindung in den Build Prozess

Es gibt eine Vielzahl Code Obfuscating Tools. Egal was für eines das man verwendet, das Einbinden in den Build Prozess gestaltet sich in der Regel ähnlich. Für das folgende Beispiel wird das gratis Tool ConfuserEx verwendet.

Zuerst musst die Xamarin.Android Projektdatei angepasst und um folgenden Eintrag ergänzt werden:

<Target Name="Obfuscate" AfterTargets="_CopyIntermediateAssemblies" Condition="'$(Configuration)' == 'Release'">
   <Exec Command="AndroidObfuscation.bat '$(SolutionDir)'" WorkingDirectory="$(SolutionDir)\TipCalculator\Obfuscation" />
</Target>

Im Debug-Build möchte man in der Regel kein Code Obfuscating betreiben, da ansonsten das Debugging nicht möglich ist und Stack Traces unleserlich sind. Daher sollte man mit Hilfe einer Condition sicherstellen, dass nur im Release-Build ein Code Obfuscating betrieben wird.

Die im oberen Beispiel genanngte AndroidObfuscation.bat Datei kann z.B. wie folgt aussehen:

echo "starting source code obfuscation"
Confuser.CLI.exe TipCalculator.crproj
echo "finished obfuscating source code"

echo "copy TipCalculator.Droid.dll"
del "..\TipCalculator.Droid\obj\Release\assemblies\TipCalculator.Droid.dll"
copy "..\Confused\TipCalculator.Droid\obj\Release\assemblies\TipCalculator.Droid.dll" "..\TipCalculator.Droid\obj\Release\assemblies\TipCalculator.Droid.dll"
del  "..\Confused\TipCalculator.Droid\obj\Release\assemblies\TipCalculator.Droid.dll"

echo "finished copying obfuscated assemblies"


Diese führt ConfuserEx aus und ersetzt anschliessen die Assemblies.

Fazit

Es ist relativ einfach ein Code Obfuscating für eine Xamarin.Android App einzurichten und so zu konfigurieren, dass dies für jeden Release-Build ausgeführt wird.

Einbinden einer Java Bibliothek in ein Xamarin.Android Projekt

19. Oktober 2015
Rehmann Christoph
1

Android besitzt ein sehr grosses Eco-System an Third-Party Bibliotheken. Es kann öfters durchaus Sinn machen eine bestehende Java Bibliothek in ein Xamarin.Android Projekt einzubinden anstatt selber eine entsprechende Implementation in C# zu schreiben.

Dabei gibt es zwei mögliche Optionen:

  • Erstellen einer Binding Bibliothek. Dies ist im Wesentlichen eine Wrapper um die Java Bibliothek herum. Die Bindings werden mit Hilfe von so genannter Managed Callable Wrappers (MCW) implementiert.
  • Verwendung des Java Native Interface (JNI) um direkt Java Code aufzurufen.

In folgendem Blog Beitrag wird auf die erste Option eingegangen und anhand eines Beispielprojektes gezeigt, auf was für Probleme man dabei stossen kann und wie diese gelöst werden können.

Das komplette Beispielprojekt kann hier gefunden werden und beinhaltet die Xamarin Solution sowie den Java Source Code der Beispielbibliothek.

Vorgehen

  • Erstellen der Binding Library
    Xamarin bieten eine Projektvorlage für das Erstellen einer Binding Bibliothek. So kann einfach zu einer bestehenden Xamarin.Android Solution ein neues Binding Projekt hinzugefügt werden.Im Template enthalten ist unter anderem die Datei Metadata.xml. Mit Hilfe von dieser kann in den Generierungsprozess der Bindings eingegriffen werden. Ausführliche Informationen dazu sind auf der Xamarin Website zu finden.
  • Java Bibliothek zum Binding Projekt hinzufügen
    Um die Java Bibliothek zum Binding Projekt hinzuzufügen, zieht man die Jar Datei in den Jars Ordner des Projektes. Anschliessend muss noch die richtige Build Action für die Jar Datei ausgewählt werden. In Unserem Fall ist dies EmbeddedJar. Eine genaue beschreibung der verschiendenen Build Actions kann hier gefunden werden.
  • Binding Projekt kompilieren
    Nun kann das Projekt kompiliert werden. Doch das ist leichter gesagt als getan. Versucht man dies nämlich mit der oben verwiesenen Jar Datei, so stellt man fest, dass mehrere Fehler auftreten:
    Build Fehler beim Kompilieren

CS0234 The type of namespace name ‘TipCalculationServiceBase’ does not exit

Wenn man sich diesen Fehler genauer anschaut, so sieht man, dass eine Klasse TipCalculationServiceImpl generiert worden ist, welche von TipCalculationServiceBase ableitet. Allerdings wurde gar keine TipCalculationServiceBase Klasse generiert. Um die Ursache des Problems zu finden, muss man sich den Java Code genauer ansehen. Dort ist zu erkennen, dass beide Klassen ebenfalls vorhanden sind. Die TipCalculationServiceBase Klasse ist allerdings nicht public. Während es in Java erlaubt ist, dass eine public Klasse von einer anderen ableitet, die nicht public ist, so ist das in C# nicht möglich.

Um das Problem zu lösen hat man nun zwei Möglichkeiten:

  • Man entfernt die TipCalculationServiceImpl Klasse mit folgendem Eintrag in der metadata.xml Datei:
    <remove-node path="/api/package[@name='crehmann.samples.monodroidjarexample']/class[@name='TipCalculationServiceImpl']"/>

Dies ist in unserem Fall jedoch keine Option, weil wir die TipCalculationServiceImpl verwenden wollen und somit unsere Binding Library einen solchen Wrapper besitzen muss.

  • Man macht die TipCalculationServiceBase mit Hilfe der metdata.xml Datei public:
    <attr path="/api/package[@name='crehmann.samples.monodroidjarexample']/class[@name='TipCalculationServiceBase']" name="visibility">public</attr>

Nun wird zwar ebenfalls ein Binding für die TipCalculationServiceBase Klasse erstellt, allerdings sollte man im C# Code diese nicht direkt verwenden.

Versucht man das Projekt erneut zu kompilieren, so stellt man fest, dass nun zwar alle vorgängigen Fehler behoben wurden. Allerdings ist ein neuer erschienen:

xamarin_android_jar_build_error_2

Dieser Fehler tritt auf, wenn z.B. ein Binding für eine Java Methode generiert wird, dass einen kovarianten Rückgabe Wert hat. So definiert das Java Interface TipCalculationService für die Methode CalculateTip einen Rückgabewert vom Typ Object, während bei TipCalculationServiceBase der Rückgabewert vom Typ TipCalculationResult ist.

Nun hat man auch wieder zwei Möglichkeiten um das Problem zu lösen:

  • Man ändert den Typ des Rückgabewertes für den generierten C# Code indem folgenden Eintrag in der Metadata.xml definiert_
    <attr path="/api/package[@name='crehmann.samples.monodroidjarexample']/class[@name='TipCalculationServiceBase']/method[@name='calculateTip' and count(parameter)=1 and parameter[1][@type='crehmann.samples.monodroidjarexample.TipRequest']]" name="managedReturn">Java.Lang.Object</attr>
  • Man fügt zum Projekt eine Partial Class Deklaration hinzu, welche das Interface entsprechend implementiert:
    using Java.Lang;
    
    namespace Crehmann.Samples.Monodroidjarexample
    {
       public abstract partial class TipCalculationServiceBase
       {
           Object ITipCalculationService.CalculateTip(TipRequest p0)
           {
               return CalculateTip(p0);
           }
       }
    }

Nun lässt sich das Projekt ohne Fehler kompilieren und kann innerhalb des Xamarin.Android Projektes referenziert und verwendet werden.

Fazit

Mit Xamarin ist es relativ leicht möglich bestehende Android Java Bibliotheken zu verwenden. Mit dem Binding Projekt Template kann dabei auf einfache Weise eine Wrapper Bibliothek generiert werden. Dabei hat man viele Möglichkeiten um in die Generierung der Wrapper Klassen einzugreifen und diese zu modifizieren um dadurch allfällige Probleme zu beheben.

 

1234567

Tag Cloud

.NET android ANgular Angular Js AngularJs Arduino ASP.Net automated testing Azure Big Data C# C++ Cloud continuous integration Elm Embedded gRPC Internet of Things IoT Java Javascript M2M OWASP Projektmanagement protobuf Python Raspberry Pi Reactive Programming REST Scrum Security Softwarequalität SPA Testen testing Testmanagement Teststrategie Visual Studio WebAPI windows windows phone 8 WPF Xamarin Xamarin.Android Xamarin.Forms

Archive

Current Posts

  • Lasttests mit NBomber
  • Kreative Interaktion mit Xamarin.Forms Touch-Actions
  • Angular vs. React: Ein pragmatischer Vergleich
  • Eine Alternative zu Azure Time Series Insights, bitte?
  • Focus on the Secure Storage service of Trusted Firmware (TFM)

Last Comments

  • Noser Blog Touch-Actions in Xamarin.Forms - Noser Blog bei Mach mehr aus Animationen in Xamarin.Forms mit SkiaSharp
  • Noser Blog Focus on the Secure Storage service of Trusted Firmware (TFM) - Noser Blog bei First run of the Trusted Firmware (TFM) application
  • Noser Blog First run of the Trusted Firmware (TFM) application - Noser Blog bei Focus on the Secure Storage service of Trusted Firmware (TFM)
  • Noser Blog Focus on the Secure Storage service of Trusted Firmware (TFM) - Noser Blog bei Security management with Trusted Firmware
  • Noser Blog ZeroMQ / NetMQ mit Protocobuf - Noser Blog bei Tutorial: Protocol Buffers in ASP.NET Core

Popular Posts

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 1 - Aufbruch

5 Comments

C# Concurrency Teil 8: Delegate Tasks

4 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 2 - Kein Picknick

4 Comments

Contact us

  1. Name *
    * Please enter your name
  2. Email *
    * Please enter a valid email address
  3. Message *
    * Please enter message
© 2013 NOSER ENGINEERING AG. All rights reserved. Datenschutz | Cookie-Richtlinie