Du kan enkelt deaktivere signaturverifisering av Android-applikasjoner (APK) ved å bruke Xposed Framework, men du bør ikke gjøre dette i de aller fleste tilfeller.
Hvis du noen gang har prøvd å endre og installere et systemprogram på nytt, har du sannsynligvis møtt programsignaturkontroller i en eller annen form. Enten fjernet du den originale appen før du fortsatte, eller så ga du den modifiserte APK-en din et annet pakkenavn for å få den til å installere uten først å fjerne den gamle applikasjonen. Og i begge tilfeller måtte du også signere applikasjonen på nytt selv for å få den til å installere i utgangspunktet.
Du kan omgå all denne atferden ved å midlertidig deaktivere applikasjonssignaturkontroller. Men før vi går inn på det metaforiske kjøttet og potetene i denne artikkelen og forteller deg hvordan du gjør det, det er viktig at vi snakker litt om applikasjonssignatursjekker, hva de gjør og hvorfor du bør aldri fjerne dem i de aller fleste tilfeller.
Grunnleggende om Android-signaturverifisering
Som standard krever Android OS alle applikasjoner som skal signeres for å bli installert. I helt grunnleggende termer betyr dette at applikasjonssignaturen brukes til å identifisere forfatteren av en applikasjon (dvs. verifisere legitimiteten), samt etablere tillitsforhold mellom applikasjoner med samme signatur. Med førstnevnte er du sikret (i rimelig grad) at en applikasjon med gyldig signatur kommer fra de forventede utviklerne. Og gjennom sistnevnte kan applikasjoner signert med samme private nøkkel kjøre i samme prosess og dele private data. Når du deretter installerer en applikasjonsoppdatering, sjekker Android OS denne signaturen for å sikre at: A) APK-en ikke har blitt tuklet i tiden siden det ble signert, og B) programmets sertifikat samsvarer med det for øyeblikket installerte versjon.
Så hvordan påvirker alt dette meg i den virkelige verden? Det er enkelt, egentlig. Hvis du skaffer en APK fra utenfor Google Play-butikken og prøver å installere den som en oppdatering til den installerte appen din (les: samme pakkenavn), vil operativsystemet forsøke å validere programmets sertifikat for å sikre at det kom fra samme initial utviklere. Hvis sertifikatet samsvarer, vil applikasjonsinstallasjonen fortsette som planlagt, applikasjonen din vil beholde sine eksisterende data, og alt er saus. Hvis signaturen ikke er gyldig (som indikerer at APK-en har blitt tuklet) eller hvis sertifikatet ikke samsvarer med den originale appen, vil installasjonen mislykkes. Og som nevnt tidligere, vil applikasjonssertifikatet bare samsvare hvis det er signert med den samme private nøkkelen som ble brukt til å signere den forrige versjonen. Med andre ord, du kan bare installere en applikasjon hvis den har en gyldig signatur som samsvarer med APK-ene innhold, og du kan bare installere en oppdatering hvis sertifikatet også samsvarer med det som ble funnet i den tidligere versjonen av appen.
[Som en humoristisk side i denne ellers tette artikkelen, er det ett veldig offentlig eksempel der en privat applikasjonssigneringsnøkkel ble tapt eller kompromittert. Jeg sikter selvfølgelig til Googles egen Authenticator-app, som fikk en oppdatering som endret pakkenavnet fra com.google.android.apps.autenticator til com.google.android.apps.authenticator2 i en oppdatering for omtrent to år siden. På grunn av denne endringen kunne alle påfølgende Authenticator-appoppdateringer bare utstedes under det nye pakkenavnet – med den nye signaturen generert av den nye private signeringsnøkkelen.]
Hvorfor du kanskje ønsker å (midlertidig) deaktivere signaturverifisering
La oss nå ta en titt på et potensielt scenario der vi kanskje ønsker å midlertidig deaktivere applikasjonssignaturverifisering. Som nevnt i begynnelsen av denne artikkelen, kan signaturverifisering være litt av en hodepine når du endrer eksisterende systemapplikasjoner. Hvis du installerer en modifisert versjon av en systemapplikasjon, vil du ikke kunne signere applikasjonen med et gyldig og samsvarende sertifikat. I tilfeller som dette vil du vanligvis først fjerne den eksisterende applikasjonen og deretter installere den endrede versjonen som normalt. Du kan også deaktivere signaturverifisering, men det er bedre (og tryggere) å la signaturverifisering være aktivert og ganske enkelt fjerne den gamle versjonen slik at den nye kan installeres. Dette kan imidlertid bli litt av et problem hvis appen du prøver å erstatte har data du helst ikke vil miste. Det er absolutt måter å bevare dataene manuelt ved å bruke root-tilgang og transplantere dem til den nye versjonen av appen, men brukere kan også ønske å deaktivere signaturverifisering midlertidig og deretter gjenoppta kontrollene etterpå. Alternativt som påpekt av XDA Senior Member mcbyte_it i kommentarfeltet kan dette også være nyttig i applikasjonsutvikling.
Hvordan gjøre det
Frem til nå har deaktivering av signaturverifisering vært en fryktelig løsning for stort sett alle problemer. Dette er fordi når du gjør det, kaster du i hovedsak Androids innebygde beskyttelse som sørger for at applikasjonene dine ikke har blitt tuklet med, og at oppdateringene deres kommer fra originalen utviklere. Men nå, takket være magien til Xposed Framework, kan du midlertidig deaktivere signaturverifisering og aktivere den på nytt når du er ferdig med å installere det modifiserte programmet. En slik Xposed-modul som kan gjøre nettopp dette ble nylig utgitt av XDA Senior Member pyler, og det fungerer som planlagt for alle enheter som kan kjøre Xposed. På denne måten når du ønsker å installere en modifisert applikasjonsoppdatering som ikke er riktig signert, kan du ganske enkelt aktiver modulen, start på nytt, installer den modifiserte applikasjonsoppdateringen, deaktiver modulen, start på nytt og vær glad vei.
Nå som du vet hvordan du midlertidig deaktiverer signaturverifisering, er det viktig å gjenta hvor viktig det er det er å la signaturverifisering være aktivert til enhver tid, med mindre du har en veldig, veldig god grunn til å deaktivere den. Som sådan bør du egentlig bare bruke et slikt verktøy for å bruke applikasjonsoppdateringer som du oppretter selv og når det er formildende omstendigheter som krever at du gjør det i stedet for å bare avinstallere det gamle programmet først.
Vær trygg, og bruk dette med omtanke.