Utvecklaren av Magisk har upptäckt att Google kan ha börjat använda hårdvarukontroller för att avgöra om en enhet har bootloader-upplåst.
XDA erkänd utvecklare topjohnwus "Magisk"-projekt har i huvudsak blivit synonymt med "root" i Android-gemenskapen. En av de främsta anledningarna till att det är så populärt är att det kan dölja det faktum att användaren har modifierat sin enhet. Google kan dock slå ner på Magisks förmåga att dölja upplåsningsstatusen för bootloader från applikationer.
För att rota din telefon behöver du vanligtvis låsa upp starthanteraren, som låter dig flasha modifierade startbilder. Detta behövs eftersom Magisk ändrar startavbildningen för att förfalska bootloader-status och/eller verifierad startstatuskontroll. Googles SafetyNet Attestation API, som är en del av Google Play Services, används för att tala om för en app om den körs på en manipulerad enhet; om SafetyNet API upptäcker att starthanteraren har låsts upp, kommer den att returnera en felstatus för "Basic Integrity"-kontrollen. Enheter som misslyckas med denna kontroll kan sedan låsas ute från appar som använder SafetyNet API för att fastställa enhetens integritet; sådana appar inkluderar vanligtvis bankappar, betalningsappar (som Google Pay) och många onlinespel (som Pokémon Go). Men eftersom SafetyNet API hittills bara har använt mjukvarukontroller för att avgöra om enheten har manipulerats, kan Magisk helt enkelt förfalska bootloader och/eller Verified Boot-status eftersom den är installerad på en lägre nivå och med högre behörighet än Google Play Services och andra användarutrymmen applikationer. Som topjohnwu förklarar, MagiskHide "[skapar] en isolerad "säker miljö" för upptäcktsprocessen, och den går genom Googles API för att skapa en
Nyligen har dock användare märkt att deras bootloader-upplåsta enheter inte klarar SafetyNets grundläggande integritetskontroll trots att de använde Magisk för att patcha startavbildningen. Enligt topjohnwu beror detta på att Google kan ha implementerat nyckelbekräftelse på hårdvarunivå för att verifiera att startbilden inte har manipulerats. Specifikt betyder detta att Google Play Services "[sänder] ett omodifierat nyckellagercertifikat till SafetyNet-servrar, verifierar dess legitimitet och kontrollerar certifikattilläggsdata för att veta om din enhet [har] verifierad start aktiverad (status för bootloader)." Det betyder att den kanske inte längre är möjligt att dölja det faktum att starthanteraren har låsts upp, vilket kommer att resultera i att applikationer som Google Pay och Pokémon Go inte fungerar i vanliga fall.
Som topjohnwu noterade kommer denna förändring av hur SafetyNet kontrollerar upplåsningsstatusen för bootloader genom en uppdatering på serversidan av SafetyNet API som finns i Google Play Services. Det är dock inte alla användare som misslyckas med dessa uppdaterade SafetyNet-kontroller, så den nya nyckelbekräftelsen på hårdvarunivå kanske inte har tillämpats i stor utsträckning ännu.
Vi har sett topjohnwu övervinna tekniska hinder gång på gång. Google rullar ofta ut nya kontroller i SafetyNet som topjohnwu sedan upptäcker och kringgår i Magisk. Varje ny version av Android medför ändringar i partitionsstrukturen eller startbilden, vilket kräver att topjohnwu studerar ändringarna och sedan implementerar en ny patchningsmetod. Men även topjohnwu kan kämpa för att hitta en förbifart den här gången.
Det beror på att lösningen den här gången skulle innebära att man hackar TEE-firmware (Trusted Execution Environment) för enheter för att hämta den privata nyckeln. Detta är dock otroligt svårt att göra eftersom det kräver att man hittar en sårbarhet i firmware som är designad för att vara otroligt säker. Faktum är att många företag erbjuder betalningar i hundratusentals dollar om en sådan sårbarhet skulle hittas. Google, till exempel, betalar 250 000 USD för sårbarheter för fjärrkörning av kod i Pixels Trusted Execution Environment, och upp till 1 000 000 USD för sårbarheter i Titan M säkerhetschip. Även om en privat nyckel på något sätt skulle läcka, är det osannolikt att den skulle vara till stor nytta eftersom Google kan återkalla nyckeln på distans så det kan inte användas för att verifiera enheters integritet.
När nyckelbekräftelse på hårdvarunivå har genomförts allmänt för SafetyNet, kommer de flesta enheter med olåsta startladdare som kör Android 8.0 Oreo eller högre att inte klara SafetyNets grundläggande integritetskontroll. Detta beror på att alla enheter som lanseras med Android 8.0 Oreo eller senare måste ha ett hårdvarunyckellager implementerat i en TEE. Vissa enheter nuförtiden har till och med dedikerade hårdvarusäkerhetsmoduler (HSM) som gör exploatering ännu svårare genom att flytta TEE bort från huvudprocessorn; Titan M i Pixel 4 och Samsungs nya säkerhetschip i Galaxy S20 är exempel på detta.
Topjohnwu förklarar också att andra potentiella lösningar är antingen omöjliga eller mycket utmanande. Att använda Xposed Framework för att ändra SafetyNet Attestation API i Google Play Services kommer sannolikt inte att fungera eftersom "korrekta SafetyNet-kontroller kommer att verifiera resultat på en fjärrserver, inte på [den] enhet som kan manipuleras av ramverk för kodinjektion." Dessutom är Google Play Services mycket förvirrad, vilket gör skapandet av en sådan Xposed-modul otroligt utmanande i den första plats. Det går inte heller att förfalska ett SafetyNet-testresultat eftersom SafetyNet-svaren "kommer från Googles servrar och är signerade med Googles privata nyckel."
Google har haft möjligheten att skärpa SafetyNet-kontroller med hjälp av hårdvarustödd nyckelbekräftelse i flera år nu. Det faktum att de avstått från att göra det i 3 år har gjort det möjligt för användare att njuta av root- och Magisk-moduler utan att offra möjligheten att använda bankappar. Det verkar dock som att Magisks förmåga att effektivt dölja upplåsningsstatusen för bootloader snart är på väg att ta slut. Det är en förändring som vi har förväntat oss i flera år, men vi är ledsna att se att den äntligen träder i kraft. Vi hoppas att Google uppdaterar SafetyNet Attestation API för att returnera om statuskontrollen används hårdvarubaserad intyg eftersom detta skulle tillåta apputvecklare att bestämma om de vill blockera alla användare som har låst upp bootloader.
Tack till Daniel Micay (@Daniel Micay) för hans input angående denna fråga!