एक पिछले दरवाजे की कहानी

प्रागितिहास

एक बार की बात है एक पुरानी-पुरानी साइट थी। माता-पिता ने उसे मना कर दिया, और अस्तित्व के दूसरे दस वर्षों में, वह हमारे पास आया। यह फ़ोल्डरों में बिखरे हुए PHP कोड का एक जंगल था। यह सब अलग-अलग समय पर, अलग-अलग एन्कोडिंग (एक ही फाइल के भीतर 3 एनकोडिंग तक) में अलग-अलग बैसाखी पैटर्न का उपयोग करते हुए लिखा गया था। MVC तब, शायद, अभी तक ज्ञात नहीं था, और डेवलपर्स ने टेम्पलेट इंजन के बारे में नहीं सुना था, इसलिए अचानक आश्चर्यचकित न हों

<? if (cond) { ?> 

HTML मार्कअप में। मैंने दाईं ओर एक रोमांचक खोज में एक घंटे से अधिक समय बिताया

 <? } ?> 

डेवलपर्स बैकअप के बारे में नहीं भूले: मूल में आप index.php, index_old.php, index.php.bak पा सकते हैं। लेकिन कोई बात नहीं, इस चमत्कार ने काम किया। और जो काम करता है उसे मत छुओ।

टाई

यह कहानी तब शुरू हुई जब एक प्रचार विशेषज्ञ को एक दिसंबर की सुबह धूप में पाद लेख में विदेशी साइटों के लिंक खोजने के लिए आश्चर्य हुआ। थोड़ी खुदाई में 2 बातें सामने आईं:

1. यह ग्लैंडर्स है ;
2. ग्राहक हैरान है।

आप ग्राहक की अस्पष्टता को समझ सकते हैं: वह इन लिंक को नहीं देखता है।

जांच

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



कुछ भी स्पष्ट नहीं है, लेकिन उस व्यक्ति के लिए ईमानदारी से धन्यवाद जिसने हेडर में एनोटेशन को नहीं हटाया। मैं `` Zend अनुकूलक '' के लिए शुरू कर रहा हूँ, यह विश्वास है कि यह इस कचरा के डिक्रिप्शन के लिए नेतृत्व करेंगे। एक काम कर रहे डिकोडर की तलाश यहां समाप्त होती है । विशेष रूप से कैप्चा से प्रसन्न:



परिणाम की नकल करने से संबंधित कुछ बवासीर के साथ, मुझे निम्नलिखित मिला:



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



यदि आप टिप्पणियों को हटाते हैं, तो यह पता चला है

 @eval(base64_decode($I0)); 

इस बिंदु पर, मुझे फ़ंक्शन को कॉल करने से पहले "@" मान को google करना पड़ा। अगला, ऑनलाइन डिकोडर्स के लिए धन्यवाद, मुझे पहेलियाँ का अगला बैच मिला।



यहाँ मैंने पहली बार chr () फंक्शन देखा। पर मिल गया

 $ll = @explode(chr(187) , @implode('', @array_map('trim', @file($ll)))); 

Googled array_map () । सामान्य तौर पर, Zend अनुकूलक द्वारा एन्क्रिप्ट की गई एक ही मूल फ़ाइल का एक टुकड़ा यहाँ उपयोग किया जाता है। मुझे पता नहीं है कि किस तरह का एल्गोरिथ्म है, लेकिन पात्रों को पुनर्व्यवस्थित करने और पहले से ही परिचित हो रहे बेस 64_डॉस्क () लेने के बाद, मुझे एक क्रिप्टो फ़ंक्शन मिला:



इसके अलावा कॉम तेजी से बढ़ना शुरू हुआ, और कई पुनरावृत्तियों के बाद फ़ाइल 2k लाइनों तक पहुंच गई। इस सभी जांच के बाद, मैंने कल के लिए फ़ाइल संरचना को छोड़ दिया, लेकिन अब कुछ मजेदार के लिए:


आपको आंतरिक सबनेट के टर्मिनलों से किसी का ध्यान नहीं जाने देता है।


दिलचस्प है, वे तुरंत इस तरह के एक एन्क्रिप्शन को वहां करते हैं, या यह कोई है जो पहले से ही हमारे लिए एक विशेषज्ञ की कोशिश कर रहा है?

एक आफ्टरवर्ड के बजाय

यदि आप मानते हैं कि फ़ाइलों को बनाने में लगने वाला समय, यह यार्ड में एक कठोर 2009 था। लेकिन मुझे उन लोगों के समय के लिए थोड़ा खेद भी है, जिन्होंने इसे बहुत मुश्किल से सीवे किया, क्योंकि मुझे यकीन है कि इस प्रक्रिया ने उन्हें रिवर्स की तुलना में अधिक समय दिया। और सब के बाद, यह सब असंभव होगा यदि केवल ज़ेड ऑप्टिमाइज़र के बारे में एनोटेशन नहीं रहता था।