गैलेक्सी एस II पर हार्ड ब्रिक बग और नोट लीक आईसीएस कर्नेल

click fraud protection

चूंकि सैमसंग गैलेक्सी एस2 लाइन अप के लिए नवीनतम लीक हमें बाएं और दाएं प्रभावित कर रहे हैं, लोग रोम के बीच, मुख्य रूप से छोटी गाड़ी, प्री-रिलीज़ आईसीएस बिल्ड और बहुत स्थिर जीबी के बीच कूद रहे हैं। आख़िरकार, हम एक आदत के रूप में XDA पर यही करते हैं: हम एक रिसाव देखते हैं, हम उसे फ्लैश करते हैं, हम उसका उपयोग करते हैं, और हम उसमें बदलाव करते हैं। यदि यह उड़ता नहीं है, तो हम बस वापस लुढ़क जाते हैं। निःसंदेह, ऐसी चीजों को चमकाने में हमेशा एक अंतर्निहित जोखिम होता है जो पहली बार में आपके डिवाइस पर नहीं होनी चाहिए, लेकिन इस दिन और उम्र में किसी डिवाइस को पूरी तरह से चमकाने का जोखिम काफी कम है। विशेष रूप से, चूँकि आपके डिवाइस को मृत अवस्था से वापस लाने के लिए उपकरण उपलब्ध हैं, जैसे कि अनब्रिकेबल मॉड XDA एलीट मान्यता प्राप्त डेवलपर द्वारा एडमऑउटलर.

इतना कहने के बाद भी, लीक की दुनिया में सब कुछ ठीक नहीं लग रहा है। XDA Elite मान्यता प्राप्त डेवलपर को धन्यवाद एन्ट्रॉपी512, हमने सीखा है कि अधिकांश उपकरण जो लीक प्राप्त कर रहे हैं उनमें फ्लैश के बाद कभी न जागने का बहुत अधिक जोखिम है। यह पता चला है कि लीक हुए आईसीएस कर्नेल में एक बड़ा बग है जो प्रभावित करता है

/data ईएमएमसी चिप में विभाजन, जो पोंछने और चमकाने जैसे कुछ कार्यों के दौरान स्पष्ट रूप से दूषित हो जाता है। मूल रूप से ऐसा माना जाता था कि यह केवल CWM जैसी कस्टम पुनर्प्राप्ति में किए गए कार्यों को प्रभावित कर रहा था। हालाँकि, ऐसी खबरें आई हैं कि चमकती हुई ईंटों से कठोर ईंटें बनाई जा रही हैं स्टॉक वसूली भी। प्रभावित उपकरण हैं:

  • सभी एपिक 4जी टच (एसपीएच-डी710) आईसीएस लीक
  • सभी गैलेक्सी नोट (GT-N7000) आईसीएस लीक
  • एटी एंड टी गैलेक्सी एस II (एसजीएच-आई777) यूसीएलडी3 रिसाव - और संभवतः अन्य सभी
  • कोरियाई SHW-M250S/K/L आधिकारिक रिलीज़ और उनके स्रोत से निर्मित कोई भी कर्नेल

एन्ट्रॉपी और अन्य डेवलपर्स ने पूरी साइट पर बिखरी हुई कई चेतावनियाँ पोस्ट की हैं, जिसमें वे विस्तार से बताते हैं कि क्या हो रहा है। हमारा सुझाव यह है कि उपयोगकर्ताओं को लीक से आईसीएस को चमकाने से तब तक दूर रहना चाहिए जब तक कि कर्नेल में बग पूरी तरह से ठीक नहीं हो जाता, जब तक कि निश्चित रूप से, आप अपने डिवाइस को हार्ड ब्रिक करने पर विचार नहीं कर रहे हों। याद रखें, यह कोई ऐसी चीज़ नहीं है जिसे अनब्रिकेबल मॉड या यहां तक ​​कि JTAG के माध्यम से पुनर्जीवित किया जा सकता है, क्योंकि यह eMMC में एक फर्मवेयर त्रुटि है। यह आपमें से उन लोगों के लिए सीधे एन्ट्रॉपी से है जो थोड़ा और विस्तार में रुचि रखते हैं:

खतरा: कई सैमसंग आईसीएस लीक कर्नेल आपके डिवाइस को नुकसान पहुंचा सकते हैं!

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

जिन गुठली के प्रभावित होने की पुष्टि की गई है वे हैं:

[*]सभी एपिक 4जी टच (एसपीएच-डी710) आईसीएस लीक[*]सभी गैलेक्सी नोट (जीटी-एन7000) आईसीएस लीक[*]एटी एंड टी गैलेक्सी एस II (एसजीएच-आई777) UCLD3 लीक - और संभवतः अन्य सभी[*]कोरियाई SHW-M250S/K/L आधिकारिक रिलीज़ और उनसे निर्मित कोई भी कर्नेल स्रोत

गुठली जो सुरक्षित होनी चाहिए वे हैं:

[*]GT-I9100 ICS लीक[*]GT-I9100 आधिकारिक रिलीज़[*]GT-I9100 अपडेट4 सोर्स बेस से निर्मित कर्नेल

प्रभावित कर्नेल चलाने पर क्षति होने की संभावना वाले ऑपरेशन:

सीडब्लूएम में वाइपिंग (और संभवतः कोई अन्य कस्टम रिकवरी) (पुष्टि)

CWM में नंद्रॉइड बैकअप पुनर्स्थापित करना (पहले वाइप करें)

सीडब्लूएम में एक और फर्मवेयर फ्लैश करना (अधिकांश फ्लैश पहले मिटा दें)

स्टॉक 3ई पुनर्प्राप्ति में वाइपिंग (संदिग्ध, एक विभाजन भी वाइप)

प्रभावित कर्नेल चलाते समय बड़ी फ़ाइलें हटाना (संदिग्ध लेकिन पुष्टि नहीं)

यदि आपके पास प्रभावित कर्नेल है:

ओडिन/हेमडाल का उपयोग करके तुरंत ज्ञात अच्छे कर्नेल को फ्लैश करें। फ़्लैश करने के लिए मोबाइल ओडिन, सीडब्लूएम, या किसी भी ऑन-डिवाइस विधि का उपयोग न करें। ज्ञात अच्छे कर्नेल में शामिल हैं:

[*]लगभग कोई जिंजरब्रेड कर्नेल[*]ICS कर्नेल GT-I9100 अपडेट4 स्रोत कोड से निर्मित

इस समस्या का मूल कारण अभी तक निर्धारित नहीं किया गया है, हालाँकि, XDA में कई मान्यता प्राप्त डेवलपर्स को संदेह है कि यह सैमसंग द्वारा एक सुविधा को सक्षम करने के कारण है प्रभावित कर्नेल, MMC_CAP_ERASE - यह एक प्रदर्शन सुविधा है जो फ्लैश लिखने के प्रदर्शन को काफी बढ़ा सकती है, लेकिन ऐसा प्रतीत होता है कि फ्लैश में एक दोष सामने आ गया है चिपसेट GT-I9100 ICS कर्नेल में यह सुविधा सक्षम नहीं है और सुरक्षित दिखाई देती है। हालाँकि, इस सुविधा के बिना सभी कर्नेल को सुरक्षित घोषित करने के लिए पर्याप्त जानकारी नहीं है - एकमात्र इकाई जो इसके मूल कारण की पुष्टि कर सकती है यह समस्या है और बिना कोई बड़ा जोखिम उठाए (कई डिवाइसों को बिना किसी मरम्मत के नष्ट कर देना) सैमसंग ने इसे ठीक घोषित कर दिया है खुद।

सामान्य तौर पर, अगली सूचना तक, यदि आप GT-I9100 के अलावा किसी अन्य Exynos-आधारित डिवाइस के लिए सैमसंग ICS लीक चला रहे हैं, तो कुछ और फ्लैश करने की दृढ़ता से सलाह दी जाती है।

और यह आज सुबह ही हमारे मंचों पर भी दिखाई दिया, XDA सदस्य के सौजन्य से गारविन. जाहिर है, Google से संपर्क किया गया है और वे इस मुद्दे से अवगत हैं, और एक इंजीनियर इसे ठीक करने की दिशा में काम करने की उम्मीद कर रहा है।

खैर, कुछ समय हो गया है लेकिन शुक्र है कि एंड्रॉइड से श्री सुमरॉल हमारे प्रश्नों पर वापस आए। मुझे लगता है कि समुदाय को पता चलेगा कि यह इंतजार के लायक था।समस्या: fwrev ठीक से सेट नहीं है।जैसा कि हमें संदेह था कि बगफिक्स हमारे निर्माण में नहीं है। (पैच इसे बिना शर्त लागू करता है।)

उद्धरण:

मूलतः द्वारा पोस्ट किया गया केन सुमरॉल

पैच में सीआईडी ​​रजिस्टर से राइट बिट्स के लिए mmc.c सेटिंग fwrev में एक लाइन शामिल है। इस पैच से पहले, फ़ाइल /sys/class/block/mmcblk0/device/fwrev को Emmc उपकरणों Rev 4 और उससे अधिक के लिए CID से प्रारंभ नहीं किया गया था, और इस प्रकार शून्य दिखाया गया था।(दूसरी पूछताछ पर)पैच लागू होने तक fwrev शून्य है।

प्रश्न: संशोधन फिक्स से मेल नहीं खाता(सुपरब्रिक मुद्दे पर चर्चा करते समय लाल रंग पर जोर दें।)

उद्धरण:

मूलतः द्वारा पोस्ट किया गया केन सुमरॉल

संभवतः आपके पास बग है, लेकिन रेव 0x19 हमारे प्रोटोटाइप उपकरणों में मौजूद फर्मवेयर का पिछला संस्करण था, लेकिन हमने पाया कि इसमें एक और बग था जो कि यदि आप एक एमएमसी इरेज़ कमांड जारी किया, यह चिप में डेटा संरचनाओं को खराब कर सकता है और डिवाइस को तब तक लॉक कर सकता है जब तक कि यह संचालित न हो जाए साइकिल चलाई. हमें इसका पता तब चला जब हम आईसीएस विकसित कर रहे थे, जब हमारे कई डेवलपर उपयोगकर्ता डेटा को फास्टबूट से मिटा रहे थे। इसलिए सैमसंग ने समस्या को ठीक किया और फर्मवेयर संशोधन 0x25 पर ले जाया गया।हां, यह बहुत कष्टप्रद है कि 0x19 दशमलव 25 है, और इससे ईएमएमसी फर्मवेयर समस्याओं का निदान करने का प्रयास करते समय बहुत भ्रम पैदा हुआ। आख़िरकार मैंने _ALWAYS_ को हेक्साडेसिमल में ईएमएमसी संस्करण को संदर्भित करना और स्पष्ट होने के लिए संख्या से पहले 0x लगाना सीख लिया।तथापि, हालाँकि 0x19 में संभवतः बग है जो फ़्लैश में 32 Kbytes शून्य डाल सकता है, आप फ़र्मवेयर संशोधन 0x19 वाले डिवाइस पर इस पैच का उपयोग नहीं कर सकते। यह पैच संशोधन 0x25 फ़र्मवेयर में कोड के दो बाइट्स को एक बहुत ही विशिष्ट हैक करता है, और पैच अधिकांश संभवतः 0x19 पर काम नहीं करेगा, और संभवत: इससे चिप ख़राब हो जाएगी, और डेटा नष्ट हो जाएगा बहुत बुरा। इस पैच को ईएमएमसी फर्मवेयर पर लागू करने के लिए चयन मानदंड इतने सख्त होने का एक कारण है।मैंने कुछ दिनों बाद अपने परिणाम यह उल्लेख करते हुए दिए कि फ़ाइल सिस्टम वाइप होने तक दूषित नहीं हुआ था। यह उस अनुवर्ती कार्रवाई की प्रतिक्रिया है।जैसा कि मैंने पिछली पोस्ट में बताया था, फर्मवेयर रेव 0x19 में एक बग है जहां इरेज़ कमांड दिए जाने के बाद ईएमएमसी चिप लॉक हो सकती है। हर बार नहीं, लेकिन अक्सर काफी होता है। आमतौर पर, इसके बाद डिवाइस रीबूट हो सकता है, लेकिन फिर बूट प्रक्रिया के दौरान लॉक हो जाता है। बहुत कम ही, यह फ़ास्टबूट लोड होने से पहले ही लॉक हो सकता है। आपका परीक्षक बदकिस्मत था. चूँकि आप फ़ास्टबूट भी प्रारंभ नहीं कर सकते हैं, डिवाइस संभवतः ईंटयुक्त है। :-( यदि वह फास्टबूट चला सकता, तब डिवाइस संभवतः मेरे पास मौजूद फर्मवेयर अपडेट कोड के साथ पुनर्प्राप्त किया जा सकता है, यह मानते हुए कि मैं इसे साझा कर सकता हूं। मैं पूछता हूं।

प्रश्न: /डेटा विभाजन क्यों?

उद्धरण:

मूलतः द्वारा पोस्ट किया गया केन सुमरॉल (एंड्रॉइड एसई)

क्योंकि /डेटा वह स्थान है जहां चिप सबसे अधिक लेखन गतिविधि का अनुभव करती है। /system को कभी नहीं लिखा जाता है (सिस्टम अपडेट के दौरान को छोड़कर) और /cache का उपयोग शायद ही कभी किया जाता है (ज्यादातर OTA प्राप्त करने के लिए)।

प्रश्न: JTAG काम क्यों नहीं करेगा?

उद्धरण:

मूलतः द्वारा पोस्ट किया गया केन सुमरॉल

जैसा कि मैंने ऊपर उल्लेख किया है, संशोधन 0x19 फर्मवेयर में एक बग था कि ईएमएमसी मिटाने के आदेश के बाद, यह छोड़ सकता था ईएमएमसी चिप की आंतरिक डेटा संरचनाएं खराब स्थिति में हैं, जिसके कारण किसी विशेष क्षेत्र में चिप लॉक हो जाती है पहुँच गया. एकमात्र समाधान चिप को मिटाना और फ़र्मवेयर को अपडेट करना था। मेरे पास ऐसा करने के लिए कोड है, लेकिन मुझे नहीं पता कि मैं इसे साझा कर सकता हूं या नहीं। मैं पूछता हूं।

प्रश्न: क्या दूषित फ़ाइल सिस्टम को (ईएमएमसी पर) ठीक किया जा सकता है?

उद्धरण:

मूलतः द्वारा पोस्ट किया गया केन सुमरॉल

e2fsck फ़ाइल सिस्टम की मरम्मत कर सकता है, लेकिन अक्सर 32 Kbytes को ब्लॉक समूह की शुरुआत में डाला जाता था, जिससे कई इनोड मिट जाते थे, और इस प्रकार e2fsck चलाने से अक्सर कई फ़ाइलें खो जाती थीं।

इसलिए, हालांकि यह समाधान फिलहाल हम पर लागू नहीं होता है, हमें सुपरब्रिक मुद्दे के बारे में अच्छी जानकारी दी गई है और साथ ही यह जानकारी भी दी गई है कि समाधान है पहले से ही विकसित (उम्मीद है कि हम इसे रिलीज़ होते देखेंगे!)। बग संभवतः हम पर लागू होता है और मान लिया जाए कि 0x19 फर्मवेयर के लिए फिक्स दिया गया है तो यह हमारे उपकरणों पर लागू होगा।हल्के-फुल्के अंदाज में, मैं उनके करीबी को शामिल करना चाहता था:

उद्धरण:

मूलतः द्वारा पोस्ट किया गया केन सुमरॉल

आपको एंड्रॉइड कर्नेल डेवलपर के रोमांचक जीवन की एक झलक मिल रही है। :-) पता चला कि काम ज्यादातर खराब हार्डवेयर से जूझ रहा है। कम से कम कभी-कभी तो ऐसा ही लगता है.

जब तक इसका समाधान न हो जाए, कृपया अपने डिवाइस पर कुछ भी आईसीएस फ्लैश करने से बचें।

क्या आप पोर्टल में कुछ प्रकाशित करना चाहते हैं? किसी भी समाचार लेखक से संपर्क करें.

[धन्यवाद एन्ट्रॉपी512 आपकी सारी मेहनत के लिए!!!]