A jailbreak kapcsán minden alkalommal felmerül sokakban, hogy vajon hogyan csinálták? Az Apple is azok közé tartozik, akiket ez kifejezetten érdekel, így a részletekről nem sűrűn hallani. Most benéznénk egy kicsit a folyamat színfalai mögé.

Egyáltalán mi az a jailbreak?

A jailbreak célja, hogy megkerülhető legyen vele az Apple több korlátozása, és olyan kiegészítők is telepíthetőek legyenek az eszközre, amiket a cég egyébként nem engedélyez, így a rendszer akár teljesen átalakítható, mind kinézetre, mind működésileg. A folyamat ugyanakkor önmagában sosem tette lehetővé az App Store-ból származó, de tört appok telepítését. Ugyanakkor több oldal is rendszeresen és következetesen összemossa a jailbreaket a warezzal.

A problémát sosem maga a jailbreak jelentette, hiszen ugyan kinek fáj az, ha valaki le akarja cserélni az ikonok vagy az egész rendszer kinézetét, vagy az Értesítési központban egy gombnyomással akarja kapcsolgatni mondjuk a Wi-Fi-t? Maximum az Apple-nek. A gondok ott kezdődnek, amikor a fejlesztők munkáját valaki nem tiszteli meg azzal, hogy akár csak 0,89€ összeggel honorálja az adott alkalmazásba fektetett idejüket, miközben egy laza ebéd bárhol sokkal többe kerül ennél. Természetesen vannak drágább appok is, de a legjellemzőbb az első árkategória.

A jailbreak iránti ellenszenvet, és a warezzal való rendszeres és következetes összemosást az váltotta ki, hogy lett egy olyan réteg, aki kifejezetten a warez miatt jailbreakel. Ezt ráadásul ironikus módon épp az váltotta ki, amikor az adott oldalak elkezdték azért diszkriminálni a jailbreaket, mert egyesek warezhoz használták – ugyanakkor közben nem adtak tájékoztatást arról, valójában miért is született a jailbreak, mire is lehet használni.

A jailbreak közben egy jó játszótér az Apple számára is, mert a népszerű kiegészítőket bármikor átveheti, és beépítheti a rendszerbe, és ha eljut odáig, hogy az adott felhasználó által használt összes tweak alapból megvan az iOS-ben, akkor az illető már talán nem fog jailbreakelni.

Most nézzük, milyen csalafintaságokat igényelt a fejlesztőcsapat részéről, hogy kijátsszák az Apple-t.

“Röviden”

Az Apple örök macska-egér játékot űz a jailbreaket fejlesztőkkel: amint megjelenik egy jailbreak, a cég azt darabokra szedi, és elemzi, hogy javítani tudja a hibákat, amelyeknek csak egyik felhasználási lehetőségét jelenti a jailbreak.

Ugyanakkor képzeljük el azt, amikor megjelenik az új iOS-verzió, mint legutóbb a 6.1, majd röviddel utána a jailbreaket fejlesztő csapatoktól megérkezik a hír, hogy nem kell sokat várni az új eszköz megjelenésére. Ahogyan az egyszerű felhasználók a gép elé tapadnak, és folyamatosan frissítik a projekt weboldalát, várva a megjelenést, úgy talán az Apple-nél sincs ez másként, hiszen őket is érdekli, mit szúrhattak el. Majd az app letöltése és ízekre szedése közben több fejlesztő is a homlokára csap, hogy “Ó, anyám! Most komolyan benne maradt egy ilyen hiba…?”, és másnap már küldik is a részletes jelentést Tim Cooknak, természetesen már a megoldási javaslatokkal, vagy konkrét javítással együtt.

David Wang, vagyis @planetbeing, az evad3rs csapat tagja elmondta, hogy az evasi0n jailbreak legalább 5 különböző, új hibát használ ki (ez egyébként egy hibával több, mint amennyit a Stuxnet esetén használtak annak fejlesztői, és amely az iráni urándúsító berendezések számítógépes rendszereit támadta).

A Forbes újságírója megkérte Davidet, hogy lépésről lépésre mondja el neki, hogyan is működik az evasion, aki ha nem is ment teljesen a részletekbe, de “röviden” összefoglalta a dolog lényegét:

• Az evasi0n először is elindítja a libimobiledevice-t, ez a library felel ugyanis az iTunes-hoz hasonló módon az eszközzel való kommunikációért, mert ugyanazt a protokollt használja. Ezen keresztül az evasi0n elsőként egy, a biztonsági mentés (backup) rendszerében lévő hibát kihasználva hozzáférést szerez olyan beállításokhoz, amikhez alapesetben nem lenne hozzáférése, konkrétan ahhoz a fájlhoz, ami az eszköz időzóna-beállítását tartalmazza.
• A jailbreak program egy szimbolikus linket helyez el az időzóna-fájlban, ami egy parancsikonként működik, az egyik helyről a másikra mutat az operációs rendszerben. Ebben az adott esetben ez a link egy adott socketre mutat, ami egy korlátozott kommunikációs csatorna a különböző programok között, Wang megfogalmazásában ez “az a bizonyos vörös telefon Moszkvába”. Az evasi0n úgy módosítja ezt a socketet, hogy az hozzáférést biztosítson a Launch Daemon-hoz (rövidítve launchd), egy olyan fő folyamathoz, ami elsőként indul el az iOS rendszer betöltésekor, és így futattni tud olyan alkalmazásokat a rendszerben, amikhez egyébként a legmagasabb szintű, “root” jogosultság szükséges, és amilyen jogkörrel a felhasználók alapból nem rendelkeznek. Ez azt jelenti, hogy amikor a backup lefut, a folyamat hozzáfér az időzóna-fájlhoz, ami így a szimbolikus linknek köszönhetően hozzáférést ad a launchd-hez is.
• Az iOS-ben persze másik védelemmel is rendelkezik, ami megakadályozza, hogy az egyes folyamatok hozzáférést szerezzenek a launchd-hez: ez a kód-aláírás (code-signing). Ez a korlátozás megköveteli, hogy az eszközön futó összes kódnak rendelkeznie kell egy nem hamisítható aláírással az Apple-től. Ezért az evasi0n elindít egy olyan új appot, ami látszólag semmiféle kódot nem tartalmaz, sem aláírtat, sem aláíratlant. Viszont amikor az evasi0n utasítja a felhasználót, hogy rányomjon erre az új ikonra, az alkalmazás egy unixos trükköt vet be, az úgynevezett “shebang”-et, amivel képes arra, hogy más, aláírással rendelkező alkalmazásokból kódot hívjon be. Ekkor egyszerűen behívja a launchd-t, amihez az előbbi socket-módosításnak köszönhetően már hozzáférése van ugye, és arra használja a folyamatot, hogy lefuttassa a “remount” parancsot, megváltozatva a csak olvasható root fájlrendszer memória-beállításait, ezzel írhatóvá téve azt.
• Most, hogy a root fájlrendszer már írható, az evasi0n módosítja a launchd.conf fájlt, ami a launchd beállításait tartalmazza, így az evasi0n által a launchd-n elvégzett módosítások annak minden futásakor lefutnak. Ezzel a jailbreak maradandó marad, tehát újraindításkor nem kell a készüléket kábelre dugni, és mondjuk a redsn0w segítségével bootoltatni.
• Ettől függetlenül az eszköz nem tekinthető jailbreakeltnek, ameddig a korlátozások nem a “kernel” szintjén kerülnek eltávolításra, mert ez a legmélyebb része az operációs rendszernek, ami ellenőrzi a code-signing meglétét, és az Apple  Mobile File Integrity Damenon (AMFID) folyamat segítségével megakadályozza, hogy a nem engedélyezett appok elinduljanak. Így az ebasi0n a launchd-t használja arra, hogy egy könyvtárnyi funkciót töltsön be az AMFID-be úgy, hogy kicserélje az eredeti funkciót egy olyanra, amely az aláírás ellenőrzésekor mindig az “elfogadva” választ adja vissza. Wang azonban ennél pontosabban nem árulta el, hogy hogyan is működik az AMFID-et áthidaló megoldás. “Az Apple-nek ezt magának kell kitalálnia.” – mondta a részleteket firtató kérdésre.
• Természetesen itt még nem ér véget az iOS védelmi rendszerének legyőzése, mert egy további nehézséget áll a hackerek útjába, megakadályozandó, hogy a kernel által használt memóriát módosíthassák, ez pedig az Address Space Layout Randomization, avagy ASLR. Ez a biztonsági megoldás az eszközön futó kódot minden betöltéskor véletlenszerű helyre mozgatja a memóriában, megakadályozva ezzel azt, hogy valaki felülírja annak bizonyos részét. Az evasi0n-t persze nem lehet csak úgy kicselezni: az app egy memória lefoglalási trükk segítségével egy adott pontot keres meg a memóriában, amit sokkal nehezebb elrejteni az ARM-alapú eszközökön, ez pedig az úgynevezett ARM exception vector. A kernel ezen része kezeli az alkalmazás-összeomlásokat, listázva, hogy a memóriában hol történt az esemény. Ebből következik, hogy az evasi0n egy összeomlást szimulál a rendszerben, és ellenőrzi az ARM exception vector értékét, hogy megtudja, a memória mely részén történt az összeomlás, és ez már elegendő információ ahhoz, hogy tudja, hol kell keresnie a kernel többi részét a memóriában.
• Amint már az ASLR is megadta magát, a jailbreak egy utolsó, az iOS USB interfészében található olyan hibát használ ki, amely a kernel egy memóriacímét adja át egy programnak, és ami közben “naivan azt várja, hogy ezt a user csak úgy, megpiszkálás nélkül visszaküldi”. Ez a hiba lehetővé teszi, hogy az evasi0n a kernel bármely részét írhassa, ha akarja. Először így felülírja a kernel azon részét, amely korlátozza saját kódjának módosíthatóságát – ez gyakorlatilag egyenlő azzal, amikor valaki a három kívánsága közül az elsőnél rögtön több kívánságot kér. ”Onnantól pedig, hogy bejutottunk a kernelbe, már semmiféle biztonsági kérdés nem érdekes többé,” – mondta Wang, “akkor egyszerűen nyertünk.”

Sokak számára már a fentiek is úgy hangozhatnak, mint valami sci-fi-ben elhangzó technikai halandzsa, de akkor most következzen a cikk hosszabbik része, ami leírja, hogy pontosan mi is történik az eszközön. Ez utóbbit az accuvantlabs csapata szedte össze, és lényegesen több szakszót fog tartalmazni a fentieknél. Ezek egy részét vonatkozó Wikipedia szócikkekkel igyekeztünk érthetőbbé tenni, illetve ki is egészítettük, ahol szükségesnek éreztük.

Lépésről lépésre

Napjainkban a jailbreaket már olyan mértékben tesztelik, mielőtt megjelenne, hogy az egyszeri felhasználó már teljesen elfeledkezhet az egész során zajló komplex folyamatokról, elegendő egyetlen gombot lenyomnia, és várni, míg a szoftver elvégzi a dolgát. Az evasi0n esetén még egy ikonra rá kell nyomni a készüléken, de erről fentebb már szó esett, miért szükséges, de már legkevésbé sem olyan bonyolult, és sok lépéses, mint amilyen az egész legelején volt.

Az első dolog talán, amit fontos megemlíteni, hogy a JailbreakMe 3.0 által kihasznált hibával szemben, amit egy gyanútlan látogató ellen a tudta nélkül is fel lehetett használni, az evasi0n használatához össze kell kötni a készüléket a számítógéppel, így gyakorlatilag alacsonyabb biztonsági kockázatot jelent, és általában csak az eszköz tulajdonosa számára hasznos. Az adatokra vadászó támadók kevésbé érdeklődnek az iOS eszközök iránt, mert egy jelkóddal lezárt készülék nem hajlandó USB-n keresztül szóba állni a számítógéppel, hacsak korábban már nem volt szinkronizálva vele, mert akkor egyszer már valaki beírta a jelkódot. Ezért ha ellopnak egy készüléket, ami jelkóddal van védve, az pár speciális esettől eltekintve nem jailbreakelhető, így az adataink sincsenek veszélyben.

Az evasi0n userland komponense

A cikk ezen része az evasi0n által kihasznált, úgynevezett userland komponensének működéséről fog szólni. A userland egy, a készülék szoftverében meglévő olyan hibát jelent, amit megfelelően használva jogosulatlan hozzáférés szerezhető, ugyanakkor általában egyszerűen tudja azt javítani az Apple, így jellemzően rövid életűek, és egy szoftverfrissítés általában végez velük. Az evasi0n által használt userland hiba igen egyedülálló, mert teljességgel fájlrendszer-alapú, tehát nem igényel úgynevezett memory corruption-t ahhoz, hogy megemelje a hozzáférési jogait mobile-ról root-ra. Talán a neve is azért lett evasi0n (~kikerülés), mert egyszerűen kikerüli az összes korlátozást, ahelyett, hogy szemtől szemben megtámadná őket.

Az evasi0n 3 szakaszban végzi el a dolgát. Minden egyes szakasz a MobileBackup daemon hibáját használja ki, amely daemon felelős a felhasználói adatok biztonsági mentéséért és azok visszaállításáért. Mivel a backupokat a felhasználó eszköze hozza létre, és más készülékekre is szabadon feltehetőnek kell lenniük, így gyakorlatilag nem megbízható adatnak számítanak.

A MobileBackup domaint (MediaDomain) és relatív útvonalat (relative path) is használ minden egyes fájl azonosításához. Minden fájl abszolút elérési útvonalát egy, a domainnel egyeztetett statikus abszolút útvonal, és a hozzá kapcsolódó, fájlspecifikus relatív útvonal határozza meg. Az evasi0n az összes fájlt a MediaDomain alatt hozza létre, így minden fájl a /var/mobile/Media alatt lesz.

1. szakasz:

Az 1. szakaszban az evasi0n létrehoz egy friss backupot, amit visszaállít majd a készülékre. Ebben a backupban összesen csak a következő fájlok vannak, és mindegyiket a MediaDomain alá hozza létre:

• directory: Media/
• directory: Media/Recordings/
• symlink: Media/Recordings/.haxx -> /var/mobile
• directory: Media/Recordings/.haxx/DemoApp.app/
• file: Media/Recordings/.haxx/DemoApp.app/Info.plist
• file: Media/Recordings/.haxx/DemoApp.app/DemoApp
• file: Media/Recordings/.haxx/DemoApp.app/Icon.png
• file: Media/Recordings/.haxx/DemoApp.app/[email protected]
• file: Media/Recordings/.haxx/DemoApp.app/Icon-72.png
• file: Media/Recordings/.haxx/DemoApp.app/[email protected]
• file: Media/Recordings/.haxx/Library/Caches/com.apple.mobile.installation.plist

A szimbolikus link (symlink), ami a .haxx névvel mutat a /var/mobile útvonalra, azért készül, hogy sikerüljön kilépni a MobileBackup domainjének útvonali korlátozása alól. Ez azt jelenti, hogy alapesetben a MediaDomain alatti fájlok helye a /var/mobile/Media, de a symlink miatt a .haxx alá visszaállított fájlok már valójában a /var/mobile alá kerülnek. Ezt a technikát már korábban is alkalmazták.

A következő lépésben létrehozza a /var/mobile alatt a DemoApp.app-ot, ami egy komplett iOS-alkalmazás, ikonnal, és minden szükséges fájllal. A com.apple.mobile.installation.plist-et is frissíti, így a Springboard tudja, hogy az app hol foglal helyet a fájlrendszerben, és meg tudja jeleníteni az ikonját a főképernyőn a többi ikon mellett.

Ugyanakkor a normál iOS appoktól eltérően ez az app egy nagyon egyedi bináris állományt tartalmaz, ami mindössze csak a következőből áll:

#!/bin/launchctl submit -l remount -o /var/mobile/Media/mount.stdout -e /var/mobile/Media/mount.stderr — /sbin/mount -v -t hfs -o rw /dev/disk0s1s1

A UNIX-ban járatlanok számára: a kernel a szöveges fájlok első sorát ellenőrzi, hogy megtalálja a megfelelő interpretert, értelmezőt az adott szkripthez. Az előbbi fájl tartalma tehát arra utasítja a kernelt, hogy futtassa a launchctl-t a megadott paraméterekkel.

Ezen felül a com.apple.mobile.installation.plist is tartalmaz egy egyedi részt a DemoApp.app számára, amiben egy környezeti változó kerül beállításra, amikor az app fut:

          <key>EnvironmentVariables</key>
            <dict>
                <key>LAUNCHD_SOCKET</key>
                <string>/private/var/tmp/launchd/sock</string>
            </dict>

Ennél a lépésnél a készülék újraindul, hogy a Springboard észre vegye az appot, és megjelenítse azt a felhasználó számára.

2.1-es szakasz:

Most, hogy a korábbi fájlok már a helyükre kerültek, a 2. szakasz azzal indul, hogy újabb üres backupot hoz létre, amivel további fájlokat állít vissza a készülékre:

• directory: Media/
• directory: Media/Recordings/
• symlink: Media/Recordings/.haxx -> /var/db
• symlink: Media/Recordings/.haxx/timezone -> /var/tmp/launchd

Ez a lépés gyakorlatilag csak egy újabb symlinket hoz létre /var/db/timezone névvel, ami a /var/tmp/launchd címre mutat. A /var/tmp/launchd jogai alapértelmezetten a következők:

drwx—— 2 root   wheel  102 Feb  4 12:17 launchd

A fenti jogok alapesetben megakadályozzák, hogy a mobile-ként futó alkalmazások elérjék a launchd-t. Következő lépésben az evasi0n értesíti a felhasználót, hogy most “megcirógatja” a lockdownd-t: ez azt jelenti, hogy az evasi0n küld egy szándékosan hibás (malformed) PairRequest parancsot a lockdownd-nek. A lockdownd az a fő daemon, amelyik az USB-n keresztül kapott parancsokat kezeli, és ennek segítségével lehet adott szolgáltatásokat elindítani vagy megállítani, mint például a MobileBackup vagy az AFC. Mivel a lockdownd root jogosultsággal fut, és a felhasználó képes kommunikálni vele, így nem rendeltetésszerű használata megszokott volt már a legutóbbi jailbreakek esetén is.

Mostanra érkeztünk el odáig, amikor az első hiba kihasználásra kerül. A lockdownd a malformed PairRequest miatt fogja, és ad egy chmod 777-et a /var/db/timezone fájlnak, így az elérhető lesz a mobile user (és mindenki más) számára. Az nem teljesen világos, hogy ez a hiba magában a lockdownd-ben van, vagy valamely, általa használt library-ben vagy framework-ben.

2.2-es szakasz:

A 2.2-es szakasz még mélyebbre fúr a /var/tmp/launchd-be. Elsőként megváltoztatja a timezone-os symlinket a következőképpen. Ezt lecseréli:

Symlink:  Media/Recordings/.haxx/timezone -> /var/tmp/launchd

Erre:

Symlink:  Media/Recordings/.haxx/timezone -> /var/tmp/launchd/sock

Ezután az evasi0n küld egy újabb malformed PairRequest csomagot a lockdownd-nek, amivel így a /var/tmp/launchd/sock is elérhetővé válik a mobile user számára.

2.3-as szakasz:

A 2.3-as szakasz azzal kezdődik, hogy az evasi0n feltölti a készülékre a Cydia és a csomaglista tar-ba tömörített fájljait. Ezek nem kerülnek azonnal felhasználásra, csak azért teszi fel őket, hogy kéznél legyenek, amikor már készen van a jailbreak.

A következő lépésben az evasion jelzi, hogy a felhasználónak el kell indítani a készüléken a Jailbreak nevű appot, ami valójában az 1. szakaszban feltöltött DemoApp.app. Nézzük meg újból, mit is csinál ez az app:

#!/bin/launchctl submit -l remount -o /var/mobile/Media/mount.stdout -e /var/mobile/Media/mount.stderr — /sbin/mount -v -t hfs -o rw /dev/disk0s1s1

Mindezt a következő környezeti változóval:

LAUNCHD_SOCKET = /private/var/tmp/launchd/sock

Ha elolvassuk a launchctl használati utasítását (man launchctl), abban láthatjuk, hogy a submit parancs a következőképpen fest:

submit -l label [-p executable] [-o path] [-e path] — command [args]
A simple way of submitting a program to run without a configuration file. This mechanism also tells launchd to keep the program alive in the event of failure.
-l label
What unique label to assign this job to launchd.
-p program
What program to really execute, regardless of what follows the — in the submit sub-command.
-o path  Where to send the stdout of the program.
-e path  Where to send the stderr of the program.

Ha pedig megnézzük ugyanígy a launchd esetén is (man launchd), ott azt fogjuk látni, hogy:

ENVIRONMENTAL VARIABLES

     LAUNCHD_SOCKET

This variable is exported when invoking a command via the launchd command line. It informs launchctl how to find the correct launchd socket for communications.

Az iOS-ben lévő legtöbb dologtól eltérően a launchd folyamatok közötti kommunikációja (inter-process communication, IPC) úgynevezett unix domain socketeken keresztül történik. Emellett több launchd is fut egyszerre, minden user esetén egy. Az iOS esetén az egyik root-ként fut, a másik pedig mobile-ként. Így amikor a felhasználó elindítja a Jailbreak (DemoApp.app) appot, akkor az mobile-ként indul el, és lefuttatja a launchctl-t. Viszont a launchctl már nem a mobile user launchd-jével kommunikál, hanem a root-éval, köszönhetően a launchd socketnek, amit a /var/db/timezone sérülékenység miatt ér el.

És mivel a root user launchd-je root jogokkal fut, ez a folyamat is root-ként fog futni, amivel a rendszerpartíciót írható/olvashatóvá teszi a korábbi csak olvasható helyett, ezzel utat nyitva az exploitnak, hogy olyan maradandó módosításokat hajtson végre a rendszerpartíción, amik a betöltés korai szakaszában már lefutnak, így lesz a jailbreak untethered.

3. szakasz:

A 3. szakaszban a jailbreak befejező része indul el, ismét a MobileBackup használatával, de ebben az esetben már teljes hozzáférése van a rendszerpartícióhoz.

• directory: Media/
• directory: Media/Recordings/
• symlink: Media/Recordings/.haxx -> /
• symlink: Media/Recordings/.haxx/private/etc/launchd.conf -> /private/var/evasi0n/launchd.conf
• directory: Media/Recordings/.haxx/var/evasi0n
• file: Media/Recordings/.haxx/var/evasi0n/evasi0n
• file: Media/Recordings/.haxx/var/evasi0n/amfi.dylib
• file: Media/Recordings/.haxx/var/evasi0n/udid
• file: Media/Recordings/.haxx/var/evasi0n/launchd.conf

Itt már kezdenek a dolgok egy kicsit zavarba ejtőek lenni, köszönhetően annak, hogy a fájlok symlinkeken mennek át, de gyakorlatilag az evasi0n létrehoz egy mappát a /var/evasi0n alatt, amibe egy futtatható állományt, egy dylib-et és egy módosított launchd.conf fájlt helyez el. A launchd.conf-ot az Apple a következőképp írja le (man launchd.conf):

DESCRIPTION

     launchd.conf contains a list of subcommands (load, unload, etc.) to run via launchctl(1) when launchd(8) starts.

A módosított launchd.conf, ami a rendszer minden betöltésekor lefut, a következőket tartalmazza:

bsexec .. /sbin/mount -u -o rw,suid,dev /
setenv DYLD_INSERT_LIBRARIES /private/var/evasi0n/amfi.dylib
load /System/Library/LaunchDaemons/com.apple.MobileFileIntegrity.plist
bsexec .. /private/var/evasi0n/evasi0n
unsetenv DYLD_INSERT_LIBRARIES
bsexec .. /bin/rm -f /private/var/evasi0n/sock
bsexec .. /bin/ln -f /var/tmp/launchd/sock /private/var/evasi0n/sock

És akkor most nézzük, melyik sor pontosan mit is csinál:

bsexec .. /sbin/mount -u -o rw,suid,dev /

• Ismét mount-olja a rendszerpartíciót írható-olvasható módban

setenv DYLD_INSERT_LIBRARIES /private/var/evasi0n/amfi.dylib

• Beteszi az amfi.dylib-et minden egyes futtatható állományba, ami ezután a pont után indul el

load /System/Library/LaunchDaemons/com.apple.MobileFileIntegrity.plist

• Betölti a MobileFileIntegrity daemon-t

bsexec .. /private/var/evasi0n/evasi0n

• Lefuttatja a saját kódját, amit korábban feltett a /var/evasi0n/evasi0n mappába

unsetenv DYLD_INSERT_LIBRARIES

• Kiveszi az előbb beállított DYLD_INSERT_LIBRARIES értékét, így az amfi.dylib az innentől elinduló futtatható állományokba már nem kerül bele

bsexec .. /bin/rm -f /private/var/evasi0n/sock

• Töröl minden már létező socket fájlt a /private/var/evasi0n/sock alól

bsexec .. /bin/ln -f /var/tmp/launchd/sock /private/var/evasi0n/sock

• Létrehoz egy symlinket, ami a /var/tmp/launchd/sock mappát a /private/var/evasi0n/sock mappára linkeli át, így más folyamat is közvetlen hozzáférést kap a root jogú launchd sockethez

Ezt követően újraindítja az eszközt, amivel a fenti konfigurációs fájl is lefut. A dolog érdekessége, hogy sem az amfi.dylib, sem az evasi0n maga nem rendelkezik aláírt kóddal (code-signed). Ha megnézzük az amfi.dylib-et otool-lal, látni fogjuk, hogy valójában nincs benne TEXT/text szekció. Ez azt jelenti, hogy nincs is mit aláírni, így nem is áll neki ezzel vacakolni. Ami viszont van benne, az nem más, mint némi lazy binding:

Konklúzió

Az evasi0n azért érdekes, mert anélkül növeli meg hozzáférési jogosultságait, hogy memory corruption-t használna. Ehelyett kihasználja a /var/db/timezone adta hibát, és hozzáférést szerez a root user launchd socketjéhez. Ezután a launchd segítségével betölti a MobileFileIntegrity-t egy kódnélkül library-vel, ami miatt az MISValidateSignature minden esetben 0 értéket ad vissza.