Mai 2018

Band 33, Nummer 5

Sicherheit: Erkennen und Reagieren auf Android-Geräte mit Rootzugriff aus Xamarin-Apps

Durch Joe Sewell

Im letzten November-Problem ich veranschaulicht Laufzeit überprüft wird, eine codeinjizierung Verwendung der Features mit Visual Studio 2017 die .NET Framework-apps vor nicht autorisierter Verwendung eines Debuggers sowie vor Manipulationen geschützt (msdn.com/magazine / mt845626). Inzwischen hat ein neuer Typ von Kontrollkästchen verfügbar sind. Überprüfen Sie den Stamm erkennt, wenn eine app Xamarin.Android auf "Stammgerät" ausgeführt wird – eine gewöhnliche apps mit Administratorberechtigungen (Root-Zugriff) fungieren ermöglicht.

In diesem Artikel Nachbereitung erläutern ich an, warum Rooting manipulierten Geräten ein Risiko darstellen, die alle Android-Entwickler kennen müssen. ausführlich beschrieben Sie, wie Entwickler Xamarin.Android erkennen und behandeln können dieses Risiko verwenden können Stamm überprüft; und bewährte Methoden für ein Beispielszenario zu veranschaulichen.

Warum müssen Sie zum Schutz vor Rooting

Die Xamarin-Plattform können Sie effizient mobiler apps für Android, iOS und Windows-Geräte erstellen. Mit .NET-Sprachen wie c# vertraute Entwickler können dieses Wissen und den mobilen Speicherplatz zuweisen. Technologien wie Xamarin.Forms abstrakten beseitigen n der Unterschiede zwischen den Plattformen, die wegen der geringeren Komplexität, Kosten und Risiken bei der Entwicklung von plattformübergreifenden apps. Durch Speicherung der Xamarin-Tools auf dem neuesten Stand, können Sie weiterhin neue Versionen und Funktionen der einzelnen Plattformen zu unterstützen.

Allerdings einige Clientplattform-spezifische Aspekte der Entwicklung für mobile eines Entwicklers Aufmerksamkeit verdienen. Ein solcher Aspekt ist die Sicherheit. Jede Plattform verfügt über eindeutige Sicherheitsrisiken und ein individuelles Sicherheitsmodell, um diese Risiken zu behandeln. Die Berechtigung Systeme unterscheiden z. B. zwischen den verschiedenen Plattformen und in einigen Fällen sogar zwischen Versionen der gleichen Plattform.

Für Android-apps werden Geräte mit entfernten nutzungsbeschränkungen Sicherheitsbedenken besonders wichtig. Solche Geräte wurden geändert, um außerhalb der normalen Sicherheitssandkasten unterbrochen, die das Betriebssystem erzwingt für apps erlauben. Dies kann das Gerät viele Gefahren, z. B. Malware und Kennwörter stehlen Keylogger verfügbar machen. Häufig root-Benutzer ihre Geräte aus, um Probleme zu lösen – wie endversatz eine Version einer App, die nicht normal für ihr Gerät verfügbar ist – unbewusst den Schweregrad dieser Bedrohungen. In anderen Fällen kann ein Benutzer selbst nicht beachten Sie, dass das Gerät als Stamm verknüpft ist und somit gefährdeten.

Letzte September ausgegeben Payment Card Industry Security Standards Council (PCI SSC), Version 2.0 von der Mobile Zahlung Annahme Sicherheitsrichtlinien für Entwickler. Um Sicherheitsrisiken mit Rooting manipulierten Geräten zu begegnen, die Richtlinien empfehlen mobile app-Entwickler implementieren, Root-Erkennung und einen Antwort-Mechanismus, um die app unter Quarantäne gestellt (bit.ly/2H5ymge). So sieht die entsprechende Text im Abschnitt "" 4.3 (Hervorhebung hinzugefügt):

[T] He-Gerät für Aktivitäten mit dem Betriebssystem Sicherheit controls—e.g., Jailbreaking oder rooting zunichte machen überwacht werden soll, und, wenn erkannt wird, muss das Gerät nach einer Lösung, die aus dem Netzwerk entfernt, entfernt die Zahlung-Annahme isoliert werden vom Gerät, Anwendung oder die Payment-Anwendung deaktiviert. Offline Erkennung von jailbreaks und Stamm und Auto-Quarantäne sind der Schlüssel, da einige Angreifer versuchen möglicherweise, das Gerät in einem Offlinestatus weiter Erkennung zu umgehen.

Zusätzlich zu den Risiken im Zusammenhang mit einem legitimen Benutzer die app in einer Umgebung mit entfernten nutzungsbeschränkungen funktioniert kann in einer solchen Umgebung auch einen böswilligen Benutzer versucht, das Reverse Engineering der app angeben. Angreifer verwenden häufig Rooting manipulierten Geräten zu untersuchen, und erstellen manipulierte Versionen von apps, die sie dann mit Malware zu füllen. Code, der als Top 10-Mobile-Risiken Manipulation aufgeführt, die Open Web Application Security Projekt (OWASP) (bit.ly/2GNbd4o) und insbesondere Aufrufe Stamm-Erkennung und-Antwort als eine Möglichkeit zur Verringerung dieses Risikos. Nicht auf diese Weise, entsprechend OWASP, kann zu regt Schaden und Entgangener Gewinn führen.

Hier wird überprüft, ob Stamm

Erkennen von Rooting manipulierten Geräten kann schwierig sein. Ein Gerät kann viele verschiedene Techniken mit Stamm und den Satz der verfügbaren Techniken ändert, im Zeitverlauf und über Android-Versionen hinweg. Folglich Stamm Erkennungscode muss ständig weiterentwickelt, und passen. Dies wird durch die Tatsache verstärkt, einige bösartigen rooting Techniken versuchen, zu deren Verwendung zu verbergen, damit gute Stamm Erkennungscode auch diese Gegenmaßnahmen berücksichtigt werden muss. Auf dem neuesten Stand Stamm Erkennungscode zu verwalten ist als kompliziert und möglicherweise nicht, in dem Ihre begrenzten Ressourcen aufwenden werden sollen.

Glücklicherweise müssen Sie Ihren eigenen Code zum Erkennen rooting schreiben. PreEmptive Protection - Dotfuscator Community Edition (CE), die mit Visual Studio 2017 für Windows enthalten ist, kann bei Ihren apps Xamarin.Android Stamm überprüft einfügen. Stamm Umgebungen Stamm überprüft erkannt werden, selbst wenn das Gerät offline ist. Zusätzlich zu einer "exit die app" Standardaktion können konfigurieren, die Überprüfungen aus, um Antworten auf rooting durch Aufrufen von app-Code angepasst.

Genau wie Xamarin selbst reduzieren Stamm überprüft, Komplexität, Kosten und Risiko im Vergleich zu parallelen eine eigene Implementierung. Dotfuscator auf dem neuesten Stand und lassen sie die Stamm-Erkennung behandeln – abrufen zurück, an die interessanten Teile Ihrer App schneller zu arbeiten.

Beispielszenario

Zur Veranschaulichung Stamm überprüft habe ich eine Beispiel-app geschützte TodoAzureAuth aufgerufen bereitgestellt. Es basiert auf einer vorhandenen Xamarin.Forms Beispiel TodoAzureAuth (bit.ly/2InvU48), die ursprünglich von David Britch geschriebenen.

Der Rest dieses Artikels wird erläutert, die app, die Schutzstrategie ich angewendet, und wie ich diese Strategie mit Stamm überprüft angewendet wird. Sie können diese Fallstudie sowie zusätzliche Szenarien, die in der Beispiel-GitHub-Repository enthalten (bit.ly/2GQutOv), um Ansätze zum Stamm überprüft zu erfahren, können Sie auf Ihre eigenen Xamarin.Android apps anwenden.

Ursprüngliche Beispiel: TodoAzureAuth wird eine Verbindung mit einer Microsoft Azure-Mobile-App-Instanz, die Benutzern das Anzeigen und Ändern einer freigegebenen Aufgabenliste aktivieren. Das Beispiel zum veranschaulichen wie zum Durchführen der Authentifizierung in einer Xamarin-app werden, benötigt den Benutzer mit einem Google-Konto anmelden, bevor der Zugriff auf die to-Do-Liste.

Die app beginnt, auf der Anmeldeseite, die keine Felder, nur eine Anmeldeschaltfläche hat. Wenn der Benutzer auf diese Schaltfläche auswählt, delegiert die app des Anmeldevorgangs zu Google OAuth-System, die den Benutzer zur Eingabe von Anmeldeinformationen, z. B. ein Kennwort erfordern. Die app selbst behandeln nicht daher die Anmeldeinformationen. Sobald der Benutzer angemeldet hat, zeigt die app die TODO-Listenseite, sodass der Benutzer Zugriff auf die freigegebene to-Do-Liste. Der Benutzer kann melden Sie sich ab und zu der Anmeldeseite zurückkehren, indem die Abmeldeschaltfläche auswählen.

Schutzstrategie: Für diesen Artikel behandelt ich das TodoAzureAuth Android-Projekt TodoAzure.Droid, als ob er die vertrauliche Daten, wie eine PCI-kompatible Anwendung verarbeitet wurden. Ich implementiert eine entsprechende Schutzstrategie mit Dotfuscator CE einen Stamm überprüfen, die in der app einfügen, der eine geschützte Version der app, geschützte TodoAzureAuth erzeugt.

In der geschützten app Wenn der Benutzer die Anmeldeschaltfläche auswählt aktiviert der Stamm überprüfen. Wenn die app auf ein Stammgerät ausgeführt wird, es abrupt beendet, und alle weiteren Versuche zum Ausführen der app werden auch nach einer kurzen Fehlermeldung beendet, selbst wenn das Gerät keinen Stamm mehr aufweist. Abbildung 1 zeigt eine Übersicht über die app, die durch diese Strategie geschützt.

Abbildung 1 Überblick über die geschützte TodoAzureAuth-Beispiel-App

Diese Strategie richtet mit den Empfehlungen die PCI-Richtlinien, die in Anführungszeichen zuvor:

• Die app wird das Gerät für rooting überwacht.
• Die app wird unter Quarantäne gestellt das Gerät von sich selbst deaktivieren, wenn eine rooting erkannt wird.
• Diese Sicherheitsmaßnahme wird ausgeführt, selbst wenn das Gerät offline ist.

Wenn die app selbst, die Nachricht fehlerwarnungen der Benutzer deaktiviert, dass das Gerät nicht sicher ist. Obwohl nicht in der Stichprobe verwendet wird, eine app mit diesem Szenario konnte auch "phone home" auf eine analyseplattform, z. B. Visual Studio-App Center (bit.ly/2pYMuk5).

Über die PCI-Richtlinien hinaus Zeilen, die diese Strategie auch von der Empfehlung OWASP beim Herunterfahren der Anwendung in einer Stamm-Umgebung um reverse Engineering zu verhindern. Ich konfiguriert den Stamm Check Aktivierung zu anderen Teilen im Code, nicht nur des Anmeldevorgangs so, falls ein Angreifer eine manipulierte Version der app mit Root-Erkennung des Anmeldevorgangs entfernt wird, andere Teile der app weiterhin rooting reagieren können. Dotfuscator verborgen auch den Code der app, und überprüfen Sie den Stamm einer anderen Ebene des Schutzes hinzugefügt.

Nicht alle apps haben die gleichen sicherheitsanforderungen und daher nicht alle apps auf rooting auf die gleiche Weise reagieren soll. Ich haben einen strikten Ansatz für das Beispiel, aber eine weniger strenge Strategie kann auf Rooting manipulierten Geräten unter bestimmten Umständen Ausführung die Anwendung ermöglichen. Ein Beispiel finden Sie unter "Eine alternative Schutzstrategie."

Geschützte Beispiel: Sie können die geschützte TodoAzureAuth Beispiel mit dem zuvor angegebenen Link-GitHub anzeigen. Klicken Sie auf die Standard-hauptverzweigung haben ich bereits konfiguriert Dotfuscator CE um TodoAzure.Droid mit einem Stamm überprüfen, damit die app erfüllt, die zuvor erläuterten Strategie zu schützen. Führen Sie das Git-Verlauf, beginnend mit der Verzweigung vor Überprüfungen zu sehen, wie ich die Schritte in diesem Artikel, die die Stichprobe angewendet.

Zum Einrichten, erstellen und Ausführen des Beispiels finden Sie im Beispiel Infodatei für Details. Die Infodatei enthält ferner Details auf anderen Verzweigungen im Repository vorhanden, in denen unterschiedlichen Strategien als Konto für diesen Artikel, z. B. die in "Eine alternative Schutzstrategie." beschriebene Strategie veranschaulicht.

Integrieren von Dotfuscator in Xamarin erstellt

Da Dotfuscator für .NET Assemblys (DLL- und .exe-Dateien) ausgeführt wird, wie Formate für nicht mobile-Plattform Android-Paketen (apk-Dateien), musste ich Dotfuscator in den Buildprozess Xamarin integrieren. Einrichten der Integration erfordert das Installieren und registrieren Dotfuscator CE, eine spezielle MSBuild Targets-Datei herunterladen und Ändern der Projektdatei, um diese Ziele einzubeziehen. Ich habe Anleitungen zum Ausführen dieser Integrationsschritte für die Xamarin-Blog so geschrieben finden Sie die Anweisungen unter bit.ly/2w9em6c.

Wichtiger Hinweis: Stamm überprüft erfordern Dotfuscator CE Version 5,35 oder höher für Visual Studio-2017. Sie erhalten immer die neueste Version des bit.ly/2fuUeow.

Ich die Xamarin-Blog-Anweisungen, um die Projektdatei TodoAzure.Droid Version schützen gefolgt | Buildkonfiguration "anycpu". In diesem Artikel betrifft nur Android-Projekt, da eine Android-spezifische Funktion Stamm überprüft werden, aber Sie können auch die Xamarin-Blog-Anweisungen zum Schutz von iOS und universelle Windows-Plattform (UWP)-Projekten mit Code Verbergung folgen.

Konfigurieren des Schutzes Dotfuscator

Nachdem ich Dotfuscator in das TodoAzure.Droid Projekt Buildprozess integriert ist, konfiguriert ich den Schutz durch die Dotfuscator CE-Benutzeroberfläche. Die Einstellungen für den Schutz für ein Projekt werden in eine spezielle Dotfuscator Config-Datei gespeichert, das Build-Integration zu Ihrem Projekt erstmalig hinzufügt, die sie erstellt.

Erstellen die Dotfuscator-Config-Datei ein: Verwendung von Visual Studio 2017 erstellt ich die TodoAzure.Droid Projekt in der Version die Buildkonfiguration für die AnyCPU-Plattform ist die Konfiguration, die ich mit Dotfuscator eingerichtet haben. Dies erstellt eine neue Dotfuscator Config-Datei, DotfuscatorConfig.xml, in das Verzeichnis des Projekts. Ich hinzugefügt damit könnten später anpassen und wenden Sie erneut den Schutz, basierend auf die Anpassung an die neue Datei quellcodeverwaltung.

Der Build erstellt auch ein DotfuscatorReports Verzeichnis in meiner Projektverzeichnis ein, also, in dem Dotfuscator verschiedene Berichtsdateien schreibt, wenn es als Teil der Integration ausgeführt wird. Da das dieses Verzeichnis Inhalt zu jedem Build aktualisieren, musste ich meine Datenquellen-Steuerelements, dieses Verzeichnis zu ignorieren.

Öffnende Dotfuscator: Ich geöffnet zum Anpassen der Dotfuscator-Datei "App.config" die Dotfuscator CE-Benutzeroberfläche von Visual Studio 2017 durch Auswählen von Tools | PreEmptive Schutz - Dotfuscator. In der Dotfuscator UI, die angezeigt wurden, ausgewählte ich Datei | Öffnen Sie das Projekt, in der TodoAzure.Droid Projektverzeichnis navigiert ist und DotfuscatorConfig.xml Dotfuscator-Config-Datei ausgewählt. Die Dotfuscator UI aktualisiert, um die zwei Assemblys anzuzeigen, die diese Dotfuscator-Config-Datei schützt: TodoAzure.Droid.dll selbst und die portablen (PCL) Bibliotheksassembly TodoAzure.dll.

Beachten Sie, dass die Option "Project erstellen" im Dotfuscator UI Xamarin Verpackung Schritte nicht beibehalten. Um sicherzustellen, dass das Android-Paket die geschützten Assemblys enthält, erstellen Sie das Projekt stattdessen in Visual Studio oder über MSBuild.

Aktivieren Codeinjizierung: Überprüfungen sind Bestandteil der Dotfuscator Code Injection-Funktionen. Um eine codeinjizierung zu aktivieren, ich mit der rechten Maustaste des Knotens "Injection" in der Navigationsleiste Dotfuscator und überprüft die Option Enable aus. Die Textfarbe des Injection-Knotens von Grau in Schwarz bedeutet, dass Injection aktiviert wurde geändert.

Anzeigen von konfiguriert überprüft: Die Seite "Dotfuscator überprüft" zeigt eine Liste aller konfigurierten Prüfungen für eine geladenen Konfigurationsdatei in diesem Fall DotfuscatorConfig.xml im Projekt TodoAzure.Droid. Zum Anzeigen dieser Seite, wenn ich die Injection-Knoten ausgewählt und auf der Registerkarte "überprüft" gewechselt.

Wenn ich diese Liste zuerst besucht hat, war leer. Nachdem ich einen neuen Stamm überprüfen, wie im nächsten Abschnitt erläutert konfiguriert, aktualisiert die Liste eine Zeile für die Überprüfung eingeschlossen, wie unter Abbildung 2. Ich konnte die Konfiguration für die Überprüfung anzeigen, indem Sie auf diese Zeile doppelklicken.

Abbildung 2 die Dotfuscator überprüft die Seite ", zeigt eine Stamm-Überprüfung

Beachten Sie, dass Sie mehr als ein Stammverzeichnis für eine einzelnes Dotfuscator Config-Datei überprüfen konfigurieren können, obwohl ich für diesen Artikel nicht geschehen. Ein Beispiel für eine app, die von mehreren Prüfungen geschützt finden Sie in der AdventureWorksSalesClient .NET Framework-Apps, die ich zum letzten November geschrieben wurde.

Hinzufügen einer Stamm-Kontrollkästchen

Von der Seite "Überprüfung" hinzugefügt ich eine Check-Stamm durch Klicken auf die Schaltfläche "Überprüfen der Stammzertifizierungsstelle hinzufügen". Wenn ich hat, angezeigt Dotfuscator ein neues Fenster für die neue Überprüfung konfigurieren. Abbildung 3 zeigt die fertige Konfiguration; in diesem Abschnitt wird erläutert, die Bedeutung der einzelnen Einstellungen und warum ich diese Einstellungen ausgewählt haben.

Abbildung 3-Konfiguration die Stamm-Suche – zusätzliche Standorte, die durch den reduzierten TodoAzure.dll Knoten ausgeblendet

Positionen: Jedes Kontrollkästchen wird eine oder mehrere Methoden in der app mit dem Namen Speicherorte zugeordnet. Wenn die app eine solche Methode aufruft, wird aktiviert. Überprüfen Sie den Stamm, zu diesem Zeitpunkt erkennen, wenn das Gerät zu Rooting manipuliert werden. Nach dem Ausführen alle Berichts- und Antwort-Funktionalität, vorausgesetzt, dass diese Measures die app zu beenden wurde nicht konfiguriert gibt das Kontrollkästchen-Steuerelement an den Anfang der Methode zurück.

Für dieses Szenario-Überprüfung aktiviert ich mehrere Speicherorte. Die Position, die zuerst in der app verwendet wird TodoAzure.Droid.MainActivity.AuthenticateAsync, das eine anmeldeanforderung koordiniert. Mit diesem Speicherort bedeutet, dass der Stamm überprüfen führt die Erkennung und die Antwort immer des Anmeldevorgangs beginnt.

Pro Schutzstrategie wird eine Anwendung auf ein Stammgerät erreichen die AuthenticateAsync-Methode beendet. Daher hinzufügen warum ich anderer Methoden, die auftreten, weiter unten in der app-Lebenszyklus als zusätzliche Speicherorte? Dadurch wird die app Verteidigung gegen reverse Engineering-Team zu helfen. Wenn ein Angreifer eine manipulierte Version der app, die umgeht oder Stamm überprüfen Code an AuthenticateAsync entfernt erstellt, werden diese anderen Speicherorten weiterhin auf einer Stamm-Umgebung zu reagieren können.

Einige dieser zusätzlichen Speicherorte sind in TodoAzure.dll definiert. Dies kann überraschend, sein, da dieser Assembly auf allen Plattformen für Xamarin, Logik enthält nicht nur Android. Wie Dotfuscator einfügen eine Check-Stamm – erkennt die Android-Geräte sein – in einer Assembly plattformunabhängigem? Beachten Sie, dass diese Dotfuscator-Config-Datei für das Projekt TodoAzure.Droid spezifisch ist, die auf das Projekt TodoAzure verweist. Wenn Dotfuscator TodoAzure.dll ändert, wird er nur die Assembly ändern, die Visual Studio oder Kopien von MSBuild für die im aktuellen Projekt TodoAzure.Droid verwenden. Der ursprüngliche TodoAzure Assembly des Projekts bleibt unverändert.

Anwendungsbenachrichtigung: Überprüft können die Ergebnisse ihrer Erkennung, um app-Code gemeldet werden. Dadurch können Sie die Berichterstattung und Antwort Verhaltensweisen angepasst haben, während der Überprüfungen mit eingefügten Dotfuscator Handle die Erkennung Arbeit. Der App_Code, der das Ergebnis der Erkennung empfängt wird eine Anwendung Benachrichtigung Sink aufgerufen.

Um die Schutzstrategie in diesem Szenario zu erfüllen, musste ich haben die app selbst zu deaktivieren, damit zukünftige Ausführungen der app mit einer Fehlermeldung beendet. Ich ausgewählt haben, fügen Sie diese Logik in einer Methode, TodoAzure.App.DisableIfCompromised, deaktivieren und sie als Senke für die Überprüfung durch die folgenden überprüfen Sie Eigenschaften festlegen:

• ApplicationNotificationSinkElement: Die Art des Codeelements; In diesem Fall kann eine Methode.
• ApplicationNotificationSinkName: Der einfache Name des Codeelements; In diesem Fall DisableIfCompromised.
• ApplicationNotificationSinkOwner: Der Typ, der das Codeelement enthält; In diesem Fall TodoAzure.App.

Der Speicherorte für die Überprüfung kann diese Senke-Methode aufrufen, wie sie öffentliche und statische ist. Um mit einem Häkchen kompatibel zu sein, die Methode ist synchron (nicht-Async) akzeptiert ein Argument für die einzelnen Bool und verfügt über einen void-Rückgabetyp.

Wenn aktiviert, ruft der Kontrollkästchen die-Methode auf und übergibt das Argument "true", wenn das Gerät als Stamm verknüpft ist und "false" andernfalls. Wenn dieses Argument ist "true" – erkennt, dass, wenn die Überprüfung auf rooting – die Methode speichert einen Wert an den lokalen Speicher, der angibt, die app ist jetzt deaktiviert. Eine zugehörige Eigenschaft, IsDisabled, macht den gespeicherten Wert:

// Definitions in TodoAzure.App
private const string DisabledPropertyKey = "AppStatus";
public static void DisableIfCompromised(bool wasCompromised)
{
  if (!wasCompromised) { return; }
  Current.Properties[DisabledPropertyKey] = new Random().Next();
  SavePropertiesNow();
}
public static bool IsDisabled =>
  Current.Properties.ContainsKey(DisabledPropertyKey);

Nachdem die Anwendung deaktiviert wurde, müssen künftige Ausführung anzuzeigende eine Fehlermeldung und beenden. Zu diesem Zweck überschrieben ich TodoAzure.LoginPage.OnAppearing, die aufgerufen wird, unmittelbar bevor die Anmeldeseite angezeigt wird, wenn die app gestartet hat. Wenn die Anwendung deaktiviert ist, blendet die Anmeldeseite diese Methode, wird ein Fehlerdialogfeld und dann beendet.

// Definition in TodoAzure.LoginPage
protected override async void OnAppearing()
{
  if (App.IsDisabled)
  {
    IsVisible = false;
    var message = "The security of this device has been compromised. "
      + " The app will exit.";
    await DisplayAlert("App deactivated", message, "Exit App");
    App.Exit(); // Delegates to platform-specific exit logic
  }
  base.OnAppearing();
}

Da ich Verteidigung gegen reverse Engineering-Team möchte, habe ich zusätzliche Maßnahmen, um sicherzustellen, dass die app für derartige Angriffe weniger fehleranfällig sein würde. Einen vagen Namen für den gespeicherten Wert AppStatus, verwendet, und legen Sie den Wert auf eine zufällige Zahl, die die Bedeutung des Werts verdeckt. Ich habe konfiguriert auch Dotfuscator um verschleiern die app wie DisableIfCompromised, Bezeichner umbenennen, damit ein Angreifer, Anzeigen von dekompilierten Code nicht einfach diese Methode als nicht von Interesse identifizieren. Nähere Informationen dazu, wie ich umbenennen Verbergung konfiguriert finden Sie in der Beispiel-Infodatei.

Aktion: Während die Senke (DisableIfCompromised-Methode) eine Eigenschaft, um sicherzustellen, dass zukünftige Ausführungen der app-Ausgang festlegt, beendet nicht selbst die app Wenn rooting zuerst erkannt wird. Stattdessen konfiguriert ich die Überprüfung zu diesem Zweck automatisch durch Festlegen der Action-Eigenschaft überprüfen zu beenden.

Wenn die Überprüfung ein Stammgerät erkennt, die Senke benachrichtigt und dann die app sofort beendet. Mit der Senke, anstatt die Überprüfung ausführen, indem Sie diese anfänglichen beenden, ich mehrere Kopien der beenden-Logik, über die app zu verteilen. Wie bei mehreren Standorten können mehrere Kopien der beenden-Logik für die app besser selbst schützen, wenn ein Angreifer Teil der Stamm-Überprüfungen entfernt wurde.

Erstellen und Testen der App

Nach dem Konfigurieren der Stamm überprüfen, beendet ich Fenster das Kontrollkästchen OK auswählen und dann ich meine Änderungen auf Dotfuscator-Config-Datei gespeichert haben, indem Sie die Datei auswählen | Speichern Sie Projekt. Ich erstellt TodoAzure.Droid in Visual Studio für die geschützte app testen, um sicherzustellen, dass ich den Stamm Check zum Erzwingen der beabsichtigten Schutzstrategie ordnungsgemäß konfiguriert.

Ich getestet, die app auf einem Gerät nicht als Stammelement, ein Stammgerät und einen Emulator aus. Auf dem Gerät nicht als Stammelement funktioniert die app in der Regel haben und dann zulassen, dass ich melden Sie sich zum Anzeigen der to-Do-Liste. Allerdings auf Rooting manipuliertes Gerät und auf dem Emulator aus, nach der Auswahl der Anmeldeschaltfläche die app unvermittelt geschlossen. Nach dem erneuten Starten der Anwendung, die app in angezeigten Fehlerdialogfeld angezeigt Abbildung 4; nachdem nach dem Schließen des Dialogfelds, die app einmal beendet. Zum Anzeigen der Anmeldeseite musste erneut deinstallieren und Neuinstallieren der app.

Abbildung 4 der geschützten TodoAzure.Droid in einem Emulator ausführen

Zusammenfassung

Ich hoffe, dass in diesem Artikel beigetragen hat beleuchten eine Möglichkeit, effektiv zu erkennen und reagieren auf den Stamm der Android-Geräten mithilfe von kostenlose Tools in Visual Studio enthalten. Obwohl ich eine bekanntes Beispiel-app als Referenz verwendet, können Sie die Vorschläge in diesem Artikel eingeführt, um alle Arten von Xamarin.Android apps und verschiedene andere Strategien zum Schutz anwenden.

Wenn Sie weitere Informationen über Überprüfungen interessiert sind, empfehlen wir die vorherigen MSDN Magazine Artikel zu lesen. In diesem erläutert ich weitere Arten von Überprüfungen, dass Sie in .NET Framework-apps übernehmen können und wie mit überprüft verhindern, Daten sicherheitsverletzungen dass.

Möglicherweise auch Interesse erweiterten Funktionen für Check- und Verbergen von Dotfuscator Professional Edition (bit.ly/2xgEZcs) oder das Begleittool für Java und herkömmliche Android-apps präemptiven Protection - DashO (bit.ly/2ffHTrN). Sie können Stand in alle Entwicklungen Prüfungen und präemptiven Schutz von PreEmptive Solutions auf Twitter folgen (twitter.com/preemptive) und besuchen Sie unsere Blog (preemptive.com/blog).

Eine alternative Schutzstrategie

Dieser Artikel bietet eine Strategie zum Erkennen von und reagieren auf Stamm Geräte, andere Strategien sind jedoch ebenfalls möglich. Die Strategie, die Sie auswählen, für die app geeignet sein sollte, der Kontext, in dem Ihre Anwendung verwendet wird, und die Sicherheitsrisiken, möchten Adresse ab. Sie können dann als Stamm überprüft wird, um die ausgewählte Strategie zu implementieren anwenden. Für die Instanz, wenn Ihre app nicht unter keinen Umständen beenden muss, können Sie konfigurieren einen Stamm überprüfen deaktivieren bestimmter Funktionen bei der rooting erkannt wird, anstatt die Anwendung verlassen.

Eine einzelne app müssen möglicherweise auch als Reaktion auf rooting unterschiedlich, je nach Informationen, die zur Laufzeit bekannt. Erwägen Sie eine app, die in mehreren geografischen Regionen zur Verfügung steht. Die app-Antwort auf rooting müssen möglicherweise nach Region zur Einhaltung der örtlich anwendbaren Gesetzen und Vorschriften, variieren, insbesondere dann, wenn diese Antwort enthält den störungsprotokolle zurück an den Entwickler ("phoning Home") zu senden.

Beim Entwickeln einer Schutzstrategie für die müssen Sie auch die Auswirkungen erwägen, die Ihre Strategie für Benutzer Ihrer App hat, die absichtlich ihre Geräte in gutem Glauben als Stammelement aufweisen. Diese "Hauptbenutzer" könnte ein beträchtlicher Teil der Ihre Kunden und Geräte mit entfernten nutzungsbeschränkungen untersagen Laufwerk konnte diese Weg von Ihrer app. Sie müssen abwägen Sicherheitsrisiken mit Rooting manipulierten Geräten für die Business Risiken im Zusammenhang mit alienating gültige Benutzer können solche Geräte.

Für diesen Artikel davon ausgegangen, dass ich, dass TodoAzure.Droid sensible Daten behandelt, also um Daten vor Diebstahl und reverse Engineering-Team, Rooting manipulierten Geräten sollte auch völlig unzulässigen. Wenn ich die Daten stattdessen als nicht vertraulich behandelt wurde, konnte ich implementiert haben eine Schutzstrategie, mit dem Rooting manipulierten Geräten unter bestimmten Umständen kann dadurch für erfahrene Benutzer. In dieser Alternativen Strategie, anstatt die Anwendung selbst deaktivieren wird die app der Benutzer aus, wenn ein Stammgerät erkannt wird. Diese Warnung wird sichergestellt, dass der Benutzer kennt den unsicheren Status des Geräts und die etwaigen Risiken wie den Diebstahl von Anmeldeinformationen. Die Benutzer können Anmeldeversuch abbrechen oder akzeptieren die Risiken und die Anmeldung fortgesetzt.

Für die Benutzer warnen Verzweigung des geschützten TodoAzureAuth GitHub-Repositorys habe ich Dotfuscator CE zum Schützen von TodoAzure.Droid mit einem Stamm überprüfen, die diese alternativen Schutzstrategie implementiert konfiguriert. Die Infodatei für diese Verzweigung wird erläutert, die feinere Punkte der Konfiguration.

Beachten Sie, dass diese alternativen Strategie einen Kompromiss zwischen erfahrene Benutzer beim Zugriff und das Risiko von reverse Engineering. Unter diese Strategie kann risikoteilnehmer weiterhin die app auf ein Stammgerät zum Zweck der reverse Engineering installieren; im Warnungsdialogfeld wäre nicht beenden. Verwendet weiterhin Dotfuscator, um die app zu verbergen, bietet ein Maß an Schutz gegen reverse Engineering. Eine wirkliche app konnte Weitere Steuerelemente, wie das Anfordern von speziellen Authentifizierung die app auf ein Stammgerät nutzen implementieren.

Abbildung A zeigt die Warnung, die von der app, die bei der Ausführung unter einem Stammgerät angezeigt.

Abbildung einer TodoAzure.Droid, geschützt durch diese alternative Strategie, die in einem Emulator ausgeführt wird, nachdem der Benutzer die Schaltfläche "Login" auswählt

Joe Sewellist eine Software Engineering und technische Writer im Team Dotfuscator bei PreEmptive Solutions. Er wurde zuvor für die offizielle Xamarin-Blog und MSDN Magazine geschrieben.

Unser Dank gilt dem folgenden technischen Experten bei Microsoft für die Durchsicht dieses Artikels: David Britch
David Britch arbeitet in der Xamarin-Dokumentationsgruppe bei Microsoft. Er wurde für einen Bereich von Software Development Veröffentlichungen z. B. Bücher, Prozessleitfaden-Dokumentation, referenzimplementierungen, Whitepapers, Videos und Trainern Kurse geschrieben.