wake-up-neo.com

Wie vermeide ich Reverse Engineering einer APK-Datei?

Ich entwickle eine Zahlungsverarbeitungs-Appfür Android und möchte verhindern, dass ein Hacker über die Datei APK auf Ressourcen, Assets oder Quellcode zugreift.

Wenn jemand die Erweiterung .apk in .Zip ändert, kann er sie dekomprimieren und problemlos auf alle Ressourcen und Ressourcen der App zugreifen. Mit dex2jar und einem Java-Dekompiler kann er auch auf den Quellcode zugreifen. Das Reverse Engineering einer Android-APK-Datei ist sehr einfach. Weitere Informationen finden Sie unter Stapelüberlauf-Frage Reverse Engineering von einer APK-Datei in ein Projekt.

Ich habe das mit dem Android SDK gelieferte Proguard-Tool verwendet. Beim Reverse Engineering einer APK-Datei, die mit einem signierten Keystore und Proguard erstellt wurde, wird der Code verschleiert.

Die Namen der Android-Komponenten bleiben jedoch unverändert, und einige Codes, wie in der App verwendete Schlüsselwerte, bleiben unverändert. Gemäß der Proguard-Dokumentation kann das Tool die in der Manifest-Datei genannten Komponenten nicht verschleiern.

Jetzt sind meine Fragen:

  1. Wie kann ich komplett verhindernReverse Engineering eines Android APK? Ist das möglich?
  2. Wie kann ich alle Ressourcen, Ressourcen und den Quellcode der App schützen, damit Hacker die APK-Datei in keiner Weise hacken können?
  3. Gibt es eine Möglichkeit, das Hacken schwieriger oder sogar unmöglich zu machen?Was kann ich noch tun, um den Quellcode in meiner APK-Datei zu schützen?
702
sachin003

1. Wie kann ich das Reverse Engineering einer Android APK vollständig vermeiden? Ist das möglich?

AFAIK, es gibt keinen Trick, um das Reverse Engineering vollständig zu vermeiden.

Und auch von @inazaruk sehr gut gesagt: Was auch immer Sie mit Ihrem Code tun, ein potenzieller Angreifer kann ihn auf jede Weise ändern, die er oder sie für machbar hält. Sie können Ihre Anwendung grundsätzlich nicht vor Änderungen schützen. Jeder Schutz, den Sie dort einfügen, kann deaktiviert/entfernt werden.

2. Wie kann ich alle Ressourcen, Assets und Quellcode der App schützen, sodass Hacker die APK-Datei auf keine Weise hacken können?

Sie können verschiedene Tricks ausführen, um das Hacken jedoch schwieriger zu machen. Verwenden Sie beispielsweise Verschleierung (wenn es sich um Java-Code handelt). Dies verlangsamt normalerweise das Reverse Engineering erheblich.

3. Gibt es eine Möglichkeit, Hacking schwieriger oder sogar unmöglicher zu machen? Was kann ich noch tun, um den Quellcode in meiner APK-Datei zu schützen?

Wie jeder sagt und wie Sie wahrscheinlich wissen, gibt es keine 100% ige Sicherheit. Der Startpunkt für Android, den Google eingebaut hat, ist ProGuard. Wenn Sie die Möglichkeit haben, gemeinsam genutzte Bibliotheken aufzunehmen, können Sie den erforderlichen Code in C++ einfügen, um die Dateigröße, die Integration, Etc. Zu überprüfen. Wenn Sie dem Bibliotheksordner Ihres APK in jedem Build eine externe native Bibliothek hinzufügen möchten, , Können Sie sie mit dem folgenden Vorschlag verwenden.

Fügen Sie die Bibliothek in den systemeigenen Bibliothekspfad ein, der standardmäßig in Ihrem Projektordner auf "libs" gesetzt ist. Wenn Sie den systemeigenen Code für das 'armeabi' target erstellt haben, setzen Sie ihn Unter libs/armeabi . Wenn es mit armeabi-v7a gebaut wurde, dann legen Sie es unter __. libs/armeabi-v7a.

<project>/libs/armeabi/libstuff.so
339

AFAIK, Sie können die Dateien im Verzeichnis/res nicht mehr schützen, als sie jetzt geschützt sind.

Es gibt jedoch Schritte, die Sie ergreifen können, um Ihren Quellcode zu schützen, oder zumindest das, was er tut, wenn nicht alles.

  1. Verwenden Sie Tools wie ProGuard. Diese verschleiern Ihren Code und machen das Lesen schwieriger, wenn er dekompiliert wird, wenn nicht unmöglich.
  2. Verschieben Sie die wichtigsten Teile des Dienstes aus der App und in einen Webservice, der hinter einer serverseitigen Sprache wie PHP versteckt ist. Zum Beispiel, wenn Sie einen Algorithmus haben, für dessen Erstellung Sie eine Million Dollar gebraucht haben. Offensichtlich möchten Sie nicht, dass Leute es aus Ihrer App stehlen. Verschieben Sie den Algorithmus und lassen Sie die Daten auf einem Remote-Server verarbeiten, und verwenden Sie die App, um sie einfach mit den Daten zu versehen. Oder verwenden Sie das NDK, um sie nativ in .so-Dateien zu schreiben, bei denen die Wahrscheinlichkeit einer Dekompilierung viel geringer ist als bei apks. Ich glaube nicht, dass es jetzt einen Decompiler für .so-Dateien gibt (und selbst wenn dies der Fall wäre, wäre er nicht so gut wie die Java-Decompiler). Darüber hinaus sollten Sie, wie @nikolay in den Kommentaren erwähnt, SSL verwenden, wenn Sie zwischen Server und Gerät interagieren.
  3. Wenn Sie Werte auf dem Gerät speichern, speichern Sie sie nicht im Rohformat. Wenn Sie beispielsweise ein Spiel haben und den Betrag in Spielwährung speichern, den der Benutzer in SharedPreferences hat. Nehmen wir an, es ist 10000 Münzen. Statt 10000 direkt zu speichern, speichern Sie es mit einem Algorithmus wie ((currency*2)+1)/13. Statt 10000 speichern Sie 1538.53846154 in den SharedPreferences. Das obige Beispiel ist jedoch nicht perfekt, und Sie müssen an einer Gleichung arbeiten, bei der die Währung nicht durch Rundungsfehler usw. verloren geht.
  4. Ähnliches können Sie für serverseitige Aufgaben tun. Nehmen wir als Beispiel ein Beispiel für Ihre App zur Zahlungsabwicklung. Angenommen, der Benutzer muss $200 bezahlen. Senden Sie nicht einen $200-Rohwert an den Server, sondern senden Sie eine Reihe kleinerer vordefinierter Werte, die sich zu $200 addieren. Verfügen Sie zum Beispiel über eine Datei oder Tabelle auf Ihrem Server, die Wörter mit Werten gleichsetzt. Nehmen wir also an, dass Charlie$47 und John$3 entspricht. Anstatt $200 zu senden, können Sie also Charlie viermal und John viermal senden. Interpretieren Sie auf dem Server, was sie bedeuten und addieren Sie es. Dies hindert einen Hacker daran, beliebige Werte an Ihren Server zu senden, da er nicht weiß, was Word welchem ​​Wert entspricht. Als zusätzliche Sicherheitsmaßnahme könnten Sie auch hier eine Gleichung wie in Punkt 3 haben und die Schlüsselwörter alle n Anzahl von Tagen ändern.
  5. Schließlich können Sie unbeabsichtigten Quellcode in Ihre App einfügen, sodass der Hacker nach einer Nadel im Heuhaufen sucht. Fügen Sie zufällige Klassen ein, die Ausschnitte aus dem Internet enthalten, oder einfach Funktionen zum Berechnen von zufälligen Dingen wie der Fibonacci-Sequenz. Stellen Sie sicher, dass diese Klassen kompiliert werden, aber nicht von der tatsächlichen Funktionalität der App verwendet werden. Fügen Sie genug dieser falschen Klassen hinzu, und der Hacker hat Schwierigkeiten, Ihren echten Code zu finden.

Alles in allem gibt es keine Möglichkeit, Ihre App zu 100% zu schützen. Sie können es schwieriger machen, aber nicht unmöglich. Ihr Webserver könnte gefährdet sein. Der Hacker könnte Ihre Schlüsselwörter ermitteln, indem er mehrere Transaktionsbeträge und die von Ihnen gesendeten Schlüsselwörter überwacht. Der Hacker könnte mühsam durch die Quelle gehen und herausfinden, welcher Code ein Dummy ist.

Sie können sich nur wehren, aber niemals gewinnen.

119
Raghav Sood

Zu keinem Zeitpunkt in der Computergeschichte war es möglich, das Reverse Engineering von Software zu verhindern, wenn Sie Ihrem Angreifer eine Arbeitskopie davon geben. Auch höchstwahrscheinlich es wird nie möglich sein.

Wenn Sie das verstanden haben, gibt es eine offensichtliche Lösung: Geben Sie Ihre Geheimnisse nicht an Ihren Angreifer weiter. Obwohl Sie den Inhalt Ihrer APK nicht schützen können, Was Sie schützen können , ist alles, was Sie nicht verbreiten. In der Regel handelt es sich hierbei um serverseitige Software, die für Dinge wie Aktivierung, Zahlungen, Durchsetzung von Regeln und andere nützliche Code-Elemente verwendet wird. Sie können wertvolle Assets schützen, indem Sie sie nicht in Ihrer APK verteilen . Richten Sie stattdessen einen Server ein, der auf Anforderungen Ihrer App reagiert, die Assets "verwendet" (was auch immer das bedeuten mag) und dann das Ergebnis an die App zurücksendet. Wenn dieses Modell für die Assets, an die Sie denken, nicht funktioniert, sollten Sie Ihre Strategie möglicherweise überdenken.

Auch wenn Ihr primäres Ziel ist, App-Piraterie zu verhindern: nicht einmal die Mühe machen. Sie haben bereits mehr Zeit und Geld in dieses Problem gesteckt, als irgendeine Maßnahme zur Pirateriebekämpfung jemals erhoffen könnte, Sie zu retten. Der Return on Investment zur Lösung dieses Problems ist so gering, dass es keinen Sinn macht, darüber nachzudenken.

111
tylerl

Erste Regel für die App-Sicherheit: Jede Maschine, auf die ein Angreifer uneingeschränkten physischen oder elektronischen Zugriff erhält, gehört jetzt Ihrem Angreifer, unabhängig davon, wo er sich tatsächlich befindet oder was Sie dafür bezahlt haben.

Zweite Regel der App-Sicherheit: Jede Software, die die physischen Grenzen verlässt, in die ein Angreifer nicht eindringen kann, gehört jetzt zu Ihrem Angreifer, unabhängig davon, wie viel Zeit Sie dafür aufgewendet haben.

Dritte Regel: Jede Information, die dieselben physischen Grenzen hinterlässt, die ein Angreifer jetzt nicht durchdringen kann, gehört Ihrem Angreifer, unabhängig davon, wie wertvoll er für Sie ist.

Die Grundlagen der Informationstechnologiesicherheit basieren auf diesen drei Grundprinzipien. Der einzig wirklich sichere Computer ist der, der in einem sicheren, in einem Farraday-Käfig, in einem Stahlkäfig eingeschlossen ist. Es gibt Computer, die die meiste Zeit ihres Lebens in genau diesem Zustand verbringen. Einmal im Jahr (oder weniger) generieren sie die privaten Schlüssel für vertrauenswürdige Stammzertifizierungsstellen (vor einem Zeugenhort mit Kameras, die jeden Zentimeter des Raums aufzeichnen, in dem sie sich befinden).

Heute werden die meisten Computer in diesen Umgebungen nicht verwendet. Sie sind physisch im Freien und über einen Funkkanal mit dem Internet verbunden. Kurz gesagt, sie sind anfällig, ebenso wie ihre Software. Ihnen ist daher nicht zu trauen. Es gibt bestimmte Dinge, die Computer und ihre Software wissen oder tun müssen, um nützlich zu sein. Es muss jedoch darauf geachtet werden, dass sie niemals genug wissen oder tun können, um Schäden zu verursachen (zumindest nicht dauerhaft außerhalb der Grenzen dieser einzelnen Maschine) ).

Sie wussten schon alles. Deshalb versuchen Sie, den Code Ihrer Anwendung zu schützen. Darin liegt aber das erste Problem. Verschleierungswerkzeuge können den Code zum Durcheinander bringen, aber ein Programm muss noch ausgeführt werden. Dies bedeutet, dass der tatsächliche Logikfluss der App und die von ihr verwendeten Daten nicht durch Verschleierung beeinträchtigt werden. Mit etwas Beharrlichkeit kann ein Angreifer den Code einfach unkenntlich machen, und das ist in bestimmten Fällen nicht notwendig, in denen das, was er betrachtet, nichts anderes sein kann als das, wonach er sucht.

Stattdessen sollten Sie sicherstellen, dass ein Angreifer mit Ihrem Code nichts anfangen kann, unabhängig davon, wie leicht es ist, eine klare Kopie davon zu erhalten. Das heißt, keine hart codierten Geheimnisse, denn diese Geheimnisse sind nicht geheim, sobald der Code das Gebäude verlässt, in dem Sie sie entwickelt haben.

Diese Schlüsselwerte, die Sie hartcodiert haben, sollten vollständig aus dem Quellcode der Anwendung entfernt werden. Stattdessen sollten sie sich an einem von drei Orten befinden. flüchtiger Speicher auf dem Gerät, der für einen Angreifer schwieriger (aber immer noch nicht unmöglich) ist, um eine Offline-Kopie von zu erhalten; permanent auf dem Server-Cluster, zu dem Sie den Zugriff mit einer eisernen Faust steuern; oder in einem zweiten Datenspeicher, der nicht mit Ihrem Gerät oder Ihren Servern zusammenhängt, wie z. B. einer physischen Karte oder im Speicher Ihres Benutzers (was bedeutet, dass sich der Datenspeicher irgendwann im flüchtigen Speicher befindet, muss aber nicht lange sein).

Betrachten Sie das folgende Schema. Der Benutzer gibt seine Anmeldeinformationen für die App aus dem Speicher in das Gerät ein. Sie müssen sich leider darauf verlassen, dass das Gerät des Benutzers nicht bereits durch einen Keylogger oder Trojaner gefährdet ist. Das Beste, was Sie in dieser Hinsicht tun können, ist die Implementierung der Multi-Faktor-Sicherheit, indem Sie sich schwer fälschliche Informationen über die vom Benutzer verwendeten Geräte (MAC/IP, IMEI usw.) merken und mindestens einen zusätzlichen Kanal bereitstellen Dadurch kann ein Login-Versuch auf einem unbekannten Gerät überprüft werden.

Sobald die Anmeldeinformationen eingegeben wurden, werden sie von der Client-Software (unter Verwendung eines sicheren Hashes) verschleiert, und die Klartext-Anmeldeinformationen werden verworfen. Sie haben ihren Zweck erfüllt. Die verschleierten Anmeldeinformationen werden über einen sicheren Kanal an den Server mit Zertifikat-Authentifizierung gesendet, der sie again erneut ansteuert, um die Daten zu erzeugen, die zur Überprüfung der Gültigkeit der Anmeldung verwendet werden. Auf diese Weise weiß der Client nie, was tatsächlich mit dem Datenbankwert verglichen wird. Der App-Server kennt niemals die Klartext-Anmeldeinformationen, die er zur Validierung erhält. Der Datenserver weiß nie, wie die zur Validierung gespeicherten Daten erzeugt werden, und ein Mitarbeiter Die Mitte sieht nur Kauderwelsch, selbst wenn der sichere Kanal beeinträchtigt wurde.Nach der Überprüfung sendet der Server ein Token über den Kanal zurück. Das Token ist nur innerhalb der sicheren Sitzung nützlich und besteht entweder aus zufälligem Rauschen oder einer verschlüsselten (und somit überprüfbaren) Kopie der Sitzungskennungen. Die Clientanwendung muss dieses Token auf demselben Kanal als Teil einer Anforderung an den Server senden etwas zu tun. Die Client-Anwendung wird dies viele Male tun, da sie nichts mit Geld, sensiblen Daten oder anderen Elementen tun kann, die sich selbst schädigen könnten. Stattdessen muss der Server diese Aufgabe ausführen. Die Clientanwendung schreibt niemals sensible Informationen in den permanenten Speicher des Geräts, zumindest nicht im Klartext. Der Client kann den Server über den sicheren Kanal nach einem symmetrischen Schlüssel fragen, um lokale Daten zu verschlüsseln, an die sich der Server erinnern wird. In einer späteren Sitzung kann der Client den Server nach demselben Schlüssel fragen, um die Daten für die Verwendung im flüchtigen Speicher zu entschlüsseln. Diese Daten werden auch nicht die einzige Kopie sein. Alles, was der Client speichert, sollte auch in irgendeiner Form an den Server übermittelt werden.

Offensichtlich ist Ihre Anwendung dadurch stark vom Internetzugang abhängig. Das Clientgerät kann keine seiner Grundfunktionen ohne ordnungsgemäße Verbindung mit dem Server und Authentifizierung durch den Server ausführen. Nicht anders als Facebook.

Nun, der Computer, den der Angreifer haben möchte, ist Ihr Server, da dies und nicht die Client-App/das Gerät die Sache ist, durch die er Geld verdienen oder anderen Menschen Schmerzen bereiten kann. Kein Problem; Sie erhalten viel mehr Geld für Ihr Geld und die Mühe, den Server abzusichern, als wenn Sie versuchen, alle Clients zu sichern. Der Server kann sich hinter allen Arten von Firewalls und anderer elektronischer Sicherheit befinden und kann zusätzlich hinter Stahl, Beton, Keycard/Pin-Zugriff und 24-Stunden-Videoüberwachung physisch gesichert werden. Ihr Angreifer muss in der Tat sehr komplex sein, um direkt auf den Server zugreifen zu können, und Sie sollten (sollten) sofort davon erfahren.

Am besten kann ein Angreifer das Telefon und die Anmeldeinformationen eines Benutzers stehlen und sich mit den eingeschränkten Rechten des Clients am Server anmelden. In diesem Fall sollte der legitime Benutzer genauso wie beim Verlust einer Kreditkarte angewiesen werden, eine 800-Nummer anzurufen (vorzugsweise leicht zu merken), und nicht auf der Rückseite einer Karte, die er in seiner Handtasche, Brieftasche oder Aktentasche bei sich tragen würde zusammen mit dem mobilen Gerät gestohlen) von jedem Telefon, auf das sie zugreifen können, das sie direkt mit Ihrem Kundendienst verbindet. Sie geben an, dass ihr Telefon gestohlen wurde, geben eine grundlegende eindeutige Kennung an, und das Konto ist gesperrt. Alle Transaktionen, die der Angreifer möglicherweise verarbeiten konnte, werden zurückgesetzt, und der Angreifer ist wieder auf Platz eins. 

The best an attacker can do is steal a user's phone and credentials and log in to the server with the limited rights of the client. Should this happen, just like losing a credit card, the legitimate user should be instructed to call an 800 number (preferably easy to remember, and not on the back of a card they'd carry in their purse, wallet or briefcase which could be stolen alongside the mobile device) from any phone they can access that connects them directly to your customer service. They state their phone was stolen, provide some basic unique identifier, and the account is locked, any transactions the attacker may have been able to process are rolled back, and the attacker is back to square one.

80
KeithS

1. Wie kann ich das Reverse Engineering einer Android APK vollständig vermeiden? Ist das möglich?

Das ist nicht möglich

2. Wie kann ich alle Ressourcen, Assets und Quellcode der App schützen, sodass Hacker die APK-Datei auf keine Weise hacken können?

Wenn jemand eine .apk-Erweiterung in .Zip ändert, kann jemand nach dem Entpacken problemlos alle Ressourcen abrufen (außer Manifest.xml), aber mit - APKtool kann man wirklich etwas bekommen Inhalt der Manifestdatei. Wieder ein Nein.

3. Gibt es eine Möglichkeit, Hacking schwieriger oder sogar unmöglicher zu machen? Was kann ich noch tun, um den Quellcode in meiner APK-Datei zu schützen?

Wieder nein, aber Sie können bis zu einem gewissen Grad verhindern, das heißt, 

  • Laden Sie eine Ressource aus dem Web herunter und führen Sie einen Verschlüsselungsvorgang durch
  • Verwenden Sie eine vorkompilierte native Bibliothek (C, C++, JNI, NDK).
  • Führen Sie immer etwas Hashing aus ( MD5 / SHA oder eine andere Logik)

Selbst mit Smali können Benutzer mit Ihrem Code spielen. Alles in allem ist es nicht möglich.

66
Azhar Shaikh

Eine 100% ige Vermeidung des Reverse Engineering der Android APK ist nicht möglich. Sie können jedoch die folgenden Methoden verwenden, um das Extrahieren weiterer Daten wie Quellcode, Assets aus Ihrer APK und Ressourcen zu vermeiden:

  1. Verwenden Sie ProGuard, um den Anwendungscode zu verschleiern

  2. Verwenden SieNDKmit C und C++ , um Ihren Anwendungskern zu sichern und einen Teil des Codes in .so-Dateien zu sichern

  3. Um Ressourcen zu sichern, fügen Sie nicht alle wichtigen Ressourcen in den Assets-Ordner in APK ein. Laden Sie diese Ressourcen beim ersten Start der Anwendung herunter.

35

Entwickler können die folgenden Schritte ausführen, um einen APK irgendwie vor Diebstahl zu schützen.

  • die grundlegendste Methode ist die Verwendung von Tools wie ProGuard, um ihren Code zu verschleiern. Bislang war es jedoch ziemlich schwierig, jemanden vollständig daran zu hindern, eine App zu dekompilieren.

  • Auch ich habe von einem Werkzeug HoseDex2Jar gehört. Es stoppt Dex2Jar durch Einfügen von harmlosem Code in eine Android APK, der Dex2Jar verwirrt und deaktiviert und den Code vor Dekompilierung schützt. Es könnte irgendwie verhindern, dass Hacker eine APK in lesbaren Java-Code zerlegen. 

  • Verwenden Sie eine serverseitige Anwendung, um nur dann mit der Anwendung zu kommunizieren, wenn sie benötigt wird. Es könnte helfen, die wichtigen Daten zu verhindern.

Überhaupt können Sie Ihren Code nicht vollständig vor potenziellen Hackern schützen. Irgendwie könnte es für Sie schwierig und frustrierend sein, Ihren Code zu dekompilieren. Eine der effizientesten Methoden besteht darin, in nativem Code (C/C++) zu schreiben und als kompilierte Bibliotheken zu speichern.

33

1. Wie kann ich das Reverse Engineering einer Android APK vollständig vermeiden? Ist das möglich?

Das ist unmöglich

2. Wie kann ich alle Ressourcen, Assets und Quellcode der App schützen, sodass Hacker die APK-Datei auf keine Weise hacken können?

Entwickler können Schritte unternehmen, wie beispielsweise Tools wie ProGuard, um ihren Code zu verschleiern. Bislang war es jedoch ziemlich schwierig, jemanden daran zu hindern, eine App zu dekompilieren.

Es ist ein wirklich großartiges Werkzeug und kann die Schwierigkeit beim Umkehren des Codes erhöhen, während der Footprint des Codes verringert wird.

Integrierte ProGuard-Unterstützung: ProGuard ist jetzt im Lieferumfang der SDK-Tools enthalten. Entwickler können nun ihren Code als integrierten Bestandteil eines Release-Builds verschleiern.

3. Gibt es eine Möglichkeit, Hacking schwieriger oder sogar unmöglicher zu machen? Was kann ich noch tun, um den Quellcode in meiner APK-Datei zu schützen?

Während meiner Recherche erfuhr ich von HoseDex2Jar . Dieses Tool schützt Ihren Code vor der Dekompilierung, aber es scheint nicht möglich zu sein, Ihren Code vollständig zu schützen.

Einige hilfreiche Links können Sie darauf verweisen. 

22
RobinHood

Hier sind einige Methoden, die Sie ausprobieren können:

  1. Verwenden Sie Verschleierung und Tools wie ProGuard .
  2. Verschlüsseln Sie einen Teil der Quelle und Daten.
  3. Verwenden Sie eine proprietäre integrierte Prüfsumme in der App, um Manipulationen zu erkennen.
  4. Führen Sie Code ein, um das Laden in einem Debugger zu vermeiden, dh lassen Sie die App den Debugger erkennen und den Debugger beenden/beenden.
  5. Trennen Sie die Authentifizierung als Onlinedienst.
  6. Verwenden Sie Anwendungsvielfalt
  7. Verwenden Sie die Fingerprint-Technik zum Beispiel für Hardwaresignaturen der Geräte von verschiedenen Subsystemen, bevor Sie das Gerät authentifizieren.
21
Shan

Die Hauptfrage hier ist, dass die Dex-Dateien dekompiliert werden können und die Antwort ist, dass sie "irgendwie" sein können. Es gibt Disassembler wie dedexer und smali .

Wenn ProGuard richtig konfiguriert ist, wird Ihr Code verschleiert. DexGuard, eine kommerzielle erweiterte Version von ProGuard, kann ein wenig mehr helfen. Ihr Code kann jedoch weiterhin in smali konvertiert werden, und Entwickler mit Reverse-Engineering-Erfahrung können anhand des smali herausfinden, was Sie tun.

Wählen Sie vielleicht eine gute Lizenz und setzen Sie diese gesetzlich auf bestmögliche Weise durch.

21

1. Wie kann ich das Reverse Engineering einer Android APK vollständig vermeiden? Ist das möglich?

Unmöglich

2. Wie kann ich alle Ressourcen, Assets und Quellcode der App schützen, sodass Hacker die APK-Datei auf keine Weise hacken können?

Unmöglich

3. Gibt es eine Möglichkeit, Hacking schwieriger oder sogar unmöglicher zu machen? Was kann ich noch tun, um den Quellcode in meiner APK-Datei zu schützen?

Schwieriger - möglich, aber in der Tat wird es schwieriger, vor allem für den durchschnittlichen Benutzer, der nur nach Hacking-Guides sucht. Wenn jemand Ihre App wirklich hacken möchte, wird sie früher oder später gehackt.

21
janot

Ihr Kunde sollte jemanden einstellen, der weiß, was er tut, der die richtigen Entscheidungen treffen und Sie beraten kann.

Sprechen Sie darüber, dass Sie die Möglichkeit haben, das Transaktionsverarbeitungssystem im Backend zu ändern. Es ist absurd - Sie sollten solche architektonischen Änderungen nicht vornehmen dürfen, erwarten Sie also nicht.

Meine Begründung dazu:

Da es sich bei Ihrer Domain um die Zahlungsabwicklung handelt, können Sie davon ausgehen, dass PCI DSS und/oder PA DSS (und potenzielles Bundes- und Bundesrecht) für Ihr Unternehmen von Bedeutung sind sichern. Verunsichern Sie sich dann (durch Testen), dass Sie nicht sicher sind, und führen Sie dann einen Fixiervorgang durch, testen Sie erneut, usw., bis die Sicherheit auf einem geeigneten Niveau überprüft werden kann = teurer, langsamer, risikoreicher Weg zum Erfolg. Um das Richtige zu tun, muss man im Voraus nachdenken, erfahrene Talente für den Job einsetzen, sich auf sichere Weise entwickeln, dann testen, reparieren (weniger), usw. (weniger), bis die Sicherheit auf einem geeigneten Niveau überprüft werden kann. risikoarmer Weg zum Erfolg.

12
straya

Als jemand, der ausgiebig auf Zahlungsplattformen gearbeitet hat, einschließlich einer mobilen Zahlungsanwendung (MyCheck), würde ich sagen, dass Sie dieses Verhalten an den Server delegieren müssen. Es sollte kein Benutzername oder Kennwort für den Zahlungsprozessor (was auch immer es ist) gespeichert werden Das ist das letzte, was Sie wollen, denn die Quelle kann auch dann verstanden werden, wenn Sie den Code verschleiern.

Sie sollten auch keine Kreditkarten oder Zahlungstoken in der Anwendung speichern. Alles sollte wiederum an einen von Ihnen erstellten Dienst delegiert werden. Dies ermöglicht Ihnen später auch, PCI-konformer zu sein und die Kreditkartenunternehmen haben gewonnen atme deinen Hals nicht ab (wie sie es für uns getan haben).

7
Itai Sagi

Wenn wir Reverse Engineering (fast) unmöglich machen möchten, können wir die Anwendung auf einen äußerst manipulationssicheren Chip setzen, der alle sensiblen Daten intern ausführt und mit einem Protokoll kommuniziert, um die Steuerung der GUI auf dem Host zu ermöglichen. Selbst manipulationssichere Späne sind nicht 100% rissfest; Sie legen die Messlatte viel höher als die Softwaremethoden. Dies ist natürlich unpraktisch: Die Anwendung erfordert einige kleine USB-Warzen, die den Chip in das Gerät einführen.

Die Frage offenbart nicht die Motivation, diese Anwendung so eifersüchtig schützen zu wollen. 

Wenn das Ziel darin besteht, die Sicherheit der Zahlungsmethode zu verbessern, indem die Sicherheitslücken der Anwendung (bekannt oder anderweitig) verborgen werden, ist dies völlig falsch. Die sicherheitssensitiven Bits sollten in der Tat eine offene Quelle sein, wenn dies machbar ist. Sie sollten es jedem Sicherheitsforscher, der Ihre Anwendung überprüft, so einfach wie möglich machen, um diese Teile zu finden, deren Betrieb zu untersuchen und sich mit Ihnen in Verbindung zu setzen. Zahlungsanwendungen sollten keine eingebetteten Zertifikate enthalten. Das heißt, es sollte keine Serveranwendung geben, die einem Gerät vertraut, einfach weil es ein festes Zertifikat vom Werk hat. Eine Zahlungstransaktion sollte nur für die Anmeldeinformationen des Benutzers durchgeführt werden, wobei ein ordnungsgemäß entworfenes Ende-zu-Ende-Authentifizierungsprotokoll verwendet wird, das das Vertrauen der Anwendung, der Plattform oder des Netzwerks usw. ausschließt.

Wenn das Ziel darin besteht, das Klonen zu verhindern, wenn der manipulationssichere Chip nicht vorhanden ist, können Sie nichts dagegen tun, um das Programm vor Reverse Engineering und Kopieren zu schützen, sodass jemand eine kompatible Zahlungsmethode in seine eigene Anwendung integriert Aufstieg zu "nicht autorisierten Kunden". Es gibt Möglichkeiten, die Entwicklung nicht autorisierter Kunden zu erschweren. Eine wäre, Prüfsummen basierend auf Momentaufnahmen des vollständigen Status des Programms zu erstellen: alle Statusvariablen für alles. GUI, Logik, was auch immer. Ein Klonprogramm hat nicht genau denselben internen Status. Sicher, es ist eine Zustandsmaschine, die ähnliche von außen sichtbare Zustandsübergänge aufweist (wie von Ein- und Ausgängen beobachtet werden kann), aber kaum denselben internen Zustand. Eine Serveranwendung kann das Programm abfragen: Wie ist Ihr detaillierter Status? (Geben Sie mir eine Prüfsumme über alle Ihre internen Zustandsvariablen). Dies kann mit Dummy-Client-Code verglichen werden, der parallel auf dem Server ausgeführt wird und die echten Zustandsübergänge durchläuft. Ein Klon eines Drittanbieters muss alle relevanten Statusänderungen des echten Programms replizieren, um die richtigen Antworten zu geben, die seine Entwicklung behindern.

7
Kaz

Die anderen Antworten sind hier richtig. Ich möchte nur eine andere Option anbieten.

Für bestimmte Funktionen, die Sie als wichtig erachten, können Sie das WebView Control in Ihrer App hosten. Die Funktionalität würde dann auf Ihrem Webserver implementiert. Es sieht so aus, als würde es in Ihrer Anwendung laufen.

7
Sarel Botha

Ich schlage vor, dass Sie Schützen Sie Softwareanwendungen vor Angriffen. Es ist eine kommerzielle Dienstleistung, aber die Firma meines Freundes hat das genutzt und sie sind froh, es zu nutzen.

5
Talha

APK-Signaturschema v2 in Android N

Die PackageManager-Klasse unterstützt jetzt die Überprüfung von Apps mit dem APK-Signaturschema v2. Das APK-Signaturschema v2 ist ein Ganzdatei-Signaturschema, das die Überprüfungsgeschwindigkeit erheblich verbessert und die Integritätsgarantie durch Erkennen nicht autorisierter Änderungen an APK-Dateien verbessert.

Um die Abwärtskompatibilität aufrechtzuerhalten, muss ein APK mit dem Signaturschema der Version 1 (JAR-Signaturschema) signiert werden, bevor es mit dem Signaturschema der Version 2 signiert wird. Mit dem v2-Signaturschema schlägt die Überprüfung fehl, wenn Sie den APK nach dem Signieren mit dem v2-Schema mit einem zusätzlichen Zertifikat signieren.

Die Unterstützung für das APK-Signaturschema v2 wird später in der N Developer Preview verfügbar sein.

http://developer.Android.com/preview/api-overview.html#apk_signature_v2

4
thiagolr

Es ist nicht möglich, RE vollständig zu vermeiden, aber indem sie intern komplexer gemacht werden, wird es für Angreifer schwieriger, die klare Funktionsweise der App zu sehen, wodurch die Anzahl der Angriffsvektoren reduziert werden kann.

Wenn die Anwendung mit hochsensiblen Daten arbeitet, gibt es verschiedene Techniken, die die Komplexität des Reverse-Engineering Ihres Codes erhöhen können. Eine Technik ist die Verwendung von C/C++, um die einfache Laufzeitmanipulation durch den Angreifer zu begrenzen. Es gibt zahlreiche C- und C++ - Bibliotheken, die sehr ausgereift sind und sich leicht in Android-JNI integrieren lassen. Ein Angreifer muss zunächst die Debugging-Einschränkungen umgehen, um die Anwendung auf einem niedrigen Niveau anzugreifen. Dies erhöht die Komplexität eines Angriffs. Für Android-Anwendungen sollte Android: debuggable = "false" im Anwendungsmanifest eingestellt sein, um eine einfache Laufzeitmanipulation durch einen Angreifer oder Malware zu verhindern. 

Trace Checking - Eine Anwendung kann feststellen, ob sie gerade von einem Debugger oder einem anderen Debugging-Tool verfolgt wird. Bei der Verfolgung kann die Anwendung eine beliebige Anzahl möglicher Angriffsreaktionsaktionen ausführen, z. B. das Verwerfen von Verschlüsselungsschlüsseln zum Schutz der Benutzerdaten, das Benachrichtigen eines Serveradministrators oder andere derartige Antworten, um sich selbst zu schützen. Dies kann durch Prüfen der Prozessstatusflags oder durch Verwenden anderer Techniken ermittelt werden, z. B. Vergleichen des Rückgabewerts von ptrace attach, Prüfen des übergeordneten Prozesses, Debugger der Blacklist in der Prozessliste oder Vergleichen von Zeitstempeln an verschiedenen Stellen des Programms.

Optimierungen - Zum Ausblenden fortgeschrittener mathematischer Berechnungen und anderer Arten komplexer Logik kann die Verwendung von Compileroptimierungen Verschleierung des Objektcodes helfen, so dass er von einem Angreifer nicht ohne weiteres zerlegt werden kann, was ihn erschwert damit ein Angreifer den jeweiligen Code verstehen kann. In Android kann dies leichter durch Verwendung von nativ zusammengestellten Bibliotheken mit dem NDK erreicht werden. Darüber hinaus sorgt die Verwendung eines LLVM-Obfuscators oder eines anderen SDK für Protektoren für eine bessere Verschleierung des Maschinencodes.

Stripping binaries - Das Entfernen nativer Binärdateien ist eine effektive Methode, um die Zeit und das Skill-Level eines Angreifers zu erhöhen, um die neuen Funktionen der Anwendung auf niedriger Ebene anzuzeigen. Durch das Entfernen einer Binärdatei wird die Symboltabelle der Binärdatei entfernt, sodass ein Angreifer eine Anwendung nicht leicht debuggen oder zurückentwickeln kann. Sie können sich auf Techniken beziehen, die auf GNU/Linux-Systemen verwendet werden, z. B. Sstriping oder die Verwendung von UPX.

Und zum Schluss müssen Sie über Verschleierung und Tools wie ProGuard Bescheid wissen.

3
Sanket Prabhu

Mit @Muhammad Saqib hier vereinbart: https://stackoverflow.com/a/46183706/2496464

Und @Mumair gibt gute Startschritte: https://stackoverflow.com/a/35411378/474330

Es ist immer davon auszugehen, dass alles, was Sie auf dem Gerät Ihres Benutzers verteilen, dem Benutzer gehört. Schlicht und einfach. Möglicherweise können Sie die neuesten Tools und Verfahren verwenden, um Ihre geistigen Eigenschaften zu verschlüsseln. Es gibt jedoch keine Möglichkeit, eine entschlossene Person daran zu hindern, Ihr System zu "studieren". Und selbst wenn die derzeitige Technologie es schwierig machen könnte, unerwünschten Zugang zu erlangen, könnte es morgen einen einfachen Weg geben oder sogar nur die nächste Stunde!

Hier kommt also die Gleichung:

When it comes to money, we always assume that client is untrusted.

Auch so einfach wie eine In-Game-Wirtschaft. (Vor allem bei Spielen! Es gibt dort 'erfahrene' Benutzer und Schlupflöcher verbreiten sich in Sekunden!)

Wie bleiben wir sicher?

Die meisten unserer Schlüsselverarbeitungssysteme (und natürlich die Datenbank) befinden sich auf der Serverseite. Und zwischen Client und Server liegen verschlüsselte Kommunikationen, Validierungen usw. Das ist die Idee von Thin Client.

3
Zennichimaro

Das Reverse Engineering einer APK kann nicht vollständig vermieden werden. Zum Schutz von Anwendungsressourcen und -ressourcen können Sie die Verschlüsselung verwenden.

  • Die Verschlüsselung macht es schwieriger, sie ohne Entschlüsselung zu verwenden. Wenn Sie einen starken Verschlüsselungsalgorithmus verwenden, wird das Cracken schwieriger.
  • Hinzufügen von Spoof-Code in Ihre Hauptlogik, um das Cracken schwieriger zu gestalten.
  • Wenn Sie Ihre kritische Logik in einer beliebigen Muttersprache schreiben können, ist das Dekompilieren sicherlich schwieriger.
  • Verwenden von Sicherheitsframeworks von Drittanbietern wie Quixxi
3
immutable

Grundsätzlich ist es nicht möglich. Es wird niemals möglich sein. Es gibt jedoch Hoffnung. Sie können einen obfuscator verwenden, um einige häufig vorkommende Angriffe viel schwieriger auszuführen. Dazu gehören:

  1. Umbenennen von Methoden/Klassen (im Dekompiler erhalten Sie Typen wie a.a)
  2. Verschleierung des Kontrollflusses (daher ist der Code im Decompiler sehr schwer lesbar)
  3. Zeichenfolgen und möglicherweise Ressourcen verschlüsseln

Ich bin sicher, es gibt noch andere, aber das sind die wichtigsten. Ich arbeite für eine Firma namens PreEmptive Solutions auf einem .NET obfuscator. Sie haben auch einen Java-Obfuscator, der für Android sowie als DashO funktioniert.

Verschleierung kommt jedoch immer mit einem Preis. Die Leistung ist in der Regel schlechter und erfordert normalerweise etwas mehr Zeit für die Veröffentlichung. Wenn Ihr geistiges Eigentum für Sie jedoch extrem wichtig ist, lohnt es sich in der Regel.

Andernfalls besteht die einzige Möglichkeit darin, die Android-Anwendung so zu gestalten, dass sie nur einen Server durchläuft, auf dem sich die gesamte Logik der Anwendung befindet. Dies hat seinen eigenen Anteil an Problemen, da dies bedeutet, dass Benutzer mit dem Internet verbunden sein müssen, um Ihre App verwenden zu können.

Dieses Problem hat nicht nur Android. Es ist ein Problem in jedem App Store. Es ist nur eine Frage, wie schwierig es ist, an die Paketdatei zu gelangen (zum Beispiel glaube ich nicht, dass es für iPhones sehr einfach ist, aber es ist immer noch möglich).

3
Earlz

Sollen nicht TPM-Chips (Trusted Platform Module) für Sie geschützten Code verwalten? Sie werden auf PCs (vor allem bei Apple) immer häufiger und sind in den heutigen Smartphone-Chips bereits enthalten. Leider gibt es noch keine OS-API, um davon Gebrauch zu machen. Hoffentlich fügt Android eines Tages Unterstützung hinzu. Dies ist auch der Schlüssel zum Bereinigen von Content DRM (an dem Google für WebM arbeitet).

2
robUx4

Nichts ist sicher, wenn Sie es den Endbenutzern zur Verfügung stellen, aber einige übliche Praktiken machen es für Angreifer schwieriger, Daten zu stehlen.

  • Setzen Sie Ihre Hauptlogik (Algorithmen) auf die Serverseite.
  • Kommunikation mit Server und Client Stellen Sie sicher, dass die Kommunikation zwischen Server und Client über SSL oder HTTPS gesichert ist. oder verwenden Sie andere Schlüsselpaar-Generierungsalgorithmen (ECC, RSA). Stellen Sie sicher, dass vertrauliche Informationen End-to-End-verschlüsselt bleiben.
  • Verwenden Sie Sitzungen und lassen Sie sie nach einem bestimmten Zeitintervall ablaufen.
  • Verschlüsseln Sie Ressourcen, und holen Sie sie bei Bedarf vom Server ab.
  • Oder Sie können eine Hybrid-App erstellen, die über webview Zugriffssystem auf Ressource + Code auf dem Server zugreift

Mehrere Ansätze; Dies ist offensichtlich, Sie müssen unter Leistung und Sicherheit aufgeben

2
mumair

Wenn Ihre App so empfindlich ist, sollten Sie den Zahlungsverarbeitungsteil auf der Serverseite berücksichtigen. Versuchen Sie, Ihre Zahlungsverarbeitungsalgorithmen zu ändern. Verwenden Sie die Android-App nur zum Erfassen und Anzeigen von Benutzerinformationen (d. H. Kontostand) und anstatt Zahlungen innerhalb von Java-Codes zu verarbeiten, senden Sie diese Aufgabe mithilfe eines sicheren SSL-Protokolls mit verschlüsselten Parametern an Ihren Server. Erstellen Sie eine vollständig verschlüsselte und sichere API für die Kommunikation mit Ihrem Server.

Natürlich kann es auch gehackt werden und hat nichts mit dem Schutz von Quellcodes zu tun, sondern es ist eine andere Sicherheitsschicht, die es Hackern erschwert, Ihre App zu betrügen.

1
Muhammad Saqib

Wie kann ich alle Ressourcen, Assets und Quellcode der App schützen, sodass Hacker die APK-Datei auf keine Weise hacken können?

Eine APK-Datei ist mit dem Algorithmus SHA-1 geschützt. Sie können einige Dateien im Ordner META-INF von APK sehen. Wenn Sie eine APK-Datei extrahieren, den Inhalt ändern und erneut komprimieren, wird die APK-Datei auf einem Android-Computer nicht ausgeführt, da die SHA-1-Hashes niemals übereinstimmen. 

1
Jeegar Patel

Ich stimme zu, dass es keine 100% -ige Lösung gibt, die Ihren Code schützen wird, v3 von HoseDex2Jar ist jetzt aktiv, wenn Sie es ausprobieren möchten.

1
Godfrey Nolan

Eine 100% ige Sicherheit des Quellcodes und der Ressourcen ist in Android nicht möglich. Aber Sie können es dem Reverse Engineer etwas schwer machen. Weitere Details hierzu finden Sie unter folgenden Links:

Besuchen Sie Konstante Werte sicher speichern und https://www.agicent.com/blog/mobile-app-security-best-practices/

1
Rajiv Ranjan

wenn sie die App auf ihrem Telefon haben, haben sie vollen Zugriff auf deren Speicher. Wenn Sie also verhindern möchten, dass es gehackt wird, können Sie versuchen, es so zu machen, dass Sie die statische Speicheradresse nicht direkt mit einem Debugger abrufen können. Sie könnten einen Stapelpufferüberlauf ausführen, wenn sie etwas zu schreiben haben und ein Limit haben. Versuchen Sie es also so, wenn sie etwas schreiben, wenn Sie ein Limit haben müssen, wenn Sie mehr Zeichen als Limit einschicken, wenn (Eingabe> Limit) dann ignorieren, so dass sie keinen Assembly-Code dort einfügen können.

0
user3742860

Tool: Wenn Sie Proguard in Ihrer Anwendung verwenden, kann dies auf das Reverse-Engineering Ihrer Anwendung beschränkt sein.

0
Mayank Nema

Ich kann diese gute Antwort in diesem Thread sehen. Neben Facebook können Sie redex verwenden, um den Code zu optimieren. Redex arbeitet auf .dex-Ebene, wo Proguard als .class-Ebene arbeitet. 

0
Asthme