iPhone 4 को jailbreak करना, भाग 1: प्रवेश बिंदु हासिल करना

• gala iPhone 4 के लिए iOS 4 jailbreak को सीधे implement करने वाला प्रोजेक्ट है, और भाग 1 पुराने डिवाइसों में SecureROM vulnerability का उपयोग करके प्रारंभिक code execution हासिल करने की प्रक्रिया पर केंद्रित है
• iOS boot में SecureROM, LLB या iBSS को verify करता है, और उसके बाद हर चरण अगले चरण को verify करता है; इस तरह trust chain बनती है, जबकि SecureROM को निर्माण के बाद update के ज़रिए बदला नहीं जा सकता
• limera1n A4 SoC के SecureROM को target करता है और DFU mode में iBSS transfer का इंतज़ार कर रहे डिवाइस पर हमला करता है; USB control message fuzzing में मिला crash heap overflow और shellcode execution तक ले जाता है, ऐसा लगता है
• pod2g के SecureROM dumper को संदर्भ बनाकर 0x84000000 communication area और 0xA1:2 USB read request का उपयोग किया गया, और SecureROM dump व debug values को host पर लाने वाले flow को दोबारा implement किया गया
• Rust में लिखे payload को Mach-O के __TEXT,__text से shellcode के रूप में extract कर चलाने वाली pipeline बनाई गई, लेकिन static strings के __const में रखे जाने से instruction pointer-relative addressing और assembly placement की ज़रूरत पड़ी

---

iPhone 4 jailbreak प्रोजेक्ट की शुरुआत

• gala iPhone 4 के लिए iOS 4 jailbreak बनाने वाला प्रोजेक्ट है, और यह दस्तावेज़ उसका भाग 1 “Gaining Entry” है
• पहले का iOS tweak development अनुभव Cydia distribution, SpringBoard functionality modification, Objective-C runtime का सीधा उपयोग, और closed-source binaries की reverse engineering तक फैला हुआ था
• खुद jailbreak लिखने का लक्ष्य यह समझना था कि jailbreak प्रक्रिया वास्तव में कैसे काम करती है
• यह काम p0sixninja और axi0mX द्वारा open source के रूप में साझा किए गए ज्ञान पर काफी निर्भर है

पुराने iPhone और Boot ROM vulnerability का चयन

• पहला कदम eBay से iPhone 4 और iPhone 3GS खरीदना था
• नए Xcode में पुराने iOS versions को target करने की अनुमति नहीं थी, इसलिए 2010 के दशक वाले तरीके से apps build और install करने का रास्ता जल्दी बंद हो गया
  • पुराने Mac OS X और Xcode को VM में install करने का विकल्प भी देखा गया, लेकिन छोड़ दिया गया
  • यह भी स्पष्ट नहीं था कि Apple अब भी legacy iOS target binaries पर sign करेगा या नहीं
• विकल्प था कि सीधे Boot ROM vulnerability को target किया जाए
  • इससे पुराने toolchain या VM के बिना, host machine से USB के जरिए डिवाइस के साथ interact करने वाले code से काम हो सकता था
  • iPhone Wiki के Vulnerabilities and Exploits सेक्शन में limera1n exploit code की जाँच की गई

SecureROM और iOS boot trust chain

• Apple की terminology में SecureROM iOS boot process का पहला चरण है, जो अगला boot stage शुरू करता है
• SecureROM दो तरह के components load कर सकता है
  • सामान्य boot में यह NOR की disk partition से Low Level Bootloader, यानी LLB, को boot करता है
  • DFU mode में USB के जरिए कंप्यूटर से जुड़ने पर Restore iPhone प्रक्रिया में iBoot Single Stage, यानी iBSS, bootloader प्राप्त कर सकता है
• SecureROM यह verify करता है कि LLB या iBSS, Apple द्वारा signed और trusted image है या नहीं
• इसके बाद LLB और iBSS भी अपने द्वारा load किए जाने वाले अगले चरण को verify करते हैं और इस तरह trust chain बनती है
• SecureROM पहला चरण होने के कारण किसी पिछले चरण से verify नहीं होता और निर्माण के समय read-only memory में लिखा जाता है
  • अन्य चरणों को iOS update से बदला जा सकता है
  • किसी खास SecureROM version की vulnerability उस version के साथ बने डिवाइसों में स्थायी रूप से बनी रहती है

limera1n के साथ DFU डिवाइस पर code execution हासिल करना

• limera1n geohot द्वारा 2010 में प्रकाशित SecureROM exploit है, जिसे इसी नाम के jailbreak tool के रूप में package भी किया गया था
• जब DFU mode डिवाइस USB के जरिए host से iBSS पाने के लिए इंतज़ार कर रहा होता है, तब limera1n का उपयोग किया जा सकता है
• क्योंकि A4 SoC में शामिल SecureROM vulnerable है, इसलिए iPhone 4 एक उपयुक्त target बनता है
• limera1n की सटीक कार्यप्रणाली सार्वजनिक रूप से पूरी तरह साफ़ नहीं है
  • geohot ने कहा था कि उसे नहीं पता यह क्यों काम करता है
  • p0sixninja ने एक theory का अनुमान लगाया था
  • crash USB control message fuzzing से मिला था, और यह heap overflow तक ले जाने वाली race condition जैसा दिखता है, जो shellcode injection और execution संभव बनाती है

DFU mode डिवाइस से memory पढ़ना

• pod2g का SecureROM dumper limera1n implementation, payload example, और USB-आधारित memory reading method दिखाने वाला संदर्भ implementation है
• SecureROM dumper, SecureROM-mapped 0x0 memory को USB receive area में copy करता है, फिर host USB control message से data पढ़ता है
• समझा गया flow इस प्रकार है
  • A4 का MMU, SRAM की शुरुआत को 0x84000000 पर map करता है
  • host, request type 0x21 और request ID 1 वाले USB control packet से iBSS image को chunks में भेज सकता है
  • यह data 0x84000000 से SRAM में copy होता है, और SecureROM अगले packet copy location को track करने के लिए एक internal counter बनाए रखता है
  • डिवाइस request type 0xA1, request ID 2 control packet का भी जवाब देता है और 0x84000000 की memory contents को host को भेजता है
• यह read feature खास तौर पर तब उपयोगी होती है जब आप डिवाइस पर code execute कर सकते हों
  • payload मनचाहा data 0x84000000 में copy करता है
  • host A1:2 read request से उस data को वापस ले सकता है
• p0sixninja की 2013 की Hack In the Box Malaysia presentation slides में pod2g के SecureROM dumper को SHAtter-based बताया गया है, लेकिन वास्तविक utility limera1n implementation का उपयोग करती है
• अपनी limera1n implementation से SecureROM dump सफलतापूर्वक हासिल किया गया

0x84000000 का उपयोग कर payload debugging

• code execution मिलने के बाद यह पता लगाना ज़रूरी था कि shellcode कहाँ execute हो रहा है, stack कहाँ है, और shellcode कौन-सी memory overwrite कर रहा है
• SecureROM dumper के read flow को debug output के लिए दोबारा इस्तेमाल किया गया
  • payload instruction pointer और stack pointer की values को 0x84000000 में copy करता है
  • host-side code उसी तरीके से values को फिर पढ़ता है
  • यह तरीका memory dump के ज़रिए एक साधारण print() जैसा काम करता है
• automated script exploit चलने के बाद 0x84000000 के पहले कुछ words dump करके output window में दिखाती है
• प्राप्त values ने shellcode execution location और stack location दिखाए
  • instruction pointer लगभग 0x8402b048 के पास था
  • stack pointer 0x8403bfa0 था
  • stack pointer, SecureROM द्वारा सेट किए गए सामान्य stack area के भीतर था, और instruction pointer receive image area के भीतर था

Rust payload और Mach-O shellcode extraction

• केवल assembly में payload लिखने के बजाय Rust payload build कर उसे shellcode में बदलने वाला build system बनाया गया
• Rust ने 2020 की शुरुआत में armv7-apple-ios target support बंद कर दिया था, लेकिन rustup के जरिए पुराने supported toolchain पर स्विच किया जा सकता है
• high-level language से compile करने पर सिर्फ raw machine code ही नहीं, बल्कि metadata, virtual address space configuration info, symbol table, और linker information वाला binary बनता है
• exploit के लिए memory में inject करके jump करने लायक bytes ही चाहिए, इसलिए पूरे Mach-O की जगह __TEXT segment के __text section की ही ज़रूरत होती है
• strongarm एक Mach-O analysis library है, और build system में Mach-O parse करके __TEXT,__text section को file में extract करने के लिए इसका उपयोग किया गया
• extracted file के bytes ही वह shellcode बनते हैं जिसे limera1n के जरिए डिवाइस पर execute किया जाता है

linker और static data की समस्या

• सामान्य binaries OS infrastructure और start या _main जैसे entry point symbol conventions का उपयोग करते हैं, लेकिन इस shellcode use case में ऐसे symbols की ज़रूरत नहीं होती
• linker डिफ़ॉल्ट रूप से _main या start न होने पर error देता है
• -U _main, -U start, -static options के संयोजन से ऐसा Mach-O file बनाया जा सका जो dyld का उपयोग नहीं करता
• strongarm शुरुआत में LC_DYLD_INFO load command के बिना binaries को handle नहीं कर पा रहा था और exception दे रहा था
  • वह binary dyld का उपयोग नहीं करती थी, इसलिए LC_DYLD_INFO मौजूद नहीं था
  • इसे handle करने के लिए strongarm में patch जोड़ा गया
• Rust code में static strings जोड़ते ही payload टूट गया
  • compiled static strings को __const में रखा जाता है
  • shellcode extraction process सिर्फ __TEXT,__text छोड़ती है, इसलिए __const data memory में load नहीं होता
  • नतीजतन code unmapped address से strings पढ़ने की कोशिश करता है और crash हो जाता है
• समाधान यह था कि static data को __TEXT,__text के भीतर रखा जाए और स्थिर load address मानने के बजाय instruction pointer-relative addressing का उपयोग किया जाए
• वर्तमान तरीका assembly में strings define करता है और उनका address Rust payload entry point को देता है

भाग 1 में पूरा किया गया execution pipeline

• अंतिम pipeline इस क्रम में काम करती है
  • Rust payload को modify किया जाता है
  • बटन दबाकर payload compile किया जाता है
  • binary से shellcode extract किया जाता है
  • runner, जुड़े हुए DFU iPhone पर limera1n के जरिए payload execute करता है
  • runner communication space के रूप में इस्तेमाल होने वाले 0x84000000 से data अपने-आप पढ़कर hexdump के रूप में दिखाता है
• इस बिंदु पर डिवाइस पर arbitrary code execute किया जा सकता है
• arbitrary code execution सिद्धांततः बहुत कुछ संभव बनाता है, लेकिन डिवाइस से वास्तव में दिलचस्प काम करवाना एक अलग चरण के रूप में बाकी है
• अगला चरण Part 2: Bypassing the Bootchain में जारी रहता है

[GN⁺]

Hacker News की राय

• कई सालों तक सिर्फ पढ़ता रहा, लेकिन यह बात कहने के लिए आखिरकार Hacker News अकाउंट बना लिया। लंबे समय तक बहुत से लोगों के लिए रहस्यमयी ब्लैक बॉक्स रही चीज़ को इस तरह समझाकर लिखने के लिए धन्यवाद
  iOS 4 वाले iPod 4G को jailbreak करते समय terminal messages को लगातार ऊपर जाते देखकर बेहद घबराने की याद आज भी साफ़ है। बाद में स्कूल के lunch break में दोस्तों के devices पर भी यही करता था, और इस बात की चिंता रहती थी कि कहीं गलती से फोन खराब करके कई सौ डॉलर का brick device न बना दूँ
  कई साल बाद पीछे मुड़कर देखता हूँ, तो Apple की दीवारें तोड़कर user code चलाने वाला वह “जादू” ही मुझे programming में डुबोने की वजह बना, और इससे जुड़े सभी लोगों का दिल से आभारी हूँ

  • tech industry में काम करते हुए कई दिन ऐसे होते हैं जब लक्ष्य तय करने के बावजूद उन चीज़ों की वजह से मन खट्टा हो जाता है जिन्हें समझ नहीं पाता या कर नहीं पाता। फिर भी कभी-कभी ऐसे लेख पढ़कर लगता है कि open source या व्यापक tech community से हार नहीं माननी चाहिए
  • iPhone पसंद है, लेकिन पुराने दिनों में कई Android devices पर CyanogenMod डालना याद आता है। वह सचमुच बहुत शानदार लगता था
  • मेरा भी ऐसा ही अनुभव रहा। आखिरकार मैंने खुद jailbreak tweaks बनाना शुरू किया, और वही programming में गंभीरता से उतरने की वजह बना

• लेख के लिए सच में धन्यवाद। इतने जटिल concepts को आसान तरीके से समझाने के लिए गहरी समझ चाहिए। पढ़ते-पढ़ते देर रात तक jailbreak projects hack करने की अच्छी यादें ताज़ा हो गईं

• पढ़ते हुए पूरे समय बहुत मज़ा आया। खासकर इसलिए क्योंकि मैं अभी भी native code reverse engineering में उतना निपुण नहीं हूँ
  यह system recovery mechanism का इस्तेमाल करके trust chain तोड़ता है और बदला हुआ iOS boot करता है, इसलिए यह tethered jailbreak जैसा लगता है। ऐसे में जानना चाहता हूँ कि untethered jailbreak कैसे काम करता है। क्या वह secure boot chain को पूरी तरह bypass किए बिना वैसा ही छोड़कर, चल रहे system में किसी privileged process या unprivileged process को exploit करने और फिर अलग से privilege escalation करने का तरीका होता है? persistence कैसे हासिल की जाती है, और bootloader तथा kernel की अपनी signature checks को छुए बिना kernel की signature checks को कैसे patch किया जाता है?

  • आम तौर पर इसे boot process के दौरान या उसके ठीक बाद user space से kernel को फिर से exploit करने के लिए configure किया जाता है। जो techniques याद हैं उनमें नया launch daemon जोड़ना, developer certificate से app sign करना, और dynamic linker के अजीब व्यवहार का दुरुपयोग करके signature checks bypass करने वाले binaries रखना शामिल था

• सचमुच बेहतरीन लेख है। यह देखकर अच्छा लगा कि आप अब भी community में सक्रिय हैं

• इसे बनाने के लिए धन्यवाद। मेरे पास खास तस्वीरों से भरा एक iPhone 4s है, लेकिन किसी तरह PIN भूल गया और अब कई सालों से इंतज़ार की स्थिति में है
  अगर तस्वीरें न होतीं तो बस reset कर देता, लेकिन सोच रहा हूँ कि क्या इससे PIN reset करके तस्वीरें copy की जा सकती हैं

  • शायद मुश्किल होगा। [0] के अनुसार passcode का इस्तेमाल filesystem encryption key की सुरक्षा के लिए होता है, इसलिए passcode के बिना files decrypt नहीं की जा सकतीं। मुझे नहीं पता कि photos encrypted रूप में store होती हैं या नहीं, लेकिन शायद ऐसा मानना सही होगा
    संशोधन: मैं गलत भी हो सकता हूँ। [0] में यह भी लिखा है कि कुछ समय तक केवल Mail storage encrypted था और default iOS 7 में बदला। इसलिए अगर iPhone पर iOS <= 6 है, तो इस तरीके से device access करके photos copy किए जा सक सकते हैं। [1] का tool मददगार हो सकता है
    [1] https://code.google.com/archive/p/iphone-dataprotection/
    [0] https://darthnull.org/ios-encryption/

• सच में अच्छा लेख था। हालांकि पुराने iOS interface में skeuomorphic design की शान साफ़ दिखने वाला हिस्सा देखकर मन खिन्न हो गया। John Ive से मुझे कितनी चिढ़ है, यह फिर महसूस हुआ

  • तुम्हारा मतलब उस दौर से है जब buttons सचमुच clickable buttons जैसे दिखते थे? आज की तरह नहीं, जहाँ बेहद खराब flat design की कमियों से बचने के लिए आखिरकार accessibility features जोड़ने पड़े
    शायद Jony को software संभालने के बजाय razor जैसे तेज़ aluminum wrist rests ही design करते रहना चाहिए था
  • मेरे हिसाब से iPhone ने iPhone 4 और iOS 4 पर अपनी peak हासिल की थी। उसके बाद भी incremental improvements हुए, लेकिन आखिरी बार जब नया iPhone सच में बड़ा upgrade लगा, वह वही समय था। antenna gate को छोड़ दें, तो hardware और software design दोनों बस सही तरह से फिट बैठते थे

• शुरुआत के कुछ हिस्से बहुत मज़े से पढ़े। इस नज़रिए से follow करना शानदार है। मैं भी यह समझने के लिए source code बहुत पढ़ता हूँ कि दूसरे लोग exploits जैसी चीज़ें कैसे implement करते हैं, और यह जानकर अच्छा लगा कि बाकी लोग भी ऐसा करते हैं

• अभी पढ़ा नहीं है, लेकिन उत्सुक हूँ। शुरुआत में listed सारे tweaks मैंने इस्तेमाल किए हैं, और बस यह कहना चाहता था कि उन्हें बनाने के लिए धन्यवाद। शुरुआती iOS jailbreaking सच में बहुत मज़ेदार थी

• बहुत अच्छा था। चलाकर देखने की कोशिश की, लेकिन अफसोस कि मेरा पुराना device शुरू से ही boot नहीं हो रहा था
  मैंने भी उस समय tweaks बनाए थे और jailbreak को black magic जैसा महसूस करता था। यह लेख पढ़ने के बाद भी कुछ हद तक अब भी वैसा ही लगता है

• इसे इस तरह व्यवस्थित करके लिखने के लिए बहुत धन्यवाद। ऐसी चीज़ें सीखने में मेरी बहुत रुचि है। खासकर dafang-hacks की तरह सस्ते Wi-Fi security cameras को अपने custom firmware से “मुक्त” करना, या Kindle Fire tablet को root करने के लिए नया exploit बनाना सीखना चाहता हूँ
  लेकिन हैरानी की बात है कि इस प्रक्रिया को विस्तार से समझाने वाले लेख ढूँढना बहुत मुश्किल है