Applikationssignaturbekræftelse: Sådan fungerer det, hvordan du deaktiverer det med Xposed, og hvorfor du ikke bør

Hvis du nogensinde har prøvet at ændre og geninstallere et systemprogram, er du sandsynligvis stødt på kontrol af applikationssignatur i en eller anden form. Enten fjernede du den originale app, før du fortsatte, eller også gav du din ændrede APK et andet pakkenavn for at få den til at installere uden først at fjerne den gamle applikation. Og i begge tilfælde skulle du også selv signere applikationen igen for at få den til at installere i første omgang.

Du kan omgå al denne adfærd ved midlertidigt at deaktivere applikationssignaturkontrol. Men før vi kommer ind på det metaforiske kød og kartofler i denne artikel og fortæller dig, hvordan du gør det, det er vigtigt, at vi taler lidt om applikationssignaturtjek, hvad de gør, og hvorfor du bør aldrig fjerne dem i langt de fleste tilfælde.

Grundlæggende om Android-signaturbekræftelse

Som standard kræver Android OS

alle applikationer, der skal signeres for at blive installeret. Helt grundlæggende betyder det, at applikationssignaturen bruges til at identificere forfatteren af ​​en applikation (dvs. verificere dens legitimitet), samt etablere tillidsforhold mellem applikationer med samme signatur. Med førstnævnte er du sikret (i rimelig grad), at en applikation med en gyldig signatur kommer fra de forventede udviklere. Og gennem sidstnævnte kan applikationer, der er signeret med den samme private nøgle, køre i den samme proces og dele private data. Når du derefter installerer en applikationsopdatering, tjekker Android OS denne signatur for at sikre, at: A) APK'en ikke er blevet manipuleret i tiden siden den blev underskrevet, og B) applikationens certifikat svarer til det aktuelt installerede version.

Så hvordan påvirker alt dette mig i den virkelige verden? Det er simpelt, virkelig. Hvis du anskaffer en APK uden for Google Play Butik og forsøger at installere den som en opdatering til din aktuelt installerede app (læs: samme pakkenavn), vil OS forsøge at validere programmets certifikat for at sikre, at det kom fra den samme initial udviklere. Hvis certifikatet matcher, vil applikationsinstallationen fortsætte som planlagt, din applikation beholder sine eksisterende data, og alt er sovs. Hvis signaturen ikke er gyldig (hvilket angiver, at APK-en er blevet manipuleret), eller hvis certifikatet ikke matcher den originale app, vil installationen mislykkes. Og som tidligere nævnt vil applikationscertifikatet kun matche, hvis det er signeret med den samme private nøgle, som blev brugt til at signere den tidligere version. Med andre ord kan du kun installere en applikation, hvis den har en gyldig signatur, der matcher APK'ens indhold, og du kan kun installere en opdatering, hvis dens certifikat også matcher det, der findes på den tidligere version af appen.

[Som en humoristisk side i denne ellers tætte artikel er der et meget offentligt eksempel, hvor en privat applikationssigneringsnøgle blev tabt eller kompromitteret. Jeg henviser selvfølgelig til Googles egen Authenticator-app, som modtog en opdatering, der ændrede sit pakkenavn fra com.google.android.apps.authenticator til com.google.android.apps.authenticator2 i en opdatering for omkring to år siden. På grund af denne ændring kunne alle efterfølgende Authenticator-appopdateringer kun udstedes under det nye pakkenavn - med den nye signatur genereret af den nye private signaturnøgle.]

Hvorfor du måske ønsker at (midlertidigt) deaktivere signaturbekræftelse

Lad os nu tage et kig på et potentielt scenarie, hvor vi måske ønsker midlertidigt at deaktivere applikationssignaturbekræftelse. Som nævnt i starten af ​​denne artikel, kan signaturbekræftelse være lidt af en hovedpine, når du ændrer eksisterende systemapplikationer. Hvis du installerer en ændret version af en systemapplikation, vil du ikke kunne signere applikationen med et gyldigt og matchende certifikat. I tilfælde som dette vil du normalt først fjerne den eksisterende applikation og derefter installere den ændrede version som normalt. Du kan også deaktivere signaturbekræftelse, men det er bedre (og sikrere) at lade signaturbekræftelse være aktiveret og blot fjerne den gamle version, så den nye kan installeres. Dette kan dog blive lidt af et problem, hvis den app, du forsøger at erstatte, har data, som du helst ikke vil miste. Der er helt sikkert måder at bevare dataene manuelt ved at bruge root-adgang og transplantere dem til den nye version af appen, men brugere ønsker måske også blot at deaktivere signaturbekræftelse midlertidigt og derefter genoptage kontrollen bagefter. Alternativt som påpeget af XDA Senior Member mcbyte_it i kommentarerne kan dette også være nyttigt i applikationsudvikling.

Sådan gør du

Indtil nu har deaktivering af signaturbekræftelse været en forfærdelig løsning på stort set ethvert problem. Dette skyldes, at når du gør det, smider du i det væsentlige Androids indbyggede beskyttelse, der sikrer at der ikke er manipuleret med dine applikationer, og at deres opdateringer kommer fra originalen udviklere. Men nu takket være magien ved Xposed Framework kan du midlertidigt deaktivere signaturbekræftelse og genaktivere den, når du er færdig med at installere din modificerede applikation. Et sådant Xposed-modul der kan gøre netop dette blev for nylig udgivet af XDA Senior Member pyler, og det fungerer som planlagt for alle enheder, der er i stand til at køre Xposed. På denne måde, når du ønsker at installere en ændret applikationsopdatering, der ikke er blevet korrekt signeret, kan du ganske enkelt aktiver modulet, genstart, installer den ændrede programopdatering, deaktiver modulet, genstart, og vær glad vej.

Nu hvor du ved, hvordan du midlertidigt deaktiverer signaturbekræftelse, er det vigtigt at gentage, hvor vigtigt det er det er at lade signaturbekræftelse være aktiveret til enhver tid, medmindre du har en meget, meget god grund til at deaktivere det. Som sådan bør du kun bruge sådan et værktøj til at anvende applikationsopdateringer, som du selv opretter, og hvornår der er formildende omstændigheder, der kræver, at du gør det i stedet for blot at afinstallere det gamle program først.

Vær sikker, og brug dette med omtanke.