Come decomprimere e modificare boot.img per il porting della ROM?


14

Di recente ho scaricato questa ROM per il mio Allview P5 (Allview P5 è l'equivalente di Gionee GN700W / FLY IQ441 / QMobile Noir A8). Si chiama Primonex ROM ed è realizzato per la versione Gionee del telefono.

  • In primo luogo, ho provato a installarlo così com'è ma si è bloccato nella schermata di avvio.
  • Dopo alcune ricerche ho scoperto che potrebbe essere un problema con il boot.imgfile e non so come estrarlo o modificarlo ...

Qualcuno può dirmi come si fa?

Risposte:


12

Selezione degli strumenti

Il metodo che presento qui si basa sul codice sorgente Android di CyanogenMod.

Mentre AOSP di Google fornisce solo lo strumento per creare il boot.imgfile, CyanogenMod aggiunge anche lo unpackbootimgstrumento che consente di decomprimerlo . Questo strumento non sembra progettato specificatamente per CyanogenMod in alcun modo, quindi la maggior parte delle probabilità è che funzioni anche con altre ROM.

Esistono, tuttavia, un numero relativamente elevato di alternative per decomprimere il boot.imgfile che funzionano tutte più o meno allo stesso modo.

Fondamentalmente, tale strumento di decompressione estrarrà il contenuto del boot.imgfile e visualizzerà una serie di parametri che dovrete passare allo mkbootimgstrumento di Google per creare un file la cui configurazione (principalmente parametri del kernel e indirizzi di memoria) corrisponderà a quella originale.

Ecco alcuni esempi, non li ho testati personalmente, quindi non posso consigliarne nessuno e li presento solo a scopo di riferimento:

  • Alcuni sono open source o basati su script:

    • Apparentemente Android Kitchen doveva essere una specie di coltellino svizzero per sviluppatori Android. L'autore originale ha ufficialmente smesso di mantenere il progetto, pochi altri utenti lo hanno modificato come javilonas o cmotc .
    • szym punta alla semplicità aggiungendo wrapper di shell script al suo set di strumenti per rendere più semplice il processo completo di disimballaggio e reimballaggio.
    • osm0sis propone un fork di strumenti di CyanogenMod "biforcati e aggiornati" secondo la descrizione del progetto. Questo progetto sembra davvero ancora mantenuto, il che non è molto comune in questo settore, tuttavia il vantaggio reale rispetto agli strumenti originali di CyanogenMod non mi è chiaro.
  • Alcuni sono binari proprietari gratuiti a sorgente chiuso:

    • Quella di Kuismaunmkbootimg appare abbastanza spesso nei forum di aiuto e sembra fare un buon lavoro nell'aiutare a gestire casi strani, pubblicando raccomandazioni inglesi "leggibili dall'uomo" quando sono necessarie alcune modifiche nel mkbootimgcodice sorgente e mostrando la riga di comando esatta da usare per ricostruire l'immagine.
    • Anche Xiaolumkbootimg_tools sembra menzionato abbastanza spesso e consente di decomprimere e reimballare boot.imge il file dell'albero del dispositivo dt.img. Non lasciarti ingannare dal fatto che è ospitato su GitHub: è un binario proprietario di origine chiusa e solo i binari compilati sono disponibili sul loro repository (in realtà mi sto anche chiedendo l'esatto interesse di utilizzare un repository di codice sorgente per archiviare BLOB binari, ma persone diverse, menti diverse ...).
    • CNexus sul forum XDA fornisce un archivio con una selezione di strumenti.
    • Questa risposta in Unix.SE raccomanda alcuni strumenti del progetto Android Serial Port ora apparentemente defunto. I nomi dei file, tuttavia, mi portano a pensare che queste dovrebbero essere vecchie versioni precompilate degli strumenti di CyanogenMod (il progetto è chiuso, non c'è documentazione né supporto).

Tutti questi strumenti (e altri che potresti trovare con qualsiasi motore di ricerca) dovrebbero funzionare allo stesso modo, ma alcuni potrebbero funzionare meglio di altri nella gestione di alcuni casi particolari che potresti incontrare con il tuo dispositivo. La maggior parte di essi, tuttavia, almeno nell'arena open source, non sembra essere mantenuta regolarmente, quindi la migliore scommessa secondo me per avere strumenti funzionanti, mantenuti e documentati è quella di andare con quelli di CyanogenMod.

Alcuni produttori producono ROM più o meno lontane dallo standard AOSP (indirizzi insoliti, intestazioni, formato file, ecc.). Se la procedura standard di seguito non funziona, forse uno di questi software alternativi potrebbe fare il trucco. Altrimenti, dovrai verificare la presenza di problemi specifici per il tuo dispositivo: alcuni sembrano aver bisogno di una procedura specifica o persino di strumenti specifici (conferisci questa domanda relativa ai dispositivi MediaTek, ad esempio).

Installazione degli strumenti

La compilazione del set di strumenti CyanogenMod per l' boot.imgimballaggio e il disimballaggio è abbastanza semplice.

  • Se hai già installato l'albero completo del codice sorgente Android (puoi controllare la mia altra risposta per ottenere maggiori informazioni a riguardo), vai nella system/core/mkbootimg/directory (come promemoria, il codice sorgente AOSP di Google fornisce solo lo strumento per creare il boot.imgfile, non fornire qualsiasi strumento di disimballaggio),
  • Se non hai e non hai bisogno di questo per nessun altro scopo, una soluzione più semplice e veloce è quella di clonare solo il repository android_system_core di CyanogenMod :

    git clone https://github.com/CyanogenMod/android_system_core.git
    cd android_system_core/mkbootimg/
    

Una volta nella directory giusta, compila e installa:

gcc -o ./mkbootimg -I ../include ../libmincrypt/*.c ./mkbootimg.c
gcc -o ./unpackbootimg -I ../include ../libmincrypt/*.c ./unpackbootimg.c
sudo cp ./mkbootimg ./unpackbootimg /usr/bin/

Nota che Google sta sostituendo la C mkbootimgcon una versione di Python , quindi nelle versioni future non sarà più necessaria alcuna compilazione per questo comando.

Sarà inoltre necessario installare strumenti Android sul computer per consentire la comunicazione con il telefono. Avrai bisogno di adb(Android Debug Bridge, un'utilità di shell che consente di comunicare con il sottosistema di debug di Android), adbd(il demone correlato) e fastboot(un'utilità di shell che consente di comunicare con il sistema di bootloader del telefono).

La tua distribuzione Linux preferita può fornirli in pacchetti singoli o separati, ma di solito sono sempre chiamati "android-tools":

  • Debian / Ubuntu: sudo apt-get install android-tools-{adb,adbd,fastboot}
  • Fedora / CentOS: sudo yum install android-tools
  • openSUSE: sudo zypper install android-tools

Recupera il boot.imgfile

Estrarre il file boot.img dal file .zip della ROM o direttamente dal dispositivo:

  • Dal file .zip della ROM di serie: alcune applicazioni come SuperSU possono modificare il file boot.img direttamente sul dispositivo, sostituendolo con quello di serie si rompono tali applicazioni.
  • Direttamente dal dispositivo: alcune persone segnalano problemi di lettura che portano a danneggiati boot.img. IMO, questi problemi sono molto probabilmente legati all'uso di cavi USB o hub USB scadenti e possono essere semplicemente evitati utilizzando cavi di buona qualità che collegano direttamente il telefono al computer. È inoltre necessario eseguire ADB in modalità root (a seconda della ROM utilizzata, potrebbe essere banale o meno).

Il primo metodo è molto ovvio: estrarre il file .zip con qualsiasi software ZIP, il boot.imgfile dovrebbe essere proprio lì alla radice dell'archivio.

Per il secondo metodo, dovrai prima determinare il percorso (purtroppo specifico del dispositivo) verso il dispositivo di archiviazione in cui boot.imgè possibile recuperare il contenuto. Conosco due metodi per questo:

  • ls /dev/block/platform/*/by-name/(dove *le coperture ancora un altro nome della cartella specifica del dispositivo, è probabile che sia l'unica directory sotto platform/), il nome esatto di ricerca è anche dipendente dalla piattaforma, ma rende senso comune (alcuni esempi: boot, LNX(acronimo di "Linux")). I file in questa directory sono in realtà collegamenti simbolici e alcune persone si preoccupano di andare manualmente alla destinazione, ma consiglio di attenersi al percorso basato sul nome di livello superiore che, sebbene più lungo, rimane meno soggetto a errori. Quindi finirai con un percorso simile /dev/block/platform/sdhci-tegra.3/by-name/LNX.
  • Su alcuni dispositivi (più vecchi?), È possibile trovare il dispositivo giusto esaminando l'output di cat /proc/mtd. Se vedi il dispositivo mtd2associato "boot"all'etichetta, utilizzerai il percorso /dev/mtd2.

Adesso:

  • Dal menu sviluppatore del telefono:
    • Abilita il debug sul telefono,
    • Consenti accesso root ad ADB (questo passaggio si applica ai telefoni che eseguono CynogenMod, altri dispositivi potrebbero richiedere procedure potenzialmente più complesse),
  • Collegalo al tuo computer (e da lì al guest VM se stai eseguendo strumenti Android da una macchina virtuale).

Se ciò non è già stato fatto, ti consiglio di avviare manualmente il server ADB sul lato del computer, questo ti permetterà di validare direttamente la chiave RSA sul lato del dispositivo senza influenzare il comportamento dei seguenti comandi ADB:

adb start-server

Quindi cambia ADB in modalità root:

adb root

Infine, dovresti essere in grado di estrarre direttamente il boot.imgfile dal dispositivo utilizzando tale comando (il percorso e i nomi di origine e destinazione sono indicati come esempi, adattali alle tue esigenze e preferenze):

adb pull /dev/block/platform/sdhci-tegra.3/by-name/LNX ./boot.img

Il comando copierà l'intera partizione, sia quella utilizzata che quella libera, quindi non sorprenderti se il boot.imgfile risultante sarà più grande del boot.imgfile originale fornito con il file .zip della ROM di scorta, il contenuto stesso rimarrà simile.

Una volta terminato il trasferimento, scollegare il telefono e non dimenticare di disabilitare sia il debug sia l'accesso root dal menu dello sviluppatore.

Decomprimi il boot.imgfile originale

Decomprimere il boot.imgfile stesso utilizzando il comando compilato in precedenza:

unpackbootimg -i ./boot.img

Questo produrrà diverse informazioni essenziali per permetterti di ricostruire un nuovo boot.imgcon la struttura corretta rispetto allo stock boot.img. Tuttavia, non affrettarti sul tuo blocco note poiché CyanogenMod's upackbootimgsalva anche le stesse informazioni in diversi file che useremo in seguito.

Questo comando genera diversi file con suffissi particolari aggiunti al nome del file di input:

  • *-second: Si tratta del bootloader di secondo livello, opzionale e raramente utilizzato sui telefoni degli utenti finali. Se questo file è vuoto (il caso più comune), il bootloader del telefono chiamerà direttamente il kernel Linux.
  • *-zImage: Questo è il kernel Linux.
  • *-ramdisk.gzoppure *-ramdisk.lz4: il disco RAM utilizzato per popolare la directory principale del dispositivo. L'estensione varia in base all'algoritmo di compressione utilizzato.
  • *-dt: L'albero dei dispositivi, popolato /dev.
  • Il resto sono piccoli file che contengono ciascuno dei valori visualizzati in unpackbootimgoutput. Questi valori definiscono il parametro della riga di comando da passare al kernel Linux e gli indirizzi in cui il bootloader dovrà caricare ciascun oggetto all'avvio.

Molto spesso, si decomprime il file boot.imgper essere in grado di modificare il contenuto della directory principale del telefono. Come visto sopra, questo contenuto è archiviato nel file *-ramdisk.gzo *-ramdisk.lz4e può essere estratto usando i comandi seguenti:

mkdir ./ramdisk
cd ./ramdisk/
gzip -dc ../boot.img-ramdisk.gz | cpio -imd

Per un disco RAM compresso LZ4, sostituire l'ultimo passaggio con lz4 -d ../boot.img-ramdisk.lz4 | cpio -imd.

Ora sei libero di fare la modifica che desideri prima di procedere. Tuttavia, potrebbe valere la pena seguire una volta la procedura completa di decompressione - reimballaggio - avvio senza modificare nulla per garantire che gli strumenti funzionino come previsto. Altrimenti, in caso di problemi, non sarai certo se la causa sia la tua modifica o una certa incompatibilità (vedi le mie osservazioni all'inizio su alcuni produttori che richiedono procedure o strumenti non standard).

Ricostruisci per ottenere il nuovo new-boot.imgfile

Il processo di creazione della ROM CyanogenMod si basa su uno strumento interno mkbootfs, per produrre il boot.imgfile (ciò accade in build / tools / releasetools / common.py ). Tuttavia, i passaggi per creare questo strumento mi sembrano inutilmente complessi, mentre l'utilizzo del sistema fornito cpiosembra funzionare altrettanto bene. La differenza principale tra i due, secondo la mia comprensione dopo un (molto) rapido controllo nel mkbootfscodice Souce, sembra che quest'ultimo applichi alcune misure di integrità non includendo i file punteggiati e la /rootdirectory nell'archivio risultante mentre la cpioprocedura basata di seguito inserirà ciecamente l'intero albero di directory selezionato nell'archivio.

Conclusione: compilazione inutilmente complessa con pochissimi vantaggi, quindi atteniamoci agli strumenti forniti dal sistema!

Inizia creando il nuovo disco RAM, dalla ramdiskdirectory creata sopra, digita:

find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz

Oppure, se è necessario generare un archivio LZ4:

find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | lz4 > ../new-boot.img-ramdisk.lz4

L'obiettivo qui è quello di creare un nuovo file del disco RAM con proprietà il più vicino possibile a quello originale (ad esempio, l'impostazione del proprietario sembra spesso mancare nelle procedure condivise nei forum e nei blog, tuttavia questo era richiesto sul mio dispositivo).

Vai ora nella directory principale per generare il new-boot.imgfile stesso.

cd ..

Come visto sopra, il unpackbootimgcomando di CyanogenMod genera un file corrispondente a ciascun parametro previsto da mkbootimg. Pertanto, è sufficiente emettere un mkbootimg -hper ottenere un elenco di tutti i parametri, quindi impostare ognuno di essi sul valore appropriato utilizzando il file corrispondente. Si noti che alcuni parametri prevedono un percorso di file mentre altri prevedono di ricevere il contenuto del file come valore. Vedi un esempio del comando risultante di seguito:

mkbootimg --kernel ./boot.img-zImage \
--ramdisk ./new-boot.img-ramdisk.gz \
--second ./boot.img-second \
--cmdline "$(cat ./boot.img-cmdline)" \
--base "$(cat ./boot.img-base)" \
--pagesize "$(cat ./boot.img-pagesize)" \
--dt ./boot.img-dt \
--ramdisk_offset "$(cat ./boot.img-ramdisk_offset)"
--second_offset "$(cat ./boot.img-second_offset)" \
--tags_offset "$(cat ./boot.img-tags_offset)" \
--output ./new-boot.img

Qui non sono impostati solo due parametri:

  • --board: Secondo la mia comprensione, questo è solo un campo informativo che consente di inserire un nome di modello nell'immagine risultante.
  • --id: Questo non prevede alcun valore, stampa solo un identificatore univoco dopo che l'immagine è stata creata (combinando un timestamp e un checksum).

Flash il new-boot.imgfile sul dispositivo

  • Avvia il dispositivo in modalità avvio rapido (ovvero modalità bootloader, in genere tenendo premuti i pulsanti di accensione e volume).
  • Collegare il cavo USB
  • Verificare che il dispositivo sia stato rilevato correttamente:

    sudo fastboot devices
    
  • Prova ad avviare utilizzando la nuova ROM (senza ancora eseguirne il flashing, quindi in caso di problemi devi solo riavviare il telefono per ripristinarlo, sostituisci il ./new-boot.imgnome del file con il tuo):

    sudo fastboot boot ./new-boot.img
    
  • Se il telefono funziona correttamente con la nuova immagine di avvio, torna in modalità di avvio rapido e flash in modo permanente:

    sudo fastboot flash boot ./new-boot.img
    sudo fastboot reboot
    

Conclusione

All'inizio questa procedura può sembrare scoraggiante, ma una volta che lo capirai, vedrai che in realtà non lo è.

L'aspetto "scoraggiante" deriva dal fatto che non esiste un unico "sistema Android": molti produttori e fornitori di ROM apportano modifiche che possono variare da una sottile differenza di percorso a un ambiente completamente non standard.

Quello che devi fare è determinare la postura del tuo dispositivo particolare, e quindi quali sono i pochi comandi appropriati nel tuo caso. Una volta ottenuti, puoi attenerti a loro e persino copiarli facilmente se ne hai bisogno spesso.

Sono entrato volontariamente in dettagli di livello relativamente basso a volte perché ti consentirà di risolvere i problemi più facilmente. Utilizzeresti un'utilità opaca "più semplice" per creare e eseguire il flashing del tuo nuovo boot.imgfile e vedere che il tuo dispositivo non può iniziare con esso, sarebbe più difficile per te determinare quale passo è andato storto. Qui, ad ogni passaggio, sarai in grado di confrontare i dati che stai manipolando con i dati provenienti dal boot.imgfile originale o i dati visti sul telefono, o provare ad esempio a ricostruire il boot.imgfile con l'originale o il nuovo generato File del disco RAM per verificare se ciò fa alcuna differenza (ciò consente di individuare se il problema deriva dalla boot.imgprocedura di generazione del file del disco RAM o).


2

Usa Android Kitchen. C'è un'opzione per decomprimere / reimballare boot.img lì, sotto Advanced options.


Purtroppo l'autore originale si è ufficialmente fermato per mantenere Android Kitchen: " Questo progetto è stato ritirato a partire dal 2013, poiché sono stato sopraffatto dal numero di dispositivi da supportare, dalla domanda, dalla cattiva salute e dalle continue richieste di aiuto ". Sono state create alcune forcelle (fornisco alcuni collegamenti nella mia risposta), ma non so quanto siano supportate (non ho trovato alcun modo pubblico ovvio per sollevare problemi o richiedere un'evoluzione, ad esempio).
WhiteWinterWolf
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.