Wie kann man eine "Android Unlocker" App sicherer gegen Cracker machen?

Question

Für die kostenpflichtige Version meiner App habe ich mich für die Unlocker-App Route entschieden, da sie einfach zu implementieren ist, erlaubt individuelle Statistiken in der Entwicklerkonsole, aber hauptsächlich, weil ich keine 2 Codebasen pflegen müsste Version und ein anderes für die kostenpflichtige Version). Selbst wenn ich ein CVS benutze (was ich tue), wäre es immer noch ein Schmerz im Nacken, um Features und Bugfixes zu verschmelzen. Die Unlocker App ist viel einfacher zu implementieren ...

Aber das kommt mit einem gravierenden Nachteil, es ist wirklich einfach, die Sicherheitsüberprüfung zu überholen; es sei denn, ich verpasse hier etwas.

Egal was ich tue, wird eine solche Implementierung immer auf eine einfache if, wie diese führen:

if(Program.isPremiumVersion()) { 
    // Remove ads... 
} 

Die isPremiumVersion() Methode der Verantwortliche für die Arbeit bei der Prüfung für den bezahlten unlocker App-Installation ist, wenn die Zertifikate übereinstimmen und all das Zeug. Ja, die Unlocker-App ist durch die LVL geschützt (obwohl ich ein paar Artikel gelesen habe, in denen erwähnt wird, wie unsicher LVL ist, aber das ist im Moment nicht der Punkt). Aber am Ende, egal wie komplex der Code innerhalb isPremiumVersion() wird, führt es immer zu einem true oder Wert.

Das Überschreiben einer solchen Sicherheitsfunktion ist nur eine Frage des Reverse Engineering des Codes und es immer true zurückgeben. Es ist nicht? Wie können wir unsere Android-Apps davor schützen? Und ja, der Code ist mit ProGuard verschleiert. Dennoch sollte es für jemanden, der gut genug ist, nicht zu schwer sein.

Bitte beachten Sie, dass ich nicht versuche, die Cracker zu bekämpfen, wir können einfach nicht gewinnen. Ich werde dabei nicht den Schlaf verlieren und unzählige Stunden mit der "perfekten Lösung" verschwenden. Ich suche nur nach einer Möglichkeit, es ein wenig sicherer zu machen. Das scheint zumindest theoretisch so einfach zu knacken. Bin ich aber falsch?

Irgendwelche Ideen, um die Sicherheit einer solchen Funktion zu verbessern?

Answer 1

Sie bereits gesehen haben, aber hier ist ein Code für die Implementierung, über was Sie sprechen:

http://groups.google.com/group/android-developers/browse_thread/thread/4ad3d67f735f16d7/948b4f9eee2490a3?pli=1

Es prüft, ob die Unterschriften auf der freien und unlocker App gleich sind. Es ist also nicht möglich, dass jemand eine App mit dem richtigen Namen künstlich erstellt, da die Signaturen unterschiedlich sind. Es ist jedoch immer noch möglich für Leute, die apk vom Telefon zu reißen und zu verteilen. Die einzige Möglichkeit, dies zu bekämpfen, wäre die Verwendung einer Serverauthentifizierung, die jedoch Kosten und Komplexität verursacht.

Answer 2

Es gibt keinen einfachen Weg darum.

Sie müssen versuchen, es zu maskieren. Hier sind ein paar Tipps:

Tipp 1: Returning Boolean ist zu offensichtlich. Versuchen Sie, einen Wert (z. B. int) zurückzugeben. Verwenden Sie dann einen Vergleich, um festzustellen, ob dies ein gültiger bekannter Rückgabewert ist.

Zum Beispiel: Holen Sie sich die MD5 einer Zeichenfolge, die etwas enthält, von dem Sie sagen können, ob es Premium ist oder nicht. Angenommen, Sie haben in jeder App eine statische abschließende Zeichenfolge. Vielleicht beginnt der md5 mit einer 9 und der andere mit einer 1. In diesem Fall berechnen Sie den md5 und sehen, ob er größer ist als eine "zufällige" Zahl, von der Sie wissen, dass sie zwischen den beiden anderen Zahlen liegt. Nehmen wir an, die MD5 von "Premium" ist 987 und die MD5 von "Free" ist 123. Sie können die MD5 berechnen und mit 456 vergleichen.

Tipp 2 - Noch besser: Duplizieren Sie einen Code und verwenden Sie jedes Mal andere Werte (anstelle von 456)! Hoffentlich wird es dadurch schwieriger, den verschleierten Code zu entschlüsseln.

Ich weiß, dass alle diese Überprüfungen schließlich zu einem booleschen Wert zugeordnet werden (if(1 > 2) wird zu if(true) ausgewertet werden), aber es sollte schwieriger sein, Ihre App Reverse Engineering.

Tipp 3: Führen Sie die Überprüfungen für "isPremium" nicht an den offensichtlichsten Stellen durch. Führen Sie zum Beispiel die Überprüfung nicht durch, wenn Sie Ihre App starten, da dies der naheliegendste Ort dafür ist. Es kann schwierig sein, bestimmte offensichtliche Punkte zu vermeiden, wenn Sie bedingte Logik abhängig von der Version der App haben möchten, aber geben Sie hier Ihr Bestes!

Tipp 4: bauen und verschleiern Sie Ihre App. Führen Sie Reverse-Engineering-Tools gegen Ihre apk. Lesen Sie es und sehen Sie, wie es aussieht.

Schließlich, schauen Sie sich dieses Google IO Präsentation jeden Tag beim Frühstück: Evading Pirates and Stopping Vampires using License Verification Library, In-App Billing, and App Engine

[EDIT - ein paar weitere Tipps]

Tipp 6: versuchen, den Code, den Sie überprüfen verwenden zu verwenden, um an vollkommen gültigen Orten. Dies könnte verschleiern, was Sie wirklich dort tun. Dies könnte den Aufruf des Codes beinhalten, um zu prüfen, welche Version der App das ist, aber nichts Sinnvolles damit zu tun. Oder, in meinem vorherigen Beispiel, den md5 mit 012 oder 999 zu vergleichen, nur um die tatsächliche Verwendung dieser Variablen zu verwässern.

Tipp 7: Statt sich auf eine einzelne Zeichenfolge zu verlassen, könnten Sie die Zeichenfolge zur Laufzeit konstruieren. Finale und Statik könnten zu viel Aufmerksamkeit auf sich ziehen, also könnte es eine gute Sache sein, diese zu vermeiden.

Tipp 8: nicht je den LVL-Code verwenden, wie in Google-Tutorials zur Verfügung gestellt. Ändern Sie es. Viel!

Hinweis: Ich bin nicht sicher, ob einige dieser Tipps tatsächlich einen großen Unterschied machen, aber Sie sollten gute Chancen haben, Crackers das Leben ein bisschen härter zu machen.