📬 ✖️ 📲 Xbox 360 की सुरक्षा और हैकिंग (भाग 1) ♥️ 👩🏼‍🔧 💭

आपने शायद Xbox 360 गेम कंसोल के बारे में सुना है, और यह "चमकती" है। "फर्मवेयर" द्वारा यहां गेम और मालिकाना सॉफ्टवेयर की प्रतियां लॉन्च करने के लिए अंतर्निहित सुरक्षा तंत्र का एक बाईपास है। और यहाँ सवाल उठते हैं! क्या तंत्र, कैसे वे चारों ओर मिलता है? डेवलपर्स ने क्या किया, उन्होंने इसे कैसे प्राप्त किया? वास्तव में, विषय बहुत व्यापक और दिलचस्प है, खासकर Xbox 360 के लिए - यहां आप सॉफ्टवेयर भेद्यता, हार्डवेयर खामियां और बिल्कुल जादुई जादू पा सकते हैं। दिलचस्प? झांकना! पहले भाग में, हम हाइपरविज़र, ड्राइव और फ़र्मवेयर से परिचित हैं ...

विषय से मिलते हैं

Xbox 360 गेम कंसोल 2005 में जारी किया गया था और तब से लोहे की विशेषताओं में बदलाव नहीं आया है। हर समय यह जारी किया गया था, वे एक ही थे:

3.2 गीगाहर्ट्ज़ पावरपीसी सीपीयू, / 3 कोर
500 मेगाहर्ट्ज जीपीयू
512 एमबी रैम
SATA DVD-ROM
SATA HDD (वैकल्पिक)

हां, समय के साथ डिजाइन में बदलाव आया, नैनोमीटर घटे:

फिर भी, सभी खेलों ने शान्ति के सभी "संशोधनों" पर समान रूप से अच्छी तरह से काम किया - यह ठीक यही स्थिति है जब आधुनिक खेलों को 2005 के उपकरणों पर चलाया जा सकता है।

रिलीज़ के समय, एक ज़ोरदार बयान दिया गया था कि कंसोल को यथासंभव सुरक्षित रूप से विकसित किया गया था - हार्डवेयर स्तर पर सुरक्षा के साथ कस्टम चिप्स, और सामान्य तौर पर, हैकर्स ने इसे अभी तक नहीं देखा है:

इस बॉक्स में सुरक्षा के स्तर हैं जो हैकर समुदाय ने पहले कभी नहीं देखे हैं

डेवलपर्स के साथ क्या हुआ?

सबसे पहले , उन्होंने सब कुछ किया ताकि सिस्टम का प्रोग्राम कोड प्राप्त न किया जा सके । एक 32 केबी रॉम जिसमें एक प्राथमिक लोडर (1 बीएल) और एक 64 केबी एसआरएएम जिसमें इसे निष्पादित किया गया था, केंद्रीय प्रोसेसर में बनाया गया था। CPU चिप से ROM की सामग्री प्राप्त करना बहुत मुश्किल है:

दूसरे , विशेष फ़्यूज़ को एक ही प्रोसेसर में डाल दिया गया था - बर्न (शाब्दिक रूप से, उच्च वोल्टेज) कूदने वाले, एक बार प्रोग्राम करने योग्य मेमोरी। फ़्यूज़ में शामिल हैं:

JTAG इंटरफ़ेस लॉक बिट्स
उपसर्ग के उद्देश्य को निर्धारित करने वाले बिट्स (खुदरा / देवकिट / टेस्टकिट)
अद्वितीय 128-बिट प्रोसेसर कुंजी
डाउन-डाउन मान (LDV) डाउनग्रेड को अक्षम करने के लिए काउंटर

हां, संलयन की मात्रा सीमित है। यदि आप लगातार 80 बार अपने कंसोल को अपडेट करने का प्रबंधन करते हैं, तो सीएफएलडीवी काउंटर समाप्त हो जाएगा और ... मुझे नहीं पता, मैंने ऐसा करने की कोशिश नहीं की है। शायद, उपसर्ग अब अपडेट नहीं किया जाएगा।

तीसरा , डेवलपर्स ने विश्वास की एक श्रृंखला को लागू किया है । बूटलोडर्स की प्रामाणिकता को सत्यापित करने के लिए, आधुनिक (उस समय) SHA-1 और RSA-2048 एल्गोरिदम का एक संयोजन उपयोग किया गया था, जिसने आपके स्वयं के कोड या बूटलोडर्स के अनधिकृत संशोधन को शुरू करने की संभावना को बाहर कर दिया था यदि आपको किसी तरह कंसोल से सभी चाबियाँ मिलीं और सिस्टम को फिर से बनाने में सक्षम थे। ।

चौथा , डेवलपर्स ने "किसी पर भरोसा न करें" के सिद्धांत पर आगे बढ़ने का फैसला किया और रैम को उसी दुर्भाग्यपूर्ण सीपीयू में बचाने के लिए एक विशेष हार्डवेयर मॉड्यूल रखा ! इसकी मदद से, प्रोग्राम कोड वाले सभी क्षेत्रों को एन्क्रिप्ट किया गया था, और अखंडता निगरानी को सबसे महत्वपूर्ण क्षेत्रों (हाइपरविजर) के लिए चालू किया गया था!

ऐसा करने से, डेवलपर्स ने डीएमए हमलों के खिलाफ खुद का बचाव किया, जब बाहरी उपकरणों के माध्यम से जिनकी रैम तक पहुंच होती है, वे रैम में सिस्टम प्रोग्राम कोड को संशोधित करते हैं।

अंत में , हाइपरविजर ने मेमोरी क्षेत्रों में अधिकारों के भेदभाव से निपटा । केवल वह पृष्ठों को निष्पादन योग्य बना सकता है, निश्चित रूप से, इससे पहले कि उसने डिजिटल हस्ताक्षर की जाँच की थी, इसलिए अहस्ताक्षरित कोड को डाउनलोड करना या कुछ ड्राइवर या गेम में भेद्यता के माध्यम से डेटा क्षेत्र से कुछ निष्पादित करना असंभव था (अक्ष और गेम को कास्ट अधिकारों के साथ लॉन्च किया गया था) ।

नतीजतन, Xbox 360 ऑपरेटिंग सिस्टम को अच्छी तरह से संरक्षित किया गया था, और इसलिए, डीवीडी-रॉम को पहले हमले वेक्टर के रूप में चुना गया था।

हम शुरू करते हैं ... बैकअप!

Xbox 360 में, एक दोहरी परत वाली डीवीडी को खेलों के लिए मुख्य मीडिया के रूप में चुना गया था। स्वाभाविक रूप से, रक्षा तंत्र भी यहां मौजूद थे:

DVD-ROM के साथ डेटा विनिमय एक अद्वितीय कुंजी के साथ एन्क्रिप्ट किया गया था
डिस्क की शुरुआत में लाइसेंसिंग की पुष्टि करने के लिए विशेष "सुरक्षा क्षेत्र" थे
डिस्क पर निष्पादन योग्य फ़ाइलों को डिजिटल रूप से हस्ताक्षरित किया गया था

लेकिन मुख्य प्रणाली की तुलना में डीवीडी ड्राइव की सुरक्षा पर बहुत कम ध्यान दिया गया था। गेम कंसोल ने डीवीडी ड्राइव पर बहुत अधिक विश्वास दिखाया - यह डीवीडी-रॉम था जिसने डिस्क के लाइसेंस का निर्धारण किया। इसके अलावा, फर्मवेयर को बाहरी मेमोरी में संग्रहीत किया गया था और प्रोग्रामर द्वारा पढ़ा जा सकता है:

परिणामस्वरूप, 14 मई, 2006 को, कमोडोर 4eva (c4eva) ने TS-H943 मॉडल को चलाने के लिए पहला संशोधित फर्मवेयर जारी किया:

फर्मवेयर रिलीज के लिए README

— Xtreme firmware for TS-H943 Xbox 360
— Here it is, the long awaited World first Xbox 360 backup firmware modification to boot all game backups!

Features
— Boots all Xtreme Xbox 360 backups
Boots all Xtreme Xbox 1 backups
Boots all Xbox 360 originals
Boots all Xbox 1 originals on Xbox 360
Xtreme0800 extraction firmware enables drive to function natively under Windows without any hardware conversion/adaptors
Use on Xbox Live at own risk

Technical details
— Reads Xbox 360 security sector from PSN 04FB1F (Layer 0)
Reads Xbox 1 security sector from PSN 605FF (Layer 0)
Security sector must be extrated using Xtreme0800 360 firmware for Xbox360 games and Xbox 1 games
Will not boot Xbox 1 backups made with Xbox1 605b 0800 firmware (maybe in future release)

फर्मवेयर ने एक डीवीडी डिस्क पर निश्चित क्षेत्रों से सुरक्षा क्षेत्रों को पढ़ा और कंसोल को धोखा दिया, जिससे यह लगता है कि एक लाइसेंस प्राप्त डिस्क डाली गई थी।

उसी समय, 0800 फर्मवेयर जारी किया गया था, जिसे गेम की प्रतियां बनाने और सुरक्षा क्षेत्रों को पढ़ने के लिए डिज़ाइन किया गया था। Xbox 360 ड्राइव, इस तरह के फर्मवेयर के साथ फ्लैश किया गया था, कंप्यूटर पर पता लगाया गया था और गेम डिस्क के क्षेत्रों को पूरी तरह से पढ़ सकता था।

0800 फर्मवेयर का उपयोग करने पर README

Extracting Security Sector
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following four custom cdb commands:

AD 00 FF 02 FD FF FE 00 08 00 01 C0
AD 00 FF 02 FD FF FE 00 08 00 03 C0
AD 00 FF 02 FD FF FE 00 08 00 05 C0
AD 00 FF 02 FD FF FE 00 08 00 07 C0

Then save hexadecimal display as bin file as SS.bin

Creating a game backup
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Extract Isobuilder.rar
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following custom cdb command to unlock drive: (game data visable)

FF 08 01 01

Run Isobuster
Right click on DVD and select Extract From-To
Click Length and enter number of LBAs as follows:

Xbox 1 Original Number of LBA to read 3431264 decimal
or
Xbox 360 Original Number of LBA to read 3567872 decimal
Select User Data (2048 bytes/block)
Click Start Extraction
Enter filename as game.iso and click Save
Upon read error dialogue box choose fill with blank zeros for sector and select use this selection for all errors
Copy game.iso and ss.bin to the relevent isobuilder directory (Depending on Xbox 360 or Xbox 1 game)
Run build360.bat (Xbox 360 game) or build.bat (xbox 1 game)
Ensure your burner will set the booktype of DVD+R DL to DVDRom
Burn with CloneCd and choose the image.dvd file

एक अन्य गेम को आंशिक रूप से निम्नलिखित चाल के साथ कॉपी किया जा सकता है:

एक कंप्यूटर में रखा डीवीडी- ROM साधारण दो-परत डिस्क
रुको जब तक यह शांत न हो जाए और कताई बंद हो जाए
एक पेपर क्लिप के साथ, ट्रे खोलें और Xbox 360 से ड्राइव को गेम में बदलें
ट्रे को बंद करें और एक डिस्क छवि बनाएं!

(यह सभी डीवीडी-रॉम मॉडल पर काम नहीं करता था)

सबसे महत्वपूर्ण बात यह है कि ड्राइव विशेष एटीए कमांड के साथ सॉफ्टवेयर द्वारा विशेष रूप से फ्लैश किया गया था। किट में मूल फर्मवेयर पढ़ने और संशोधित लिखने के लिए एक विशेष कार्यक्रम शामिल था। मूल फर्मवेयर में, क़ीमती कुंजी संग्रहीत की गई थी, जिसके साथ ड्राइव को Xbox 360 से जोड़ा गया था:

कुंजी के नुकसान का मतलब है कि लाइसेंस प्राप्त डिस्क भी लॉन्च नहीं किया जा सकता है, इसलिए कुछ ने नोटबुक में कुंजी लिखी, जहां भी संभव हो, इसे बचाया, यह सबसे पोषित ज्ञान था।

ऑनलाइन गेम के बारे में एक अलग विषय आतंक था। हर कोई डरता था कि माइक्रोसॉफ्ट को पता चलेगा कि ड्राइव को संशोधित किया गया था और कंसोल को दूरस्थ रूप से अक्षम कर दिया गया था। कुछ ने कारखाने और संशोधित फर्मवेयर के बीच स्विच करने के लिए एक हार्डवेयर मोड भी बनाया है:

उन्होंने मूल फर्मवेयर "लाइसेंस में" खेला और, नेटवर्क से कनेक्शन के साथ, शर्मनाक तरीके से उन्हें संशोधित इंटरनेट केबल पर डिस्कनेक्ट कर दिया। वैसे, आतंक व्यर्थ नहीं था, लेकिन ऐसे मॉड पूरी तरह से व्यर्थ थे, नेटवर्क से कनेक्ट किए बिना सब कुछ लॉग किया गया था।

ठीक एक महीने बाद (15 जून, 2006) फर्मवेयर को दूसरे ड्राइव मॉडल पर पोर्ट किया गया, जो उस समय Xbox 360 में स्थापित किया गया था - हिताची GDR3120L। उनके पास एक बाहरी फ्लैश ड्राइव भी थी जिसमें फर्मवेयर था:

इस ड्राइव को बेहतर तरीके से संरक्षित किया गया था:

फर्मवेयर को रॉम में एन्क्रिप्टेड रूप में संग्रहीत किया गया था
फर्मवेयर में अखंडता नियंत्रण था
फर्मवेयर को अधिलेखित करने के लिए, आपको एक विशेष "मोड बी" में जाना होगा

और अगर शोधकर्ताओं ने पहले दो बिंदुओं को स्वयं प्रबंधित किया, तो "मोड बी" में अनुवाद की उपलब्धि सभी ~~युवा~~ फ़्लैशर्स द्वारा दोहराई जानी थी ।

इस कार्रवाई को स्लैक्स लिनक्स के साथ एक विशेष बूट डिस्क का उपयोग करके, या स्टार्टअप पर तारों को छोटा करके प्रस्तावित किया गया था। ड्राइव पावर कनेक्टर के संपर्कों 0 और 9 को शॉर्ट-सर्किट करना आवश्यक था। उदाहरण के लिए, पिन के साथ!

दोनों मामलों में, इस तरह के दुर्व्यवहार के बाद, ड्राइव को विंडोज में एक नियमित डीवीडी-ड्राइव के रूप में परिभाषित किया गया था, जहां इसे उठाया गया था और ~~बलात्कार~~ और सिलाई की गई थी।

पहली रिलीज के बाद, कस्टम फ़र्मवारों को अंतिम रूप दिया गया था, स्थिरता में सुधार किया गया था, नए खेलों के लिए समर्थन जोड़ा गया था, सामान्य तौर पर, सब कुछ हमेशा की तरह था।

Microsoft जवाब

डेवलपर्स का आरोप है कि "अटूट" कंसोल को हैक कर लिया गया था, बस इसका जवाब दिया गया था:

सिस्टम को हैक नहीं किया गया था, हमने सिर्फ गेम की प्रतियां लॉन्च करने का तरीका सीखा, हम इस पर काम कर रहे हैं

मूल उत्तर

The core security system has not been broken. However, it is reported that the authentication protocol between the optical disc drive and the console may be attacked, which if accurate could allow people to play illegally copied games. Our security team is aware of this and we are investigating potential solutions to this issue. The Xbox 360 platform was designed to be updated, and we are prepared to respond appropriately should any unauthorized activity be identified.

वास्तव में स्थिति को ठीक करने के लिए क्या किया गया था:

सैमसंग टीएस-एच 943 ने एमएस 28 फर्मवेयर के साथ आना शुरू किया, जिसने प्रसिद्ध एटीए कमांड द्वारा फर्मवेयर मोड में प्रवेश नहीं किया
हिताची जीडीआर 3120 एल फर्मवेयर 0078 और 0079 के साथ दिखाई दी, मोड बी में भी चमकती नहीं
नई BenQ-LiteOn VAD6038 अपील दिखाई देती है
Xbox Live पर समुद्री डाकू का पहला नुकीला "प्रतिबंध" शुरू हुआ, समुद्री डाकू को हमेशा के लिए ऑनलाइन खेलने के लिए मना किया गया था

यदि प्रतिबंध के साथ सब कुछ अस्पष्ट और अपूरणीय था (उस समय में), तो शोधकर्ताओं ने जल्द ही ड्राइव का पता लगा लिया:

हिताची के लिए एक विशेष ऑडियो डिस्क के माध्यम से फर्मवेयर मोड को अनलॉक करना पाया गया
सैमसंग ms28 और BenQ VAD6038 सस्ते SATA VIA 6421 नियंत्रकों के माध्यम से फर्मवेयर मोड में पूरी तरह से चले गए

चलो थोड़ी देर के लिए ड्राइव फ़र्मवेयर के लिए युद्ध के मैदान को छोड़ दें, एक बहुत ही दिलचस्प अवधि नहीं थी जब शोधकर्ताओं ने "चुपके" फर्मवेयर बनाने की कोशिश की, ताकि Xbox Live पर प्रतिबंध न लगाया जाए, नए "तरंगों" के साथ नए गेम में समायोजित करें - सिस्टम अपडेट संस्करण और सब कुछ के लिए परिणामों को पोर्ट करें फर्मवेयर और ड्राइव की एक विस्तृत विविधता। सभी समान, सब कुछ सिले हुए थे, "बैकअप" सफलतापूर्वक लॉन्च किए गए थे, Xbox 360 लोगों के बीच लोकप्रियता हासिल कर रहा था ...

धुरी को तोड़ना!

जैसा कि आप कहानी के पहले भाग से याद करते हैं, Xbox 360 सिस्टम में एक हाइपरविजर था जो सब कुछ और सब कुछ नियंत्रित करता था। अच्छा यहाँ। सिस्टम के एक संस्करण में, एक भेद्यता अचानक उसमें दिखाई दी! शोधकर्ताओं ने हाइपर्वाइजर कोड के नमूने कैसे प्राप्त किए, यह मुझे निश्चित रूप से ज्ञात नहीं है। लेकिन तथ्य यह है - 2006 के अंत में, शोधकर्ताओं ने Xbox 360 पर अहस्ताक्षरित कोड लॉन्च किया, और 2007 की शुरुआत में डेवलपर्स द्वारा भेद्यता तय की गई थी:

Timeline:
Oct 31, 2006 — release of 4532 kernel, which is the first version containing the bug
Nov 16, 2006 — proof of concept completed; unsigned code running in hypervisor context
Nov 30, 2006 — release of 4548 kernel, bug still not fixed
Dec 15, 2006 — first attempt to contact vendor to report bug
Dec 30, 2006 — public demonstration
Jan 03, 2007 — vendor contact established, full details disclosed
Jan 09, 2007 — vendor releases patch
Feb 28, 2007 — full public release

हाइपरविजर की एक विशेषता थी - बाकी कोड के विपरीत, इसे वर्चुअल एड्रेस स्पेस में नहीं, बल्कि फिजिकल (रियल मोड) में निष्पादित किया गया था। प्रसारण का उपयोग नहीं किया गया था, कॉल सीधे किए गए थे (प्रपत्र 0x00000000'xxxxxx के पते)। या तो यह गति के लिए किया गया था, या सरलता के लिए ... और यहां Xbox 360 एड्रेस स्पेस की एक विशेषता थी।

मेमोरी का एक्सेस मोड इसके भौतिक पते द्वारा निर्धारित किया गया था। अर्थात्, पते के सबसे महत्वपूर्ण बिट्स का एक आधिकारिक उद्देश्य था। उदाहरण के लिए, पता 0x00000 0 00'0000201C का मतलब पते की सीधी पहुँच 0x201C है, और 0x00000 1 00'0000201C का मतलब है कि आपको उसी भौतिक पते 0x201C को पढ़ते समय मक्खी पर अखंडता को डिक्रिप्ट और सत्यापित करना होगा।

तदनुसार, एन्क्रिप्शन और सुरक्षा सक्षम करने के लिए निष्पादन के लिए, आपको 0x00000 1 00'xxxxxxxx जैसे पतों का उल्लेख करना होगा। तभी हार्डवेयर मॉड्यूल में सुरक्षात्मक तंत्र शामिल थे। इसलिए, हार्डवेयर स्तर पर, वांछित बिट स्वचालित रूप से जोड़ा गया था (इसके लिए विशेष HRMOR रजिस्टर जिम्मेदार था - हाइपरवाइजर रियल मोड ऑफ़सेट रजिस्टर)!

एक बार फिर - जैसे ही हाइपरवाइजर 0x00000 0 00'xxxxxxxx जैसे एड्रेस को एक्सेस करता है , MMU अपने आप ही इस एड्रेस को 0x00000 1 00'xxxxxxxx में बदल देता है, जिसमें एन्क्रिप्शन और प्रोटेक्शन शामिल हैं! तो भौतिक स्मृति से, सुरक्षा और एन्क्रिप्शन के बिना, "सीधे" कोड को निष्पादित करने का कोई भी प्रयास विफलता के लिए बर्बाद होता है ... या नहीं?

आइए हाइपरविजर संस्करण 4532 के असुरक्षित कोड को देखें:

// %r0 – 13D8: cmplwi %r0, 0x61 // ID 13DC: bge illegal_syscall // 0x61, , ... 13F0: rldicr %r1, %r0, 2, 61 // 4 13F4: lwz %r4, syscall_table(%r1) // 13F8: mtlr %r4 // lr ... 1414: blrl //

गोफर देखें? पर वह है! Cmplwi निर्देश 32-बिट मान के साथ काम करता है , लेकिन rldicr - 64-बिट के साथ ! यही है, हम एक सिस्टम कॉल नंबर के रूप में मान 0x20000000'0000002A दे सकते हैं, यह परीक्षण पास करेगा (क्योंकि निचला 32-बिट हिस्सा 0x61 से कम है), और परिणामस्वरूप, 0x10EC, पते के बजाय हैंडलर का पता 0x80000000'000010EC से लिया जाएगा!

और फिर, जैसा कि वे कहते हैं, अपने हाथों को देखें। पते के सबसे महत्वपूर्ण बिट्स शून्य के बराबर नहीं हैं, क्रमशः, HRMOR नहीं जोड़ा गया है ! और चूंकि वास्तविक पता स्थान 32-बिट है, इसलिए हमारे द्वारा निर्धारित 63-बिट को केवल अनदेखा कर दिया जाता है। हमने हाइपरविजर को अनएन्क्रिप्टेड और असुरक्षित मेमोरी पर पुनर्निर्देशित किया, बस एक गलत सिस्टम कॉल नंबर सबमिट करके!

लेकिन प्रतीक्षा करें, ताकि जहां कूदना है, हमें भौतिक मेमोरी में अपना डेटा लिखने में सक्षम होने की आवश्यकता है। इसे कैसे प्राप्त किया जाए?

यह वह जगह है जहां दूसरा कारक खेल में आता है - Xbox 360 पर GPU स्मार्ट था, यहां तक कि बहुत स्मार्ट भी । उन्होंने भौतिक स्मृति में ज्यामिति डेटा अपलोड करने के लिए एक विशेष shader निर्देश, MemExport का समर्थन किया। यही है, आप shader संकलित कर सकते हैं, इसे GPU पर निष्पादित कर सकते हैं और इस प्रकार कहीं भी कुछ भी रिकॉर्ड कर सकते हैं! और सबसे महत्वपूर्ण बात, शेडर्स पर हस्ताक्षर नहीं किए गए थे, यदि आप किसी भी तरह से गेम डिस्क को संशोधित करते हैं, तो आप आसानी से शेडर कोड को बदल सकते हैं।

एक सवाल रह गया। गेम डिस्क पर shader कोड कैसे बदलें? और यहाँ कंसोल के डीवीडी ड्राइव को हैक करना बहुत उपयोगी था। हमने एक शेडर लिखा, इसे खेल की छवि में बदल दिया, इसे डिस्क पर रिकॉर्ड किया और लिनक्स लॉन्च किया!

हां, इसे चलाने के लिए, मुझे हर बार खेल शुरू करना पड़ा, काम करने के लिए प्रतीक्षा करें, लिनक्स के साथ बूट डिस्क डालें, लेकिन यह कम से कम कुछ था!

जैसा कि पहले ही उल्लेख किया गया है, Microsoft ने एक सिस्टम अपडेट जारी किया जिसमें उन्होंने हाइपरवाइज़र की भेद्यता को निर्धारित किया। लेकिन क्या होगा अगर आप एक कमजोर कर्नेल लौटाते हैं?

डाउनग्रेड!

सामान्य तौर पर, Xbox 360 के आर्किटेक्चर को डाउनग्रेड से सुरक्षा तंत्र रखा गया था। प्रोसेसर के हार्डवेयर फ़्यूज़ में, हर बार अपडेट (लॉक डाउन वैल्यू, एलडीवी में वृद्धि) के दौरान थोड़ा सा जला दिया गया था, और अगर यह एलडीवी फ़्यूज़ और सिस्टम में मेल नहीं खाता, तो कंसोल बस शुरू नहीं हुआ।

Xbox 360 बूटलोडर संरचना पर विचार करें, अर्थात्, "बूटलोडर अनुभाग":

यह देखा जा सकता है कि छवि में बूटलोडर्स के कई सेट हैं, जिनमें से प्रत्येक कुछ एलडीवी से मेल खाता है। उदाहरण में, ये हैं 1888 LDV 0, के लिए 16,767 LDV 3 के लिए और 16,756 LDV 2 के लिए

तो, सिस्टम में ही वर्गों 6BL / 7BL में दर्ज की गई और बस रहे थे की सभी अद्यतन आधार "मूल" 5BL को पैच के रूप में "लागू किया" 1888 । लेकिन क्या लागू करने के लिए पैच का एक सेट फ़्यूज़ और बूटलोडर हेडर में निर्धारित एलडीवी के अनुसार चुना गया था! और सिर्फ 5BL पर हैडर को संशोधित किया जा सकता है, लेकिन एक बड़ी BUT के साथ - हेडर को HMAC-SHA-1 हैश राशि में दर्ज किया गया था। और यह साधारण मेमचैंप द्वारा जांचा गया था ।

यदि आपको अभी भी समझ में नहीं आ रहा है कि चीजें कहां जा रही हैं, तो यहां आप टाइम अटैक (टाइमिंग अटैक) लागू करने में सफल रहे। पहली विसंगति के तुरंत बाद मानक मेम्कंप फ़ंक्शन तुलना को पूरा करता है। इसलिए, हैश के पहले बाइट को बदलकर और मेमकैंप के रनटाइम का पता लगाकर, आप वांछित मान का चयन कर सकते हैं (सत्यापन समय इसके साथ बढ़ जाएगा)। आगे जारी रखते हुए, आप हैश राशि के सभी बाइट्स उठा सकते हैं!

माप के लिए, POST_OUT डिबग बस का उपयोग किया गया था। यह एक पीसी की तरह काम करता है, लोडिंग के अलग-अलग समय में एक-बाइट मान प्रदर्शित किया जाता है, जिसके द्वारा आप अनुमान लगा सकते हैं कि प्रोसेसर वर्तमान में कहां चल रहा है और क्या त्रुटि हुई। वास्तव में, ये मदरबोर्ड पर 8 बिंदु हैं, जिनमें से प्रत्येक एक विशिष्ट बिट मान के लिए जिम्मेदार है:

इन बिंदुओं को हल करने के बाद, आप बस डाउनलोड चरणों में से प्रत्येक के निष्पादन समय को माप सकते हैं और देख सकते हैं कि क्या कोई त्रुटि हुई है।

हैश चयन की पूरी प्रक्रिया में लगभग एक घंटे का समय लगता है:

नतीजतन, हमें एक छवि मिलती है जिसमें कोर कर्नेल के लिए वर्तमान एलडीवी स्थापित होता है, जिसके कारण कोई पैच लागू नहीं होता है और 1888 सिस्टम का सबसे पुराना संस्करण लॉन्च किया जाता है! जहां से पहले से ही कमजोर संस्करण 4532 में अपग्रेड करना संभव है:

बेशक, Microsoft ने इस भेद्यता को पहले अपडेट किए गए बूटलोडर (2BL, "CB") को अपडेट करके और CBLDV फ्यूज को जलाकर ठीक कर दिया, जिससे फिर से असंभव हो गया। अब memcmp के बजाय, इसके सुरक्षित संस्करण का उपयोग किया गया था, इनपुट मानों की परवाह किए बिना समान रनटाइम के साथ।

JTAG हैक!

लेकिन यहां, शोधकर्ताओं ने हार नहीं मानी और एक बचाव का रास्ता खोज लिया। हां, ऐसे कि डेवलपर्स कल्पना भी नहीं कर सकते थे।

कंसोल के संचालन के सामान्य मोड में, सभी बूटलोडर एक श्रृंखला में एक दूसरे से जुड़े होते हैं। नतीजतन, प्रत्येक बूटलोडर का डिक्रिप्शन पिछले बूट लोडर (पेयरिंग डेटा) के हेडर में डेटा क्षेत्र पर निर्भर करता है। इसके अतिरिक्त, कोड का एन्क्रिप्शन अद्वितीय प्रोसेसर कुंजी पर निर्भर करता है, इसलिए आप CPU_Key को जाने बिना एक कार्यशील छवि को नहीं ले सकते और इकट्ठा नहीं कर सकते हैं। या यह संभव है?

कंसोल प्रोडक्शन स्टेज पर (जब प्रोसेसर कुंजी को अभी तक फ़्यूज़ में नहीं जलाया गया है), एक विशेष Xbox 360 लॉन्च मोड का उपयोग तब किया जाता है जब पेयरिंग डेटा शून्य (जीरो-पेयरिंग) होता है। और ऐसी छवि (एक कमजोर गिरी के साथ!) प्रोसेसर कुंजी को जानने के बिना किसी भी कंसोल पर चलाया जा सकता है!
दुर्भाग्य से, कोई पूर्ण लॉन्च नहीं होगा, यह त्रुटि यहां समाप्त हो जाएगी:

यही है, किंग कांग खेल शुरू नहीं किया जा सकता है, shaders के माध्यम से शोषण को सक्रिय नहीं किया जा सकता है ... लेकिन कमजोर कर्नेल पहले से ही शुरू हो रहा है! शायद रैम को रिकॉर्ड करने का एक और तरीका है? यह पता चला कि वहाँ है।

शुरुआत के लिए, हम GPU JTAG पिन के कंसोल के दक्षिण कंसोल के तीन मुफ्त GPIO मिलाप करते हैं:

फिर हम दक्षिण पुल के फर्मवेयर को संशोधित करते हैं (यह एन्क्रिप्ट किया गया है, लेकिन हस्ताक्षरित नहीं है) और कमजोर कर्नेल के साथ छवि एकत्र करें। फिर जादू होता है:

स्टार्टअप पर, JTAG GPU पर दक्षिण पुल PCI एक्सप्रेस पर चढ़ता है और NAND नियंत्रक को कॉन्फ़िगर करता है
अब, पढ़ते समय, एनएएनडी नियंत्रक को उस मेमोरी क्षेत्र में डेटा लिखना होगा जो हमें चाहिए
सिस्टम का कोर शुरू होता है और सिस्टम को शुरू होने वाले दक्षिण पुल को सूचित करता है
दक्षिण पुल NAND कंट्रोलर को खींचता है, रैम को सही जगह पर ओवरराइट करता है और हाइपरवाइज़र की भेद्यता का फायदा उठाता है!
नियंत्रण हमारे कोड में स्थानांतरित कर दिया जाता है, जो हम चाहते हैं

संक्षेप में, उन्होंने किंग कांग शेडर एक्सप्लॉइट में सब कुछ वैसा ही किया, लेकिन कूलर - खेल शुरू करने और डिस्क बदलने की कोई आवश्यकता नहीं है।

JTAG हैक के आधार पर, सिस्टम के संशोधित संस्करण बनाए गए थे - XBReboot, Freeboot, विकलांग हस्ताक्षर सत्यापन के साथ, जहां समुद्री डाकू पहले से ही घूम रहे थे। खेलों को न केवल यूएसबी ड्राइव और डिस्क से लॉन्च किया जा सकता है, बल्कि एक कंप्यूटर से सीधे एसएमबी प्रोटोकॉल के माध्यम से भी लॉन्च किया जा सकता है।

महत्वपूर्ण रूप से, एक पूर्ण-प्रणाली वाले सिस्टम हैक ने उन लोगों को मौका दिया जो डीवीडी कुंजी खो चुके थे और खेल नहीं सकते थे - प्रोसेसर कुंजी होने के कारण, डीवीडी कुंजी को निकालना मुश्किल नहीं था।

बेशक, यहां Microsoft ने जल्दी से भेद्यता को बंद कर दिया, फिर से 2BL को अपडेट किया और CBLDV का मान बढ़ाया। इस पर, कमजोर हाइपरविजर का महाकाव्य समाप्त हो गया, लोग दुकानों में "JTAG संगत" कंसोल के अवशेष खरीदने के लिए दौड़े - हर कोई बिना किसी समस्या के यूएसबी फ्लैश ड्राइव के साथ खेलना चाहता था। फ़ोरम पर चर्चाएं हुईं कि कौन सी बंडलों के साथ रिलीज़ की तारीख हैकिंग के लिए उपयुक्त है ...

Xbox 360 सिस्टम में संशोधनों का विषय लगभग दो साल तक रुका रहा, लेकिन फ़र्मवेयर का विषय विकसित होना जारी रहा। और बस लाइटऑन ड्राइव के फर्मवेयर में, शोधकर्ताओं और माइक्रोसॉफ्ट के बीच सबसे व्यापक लड़ाई हुई। लेकिन अगले लेख में उस पर अधिक :)

लिंक:

GoogleTechTalks रिपोर्ट
King Kong Hack
Timing Attack
JTAG / SMC हैक

Xbox 360 प्रोटेक्शन एंड हैकिंग, पार्ट 1 Xbox 360
प्रोटेक्शन एंड हैकिंग, पार्ट 2
Xbox 360 प्रोटेक्शन एंड हैकिंग, पार्ट 3

पीएस विवरण में रुचि रखने वाला कोई भी व्यक्ति, मैं टिप्पणियों में विषय पर किसी भी प्रश्न का उत्तर दूंगा!