mauidll

Extrahiert die verwalteten (.NET) Assemblies aus einem MAUI-Android-Assembly-Store.

.NET-Android-Apps liefern ihren verwalteten Code in einer Shared Library aus, üblicherweise libassemblies.<abi>.blob.so (ältere Versionen) oder libassembly-store.so. mauidll parst diese Datei und schreibt jede darin enthaltene Assembly als standardmäßige .dll-Datei auf die Festplatte, bereit zur Untersuchung in einem Decompiler wie ILSpy.

Das Tool ist ein einzelnes, in sich geschlossenes Crystal-Programm ohne externe Abhängigkeiten. Der benötigte LZ4-Decompressor ist inline implementiert, sodass nichts über die Standardbibliothek hinaus erforderlich ist.

Schnellstart

crystal build --release mauidll.cr -o mauidll
./mauidll libassembly-store.so extracted-dlls

Die von crystal build erzeugte Binärdatei ist in sich geschlossen: Sie benötigt Crystal nur auf dem Build-Rechner, nicht auf einem Rechner, auf dem Sie sie ausführen.

Installation

1. Crystal installieren

mauidll wird mit der Sprache Crystal kompiliert. Falls Sie Crystal noch nicht haben:

macOS

Der beliebteste Weg ist Homebrew:

brew install crystal

Crystal ist auch als offizielles universelles Tarball (Apple Silicon und Intel) von der Download-Seite verfügbar.

Linux

Installieren Sie auf Debian, Ubuntu und verwandten Distributionen das offizielle Paket- Repository und dann den Compiler:

curl -fsSL https://crystal-lang.org/install.sh | sudo bash
sudo apt install crystal

Alternativ, auf jeder Distribution, die Snaps unterstützt:

sudo snap install crystal --classic

Auf Arch Linux:

sudo pacman -S crystal shards

2. Build

crystal build --release mauidll.cr -o mauidll

mauidll wurde mit Crystal 1.20.x entwickelt und getestet. Es verwendet nur die Standard- bibliothek, sodass jede einigermaßen aktuelle Version funktionieren sollte.

Verwendung

./mauidll <assembly-store.so> [outdir]

Beispiel:

./mauidll /tmp/app64-v8a/libassembly-store.so /tmp/extracted

Die Ausgabezeilen melden eine Zeile pro Assembly (name: size -> decompressed size, valid PE), gefolgt von einer Zusammenfassung wie:

Extracted 235 entries, valid PE (MZ) after extraction: 235/235

Funktionsweise

1. Die Store-Datei ist ein ELF-Objekt. Der Assembly-Store befindet sich in einem nicht ladbaren payload-Abschnitt, den mauidll über die ELF-Abschnitts- header lokalisiert (sowohl 32- als auch 64-Bit-ELF werden unterstützt).
2. Die Payload beginnt mit einem 20-Byte-XABA-Header: Magic, Version, Anzahl der Einträge, Anzahl der Indexeinträge und Indexgröße.
3. Nach dem Index kommen die Deskriptoren, jeweils 28 Bytes (Mapping-Index, Daten- offset, Datengröße), dann eine Tabelle mit Namen (uint32 Little-Endian-Länge + UTF-8-Bytes pro Eintrag).
4. Jeder Blob ist entweder eine bereits komprimierte Assembly oder eine rohe. Ein Blob, der mit XALZ beginnt, ist ein roher LZ4-Block (nicht das LZ4-Frame-Format), dem ein 12-Byte-Header vorausgeht, der die unkomprimierte Größe enthält; alles andere (beginnend mit MZ) wird unverändert gespeichert.
5. Dekomprimierte Blobs werden unter ihrem Assembly-Namen auf die Festplatte geschrieben und darauf geprüft, ob sie mit der MZ-PE-Signatur beginnen.