Manipulationserkennung
Die Manipulationserkennung trägt entscheidend dazu bei, die Integrität und Sicherheit von Softwareanwendungen zu gewährleisten. Im .NET-Umfeld ist Babel Obfuscator ein leistungsfähiges Tool, um Manipulationen zu erkennen. Mit der Manipulationserkennung von Babel geben Entwickler ihren Anwendungen eine zusätzliche Schutzebene und führen als Reaktion auf Manipulationsversuche benutzerdefinierte Logik aus.
Bei einer signierten Assembly kann schon .NET Framework erkennen, ob eine Anwendung manipuliert wurde. Babel Obfuscator geht jedoch einen Schritt weiter und bietet eine zusätzliche Absicherung. Wenn Sie die Manipulationserkennung in Babel einschalten, kann die verschleierte Assembly selbst prüfen, ob sie manipuliert wurde. Im Fall einer Manipulation kann die Anwendung beendet werden, oder es werden benutzerdefinierte Methoden in der Assembly aufgerufen, die kontrollierter auf die Manipulation reagieren.
Auf mobilen Zielen mit .NET MAUI übernimmt ab Version 12 eine Prüfung der Paketintegrität die Manipulationserkennung, anstelle des Abbild-Hashs der Desktop-Ziele: unter Android eine Prüfung der APK-Signatur (siehe Paketintegrität unter Android (MAUI)) und unter iOS eine Prüfung der Bundle-ID und des Bereitstellungsprofils (siehe Paketintegrität unter iOS (MAUI)). Auf Desktop-Zielen bildet die Prüfung einen Hash des geladenen Abbilds im Speicher. Bei Apps, die als einzelne Datei, getrimmt oder mit AOT veröffentlicht werden, ist sie deshalb wirkungslos. Babel gibt eine Warnung aus, wenn die Manipulationserkennung für eine solche Veröffentlichung angefordert wird.
Manipulationserkennung konfigurieren
Die Manipulationserkennung lässt sich in Babel einfach einschalten: entweder auf der Befehlszeile mit dem entsprechenden Schalter oder über die Babel-Aufgabe, indem Sie das Attribut TamperingDetection in die Projektdatei aufnehmen.
Befehlszeile
babel myapp.exe --tamperingdetectionMSBuild-Aufgabe Babel
<PropertyGroup>
<TamperingDetection>true</TamperingDetection>
</PropertyGroup>
<Babel TamperingDetection="$(TamperingDetection)" />Sobald die Manipulationserkennung eingeschaltet ist, prüft die verschleierte Assembly zur Laufzeit automatisch, ob sie manipuliert wurde. Ist das der Fall, wird die Anwendung beendet.
Auf Desktop-Zielen (.NET Framework und .NET auf der CoreCLR) berechnet die Prüfung einen Hash des geladenen Abbilds im Speicher und vergleicht ihn mit einem Hash, der bei der Verschleierung in die Assembly eingetragen wurde. Dieses Verfahren setzt voraus, dass die Assembly als speicherabgebildetes Abbild vorliegt. Es greift daher nicht bei Anwendungen, die als einzelne Datei, getrimmt oder mit AOT veröffentlicht werden. Wenn Sie die Manipulationserkennung für eine solche Veröffentlichung anfordern, warnt Babel, dass die Prüfung wirkungslos wäre.
Paketintegrität unter Android (MAUI) Ultimate
Der oben beschriebene Hash des Abbilds im Speicher lässt sich unter Android nicht verwenden: Die Anwendung läuft auf MonoVM, und die verwalteten Assemblys sind im APK verpackt, statt als Windows-PE-Abbild geladen zu werden. Ab Version 12 bietet Babel für Ziele mit .NET for Android (MAUI) einen gleichwertigen Schutz, der auf der Integrität der APK-Signatur beruht.
Wenn Sie die Manipulationserkennung für eine net*-android-Assembly einschalten, fügt Babel eine Laufzeitprüfung ein. Sie liest das Zertifikat, mit dem das laufende APK signiert wurde, und vergleicht es mit einem oder mehreren Fingerabdrücken vertrauenswürdiger Signierer, die Sie bei der Verschleierung pinnen. Wird die Anwendung mit einem anderen Schlüssel neu signiert oder neu verpackt, was der klassische Weg ist, eine veränderte App weiterzuverbreiten, stimmen die Fingerabdrücke nicht mehr überein, und die Reaktion auf die Manipulation wird ausgelöst: Die Anwendung wird beendet, oder Ihr benutzerdefinierter Handler wird aufgerufen (siehe Benutzerdefinierte Aktion bei erkannter Manipulation). Da die Prüfung die Paketsignatur des Betriebssystems und nicht das verwaltete Abbild untersucht, funktioniert sie auch mit Trimming und AOT-Kompilierung (Ahead-of-Time).
Das Signaturzertifikat pinnen
Babel kann das Signaturzertifikat nicht allein aus der Assembly kennen, denn es wird erst später angewendet, wenn das APK signiert wird. Deshalb pinnen Sie den SHA-256-Fingerabdruck des erwarteten Zertifikats mit der Option --trustedsigner. Die Option lässt sich wiederholen, sodass Sie mehr als ein Zertifikat pinnen können (zum Beispiel einen Upload-Schlüssel und einen App-Signaturschlüssel von Google Play):
babel MyApp.dll --tamperingdetection --trustedsigner 2924C53EE9C511E9F26E0720FD8151064F7621681667D7AB1899E551CDB25104Über die MSBuild-Aufgabe:
<PropertyGroup>
<TamperingDetection>true</TamperingDetection>
<TrustedSigner>2924C53EE9C511E9F26E0720FD8151064F7621681667D7AB1899E551CDB25104</TrustedSigner>
</PropertyGroup>
<Babel TamperingDetection="$(TamperingDetection)" TrustedSigner="$(TrustedSigner)" />Den SHA-256-Fingerabdruck Ihres Signaturzertifikats erhalten Sie mit keytool (aus dem Keystore) oder mit apksigner (aus einem erstellten, signierten APK):
keytool -list -v -keystore my-release.keystore -alias my-alias | grep -i SHA256
# or, from a signed APK:
apksigner verify --print-certs MyApp.apk | grep -i 'SHA-256'Entfernen Sie die Doppelpunkte, die als Trennzeichen dienen. Der an --trustedsigner übergebene Wert ist eine hexadezimale Zeichenfolge mit 64 Zeichen.
Wenn Sie die Manipulationserkennung für ein Android-Ziel einschalten, ohne einen vertrauenswürdigen Signierer zu pinnen, gibt Babel eine Warnung aus und weicht auf eine schwächere Prüfung aus, die nur feststellt, ob das Paket signiert ist. Übergeben Sie für einen echten Schutz immer --trustedsigner (TrustedSigner) mit dem Fingerabdruck Ihres Release-Zertifikats.
Paketintegrität unter iOS (MAUI) Ultimate
Unter .NET for iOS (MAUI) wird der verwaltete Code vollständig vorab kompiliert (AOT), und es gibt kein speicherabgebildetes PE-Abbild, über das ein Hash gebildet werden könnte. Das Verfahren der Desktop-Ziele lässt sich daher nicht verwenden. Ab Version 12 bietet Babel für net*-ios-Ziele eine Prüfung der Paketidentität: Zur Laufzeit vergleicht die verschleierte App ihre eigene Bundle-ID und, wenn sie aus einem Build mit Bereitstellungsprofil läuft, die Apple-Team-ID mit Werten, die Sie bei der Verschleierung pinnen. Stimmt einer der Werte nicht mehr überein, zum Beispiel nachdem die App neu verpackt oder mit einer anderen Entwickleridentität neu signiert wurde, wird die Reaktion auf die Manipulation ausgelöst (die Anwendung wird beendet, oder Ihr benutzerdefinierter Handler wird aufgerufen). Die Prüfung läuft beim Prozessstart aus einem Modulinitialisierer und funktioniert unter vollständigem AOT.
Bundle-ID und Team-ID pinnen
Pinnen Sie die erwarteten Werte mit den Optionen --trustedbundle und --trustedteam:
babel MyApp.dll --tamperingdetection --trustedbundle com.mycompany.myapp --trustedteam ABCDE12345Über die MSBuild-Aufgabe:
<PropertyGroup>
<TamperingDetection>true</TamperingDetection>
<TrustedBundle>com.mycompany.myapp</TrustedBundle>
<TrustedTeam>ABCDE12345</TrustedTeam>
</PropertyGroup>
<Babel TamperingDetection="$(TamperingDetection)"
TrustedBundle="$(TrustedBundle)"
TrustedTeam="$(TrustedTeam)" />--trustedbundleist derCFBundleIdentifierIhrer App (ausInfo.plist).--trustedteamist Ihre 10-stellige Apple-Team-ID (sichtbar im Apple Developer Portal unter „Membership“ und im Identitätsnamen Ihres Signaturzertifikats, zum BeispielApple Development: You (ABCDE12345)).
Jeder gepinnte Wert ist optional und wird unabhängig geprüft: Pinnen Sie die Bundle-ID, die Team-ID oder beide.
Die Prüfung der Team-ID liest das eingebettete Bereitstellungsprofil der App (embedded.mobileprovision), das in Entwicklungs-, Ad-hoc- und Enterprise-Builds vorhanden ist. Im iOS-Simulator ist es nicht verfügbar (dort wird die Prüfung übersprungen), und aus App-Store-Builds wird es entfernt (Apple signiert sie neu). Verlassen Sie sich für die Verteilung über den App Store daher auf die gepinnte Bundle-ID. Wenn Sie die Manipulationserkennung für ein iOS-Ziel einschalten, ohne einen der beiden Werte zu pinnen, gibt Babel eine Warnung aus und führt keine Integritätsprüfung durch.
Benutzerdefinierte Aktion bei erkannter Manipulation
Um die Reaktion auf Manipulationsversuche anzupassen, können Entwickler in ihrer Assembly eine eigene Methode definieren. Mit dem Attribut [Obfuscation] und der Funktion „on tampering detected method“ wird eine benutzerdefinierte Methode bestimmt, die das Manipulationsereignis behandelt. So können Entwickler eigene Logik umsetzen und angemessen reagieren, wenn eine Manipulation erkannt wird. Sie können zum Beispiel ein verborgenes Flag setzen, falsche Ergebnisse erzeugen oder gezielte Gegenmaßnahmen auslösen, um die Auswirkungen der Manipulation zu begrenzen. Derselbe Handler wird für die Abbildprüfung auf dem Desktop und für die Prüfungen der Paketintegrität unter Android und iOS verwendet, sodass eine einzige Methode alle Ziele abdeckt.
class CustomTampering
{
public static bool HasBeenTampered { get; internal set; }
[Obfuscation(Feature = "on tampering detected method")]
static void OnTamperingDetected()
{
HasBeenTampered = true;
}
}Der Code zeigt eine einfache Implementierung für die Behandlung einer erkannten Manipulation.
Ist HasBeenTampered auf true gesetzt, wurde eine Manipulation erkannt. Es empfiehlt sich, in diesem Fall bestimmte Aktionen oder bestimmten Code auszuführen:
if (CustomTampering.HasBeenTampered)
{
// Tampering detected: Implement appropriate security measures or handle the
// situation accordingly.
// Examples include logging the incident, notifying system administrators,
// disabling critical functionality or terminating the application.
}Zusammengefasst: Mit der Manipulationserkennung von Babel Obfuscator erhöhen Entwickler die Sicherheit ihrer .NET-Anwendungen erheblich. Weil sie Manipulationsversuche erkennen und darauf reagieren können, schützen sie ihre Software vor unbefugten Änderungen, wahren die Datenintegrität und schützen vertrauliche Informationen.