Inhoudsopgave:
Aan het begin van elke maand geeft Google het maandelijkse Android Security Bulletin uit en begint het updates naar Pixel-telefoons te verzenden. Het is geweldig dat het bedrijf transparant is over wat er gaande is en hoe dingen worden opgelost, zelfs als je niet het type persoon bent dat graag de broncode leest.
Er is veel werk dat aan deze patches besteedt voordat ze openbaar worden gemaakt, en er is nog meer werk mee gemoeid voordat het naar andere telefoons gaat - als het al komt. Laten we eens kijken hoe de worst is gemaakt en proberen beter te begrijpen waarom de tijdlijn voor beveiligingspatches een beetje wazig is.
Eerst repareer je Android
Android is een ingewikkeld beest. Er is meer dan 5 miljoen regels code om bedrijven te helpen die mobiele producten aan de slag te laten gaan met een compleet applicatieplatform inclusief toegang tot Google Play en andere services. Het is niet iets dat kan worden gebruikt zoals het is; deze bedrijven besteden veel tijd aan het op maat maken van Android om samen te voegen met de andere software die ze mogelijk gebruiken om een mooi gehomogeniseerd besturingssysteem te maken.
Google heeft enkele regels over hoe dit moet worden gedaan als een bedrijf zijn services wil opnemen, maar fabrikanten hebben een lange leiband over hoe het eindproduct is gebouwd.
Deze code is waar een beveiligingspatch tot leven komt. Iemand, of het nu een beveiligingsonderzoeker is of gewoon een gemiddelde Joe, vindt een fout in een telefoon die kan worden gebruikt om de beveiligingslaag van het apparaat te verminderen. Als die fout niet iets is dat een OEM heeft gemaakt, moet het Android-team uitzoeken wat er gebeurt, waarom het gebeurt en hoe dit op de minst storende manier kan worden opgelost.
Als er een beveiligingslek wordt gevonden en het maakt deel uit van de basis Android-code, moet Google dit verhelpen en het vervolgens naar iedereen verzenden.
Vaak is de fout niet iets dat Google kan oplossen. Net als wij heeft Google geen toegang tot firmware van bedrijven die hardware maken zoals Qualcomm of LG. Als het probleem op hardwareniveau moet worden opgelost, is de kans groot dat het bedrijf dat enkele van de gebruikte componenten levert, eerst wijzigingen moet aanbrengen. Als dit het geval is, worden die wijzigingen doorgestuurd naar Google, zodat deze kan zien wat er moet worden gedaan om ze in de Android-code op te nemen.
Deze wijzigingen kosten tijd, vooral als het een hardwareleverancier betreft. Er is patchen en testen en meer patchen en meer testen voor elke fout in een patch. Zodra Google ervan overtuigd is dat ze een geldige oplossing voor een beveiligingsfout hebben, krijgt elk bedrijf dat Android-telefoons maakt vroegtijdig toegang (ten minste 30 dagen voordat de patch door Google openbaar wordt gemaakt) zodat ze aan de slag kunnen.
Fase twee
Hier wordt het meeste werk gedaan. Google kan Android zelf schrijven en onderhouden, maar het grootste deel van de apparaten die het gebruiken, wordt niet door Google gemaakt. Degenen die zijn - Pixel-telefoons - zijn hier ook opgenomen. Google-hardware is een klant van Android op dezelfde manier als Samsung of Motorola.
De Samsung's en LG's van de mobiele industrie, die veel wijzigingen aanbrengen in Android, hebben veel werk te doen wanneer het tijd is om een patch samen te voegen.
Al deze bedrijven gaan aan een aantal dingen werken zodra ze nieuwe code van Google hebben. Het eerste - en mogelijk belangrijkste - deel is het bepalen welk deel van de patch niet nodig is. En er zijn genoeg dingen in elke patch die een enkel bedrijf vrij kan negeren.
Als NVIDIA bijvoorbeeld wijzigingen moest aanbrengen die teruggeduwd worden naar Android, hebben geen Samsung-telefoons dat deel van de patch nodig. Een extremer voorbeeld zijn de wijzigingen die BlackBerry of Samsung hebben aangebracht waardoor het probleem al op een andere manier wordt aangepakt. Uitzoeken wat nodig is en wat niet, kan tijdrovend zijn, vooral wanneer een bedrijf grote wijzigingen aanbrengt in bepaalde delen van het besturingssysteem. Google onderzocht beschuldigingen dat OEM's beveiligingspatches stuurden die niet ingingen op sommige dingen die ze zouden moeten hebben, en dit is wat het heeft gevonden.
Niet elk deel van een patch is op elke telefoon nodig.
Zodra dat is gebeurd, moet de rest van de patch worden samengevoegd in de aangepaste Android-code van een leverancier, en vervolgens worden gebouwd en getest. Het onderdeel 'gebouwd en getest' kan een grote hoofdpijn worden als de patch niet alleen kan worden toegepast omdat deze bestanden raakt die door aangepaste code worden gebruikt of ervan afhankelijk zijn. Dat zien we ook veel. Telkens wanneer Bluetooth of Wi-Fi wordt gepatcht, of het nu de hardware of de software erachter is, raakt het code aan die is gewijzigd door een grote OEM die een aantrekkelijker besturingssysteem maakt dan een 'standaard' Android. Er zijn veel delen van Android die een OEM kan aanraken.
Zodra de technici bij Samsung of een andere leverancier een besturingssysteem hebben dat opstart en draait, moet dit worden getest. En nog wat getest. Het testen kan inhouden dat netwerkingenieurs van verschillende betrokken providers worden betrokken, en dat Google en / of de fabrikant van een component weer in de mix worden opgenomen. Het moet kloppen. Een patch die naar duizenden en duizenden telefoons wordt gestuurd, kan mogelijk het netwerk van een provider verlammen, de gegevenslimiet van elke gebruiker opeten, of zelfs ervoor zorgen dat de telefoon zelf niet meer werkt. Zoiets is onaanvaardbaar en moet worden gevonden voordat het het gebouw verlaat.
De uitrol
Het bedrijf dat uw telefoon, Google en misschien uw provider heeft gemaakt, werkt samen om een massa-over-the-air-update gereed te krijgen. Als je ooit de URL hebt gezien die wordt gebruikt om een patch te downloaden, zul je merken dat er "Google" in het webadres staat. Dat komt omdat de motor in uw telefoon die een OTA-update kan ophalen en verwerken op een zeer specifieke plaats naar een patch zoekt. Het moet weten dat de patch 100% correct is en ondertekend door de juiste digitale handtekening. Het zal dit opnieuw controleren zodra de patch volledig is gedownload.
Als u uw telefoon bij een koerier hebt gekocht, heeft deze tijdens de hele levensduur van een patch voldoende input.
Uw provider heeft mogelijk enkele regels over wanneer en wie een patch kan downloaden zodra deze live is, als hun naam op de telefoon staat. Bedrijven zoals Samsung of LG maken aangepaste versies van hun meest populaire modellen voor elke vervoerder, die veel input hebben over hoe dingen worden gedaan. Dat zou moeten omdat de naam op de doos staat. Dit kan frustrerend zijn, maar het is logisch. Als iedereen in Pittsburgh (bijvoorbeeld) die een Samsung Galaxy S8-telefoon heeft, tegelijkertijd een 800 MB patch probeert op te halen, zal het netwerk op plekken uiteenvallen. Uw provider zal alles doen wat nodig is om het netwerk in leven te houden.
Google plaatst ook een soort opschorting bij OTA-implementaties. Een specifiek aantal gebruikers ontvangt een patch en na een bepaalde tijd bepaalt Google of die gebruikers een goede of een slechte ervaring hebben gehad. Als alles goed gaat, krijgt een groter aantal gebruikers de patch in een tweede ronde. Dit herhaalt zich meerdere keren voordat de sluizen worden geopend. Gebruikers die niet willen wachten op deze laatste test kunnen handmatig een patch downloaden via hun apparaatinstellingen.
Wanneer het jouw beurt is en je je telefoon het groene licht hebt gegeven om dat bestand te pakken, wordt het gedownload en neemt je telefoon de controle over.
In jouw handen
Een patch wordt naar je telefoon gedownload en geverifieerd als het juiste spul. Oudere versies van Android hebben een speciale cache, een gedeelte van uw opslag dat is gescheiden voor zaken als een updatebestand; dingen die slechts tijdelijk aan de telefoon zijn. Telefoons die de naadloze updatefunctie van Android gebruiken (wat de meeste telefoons met Android Nougat moeten zijn wanneer ze worden verkocht) "glijden" de gedownloade bestanden in zogenaamde slots. In beide gevallen moet u voldoende ruimte hebben om het OTA-bestand uit te pakken en eraan te werken.
Telefoons met oudere versies van Android hebben mogelijk een speciale cachepartitie die tijdens een update wordt gebruikt. Het moet 2, 5 keer groter zijn dan het OTA-bestand dat je hebt gedownload.
De OTA-updatesoftware in uw telefoon is een onderdeel van Android. Een script in het gedownloade bestand vertelt het hoe je de bestanden kunt vinden die moeten worden gewijzigd en het kopieert die bestanden naar de cache van je apparaat of naar de aangewezen sleuf. Vervolgens worden de originele bestanden op uw telefoon vergeleken met de gedownloade bestanden. Sommige kunnen een eenvoudige swap zijn - neem bestand X van de telefoon en verwijder het, en vervang het vervolgens door bestand X van de OTA-download. Anderen zijn niet het volledige bestand en bevatten alleen kleine specifieke wijzigingen. De updater- en installatiesoftware in uw telefoon weet wat u hier moet doen.
Veel bestanden in Android, vooral de applicaties en softwarebibliotheken, zijn echt veel bestanden gecomprimeerd in een speciaal archief. U kunt een APK-bestand nemen en het wijzigen in een zip-bestand en het openen met Windows. Soms moeten deze archieven worden geopend en moeten delen ervan worden vervangen door nieuwe versies die zijn gedownload voor de beveiligingspatch. Daarom heb je die werkruimte in je cachepartitie nodig - daar worden deze bestanden uitgepakt.
Veel bestanden op uw telefoon zijn echt archieven die veel bestanden bevatten - inclusief andere archieven van bestanden. Het is ingewikkeld.
Zodra elk bestand in de OTA-update is verwerkt en wijzigingen zijn aangebracht in kopieën van systeembestanden, is het tijd om het systeem met hen uit te voeren. Dit gebeurt wanneer de telefoon u vraagt om opnieuw op te starten nadat de ontvangen OTA is verwerkt, omdat er vaak bestanden zijn die moeten worden gepatcht maar die in gebruik zijn terwijl de telefoon actief is. Mogelijk ziet u een scherm dat aangeeft dat er werk aan de hand is tijdens het opnieuw opstarten of ziet u mogelijk het Android-logo. In beide gevallen worden bestanden gecontroleerd, op hun plaats gezet en opnieuw gecontroleerd. De oude bestanden worden in de cache bewaard voor het geval er een probleem is en u niet kunt opstarten met de nieuwe bestanden.
Het enige dat u nog moet doen, is ervoor zorgen dat alles nog steeds is zoals u het wilt, en dat u een nieuwere datum voor de versie van de beveiligingspatch heeft in de instellingen van uw telefoon. Nu ben je klaar voor de volgende update!
