Aan het begin van elke maand publiceert Google de maandelijkse Android-beveiligingsbulletin en begint met het verzenden van updates naar Pixel-telefoons. Het is geweldig dat het bedrijf transparant is over wat er aan de hand is en hoe dingen worden opgelost, zelfs als je niet het type persoon bent dat graag de broncode leest.
Er gaat veel werk in deze patches zitten voordat ze openbaar worden gemaakt, en er is zelfs nog meer werk mee gemoeid voordat het op andere telefoons aankomt - als het al komt. Laten we eens kijken hoe de worst wordt gemaakt en proberen beter te begrijpen waarom de tijdlijn voor beveiligingspatches een beetje wazig is.
Eerst repareer je Android
Android is een ingewikkeld beest. Het bestaat uit meer dan 5 miljoen regels code om bedrijven die mobiele producten maken te helpen aan de slag te 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 proberen Android op maat te krijgen om samen te smelten met de andere software die ze mogelijk gebruiken om een mooi gehomogeniseerd besturingssysteem te creëren.
Google heeft een aantal regels over hoe dit moet gebeuren als een bedrijf zijn diensten wil opnemen, maar fabrikanten hebben een lange lijn over hoe het eindproduct wordt 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 het op de minst storende manier kan worden opgelost.
Als er een beveiligingsfout wordt gevonden en deze maakt deel uit van de basis-Android-code, moet Google deze repareren en vervolgens naar alle anderen sturen.
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 de fout op hardwareniveau moet worden verholpen, 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 het kan zien wat er moet gebeuren om ze in de Android-code op te nemen.
Deze wijzigingen kosten tijd, vooral als er een hardwareleverancier bij betrokken is. Er is patchen en testen en meer patchen en meer testen voor elke fout die in een patch wordt aangepakt. Zodra Google er zeker van is dat ze een geldige oplossing hebben voor een beveiligingsfout, moet elk bedrijf dat Android maakt telefoons krijgen vroege toegang (minstens 30 dagen voordat de patch door Google openbaar wordt gemaakt), zodat ze erbij kunnen werk.
Fase twee
Hier wordt het meeste werk gedaan. Google mag Android zelf schrijven en onderhouden, maar de meeste apparaten die het gebruiken, zijn niet door Google gemaakt. Degenen die - Pixel-telefoons - zijn hier ook opgenomen. Google-hardware is op dezelfde manier klant van Android Samsung of Motorola is.
De Samsungs en LG's van de mobiele industrie, die veel wijzigingen aanbrengen in Android, hebben veel werk te verzetten als het tijd is om een patch samen te voegen.
Al deze bedrijven gaan aan de slag met een aantal dingen zodra ze nieuwe code van Google hebben. Het eerste - en mogelijk belangrijkste - deel is bepalen welk deel van de patch niet nodig is. En er zijn tal van dingen in elke patch die een enkel bedrijf vrijelijk kan negeren.
Als bijvoorbeeld NVIDIA moest wijzigingen aanbrengen die worden teruggeduwd naar Android, geen enkele Samsung-telefoon heeft dat deel van de patch nodig. Een extremer voorbeeld zijn de wijzigingen die BlackBerry of Samsung hebben aangebracht die het probleem al op een andere manier aanpakken. 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 de beschuldigingen dat OEM's beveiligingspatches stuurden die bepaalde dingen niet aanpakten die ze zouden moeten hebben, en dit is wat het ontdekte.
Niet elk onderdeel 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 "gebouwde en geteste" gedeelte kan een grote hoofdpijn worden als de patch niet zomaar kan worden toegepast omdat het bestanden raakt die aangepaste code gebruikt of waarvan de code afhankelijk is. Dat zien we ook veel. Telkens wanneer Bluetooth of Wi-Fi wordt gepatcht, of het nu de hardware of de software erachter is, zal het gebeuren aanraakcode die is gewijzigd door een grote OEM die een mooier besturingssysteem maakt dan "stock" Android. Er zijn veel onderdelen van Android die een OEM kan aanraken.
Zodra de technici van Samsung of een andere leverancier een besturingssysteem hebben dat opstart en werkt, moet het worden getest. En nog wat getest. Het testen kan bestaan uit het inschakelen van netwerktechnici van verschillende betrokken providers, maar ook het weer betrekken van Google en/of de fabrikant van een component. Het moet kloppen. Een patch die naar duizenden en duizenden telefoons wordt verzonden, kan mogelijk het netwerk van een provider verlammen, de datalimiet van elke gebruiker opeten of zelfs ervoor zorgen dat de telefoon zelf niet meer werkt. Iets dergelijks is onaanvaardbaar en heeft te vinden voordat het het gebouw verlaat.
De uitrol
Het bedrijf dat je telefoon heeft gemaakt, Google en misschien je provider werken samen om een massale draadloze update klaar te krijgen. Als u ooit de URL hebt gezien die wordt gebruikt om een patch te downloaden, zult u merken dat er "Google" in het webadres staat. Dat komt omdat de engine in je telefoon die een OTA-update kan ophalen en verwerken, op een heel specifieke plek op zoek is naar een patch. Het moet weten dat de patch 100% correct is en is ondertekend met 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 gedurende de hele levensduur van een patch voldoende input.
Je 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 provider, die veel input heeft voor hoe dingen worden gedaan. Het 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 patch van 800 MB probeert op te halen, zal het netwerk op plekken instorten. Uw provider zal alles doen wat nodig is om het netwerk in leven te houden.
Google houdt ook een soort van greep op OTA-uitrol. Een bepaald 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 golf. Dit herhaalt zich meerdere keren voordat de sluizen worden geopend. Gebruikers die niet op deze laatste test willen wachten, kunnen handmatig een patch downloaden via hun apparaatinstellingen.
Als het jouw beurt is en je je telefoon groen licht hebt gegeven om dat bestand te pakken, wordt het gedownload en neemt je telefoon de controle over.
In jouw handen
Er wordt een patch naar je telefoon gedownload en geverifieerd als de juiste dingen. Oudere versies van Android hebben een speciale cache, een gedeelte van uw opslag dat is opgedeeld voor zaken als een updatebestand; dingen die maar tijdelijk aan de telefoon zijn. Telefoons die gebruiken De naadloze updatefunctie van Android (wat de meeste telefoons met Android Nougat zouden moeten zijn wanneer ze worden verkocht) "stop" 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-updatersoftware in uw telefoon is een onderdeel van Android. Een script in het gedownloade bestand vertelt hoe de bestanden moeten worden gevonden die moeten worden gewijzigd en het kopieert die bestanden naar de cache van uw apparaat of naar de daarvoor bestemde sleuf. Vervolgens worden de originele bestanden op uw telefoon vergeleken met de bestanden die zijn gedownload. Sommige kunnen een simpele omwisseling 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 weten wat ze hier moeten doen.
Veel bestanden in Android, met name de applicaties en softwarebibliotheken, zijn eigenlijk heel veel bestanden die in een speciaal archief zijn gecomprimeerd. U kunt een APK-bestand nemen en dit wijzigen in een .zip-bestand en openen met Windows. Soms moeten deze archieven worden geopend en moeten delen ervan worden verwisseld met 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 eigenlijk archieven die veel bestanden bevatten, inclusief andere archieven met bestanden. Het is gecompliceerd.
Zodra elk bestand in de OTA-update is verwerkt en wijzigingen zijn aangebracht in kopieën van systeembestanden, is het tijd om het systeem ermee te laten werken. 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 gang is tijdens het opnieuw opstarten of ziet u mogelijk alleen 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.
U hoeft alleen nog maar te controleren of alles nog steeds is zoals u het wilt, en u hebt een nieuwere datum voor de versie van de beveiligingspatch in de instellingen van uw telefoon. Nu ben je klaar voor de volgende update!