Applikationssignaturverifiering: hur det fungerar, hur man inaktiverar det med Xposed och varför du inte borde

click fraud protection

Du kan enkelt inaktivera signaturverifiering av Android-applikationer (APK) med Xposed Framework, men du bör inte göra detta i de allra flesta fall.

Om du någonsin har försökt att ändra och installera om ett systemprogram, har du förmodligen stött på programsignaturkontroller i en eller annan form. Antingen tog du bort den ursprungliga appen innan du fortsatte, eller så gav du din modifierade APK ett annat paketnamn för att få den att installeras utan att först ta bort den gamla applikationen. Och i båda fallen var du också tvungen att signera om applikationen själv för att få den att installeras i första hand.

Du kan komma runt alla dessa beteenden genom att tillfälligt inaktivera programsignaturkontroller. Men innan vi går in på det metaforiska köttet och potatisen i denna artikel och berättar hur man gör det, det är viktigt att vi pratar lite om applikationssignaturkontroller, vad de gör och varför du skall aldrig ta bort dem i de allra flesta fall.

Grunderna för Android-signaturverifiering

Som standard kräver Android OS Allt applikationer som ska signeras för att kunna installeras. I mycket grundläggande termer betyder detta att applikationssignaturen används för att identifiera författaren till en applikation (dvs. verifiera dess legitimitet), samt upprätta förtroenderelationer mellan applikationer med samma signatur. Med den förra är du säker (i rimlig grad) att en applikation med en giltig signatur kommer från de förväntade utvecklarna. Och genom det senare kan applikationer signerade med samma privata nyckel köras i samma process och dela privata data. När du sedan installerar en programuppdatering kontrollerar Android OS den här signaturen för att se till att: A) APK-filen inte har blivit manipulerats under tiden sedan det signerades, och B) programmets certifikat matchar det för det för närvarande installerade version.

Så hur påverkar allt detta mig i den verkliga världen? Det är enkelt, verkligen. Om du skaffar en APK utanför Google Play Butik och försöker installera den som en uppdatering av din för närvarande installerade app (läs: samma paketnamn), kommer operativsystemet att försöka validera programmets certifikat för att säkerställa att det kom från samma initial utvecklare. Om certifikatet stämmer överens kommer applikationsinstallationen att fortsätta som planerat, din applikation kommer att behålla sina befintliga data och allt är sås. Om signaturen inte är giltig (vilket indikerar att APK-filen har manipulerats) eller om certifikatet inte matchar det för den ursprungliga appen, kommer installationen att misslyckas. Och som nämnts tidigare kommer applikationscertifikatet bara att matcha om det är signerat med samma privata nyckel som användes för att signera den tidigare versionen. Med andra ord kan du bara installera en applikation om den har en giltig signatur som matchar APK: s innehållet, och du kan bara installera en uppdatering om dess certifikat också matchar det som finns i den tidigare versionen av appen.

[Som en humoristisk sida i denna annars täta artikel, finns det ett mycket offentligt exempel där en privat applikationssigneringsnyckel gick förlorad eller äventyrad. Jag syftar givetvis på Googles egen Authenticator-app som fick en uppdatering som ändrade sitt paketnamn fr.o.m. com.google.android.apps.authenticator till com.google.android.apps.authenticator2 i en uppdatering för ungefär två år sedan. På grund av denna ändring kunde alla efterföljande uppdateringar av Authenticator-appen endast utfärdas under det nya paketnamnet - med den nya signaturen genererad av den nya privata signeringsnyckeln.]

Varför du kanske vill (tillfälligt) inaktivera signaturverifiering

Låt oss nu ta en titt på ett potentiellt scenario där vi kanske vill tillfälligt inaktivera verifiering av programsignatur. Som nämnts i början av den här artikeln kan signaturverifiering vara lite av en huvudvärk när du ändrar befintliga systemapplikationer. Om du installerar en modifierad version av en systemapplikation kommer du inte att kunna signera applikationen med ett giltigt och matchande certifikat. I sådana fall vill du normalt först ta bort det befintliga programmet och sedan installera den modifierade versionen som vanligt. Du kan också inaktivera signaturverifiering, men det är bättre (och säkrare) att lämna signaturverifiering aktiverad och helt enkelt ta bort den gamla versionen så att den nya kan installeras. Detta kan dock bli lite av ett problem om appen du försöker ersätta har data som du helst inte vill förlora. Det finns säkert sätt att bevara data manuellt med hjälp av root-åtkomst och transplantera den till den nya versionen av appen, men användare kanske också vill helt enkelt inaktivera signaturverifiering tillfälligt och sedan återuppta kontrollerna efteråt. Alternativt som påpekats av XDA Senior Member mcbyte_it i kommentarerna kan detta också vara användbart vid applikationsutveckling.

Hur man gör det

Fram till nu har inaktivering av signaturverifiering varit en hemsk lösning för i stort sett alla problem. Detta beror på att när du gör det, slänger du i princip Androids inbyggda skydd som säkerställer att dina applikationer inte har manipulerats och att deras uppdateringar kommer från originalet utvecklare. Men nu tack vare magin med Xposed Framework kan du tillfälligt inaktivera signaturverifiering och återaktivera den när du är klar med installationen av din modifierade applikation. En sådan Xposed-modul som kan göra just detta släpptes nyligen av XDA Senior Member pyler, och det fungerar som planerat för alla enheter som kan köra Xposed. På detta sätt när du vill installera en modifierad applikationsuppdatering som inte har signerats korrekt, kan du helt enkelt aktivera modulen, starta om, installera den modifierade programuppdateringen, inaktivera modulen, starta om och var glad sätt.

Nu när du vet hur du tillfälligt inaktiverar signaturverifiering är det viktigt att upprepa hur viktigt det är det är att lämna signaturverifiering aktiverad hela tiden, såvida du inte har en mycket, mycket god anledning att inaktivera Det. Som sådan bör du egentligen bara använda ett sådant verktyg för att tillämpa applikationsuppdateringar som du skapar själv och när det finns förmildrande omständigheter som kräver att du gör det istället för att bara avinstallera det gamla programmet först.

Var säker och använd detta med omtanke.