फ़ाइलों द्वारा स्टेग्नोग्राफ़ी: डेटा को सीधे सेक्टरों में छिपाना

संक्षिप्त परिचय

यदि किसी को याद न हो तो स्टेग्नोग्राफ़ी कुछ कंटेनरों में जानकारी छिपा रही है। उदाहरण के लिए, चित्रों में (चर्चा की गई)। यहां и यहां). आप फ़ाइल सिस्टम की सेवा तालिकाओं में भी डेटा छुपा सकते हैं (इसके बारे में लिखा गया था)। यहां), और भी टीसीपी प्रोटोकॉल सेवा पैकेट में. दुर्भाग्य से, इन सभी तरीकों में एक खामी है: किसी कंटेनर में जानकारी को अदृश्य रूप से "डालने" के लिए, आपको चालाक एल्गोरिदम की आवश्यकता होती है जो कंटेनर की आंतरिक संरचना की ख़ासियत को ध्यान में रखते हैं। और कंटेनर के हेरफेर के प्रतिरोध के साथ समस्याएं उत्पन्न होती हैं: उदाहरण के लिए, यदि आप चित्र को थोड़ा संपादित करते हैं, तो छिपी हुई जानकारी खो जाती है।

क्या चालाक एल्गोरिदम और डेटा के साथ सूक्ष्म हेरफेर के बिना किसी तरह से काम करना संभव है, और फिर भी कंटेनर की कार्यक्षमता और छिपे हुए डेटा की सुरक्षा का स्वीकार्य स्तर सुनिश्चित करना संभव है? आगे देखते हुए, मैं कहूँगा - हाँ, आप कर सकते हैं! मैं एक उपयोगिता भी पेश करूंगा।

विधि का खूनी विवरण

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

इस पद्धति का लाभ स्पष्ट है: हम फ़ाइल प्रारूप, या यहां तक ​​कि प्रयुक्त फ़ाइल सिस्टम के प्रकार पर भी निर्भर नहीं करते हैं।

मुझे लगता है कि नुकसान भी स्पष्ट हैं:

• गुप्त डेटा को केवल संपूर्ण डिस्क को पूरी तरह से फिर से लिखकर, उसके बाद उपयोगकर्ता को दिखाई देने वाली सामग्री को फिर से बनाकर बदला जा सकता है। हालाँकि, आप ऐसे सॉफ़्टवेयर का उपयोग नहीं कर सकते जो किसी छवि से डिस्क को फिर से बनाता है: यह पिछले गुप्त डेटा को भी फिर से बनाएगा।
• गुप्त डेटा की मात्रा जितनी बड़ी होगी, कुछ जानकारी खोने की संभावना उतनी ही अधिक होगी।
• डिस्क से डेटा पुनर्प्राप्त करने में लंबा समय लग सकता है. कई मिनटों से लेकर कई दिनों तक (आधुनिक डिस्क बड़ी होती हैं)।

अब आइए विशिष्ट बातों पर चलते हैं।

यह स्पष्ट है कि यदि आप पूरी डिस्क पर गुप्त डेटा फैला देंगे, तो यह केवल नग्न आंखों से छिपा रहेगा। यदि आप अपनी दृष्टि को एक डिस्क संपादक से सुसज्जित करते हैं, तो डेटा अपनी पूरी महिमा में दिखाई देगा। इसलिए, डेटा को एन्क्रिप्ट करना एक अच्छा विचार होगा ताकि वह दिखाई न दे। हम सरलता से, लेकिन सुरूचिपूर्ण तरीके से एन्क्रिप्ट करेंगे: aes256-cbc एल्गोरिथम का उपयोग करके। हम उपयोगकर्ता से एन्क्रिप्शन कुंजी मांगेंगे और उसे एक अच्छा पासवर्ड देने देंगे।

अगला प्रश्न यह है कि हम "अच्छे" डेटा को ख़राब डेटा से कैसे अलग कर सकते हैं। यहां एक चेकसम हमारी मदद करेगा, लेकिन साधारण नहीं, बल्कि SHA1। और क्या? यह गिट के लिए काफी अच्छा है, इसलिए यह हमारे लिए भी उपयुक्त होगा। निर्णय लिया गया: हम प्रत्येक संग्रहीत जानकारी को एक चेकसम के साथ प्रदान करते हैं, और यदि डिक्रिप्शन के बाद यह मेल खाता है, तो इसका मतलब है कि डिक्रिप्शन सफल रहा।

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

व्यवहार में विधि का परीक्षण करना

जाँच करने के लिए, आइए सबसे सामान्य माध्यम लें - एक फ्लैश ड्राइव। मुझे 1 जीबी क्षमता वाला एक पुराना वाला मिला, जो प्रयोगों के लिए काफी उपयुक्त है। यदि आप, मेरी तरह, भौतिक मीडिया से परेशान न होने, बल्कि इसे एक फ़ाइल - एक डिस्क छवि पर परीक्षण करने का विचार लेकर आए हैं, तो मैं तुरंत कहूंगा: यह काम नहीं करेगा। ऐसी "डिस्क" को फ़ॉर्मेट करते समय, लिनक्स फिर से फ़ाइल बनाता है, और सभी अप्रयुक्त सेक्टर शून्य से भर जाएंगे।

लिनक्स वाली एक मशीन के रूप में, दुर्भाग्य से, मुझे बालकनी पर पड़े रास्पबेरी पाई 3 पर एक मौसम स्टेशन का उपयोग करना पड़ा। वहां बहुत अधिक मेमोरी नहीं है, इसलिए हम बड़ी फ़ाइलों को नहीं छिपाएंगे। हम स्वयं को अधिकतम 10 मेगाबाइट आकार तक सीमित रखते हैं। बहुत छोटी फ़ाइलों को छिपाने का भी कोई मतलब नहीं है: उपयोगिता 4 केबी क्लस्टर में डिस्क पर डेटा लिखती है। इसलिए, नीचे हम खुद को 3 केबी फ़ाइल तक सीमित रखेंगे - यह ऐसे एक क्लस्टर में फिट बैठता है।

हम फ्लैश ड्राइव को चरणों में मॉक करेंगे, प्रत्येक चरण के बाद जांच करेंगे कि छिपी हुई जानकारी पढ़ने योग्य है या नहीं:

1. 16 KB के क्लस्टर आकार के साथ FAT16 प्रारूप में तेज़ फ़ॉर्मेटिंग। यह वही है जो विंडोज 7 एक फ्लैश ड्राइव के साथ करने की पेशकश करता है जिसमें फ़ाइल सिस्टम नहीं है।
2. फ्लैश ड्राइव को सभी प्रकार के कचरे से 50% तक भरना।
3. फ्लैश ड्राइव को सभी प्रकार के कचरे से 100% तक भरना।
4. FAT16 प्रारूप में "लंबा" स्वरूपण (हर चीज़ को अधिलेखित करना)।

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

Total clusters read: 250752, decrypted: 158
ERROR: cannot write incomplete secretFile

जैसा कि आप देख सकते हैं, केवल 158 क्लस्टर सफलतापूर्वक डिक्रिप्ट किए गए थे (632 किलोबाइट कच्चा डेटा, जो 636424 बाइट्स पेलोड देता है)। यह स्पष्ट है कि यहां 10 मेगाबाइट प्राप्त करने का कोई तरीका नहीं है, और फिर भी इन समूहों के बीच स्पष्ट रूप से डुप्लिकेट हैं। आप इस तरह से 1 मेगाबाइट भी पुनर्प्राप्त नहीं कर सकते। लेकिन हम गारंटी दे सकते हैं कि हम फ्लैश ड्राइव से 3 किलोबाइट गुप्त डेटा पुनर्प्राप्त करेंगे, भले ही इसे स्वरूपित किया गया हो और क्षमता के अनुसार लिखा गया हो। हालाँकि, प्रयोगों से पता चलता है कि ऐसी फ्लैश ड्राइव से 120 किलोबाइट लंबी फ़ाइल निकालना काफी संभव है।

दुर्भाग्यवश, अंतिम परीक्षण से पता चला कि संपूर्ण फ़्लैश ड्राइव ओवरराइट हो गई थी:

$ sudo ./steganodisk -p password /dev/sda
Device size: 250752 clusters
250700 99%
Total clusters read: 250752, decrypted: 0
ERROR: cannot write incomplete secretFile


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

यह भी काफी अपेक्षित है कि 10 मेगाबाइट को पूरी तरह से भरी हुई डिस्क पर छिपाया नहीं जा सकता। लेकिन अब सफलतापूर्वक डिक्रिप्ट किए गए क्लस्टरों की संख्या दोगुनी से अधिक हो गई है!

Total clusters read: 250752, decrypted: 405

दुर्भाग्य से, टुकड़ों से एक मेगाबाइट इकट्ठा करना असंभव है, लेकिन दो सौ किलोबाइट आसान है।

खैर, इस बार आखिरी, चौथे चेक के बारे में खबर खुशी देने वाली है: ऐसी फ्लैश ड्राइव को पूरी तरह से फॉर्मेट करने से सारी जानकारी नष्ट नहीं हुई! 4 किलोबाइट गुप्त डेटा अप्रयुक्त स्थान में पूरी तरह से फिट बैठता है।

परीक्षण सारांश तालिका:

थोड़ा सिद्धांतीकरण: खाली स्थान और अप्रयुक्त क्षेत्रों के बारे में

यदि आपने कभी अपनी हार्ड ड्राइव को विभाजनों में विभाजित किया है, तो आपने देखा होगा कि डिस्क पर सभी खाली स्थान को आवंटित करना हमेशा संभव नहीं होता है। पहला खंड हमेशा कुछ इंडेंटेशन (आमतौर पर 1 मेगाबाइट, या 2048 सेक्टर) से शुरू होता है। अंतिम खंड के पीछे, ऐसा भी होता है कि अप्रयुक्त क्षेत्रों की एक छोटी "पूंछ" बनी रहती है। और कभी-कभी अनुभागों के बीच अंतराल होते हैं, हालांकि शायद ही कभी।

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

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

ई-ई-ई - ड्रम रोल! उत्तर लगभग हमेशा हाँ ही होगा! दरअसल, ज्यादातर मामलों में, फ़ाइल सिस्टम बनाने से डिस्क पर सेवा जानकारी के केवल कुछ ब्लॉक लिखने तक ही सीमित रहता है, और अन्यथा विभाजन की सामग्री नहीं बदलती है।

और यह भी - विशुद्ध रूप से अनुभवजन्य रूप से - हम मान सकते हैं कि फ़ाइल सिस्टम हमेशा अंतिम सेक्टर तक आवंटित सभी स्थान पर कब्जा नहीं कर सकता है। उदाहरण के लिए, 16 किलोबाइट के क्लस्टर आकार वाला एक FAT64 फ़ाइल सिस्टम स्पष्ट रूप से 64 किलोबाइट के एकाधिक आकार वाले विभाजन पर पूरी तरह से कब्जा नहीं कर सकता है। ऐसे अनुभाग के अंत में उपयोगकर्ता डेटा संग्रहीत करने के लिए दुर्गम कई क्षेत्रों की "पूंछ" होनी चाहिए। हालाँकि, इस धारणा की प्रयोगात्मक रूप से पुष्टि नहीं की जा सकी।

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

प्रयोगों के लिए उपयोगिता

आप उपयोगिता के स्रोत कोड को छू सकते हैं यहां

निर्माण के लिए, आपको Qt संस्करण 5.0 या उच्चतर और OpenSSL की आवश्यकता होगी। यदि कुछ काम नहीं करता है, तो आपको steganonisk.pro फ़ाइल को संपादित करना पड़ सकता है।

आप क्लस्टर आकार को 4 KB से, मान लीजिए, 512 बाइट्स (secretfile.h में) में बदल सकते हैं। साथ ही, सेवा जानकारी की लागत में वृद्धि होगी: हेडर और चेकसम एक निश्चित 68 बाइट्स पर कब्जा कर लेते हैं।

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

का आनंद लें।

स्रोत: www.habr.com