🐖 🤛🏽 🏩 राइट इन द शैडोज़ 🛌 ‼️ 🚞

यह उन कार्यों में से एक के बारे में कहानी है, जिन्हें हमने CTFZone योग्यता चरण के लिए तैयार किया था, जो नवंबर के अंत में आयोजित किया गया था। आप यहां योग्यता तैयारी प्रक्रिया के बारे में पढ़ सकते हैं ।

आप दो फ़ाइलों से शुरू करते हैं: decrypt_flag.py और ntfs_volume.raw। आइए स्क्रिप्ट पर एक नज़र डालें। वह key.bin नाम की एक फ़ाइल खोलता है, और फिर, एक लूप का उपयोग करके, वह फ़ाइल के अंदर प्रत्येक ऑफसेट से एक 34-बाइट बाइनरी स्ट्रिंग लेने की कोशिश करता है, जिसे तब PBKDF2 फ़ंक्शन के इनपुट के रूप में उपयोग किया जाता है। प्रत्येक लौटी हुई कुंजी का उपयोग कोड में एन्क्रिप्टेड स्ट्रिंग सिलन को डिक्रिप्ट करने के लिए XOR कुंजी के रूप में किया जाता है। यदि इसका डिक्रिप्टेड एमडी 5 हैश डिक्रिप्टेड रूप में पूर्व निर्धारित मूल्य से मेल खाता है, तो स्क्रिप्ट ध्वज प्राप्त करने और प्रिंट करने के लिए प्राप्त डेटा का उपयोग करता है।

इसलिए आपको key.bin फ़ाइल ढूंढनी होगी। छवि फ़ाइल (ntfs_volume.raw) के अंदर सभी ऑफ़सेट्स के माध्यम से इसे सॉर्ट करना असंभव है, क्योंकि कुंजी खोजने की प्रक्रिया बहुत धीमी होगी। यह नियमों द्वारा निषिद्ध नहीं है, लेकिन आप निश्चित रूप से CTF के अंत से पहले समय नहीं है।

छवि फ़ाइल में एकल-विभाजन MBR विभाजन तालिका है। इसकी भरपाई 2048 512-बाइट सेक्टर्स में होती है, और इसमें NTFS फाइल सिस्टम होता है, लेकिन key.bin फाइल इसमें नहीं है:

$ fls -o 2048 -r -p ntfs_volume.raw | grep -F key.bin | wc –l
0

NTFS ने UTF-16LE एन्कोडेड फ़ाइल नाम संग्रहीत किए हैं। आइये इसमें खोज करने की कोशिश करते हैं!

फ़ाइल रिकॉर्ड के

लिए खोज परिणाम खोज परिणामों का अध्ययन करने के बाद, हम फ़ाइल रिकॉर्ड पर ध्यान केंद्रित करते हैं जो FILE हस्ताक्षर [1] से शुरू होता है। यहाँ केवल ऐसी प्रविष्टि है:

मिला रिकॉर्ड

लक्ष्य पहले से ही करीब है! हमारे पास एक फ़ाइल रिकॉर्ड है, लेकिन हमें डेटा की आवश्यकता है। NTFS में, उन्हें $ DATA विशेषता में संग्रहीत किया जाता है, जो निवासी या अनिवासी [2] हो सकता है। हमने पाया रिकॉर्ड में, यह विशेषता ऑफसेट 0 × 3AADD00 पर शुरू होती है और अनिवासी डेटा को इंगित करती है (इसका मतलब है कि जानकारी फ़ाइल रिकॉर्ड के बाहर संग्रहीत है)।

तो वास्तव में वांछित फ़ाइल का डेटा कहां है? इस प्रश्न का उत्तर देने के लिए, तथाकथित मैपिंग जोड़े, या डेटा रन (जोड़े "ब्लॉक लंबाई - ब्लॉक ऑफसेट") [3] को डिकोड करना आवश्यक है। वांछित फ़ाइल के डेटा रन निम्न हैं (ऑफसेट 0 × 3AADD40 पर ध्यान दें): 22 53 01 A0 4E 21 05 31 C1 11 38 30 00. या, यदि हम उन्हें पुनर्व्यवस्थित करते हैं:

1.	22 53 01 A0 4E
2.	21 05 31 C1
3.	11 38 30 00

फ़ाइल में तीन टुकड़े होते हैं, जिनमें से पहले का आकार 339 क्लस्टर है, और यह क्लस्टर # 20128 से शुरू होता है। PBKDF2 का उपयोग करते हुए हमारे कोड के लिए, यह स्निपेट बड़ा है। जैसा कि फ़ाइल सिस्टम हेडर में संकेत दिया गया है, एक क्लस्टर का आकार 4096 बाइट्स है:

$ fsstat -o 2048 ntfs_volume.raw | grep 'Cluster Size'
Cluster Size: 4096

आइए इस ऑफसेट (बाइट्स में) के डेटा पर एक नज़र डालें:
2048 * 512 + 20128 * 4096 = 83492864। हम यहां से किसी भी महत्वपूर्ण जानकारी (उदाहरण के लिए, 128 बाइट्स) को निकालेंगे, इसे एक नई फ़ाइल में डालें, जिसे हम key.bin कहेंगे, स्क्रिप्ट चलाएँ ... कुछ भी सफल नहीं हुआ।

शायद फ़ाइल वर्तमान में संग्रहीत नहीं की गई थी, लेकिन फ़ाइल सिस्टम के पिछले संस्करण में (पिछले स्वरूपण) - यह मत भूलो कि हमने उसी नाम के साथ हटाए गए फ़ाइल के बारे में रिकॉर्ड नहीं देखा था। पहले क्लस्टर का आकार क्या था? आइए NTFS हस्ताक्षर [4] के साथ फाइल सिस्टम हेडर की तलाश करें। शायद हम भाग्यशाली हैं और हम वास्तव में पिछले स्वरूपण से हेडर पाते हैं।

फ़ाइल सिस्टम हेडर के

लिए खोज परिणाम खोज परिणामों में पहला और अंतिम स्थान वर्तमान फ़ाइल सिस्टम को संदर्भित करता है, लेकिन उनके बीच स्थित फ़ाइल सिस्टम हेडर पिछले स्वरूपण से संबंधित लगते हैं। और उनके पास एक अलग क्लस्टर आकार है!

पिछले संस्करण से फ़ाइल सिस्टम हेडर।

इस तरह के एक सेक्टर साइज़ को 0 × 4554800B: 00 02, या 512 की ऑफसेट पर लिखा जाता है। लेकिन इस तरह के क्लस्टर साइज़ को 0 × 0x4554800D: F7, या 247 की ऑफ़सेट पर रिकॉर्ड किया जाता है।

इसलिए, हमारे पास क्लस्टर साइज़ है (बाइट्स में) 512 * 247 = 126464. किसी प्रकार की बकवास! यदि आप मानते हैं कि NTFS पार्सर [5], तो इस तरह के मूल्य पर एक चिन्ह होना चाहिए और एक विशेष तरीके से संसाधित होना चाहिए, इसलिए वास्तविक क्लस्टर आकार (सेक्टरों में) 1 << - (- 9) = 512 है। या, यदि बाइट्स में, 512 = 512 = 262144 अब अधिक विश्वसनीय लगता है।

डेटा इस ऑफसेट (बाइट्स में) से यहां शुरू होता है:
2048 * 512 + 20128 * 262144 = 5277483008। चलो फिर से कोशिश करें कि वहां संग्रहीत जानकारी के साथ एक ही चाल करें ... फिर से, एक विफलता! गलत क्या है? हमारे यहां CTF है, इसका मतलब है "ऐसा नहीं" कुछ भी हो सकता है।

जिस कार्य से हम लड़ रहे हैं उसे शैडो कहा जाता है। यह संभव है कि इसका वॉल्यूम की छाया प्रतियों के साथ कुछ करना है। तो, हमारे पास फ़ाइल सिस्टम से एक फ़ाइल है जो पहले इस वॉल्यूम में मौजूद थी। दुर्भाग्य से, हम केवल इसकी छाया प्रति नहीं ले सकते हैं और माउंट नहीं कर सकते हैं, लेकिन हम सटीक ऑफसेट जानते हैं जिस पर डेटा शुरू होता है! यह 5277483008 है, या, अनुभाग के भीतर, 5277483008 - 2048 * 512 = 5276434432

है। VSS प्रारूप [6] के विनिर्देशों के अनुसार, पुनर्निर्देशित डेटा ब्लॉकों को ब्लॉक डिस्क्रिप्टर संरचना में वर्णित किया गया है जिसमें 64-बिट फ़ील्ड है जिसमें मूल ऑफसेट (वॉल्यूम के अंदर), और संग्रहीत है। लक्ष्य ब्लॉक ऑफ़सेट (वॉल्यूम के अंदर) का वर्णन करने वाला 64-बिट फ़ील्ड भी। 5276434432 को 64-बिट कम संख्या के रूप में देखते हैं।

परिणामों में केवल दो परिणाम हैं, और उनमें से केवल एक ही ऑफसेट पर स्थित है।

मिला ब्लॉक डिस्क्रिप्टर

टारगेट ब्लॉक ऑफ़सेट: 00 00 9B 03 00 00 00, या सिर्फ 60489728। अंतिम ऑफ़सेट: 60489728 + 2048 * 512 = 61538304। यहाँ से, एक नई फ़ाइल के लिए डेटा की एक निश्चित मात्रा को निर्यात करें, जिसे key.bin, और ...

$ ./decrypt_flag.py
ctfzone{my_c0ngr4t5_t0_u,w311_d0n3_31337}

किया हुआ!

राइट इन द शैडोज़

संदर्भ

More articles: