Android NDK Möglichkeit der Dekompilierung native code

Ist es möglich, zu entschlüsseln, native-code kompiliert und gerne android durch ndk ?

und ist es möglich von der apk zu rekonstruieren, das Projekt und importieren Sie Sie in eclipse (oder einer anderen IDE)?

ist es möglich, die .so Dateien in der apk-Datei wieder zu rekonstruieren, das Projekt oder ein anderes Projekt, wenn das java native Funktion Erklärung ist angemessen?

Verloren Ihre Quelle, eh?
Todd nicht wirklich, ich will nur sicherstellen, dass mein code sicher ist.

InformationsquelleAutor | 2015-03-04

  1. 2

    Dekompilieren, native source code ist (vermutlich, ich war nicht versucht, es) möglich ist, gibt es einige tools wie dieses https://www.hex-rays.com/products/decompiler/

    Ist es möglich zu rekonstruieren Projekt von apk aber wird der code verschleiert (komisch, Klassen-und Methodennamen). Sie können überprüfen Sie Ihre app gegen apk2gold (https://github.com/lxdvs/apk2gold)

    Als für Ihre Letzte Frage, mit ein wenig Mühe - ja.

    Ich dachte, wenn ich meine native code zu tun, eine Prüfung auf Paket-Namen und Absturz, wenn Sie geändert werden. würde das helfen? @jaroslawj
    Zu einem gewissen Grad - ja. Aber reverse-engineering Ihrer Bibliothek können Sie "deaktivieren", diese Einschränkung oder änderung überprüft Paket-Namen. Sie können prüfen, "strings" - Befehl auf Ihrem .also Datei - es wird Ihnen zeigen, sichtbar Symbole. Angreifer können auch "anpassen" Ihr Paket Namensgebung in seinem Java-code...
    Haben Sie dies Lesen: fuzion24.github.io/android/Verschleierung/ndk/llvm/o-llvm/2014/07/... ?

    InformationsquelleAutor jaroslawj

  2. 0

    ist es möglich von der apk zu rekonstruieren, das Projekt und importieren Sie es
    in eclipse (oder einer anderen IDE)?

    Dies kann durch dex decompilers und apk-Ressourcen-Extraktoren.

    Ist es möglich, zu entschlüsseln, native-code kompiliert und gerne android
    durch ndk ?

    ist es möglich mit dem .so dass die Dateien in der apk-Datei wieder zu
    rekonstruieren Sie das Projekt oder ein anderes Projekt, wenn das java native
    Funktion Erklärung ist angemessen?

    Sobald man das gemeinsame Objekt, Sie kann fügen Sie es in Ihr eigenes Projekt. Sie können dump Globale Symbole der Bibliothek und lernen, deren Nutzung über der dekompilierte Java-code. Jedoch, wenn gemeinsame Objekt zu bauen-gegen eine spezifische Architektur, die Sie möglicherweise nicht in der Lage, um es wieder aufzubauen, die über andere Plattformen.

    ndk baut für 7 oder 8 Bögen. Dies bedeutet, es ist möglich, dass diejenigen, die .so - Dateien verwendet werden, die in jedem Projekt.
    Ich dachte, wenn ich meine native code zu tun, eine Prüfung auf Paket-Namen und Absturz, wenn Sie geändert werden. würde das helfen?
    Wahrscheinlich. Können Sie Ihre apk-Gültigkeit durch nativen code. Diese Frage kann dir helfen : stackoverflow.com/questions/15025304/...

    InformationsquelleAutor Efe Kahraman

  3. 0

    Ist es möglich, zu entschlüsseln, native-code kompiliert und gerne android durch ndk ?

    Kann man zerlegen; gibt es in C/C++ decompilers, aber für wirklich komplexe Codes sind Sie fast nutzlos.

    und ist es möglich von der apk zu rekonstruieren, das Projekt und importieren Sie Sie in eclipse (oder einer anderen IDE)?

    ist es möglich, baksmali (zerlegen) ein .apk, etwas reparieren und smali (montieren) wieder. Kann man ersetzen einige Funktionsaufrufe, die durch eine andere Funktion aufruft, und man kann neue Klassen hinzufügen.

    Dekompilieren Java ist auch möglich, aber der code wird wahrscheinlich nicht kompilieren, so ist es vielmehr, über die Analyse als über die änderung.

    Obfuscated code noch lesbar ist, vorausgesetzt, dass Sie investieren einige Anstrengungen in der Analyse.

    Können Sie verschleiern den code, aber Sie werden sehen, Symbole, Sie finden die Ressource-ids, und Sie finden die onClick() button-Handler.

    ist es möglich mit dem .so dass die Dateien in der apk-Datei wieder zu rekonstruieren, das Projekt oder ein anderes Projekt, wenn das java native
    Funktion Erklärung ist angemessen?

    Haben Sie kein problem mit der Verwendung .so wie Sie ist mit einem anderen Projekt (es sei denn, jemand bittet Sie um einen bug zu beheben .so). In der gleichen Weise, die Sie machen können eine .jar von Ihr .apk und verwenden .jar als Bibliothek mit einem anderen Projekt.

    Im Allgemeinen, ein .so ist es ein bisschen schwieriger zu basteln, als mit einer .jar .

    ist es irgendwie verhindern, dass jemand über meinen code als jar-Datei zum Beispiel, und neu veröffentlichen? wie die Berichterstattung es zu Google?
    Da der Mensch mehr als geniale Roboter, Nein, zumindest nicht automatisch. Sie können nur machen es schwieriger. Aber Sie können beobachten die Wettbewerbsprodukte und wenn Sie sehen, einige Pakete/Klassen/Funktionen, wie com.package.hjh.Gjkjsfdl.jdsfgshhdfghj(String, String) (kein normaler Mensch würde jemals eine solche Funktion den Namen), können Sie den Bericht des Missbrauchs. Der einfachste Weg ist die Verwendung eines spezifischen log-Meldung, wenn die app initialisiert.

    InformationsquelleAutor 18446744073709551615

  4. -1

    Ist es möglich, zu entschlüsseln, native-code kompiliert

    Nicht.

    ist es möglich von der apk zu rekonstruieren, das Projekt

    Ja, eine Menge davon. Extrahieren .class Dateien ist einfach, Dekompilierung meist zu. Eine Verschleierung Schritt in Ihren build-Prozess, wird dies sehr viel schwieriger.

    Jedoch Konstante Werte und initilizers sind sehr leicht zu bekommen aus einer kompilierten Klasse. Versuchen Sie nicht, etwas wie private static String SECRET = "sesame123";. Das ist gar nicht so schwer zu reverse Engineering. - Das gleiche übrigens gilt für .so Dateien zu.

    ist es möglich mit dem .so dass die Dateien in der apk-Datei wieder zu rekonstruieren, das Projekt

    Nicht.

    Es hängt davon ab, was meinst du mit "Projekt". Die Funktionen der Unterschriften und der nativen Bibliothek sind wahrscheinlich leicht zu erholen von den entsprechenden (kompilierten) Java-Klasse auf jeden Fall. Die (Quell-)code ist im Grunde "verloren" für das gute nach dem kompilieren in systemeigenen code. Wenn jemand weiß, wie Sie Ihre gemeinsam genutzte Bibliothek, obwohl (einfach, herauszufinden, siehe oben), er wäre in der Lage zu verwenden es in welcher app er mag.

    Um es zusammenzufassen:

    a) Der source-code kann nicht rekonstruiert werden, aus der kompilierte native code.

    b) Java-Quellcode ist wesentlich einfacher zu rekonstruieren, die aus kompilierten .class Dateien; Verschleierung des Codes kann es schwerer machen.

    c) Alle Funktionen, die Ihre app, native oder nicht, kann ganz leicht entnommen werden und ausgenutzt von einer anderen app kann der Angreifer schreiben.

    Siehe auch: http://en.wikipedia.org/wiki/Security_through_obscurity

    "Der Quellcode kann nicht rekonstruiert werden von der kompilierte native code" - während die original-source-code verloren gegangen ist, es sind sicherlich native (Maschinen -) code decompilers. Siehe reverseengineering.stackexchange.com/questions/311/....
    Ja, die gibt es. - Doch, mit einem agressively optimzing compiler wie gcc mit O3), Dekompilierung, zum scheitern verurteilt ist - oder vielmehr: Es ergibt kaum mehr als disMontage.
    Oh, vereinbart. Es ist härter zu dekompilieren/disassemblieren und härter zu Chaos mit, Weise aber "härter" != "kann nicht".
    Vielen Dank für all die Hinweise und Empfehlungen, die Sie zur Verfügung gestellt.

    InformationsquelleAutor JimmyB

Schreibe einen Kommentar