DevTeam iPhone’u Nasıl Ele Geçirdi

 (fabiensanglard.net)
1 puan yazan GN⁺ 2024-03-11 | 1 yorum | WhatsApp'ta paylaş
  • 2007’deki ilk iPhone, ABD’de AT&T aboneliği olmadan etkinleştirilemiyordu ve iPhone Dev Team, yalnızca yazılımla başka operatörlerde kullanmanın yolunu açık biçimde aradı
  • Çalışma; firmware’in çözülmesi, etkinleştirmenin atlatılması, yazma izninin elde edilmesi, ARM/Mach-O toolchain kurulması, üçüncü taraf uygulamaların çalıştırılması ve operatör kilidinin kaldırılması olmak üzere 6 kilometre taşıyla özetleniyor
  • İlk kırılma noktası, .ipsw içindeki ramdisk ve şifreli DMG analizleri ile lockdownd etkinleştirme doğrulamasındaki yeniden oynatma açığından yararlanarak ana ekrana erişmekti
  • Yazma izni, Recovery Mode’da ramdisk ve kernelcache yüklendikten sonra fstab ve Services.plist değiştirilerek; /root/Media içine hapsedilmiş afcd yerine kök dosya sisteminin yönetilmesiyle elde edildi
  • Nihai unlock, baseband firmware’inin dump edilip patch’lenerek yeniden yüklenmesi ve AT+CLCK="PN",0,"00000000" komutunun çalıştırılmasını sağlayan anySIM ile otomatikleştirildi; Apple ise 27 Eylül 2007’de firmware v1.1.1 ile karşılık verdi

2007 iPhone’u ve DevTeam’in hedefi

  • Apple, iPhone’u 29 Haziran 2007’de piyasaya sürdü; o dönemde fiyatı 4GB model için $499, 8GB model için $599 idi
  • Kutudan çıkan iPhone, yalnızca Connect to iTunes ekranını gösteren etkinleştirilmemiş durumdaydı ve kullanıcının iTunes üzerinden AT&T üyeliğine kaydolması gerekiyordu
  • Kayıttan sonra bile cihaz AT&T’ye kilitli kalıyordu
  • Kanada için başlangıçta bir iPhone çıkış takvimi yoktu; Apple, Rogers ile 11 Temmuz 2008’de iPhone 3G ile birlikte anlaşmaya vardı
  • iPhone Dev Team, cihazı yalnızca yazılımla herhangi bir operatörde kullanılabilir hâle getirmeyi hedefleyerek bir araya geldi ve ilerlemeyi iphone.fiveforty.net blogunda sık sık paylaştı
    • 3 Temmuz 2007’de gece yarısından 21:00’e kadar 8 güncelleme yayımlandı

DevTeam’in 6 kilometre taşı

  • Kilitli cihazı sıradan bir akıllı telefon gibi kullanmak için şu adımlar gerekiyordu
    • Sistemi anlamak için okuma erişimi: Break DMG Password
    • Etkinleştirilmemiş durumdan çıkış: Bypass Activation
    • Sistem değişiklikleri için yazma erişimi: Get Write Access
    • Özel çalıştırılabilir dosyalar üretmek için Working Toolchain
    • Baseband’in herhangi bir operatöre bağlanmasını sağlamak için Unlock
    • Tüm süreci otomatikleştirecek uygulama: Enable Third-Party Applications
  • Wayback Machine’e göre 6 Temmuz 2007’de 6 kilometre taşından 2’si tamamlanmıştı; yolculuk 12 Eylül 2007’de sona erdi
  • 25 Eylül 2007’de taranan durum sayfasında Decrypt Firmware, Bypass Activation, Get Write Access, Get Working Toolchain, Enable Third-party Applications, Unlock Phone tamamlanmış olarak görünüyordu

.ipsw analizi ve dosya sistemini okuma

  • iTunes, cihaz geri yükleme için .ipsw uzantılı iPhone Software arşivi indiriyordu; bu dosya zip biçimindeydi
  • iPhone1,1_1.0_1A543a_Restore.ipsw içinde img2 kurtarma imajları, baseband ile ilgili Firmware klasörü, iOS çekirdeği olan kernelcache ve iki büyük DMG dosyası vardı
    • Tam iOS geri yükleme arşivinin boyutu yaklaşık 105MiB idi
  • İlk DMG olan 694-5259-38.dmg, geri yükleme sırasında kullanılan ramdisk idi ve şifreli olmadığından dd ile mount edilebiliyordu
  • Ramdisk, iOS’un tüm dosya sistemi değildi; ancak /private/etc/master.passwd üzerinden uygulamaları çalıştıran mobile kullanıcısının ve kalan süreçleri çalıştıran root kullanıcısının parolalarını görmeyi sağladı
  • İkinci DMG olan 694-5262-39.dmg, normal çalışma sırasında kullanılan iOS dosya sistemiydi ve şifreliydi
    • Anahtar, ramdisk içindeki /usr/sbin/asr içinde bulundu
    • Bu bir passphrase değil anahtar olduğu için hdiutil kullanılamıyordu; DevTeam kendi çözme aracı vfdecrypt.c’yi yazdı
    • Çözüldükten sonra çalışma zamanı dosya sisteminin tamamına okuma erişimi elde edildi

Etkinleştirmeyi atlatma

  • Normal etkinleştirmede iTunes, Apple sunucusu albert.apple.com ve iPhone’daki lockdownd rol alıyordu
    • iTunes cihazın DeviceID, IMEI, ICCID değerlerini topluyordu
    • Bu üç değeri bir token hâline getirip Apple sunucusuna gönderiyordu
    • Apple sunucusu token’ı özel anahtarıyla imzalayıp geri döndürüyordu
    • USB üzerinden bekleyen lockdownd, token’ı Apple’ın açık anahtarıyla doğruluyordu
    • Token Apple’dan gelmişse ve cihaz bilgileriyle eşleşiyorsa durum Activated olarak değişiyordu
  • dvdjon’un PhoneActivationServerı, iTunes’u HTTPS yerine HTTP üzerinden etkinleştirme sunucusuna erişecek şekilde patch’ledi ve istekleri kendi sunucusuna yönlendirdi
  • Esas nokta, yeni bir imzalı token oluşturmadan, başarılı bir etkinleştirmeden yakalanmış aynı signed token’ı girdiden bağımsız olarak geri döndüren yeniden oynatma yöntemiydi
  • George Hotz’un sunumuna göre lockdownd, yanıttaki DeviceID, IMEI, ICCID değerlerinin gerçek değerlerle eşleşip eşleşmediğini kontrol etmiyordu
  • DevTeam, plist’ten hardcoded signed token okuyup iPhone’a gönderen CLI tools geliştirdi; daha sonra bunu iTunes olmadan çalışan iPhoneInterfacee dönüştürdü

Yazma izni ve jailbreak

  • Etkinleştirilmiş iPhone, iTunes üzerinden müzik ve fotoğraf gibi dosyaların yüklenmesine izin veriyordu; ancak yüklemeden sorumlu süreç afcd, /root/Media içinde bir chroot jail’e hapsedilmişti
  • Yalnızca kullanıcı bölümü okuma/yazma (rw) olarak mount edilmişti; sistem bölümü ise salt okunur (r) durumdaydı
  • Amaç, chroot jail’den çıkıp sistem bölümüne de yazabilmekti; jailbreaking terimi de buradan çıktı
  • iPhone boot süreci normal mod ve Recovery Mode olarak ikiye ayrılıyordu
    • Normal mod BootROM → LLB → iBoot → Kernel → Normal Mode şeklinde ilerliyor; her aşama bir sonraki aşamanın imzasını doğruluyordu
    • Recovery Mode, iBoot aşamasında duruyor; iTunes ramdisk ve kernelcache gibi bileşenleri RAM’e yükleyerek geri yükleme moduna geçiriyordu
  • DevTeam, iTunesMobile.dll içinde iTunes’un geri yükleme sırasında dosya sistemine nasıl yazdığını inceleyerek mount, umount, ditto gibi komutları tespit etti
  • iPHUC, iTunesMobile.dll’in özel metotlarıyla Recovery Mode’daki cihazla iletişim kuran bir CLI aracıydı
    • Kullanıcı cihazı Recovery Mode’a alıyordu
    • Ramdisk cihaza gönderilip RAM’e yükleniyordu
    • Kernelcache gönderiliyor ve çekirdek ramdisk’i gösterecek şekilde boot ediliyordu
    • Cihaz Restore Mode’a giriyordu
  • Asıl jailbreak işlemi fstab ve Services.plist değişiklikleriyle yapıldı
    • fstab içinde sistem bölümünün salt okunur değil rw olarak mount edilmesi sağlandı
    • Services.plist içine /root/Media yerine / temel alınan ikinci bir afcd servisi eklendi
    • Yeniden başlatmadan sonra iTunes, afcd2 üzerinden tüm dosya sistemini görebiliyordu; hem sistem hem kullanıcı bölümleri okunup yazılabilir hâle geldi
  • Daha sonra etkinleştirme ve yazma erişimi, Mac OS X masaüstü uygulaması INdependence ile otomatikleştirildi

Toolchain ve üçüncü taraf uygulamalar

  • Toolchain ve üçüncü taraf uygulamaları çalıştırma süreci hakkında kamuya açık bilgi fazla değil; ancak en az 12 kişi bu işe katıldı
  • 19 Temmuz 2007’de ARM’i hedefleyen binutils toolchain tamamlandı ve DevTeam’in kendi yazdığı programları iPhone’da çalıştırması mümkün oldu
  • Nightwatch’ın ARM/Mach-O Toolchaini ile ilk bağımsız Hello World uygulaması derlenip iPhone’da çalıştırıldı
  • GeoHotz, Apple dışında Mach-O ve ARM kombinasyonunun daha önce olmadığını, bunu kendilerinin yazması gerektiğini açıkladı
  • Toolchain’in bir diğer hedefi, iTunesMobile.so içindeki özel fonksiyonları açığa çıkaran MobileTerminal.h dosyasını yeniden oluşturarak iTunes’u çalıştırmadan afc ile iletişim kurmaktı
  • Bazı sunumlar çekirdeğin execl öncesinde çalıştırılabilir dosya imzasını kontrol ettiğini söylese de, ilk iPhone’un bunu yapmadığı ve bunun v1.1.1’de eklenmiş göründüğü sonucuna varılıyor

Baseband unlock ve anySIM

  • iPhone, iOS’un çalıştığı akıllı telefon bölümü ile telefon/modem işlevini üstlenen baseband bölümü olarak ikiye ayrılıyordu
    • İki sistemin de kendi RAM’i, CPU’su, depolaması, firmware’i ve osilatörü vardı
    • İkisi, /dev/tty.baseband üzerine mount edilmiş UART hattı üzerinden AT komutları alışverişi yapıyordu
  • Unlock için gerekli AT komutu baştan beri biliniyordu
    • AT+CLCK="PN",0,"xxxxxxxx"
    • xxxxxxxx, Network Control Key olan NCK idi ve her cihaza özgü olduğu düşünülüyordu
    • Deneme sayısı 3–10 ile sınırlıydı; sonrasında firmware AT&T’ye hardlock olabiliriydi
  • Baseband’de de BootROM ve güven zinciri vardı; imza doğrulaması uygulanıyordu
  • MuscleNerd, baseband’de DFU/Recovery Mode gibi bir güvenlik ağı bulunmadığını; NOR’a veya imaja yanlış müdahale edilirse cihazın kalıcı olarak bozulabileceğini açıkladı
  • Temmuz 2007’de DevTeam, .ipsw içindeki baseband’i tersine mühendislikle inceledi; ramdisk içindeki /usr/local/bin/bbupdaterı da analiz ederek yeni baseband yükleme komutlarını belirledi
  • İlk CLI iUnlock, dump edilmiş firmware nor ve ICE03.12.06_G.fls gibi birden çok dosyaya ihtiyaç duyuyordu
  • Daha sonra daha basit anySIM uygulaması çıktı; telefona yüklendikten sonra tek düğmeyle çalıştırılabiliyordu
  • anySIM şu sırayla çalışıyordu
    • /dev/tty.baseband açılıp modem parametreleri ayarlanıyordu
    • 4MiB boyutundaki baseband, yani NOR, /tmp içine dump ediliyordu
    • Baseband RAM’e yükleniyordu
    • Ramdisk’ten çıkan ICE03.12.06_G.fls secpack yükleniyordu
    • RAM içindeki baseband komutu patch’lenerek herhangi bir NCK’nin unlock’a izin vermesi sağlanıyordu
    • Patch’lenmiş baseband yeniden yükleniyordu
    • AT+CLCK="PN",0,"00000000" ve AT+CLCK="PN",2 çalıştırılıyordu

-0x400 hilesi

  • Patch’lenmiş baseband firmware’inin normalde imza kontrolünden geçememesi ve yüklemenin başarısız olması gerekirdi
  • Atlatma yöntemi minus 0x400 offset’ini kullanıyordu
  • GeoHotz, ilk 0x400 byte’ın imza doğrulanana kadar kullanılmadığını; bu yüzden yazmaya 0x400 byte öncesinden başlamanın yeterli olduğunu açıkladı
  • Daha sonra Hacker News okurlarının açıklamalarına göre baseband yeni firmware’i en fazla 0x800 byte’lık parçalar hâlinde alıyordu
    • Tüm 4MiB’i RAM’de saklayıp ardından checksum kontrolü yaparak flash’a yazan bir yapı değildi
    • Alınan byte’lar hemen flash’a yazılıyordu; ancak yalnızca ilk 0x400 byte RAM’de buffer’lanıyordu
    • Yükleme bitince baseband checksum’ı kontrol ediyordu
    • Başarısız olursa buffer’lanmış ilk 0x400 byte flash’a yazılmadan atılıyordu
  • -0x400 yöntemi, önce özgün firmware konumundan 0x400 byte önce çöp veri yazıp ardından 4MiB firmware’i göndermeye dayanıyordu
    • Checksum başarısız oluyor ve çöp 0x400 byte atılıyordu
    • Ancak kalan yeni firmware doğru konuma zaten flash’lanmış oluyordu

Tamamlanma ve sonrasındaki kedi-fare oyunu

  • Tam yazılımsal unlock talimatları 12 Eylül 2007’de yayımlandı
  • Bununla birlikte kıtalara göre başarı örnekleri de yayımlandı; Kanada örneği de bunlar arasındaydı
  • Apple, 27 Eylül 2007’de iPhone firmware v1.1.1’i hızla yayımladı
  • DevTeam’in ilerleme çubuğu Decrypt 1.1.1, Get Write Access 1.1.1, Activate 1.1.1, Unlock 1.1.1, Enable Third-party Applications 1.1.1 olarak sıfırlandı
  • O andan itibaren Apple ile iPhone hacking topluluğu arasındaki kedi-fare oyunu başladı ve sonrasında da sürdü

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-11
Hacker News yorumları
  • Firmware güncellemelerinde yaygın bir yöntem. İlk 0x400 bayt, bir önceki aşama yükleyicinin bu aşamayı boot etmeden önce kontrol etmesi gereken başlık olduğundan, veriyi alıp serbestçe yazarken başlığın kendisi yazılmaz
    Başlık olmadığı için kod çalıştırmaya geçilmez ve bu yüzden güvenlidir; en sonda tüm imzanın doğrulaması geçerse başlık yazılarak tüm imaj geçerli hale getirilir
    Buradaki hile, istenen yazma konumundan 0x400 bayt önce önce çöp 0x400 bayt yazmaktır. Bu kısım başlık olarak değerlendirilip sadece tamponlanır ve gerçekte yazılmaz; kalan aktarım verisi ise istenen konuma gerçekten yazılır. Sonrasında imza doğrulaması başarısız olur ve aslında istenmeyen ilk 0x400 bayt da yazılmadığı için işlem başarılı sayılır
    • “Kurtarma modu” denilen kısmın o zamanlar DFU modu olarak adlandırıldığını sanıyorum. “Device firmware update” idi; o dönemde buna “recovery” deniyor muydu, üzerinden 15 yıldan fazla geçtiği için emin değilim
    • iZsh(https://x.com/izsh1911) de biliyor olabilir ama 10 yıldan uzun süredir iletişimimiz yok
  • Fabien’in yazısına yakışır şekilde iyi yazılmış ve çok ayrıntılı. O dönemde bu iPhone koruma mekanizmasını analiz ettiklerini izlediğimi hatırlıyorum; sonrasında gerçekten uzun bir yolculuk oldu
    Veri yazmadan önce uygulanan -0x400 kaydırmasını biri daha açıklarsa konu tamamen netleşecek gibi
    • -0x400 kaydırması kabaca şöyle çalışıyor gibi görünüyor
      Seek(fd, 0xA0020000 - 0x400); ile verinin yazılacağı yerden 0x400 önceye gidiliyor ve SendWrite(fd, foo, 0x400, false); ile yazılmak istenen ilk 0x400 bayt sıfırlarla dolduruluyor
      Ardından SendWrite(fd, fw, fwsize, true); ile kalan baytlar gerçek veriyle dolduruluyor ve SendEndSecpack(fd); çağrılıyor. iPhone, 0x400 bayttan sonraki veriyi yani aslında yazılmak istenen tüm veriyi kopyalayıp ardından imza doğrulamasını deniyor ve başarısız oluyor. İmza doğrulaması başarılı olsaydı sıfır bırakılan ilk 0x400 bayt da o anda kopyalanacaktı
  • Tarih kaydı açısından, iPHUC’u ben yaptım ve adını 19 yaşındayken koydum. “nightwatch” takma adını kullanan kişi erken dönem jailbreak’in ve “jailbreak” teriminin ortaya çıkmasının baş aktörlerinden biriydi ve birlikte çalışmak çok keyifliydi
    Sanırım PSP’nin kilidini açan PDF ya da TIFF exploit’leri de onun işiydi. Güney Amerika’da bir yerde, muhtemelen üniversitede çalışıp yaşıyordu ama bildiklerim bununla sınırlı
    Gerçekten çok eğlenceli bir dönemdi ve çok şey öğrendim. Ancak George Hotz, yapmaması yönündeki tekrar eden rica ve uyarılara rağmen, Japonca belgelere erişim konusunda yardımcı olan bazı kişilerin güvenliğini riske attı; bu çok sinir bozucuydu ve sonunda dev team’in projeden ayrılmasının nedeni de buydu
    • ARM mimarisini anlamama yardım eden kişilerden birinin “pineapple” takma adını kullandığını hatırladım. O dönemde ARM nispeten yeniydi; bu yüzden ilk arayüzlerde ananas motifi çoktu. Gerçekten çok iyi insanlardı, iletişimi sürdürememiş olmam üzücü
    • İftira davası riski olmadan anlatılabilecek kadarıyla, George Hotz’un insanların güvenliğini nasıl tehlikeye attığı hakkında daha fazlasını duymak isterim
  • DeviceID, IMEI ve ICCID birleştirilerek bir token oluşturulması, bunun Apple sunucusu albert.apple.com’a gönderilip Apple’ın özel anahtarıyla imzalanması ve ardından cihazda lockdownd tarafından Apple açık anahtarıyla doğrulanıp durumun “Activated” olarak değiştirilmesi, bugünkü OAuth’ın bir öncülü gibi geliyor
  • Ah, güzel günler. iPhone hack’lemenin kolay olduğu zamanlar… kolay demek yerine, bugüne göre çok daha kolay olduğu zamanlar demek daha doğru
  • Akış şemasını hangi araçla yaptıklarını merak ediyorum. Metin tabanlı görünüyor ve mermaid’den daha iyi olabilir gibi duruyor
    • Ben https://asciiflow.com kullanıyorum
    • Monodraw’a benziyor. Birkaç gün önce HN’de yeniden paylaşılmıştı
  • Hatırladığım bir anı olarak, iPhone OS 1.1 çıktığında ve jailbreak’i engellediğinde IRC kanalındaydım. O sırada bulunan yöntemlerden biri 1.0.2’ye downgrade etmek, telefonu jailbreak yapmak ve sonra iTunes üzerinden erişilebilen /root/Media dizinini / için sembolik link yapmakti
    Bu link yükseltme sırasında da korunuyordu ve sonrasında firmware güncellemesi yapınca rootfs’ye erişim sağlanabiliyordu. O zamanlar adı iOS değil iPhone OS’tu
  • İlk iPhone’larda “S” harfi güvenlik anlamına geliyor gibi duruyor. İlk ürünü piyasaya çıkarma telaşının sonucu gibi
    Otomobil üreticilerinde de benzeri vardır. Yeni bir ürünün ya da yeni bir platformun ilk birkaç model yılını satın almamak genelde daha iyidir
    • “S”nin ne anlama geldiği konusunda bir uzlaşma yok ve Apple da bunu resmî olarak hiç açıklamadı. “Successor”, “Second”, “Speed” kulağa bir ölçüde mantıklı geliyor ama gerçek cevap bilinmiyor
      Genelde “S”, temel modele kıyasla küçük bir yükseltmeyi ifade eden bir işaretti