iPhone 4 Jailbreak’i Bölüm 1: Giriş Noktasını Elde Etmek

• gala, iPhone 4 için iOS 4 jailbreak’ini doğrudan uygulayan bir proje; 1. bölüm, eski cihazlarda SecureROM açığını kullanarak ilk kod çalıştırmayı elde etme sürecine odaklanıyor
• iOS önyüklemesi, SecureROM’un LLB veya iBSS’i doğrulamasıyla başlar ve sonraki aşamaların bir sonraki aşamayı doğruladığı bir güven zinciri olarak devam eder; SecureROM ise üretimden sonra güncellemeyle değiştirilemez
• limera1n, A4 SoC’nin SecureROM’unu hedef alır ve DFU modunda iBSS aktarımını bekleyen cihaza saldırır; USB kontrol mesajı fuzzing’i sırasında bulunan çöküşün heap overflow’a ve shellcode çalıştırmaya yol açtığı düşünülüyor
• pod2g’nin SecureROM dumper’ı referans alınarak 0x84000000 iletişim alanı ve 0xA1:2 USB okuma isteği kullanılıyor; SecureROM dump’ını ve debug değerlerini host’a alma akışı yeniden uygulanıyor
• Rust ile yazılan payload’u Mach-O’nun __TEXT,__text bölümünden shellcode olarak çıkarıp çalıştıran bir pipeline oluşturuldu; ancak statik string’lerin __const içine yerleşmesi nedeniyle instruction pointer’a göre göreli adresleme ve assembly yerleşimi gerekli hale geldi

---

iPhone 4 jailbreak projesinin çıkış noktası

• gala, iPhone 4 için iOS 4 jailbreak’i oluşturan bir proje; bu belge de onun 1. bölümü olan “Gaining Entry”ye karşılık geliyor
• Önceki iOS tweak geliştirme deneyimi; Cydia dağıtımına, SpringBoard işlevlerini değiştirmeye, Objective-C runtime’ını doğrudan kullanmaya ve kapalı kaynak binary’leri tersine mühendisliğe uzandı
• Kendi jailbreak’ini yazma hedefi, jailbreak sürecinin gerçekte nasıl çalıştığını anlamak
• Bu çalışma, p0sixninja ve axi0mX’in açık kaynak olarak paylaştığı bilgiye büyük ölçüde dayanıyor

Eski iPhone ve Boot ROM açığını seçmek

• İlk adım, eBay’den iPhone 4 ve iPhone 3GS satın almaktı
• Güncel Xcode eski iOS sürümlerini hedeflemeye izin vermediğinden, 2010’ların yöntemiyle uygulama derleyip yükleme yolu kısa sürede tıkandı
  • Eski Mac OS X ve Xcode’u bir VM’e kurma seçeneği de değerlendirildi, ancak vazgeçildi
  • Apple’ın eski iOS hedefli binary’leri hâlâ imzalayıp imzalamayacağı da belirsizdi
• Alternatif, doğrudan Boot ROM açığını hedeflemekti
  • Eski toolchain’ler veya VM olmadan, yalnızca host makineden USB üzerinden cihazla etkileşen kodla denenebilirdi
  • iPhone Wiki’nin Vulnerabilities and Exploits bölümünde limera1n exploit kodu bulundu

SecureROM ve iOS önyükleme güven zinciri

• Apple terminolojisinde SecureROM, iOS önyükleme sürecinin ilk aşamasıdır ve sonraki önyükleme aşamasını başlatır
• SecureROM iki bileşeni yükleyebilir
  • Normal önyüklemede NOR’daki disk bölümünden Low Level Bootloader, yani LLB’yi başlatır
  • DFU modunda USB ile bilgisayara bağlandığında Restore iPhone sürecinde iBoot Single Stage, yani iBSS bootloader’ını alabilir
• SecureROM, LLB veya iBSS’in Apple tarafından imzalanmış güvenilir bir imaj olup olmadığını kontrol eder
• Daha sonra LLB ve iBSS de yükledikleri sonraki aşamaları doğrulayarak bir güven zinciri oluşturur
• SecureROM ilk aşama olduğu için önceki bir aşama tarafından doğrulanmaz ve üretim sırasında salt okunur belleğe işlenir
  • Diğer aşamalar iOS güncellemeleriyle değiştirilebilir
  • Belirli bir SecureROM sürümündeki açık, o sürümle üretilmiş cihazlarda kalıcı olarak kalır

limera1n ile DFU cihazında kod çalıştırma elde etmek

• limera1n, geohot’ın 2010’da yayımladığı ve aynı adlı jailbreak aracıyla paketlediği bir SecureROM exploit’idir
• DFU modundaki cihaz USB üzerinden host’tan iBSS almak için beklerken limera1n kullanılabilir
• A4 SoC içindeki SecureROM savunmasız olduğundan iPhone 4 uygun bir hedef haline gelir
• limera1n’in tam çalışma mantığı kamuya açık kaynaklarda eksiksiz biçimde derlenmiş değildir
  • geohot, neden çalıştığını bilmediğini söylemişti
  • p0sixninja bir teori tahmin etmişti
  • Çöküş, USB kontrol mesajı fuzzing’iyle bulunmuştu; heap overflow’a yol açan bir race condition gibi görünüyor ve shellcode enjekte edip çalıştırmayı mümkün kıldığı düşünülüyor

DFU modundaki cihazdan bellek okuma

• pod2g’nin SecureROM dumper’ı, limera1n uygulamasını, payload örneğini ve USB tabanlı bellek okuma yöntemini birlikte gösteren bir referans uygulama oldu
• SecureROM dumper, SecureROM’un eşlendiği 0x0 belleğini USB alma alanına kopyaladıktan sonra host’tan USB kontrol mesajıyla veriyi okur
• Anlaşılan akış şöyle
  • A4’ün MMU’su SRAM’in başlangıcını 0x84000000 adresine eşler
  • Host, request type 0x21, request ID 1 olan USB kontrol paketleriyle iBSS imajını parçalar halinde gönderebilir
  • Bu veri SRAM’e 0x84000000 adresinden başlayarak kopyalanır ve SecureROM bir sonraki paket kopyalama konumunu izleyen dahili bir sayaç tutar
  • Cihaz ayrıca request type 0xA1, request ID 2 kontrol paketlerine de yanıt verir ve 0x84000000 adresindeki bellek içeriğini host’a gönderir
• Bu okuma işlevi, cihazda kod çalıştırılabildiğinde özellikle kullanışlıdır
  • Payload, istenen veriyi 0x84000000 adresine kopyalar
  • Host, A1:2 okuma isteğiyle bu veriyi alabilir
• p0sixninja’nın 2013 Hack In the Box Malaysia sunumu slaytlarında pod2g’nin SecureROM dumper’ının SHAtter tabanlı olduğu yazıyor, ancak gerçek araç limera1n uygulamasını kullanıyor
• Kendi limera1n uygulamasıyla SecureROM dump’ı başarıyla alındı

0x84000000 ile payload debug’ı

• Kod çalıştırma elde edildikten sonra shellcode’un nerede çalıştığını, stack konumunun neresi olduğunu ve shellcode’un hangi belleğin üzerine yazdığını kontrol etmek gerekiyordu
• SecureROM dumper’ın okuma akışı debug çıktısı amacıyla yeniden kullanıldı
  • Payload, instruction pointer ve stack pointer değerlerini 0x84000000 adresine kopyalar
  • Host tarafındaki kod aynı yöntemle değerleri geri okur
  • Bu yöntem, bellek dump’ı üzerinden basit bir print() görevi görür
• Otomatik script, exploit çalıştırıldıktan sonra 0x84000000 adresindeki ilk birkaç word’ü dump edip çıktı penceresinde gösterir
• Doğrulanan değerler shellcode çalışma konumunu ve stack konumunu gösterdi
  • Instruction pointer 0x8402b048 civarındaydı
  • Stack pointer 0x8403bfa0 idi
  • Stack pointer, SecureROM’un ayarladığı normal stack alanının içindeydi; instruction pointer ise alınan imaj alanının içindeydi

Rust payload’u ve Mach-O shellcode çıkarma

• Payload’u yalnızca assembly ile yazmak yerine Rust payload’u derleyip shellcode’a dönüştüren bir build sistemi kuruldu
• Rust, 2020 başında armv7-apple-ios target desteğini bırakmıştı, ancak rustup ile eski desteklenen toolchain’e geçilebiliyor
• Yüksek seviyeli bir dille derleme yapıldığında yalnızca ham makine kodu değil; metadata, sanal adres alanı yapılandırma bilgisi, symbol table ve linker bilgileri içeren bir binary üretilir
• Exploit için belleğe enjekte edilip jump edilecek byte’lar yeterli olduğundan Mach-O’nun tamamı değil, yalnızca __TEXT segmentindeki __text section’ı gerekir
• strongarm, bir Mach-O analiz kütüphanesidir; build sisteminde Mach-O’yu parse edip __TEXT,__text section’ını dosyaya çıkarmak için kullanıldı
• Çıkarılan dosyanın byte’ları, limera1n ile cihazda çalıştırılacak shellcode oldu

Linker ve statik veri sorunu

• Normal binary’ler OS altyapısını ve start ya da _main gibi entry point symbol kurallarını kullanır, ancak bu shellcode kullanımı için böyle symbol’lere gerek yoktur
• Linker varsayılan olarak _main veya start yoksa hata verir
• -U _main, -U start, -static seçenekleri birleştirilerek dyld kullanmayan bir Mach-O dosyası oluşturulabildi
• strongarm başlangıçta LC_DYLD_INFO load command’ı olmayan binary’leri işleyemediği için exception fırlatıyordu
  • Bu binary dyld kullanmadığından LC_DYLD_INFO yok
  • Bunu işlemek için strongarm’a bir patch eklendi
• Rust koduna statik string eklenince payload bozuldu
  • Derlenen statik string __const içine yerleştirildi
  • Shellcode çıkarma süreci yalnızca __TEXT,__text bıraktığı için __const verisi belleğe yüklenmedi
  • Sonuçta kod eşlenmemiş bir adresten string okumaya çalışır ve çöker
• Çözüm, statik veriyi __TEXT,__text içine dahil etmek ve kararlı bir yükleme adresi varsaymamak için instruction pointer’a göre göreli adresleme kullanmaktır
• Mevcut yöntem, string’i assembly içinde tanımlayıp adresini Rust payload entry point’ine geçiriyor

1. bölümde tamamlanan yürütme pipeline’ı

• Nihai pipeline şu sırayla çalışıyor
  • Rust payload’u düzenlenir
  • Bir düğmeye basılarak payload derlenir
  • Binary’den shellcode çıkarılır
  • Runner, bağlı DFU iPhone’da limera1n ile payload’u çalıştırır
  • Runner, iletişim alanı olarak kullanılan 0x84000000 adresinden veriyi otomatik olarak okuyup hexdump olarak gösterir
• Bu noktada cihazda rastgele kod çalıştırılabilir
• Rastgele kod çalıştırma teoride birçok işi mümkün kılar, ancak cihazın gerçekten ilginç bir şey yapmasını sağlamak ayrı bir aşama olarak kalır
• Sonraki adım Part 2: Bypassing the Bootchain ile devam eder

[GN⁺]

Hacker News yorumları

• Yıllarca sadece okuyup durduktan sonra, sırf bunu söylemek için sonunda bir Hacker News hesabı açtım. Uzun süre birçok kişi için gizemli bir kara kutu olan bir şeyi böyle derlediğiniz için teşekkürler.
  iOS 4 yüklü iPod 4G’mi jailbreak yaptığım zaman, terminal mesajlarının peş peşe aktığını izlerken ne kadar gerildiğimi hâlâ çok net hatırlıyorum. Sonra okulda öğle aralarında arkadaşlarımın cihazlarını da yapıyordum; yanlışlıkla telefonu bozup yüzlerce dolarlık bir tuğla cihaza çevirmekten korkuyordum.
  Yıllar sonra geriye dönüp bakınca, Apple’ın duvarlarını aşıp kullanıcı kodu çalıştırmanın o “sihri” beni programlamaya çeken şey oldu; emeği geçen herkese derinden minnettarım.

  • Teknoloji sektöründe çalışırken, hedef koysanız bile anlamadığınız ya da başaramadığınız işler yüzünden soğuduğunuz çok gün oluyor. Yine de böyle yazıları ara sıra okuyunca açık kaynaktan ya da genel olarak teknoloji topluluğundan vazgeçmemek gerektiğini hissediyorum.
  • iPhone’u seviyorum ama eskiden çeşitli Android cihazlara CyanogenMod kurmayı özlüyorum. Gerçekten harika geliyordu.
  • Benzer bir deneyim yaşadım. Sonunda kendim jailbreak tweak’leri yapmaya başladım; bu da programlamaya ciddi biçimde girmemin başlangıcı oldu.

• Yazı için gerçekten teşekkürler. Bu kadar karmaşık kavramları kolay anlatmak derin bir anlayış gerektiriyor. Okurken, gecenin geç saatlerine kadar jailbreak projelerini hack’lediğim güzel anılar aklıma geldi.

• Okurken baştan sona gerçekten keyif aldım. Özellikle hâlâ native kod tersine mühendisliği konusunda acemi olduğum için daha da öyleydi.
  Bu, sistem kurtarma mekanizmasını kullanarak güven zincirini kırıp değiştirilmiş bir iOS’u başlattığı için tethered jailbreak gibi görünüyor. Öyleyse untethered jailbreak’in nasıl çalıştığını merak ediyorum. Güvenli önyükleme zincirini hiç es geçmeden olduğu gibi bırakıp, çalışan sistemdeki ayrıcalıklı ya da ayrıcalıksız bir süreci exploit ettikten sonra ayrıca yetki yükseltme yapmak şeklinde mi işliyor? Kalıcılık nasıl sağlanıyor; bootloader ve çekirdeğin kendi imza kontrollerine dokunmadan çekirdeğin imza kontrolü nasıl patch’leniyor, onu da merak ediyorum.

  • Genelde önyükleme sürecinde ya da hemen sonrasında kullanıcı alanından çekirdeği yeniden exploit edecek şekilde yapılandırılır. Hatırladığım teknikler arasında yeni bir launch daemon eklemek, uygulamayı geliştirici sertifikasıyla imzalamak, dinamik linker’ın tuhaf davranışlarından yararlanarak imza kontrolünü atlatan bir binary yerleştirmek gibi şeyler vardı.

• Gerçekten harika bir yazı. Hâlâ toplulukta aktif olduğunu görmek sevindirici.

• Bunu hazırladığın için teşekkürler. İçinde çok özel fotoğraflar olan bir iPhone 4s’im var; bir şekilde PIN’i unuttum ve yıllardır beklemek zorunda kaldığım bir durumda kaldı.
  Fotoğraflar olmasa doğrudan sıfırlardım; bununla PIN’i sıfırlayıp fotoğrafları kopyalayabilir miyim merak ediyorum.

  • Muhtemelen zor olur. [0]’a göre parola dosya sistemi şifreleme anahtarını korumak için kullanılıyor, bu yüzden parola olmadan dosyaların şifresi çözülemez. Fotoğrafların şifreli saklanıp saklanmadığını bilmiyorum ama öyle olduğunu varsaymak doğru olur gibi.
    Düzeltme: Yanılıyor olabilirim. [0]’da bir süre yalnızca Mail depolamasının şifrelendiği ve varsayılanın iOS 7’de değiştiği de yazıyor. Bu yüzden iPhone iOS <= 6 çalıştırıyorsa bu yöntemle cihaza erişip fotoğrafları kopyalamak mümkün olabilir. [1]’deki araç yardımcı olabilir.
    [1] https://code.google.com/archive/p/iphone-dataprotection/
    [0] https://darthnull.org/ios-encryption/

• Gerçekten iyi bir yazıydı. Yalnız eski iOS arayüzünün skeuomorphic tasarımın ihtişamını tümüyle gösterdiği sahneler içimi burktu. John Ive’dan ne kadar hoşlanmadığımı yeniden fark ettim.

  • Tıklanabilir düğmelerin tıklanabilir düğmeler gibi göründüğü dönemden mi bahsediyorsun? Berbat düz tasarım yüzünden sonunda kusurları dolanmak için erişilebilirlik özelliği eklemek zorunda kalınan bugünden farklı olarak.
    Jony belki de yazılımın başına geçmek yerine jilet gibi keskin alüminyum bilek dayanakları tasarlamaya devam etmeliydi.
  • Bence iPhone, iPhone 4 ve iOS 4 ile zirvedeydi. Sonrasında da kademeli iyileştirmeler oldu ama yeni bir iPhone’un gerçekten büyük bir yükseltme gibi hissettirdiği son an oydu. Antenna-gate’i saymazsak donanım ve yazılım tasarımı tamamen yerine oturmuştu.

• İlk birkaç bölümü gerçekten keyifle okudum. Bu bakış açısından takip etmek harika. Ben de başkalarının exploit gibi şeyleri nasıl uyguladığını anlamak için kaynak kodu çok okuyorum; başkalarının da böyle yaptığını görmek güzel.

• Henüz okumadım ama heyecanlıyım. Başta listelenen tweak’lerin hepsini kullandım ve onları yaptığın için teşekkür etmek istedim. Erken dönem iOS jailbreak’i gerçekten eğlenceliydi.

• Çok iyiydi. Çalıştırmayı denedim ama ne yazık ki eski cihazım daha en baştan açılmadı.
  Ben de o dönemde tweak yapmıştım ve jailbreak bana kara büyü gibi geliyordu. Bu yazıyı okuduktan sonra bile hâlâ bir ölçüde öyle geliyor.

• Böyle derlediğin için gerçekten teşekkürler. Bu tür şeyleri öğrenmeye çok ilgiliyim. Özellikle dafang-hacks gibi ucuz Wi‑Fi güvenlik kameralarını kendi özel firmware’imle “özgürleştirmeyi” ya da Kindle Fire tabletleri root’lamak için yeni exploit’ler yapmayı öğrenmek istiyorum.
  Ama bu süreci ayrıntılı anlatan yazılar bulmak şaşırtıcı derecede zor.