Att dölja root-åtkomst i Magisk är på väg att bli mycket svårare att göra tack vare en nyligen genomförd förändring i SafetyNet som ger hårdvaruattester.
Tillbaka i mars installerade några användare med Magisk lade märke till att deras enheter inte klarade SafetyNet-intyg. Den här nyheten var oroande för gemenskapen på XDA eftersom det betyder att många viktiga bank-/finansiella appar och populära spel som Pokémon Go och Fate/Grand Order vägrade att köras på rotade enheter. Under en tid verkade det som om de skärpta restriktionerna i SafetyNet drogs tillbaka, för att sedan rulla ut igen för en handfull användare under de senaste veckorna. Google bekräftade dock tyst i början av maj att de testar hårdvarustödda intyg för SafetyNet-svar, vilket är det som gjorde att Magisk inte kunde dölja upplåsningsstatusen för bootloadern igen Mars. Om denna förändring rullar ut i stor utsträckning kommer det att innebära att användare måste välja mellan att ha tillgång till root/anpassade ROM/kärnor/etc. eller deras föredragna bankappar och spel. En av Androids största överklaganden för avancerade användare kan snart vara borta.
För att sammanfatta denna serie händelser bör vi först tala om SafetyNet i sig. SafetyNet är en uppsättning API: er i Google Play Services. SafetyNet Attestation API är en av dessa API: er, och den kan anropas av tredjepartsapplikationer för att kontrollera om enhetens mjukvarumiljö har manipulerats på något sätt. API letar efter olika saker som tecken på superanvändarbinärer, upplåsningsstatus för bootloader och mer. När du rotar en enhet med Magisk, "skapar den en isolerad "säker miljö" för [SafetyNet]-detekteringsprocessen, och den går genom Googles API för att skapa en äkta SafetyNet-resultat som inte återspeglar enhetens verkliga status, säger XDA Senior Recognized Developer topjohnwu. Detta gör att användaren kan rota sin telefon samtidigt som man säkerställer att API: et alltid returnerar "falskt" för eventuella kontroller av upplåsning av bootloader. Den här metoden för att kringgå SafetyNets upplåsningsdetektering av bootloader har fungerat för Magisk under de senaste år, men det beror bara på att Google har väntat med att verifiera integriteten hos startavbildningen med hjälp av hårdvara intyg. I mars verkade det som att Google äntligen började använda hårdvarubevis i SafetyNet för att verifiera boot image, men vi fick aldrig ett officiellt uttalande från Google som bekräftade ändringen och endast ett fåtal användare var det påverkade. Som upptäckts av XDA Senior Member DisplaxGoogle bekräftade dock den 5 maj 2020 att SafetyNet Attestation API-svar från vissa enheter nu inkluderar maskinvarustödda kontroller.
På Google-gruppen för "SafetyNet API-klienter" beskriver Google en ny funktion för Attestation API: evaluationType. JSON Web Signature (JWS)-svaret från vissa enheter kommer att ha ett fält som heter "evaluationType" som "kommer att ge utvecklare insikt in i de typer av signaler/mätningar som har bidragit till varje enskilt SafetyNet Attestation API-svar." En av de token som stöds i det här fältet är "HARDWARE_BACKED" vilket indikerar att API: et "[använde] de tillgängliga hårdvarustödda säkerhetsfunktionerna för fjärrenheten (t.ex. hårdvarustödd nyckelbekräftelse) för att påverka [dess] utvärdering." Google säger att de "för närvarande utvärderar och justerar behörighetskriterierna för enheter där vi kommer att förlita oss på hårdvarustödda säkerhetsfunktioner." Vad detta betyder är att på vissa enheter använder Google Play Services nu hårdvarustödd bekräftelse för att upptäcka att enhetens programvara inte har manipulerad. Google har inte officiellt dokumenterat denna förändring utanför tillkännagivandet i Google-gruppen, så vissa utvecklare som använder SafetyNet kan inte vara medveten om denna ändring (och därför ännu inte letar efter fältet "HARDWARE_BACKED" i JWS-svar.) Men för de appar som letar efter det här fältet, det finns nu inget sätt att dölja root-åtkomst för dem, förutsatt att din enhet är en del av testet som Google är löpning.
Enligt topjohnwu innebär hårdvarustödd bekräftelse att Google Play Services nu "[skicker] 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)." Eftersom de privata nycklar som nyckellagringscertifikaten härrör från stöds av telefonens isolerade säkra miljö, skulle hämtning av dem innebära att säkerheten för telefonens Trusted Execution Environment (TEE) eller dedikerad hårdvarusäkerhet modul (HSM). Om man på något sätt kunde läcka en privat nyckel, nycklar skulle snabbt återkallas när Google fick reda på det. Google erbjuder hundratusentals dollar i belöningar för alla kritiska säkerhetsbrister som påverkar TEE i Pixel-telefoner, vilket bara visar att det är oerhört osannolikt att detta är en möjlig väg att kringgå upplåsningsdetektering av bootloader hur som helst.
Ett annat potentiellt sätt som Magisk skulle kunna fortsätta att förfalska upplåsningsstatusen för bootloader är genom att modifiera SafetyNets kod på klientsidan för att alltid använda BASIC-utvärderingen. Som topjohnwu anteckningar, men detta skulle kräva injicering av anpassad kod i Google Play Services via ett hooking-ramverk som Xposed Framework. Detta är inte bara svårt att göra eftersom Google Play-tjänster är mycket förvirrade, utan det är också omöjligt att dölja eftersom "viss minnesutrymmesanalys kommer att avslöja kodmanipulation mycket enkelt." Dessutom skulle detta också bara fungera om Googles servrar fortsätter att acceptera BASIC-utvärderingar och om HARDWARE_BACKED-utvärderingar inte tillämpas på enheter som stöder dem. (SafetyNet-svar "[kommer] från Googles servrar och är signerade med Googles privata nyckel", enligt topjohnwu, så de faktiska svaren kan inte förfalskas.)
Sedan Android 7 Nougat har Google krävt att alla enheter har en isolerad säker miljö, vilket innebär att denna ändring av hur SafetyNet verifierar upplåsning av bootloader kommer att påverka de flesta enheter som är ute där. Eftersom äldre enheter utan en isolerad säker miljö uppenbarligen inte kan utföra hårdvarustödd attestation, kommer Magisk fortfarande att kunna dölja root-åtkomst på dessa enheter. Men om denna förändring rullar ut brett måste alla andra göra ett svårt val mellan root-åtkomst och bankappar.
Tyvärr finns det förmodligen många appar där ute som använder SafetyNet-kontroller när de faktiskt inte behöver det. Ett exempel som nämns av topjohnwu är den officiella McDonald's-appen, som till synes vägrar att köras på en upplåst enhet med bootloader. På Twitter kallar topjohnwu appar som överanvänder API: et för att skapa en fientlig miljö för avancerade användare. XDA erkänd utvecklare Quinny899 ansluter sig till en anekdot om hur hans team övervägde att använda SafetyNet för att kontrollera enhetens säkerhetsstatus. De bestämde sig till slut för att inte gå igenom det eftersom hans teams app krypterar all känslig data den fungerar med. SafetyNet, menar han, bör inte användas i stället för korrekt säkerhets- och datahanteringspraxis, särskilt när man överväger möjligheten att utnyttja superanvändare.
För mer information om hur den nya SafetyNet-ändringen påverkar Magisk, kolla in topjohnwu's utmärkt FAQ på Twitter. Om du bara vill kontrollera om din enhet är en del av Googles nya SafetyNet-test kan du följa med denna guide av XDA Senior Member Displax eller ladda ner den senaste Magisk Manager-versionen.
Den här artikeln uppdaterades klockan 10:46 EST den 30 juni 2020 för att korrigera att Google endast betalar ut belöningar för TEE-sårbarheter som finns i Pixel-telefoner. Dessutom lades detaljer till om den senaste Magisk Manager-utgåvan som nu visar fältet evaluationType i den inbyggda SafetyNet-checkaren.