स्टेग्नोग्राफी वापरून हार्ड ड्राइव्ह जागा वाचवा

जेव्हा आपण स्टेग्नोग्राफीबद्दल बोलतो, तेव्हा लोक दहशतवादी, पेडोफाइल, हेर किंवा, सर्वात चांगले, क्रिप्टोअनार्किस्ट आणि इतर शास्त्रज्ञांचा विचार करतात. आणि खरोखर, आणखी कोणाला आवश्यक आहे लपवा बाह्य डोळ्यांमधून काहीतरी? याचा सामान्य माणसाला काय फायदा होऊ शकतो?

तो एक आहे बाहेर वळते. म्हणूनच आज आपण स्टेग्नोग्राफी पद्धती वापरून डेटा संकुचित करू. आणि सरतेशेवटी, वाचक फाइल सिस्टमवर विनामूल्य गीगाबाइट्सची संख्या वाढवण्यासाठी JPEG मध्ये त्याचे मौल्यवान फोटो संग्रहण वापरण्यास सक्षम असेल.

काय?

वाचकांच्या लक्षात असल्यास, स्टेग्नोग्राफी ही अशी विचित्र अल्गोरिदम आहे ज्यामुळे एका माहितीची उपस्थिती दुसर्‍या आत लपवणे शक्य होते. अगदी सोप्या भाषेत: चित्र + फाइल == अंदाजे समान चित्र, परंतु फारसे नाही (चित्रांऐवजी काहीही असू शकते, परंतु सामान्यतः त्यामध्ये सर्वकाही स्पष्ट असते). आत काहीतरी आहे की नाही हे ठरवण्याचा सोपा मार्ग नसावा.

पण जर एखाद्याला दुसऱ्यापासून वेगळे करता येत नसेल तर त्यात काही फरक आहे का? ग्राहकाच्या दृष्टिकोनातून, वापरकर्त्याला गणिताच्या अचूकतेची (बिटांच्या विशिष्ट संचाद्वारे प्रतिबिंबित) काळजी नसते, फक्त त्याला काय समजते.

उदाहरणार्थ, एका गोंडस कुत्र्याच्या तीन प्रतिमा पाहू:

सावधान, JPEG!

आकारात प्रचंड फरक असूनही, काही लोक तिसरी आवृत्ती निवडतील. दुसरीकडे, पहिल्या दोन छायाचित्रांमधील फरक इतका लक्षणीय नाही आणि त्यातील माहितीचे प्रमाण (माझ्या दृष्टिकोनातून) समान असू शकते.

हे तत्त्व आधीच जुने आहे आणि बर्याच वर्षांपासून हानीकारक माहिती कॉम्प्रेशन पद्धतींनी सक्रियपणे शोषण केले आहे. परंतु तोडणे म्हणजे इमारत नाही; आम्हाला समस्येच्या अधिक प्रगत बाजूमध्ये रस आहे. अतिरिक्त आकाराची माहिती एम्बेड करणे शक्य आहे का N फाईलमध्ये जेणेकरून त्याचा आकार वाढेल M < N, परंतु बदल वापरकर्त्याच्या लक्षात येण्यासारखे नव्हते?

तू नक्कीच करू शकतोस. परंतु लगेचच काही आरक्षणे करणे योग्य आहे:

• प्रथम, पद्धत सार्वत्रिक असली पाहिजे आणि बहुतेक इनपुट डेटावर सकारात्मक परिणाम द्या. म्हणजेच, सरासरी, यादृच्छिक इनपुटसाठी, संचयित केलेल्या माहितीच्या प्रमाणात वास्तविक घट झाली पाहिजे. "सरासरी" याचा अर्थ असा आहे की उलट घडू शकते, परंतु प्रबळ नसावे.
• दुसरे म्हणजे, माहिती एम्बेड करण्यापूर्वी संकुचित कंटेनरचा आकार त्याच प्रकारे संकुचित केलेल्या बदलापेक्षा मोठा असणे आवश्यक आहे. LSB पद्धतीचा वापर करून BMP प्रतिमांमध्ये फक्त बिट्स एम्बेड करणे हे स्टेगॅनोग्राफिक कॉम्प्रेशन नाही, कारण, काही प्रकारच्या DEFLATE द्वारे चालवल्या गेल्यामुळे, मूळ प्रतिमा बहुधा लक्षणीयपणे लहान असेल.
• तिसरे म्हणजे, निकाल काढला जाणे आवश्यक आहे आणि शास्त्रीय पद्धतींनी आधीच संकुचित केलेल्या डेटाच्या संदर्भात तुलना करणे आवश्यक आहे. हे त्यांच्या रिडंडंसीमधील फरकांचा संभाव्य प्रभाव काढून टाकेल आणि सामान्य प्रकरणात अधिक कार्यक्षम कॉम्प्रेशन प्रदान करेल.

कोठे?

स्टेग्नोग्राफीचा वापर सूचित करतो की, संकुचित माहिती व्यतिरिक्त, आम्हाला कंटेनरची आवश्यकता असेल ज्यामध्ये ती एम्बेड केली जाईल. एम्बेड केलेल्या माहितीची कमाल रक्कम मुख्यत्वे वैयक्तिक गुणधर्मांवर अवलंबून असते, परंतु त्यांची संख्या मोजणे खूप सोपे आहे. म्हणून, कंटेनरचे स्वरूप सामान्य असणे आवश्यक आहे जेणेकरुन वापरकर्त्याकडे "कंप्रेशन" प्रक्रियेचा कोणताही फायदा मिळविण्यासाठी पुरेसा असेल.

या संदर्भात, ग्राफिक्स, ऑडिओ आणि व्हिडिओ फाइल्स चांगले उमेदवार आहेत. परंतु, विविध स्वरूप, कोडेक्स इत्यादींच्या विविधतेमुळे, व्यवहारात आमच्याकडे इतक्या पर्यायांपैकी एक पर्याय शिल्लक आहे.

हे सर्व लक्षात घेता, माझी निवड JPEG वर पडली. जवळजवळ प्रत्येकाकडे ती आहे, बहुतेक प्रतिमांसाठी जवळजवळ डी-फॅक्टो फॉरमॅट असल्याने, वैयक्तिक आणि व्यावसायिक दोन्ही हेतूंसाठी ते मोठ्या प्रमाणावर वापरले जाते.

ते अवलंबून आहे?

पुढे जवळ- आणि तांत्रिक आकृत्या आणि वर्णने जास्त स्पष्टीकरणाशिवाय आहेत, म्हणून ज्यांना स्वारस्य आहे ते “उच्च तंत्रज्ञान” विभागात स्क्रोल करून ते वगळू शकतात.

सामान्य वैशिष्ट्ये

कुठेतरी डेटा एम्बेड करण्यासाठी, आपण प्रथम कुठे हे निर्धारित करणे आवश्यक आहे. फाइल सिस्टीमवर कितीही वेगवेगळी छायाचित्रे असू शकतात, ज्यापैकी वापरकर्त्याला फक्त काही वापरायचे असतील. कंटेनरच्या अशा इच्छित संचाला आम्ही लायब्ररी म्हणू.

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

या प्रकरणात, संपूर्ण फाइल सिस्टममध्ये नियमित अभिव्यक्ती वापरून प्रारंभिक शोध घेण्यात काही अर्थ नाही; विशिष्ट रूट निर्देशिका निर्दिष्ट करणे पुरेसे आहे. त्यात एक विशेष संग्रहण फाइल जतन केली जाईल, ज्यामध्ये संकुचित माहितीच्या त्यानंतरच्या पुनर्प्राप्तीसाठी आवश्यक असलेल्या इतर मेटा-माहितीसह त्या हॅश असतील.

हे सर्व कोणत्याही स्टेगॅनोग्राफिक डेटा कम्प्रेशन अल्गोरिदमच्या कोणत्याही अंमलबजावणीवर तितकेच लागू होते. डेटा कॉम्प्रेशन आणि रिकव्हरीच्या प्रक्रियेस स्वतःच पॅकिंग आणि अनपॅकिंग असे म्हटले जाऊ शकते.

F5

आता आपण काय करत आहोत आणि का हे स्पष्ट झाले आहे, ध्येय साध्य करण्यासाठी अल्गोरिदमचे वर्णन करणे बाकी आहे. जेपीईजी फाईल एन्कोड करण्याची प्रक्रिया आठवूया (बॉमन नॅशनल लायब्ररीच्या विकीला धन्यवाद):

ते पाहता, ताबडतोब काही टिप्पण्या करणे चांगले आहे:

• JPEG फाईलचा आकार एखाद्या प्रकारच्या Winrar सह संकुचित करण्याचा प्रयत्न न करता देखील इष्टतम मानला जाऊ शकतो;
• किमान स्वीकारार्ह कार्यप्रदर्शन प्रदान करण्यासाठी केवळ संग्रहित माहिती (जे डिस्क्रिट कोसाइन ट्रान्सफॉर्म, DCT मधून आउटपुट आहे) सुधारित केली जाऊ शकते.
• वापरकर्त्याच्या लक्षात येण्याजोग्या औद्योगिक स्केलवरील डेटा गमावू नये म्हणून, प्रत्येक वैयक्तिक प्रतिमेमध्ये कमीतकमी बदल करणे आवश्यक आहे;

अल्गोरिदमचे संपूर्ण कुटुंब या अटींशी जुळते, जे तुम्ही स्वतःला परिचित करू शकता या चांगल्या सादरीकरणात. त्यापैकी सर्वात प्रगत अल्गोरिदम आहे F5 ब्राइटनेस घटकाच्या डीसीटी गुणांकांसह कार्य करताना अँड्रियास वेस्टफेल्ड (मानवी डोळा त्याच्या बदलांबद्दल सर्वात कमी संवेदनशील असतो). विद्यमान JPEG फाईलसह कार्य करताना त्याचे सामान्य लेआउट खालीलप्रमाणे प्रदर्शित केले जाते:

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

पूर्णांक गुणांकांमध्ये बदल स्वतःच केले जातात आणि त्यांचे निरपेक्ष मूल्य एकाने कमी करण्यासाठी खाली येतात, जे साधारणपणे, डेटा कॉम्प्रेशनसाठी F5 वापरण्याची परवानगी देते. मुद्दा असा आहे की JPEG मधील मूल्यांच्या सांख्यिकीय वितरणामुळे Huffman एन्कोडिंगनंतर निरपेक्ष मूल्यातील कमी केलेले गुणांक बहुधा कमी बिट्स व्यापेल.

शून्य (तथाकथित कपात) च्या निर्मितीच्या बाबतीत, संग्रहित माहितीची संख्या त्याच्या आकाराने कमी केली जाईल, कारण पूर्वीचा स्वतंत्र गुणांक शून्याच्या RLE एन्कोड केलेल्या क्रमाचा भाग बनेल:

बदल

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

मूळ अल्गोरिदम गुप्त संदेश प्रसारित करण्यासाठी डिझाइन केलेले आहे, म्हणून ते एका वेळी फक्त एका कंटेनरसह कार्य करते, असे गृहीत धरून की वापरकर्ता स्वतःच आवश्यक असल्यास, जर काही असेल तर त्याचे भाग बनवेल. शिवाय, प्रत्येक कंटेनरमध्ये स्वतंत्रपणे एम्बेड केल्यावर, प्रत्येक कंटेनरमध्ये किती बिट डेटा ठेवायचा हे तुम्हाला आधीच माहित असणे आवश्यक आहे. म्हणून, लायब्ररीच्या प्रत्येक घटकाचे गुणांक एका अमूर्त मोठ्यामध्ये एकत्र केले पाहिजे आणि मूळ अल्गोरिदमनुसार त्याच्यासह कार्य केले पाहिजे.

मूळ F5 कंटेनर आकाराच्या 12% पर्यंत परवानगी देत ​​असल्याने, हे बदल कमाल क्षमता देखील वाढवेल: संपूर्ण लायब्ररीच्या आकाराच्या "12% पर्यंत" हे "12% पर्यंत" च्या बेरीजपेक्षा मोठे किंवा समान आहे "त्याच्या प्रत्येक घटकातून.

संहिताबद्ध सर्वसाधारण योजना खालीलप्रमाणे आहे:

अल्गोरिदम स्वतः

आता सुरुवातीपासून शेवटपर्यंत अल्गोरिदमचे वर्णन करण्याची वेळ आली आहे, जेणेकरून वाचकांना अंधारात ठेवू नये:

• वापरकर्ता बायनरी कॉम्प्रेस करण्यायोग्य डेटा M आणि लायब्ररी L ची व्याख्या रेग्युलर एक्सप्रेशन आणि सर्च रूट डिरेक्टरी वापरून करतो;
• ज्या क्रमाने ते FS वर दिसतात, लायब्ररी घटक MC बनवतात:
  • गुणांक सीची मालिका फाइल डेटामधून डीकोड केली जाते;
  • MC <- MC | क;
• पॅरामीटर k हे भयंकर असमानतेच्या आधारे निर्धारित केले जाते: |M| * 8 / (count_full(MC) + count_ones(MC) * k_rate(k)) < k / ((1 << k) - 1);
• पुढे घेतले n = (1 << k) - 1 MC कडून शून्य नसलेल्या घटकांचे किमान लक्षणीय बिट्स आणि त्यावर लिहिलेले a:
  • मॅजिक हॅश फंक्शन मानले जाते f, एन-बिट शब्द दर्शवित आहे a k-bit ला s;
  • तर s == 0, नंतर काहीही बदलण्याची गरज नाही आणि अल्गोरिदम पुढील गुणांकांवर पुढे जाईल;
  • यासाठी जबाबदार असलेल्या गुणांकाचे परिपूर्ण मूल्य कमी करा s-अहो शब्दात थोडा a;
  • जर कपातीच्या परिणामी कपात झाली (गुणक 0 होते), तर सुरुवातीपासून चरण पुन्हा करा;
• सर्व गुणांक RLE आणि Huffman द्वारे एन्कोड केलेले आहेत, स्त्रोत फायलींवर लिहिलेले आहेत;
• पॅरामीटर k हे संग्रहण फाइलवर लिहिलेले आहे;
• MD5 हॅशची गणना प्रत्येक फाईल L मधून त्यांच्या मूळ स्थानाच्या क्रमाने केली जाते आणि संग्रहण फाइलवर लिहिली जाते.

हाय टेक

अल्गोरिदमचे साधे स्वरूप आणि इतर उच्च-स्तरीय (विशेषत: कचरा संकलनासह) भाषांमधील अंमलबजावणी भयंकर कार्यप्रदर्शन देईल, म्हणून मी या सर्व जटिलता शुद्ध C मध्ये लागू केल्या आणि अंमलबजावणी गती आणि दोन्ही बाबतीत अनेक ऑप्टिमायझेशन केले. मेमरी (डीसीटीच्या आधीही कॉम्प्रेशनशिवाय या चित्रांचे वजन किती आहे याची आपल्याला कल्पना नाही). परंतु तरीही, प्रथम अंमलबजावणीच्या गतीने इच्छित होण्यासारखे बरेच काही सोडले, म्हणून मी संपूर्ण प्रक्रिया आणि वापरलेल्या पद्धतींचे वर्णन करणार नाही.

क्रॉस-प्लॅटफॉर्म libjpeg, pcre आणि tinydir लायब्ररीच्या संयोजनाने साध्य केले जाते, ज्यासाठी आम्ही त्यांचे आभार मानतो. डीफॉल्टनुसार, सर्वकाही सामान्य द्वारे संकलित केले जाते make, म्हणून Windows वापरकर्ते स्वतःसाठी काही Cygwin स्थापित करू इच्छितात किंवा व्हिज्युअल स्टुडिओ आणि लायब्ररीशी स्वतःहून व्यवहार करू इच्छितात.

अंमलबजावणी कन्सोल युटिलिटी आणि लायब्ररीच्या स्वरूपात उपलब्ध आहे. ज्यांना स्वारस्य आहे ते Github वरील रेपॉजिटरीमध्ये रीडमीमध्ये नंतरचे वापरण्याबद्दल अधिक जाणून घेऊ शकतात, ज्याची लिंक मी पोस्टच्या शेवटी जोडेन. आणि येथे आम्ही कामाचे वर्णन आणि प्रात्यक्षिक वर जाऊ.

कसे वापरावे?

काळजीपूर्वक. वापरलेल्या प्रतिमा इच्छेनुसार हलवल्या जाऊ शकतात, पुनर्नामित केल्या जाऊ शकतात आणि कॉपी केल्या जाऊ शकतात. तथापि, आपण अत्यंत सावधगिरी बाळगली पाहिजे आणि त्यांची सामग्री कोणत्याही प्रकारे बदलू नये. थोडासा बदल केल्याने हॅशमध्ये व्यत्यय येईल आणि माहिती पुनर्प्राप्त करणे अशक्य होईल.

समजा संकलित केल्यानंतर आपल्याला एक्झिक्युटेबल फाइल f5ar मिळेल. ध्वज वापरून त्याच्या वापराच्या शक्यतांची गणना करण्यासाठी तुम्ही लायब्ररीच्या आकाराचे विश्लेषण करू शकता -a: ./f5ar -a [папка поиска] [Perl-совместимое регулярное выражение]. संघाकडून पॅकेजिंग केले जाते ./f5ar -p [папка поиска] [Perl-совместимое регулярное выражение] [упаковываемый файл] [имя архива], आणि वापरून अनपॅक करणे ./f5ar -u [файл архива] [имя восстановленного файла].

कामाचे प्रात्यक्षिक

पद्धतीची प्रभावीता दर्शविण्यासाठी, मी सेवेतून कुत्र्यांच्या 225 पूर्णपणे विनामूल्य फोटोंचा संग्रह अपलोड केला आहे. Unsplash. त्यांच्यापैकी प्रत्येकामध्ये सामान्य वापरकर्त्याच्या फोटोंपेक्षा किंचित उच्च गुणवत्ता आहे, परंतु तरीही. एकूण आकारावर लायब्ररीच्या एन्कोडिंग वैशिष्ट्यांचा प्रभाव तटस्थ करण्यासाठी libjpeg वापरून त्यातील प्रत्येकाला पुन्हा एन्कोड करण्यात आले. संकुचित करण्यायोग्य डेटाचे सर्वात वाईट उदाहरण दर्शविण्यासाठी, dd वापरून यादृच्छिक 36-मीटर (एकूण आकाराच्या 5% पेक्षा किंचित जास्त) एकसमान वितरित फाइल व्युत्पन्न केली गेली.

चाचणी प्रक्रिया अगदी सोपी आहे:

$ ls
binary_data dogs f5ar
$ du -sh dogs/
633M dogs/
$ du -h binary_data
36M binary_data

$ ./f5ar -p dogs/ .*jpg binary_data dogs.f5ar
Reading compressing file... ok
Initializing the archive... ok
Analysing library capacity... done in 16.8s
Detected somewhat guaranteed capacity of 48439359 bytes
Detected possible capacity of upto 102618787 bytes
Compressing... done in 32.6s
Saving the archive... ok

$ ./f5ar -u dogs/dogs.f5ar unpacked
Initializing the archive... ok
Reading the archive file... ok
Filling the archive with files... done in 1.2s
Decompressing... done in 17.5s
Writing extracted data... ok

$ sha1sum binary_data unpacked
ba7ade4bc77881ab463121e77bbd4d41ee181ae9 binary_data
ba7ade4bc77881ab463121e77bbd4d41ee181ae9 unpacked
$ du -sh dogs/
563M dogs/

किंवा चाहत्यांसाठी स्क्रीनशॉट

तुम्ही बघू शकता, हार्ड ड्राइव्हवरील मूळ 633 + 36 == 669 मेगाबाइट्स डेटावरून, आम्ही ~563 चे कॉम्प्रेशन रेशो देऊन, अधिक छान 1,188 सह समाप्त केले. हा मूलगामी फरक शास्त्रीय पद्धती (जसे की tinyjpg) वापरून जेपीईजी फाइल्स ऑप्टिमाइझ करताना प्राप्त झालेल्या अत्यंत लहान नुकसानांद्वारे स्पष्ट केला जातो. साहजिकच, स्टेगॅनोग्राफिक कॉम्प्रेशन वापरताना, माहिती फक्त "हरवलेली" नसते, परंतु इतर डेटा एन्कोड करण्यासाठी वापरली जाते. शिवाय, F5 च्या वापरामुळे "ऑप्टिमाइज्ड" गुणांकांची संख्या पारंपारिक ऑप्टिमायझेशनच्या तुलनेत खूपच कमी आहे.

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

हॅब्रास्टोरेजवर बसत नसलेल्या प्रतिमांचे दुवे

मूळ - https://i.ibb.co/wNDLNcZ/1.jpg
सुधारित - https://i.ibb.co/qWvpfFM/1.jpg
फरक - https://i.ibb.co/2ZzhHfD/diff.jpg

त्याऐवजी एक निष्कर्ष

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

-> GitHub

स्रोत: www.habr.com