'Broncode van iBoot-bootloader voor iOS 9 verschijnt op GitHub'

De broncode van iBoot, deel van het bootproces van iOS, is op GitHub verschenen. Het zou daarbij gaan om de code voor een oudere versie van iOS, namelijk versie 9. Onderzoekers kunnen de software daardoor onderzoeken op kwetsbaarheden.

Onderzoeker Jonathan Levin zegt op Twitter dat de uitgelekte broncode ook gebruikt kan worden om 'een vrij iOS te draaien op ARM-bordjes of in een emulator'. De weg daar naartoe zou echter nog lang zijn. De onderzoeker zegt tegen Motherboard dat het om een belangrijk lek gaat. Het zou om de daadwerkelijke code gaan, omdat deze overeenkomt met iBoot-code die hij zelf door reverse engineering heeft weten te achterhalen. De site schrijft dat een tweede, niet nader genoemde onderzoeker eveneens de echtheid van de code heeft bevestigd. Apple versleutelt de code, waardoor deze niet te benaderen is.

Levin legt verder uit dat onderzoekers aan de hand van de code op zoek kunnen gaan naar bugs en kwetsbaarheden. Doordat het om een iBoot-versie voor een oudere variant van iOS gaat, is de vraag of de ontdekking nut heeft voor moderne versies van het besturingssysteem, afhankelijk van hoeveel overeenkomsten er in de oude en nieuwe versies van de code zitten. Volgens de onderzoeker maakt de publicatie ook de weg vrij naar tethered jailbreaks.

Motherboard wijst erop dat de code vier maanden geleden al op Reddit is verschenen in de jailbreak-subreddit, maar dat het bericht destijds weinig aandacht kreeg. Een opmerking van de AutoModerator-bot wijst erop dat de poster, genaamd apple_internals, niet voldeed aan de minimumvereisten voor het plaatsen van berichten. De GitHub-pagina die de code in eerste instantie hostte is inmiddels niet meer te benaderen door een dmca-klacht. Die is ingediend door een Amerikaans advocatenkantoor en noemt Apple als de partij die door de publicatie schade oploopt.

Het iBoot-onderdeel is verantwoordelijk voor het laden van iOS en controleert of de kernel van de juiste ondertekening is voorzien. Motherboard trekt de vergelijking met een bios.

Reacties (99)

Valt mij wel op hoe inconsequent de codestyle is.
https://github.com/h1x0rz.../init_product.c#L807-L851
Dan twee spaties indenting, dan weer een tab.
Nieuwe blocks soms openen op new line, en soms op dezelfde:
https://github.com/h1x0rz.../init_product.c#L874-L881

Ik ben Javascript (Node.js) gewend, misschien dat het in C anders is.

Het argument dat ik van sommige zie dat het in een IDE niet opvalt is een non argument, je werkt danwel met tabs, danwel met spaties, geen mix. Evenals het newline, same line voor een block.

Het geeft aan dat er inconsequent wordt gewerkt.

Btw ook de comments zijn inconsequent het is een mix van // en /*

Soms wordt er wel een goede comment geplaats (aangeven van reden van keuze) soms staat er gewoon hier wordt x gedaan (wat nagenoeg letterlijk de naam van de call is) En nee het betreft geen method definitions:

<sub>// In case of failure, put back the static cookie just in case.
task_stack_magic = DEFAULT_TASK_STACK_MAGIC;

/* We should never be here with interrupts disabled */
RELEASE_ASSERT(0 == current_task->irq_disable_count);

/* initialize the random cookie used for overflow detection */
task_init_stack_magic_cookie();

/* set up the new task */
t->magic = TASK_MAGIC;</sub>

Zelfs nog review comments in code de xxx:

<sub>/*
* Sanity check the world before we yield from this task.
*
* XXX we could avoid this for the idle task to improve latency for
* tasks made runnable in interrupt context.
*/
if (likely(&bootstrap_task != current_task)) {
#if defined(__arm__) && !defined(__clang_analyzer__)
/* the bootstrap task might yield before calling task_init() */
/* XXX really? */
if (unlikely(nullptr_value != *(volatile uint32_t *)NULL))
panic("reset vector overwritten while executing task '%s' (0x%08x)",
current_task->name, *(volatile uint32_t *)NULL);
#endif</sub>


Ik mag echt hopen dat dit geen release versie is maar een draft....

[Reactie gewijzigd door pietjuhhh1990 op 8 februari 2018 10:51]

Precies de reden voor mijn post.
Vond het ook opvallend dat ik op -1 stond.
Anyway, IDE's zijn zo instelbaar dat als je op [tab] drukt, er twee spaties komen (of whatever je wil)
In dit geval drukken ze dus soms op [tab] en soms twee keer op [spatie]

Dat is het ergste nog niet, maar geeft wel aan dat er niet volgens duidelijke afspraken gewerkt wordt.
En voor zo'n mega organisatie gebaasd mij dat oprecht.
Bugs zijn namelijk sneller gemaakt, en een bug in de bootloader van iOS devices lijkt mij niet bepaald wenselijk.
Tuurlijk wordt dat allemaal wel goed getest, maar stel dat ook de tests niet volgens duidelijke afspraken gaan zoals de code.

Ik heb zelfs review comments gevonden in de code (heb mn post aangevuld)
Ik hoop echt dat dit geen final release is geweest

Zag je edit ja.
In dat geval, mocht dit met testen ook zo zijn.
// Het werkt nog niet helemaal, als {dit} niet aangepast wordt naar {dat} dan kan het zijn dat device nooit meer kan opstarten

* wordt gereleased*

Surtout bizar dat Apple hier niet strenger in is na hun SSL bug

Je praat hier over code die geschreven is in 2014 (met nog wat fixes in 2015 wellicht voor de release), die nu gelekt is.
Je praat dus ook over policies en stand van zaken van bijna 4 jaar oud....

[Reactie gewijzigd door NovapaX op 8 februari 2018 12:39]

Dat is op zich maar drie~vier jaar hoor. Ik heb weinig bedrijven gezien die ingrijpende veranderingen in hun workflow doorvoeren in dat tijdsbestek. Zeker niet als er geen concrete reden voor is/ze die reden niet zien.
Het is dus gewoon een tamelijk recent voorbeeld en ze zullen ongetwijfeld nog steeds wel zo werken.

[Reactie gewijzigd door Koffiebarbaar op 8 februari 2018 12:49]

Voor hetzelfde geld kijk je naar een development branche van 1 of andere stagiair die gewoon een beetje aan het kloten is geweest, ontslagen door Apple en uit frustratie zijn branche heeft gepubliceerd...

Ik heb ook meerder clones gemaakt van sources die gebruikt worden in een project waar ik werk, ik hou mezelf bezig met de infrastructuur code en heb totaal geen kaas gegeten van de Python code die gebruikt wordt voor het draaien van wiskundige modellen maar ik speel wel met de code om high-level begrip te krijgen en zou dit zomaar kunnen publiceren als "productie code" terwijl mijn code in werkelijkheid niet eens development omgeving waardig is

Zeg niet dat het in deze situatie zo is gebeurd, ik zeg wel dat je na het zien van code geen flauw benul hebt of dit uiteindelijk ook zo is geïmplementeerd

[Reactie gewijzigd door Mellow Jack op 8 februari 2018 14:43]

Ja, want Apple laat de iPhone productie iBoot software schrijven door "1 of andere stagiair die gewoon een beetje aan het kloten is geweest".

Apple heeft hier gewoon duidelijk steken laten vallen, je hoeft hun niet te verdedigen.

Ik verdedig Apple niet... Natuurlijk is het knullig maar 90% van de reacties hier slaan nergens op, zonder ook maar enige kennis over de inhoud hoor je iedereen schreeuwen over de ernst van de situatie terwijl niemand het echt lijkt te begrijpen... Bron code is niets meer dan tekst... Ik kan een stagiair een opdracht geven om een innovatieve oplossing te vinden voor een probleem obv oude code... Puur om te zien of diegene wel voldoet aan de eisen die je hebt aan een beginnende software engineer, diegene denkt te werken met echte productie code, publiceert het als zodanig en alle Tweaker lama's lopen er achteraan zonder zelf even logisch na te denken

Apple heeft zelf al impliciet bevestigd dat de gelekte code gewoon productie software is. Je post is niet echt relevant.

Je weet inderdaad niet of het wellicht een draft of mid-development code betreft.
Bovendien, aan de copyright statement bovenaan, stamt de code uit 2014.... 3-4 jaar oud dus.

Kun je weinig conclusies aan verbinden voor wat betreft de staat van coding/development op dit moment.

Verder heb ik de code even doorgebrand, maar zo ernstig ziet het er allemaal niet uit.
Als je bijvoorbeeld intern besluit om je comment-style aan te passen, dan ga je natuurlijk niet met terugwerkende kracht een beetje comments aan zitten passen. Zo essentieel is dat nou ook weer niet.

Waarom zou je je daar als professionele ontwikkelaar druk om maken? Het gaat om het eindproduct. Een commercieel bedrijf als Apple wil over het algemeen hoge productiviteit zien. En dus geen opmaakpurisme op karakterniveau...

Just my two cents.

Plausibele reden voor de verschillende stijlen is dat niet alle developers dezelfde editor gebruiken.

Code wordt waarschijnlijk ook niet gecompiled in een IDE maar dmv makefiles.

Dat is gewoon een kwestie van afspraken, IDE instellingen en controle.
Maar zelfs in de grotere bedrijven schort het hier nog al eens aan. Meestal begint het met een `quick-fix` en na een tijdje is je code onleesbaar

Als niet alle ontwikkelaars voor nette code en afspraken zijn, dan blijft het dwijlen met de kraan open.

Je druk maken over indents, spacings en andere codestyle gezeur laat je als ervaren programmeur over aan de newbies.

Ik ben nog nooit een "goede" ervaren architect of designer tegen gekomen die zegt dat dit niet belangrijk is, wel dat ze er vaak geen zin in hebben e.d. maar het maakt de code minder leesbaar.

Als je het jezelf aanleert kost heet 0,0 moeite.

Het is vooral bij de oudere garde dat het wordt weggemoffeld.

[Reactie gewijzigd door pietjuhhh1990 op 8 februari 2018 11:13]

Als je ervaring hebt in dit type projecten dan weet je dat architecten standaardisatie willen en dat dit in projecten vaak niet goed gaat. Bijv. Een software project waar ik in heb meegedraaid werd het eerste jaar uitgevoerd door een redelijk consistent team... Dit jaar, nieuwe budgetten dus alle "toppers" moesten over naar de high profile projecten van dit jaar waardoor het oude project word doorontwikkeld door een relatief nieuw team...

Het is natuurlijk niet zo zwart wit hoe ik het nu schets maar het is wel elke keer afwachten of het nieuwe team zich aan de architectuur principes houd

Een "goed" team zou dit zonder problemen kunnen voortzetten, eveneens zou een goed team ook zorgen dat de code conventions ergens gedocumenteerd zijn.

Ik kan me voorstellen dat het door voorgeschreven situaties ook vaak mis loopt, maar dat zijn dan dus ook geen kwaliteitsbewuste teams.

[Reactie gewijzigd door pietjuhhh1990 op 8 februari 2018 16:53]

maar dat zijn dan dus ook geen kwaliteitsbewuste teams.

Eens maar helaas... Onder druk word alles vloeibaar en helaas ken ik geen bedrijven en personen die alles goed doen

ja en? Daar heb je checkstyle configuraties en codestyle exports voor. Iedere IDE kan al dan niet d.m.v. plugins gewoon een standaard gebruiken van codestyle conventies die gewoon in het project geborgd staan als XML bestand.

Hoe moeilijk wil je het hebben? Twee keer klikken en je hoeft je nergens druk om te maken.

edit:
atoucorrect...

[Reactie gewijzigd door supersnathan94 op 8 februari 2018 21:20]

Hmm. Het is belangrijk dat het team er comfortabel mee is. En afhankelijk van de IDE/tools die gebruikt worden is het wel of niet relevant. Goede formatting maar ruk algoritme kennis vind ik erger dan andersom.

Code conventions zijn eenvoudig te volgen, dat is meer een discipline als een kunnen kwestie. Als je het jezelf even aanleert kost het je geen moeite, het is alleen even de stap om het aan te leren.

Extra tijd kost het namelijk niet, eveneens zijn er veel tools met auto-formatting, dan zijn de intentaties e.d. "altijd" goed.

Ik kom nog wel eens ingevlogen in projecten. Dan is het vaak een hels karwei om te achterhalen welke conventies men allemaal heeft en ben ik een paar (factureerbare) uren bezig met instellingen maken. Als een team het opzetten van een devstation goed voor elkaar heeft dan is het geen probleem, als dat niet zo is dan doe ik het hoogst noodzakelijke (versiebeheer, issue tracking etc.). Code formatting is een hoop gepriegel (enter voor of na een brace, case statements wel of niet indenten etc.). Een keer raden waar ik dan tijd in steek.

Als je dat overlaat aan de "newbies" dan zal het niet beter worden, beter als ervaren programmeur de leiding te nemen hierover.

Gemier over comment stijl (// vs /**/) en blocks openen op dezelfde regel of een nieuwe regel laat je aan de newbies over, uitlijning van tabs vind ik al iets belangrijker.

Het belangrijks vind ik nog bijvoorbeeld hoofdlettergebruik (types UpperCamelCase, members lowerCamelCase, _fieldNames beginnen met een underscore en in de rest van de code no_underscores etc. of wat je dan ook afspreekt). Als je daar geen lijn in trekt dan maakt dat je code gruwelijk om naar te kijken en haast onleesbaar...

Veel van de spullen die jij aanhaalt:
UpperCamelCase -> Dit is Pascal case btw
_fieldNames -> Of dit voor private nodig is, dat hangt af van de taal, geld niet voor elke taal.
rest van de code no_underscores -> Ook weer taal afhankelijk

Voor code quality moet je eenduidig zijn, daarmee dus ook de commentblocks e.d. Je doet 't goed of niet.

Dit is Pascal case btw

Ongetwijfeld, ik ken het als ucc

Wat betreft taalafhankelijkheid quote ik mijzelf:

of wat je dan ook afspreekt

Ik noemde enkel wat voorbeelden, als ik hier elke taal en dialect moet gaan verdedigen dan ben ik hier weg!

Je doet 't goed of niet

Zeker met je eens, maar er is een verschil tussen het goed doen en het zogenoemde kommaneuken

[Reactie gewijzigd door biteMark op 8 februari 2018 12:28]

Veel talen hebben een standaard, het beste is om zo veel mogelijk te conformeren aan de bestaande standaard. Dit maakt het ook makkelijker voor nieuwe developers of voor degene die het over 5 jaar nog moeten onderhouden.

Probeer zo min mogelijk "custom-rules" te hebben want deze moet je altijd uitleggen.

Ik noemde enkel wat voorbeelden

Wat er staat heeft dus niet per sé betrekking op één programmeertaal.

als ik hier elke taal en dialect moet gaan verdedigen dan ben ik hier weg!

Ik ga hier dus niet elke taal en dialect verdedigen.

Gemier over comment style en blocks openen op dezelfde regel of een nieuwe regel laat je aan een linter over. In python flake8, in JS iets als eslint, in TS tslint. 1 keer goed over nadenken en dan gewoon als CI-job bij elke commit laten runnen, en niet mergen als je job niet passed.

Thank you.
Dat soort dingen moet je gewoon op buildniveau borgen en het liefst gelijk een warning geven in de editor. Verschillende linters helpen daar enorm bij. Checkstyle doet dit bijv voor Java erg netjes.

Hmm deels ben ik het hier mee eens. Ja inderdaad dat echte mieren geneuk is zonde van je tijd maar als ervaren programmeur en/of ervaren bedrijf zorg je wel dat er een codingstandard is. In het geval van c# programming kan je deze codingstandard zelfs forceren. Je source kan niet eens gecompiled worden als je je niet aan deze standaard houdt.

Dat staat los van de taal. Het heeft alleen met de toolchain te maken, dus dit soort 'warning->error' policies kun je bij vrijwel alle talen toepassen. Bij GCC kun je zo'n beetje alles op dit gebied customizen.

Je kraamt onzin uit. Als je met honderden developers op dezelfde codebase werkt zijn wat 'huisregeltjes' wel zo fijn om de boel op orde te houden, waaronder dankzij uniformiteit. Maar er zijn ook codestyle-regels die je simpelweg behoeden voor snel gemaakte bugs. Juist een ervaren developer weet dat, terwijl de newbie denkt: het zal wel. Totdat ie zelf de praktijk leert kennen.

Jij bent een newbie?
Duidelijk geen ervaren programmeur gezien je reactie.

Ja, maar verwacht van een bedrijf als Apple dat ze hier wel streng op zijn.
Toch belangrijke code.

Dan twee spaties indenting, dan weer een tab.

Als de tab-size in je IDE op 2 spaties staat ingesteld, dan valt het niet op. Github toont een tab als 8 spaties, waardoor het natuurlijk overduidelijk is. Moderne IDE's klagen overigens ook vaak als indentation inconsistent is, precies om deze rede

[Reactie gewijzigd door P1nGu1n op 8 februari 2018 10:28]

In code review valt dat wel op. Maar dat ligt er natuurlijk aan hoe hun werkwijze is.
Ben ik best benieuwd naar overigens.

hangt er maar helemaal van af... als ik code review zet ik whitespacing altijd als eerste uit, ik kijk naar de oplossing en niet de opmaak ;-)

Dat is maar hoeveel waarde je hecht aan code review.
Ik vind het enorm belangrijk dat ook de opmaak van je code duidelijk is, helpt collega developers enorm.

Klopt, dat kan inderdaad. maar mijn taak is controleren of de technische oplossing correct is en ons verder helpt. Opmaak is daarin ondergeschikt en kan door elke ontwikkelaar opgepakt worden.

Kan zijn, maar dan is er dus een "elke ontwikkelaar" die daar op let, en dat aanmerkt. En dan moet dat aangepast worden.
Bij Apple wordt dat blijkbaar niet gedaan. Dus back to my point.

Opmaak had voor je review al op orde moeten zijn, want dergelijke changes horen gewoon niet in je repo te komen. Het feit dat je whitespace uit zet geeft al aan dat dit bij jullie totaal niet in het vizier is en dat je geen idee hebt hoe je dat kunt voorkomen. Goed pre-commit checks kunnen je überhaupt besparen dat je zelf dat vinkje moet zetten voor whitespaces uit.

Je toon insinueert dat we maar wat doen en geen flauw idee hebben hoe een codebase onderhouden moet worden. Knap dat je dat zo concludeert... Maar je hebt zeker nog nooit met een codebase gewerkt waar met meer dan 100 man tegelijk aan gewerkt wordt en die al bestond voordat pre-commit checks uberhaubt bestonden. Wanneer een heel scala aan ontwikkelaars, van junior tot senior allemaal aan hetzelfde project werken, waarbij elke ontwikkelaar vrij is om te kiezen voor het OS waar ze zich prettig bij voelen en de IDE waar ze zich prettig bij voelen. Bij grotere organisaties kruipt inconsistente opmaak er snel in, en als er dan een keuze gemaakt moet worden tussen zorgen dat er een snelle oplossing komt voor een urgent probleem, of dat de opmaak van de code goed is, weet ik wel wat de keuze wordt. Opmaak van code is ten alle tijden ondergeschikt aan de technische oplossing.

Excuus. Dan is mijn toon niet helemaal goed overgekomen. Het stuit mij alleen tegen de borst dat je geen tijd kunt vinden om het wel netjes te doen. Dit zorgt namelijk voor bugs.

Bij ons kijken bij een gemiddelde code-review 5 of meer ontwikkelaars naar de code van anderen, waarbij iedere ontwikkelaar een ander doel voor ogen heeft:
- de architect kijkt of het past in de blauwdrukken
- de technical lead kijkt of het past binnen de vastgestelde regels
- senior developers kijken naar inhoudelijke correctheid
- junior/medior developers kijken veel naar stijl en opmaak

Uiteraard kan een architect ook kijken naar de stijl en opmaak, maar dat is niet zijn taak. Als je bedenkt dat er gemiddeld 50 reviews per dag geopend worden is het handiger om je alleen bezig te houden met de dingen die er toe doen en de zaken die er niet toe doen hou je uit je beeld om afleiding te voorkomen.

Ik begrijp je punt, het is alleen wat voorbarig om conclusies te trekken op een schakel uit de keten als je het gehele proces niet kent.

Ook in C hoor je in een project consequent te zijn qua codestijl. Daarbij moet ik wel zeggen dat Apple's document hierover erg summier is. Het gaat eigenlijk alleen over naamgeving, en zegt niets over brackets en tabs/spaties.

Lijkt er op dat de github repo offline is gehaald maar dit zou nog een mirror zijn

https://www.youtube.com/watch?v=SsoOG6ZeyUI

Iemand hier een linkje naar een site waar het nog wel op staat? Lig ik te slapen. Komt dit online. Best benieuwd eigenlijk.

Waarom is men zo 'benauwd' dat er een dcma nodig is voor 4 jaar oude code (althans als ik het goed begrepen heb)?

Omdat een groot deel van deze code nu nog steeds gebruikt wordt. Wel doorontwikkeld natuurlijk. Maar als ze ergens een bug in vinden kan dit vrij grote gevolgen hebben.

Ah "security through obscurity" grappig.

Zoals al eerder aangegeven hierboven, te laat. Nogmaals ik snap het niet.

Omdat zeer waarschijnlijk grote delen van de code nog steeds in iOS 11 gebruikt worden. Het is onlogisch en onnodig om een bootloader volledig te herschrijven voor een nieuwe iOS versie. Vergelijk het met het BIOS in je PC, die hoeft ook niet herschreven te worden voor een nieuwe OS versie.

Daarnaast geeft de code natuurlijk een hoop inzicht in hoe de bootloader werkt en deze kennis kan gebruikt worden om (onderzoek te doen naar) bijv. iOS op niet Apple hardware te gebruiken of een niet door Apple gemaakt of een aangepaste versie van het besturingssysteem.

Dus security through obscurity ...

Zoals je het nu uitlegt is het "gevaarlijk"om die code te bekijken. Wat hebben ze te verbergen? Slechte code ?

Het is al wereldwijd beschikbaar ... die code. Dus ... Kan je een heel verhaal gaan houden over van alles en nog wat. Het ligt op straat. Einde verhaal.

Ik zou zeggen leer van wat je nu terug krijgt als bedrijf met "geheime" code.

De iBoot code staat alleen versleuteld op het filesysteem van iOS?

[Reactie gewijzigd door ArtGod op 8 februari 2018 10:08]

Dan lijkt het me dat iemand binnen Apple het uitgelekt heeft..

Nee, er zijn ook niet versleutelde versies, bijvoorbeeld bij Apple zelf.
Kan zijn dat een Apple Developer dit heeft gelekt

Toch leuk op een RPI bijv. Moet het wel Jailbroken zijn direct, Kodi er op, iOS games, emulator

[Reactie gewijzigd door Macboe op 8 februari 2018 10:23]

Alle versies van iOS 9 zijn al te jailbreaken, dus daarvoor is dit niet (meer) nodig.

Inmiddels heeft Apple de code laten verwijderen via een DMCA takedown. Wat wel erg grappig is: daarmee hebben ze moeten bevestigen dat de gelekte code inderdaad de iBoot code is...

https://github.com/github.../2018/2018-02-07-Apple.md

Ik had deze gedownload, moet ik deze nu verwijderen? Ik ben niet van plan te verspreiden, gewoon bekijken.

De iPhone 4S heeft als maximale iOS versie 9, dus deze lijkt mij dan wel gevoelig te worden voor kwetsbaarheden op deze manier...

Dit is de grootste exploit van iOS. Zeker omdat de code waarschijnlijk nog in iOS 11 ook voorkomt.

[Reactie gewijzigd door RoffaboyS op 8 februari 2018 15:56]

Geweldig nieuws. Hopelijk wordt het jailbreaken van de tot nu toe verschenen versies van iOS 11 weer wat eenvoudiger (want veel van deze code zit er waarschijnlijk nog steeds in). De iBoot exploits waren altijd de leukere, want dan waren de hackers bijna meteen klaar met het exploiten van een device (op een untether na). Een bootROM exploit zou natuurlijk helemaal gaaf zijn, want dan is er een permanente untethered jailbreak beschikbaar, waar een iOS-update niets meer tegen kan doen. (A la iPhone 2g/3g)

Ik denk dat Apple hier snel op zal reageren en het zal proberen offline te halen. Er staat mij ergens iets van bij dat Apple een patent heeft op hun type bootloader, (misschien iemand die dat kan bevestigen?).

Daarnaast loop je ook risico's , er zit vast nog wel een stuk code in wat in de nieuwste iOS te vinden is.

Offline halen zal denk ik wel lukken, Alleen het verspreiden is een feit.
Dat betekend dat de code nu bij diverse mensen, hackers onderzoekers e.d. op de pc staan.

Voor apple kan het ook een voordeel zijn dat een groep onderzoekers kwetsbaarheden vinden en deze doorgeven aan apple. Andere kant kan het schaden doordat kwaadwillende hackers iets vinden dat mogelijk op het huidige IOS te vinden is.

Apple had om diezelfde reden ook het OS (iOS) al open gelaten toch?

Nee... de reden dat (delen) van de kernel open source zijn is omdat het gebaseerd is op BSD: https://www.theiphonewiki.com/wiki/Kernel#Source_Code

Nee iOS is net zoals macos gebouwd op de XNU kernel. De XNU kernel bestaat uit 2 microkernels genaamd Mach3 kernel en het gebruikt BSD services. Dat is iets anders dan gebaseerd zijn op BSD.

https://nl.m.wikipedia.org/wiki/XNU

Lijkt erop dat wikipedia.nl achterop is geraakt.

After Apple acquired NeXT, the Mach component was upgraded to OSFMK 7.3 from OSF,[2] the BSD components were upgraded with code from the FreeBSD project, and the Driver Kit was replaced with a C++ API for writing drivers called I/O Kit.

https://en.wikipedia.org/wiki/XNU

Voor het beschermen van je broncode heb je geen patent nodig: copyright is genoeg.

Alleen werkt dat niet meer in deze tijd, als de code uitgelekt is dan krijg je hem nooit meer van het internet af.

Bovendien bestaan er in Europa geen patenten op software.

Op alle code wat je typt heb je automatisch copyright, dus je mag het niet gebruiken zonder toestemming van Apple.

Een emulator bouwen op basis van deze code kan dus legaal ook niet. Het zelfde als met emulators voor consoles en dergelijke die een bios nodig hebben om te functioneren.

Dus ja, legaal gezien kun je er helemaal niets mee.

Je mag zeker een emulator bouwen op basis van deze code, zolang het een eigen implementatie is en geen copy/paste. Met de code kun je dus heel veel, je weet namelijk precies wat je moet emuleren/nabouwen.

_{Ik ben echt nog maar 1 min aan het kijken en vind een typo met een problem in de code
static volatile uint32_t deep_idle_threshold_us = 0; // <rdar://problem/8913103>
Het bug tracking systeem van Apple heet radar, denk dat dit door 'n typo is gemist....}

Foutje

[Reactie gewijzigd door pietjuhhh1990 op 8 februari 2018 10:55]

het staat in een comment... en zoals Jesse! al zegt: het is een protocol aanduiding, dan ga je vaak voor een zo kort mogelijke notatie die toch nog duidelijk blijft.

dus: er is geen probleem
edit: er is wel een probleem ;-)

[Reactie gewijzigd door Carino op 8 februari 2018 10:58]

Met het openstaande probleem duiden ik op het punt openstaande radar punt. Bugs en eventuele aanvullingen worden altijd als comment aangevuld. In het artikel wordt er gezegd dat di de gebruikte versie is en het staat vol met review comments en ook nog eens een bug.

Ah, sorry dan heb ik je verkeerd geïnterpreteerd! mea culpa!

"rdar" is hun protocol, staat op alle plekken als rdar:// en niet als radar://