mauidll

Estrae gli assembly gestiti (.NET) da un assembly store di MAUI Android.

Le app .NET Android distribuiscono il loro codice gestito all'interno di una libreria condivisa, solitamente libassemblies.<abi>.blob.so (versioni precedenti) o libassembly-store.so. mauidll analizza quel file e scrive ogni assembly che contiene su disco come un file .dll standard, pronto per l'ispezione in un decompilatore come ILSpy.

Lo strumento è un singolo programma Crystal autonomo senza dipendenze esterne. Il decompressore LZ4 di cui ha bisogno è implementato inline, quindi non serve nulla oltre alla libreria standard.

Avvio rapido

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

Il binario prodotto da crystal build è autonomo: richiede Crystal solo sulla macchina di compilazione, non su qualsiasi macchina dove lo si esegue.

Installazione

1. Installare Crystal

mauidll è compilato con il linguaggio Crystal. Se non hai ancora Crystal:

macOS

Il modo più diffuso è Homebrew:

brew install crystal

Crystal è disponibile anche come tarball universale ufficiale (Apple Silicon e Intel) dalla pagina dei download.

Linux

Su Debian, Ubuntu e distribuzioni correlate, installa il repository ufficiale dei pacchetti e poi il compilatore:

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

In alternativa, su qualsiasi distribuzione che supporta gli snap:

sudo snap install crystal --classic

Su Arch Linux:

sudo pacman -S crystal shards

2. Compilazione

crystal build --release mauidll.cr -o mauidll

mauidll è stato sviluppato e testato con Crystal 1.20.x. Usa solo la libreria standard, quindi qualsiasi versione ragionevolmente recente dovrebbe funzionare.

Utilizzo

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

Esempio:

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

Le righe di output riportano una riga per assembly (name: size -> decompressed size, valid PE), seguite da un riepilogo come:

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

Come funziona

1. Il file dello store è un oggetto ELF. L'assembly store risiede in una sezione payload non caricabile, che mauidll individua tramite gli header di sezione ELF (sono supportati sia ELF a 32 che a 64 bit).
2. Il payload inizia con un header XABA di 20 byte: magic, versione, numero di entry, numero di entry dell'indice e dimensione dell'indice.
3. Dopo l'indice vengono i descrittori, 28 byte ciascuno (indice di mappatura, offset dei dati, dimensione dei dati), poi una tabella di nomi (lunghezza uint32 little-endian + byte UTF-8 per ogni entry).
4. Ogni blob è o un assembly già compresso o uno non compresso. Un blob che inizia con XALZ è un blocco LZ4 raw (non il formato frame LZ4) preceduto da un header di 12 byte che include la dimensione non compressa; qualsiasi altra cosa (che inizia con MZ) è memorizzata verbatim.
5. I blob decompressi vengono scritti su disco con il loro nome di assembly e verificati per iniziare con la firma PE MZ.