Wie zu vermeiden, reverse engineering eine APK-Datei?
Ich entwickle eine Zahlungsabwicklung app für Android, und ich möchte verhindern, dass ein hacker Zugriff auf alle Ressourcen, Vermögenswerte oder source-code aus dem APK Datei.
Wenn jemand ändert das .apk-Erweiterung .zip, dann können Sie entpacken Sie es und einfacher Zugriff auf alle die app, die Ressourcen und Vermögen, und mit dex2jar und einem Java-decompiler, können Sie auch auf den source code zugreifen. Es ist sehr einfach zu reverse Engineering Android APK-Datei - weitere details finden Sie unter Stack Overflow Frage Reverse engineering aus einer APK-Datei zu einem Projekt.
Habe ich die Proguard-tool, mit dem Android SDK. Wenn ich reverse Engineering einer APK-Datei generiert eine keystore signiert und Proguard, bekomme ich obfuscated code.
Allerdings die Namen von Android-Komponenten unverändert bleiben und einige code wie key-Werte, die in der app bleibt unverändert. Als pro Proguard-Dokumentation mit dem tool können nicht verschleiern genannten Komponenten (in der Manifest-Datei.
Nun meine Fragen:
- Wie kann ich vollständig verhindern, dass reverse engineering Android APK? Ist das möglich?
- Wie kann ich alle schützen die app ist Ressourcen -, Vermögens-und source-code, so dass Hacker nicht hacken Sie die APK-Datei in irgendeiner Weise?
- Ist es eine Möglichkeit zu hacken hart oder sogar unmöglich? Was kann ich tun, um zu schützen, den Quellcode in meine APK-Datei?
Haben Sie in Betracht gezogen, schreiben die wichtigen Teile des Codes in C/C++, und fügen Sie Sie als eine kompilierte Bibliothek? Sie kann zerlegt werden in Assembler-code, aber reverse-engineering eine große Bibliothek von der Montage ist extrem zeitaufwendig.
ja, niemand kann zu dekompilieren von C-code ...
Willkommen auf die grundlegende Frage der Erstellung eines digitalen asset. Hacker können Maschinenbefehl Ebene, so dass, wenn ein computer die Datei Lesen können, dann kann es gehackt werden geöffnet/kopiert werden, wird kein Betrag der Verschleierung oder DRM kann jemals vollständig zu stoppen ein entschlossener hacker. Wenn Sie brauchen Sicherheit, dann stellen Sie sicher, dass der private Schlüssel werden nie in der Quelle und wissen bei der Planung, dass nur die isolation (remote und/oder dedizierte hardware) kann immer schützen.
Beachten Sie, dass je nachdem, was Ihre Zahlungsabwicklung app tut, kann es sein, regulatorische und rechtliche Richtlinien, die Auswirkungen auf Ihre app und können potetially setzen Sie auf eine strenge Bestrafung: siehe PCI-compliance, beginnend mit pcicomplianceguide.org/pcifaqs.php#11.
InformationsquelleAutor sachin003 | 2012-12-13
Du musst angemeldet sein, um einen Kommentar abzugeben.
AFAIK, gibt es nicht irgendeinen trick für die vollständige Vermeidung von reverse engineering.
Und auch sehr gut gesagt @inazaruk: Was auch immer Sie tun, um Ihren code, ein potentieller Angreifer ist in der Lage, es zu ändern, in irgendeiner Weise Sie oder er findet, dass es machbar. Sie können grundsätzlich nicht schützen Sie Ihre Anwendung aus, die geändert wird. Und jeder Schutz, den Sie in es gesetzt werden können deaktiviert/entfernt.
Können Sie verschiedene tricks, um Hacker schwieriger aber. Verwenden Sie zum Beispiel Verschleierung (wenn es Java-code). Diese in der Regel verlangsamt das reverse engineering deutlich.
Ist wie jeder sagt, und wie Sie wahrscheinlich wissen, gibt es keine 100% Sicherheit. Aber der Ort, um zu starten für Android, das von Google gebaut hat, ist ProGuard. Wenn Sie die Möglichkeit haben, einschließlich shared libraries, können Sie den code in C++ um zu überprüfen, Dateigrößen, integration,
etc. Wenn Sie zum hinzufügen eines externen native Bibliothek, um Ihre APK-Bibliothek Ordner für jede Version zu erstellen,
dann können Sie es verwenden, indem Sie die unten Vorschlag.
Setzen Sie die Bibliothek in der nativen library-Pfad standardmäßig auf "libs" in
Ihrem Projekt-Ordner. Wenn Sie gebaut, die nativen code für die 'armeabi' Ziel setzen Sie dann es
unter libs/armeabi. Wenn es gebaut wurde mit armeabi-v7a dann legen Sie es unter
libs/armeabi-v7a.
wie etwa die Verschlüsselung von strings in den code und entschlüsseln Sie zur Laufzeit? Wenn Sie die Entschlüsselung auf einem remote-server, wie andere Leute vorgeschlagen haben, erhalten Sie nicht das problem, dass der Schlüssel für die Entschlüsselung wird in den Quellen.
ja, die Verschlüsselung ist Weg, aber es ist nicht sicher, dass man notHacked. Wenn ich mich verschlüsselnde Zeichenfolge, um Sie zu entschlüsseln, brauche ich eine eindeutige id in den code. und wenn jemand in der Lage, zu dekompilieren, dann wird es sehr leicht zu Holen Sie sich die Eindeutige id.
warum Sie Hinzugefügt Bearbeitet Zeug? alle seine regelmäßigen.
ja das habe ich jetzt entfernt, die "bearbeitet" markieren von Antworten.ich bearbeitet meine Antwort, weil er mehr darüber wissen wollte, wie Bibliotheken gemeinsam nutzen, die in diesem Falle sinnvoll.
InformationsquelleAutor Bhavesh Patadiya
AFAIK, Sie können nicht schützen, Sie die Dateien, die im /res-Verzeichnis mehr, als Sie sind geschützt jetzt.
Allerdings gibt es Schritte, die Sie ergreifen können, um schützen Sie Ihre source-code, oder zumindest das, was es tut, wenn nicht alles.
10000
Münzen. Statt zu sparen10000
direkt, speichern Sie es mit einem Algorithmus wie((currency*2)+1)/13
. Also anstatt10000
sparen Sie1538.53846154
in die SharedPreferences. Aber, das obige Beispiel ist nicht perfekt, und Sie haben zur Arbeit zu kommen mit einer Formel, die nicht verlieren Währung Rundungsfehler etc.$200
. Anstatt eine raw -$200
Wert an den server, das senden einer Reihe von kleineren, vordefinierte Werte, die bis zu hinzufügen$200
. Zum Beispiel haben Sie eine Datei oder Tabelle auf dem server entspricht Wörter mit den Werten. Also lasst uns sagen, dassCharlie
entspricht$47
, undJohn
zu$3
. Also anstatt$200
senden SieCharlie
vier mal undJohn
vier mal. Auf dem server, zu interpretieren, was Sie bedeuten, und fügen Sie es. Dies verhindert, dass ein hacker aus senden von beliebigen Werten auf Ihrem server, da Sie nicht wissen, was word entspricht was Wert. Als ein zusätzliches Maß an Sicherheit, könnte man eine Gleichung wie Punkt 3, und ändern Sie die Schlüsselwörter jedern
Anzahl der Tage.Alles in allem, gibt es keine Möglichkeit, schützen Sie Ihre app zu 100%. Sie können machen es schwieriger, aber nicht unmöglich. Ihr web-server kompromittiert werden könnte, kann der hacker herausfinden konnte, Ihre Schlüsselwörter, indem Sie die überwachung mehrerer Transaktion beläuft und die keywords, die Sie senden, der hacker könnte mühsam gehen durch die Quelle und herauszufinden, welcher code ist ein dummy.
Können Sie sich nur wehren, aber nie gewinnen.
Wirklich? Wenn ich deine RAM besitze ich Sie sowieso...
Sie können die insert-random-useless-source-code in Ihre app. Dies kann nicht wirklich helfen. Dies wird nur aufblasen-Ihre Anwendung, und machen es schwieriger zu pflegen, wie gut.
Wenn Ihr Algorithmus ist Wert von einer million Dollar, dann nur weil es keine decompiler für
.so
Dateien bedeutet nicht, dass ich nicht Lesen kann Baugruppe 🙂 die Meisten von diesen fallen in die gleiche Falle, nur verschleiern, anstatt richtig sich zu schützen. Verschleierung funktioniert nur, wenn es lohnt sich nicht, ein drittes mal durch zu Folgen, so dass, wenn Sie etwas bauen, auf diese Techniken sollten Sie besser hoffen, dass Sie nicht beliebt, sonst sind Sie geschraubt, weil alle plötzlich Ihre Codebasis ist wartbaren und muss es große Veränderungen.Ich verstehe nicht, warum diese Antwort hat so eine hohe Punktzahl. 3. und 4. für die einen sind einfach nur dumm und wird Betrag keine Sicherheit.
InformationsquelleAutor Raghav Sood
Zu keinem Zeitpunkt in der Geschichte der informatik hat es jemals möglich gewesen, zu verhindern, dass reverse-engineering von software, sofern von Ihnen eine Arbeitskopie von Sie zu Ihrem Angreifer. Auch in den meisten Wahrscheinlichkeit, es nie möglich sein wird,.
Mit, dass verstanden wird, gibt es eine naheliegende Lösung: geben Sie nicht Ihre Geheimnisse, um Ihre Angreifer. Sie können zwar nicht schützen Sie den Inhalt Ihrer APK, was Sie kann schützen ist etwas, das du nicht verteilen. In der Regel ist dies der server-Seite software, für Dinge wie Aktivierung, Zahlungen, Regel-Durchsetzung, und andere saftige Stückchen code. Sie können Sie schützen wertvolle Vermögenswerte von nicht verteilen Sie Sie in Ihrem APK. Stattdessen richten Sie einen server, der reagiert auf Anfragen aus der app, "benutzt" das Vermögen (was immer das heißen mag) und dann sendet das Ergebnis zurück an die app. Wenn dieses Modell funktioniert nicht für die assets, die Sie im Sinn haben, dann möchten Sie vielleicht überdenken Sie Ihre Strategie.
Auch, wenn Ihre primäre Ziel ist es, zu verhindern, dass app-Piraterie: gar nicht. Haben Sie schon verbrannt, mehr Zeit und Geld für das problem als jedes anti-Piraterie-Maßnahme jemals hoffen, um Sie zu speichern. Der return-on-investment für die Lösung dieses Problems ist so gering, dass es nicht sinnvoll ist, selbst darüber nachzudenken.
InformationsquelleAutor tylerl
Den Grundlagen der it-Sicherheit basieren auf diesen drei Grundprinzipien; die einzige wirklich sichere computer ist der eine verschlossen in einem safe, in einem Farraday-Käfig, in einem Stahl Käfig. Es sind Computer, verbringen die meisten von Ihrem Dienst Leben, in eben diesem Staat; einmal im Jahr (oder weniger) erzeugen Sie den privaten Schlüssel für Vertrauenswürdige Stammzertifizierungsstellen (vor einer Vielzahl von Zeugen mit Kameras aufzeichnen, jeden Zentimeter des Raumes, in dem Sie sich befinden).
Nun, die meisten Computer sind nicht unter diese Art von Umgebung; Sie sind körperlich im freien, verbunden mit dem Internet über eine wireless-radio-Kanal. Kurz gesagt, Sie sind anfällig, wie Ihre software. Sie sind daher nicht vertraut werden kann. Es gibt bestimmte Dinge, die Computer und Ihre software muss wissen oder tun, um nützlich zu sein, jedoch muss darauf geachtet werden, um sicherzustellen, dass Sie können nie wissen, oder nicht genug Schaden verursachen (zumindest keine bleibenden Schäden außerhalb der Grenzen der einzelnen Maschine).
Sie wußte schon alles; das ist, warum Sie versuchen, zu schützen, die der code Ihrer Anwendung. Aber, darin liegt das erste problem; obfuscation-tools können den code ein Durcheinander für einen Menschen, zu versuchen, zu Graben, durch, aber das Programm immer noch zu laufen; das heißt, die eigentliche Logik Fluss von der Anwendung und den Daten, die er verwendet, sind nicht betroffen von der Verschleierung. Ein wenig Hartnäckigkeit kann ein Angreifer einfach un-verschleiern Sie den code, und das ist auch nicht notwendig, in bestimmten Fällen, in denen das, was er sieht, kann nichts anderes als das, was er sucht.
Statt, Sie sollten versuchen, um sicherzustellen, dass ein Angreifer nichts tun kann, was mit Ihrem code, egal wie einfach es für ihn ist, erhalten Sie eine klare Kopie. Das bedeutet, keine hart-codierten Geheimnisse, weil diese Geheimnisse nicht geheim, sobald der code verlässt das Gebäude, in dem Sie entwickelt wurde.
Diese Schlüssel-Werte, die Sie haben hart codiert sollte entfernt werden aus der Quellcode der Anwendung völlig. Stattdessen sollten Sie in einem der drei Orte; flüchtigen Speicher auf dem Gerät, das ist schwieriger (aber immer noch nicht unmöglich) für einen Angreifer um eine offline-Kopie; dauerhaft auf dem server-cluster, auf die Sie den Zugriff Steuern mit eiserner Faust; oder in einem zweiten datenspeicher unabhängig von Ihrem Gerät oder Server, die wie eine physische Karte oder in Ihrem Benutzer-Erinnerungen (das heißt, Sie wird schließlich werden in flüchtiger Speicher, aber es muss nicht für lange).
Betrachten Sie die folgende Schema. Der Benutzer gibt die Anmeldeinformationen für die app aus dem Speicher in das Gerät. Sie müssen leider darauf Vertrauen, dass der Benutzer das Gerät nicht bereits kompromittiert durch einen keylogger oder Trojaner; das beste, was Sie tun können, in dieser Hinsicht ist die Implementierung von multi-Faktor-Sicherheit, durch das erinnern schwer fake identifizieren, Informationen zu den Geräten der Nutzer (MAC/IP, IMEI, etc), und mindestens einen zusätzlichen Kanal, über den ein login-Versuch auf einem unbekannten Gerät überprüft werden kann.
Die Anmeldeinformationen, einmal eingegeben, sind verschleiert durch die client-software (mit einem secure-hash), und die Klartext-Anmeldeinformationen verworfen; Sie haben Ihren Zweck erfüllt. Die verborgenen Anmeldeinformationen gesendet werden, über einen sicheren Kanal an den Zertifikat-server authentifiziert, welcher hashes Ihnen wieder zu produzieren, die verwendeten Daten zu überprüfen, die Gültigkeit der Anmeldung. Dieser Weg, der Kunde weiß nie, was ist eigentlich im Vergleich zu den Datenbank-Wert, der app-server niemals weiß, der Klartext-Anmeldeinformationen hinter dem, was es empfängt, für die Validierung der Daten-server nie weiß, wie die Daten, die es speichert für die Validierung erzeugt wird, und ein Mann in der Mitte sieht nur Kauderwelsch, auch wenn der sichere Kanal kompromittiert wurden.
Einmal überprüft, der server sendet zurück-token über den Kanal. Das token ist nur dann sinnvoll, innerhalb der sicheren Sitzung besteht aus entweder Rauschen, oder eine verschlüsselte (und damit nachprüfbar) Kopie der session-IDS, und muss die client-Anwendung senden Sie dieses token auf den gleichen Kanal für den server als Teil einer Aufforderung, etwas zu tun. Die client-Anwendung wird das tun, das viele Male, weil es nichts tun kann, mit Geld, vertraulichen Daten, oder irgendetwas anderes, das könnte schädlich sein, indem Sie selbst; es muss stattdessen Fragen Sie den server, um diese Aufgabe. Die client-Anwendung wird nie schreiben, keine sensiblen Informationen in den persistenten Speicher auf dem Gerät selbst, zumindest nicht im Klartext; der client kann den server auffordern, über den sicheren Kanal für einen symmetrischen Schlüssel zum verschlüsseln von lokalen Daten, die der server, werden sich erinnern; in einer späteren Sitzung kann der client fordert vom server die gleichen Schlüssel zum entschlüsseln der Daten für die Verwendung im flüchtigen Speicher. Die Daten nicht nur kopieren, entweder; alles, was der client speichert sollte auch übertragen werden in irgendeiner form an den server.
Offensichtlich, das macht Ihre Anwendung sehr stark abhängig von Internet-Zugang; das client-Gerät nicht durchführen, seine grundlegenden Funktionen ohne die richtige Verbindung und die Authentifizierung durch den server. Nicht anders als Facebook, wirklich.
Nun, dass der computer, der Angreifer will, ist Ihr server, weil es und nicht die client-app/Gerät ist die Sache, die können machen ihn zu Geld oder zu anderen Menschen Schmerzen für seinen Genuss. Das ist OK, man bekommt viel mehr bang für Ihre buck, Geld und Aufwand zu sichern, den server als bei dem Versuch zum sichern der clients. Der server kann hinter allen Arten von firewalls und anderen elektronischen Sicherheit, und zusätzlich kann physikalisch gesichert hinter Stahl -, Beton -, Ausweis/pin-Zugang und 24-Stunden-Videoüberwachung. Ihre Angreifer sehr anspruchsvoll in der Tat zu gewinnen, jede Art von Zugriff auf den server direkt, und würden Sie (sollten) wissen es sofort.
Die besten kann ein Angreifer stehlen ein Telefon eines Benutzers und Anmeldeinformationen und melden Sie sich beim server mit den eingeschränkten rechten des Kunden. Sollte dies geschehen, einfach wie der Verlust einer Kreditkarte, dem berechtigten Anwender sollten angewiesen werden, rufen eine 800-Nummer (vorzugsweise leicht zu merken, und nicht auf der Rückseite einer Karte, die Sie würde tragen in Ihre Geldbörse oder Aktentasche, die gestohlen werden könnten neben dem mobilen Gerät) von jedem Telefon aus zugreifen zu können, verbindet Sie direkt mit Ihren Kunden-service. Sie feststellen, dass Ihr Handy gestohlen wurde, einige grundlegende eindeutigen Bezeichner, und der account wird gesperrt, jegliche Transaktionen, die der Angreifer möglicherweise in der Lage zu verarbeiten sind, rollte zurück, und der Angreifer ist wieder auf Platz eins.
Ich weiß das ist ein bisschen spät, aber was ist mit dem Zugriff auf die Zugriff auf den server-Teil. Dienste wie Microsoft azure bietet Sie so etwas wie dieses, um den Zugriff auf Ihre server: MobileServiceClient mClient = new MobileServiceClient( "MobileServiceUrl", // Ersetzen mit den oben genannten Site URL "AppKey", // ersetzen Sie die Application-Taste) und so ziemlich jeder, der Zugriff auf, die Zugriff auf Ihren server zu Ende Bearbeiten
Kein problem in der informatik, die nicht gelöst werden können, mit einer anderen Schicht der Dereferenzierung. Das snippet gibt die grundlegende Idee für den Zugriff auf ein Azure mobile-client-service; es bietet eine grundlegende Sicherheit gegen "drive-bys" von Microsoft vor der Tür. Sie können im Gegenzug fügen Sie zusätzliche Schichten, wie die eine session-key (im Grunde, was das verschlüsselte token ist) auf jedem service-Aufruf, und zu bekommen, dass die Schlüssel, muss er zuerst eine Authentifizierung mit einer Kombination aus wissen um die Anmeldeinformationen und das Verschlüsselungsschema.
InformationsquelleAutor KeithS
Ist dies nicht möglich,
Wenn sich jemand ändern .apk-Erweiterung .zip, dann nach dem entpacken, kann mir jemand bequem alle Ressourcen (außer Manifest.xml), aber mit APKtool kann man den wirklichen Inhalt der manifest-Datei zu. Wieder ein Nein.
Wieder, Nein, aber Sie können verhindern, dass bis zu einer bestimmten Ebene, das ist,
Sogar mit
Smali
, Menschen spielen mit Ihrem code. Alles in allem, es ist nicht MÖGLICH.Es ist das "how to do" - Teil, obwohl, der, der tötet die ganze Idee. Es gibt einfach keine Möglichkeit zum ausführen von verschlüsselten code direkt; an einem gewissen Punkt, der entschlüsselte code verfügbar sein muss. Was bedeutet, dass (1) es muss eine Taste (die ich als root wahrscheinlich Zugriff haben) und (2) ich könnte sogar in der Lage zu finden, die Kopie im RAM und nicht nur sorgen über die Verschlüsselung sowieso.
Problem ist, in diesem Fall können Sie einfach nicht erhöhen die Kosten genug, um es nicht lohnt. Wir reden hier nicht über brute-forcing Schlüssel hier; wir reden über bereits -- das OS hat den Schlüssel, und wir haben das OS. Der einzige Weg, das zu beheben, wäre die OS unrootable. Viel Glück mit diesem, auch Apple kann es nicht verwalten. 🙂
Ich glaube nicht, dass die Erhöhung der Kosten im Allgemeinen ist unmöglich. Ich denke (und sage), insbesondere, dass Ihr Vorschlag unmöglich ist -- denn Sie. MATLAB ist nicht Android, und hat gewisse Freiheiten, die Android nicht. Insbesondere hat sich die Verschleierung auf die Seite; es ist viel schwerer, sich zu verstecken einen Schlüssel für die Verschlüsselung. Android kann das nicht tun. Wer den Quellcode hat, würde wissen, wo die Schlüssel versteckt sind, und würde ein tool haben, rufen Sie innerhalb von 10 Minuten des Features angekündigt werden. Es ist nicht nur möglich, das zu tun; es ist geradezu trivial.
Ich habe darauf bestanden, nichts dergleichen. Was ich darauf zu beharren ist, dass statische, ändern, verschieben, etc nicht wichtig. In einer open-source-OS, Verschlüsselung alleine nicht schützen können den code aus wer könnte reverse Engineering. Weil ich Lesen kann, der code, die Entschlüsselung, unabhängig davon, wie der Schlüssel ist, erworben, genutzt und/oder gespeichert werden, kann ich sehen, wie du es getan hast und zu replizieren-sogar leichter als ich umkehren könnten einige super geheimen app-code.
InformationsquelleAutor Azhar Shaikh
100% Vermeidung von " reverse engineering Android APK ist nicht möglich, aber Sie können diese Möglichkeiten zu vermeiden, extrahieren mehr Daten, wie z.B. source code, Vermögen bilden, Ihre APK und Ressourcen:
Verwenden ProGuard zu verschleiern Anwendung code
Verwenden NDK Verwendung C und C++ Ihre Anwendung auf Kern und sicheren Teil des Codes in
.so
DateienZu Ressourcen sichern, zählen Sie nicht alle wichtige Ressourcen in den Asset-Ordner mit APK. Laden Sie diese Ressourcen, die Zeit der Anwendung zum ersten mal starten.
Um das problem zu lösen, wird der Dritte, könnte man die Verschlüsselung der heruntergeladenen Inhalte und/oder die Verwendung einer verschlüsselten Verbindung (z.B. SSL/TLS)
Die Verschlüsselung der Verbindung schützt gegen Leute, die schnüffeln oder zu modifizieren Verkehr. In dem Fall, wo der Benutzer selbst bösartig ist (d.h. er hat Ihre apk und er hat versucht, es zu hacken), wird er dennoch bekommen die Inhalte Ihre app verwenden, extrahieren Ressourcen als root-Benutzer; aber ja, es hilft gegen einfache sniffing-Angriffe.
InformationsquelleAutor ρяσѕρєя K
Entwickler können folgende Schritte aus, um zu verhindern, dass eine APK von Diebstahl irgendwie
die einfachste Möglichkeit ist die Verwendung von tools wie
ProGuard
zu verschleiern Ihre Codes, aber bis jetzt, hat es schon ganz schwierig, vollständig zu verhindern, dass jemand das dekompilieren einer app.Habe auch ich hörte von einem tool HoseDex2Jar. Es hält
Dex2Jar
durch einfügen harmlos-code in eine Android-APK, die verwirrt und deaktiviertDex2Jar
und schützt den code vor Dekompilierung. Könnte es irgendwie verhindern, dass Hacker aus der Dekompilierung einer APK in lesbaren java-code.Verwenden einige server-side Anwendung für die Kommunikation mit der Anwendung nur wenn es nötig ist. Es könnte helfen, verhindern, dass die wichtigen Daten.
Überhaupt, können Sie nicht vollständig schützen Sie Ihren code vor den potenziellen Hacker. Irgendwie, Sie könnte es schwierig machen, und ein bisschen frustrierende Aufgabe für Sie zu dekompilieren den code. Einer der effizienteste Weg, um schreiben zu können, die in nativem code(C/C++) und speichern es als kompilierte Bibliotheken.
Wissen Sie, wie HoseDex2Jar funktioniert? Was Sie verwendet haben, zu vermeiden oder zu verwirren dex2jar.Da kann ich nicht hochladen, meine apk-Datei, um das web zu verwenden HoseDex2Jar. Wenn ich etwas tun kann, wie HoseDex2Jar zu verwechseln dex2jar dann wird Es schwer zu hack verwenden tool dex2jar.
intrepidusgroup.com/insight/2012/10/unhosing-apks
github.com/strazzere/dehoser
Vielleicht haben Sie missverstanden mein Punkt: was HoseDex2Jar tut, ist, Verpacken Sie Ihre APK so, dass die populären dex2jar-tool kann nicht (aus der box) Rücklauf. Es gibt aber auch andere tools können, und es ist sehr leicht zu besiegen, im Allgemeinen. Keinen Sinn, es zu benutzen. Niemand erwähnt Dexguard ich die Sache (von der Autorin von ProGuard; nicht kostenlos), aber es ist Arbeit betrachten. Es hat ein paar mehr Sache als die 'regelmäßigen' Verschleierung.
InformationsquelleAutor Sahil Mahajan Mj
Unmöglich
Unmöglich
Mehr schwer möglich, aber in der Tat, es wird mehr sein hart, vor allem für den durchschnittlichen Benutzer, der einfach nur googeln für hacking-Anleitungen. Wenn jemand wirklich will, um hack app es wird gehackt, früher oder später.
InformationsquelleAutor janot
, Dass ist unmöglich
Entwickler können die Schritte wie die Verwendung von tools wie ProGuard zu verschleiern Ihre Codes, aber bis jetzt, hat es schon ganz schwierig, vollständig zu verhindern, dass jemand das dekompilieren einer app.
Es ist ein wirklich tolles tool und erhöhen die Schwierigkeit, 'die Umkehrung' code schrumpfen, während Ihr code-Fußabdruck.
Integriert ProGuard-Unterstützung: ProGuard ist nun verpackt, die mit den SDK-Tools. Entwickler können jetzt verschleiern Ihre code als integrierter Bestandteil der release-build.
Während der recherche, kam ich zu wissen über HoseDex2Jar. Dieses tool schützen Sie Ihren code aus Dekompilierung, aber es scheint nicht möglich zu sein, um den code zu schützen komplett.
Einige hilfreiche links, können Sie auf diese verweisen.
InformationsquelleAutor RobinHood
Die wichtigste Frage ist hier, kann die dex-Dateien dekompiliert werden, und die Antwort ist, können Sie "Sortieren". Es gibt Zerleger wie dedexer und smali.
ProGuard, ordnungsgemäß konfiguriert ist, wird Ihren code zu verschleiern. DexGuard, die ein kommerzielles erweiterte version von ProGuard, kann helfen, ein bisschen mehr. Allerdings kann der code noch umgewandelt werden in smali und Entwickler mit reverse-engineering-Erfahrung wird in der Lage sein, um herauszufinden, was Sie tun, aus dem smali.
Vielleicht wählen Sie eine gute Lizenz und erzwingen es durch das Gesetz in der bestmöglichen Weise.
InformationsquelleAutor Abhishek Sabbarwal
Hier sind ein paar Methoden, die Sie ausprobieren können:
InformationsquelleAutor Shan
Ihre Kunden sollten Sie mieten jemand, die weiß, was Sie tun, wer kann die richtigen Entscheidungen treffen und Mentoren für Sie.
Reden oben über Sie, dass einige Möglichkeit zum ändern des transaction-processing-system auf, das backend ist absurd - Sie sollte nicht erlaubt werden, um solche änderungen in der Architektur, also erwarten Sie nicht zu können.
Meine Begründung dazu:
Da Ihre Domäne ist die Zahlungsabwicklung, die Ihr sicher davon ausgehen, dass PCI-DSS und/oder PA-DSS sind (und potenzielle Staat/Bundesgesetz) wird erheblich sein, um Ihre business - konform sein, müssen Sie zeigen, dass Sie sicher sind. Unsicher, dann erfahren (per Test), dass Sie nicht sicher ist, dann fixieren, Wiederholungen, usw. bis die Sicherheit nachgewiesen werden kann bei einem geeignetem Niveau = teuer, langsam, mit hohem Risiko Wege zum Erfolg. Das richtige zu tun, denken Sie gründlich nach vorne, Begehen erfahrene Talente für den job, entwickeln sich in einer sicheren Art und Weise, dann test, fix (weniger), etcetera (weniger), bis die Sicherheit nachgewiesen werden kann bei einem geeignetem Niveau, = - preiswert und schnell, geringes Risiko Weg zum Erfolg.
InformationsquelleAutor straya
Den anderen von Ihnen positiv bewertet werden die Antworten hier sind richtig. Ich will nur eine weitere option.
Für bestimmte Funktionen, die Sie als notwendig erachtet werden, können Sie hosten die WebView Kontrolle in Ihre app. Die Funktion würde dann umgesetzt werden auf Ihrem web-server. Es wird so Aussehen, wie es läuft in Ihrer Anwendung.
Botha ja für IMP-Bildschirme habe ich bereits verwendet webview & ja, das ist auch ein Weg, um die Sicherheit zu gewährleisten, bin ich der Annahme Ihrer Antwort.
InformationsquelleAutor Sarel Botha
Wenn wir wollen, um reverse engineering (fast) unmöglich, wir können die Anwendung auf einen sehr manipulationssicheren chip, der führt alle empfindlichen Sachen intern und kommuniziert mit einigen Protokoll, um die Steuerung GUI möglich auf dem host. Auch manipulationssichere chips sind nicht 100% Riss-Beweis; Sie haben die Messlatte viel höher ist als software-Methoden. Das ist natürlich unbequem: die Anwendung erfordert einige kleine USB-Warze, die hält den chip in das Gerät eingesetzt.
Die Frage nicht offenbart, die motivation für den Wunsch, zu schützen, die diese Anwendung so eifersüchtig.
Wenn das Ziel ist die Verbesserung der Sicherheit der Zahlungsmethode, die Sie verbirgt, was Sicherheitslücken der Anwendung haben kann (bekannt oder nicht), ist es völlig in die falsche Richtung gedacht. Die security-sensitive bits sollte eigentlich open-Source, wenn dies möglich ist. Man sollte es so einfach wie möglich für jedes security-Forscher, die Bewertungen Ihrer Anwendung zu finden, die bits und durchleuchten Ihren Betrieb, und Sie zu Kontaktieren. Payment-Anwendungen sollten nicht enthalten eingebettete Zertifikate. Das heißt, es sollte keine appliaction server, die vertraut einem Gerät einfach, weil es hat eine Feste Zertifikat von der Fabrik. Eine Zahlung gemacht werden sollte, auf die Anmeldeinformationen des Benutzers, die allein, mit einem korrekt ausgelegte end-to-end-Authentifizierung-Protokoll, das verhindert, das Vertrauen in die Anwendung, oder die Plattform oder das Netzwerk, etc.
Wenn das Ziel ist, zu verhindern, dass das Klonen, um es kurz zu manipulationssichere chip, es gibt nichts, was Sie tun können, schützen Sie das Programm aus der Zurückentwicklung und kopiert, so, dass jemand ein kompatibles Zahlungsmethode in Ihrer eigenen Anwendung, die Anlass zu "autorisierte Kunden". Es gibt Möglichkeiten, machen es schwierig, sich zu entwickeln, nicht autorisierte clients. Da wäre zum erstellen von Prüfsummen basiert auf snapshots des Programms abgeschlossen Status: alle Status-Variablen, für alles. GUI -, Logik -, was auch immer. Ein clone-Programm wird nicht exakt die gleichen internen Zustand. Sicher, es ist eine state-Maschine, die ähnlich wie äußerlich sichtbaren Zustandsübergänge (wie beobachtet werden kann, durch ein-und Ausgänge), aber kaum die gleichen internen Zustand. Eine server-Anwendung können befragen das Programm: was ist Ihre detaillierte Status? (d.h. gib mir eine Prüfsumme über alle Ihre internen Zustandsvariablen). Dies kann verglichen werden dummy-client-code, der ausgeführt wird auf dem server parallel, werde durch das echte state-übergänge. Ein Dritter Klon replizieren alle relevanten Statusänderungen der echte Programm, um die richtigen Antworten, die behindern Ihre Entwicklung.
InformationsquelleAutor Kaz
Als jemand, der gearbeitet auf payment-Plattformen, einschließlich einer mobile payment-Anwendung (MyCheck), ich würde sagen, Sie müssen delegieren, die dieses Verhalten an den server, kein Benutzername oder Passwort für die Zahlung Prozessor (je nachdem, was es ist) gespeichert werden sollen oder fest kodiert in der mobilen Anwendung, das ist das Letzte, was Sie wollen, weil die Quelle verstanden werden kann, auch wenn Sie verschleiern die code.
Auch, Sie sollten nicht speichern Kreditkarten-oder payment-Token auf die Anwendung, dann sollte alles wieder übertragen ein service, den Sie gebaut haben, wird es auch ermöglichen es Ihnen später, werden PCI-konform leichter, und die Kreditkarten-Unternehmen nicht Atem den Hals (wie Sie für uns getan haben).
InformationsquelleAutor Itai Sagi
Ich schlage vor, Sie Blick auf Schützen Software-Anwendungen vor Angriffen. Es ist ein kommerzieller Dienst, aber meinem Freund zu Unternehmen und sind froh, dass es zu benutzen.
InformationsquelleAutor Talha
APK-Signatur-Schema v2 in Android N
Die PackageManager-Klasse unterstützt jetzt die überprüfung von apps mit dem APK-Signatur-Schema v2. Die APK-Signatur-Schema v2 ist ein ganzes-Datei-Signatur-Schema, dass deutlich verbessert die überprüfung von Geschwindigkeit und stärkt die Integrität garantiert durch die Erkennung von nicht autorisierten änderungen an APK-Dateien.
Zur Aufrechterhaltung der Abwärtskompatibilität, eine APK-unterzeichnet werden muss, die mit der v1 signature scheme (JAR-Signatur-Schema), bevor Sie unterzeichnet mit dem v2-Signatur-Schema. Mit der v2-Signatur-Schema, schlägt die überprüfung fehl, wenn Sie signieren der APK mit einem zusätzlichen Zertifikat nach der Unterzeichnung mit dem v2 System.
APK-Signatur-Schema v2-Unterstützung verfügbar sein wird später in die N Developer Preview.
http://developer.android.com/preview/api-overview.html#apk_signature_v2
Darüber hinaus können Sie einfach entfernen Sie die Signatur-und re-signieren. Die v2-Signatur ist nur einen block von Daten in die APK-Datei.
InformationsquelleAutor thiagolr
Im Grunde ist es nicht möglich. Es wird nie möglich sein wird. Doch es gibt Hoffnung. Sie können eine obfuscator zu machen, so dass einige gemeinsame Angriffe sind viel schwieriger durchzuführen, einschließlich Dinge wie:
a.a
)Ich bin sicher, es gibt andere, aber das sind die wichtigsten. Ich arbeite für eine Firma namens Präemptiven Lösungen .NET obfuscator. Sie haben auch ein Java obfuscator, das funktioniert für Android-als auch eine namens DashO.
Verschleierung kommt immer mit einem Preis, though. Insbesondere die Leistung in der Regel schlechter, und es erfordert einige zusätzliche Zeit, um die meisten Veröffentlichungen. Allerdings, wenn Sie Ihr geistiges Eigentum ist sehr wichtig für Sie, dann ist es meist Wert.
Sonst, Ihre einzige Wahl ist, um es so zu machen, dass Ihre Android-Anwendung durchläuft, um einen server, dass hosts, die alle die eigentliche Logik der Anwendung. Diese hat Ihre eigenen Probleme, weil es bedeutet, dass Benutzer müssen mit dem Internet verbunden sein, um Ihre app verwenden.
Auch, es ist nicht nur Android, der dieses problem hat. Es ist ein problem auf jedem app store. Es ist nur eine Frage, wie schwierig es ist zu bekommen, um die Paket-Datei (für Beispiel, ich glaube nicht, dass es sehr einfach ist, auf iPhones, aber es ist immer noch möglich).
InformationsquelleAutor Earlz
Seine nicht vollständig vermeiden RE aber, Indem er Sie komplexer intern, setzen Sie machen es schwieriger für die Angreifer zu sehen, die übersichtliche Bedienung der app, die möglicherweise verringern die Anzahl der Angriffsvektoren.
Wenn die Anwendung verarbeitet hochsensible Daten, Verschiedene Techniken existieren, die Erhöhung der Komplexität der reverse-engineering-code. Eine Technik ist der Einsatz von C/C++ zu begrenzen einfache Laufzeit-manipulation durch den Angreifer. Es gibt genügend C-und C++ - Bibliotheken, die sind sehr ausgereift und einfach zu integrieren mit Android bietet JNI. Ein Angreifer muss zunächst die Umgehung der debugging-Einschränkungen, um zum Angriff auf die Anwendung auf einem niedrigen Niveau. Dies fügt zusätzliche Komplexität eines Angriffs. Android-Anwendungen haben sollte android:debugfähiger="false" legen Sie in der Anwendung manifestieren, um zu verhindern, dass einfache Laufzeit-manipulation durch einen Angreifer oder malware.
Trace-Überprüfung – Eine Anwendung kann bestimmen, ob oder nicht es ist derzeit verfolgt, die von einem debugger oder andere debugging-tool. Wenn verfolgt wird, die Anwendung kann führen Sie eine Reihe von möglichen attack-response-Aktionen, wie z.B. verwerfen, die Verschlüsselung Schlüssel, Nutzerdaten zu schützen, müssen Sie ein server-administrator sind, oder andere solche Art von Antworten in einem Versuch, sich selbst zu verteidigen. Diese können ermittelt werden durch überprüfen der Prozess-status-flags oder die Verwendung anderer Techniken, wie der Vergleich der Rückgabewert von ptrace befestigen, die überprüfung des übergeordneten Prozesses, blacklist-Debugger in der Prozess-Liste oder der Vergleich von Zeitstempeln an verschiedenen stellen des Programms.
Optimierungen - ausblenden, erweiterte mathematische Berechnungen und andere Arten von komplexen Logik, unter Verwendung der compiler-Optimierungen können helfen, verschleiern der Objekt-code, so dass es nicht leicht zerlegt werden, indem ein Angreifer, so dass es schwieriger für einen Angreifer, ein Verständnis zu gewinnen von dem bestimmten code. In Android kann dies leichter erreicht werden durch die Verwendung von nativ kompilierten Bibliotheken, die mit dem NDK. Darüber hinaus, mit einem LLVM-Obfuscator oder irgendwelche protector SDK eine bessere Maschine, code-Verschleierung.
Strippen binaries – Stripping systemeigene Binärdateien ist ein effektiver Weg zur Erhöhung der Menge an Zeit und skill-level benötigt ein Angreifer, um das make-up der Anwendung der low-level-Funktionen. Durch das Strippen einer binären, die symbol-Tabelle der Binärdatei entfernt wird, so dass ein Angreifer nicht einfach Debuggen oder reverse Engineering einer Anwendung.Sie können sich Techniken verwendet, auf GNU/Linux-Systeme wie sstriping oder mit dem Programmpaket UPX.
Und endlich müssen Sie sich bewusst sein, über Verschleierung und tools wie ProGuard.
InformationsquelleAutor Sanket Prabhu
Gibt es keinen Weg, um vollständig zu vermeiden, reverse-engineering einer APK. Zum Schutz der Vermögenswerte Anwendung, Ressourcen, können Sie eine Verschlüsselung verwenden.
InformationsquelleAutor immutable
Vereinbart mit @Muhammad Saqib hier:
https://stackoverflow.com/a/46183706/2496464
Und @Mumair einen guten Start Schritte:
https://stackoverflow.com/a/35411378/474330
Es ist immer davon auszugehen, dass alles, was Sie verbreiten, um Ihre Benutzer-Gerät, gehören dem Benutzer. Schlicht und einfach. Sie können möglicherweise verwenden Sie die neuesten tools und Verfahren zu verschlüsseln, die Ihre geistigen Eigenschaften, aber es gibt keine Möglichkeit zu verhindern, dass eine bestimmt person aus dem "studieren" Ihrer Anlage. Auch wenn die aktuelle Technologie mag es Ihnen schwer machen zu gewinnen unerwünschten Zugriff, möglicherweise gibt es einige einfache Weg, morgen oder auch nur die nächste Stunde!
So, hier kommt die Gleichung:
Sogar als einfacher als in-game Wirtschaft. (Besonders bei spielen! Es gibt mehr 'sophisticated' Benutzer und Lücken verbreiten sich in Sekunden!)
Wie wir sicher bleiben?
Meisten, wenn nicht alle, unserer key-processing-Systeme (und die Datenbank natürlich), die sich auf der server-Seite. Und zwischen client und server liegt, verschlüsselte Kommunikation, Validierungen, etc. Das ist die Idee von thin-client.
InformationsquelleAutor Zennichimaro
Nicht TPM-chips (Trusted Platform Module) sollen verwalten geschützt-code für Sie ? Sie sind immer häufiger auf PCs (vor allem Apfel) und Sie möglicherweise bereits vorhanden ist, in der heutigen smartphone-chips. Leider gibt es keine OS-API zu nutzen es noch nicht. Hoffentlich wird Android hinzufügen von Unterstützung für diesen einen Tag. Das ist auch der Schlüssel für saubere Inhalte, die DRM (die Google für WebM).
InformationsquelleAutor robUx4
webview
schützen Ressource + code auf dem serverMehrere Ansätze; das ist offensichtlich, Sie haben, um Opfer unter Leistung und Sicherheit
InformationsquelleAutor mumair
Eine APK-Datei ist geschützt mit der SHA-1 Algorithmus. Sie können einige Dateien in den META-INF Ordner von APK. Wenn Sie das extrahieren von APK-Datei und ändern Sie Ihre Inhalte und zip es wieder und wenn Sie ausführen, dass die neue APK-Datei auf einem Android-Maschine, es wird nicht funktionieren, da der SHA-1-hashes wird nie passen.
Dies kann verhindern, dass das android-Gerät aus ausgeführt geänderten code, aber man kann immer noch leicht extrahieren Sie die relevanten code und neuen code schreiben auf einem PC was macht, was man will.
InformationsquelleAutor Jeegar Patel
Während ich damit einverstanden, es gibt keine 100% Lösung um den code zu schützen, v3 von HoseDex2Jar ist jetzt, wenn Sie möchten, es zu versuchen.
InformationsquelleAutor Godfrey Nolan
Wenn Ihre app diese sensiblen dann sollten Sie die Zahlungsabwicklung Teil auf server-Seite. Versuchen Sie, ändern Sie Ihre Zahlung processing-algorithmen. Die android app ist nur zum sammeln und anzeigen von Informationen für den Benutzer (ich.e-Konto-Guthaben) und eher als die Verarbeitung von Zahlungen innerhalb des java-codes, schicken Sie diese Aufgabe, um Ihren server mit einer sicheren SSL-Protokoll verschlüsselte Parameter. Erstellen Sie voll verschlüsselte und sichere API zur Kommunikation mit dem server.
Natürlich kann Es auch sein, auch gehackt und es hat nichts zu tun mit dem Quellcode-Schutz, aber halte es für eine weitere security-Schicht, um es schwieriger für Hacker zu betrügen, Ihre app.
InformationsquelleAutor Muhammad Saqib
wenn Sie die app auf Ihrem Handy haben, haben Sie vollen Zugriff auf den Speicher. so, wenn u wollen, zu verhindern, dass es gehackt wird, könnten Sie versuchen, es so zu machen, dass u cant Holen Sie sich den statischen Speicher-Adresse direkt mit Hilfe eines Debuggers. Sie könnten einen stack-überlauf, wenn Sie irgendwo zu schreiben, und Sie haben ein limit. so versuchen, es so zu machen, wenn Sie etwas schreiben, wenn u haben eine Grenze haben, wenn Sie senden in mehr chars als limit, if (input > limit) dann ignorieren, so dass Sie cant Assembler-code gibt.
InformationsquelleAutor user3742860
Tool: Mit Proguard in Ihrer Anwendung beschränkt werden kann, auf reverse-engineering Ihre Anwendung
InformationsquelleAutor Mayank Nema
Kann ich sehen, dass gute Antwort in diesem thread . Zusätzlich können Sie facebook
redex
den code optimieren. REDEX höchste funktioniert auf.dex
Ebene, wo proguard Arbeit als.class
Ebene.InformationsquelleAutor Asthme
Nur eine Ergänzung zu den bereits guten Antworten.
Anderen trick, den ich kenne, ist zum speichern von wertvollen codes als Java-Library. Legen Sie dann die Bibliothek auf Ihr Android-Projekt. Wäre gut als C ist .so Datei aber Android Lib tun würde.
Diese Weise werden diese wertvollen gespeicherte codes auf Android-Bibliothek nicht sichtbar, nachdem dekompilieren.
Seltsam, nicht in meinem Fall. Ich habe 4 libs. Google-Lizenzierung + Ziemlich + android.Unterstützung.v4.ViewPagerIndicator + Meine Interne Lib kommt aus dem Android-Projekt als Bibliothek. Das Android-Projekt als Lib ist nicht sichtbar. Während die anderen 3 sichtbar sind.
es wird sichtbar sein, wenn Sie zu dekompilieren der Klassen.dex-Datei und öffnen Sie es
yup, die ich verwendet, dex2jar und jd zu simulieren. Aber ich kann ihn nicht finden. Haben Sie versucht,?
InformationsquelleAutor stuckedoverflow