Manchmal müssen Sie ein Passwort in der App selbst speichern, z. B. einen Benutzernamen / ein Passwort für die Kommunikation mit Ihrem eigenen Server. In diesen Fällen ist es nicht möglich, dem normalen Vorgang des Speicherns von Kennwörtern zu folgen - d. H. Das Kennwort zu hashen, den Hash zu speichern und mit Hash-Benutzereingaben zu vergleichen -, da Sie keine Benutzereingabe zum Vergleichen des Hashes haben. Das Passwort muss von der App selbst bereitgestellt werden. Wie schützt man das gespeicherte Passwort in der APK? Wäre eine passwortgenerierende Funktion wie die unten stehende einigermaßen sicher?
Klartext:
%Vor%Einfache Verschleierung:
%Vor%Ich weiß, dass ProGuard einige Funktionen zur Verschleierung besitzt, aber ich bin neugierig, was die obige "Verschleierung" -Technik macht, wenn sie kompiliert wird und wie schwer es für jemanden ist, es herauszufinden, indem er in der APK sucht und / oder benutzt andere anspruchsvollere Techniken?
tl; dr Wenn Sie wissen, wie APK zu dekompilieren ist, können Sie leicht das Passwort erhalten, egal wie verschleiert der Code war. Passwörter nicht in APK speichern, es ist nicht sicher.
Ich weiß, dass ProGuard einige Fähigkeiten zur Verschleierung hat, aber ich bin neugierig darüber, was die obige "Verschleierungstechnik" macht, wenn sie kompiliert wird, und wie schwer es für jemanden wäre, es herauszufinden, indem er hineinschaut die APK und / oder mit anderen komplizierteren Techniken?
Ich werde Ihnen zeigen, wie einfach es ist. Hier ist ein Android SSCCE , das wir dekompilieren werden:
MyActivity.java :
main.xml :
Nach dem Kompilieren und Ausführen können wir $()&HDI?=! auf einem TextView sehen.
Lassen Sie uns ein APK dekompilieren:
unzip myapp.apk oder klicke mit der rechten Maustaste auf die APK und Unzip here .
classes.dex datei erscheint. classes.dex in eine JAR-Datei mit dex2jar . Nach der Ausführung von dex2jar.sh classes.dex , classes_dex2jar.jar file
erscheint. Wenn wir einen Java-Decompiler auf classes_dex2jar.jar verwenden, zum Beispiel JD-GUI , rufen wir einen solchen Java-Code von MyActivity.class :
ProGuard kann nicht viel helfen, der Code wird immer noch gut lesbar sein.
Aus dem oben Gesagten kann ich Ihnen bereits eine Antwort auf diese Frage geben:
Wäre eine passwortgenerierende Funktion wie die folgende sinnvoll? sicher?
Nein. Wie Sie sehen, erhöht sich die Schwierigkeit, entschleierten Code ein wenig zu lesen. Wir sollten den Code nicht so verschleiern, weil:
In der offiziellen Android-Dokumentation, im Abschnitt Sicherheit und Design , sind sie " Berücksichtigen Sie dies, um Ihren öffentlichen Google Play-Schlüssel zu schützen:
Um Ihren öffentlichen Schlüssel vor böswilligen Benutzern und Hackern zu schützen, tun Sie dies nicht Betten Sie es in einen beliebigen Code als Literal-String ein. Konstruieren Sie stattdessen das String zur Laufzeit aus Stücken oder verwenden Sie Bit-Manipulation (zum Beispiel XOR mit einer anderen Zeichenfolge), um den eigentlichen Schlüssel zu verbergen. Der Schlüssel selbst ist keine geheimen Informationen, aber Sie wollen es nicht einfach machen für Hacker oder böswilliger Benutzer, um den öffentlichen Schlüssel durch einen anderen Schlüssel zu ersetzen.
Ok, also versuchen wir es:
%Vor% Gibt $()&HDI?=! auf einem TextView , gut.
Dekompilierte Version:
%Vor%Sehr ähnliche Situation wie zuvor.
Selbst wenn wir die extrem komplizierte Funktion soStrongObfuscationOneGetsBlind() hatten, können wir immer dekompilierten Code ausführen und sehen, was er produziert. Oder debuggen Sie es Schritt für Schritt.
Tags und Links android obfuscation decompiling deobfuscation