स्टेगॅनोग्राफी मागील फायली: थेट सेक्टरमध्ये डेटा लपवत आहे

एक छोटी प्रस्तावना

स्टेगॅनोग्राफी, जर कोणाला आठवत नसेल तर, काही कंटेनरमध्ये माहिती लपवत आहे. उदाहरणार्थ, चित्रांमध्ये (चर्चा येथे и येथे). आपण फाइल सिस्टमच्या सेवा सारण्यांमध्ये डेटा देखील लपवू शकता (याबद्दल लिहिले होते येथे), आणि अगदी TCP प्रोटोकॉल सेवा पॅकेटमध्ये. दुर्दैवाने, या सर्व पद्धतींमध्ये एक कमतरता आहे: कंटेनरमध्ये अस्पष्टपणे "घाला" माहिती देण्यासाठी, आपल्याला धूर्त अल्गोरिदम आवश्यक आहेत जे कंटेनरच्या अंतर्गत संरचनेची वैशिष्ट्ये विचारात घेतात. आणि हाताळणीसाठी कंटेनरच्या प्रतिकारामुळे समस्या उद्भवतात: उदाहरणार्थ, आपण चित्र थोडेसे संपादित केल्यास, लपलेली माहिती गमावली जाते.

धूर्त अल्गोरिदम आणि डेटासह सूक्ष्म हाताळणीशिवाय कसे तरी करणे शक्य आहे आणि तरीही कंटेनरची कार्यक्षमता आणि लपविलेल्या डेटाच्या सुरक्षिततेची स्वीकार्य पातळी सुनिश्चित करणे शक्य आहे का? पुढे पाहताना, मी म्हणेन - होय, तुम्ही करू शकता! मी एक उपयुक्तता देखील देऊ करेन.

पद्धतीचे रक्तरंजित तपशील

मूळ कल्पना कपाळावर आघात करण्याइतकी सोपी आहे: डिस्कवर असे क्षेत्र आहेत ज्यावर ऑपरेटिंग सिस्टम कधीही लिहित नाही (किंवा क्वचित प्रसंगी लिहित नाही). धूर्त अल्गोरिदम वापरून या क्षेत्रांचा शोध घेण्याची गरज टाळण्यासाठी, आम्ही रिडंडंसी वापरू - म्हणजेच, आम्ही डिस्कच्या सर्व विभागांमध्ये आमच्या लपविलेल्या माहितीची अनेक वेळा डुप्लिकेट करू. मग, या सर्व वैभवाच्या वरती, आपण आवश्यक विभाजने तयार करू शकता, फाइल सिस्टमचे स्वरूपन करू शकता, फायली लिहू शकता आणि OS स्थापित करू शकता - सर्व समान, गुप्त डेटाचा काही भाग जतन केला जाईल आणि पुनर्प्राप्त केला जाऊ शकतो आणि पुनरावृत्ती डुप्लिकेशन आम्हाला मदत करेल. तुकड्यांमधून मूळ संपूर्ण एकत्र ठेवा.

या पद्धतीचा फायदा स्पष्ट आहे: आम्ही फाइल स्वरूपावर किंवा वापरलेल्या फाइल सिस्टमच्या प्रकारावर अवलंबून नाही.

तोटे देखील आहेत, मला वाटते, स्पष्ट:

• गुप्त डेटा केवळ संपूर्ण डिस्क पूर्णपणे पुन्हा लिहून बदलला जाऊ शकतो, त्यानंतर वापरकर्त्यास दृश्यमान सामग्री पुन्हा तयार करून. तथापि, आपण प्रतिमेवरून डिस्क पुन्हा तयार करणारे सॉफ्टवेअर वापरू शकत नाही: ते मागील गुप्त डेटा देखील पुन्हा तयार करेल.
• गुप्त डेटाचे प्रमाण जितके मोठे असेल तितकी काही माहिती गमावण्याची शक्यता जास्त असते.
• डिस्कवरून डेटा पुनर्प्राप्त करण्यास बराच वेळ लागू शकतो. कित्येक मिनिटांपासून ते अनेक दिवसांपर्यंत (आधुनिक डिस्क मोठ्या आहेत).

आता स्पेसिफिकेशन्सकडे वळूया.

हे स्पष्ट आहे की जर आपण संपूर्ण डिस्कवर गुप्त डेटा स्मीअर केला तर तो फक्त उघड्या डोळ्यांपासून लपविला जाईल. जर तुम्ही तुमची नजर डिस्क एडिटरने सुसज्ज केली तर डेटा सर्व वैभवात दिसेल. म्हणून, डेटा कूटबद्ध करणे चांगली कल्पना असेल जेणेकरुन तो दिसत नाही. आम्ही फक्त एन्क्रिप्ट करू, पण चवीने: aes256-cbc अल्गोरिदम वापरून. आम्ही वापरकर्त्याला एनक्रिप्शन की विचारू आणि त्याला चांगला पासवर्ड देऊ.

पुढील प्रश्न हा आहे की आपण वाईट डेटापासून “चांगला” डेटा कसा फरक करू शकतो. येथे एक चेकसम आम्हाला मदत करेल, परंतु एक साधा नाही, परंतु SHA1. आणि काय? हे गिटसाठी पुरेसे आहे, म्हणून ते आम्हाला देखील अनुकूल करेल. निर्णय घेतला: आम्ही प्रत्येक संग्रहित माहितीचा तुकडा चेकसमसह प्रदान करतो आणि जर ते डिक्रिप्शन नंतर जुळले तर याचा अर्थ डिक्रिप्शन यशस्वी झाले.

तुम्हाला फ्रॅगमेंट नंबर आणि गुप्त डेटाची एकूण लांबी देखील आवश्यक असेल. तुकडा क्रमांक म्हणजे कोणते तुकडे आपण आधीच उलगडले आहेत आणि कोणते शिल्लक आहेत याचा मागोवा ठेवणे. शेवटच्या तुकड्यावर प्रक्रिया करताना एकूण लांबी आमच्यासाठी उपयुक्त ठरेल, जेणेकरून अनावश्यक डेटा (म्हणजे पॅडिंग) लिहू नये. बरं, आमच्याकडे अजूनही हेडर असल्याने, आम्ही तेथे गुप्त फाइलचे नाव जोडू. हे डिक्रिप्शन नंतर उपयुक्त ठरेल, जेणेकरून ते कसे उघडायचे याचा अंदाज येऊ नये.

सराव मध्ये पद्धत चाचणी

तपासण्यासाठी, सर्वात सामान्य माध्यम घेऊ - फ्लॅश ड्राइव्ह. मला 1 GB क्षमतेचे जुने सापडले, जे प्रयोगांसाठी अगदी योग्य आहे. जर तुम्हाला, माझ्याप्रमाणे, भौतिक माध्यमांचा त्रास न करण्याची कल्पना आली असेल, परंतु फाईलवर चाचणी - डिस्क प्रतिमा, तर मी लगेच म्हणेन: ते कार्य करणार नाही. अशी "डिस्क" फॉरमॅट करताना, लिनक्स पुन्हा फाइल तयार करते आणि सर्व न वापरलेले सेक्टर शून्याने भरले जातील.

Linux सह मशीन म्हणून, दुर्दैवाने, मला बाल्कनीत पडलेल्या Raspberry Pi 3 वर एक वेदर स्टेशन वापरावे लागले. तेथे जास्त मेमरी नाही, त्यामुळे आम्ही मोठ्या फाइल्स लपवणार नाही. आम्ही स्वतःला 10 मेगाबाइट्सच्या कमाल आकारापर्यंत मर्यादित करतो. खूप लहान असलेल्या फायली लपविण्यातही काही अर्थ नाही: युटिलिटी 4 KB क्लस्टर्समध्ये डिस्कवर डेटा लिहिते. म्हणून, खाली आम्ही स्वतःला 3 kb फाईलपर्यंत मर्यादित करू - ती अशा एका क्लस्टरमध्ये बसते.

लपलेली माहिती वाचण्यायोग्य आहे की नाही हे प्रत्येक टप्प्यानंतर तपासत आम्ही टप्प्याटप्प्याने फ्लॅश ड्राइव्हची थट्टा करू:

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 आवश्यक असेल. काहीतरी कार्य करत नसल्यास, तुम्हाला steganodisk.pro फाइल संपादित करावी लागेल.

तुम्ही क्लस्टरचा आकार 4 KB वरून बदलू शकता, म्हणा, 512 बाइट्स (secretfile.h मध्ये). त्याच वेळी, सेवा माहितीची किंमत वाढेल: शीर्षलेख आणि चेकसम निश्चित 68 बाइट्स व्यापतात.

तुम्हाला युटिलिटी चालवणे आवश्यक आहे, अर्थातच, रूट वापरकर्ता अधिकारांसह, आणि सावधगिरीने. निर्दिष्ट फाइल किंवा डिव्हाइस ओव्हरराइट करण्यापूर्वी कोणतेही प्रश्न विचारले जाणार नाहीत!

आनंद घ्या.

स्त्रोत: www.habr.com