App vor Cracking schützen

[Droidspirit]

Hallo,

Vorweg: Ich verwende auf meinen Androiden aus Prinzip keinerlei gecrackte Apps. Jedoch muß man sich mit dem Thema auseinandersetzen, möchte man seine eigenen Apps sicher gestalten.

Deshalb würde ich gerne mal über das Thema diskutieren.

Und zwar setze ich in meiner aktuellen App inAppBilling ein. Der Schlüssel, ob es sich bei der App um die Pro- oder Light-Version handelt, wird in einer SQLight-Datenbank gespeichert. Ich verwende den Google Lizensierungs-Dienst und die App ist mit ProGuard obfuscated.

Ich habe mir als Beispiel hierzu mal Plague Inc angeschaut. Dort wird ebenfalls inAppBilling verwendet und in einer Warez-Version läuft es so ab, dass das inAppBilling aufgerufen wird, man auf Bezahlen klickt, eine Fehlermeldung erscheint und anschließend ist die App in der Vollversion verfügbar. Wie Plague Inc allerdings intern mit der Freischaltung zur Pro-Version umgeht weiß ich allerdings nicht.

Wenn man eine mit ProGuard geschütze App dekompiliert und irgendwie den Code wieder herstellen kann, so hätte die Cracker die inAppBilling-Methode aus Plague Inc einfach ausgebaut. Auch in anderen Apps ist mir das nicht aufgefallen, also gehe ich davon aus, dass der Code einer mittels ProGuard geschützen App nicht wiederherstellbar ist.

Würde man meine App cracken wollen, so müßte man mit der gecrackten Version die SQLite-Datenbank mit ausliefern. D.h. sie müßten meine Tabellenstruktur nachbauen (mit einem gerooteten Device kommt man da ja ran), meine Schlüssel für die ProVersion irgendwie generieren, etc. Aber der ist ja ebenfalls alles obfuscated.
Hat denn schon jemand Erfahrung auf dem Gebiet gesammelt?

Viele Grüße

 

[Mike_SD]

Ich glaube du überschätzt ProGuard ein bisschen. Obfuscation ist zwar nicht verkehrt, da es den Code für Menschen schwerer lesbar macht, aber oft werden diese Cracks mit Scripten ausgeführt, die im Smali Code nach bestimmten Mustern suchern.

Sagen wir du hast im App folgende Zeile:

boolean isLicensed = myLVLChecker.getLVLResponse();

nach Obfuscation wird daraus:

boolean e = a.f();

Nicht schön zu lesen, aber ein Script verwirrst du damit nicht, weil die deine vergebenen Namen sowieso nicht beachten. Ein Cracking Script würde diese Zeile dann so ändern:

boolean e = Crack.getResponse(a);
//boolean e = a.f();

die Methode in der hinzugefügten Crack Klasse sähe dann evtl. so aus

public static boolean getResponse(Object o) {
    return true;
}

In Wirklichkeit wäre der Code nach dem Dekompilieren natürlich in Smali, nicht Java, aber das spielt ja keine Rolle.



Dein erster Schritt sollte also sein, dich damit vertraut zu machen, wie Apps überhaupt gecrackt werden. Dazu wirst du nicht drumherum kommen, dir Anti-LVL zu besorgen. Darin ist auch apktool enthalten um APKs dekompilieren zu können. Wenn dein App schon gecrackt wurde, kannst du wunderbar den Smali Code der Original- und der gecrackten Version vergleichen und so sehen, wo gebastelt wurde. Wenn nicht, lass Anti-LVL drüberlaufen und schau, ob das Script deine InApp Sachen erfolgreich aushebelt.

Darüber hinaus solltest du dir darüber Gedanken machen, ob du irgendwie prüfen kannst, ob die Logik des Programms verändert wurde. Wenn du z.B. abfragst, ob gezahlt wurde, könntest du z.B. auch eine Abfrage machen, bei der (wenn alles in Ordnung ist) false rauskommen müsste. Wenn da dann auf einmal true erscheint, dann wurde die LVL Anbindung modifiziert.

 

[Droidspirit]

Mit dem APKTool und Dex2Jar habe ich mich schon ein wenig beschäftigt. Das mit Anti-LVL und die Prüfung auf Veränderung der Programm-Logik sind gute Tipps. Das werde ich mir mal anschauen, danke.

 

[Mike_SD]

Gibt übrigens auch noch andere Varianten, z.B. kannst du dir anschauen, ob die classes.dex noch dem Original entspricht oder modifiziert wurde, aber auch für Sachen wie getDate() gibt es in Anti-LVL hooks, so dass immer das gleiche Datum ausgegeben wird. Was man dann auch wieder mit einem Sanity Check prüfen kann, indem z.B. eine neue Datei schreibt und deren Datum prüft.

 

[Droidspirit]

Wir haben gerade eine Stunde über das Thema diskutiert. Im Grunde ist kaum eine App davor wirklich sicher gecrackt zu werden. Daher haben wir folgendes in den Raum gestellt:

Ist es überhaupt sinnvoll eine App dagegen zu schützen, dass sie gecrackt wird?

Mal angenommen sie landet irgendwann auf einer Warez-Seite, dann erlangt sie dadurch ja auch noch weiter an Bekanntheit. Im Vergleich zum gesamten Nutzerkreis gesehen stellen die, die eine gecrackte Version benutzen, ja eher eine Minderheit dar. Also könnte man eigentlich auch auf die paar Leute pfeiffen. Updates erhalten diese Versionen ja eh nicht, die Apps müßten also wieder neu gecrackt werden.

Wie seht ihr das?

 

[reneph]

Wie seht ihr das?

Wenn deine Annahme in der Realität auch so ist, also nur ein recht geringer Kreis an Nutzern eine illegale Version benutzt und es stattdessen mehr Bekanntheit und somit mehr echte Verkäufe zustande kommen, dann wär es mir recht egal. Ärgern würde es mich dennoch.

Man muss halt auch versuchen rauszufinden, warum manche User illegale Versionen verwenden. Ggf. erreicht man auch einige solcher "Kunden"/Nutzer, wenn man alternative App-Angebote wahrnimmt, wo man nicht nur per Kreditkarte bezahlen kann.

Mal so nebenbei gefragt: ist das Thema jetzt rein interessehalber im Vorhinein oder sind schon illegale Versionen deiner App(s) im Umlauf?

 

[DieGoldeneMitte]

Grundsätzlich sollte man seine Energie lieber dahingehend investieren, dass die legalen User möglichst viel Spaß mit/Nutzen von der App haben.

Ich will für Leute programmieren, nicht gegen!

 

[reneph]

dass die legalen User möglichst viel Spaß mit/Nutzen von der App haben.

Das ist soweit auch richtig, aber ich würde ungern ein kommerzielles Produkt pflegen und Herzblut rein stecken, welches Hochkonjunktur bei illegalen Nutzern hat und sich dann rein monetär nicht mehr lohnt.

Ich will für Leute programmieren, nicht gegen!

Das ist ja auch korrekt, aber wenn man was kommerzialisiert, dann macht der Programmierer das (zurecht) auch für sich!

 

[Droidspirit]

Mal so nebenbei gefragt: ist das Thema jetzt rein interessehalber im Vorhinein oder sind schon illegale Versionen deiner App(s) im Umlauf?

Meine aktuelle App, an der ich jetzt seit einem Jahr arbeite, soll nun vor Weihnachten online gehen.

Sie wird es in zwei Versionen geben. Die eine wird von Bundesbehören eingesetzt, die zweite ist für Privatanwender gedacht. Vom Prinzip her machen beide Versionen das Selbe, nur sie haben halt unterschiedliche Namen und Logos. Würde ich nur eine Version rausbringen, dann sieht das ein wenig zweckentfremdet aus.

Ich habe vor inAppBilling einzusetzen, weil man dann bei der Freischaltung auf einen Export/Import der bereits hinterlegten Anwendungsdaten verzichten kann. Die freie Version beinhaltet zwar alle Funktionen der Pro-Version, man kann aber z.B. nur eine gewisse Anzahl an Daten hinterlegen und es wird Werbung an einigen Stellen angezeigt.

Der beste Zeitpunkt sich mit dem Thema auseinanderzusetzen ist halt vor der Veröffentlichung

Das mit den Bezahlmöglichkeiten habe ich mir auch überlegt. Malen mit Ben ist zwar kostenlos und ohne Werbung, aber die Donate-Version wird auch nur über AndroidPit gekauft. Über den Playstore kommt da gar nichts rum.

Andererseits will ich mit dem aktuellen Produkt den internationalen Markt ansprechen und mittels GoogleWallet gebe ich den gesamten Bezahl- und Rückgabeprozess an Google ab und muß mich nicht weiter drum kümmern.

Der ursprüngliche Beitrag von 13:30 Uhr wurde um 14:12 Uhr ergänzt:

Edit:

Ich wurde gerade von einem Bekannte auf eine Idee gebracht:

Ein Nutzer kauft meine App im Playstore. Dieser wird dann auf meinem Server eingetragen.

Dieser nutzer crackt nun meine App und stellt sie auf Warez-Seiten online. Ein Anderer lädt sich die gecrackte Version herunter und installiert sie.

Meine App prüft nun (wenn die Datenverbindung aktiviert und mein Server erreichbar ist) gegen den Server, ob dieser Nutzer (auf Android meldet sich ja jeder mit seinem Google-Account an) die Berechtigung besitzt, meine App in der Pro-Version auszuführen. Falls nicht, so wird eben wieder die Light-Version aktiviert.

 

[Mike_SD]

Ist es überhaupt sinnvoll eine App dagegen zu schützen, dass sie gecrackt wird?

Kommt drauf an...

Machen kann man viel. Man kann mit nativem Code arbeiten um Cracking Scripte zu unterlaufen, man kann eine Art Selbstüberprüfung einbauen und die in 20 verschiedenen Klassen verstreuen, so dass er auch von Hand schwer zu entfernen ist. Man kann den Cracking-Schutz auch so gestalten, dass er sich scheinbar leicht entfernen lässt, aber nach ner Weile doch wieder greift.

Ist dann halt alles eine Frage des Aufwands. Generell sollte man aber nach dem Prinzip 'ganz oder gar nicht' verfahren, denn eine halbherziger Schutz, der sich automatisiert in 20 Sekunden entfernen lässt, der nützt gar nichts, und ärgert höchstens lizensierte User wenn er nicht richtig funktioniert.

Bei der 'ganz' Variante muss man aber schon 2-3 Wochen Entwicklungsaufwand einplanen, und in Kauf nehmen, dass man evtl. selbst Abstriche beim Testen/Weiterentwickeln der App machen muss, denn wenn sich die App selbst prüft, dann muss man auch in einem Testbuild dafür sorgen, dass der Schutz nicht greift.

Es gibt viele gute Apps, die nie wirklich Geld verdienen. Wenn echtes Geld reinkommt, dann können 10% zusätzliche Verkäufe, die man evtl. erlangt, den Aufwand rechtfertigen. Wenn jedoch <1000€/Jahr rausspringen, dann ist die Zeit nicht gut investiert.

Als Alternative kann man auch darüber nachdenken, die App erstmal so zu veröffentlichen und (wenn sie wirklich einschlägt) den Cracking-Schutz im Rahmen eines Updates nachzurüsten. Klar hat man dann möglicherweise schon eine gecrackte Version im Umlauf, aber wenn man im Zuge dieses Updates ein neues Feature oder ein neues Interface-Design bringt, dann müssen Warez-User halt damit leben eine veraltete Version zu nutzen.

 

[xminister]

Meine App prüft nun (wenn die Datenverbindung aktiviert und mein Server erreichbar ist) gegen den Server, ob dieser Nutzer (auf Android meldet sich ja jeder mit seinem Google-Account an) die Berechtigung besitzt, meine App in der Pro-Version auszuführen. Falls nicht, so wird eben wieder die Light-Version aktiviert.

Und wo soll da jetzt das Problem sein, eben diesen Code für die Abfrage zu entfernen oder ganz einfach zu blocken?

 

[Mike_SD]

Meine App prüft nun (wenn die Datenverbindung aktiviert und mein Server erreichbar ist) gegen den Server, ob dieser Nutzer (auf Android meldet sich ja jeder mit seinem Google-Account an) die Berechtigung besitzt, meine App in der Pro-Version auszuführen. Falls nicht, so wird eben wieder die Light-Version aktiviert.

Du beschreibst da quasi die Funktionsweise der LVL, nur dass du sie selbst schreiben müsstest.

Probleme mi diesem Ansatz:
-lässt sich genau wie ein LVL Check cracken/auskommentieren
-du musst zuverlässig und verzögerungsfrei an die Liste der lizensierten Käufer kommen
-du musst verschlüsselt mit dem Server kommunizieren, da sich der Traffic sonst leicht mitsniffen lässt
-lässt sich leicht ausser Kraft setzen wenn der Nutzer die Netzwerkverbindung zu deinem Server unterbindet
-von Hand leicht zu cracken weil ich nur den Hostname deines Servers von server.de in serve.rde ändern und die APK rekompilieren muss

 

[Droidspirit]

Okay, das klingt logisch. Und auch das mit der Kosten/Nutzen-Rechnung von Deinem vorigen Post.

Wie handhabt ihr das denn in euren Produkten?

 

[Mike_SD]

Ich für meinen Teil, so wie ich es skizziert hatte. App released nur mit LVL ohne Cracking-Schutz, und im Zuge eines größeren Updates einen ziemlich aufwendigen Schutzmechanismus nachgerüstet, als dann die Verkäufe richtig angelaufen sind.

Muss dazu sagen, dass ich mich erst dazu entschlossen hab, als ich gesehen hab, dass gecrackte Versionen bereits nach 30 min nach einem Update im Umlauf waren.