Was wird benötigt, um aus Android-APKs kompilierte ELF-Binärdateien auszuführen? (Android-Interna verstehen)

Ich versuche zu verstehen, wie Android intern funktioniert. Vor ART wurde Dalvik verwendet, um Java-Code auszuführen. Ich denke, es hat einen Dalkiv-Prozess im 'Linux'-Kernel erstellt, der einfach eine VM war, die den Dex-Bytecode ausführte.

Für ART wird der Dex-Bytecode in Anweisungen in der Architektur des Prozessors kompiliert (passiert während des Installationsprozesses). Dieser kompilierte Dex-Bytecode wird in einer ELF-Binärdatei gespeichert. Es ist also etwas, das der 'Linux'-Kernel verstehen kann.

Angenommen, ich wollte diese ELF-Binärdatei unter Linux ausführen. Abgesehen von ashmemund binderKernel-Modulen, was würde ich noch brauchen? Welche Bibliotheken benötigt diese ELF-Binärdatei? Wird diese ELF-Binärdatei einfach als Linux-Prozess gestartet?

Ich habe versucht, den Quellcode von anbox.io zu lesen, aber ich konnte nicht verstehen, wie er eine ELF-Binärdatei von einer APK gestartet hat. Vielleicht verstehe ich den Quellcode von anbox.io besser, wenn ich verstehe, was zum Ausführen erforderlich ist.

Ich habe auch https://android.googlesource.com/platform/art/+/refs/heads/master/runtime/ gefunden , aber ich weiß nicht, wo ich anfangen soll. Was ist /runtime? Ist es ein Programm, eine Bibliothek? Ist Android Runtime etwas, das mit der aus Dex-Bytecode generierten ELF-Binärdatei verknüpft ist?

ELF-Binaries sind normalerweise völlig unabhängig von Dalvic, ART, .... Sie funktionieren einfach so, wie sie auf allen Linux-Systemen funktionieren. Sie erfordern möglicherweise einige dynamisch verknüpfte Bibliotheken. Abhängig von der Bibliothek sind sie bereits standardmäßig auf dem Gerät vorhanden oder Sie müssen sie entlang der ELF-Binärdatei platzieren. Apps können eine solche Binärdatei einfach ausführen. Sie können dies interaktiv mit einer Terminal-App wie Termux überprüfen.

Antworten (1)

Was wird benötigt, um aus Android-APKs kompilierte ELF-Binärdateien auszuführen?

Eine einfache Hello World-App , die nichts anderes tut, als Hello World! (keine Animationen, keine Sounds, keine Menüs), läuft auf einem Android 9-Gerät:

  • Öffnet 30+explizit Dateien, anonyme Inodes und UNIX-Sockets.
  • Gibt 500+speicherabgebildete Dateien von /data, /system, /vendorund frei /dev.
  • Kommuniziert zumindest mit Surface Flinger (über den Fenstermanager in system_server), um etwas auf dem Bildschirm anzuzeigen. Möglicherweise gibt es noch mehr IPCs (Binder oder andere).
  • Benötigt Aktivitäts-Manager, Paket-Manager und möglicherweise andere Dienste, die ausgeführt werden, in system_serverdenen die App-Klassen in Bezug auf die Aktivitätserstellung und -berechtigungen verwaltet werden.
  • Benötigt zygoteeinen Prozess, der ausgeführt wird, um VMs für system_serverund die App selbst zu forken.

Daher müssen alle diese Anforderungen erfüllt sein, um die ELF-Binärdatei (gemeinsames Objekt: /data/app/com.ravipatel.helloworld.test-*/oat/arm64/base.odex) auszuführen, die von APK kompiliert wurde.

Zum Vergleich: Ein mit GCJ kompiliertes Hello-World-Java-Programm verknüpft dynamisch mit weniger als 5 Bibliotheken. Während ein ähnliches C-Programm (statisch gelinkt) außer der erforderlichen Architektur keine Laufzeitabhängigkeiten hat.

Ich denke, es hat einen Dalkiv-Prozess im 'Linux'-Kernel erstellt, der einfach eine VM war, die den dexBytecode ausführte.

Nein. Dalvik war keine Kernel-basierte virtuelle Maschine ( KVM ; falls Sie das meinen). Sowohl Dalvik als auch ART sind Prozess-VMs , die im Userspace ausgeführt werden.

Für ART wird der Dex-Bytecode in Anweisungen in der Architektur des Prozessors kompiliert (passiert während des Installationsprozesses).

Es ist profilgeführt, passiert selten während des Installationsprozesses.

Was ist /runtime? Ist es ein Programm, eine Bibliothek?

Runtime ist eine Umgebung, in der Programme ausgeführt werden, die in einer bestimmten Sprache geschrieben sind. ART ist eine Laufzeitumgebung für Java. Es besteht hauptsächlich aus nativen ausführbaren Binärdateien / gemeinsam genutzten Bibliotheken (einschließlich VM / Interpreter / JIT-Compiler und OAT-Compiler) und standardmäßigen Java-Klassenbibliotheken (meistens in Form von Dateien .jar), die in /system.

Ein weiteres bekanntes Beispiel ist Java Runtime Environment ( JRE ) von Oracle/Sun, das hauptsächlich auf PCs zu finden ist.

Ist Android Runtime etwas, das mit der aus dexBytecode generierten ELF-Binärdatei verknüpft ist?

Richtig.

Wird diese ELF-Binärdatei einfach als Linux-Prozess gestartet?

Nein. Die aus einer Datei in APK kompilierte ELF-Binärdatei .dexist keine ausführbare Datei, sondern ein gemeinsames Objekt. Daher muss es zusammen mit anderen Abhängigkeiten von einem anderen Prozess, nämlich ART (VM), in den Speicher geladen werden.

Angenommen, ich wollte diese ELF-Binärdatei unter Linux ausführen. Abgesehen von ashmemund binderKernel-Modulen, was würde ich noch brauchen? Welche Bibliotheken benötigt diese ELF-Binärdatei?

Zunächst einmal können Sie die ELF-Binärdatei nicht auf einem Nicht-Android-Linux-System ausführen, da die Binärdatei keine statisch verknüpfte ausführbare Datei ist. Aber selbst wenn dies der Fall ist, gibt es noch größere Einschränkungen, insbesondere die Hardware-Abstraktion von Android. bindersund ashmemsind IPC-Mechanismen. Sie machen nur Sinn, wenn die Prozesse, mit denen die App kommunizieren möchte, auch existieren, was nicht der Fall ist. Mit Linux-basierten Java-SDKs ist dies relativ einfach zu erreichen.

VERWANDT:

Was wird benötigt, um aus Android-APKs kompilierte ELF-Binärdateien auszuführen? (Android-Interna verstehen)
AntwortenHierDatenschutz-Bestimmungen1y, 0v