English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
Principio di pacchettizzazione multi-canale con vecchia firma
Premessa
Poiché Android 7.0 ha introdotto un nuovo meccanismo di firma, ha rafforzato la加固 della firma, rendendo impossibile continuare a generare pacchetti multi-canale nel nuovo meccanismo di firma. Tuttavia, prima di parlare dell'impatto del nuovo meccanismo di firma sul piano di pacchettizzazione
Prima di influenzare e capire perché influisce sulla nostra meccanica di pacchettizzazione originale, è necessario comprendere semplicemente il principio di pacchettizzazione e il ruolo della firma nel processo di pacchettizzazione.
Flusso di pacchettizzazione di Android
Il processo di pacchettizzazione di Android è illustrato approssimativamente come nella figura, l'intero flusso è integrare il codice Java, i file di risorse e le librerie di terze parti in un file Apk, e ottimizzare e allineare i file integrati. L'intero processo può essere riassunto
La procedura di singolo è divisa in i seguenti passaggi:
I passaggi di generazione dell'APK sono più o meno così, non dobbiamo preoccuparci di dettagli di implementazione, ma capire questi flussi ci aiuta a comprendere il principio del nostro piano di packaging. Certo, così sembra che l'APK
È un file fantastico, che può essere installato e eseguito. In realtà, l'APK è solo un tipo di file .zip speciale, che può essere riconosciuto e installato come un'applicazione sul nostro dispositivo Android. Possiamo decomprimere il file APK per vedere il suo contenuto.
Si può vedere che il contenuto del file è基本上与我们前面说的基本一致，poi vediamo il folder più importante, che è il file nella figura del capitolo tre, questi file sono tutti nel folder META-INF, questo è il file che abbiamo aggiunto durante il processo di firma come identificatore unico dell'APK. Quindi, cosa significa questo per l'ottimizzazione del packaging? Ecco un mistero, lo spiegheremo dopo. Prima di capire questo, dobbiamo chiarire il fatto della firma.
Il ruolo e il principio della firma
Il ruolo della firma
L'App Android durante la fase di sviluppo ha un identificatore univoco, che chiamiamo nome del pacchetto, ad esempio il nome del pacchetto del grande client è com.Quanr. Il nome del pacchetto è come il numero di identificazione personale, che è corrispondente a ciascuna persona. Quando si installa l'App, il dispositivo riconosce l'applicazione tramite il nome del pacchetto. Non possono esistere due applicazioni con lo stesso nome del pacchetto su un singolo dispositivo, questo è l'unicità dell'App sul dispositivo. Quando aggiorniamo l'App, ad esempio con l'installazione di copertura, identifichiamo e copiamo tramite il nome del pacchetto, in modo da garantire che l'App possa essere aggiornata senza coprire altre App. Allo stesso modo, altre App con nome del pacchetto diverso non possono coprire la nostra App. Anche se Android fornisce un meccanismo di riconoscimento del nome del pacchetto, può bastare solo con il nome del pacchetto. Immaginiamo, se qualcun altro crea un'App con il nostro nome del pacchetto per coprire la nostra App o se i criminali cercano di decifrare la nostra
Gli App aggiungono contenuti propri all'interno, come annunci integrati per guadagnare denaro, rilasciano l'App modificato per coprire l'installazione dell'utente, potremmo subire enormi perdite. Naturalmente, questo tipo di cosa non accadrà mai. Google ha aggiunto un meccanismo di firma per ogni App, proprio come quando andiamo in banca a fare un'operazione, non solo dobbiamo fornire la nostra carta d'identità, ma anche firmare e lasciare impronte digitali. Il numero della carta d'identità può essere visto da tutti, ma la firma e le impronte digitali possono essere fatte solo da noi, nessun altro può imitarle. Gli App garantiscono l'unicità e la sicurezza di sé stessi proprio attraverso questo meccanismo.
Allora, come fa la firma a fare tutto questo?
Principio della firma
Ci sono diversi strumenti per la firma APK, ma i principi sono tutti molto simili. Prendiamo signapk come esempio. La firma dell'APK può essere completata utilizzando questo strumento con alcuni parametri e il nostro file di firma unico. Firmare direttamente con lo strumento è molto semplice, ma ciò che dobbiamo prestare maggiore attenzione è il suo principio e come viene implementato, in modo da aiutarci a trovare i segreti di pacchetti di canale. Prima di utilizzare lo strumento di firma, dobbiamo preparare la chiave privata e la chiave pubblica necessarie per la firma (a–(chiave privata)–>b–(chiave pubblica)–>a, meglio usare immagini per illustrare), quindi utilizzare lo strumento di firma per firmare l'APK. Dopo di che, il processo di firma creerà una nuova cartella META-INF nell'APK e genererà tre file al suo interno. Questi tre file sono la chiave e la base di verifica della firma.
Dalla figura si può vedere che i tre file sono:
Parliamo ora di come vengono generati questi tre file.
MANIFEST.MF
Guardiamo prima il suo contenuto, vediamo che sono valori SHA1 corrispondenti a Name, è facile capire che questo file contiene un valore unico per ogni file. La funzione del file MANIFEST.MF è proprio come è stato detto prima, durante la firma APK, prima di firmare ogni file, viene effettuata una codifica digitale, generando un valore SHA1 unico. Poiché i contenuti dei file diversi sono diversi, i valori SHA1 corrispondenti sono anche diversi. Pertanto, se qualcuno altera i contenuti del file, il valore SHA1 corrispondente cambierà anche. Durante la firma dell'APK, controlla ogni file e genera il valore SHA1 corrispondente, salva questi contenuti in un nuovo file MANIFEST.MF e mettili nella directory META-INF, completando la generazione del primo file di firma.
CERT.SF
Dopo aver generato il file MANIFEST.MF, possiamo registrare l'unicità di ciascun file, garantendo così che i file non vengano alterati. Anche se questo garantisce la sicurezza dei file registrati nel MANIFEST, non garantisce la sicurezza del MANIFEST stesso. Altri possono modificare i file esistenti, generare il valore SHA1 corrispondente e poi modificare il file MANIFEST. Pertanto, dobbiamo rafforzare il MANIFEST per garantire la sicurezza. Dopo aver generato il primo file, lo strumento di firma inizia a generare il secondo file, che è il CERT.RSA. In questo passaggio, viene eseguita una nuova codifica numerica sul file generato nel passaggio precedente e il risultato viene salvato nell'intestazione del nuovo file CERT.RSA. Inoltre, viene eseguita una nuova codifica numerica sui vari blocchi di attributi del file MANIFEST.MF e salvati in un blocco di attributi del file CERT.SF.
CERT.RSA
Questi file sono binari. Dopo aver generato il file CERT.SF, utilizziamo la chiave privata per calcolare la firma crittografica e salviamo la firma ottenuta insieme alle informazioni del certificato pubblico nel file CERT.RSA. Il processo di firma è terminato.
Di seguito, descriviamo brevemente i passaggi di verifica nel processo di installazione dell'APK, che è simile ai passaggi per la generazione dei file di firma:
Dal processo sopra menzionato, è chiaro che durante questo processo non è mai stata effettuata una codifica numerica e crittografia su alcun file di META-INF, poiché questa cartella viene generata durante la firma. Quando viene generato il primo file MANIFEST.MF, non è stata effettuata alcuna codifica numerica sui file presenti nella cartella, poiché questa cartella deve essere vuota. Il secondo file è generato basato sul primo, e il terzo file è generato basato sul secondo. Pertanto, durante tutto il processo, la cartella META-INF è quasi fuori dal controllo. Possiamo aggiungere alcuni file per evitare il processo di firma. Questo è il punto di breakthrough del piano di pacchetti multi-canale di Meituan.
Meituan completa il pacchettizzazione multi-canale utilizzando il principio della firma
Conoscendo il processo di pacchettizzazione in precedenza, possiamo sapere che per stampare rapidamente pacchetti di canali, dobbiamo saltare la fase di pacchettizzazione e cercare direttamente di modificare il file Apk, ma questo sfida le regole di verifica della firma di Android, tuttavia, esattamente, attraverso l'analisi del processo di firma che abbiamo fatto prima, abbiamo scoperto che possiamo aggiungere file a piacimento nella cartella META-INF per evitare il controllo delle regole di firma, e in questo modo il nuovo piano è nato. Dopo aver pacchettizzato un file Apk senza canale, copiamo questo Apk e aggiungiamo un file nella cartella META-INF, quindi determiniamo il numero di canale tramite il nome del file. In diversi file Apk, aggiungiamo diversi file di nome canale nella cartella META-INF per determinare diversi canali. Dopo di che, tutto ciò che dobbiamo fare è prendere direttamente questo file quando serve il parametro del canale, superando perfettamente questo processo di pacchettizzazione. Quindi, il tempo di questo piano è solo copiare e inserire un file basato su un file Apk, questo tipo di azione può essere fatto 900 volte al minuto su un computer di alta configurazione. Quindi, è necessario 4 minuti per stampare un pacchetto di canale, e per stampare 100 pacchetti di canale è necessario solo 4 minuti e un piccolo numero, naturalmente, questo non è il limite, se ci sono 900 canali, il tempo necessario per pacchettizzare ogni canale è 900x4 minuti, il piano di Meituan solo 5 minuti, migliorando la produttività di centinaia di volte, possiamo dire che il piano di Meituan sotto la firma vecchia è molto perfetto.
Impatto del nuovo metodo di firma sulle soluzioni esistenti
Dopo Android 7.0, Google ha adottato nuove regole di verifica della firma per migliorare la sicurezza della firma, non più per ogni file per il codice numerico, come illustrato nella figura:
Il nuovo metodo di firma è basato sulla struttura del file zip per la firma, il file Apk in realtà è un file .zip, come illustrato nella figura, può essere diviso in tre parti prima della firma.
Nella figura sottostante, la parte blu rappresenta il contenuto delle voci ZIP, la parte rosa rappresenta il Directory Centrale.
File Entry rappresenta un'entità di file, un file compresso contiene più entità di file.
L'entità di file è composta da un'header e i dati del file (comprimetti, l'algoritmo di compressione è spiegato nell'header)
Il Central Directory è composto da più File header, ciascuno dei quali保存 una posizione di offset di un'entità di file
Il file termina con una struttura chiamata End of central directory.
Guardiamo ancora l'azione di End of Central Directory, che registra la posizione di offset del Central Directory rispetto all'inizio, guardiamo anche i nostri nuovi dati di firma Apk Signing Block, che sono messi tra i Contents of ZIP entries e il Central Directory, è un dato unico generato dopo aver codificato e firmato i tre moduli di tutti i contenuti del file ZIP non firmato, può essere compreso come il numero di codifica menzionato prima, qualsiasi contenuto di questi tre cambiamenti dopo produrrà questo dato non è lo stesso, quindi non è possibile modificare alcun contenuto di Apk dopo la firma, ma non abbiamo mai modificato il contenuto al di fuori della firma Apk prima, quindi a questo punto non possiamo considerare di modificare il contenuto di Apk Signing Block, aggiungeremo un piccolo coda alla fine. Evidentemente questo metodo non funziona, come ho detto prima, c'è una parte chiamata End of Central Direcotry, che registra l'offset del Central Directory rispetto all'inizio del file ZIP, esattamente davanti all'APK Signing Block, se si cambia la lunghezza dell'APK Signing Block, l'offset del Central Directory rispetto all'inizio cambia, il contenuto diventa diverso da quello registrato nell'End of Central Directory, l'intero pacchetto Apk viene danneggiato. Allora è possibile modificare questo offset? Evidentemente no, dopo aver modificato questo offset, l'APK Signing Block cambia, quindi solo i sviluppatori che possiedono il file di firma possono ottenere i dati corretti dell'APK Signing Block, quelli che cercano di manipolare questo possono solo guardare in alto e sospirare. Questo è il principio di funzionamento del nuovo meccanismo di firma. Sotto questo nuovo meccanismo, la nostra firma vecchia potrebbe dover essere modificata in modo appropriato.
Pensiero sulla soluzione migliorata
Come ho già spiegato, la nostra nuova soluzione di pacchettizzazione è di nuovo a corto di risorse sotto il nuovo meccanismo di firma (ovviamente, se continui a utilizzare la firma vecchia, non devi preoccuparti di questo problema), ma Google ha un piano, e noi abbiamo una scala per superare le mura~
Ho già detto prima che ci sono diversi modi per aggiungere pacchetti di canale:
Abbiamo analizzato in precedenza che se si modifica qualsiasi modulo del contenuto del file zip, il blocco di firma APK cambierà, rendendo impossibile bypassare il meccanismo di firma.
Tuttavia, questo non è un problema, il meccanismo di firma è solo per garantire la sicurezza del nostro Apk, ovviamente non vogliamo alterare malevolmente l'App, siamo sviluppatori, che detengono la chiave privata e pubblica del file di firma, poiché il meccanismo di firma non può essere bypassato, possiamo direttamente modificare il pacchetto Apk e firmarlo di nuovo. Anche se l'efficienza non è altrettanto alta quanto bypassare il meccanismo di firma, rispetto al processo di confezionamento che richiede diversi minuti, questo tempo è accettabile. Generalmente, la nuova firma richiede circa tre secondi, rispetto al nostro processo di confezionamento di quattro minuti, è ancora accettabile e può essere utilizzato.
Certo, questo è solo un piano pensato basato sul nostro meccanismo di firma, prima abbiamo analizzato l'intero processo e meccanismo di confezionamento e firma, forse ci sono modi migliori per estrarre da essi, questo richiede la nostra creatività collettiva, analizzare attentamente questi processi e principi, forse puoi trovare una soluzione migliore per continuare a ottimizzare il nostro piano di confezionamento~
Sommario
Questo è tutto il contenuto riguardante l'impatto del nuovo firma Android7.0 sulla confezione multi-canalizzata, spero che il contenuto di questo articolo possa aiutare i sviluppatori Android, se hai domande puoi lasciare un messaggio per discutere.
Dichiarazione: il contenuto di questo articolo è stato tratto da Internet, il copyright è di proprietà del rispettivo proprietario, il contenuto è stato contribuito autonomamente dagli utenti di Internet e caricato autonomamente, il sito web non detiene il diritto di proprietà, non è stato editato manualmente e non assume alcuna responsabilità legale correlata. Se trovi contenuti sospetti di violazione del copyright, ti preghiamo di inviare una e-mail a notice#oldtoolbag.com (sostituisci # con @) per segnalare, fornendo prove pertinenti. Una volta verificata, il sito eliminerà immediatamente il contenuto sospetto di violazione del copyright.