👨 👨‍👧‍👧 🏢 DVR मॉडल QCM-08DL के फाइल सिस्टम HDD का अध्ययन 🐍 🧡 🖐🏻

यह आलेख वीडियो फ़ाइलों के बड़े पैमाने पर निष्कर्षण के उद्देश्य से आठ-चैनल वीडियो रिकॉर्डर की हार्ड डिस्क की फ़ाइल संरचना का अध्ययन करने के लिए समर्पित है। लेख के अंत में सी में संबंधित कार्यक्रम का कार्यान्वयन है।

वीडियो रिकॉर्डर (संक्षिप्त डीवीआर) QCM-08DL वीडियो निगरानी प्रणाली में उपयोग किया जाता है और आठ-चैनल वीडियो और ऑडियो रिकॉर्डिंग के लिए अनुमति देता है। यह मॉडल, मेरी राय में, ऑपरेशन में सबसे सस्ता और एक ही समय में विश्वसनीय है। वीडियो संपीड़न प्रारूप लोकप्रिय H264 प्रारूप है। ऑडियो के लिए, संपीड़न प्रारूप ADPCM है। वीडियो और ऑडियो को डीवीआर के अंदर स्थापित एक मानक कंप्यूटर एसएटीए हार्ड ड्राइव (एचडीडी) पर रिकॉर्ड किया जाता है। डीवीआर का उपयोग करते हुए, उन्हें दिनांक और समय के अनुसार खोजकर रिकॉर्डिंग देखना संभव है। इसके अलावा, बाहरी माध्यम पर फ़ाइल में डेटा निकालना संभव है। सबसे पहले, एक यूएसबी ड्राइव में जो डीवीआर के यूएसबी इंटरफेस से जुड़ता है। दूसरी बात - डीवीआर के वेब इंटरफेस के माध्यम से कंप्यूटर को। परिणामी फ़ाइल का नाम लंबा है, और इसमें रिकॉर्डिंग की तारीख, प्रारंभ और समाप्ति समय, रिकॉर्डिंग चैनल और अन्य अतिरिक्त जानकारी शामिल है। फ़ाइल एक्सटेंशन ".264" है। इस तरह की फ़ाइल की सामग्री की एक परीक्षा ने मुझे यह स्पष्ट कर दिया कि मीडिया कंटेनर जिसमें ऑडियो और वीडियो स्ट्रीम पैक हैं, मानक से बहुत दूर है। डीवीआर के साथ आने वाले खिलाड़ी का उपयोग करके ऐसी फाइल खोली जा सकती है। खिलाड़ी बहुत असहज है। लेकिन इसके अलावा, आप एवीआई कंटेनर में रिपैकर प्रोग्राम का उपयोग कर सकते हैं, जिसमें यह भी शामिल है। यह प्रोग्राम वीडियो स्ट्रीम को रिप्रेजेंट करता है, इसे H264 फॉर्मेट में छोड़ देता है। और साउंड स्ट्रीम ADMCM से PCM में परिवर्तित हो जाता है, जो आकार में 4 गुना बढ़ जाता है। परिणाम एक .AVI फ़ाइल है जिसे किसी भी मानक खिलाड़ी द्वारा चलाया जा सकता है। मैं तुरंत ध्यान देता हूं कि यह रीपैकेजिंग प्रोग्राम बहुत असुविधाजनक है। यह आपको केवल एक फ़ाइल पर संचालन करने की अनुमति देता है। फ़ाइलों के एक सेट को वापस करने के लिए आपको उन्हें बदले में खोलना होगा।

निम्नलिखित कार्य निर्धारित किए गए थे।

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

पहला कार्य, पहली नज़र में, बहुत सरल लग सकता है: आपको बस कंप्यूटर से HDD कनेक्ट करने और एक्सप्लोरर में विभाजन खोलने की आवश्यकता है। हालांकि, वहाँ नुकसान कर रहे हैं। यह लेख पहले कार्य के लिए समर्पित है।

मुझे पहले से ही पता था कि DVR माइक्रोकंट्रोलर का सॉफ्टवेयर शेल लिनक्स के समान ऑपरेटिंग सिस्टम पर आधारित है। इसलिए, हार्ड डिस्क का विभाजन सबसे अधिक संभावना लिनक्स जैसा होगा। इसलिए, आपको लिनक्स कंप्यूटर की आवश्यकता है। मेरे मामले में, HDD की क्षमता 1TB है, OS Xubuntu के साथ एक कंप्यूटर। HDD को कंप्यूटर से कनेक्ट करने के बाद, मैं कई गीगाबाइट प्रति केवल एक विभाजन को देख पा रहा था। यह स्पष्ट रूप से नहीं है कि आपको क्या चाहिए। सेक्शन के अंदर रिकॉर्ड फॉर्मेट की तारीखों के नाम "YYYY-MM-DD" नाम के कई फोल्डर हैं। प्रत्येक फ़ोल्डर के अंदर प्रविष्टियों के अनुरूप कई फाइलें हैं। डीवीआर से निकालते समय उसी नाम की फाइलें जो प्राप्त की गई हैं। हालांकि, उनका आकार कई गुना छोटा है और विस्तार .264 नहीं है, लेकिन .nvr। यह माना जाना चाहिए कि ये वही एनवीआर फाइलें संबंधित 264 फाइलों (या उनके मीडिया स्ट्रीम) की कुंजी हैं, जिनमें से सामग्री मुख्य एचडीडी स्थान पर स्थित हैं। मैंने फ़ाइल फ़ोल्डर से डेटा को आगे के शोध के लिए एक अलग माध्यम में कॉपी किया।

मैंने शोध के लिए बहुत सारे सॉफ्टवेयर टूल का उपयोग किया: एक डिस्क एडिटर (यह एक बाइनरी फाइल एडिटर भी है) डिस्क एक्सप्लेयर (मैंने विन्क्स बाद में इस्तेमाल किया), सहायक गणना और फिक्सिंग परिणामों के लिए एमएस एक्सेल, सहायक और अंतिम कंसोल प्रोग्राम लिखने के लिए देव-सी ++ प्रोग्रामिंग वातावरण, आदि। इस लेख में मैं इस प्रक्रिया के बारे में बात करने की कोशिश करूंगा।

सबसे पहले, HDD के पहले सेक्टर को देखें (एक सेक्टर (1 LBA) 512 बाइट्स लेता है)। इस क्षेत्र में, एक नियम के रूप में, एक एमबीआर संरचना शामिल है। इसमें बूटलोडर और सामग्री अनुभागों की एक मूल तालिका शामिल है। इस क्षेत्र की संरचना, साथ ही साथ अनुभाग विवरण की संरचना नीचे दी गई है (विकिपीडिया से लिया गया है)।

जांच की गई एचडीडी के मामले में, हमारे पास निम्नलिखित हैं। ऊपर दी गई तालिकाओं के नीचे और नीचे की आकृति को देखते हुए, हम देखते हैं कि बूटलोडर गायब है। लेकिन हम विभाजन तालिका में अधिक रुचि रखते हैं। इसे लाल फ्रेम में हाइलाइट किया गया है। अंतिम दो बाइट्स (नीला भरण) - एमबीआर हस्ताक्षर। आप विभाजन तालिका से देख सकते हैं कि डिस्क दो खंडों में विभाजित है। पहले खंड (पीला भरण) के प्रकार के लिए कोड 0x0B है। यह एक FAT32 विभाजन है। दूसरे (नारंगी भरण) के प्रकार के लिए कोड 0x83 है। यह लिनक्स विभाजन (EXT के अर्थ में) में से एक है। विभाजन प्रकार कोड बाइट्स नीले रंग में परिचालित होते हैं।

एमबीआर क्षेत्र की एक पूरी डिक्रिप्शन अनुभागों की तालिका और उनके पैरामीटर नीचे दिए गए हैं।

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

पहले उदाहरण के रूप में EXT2 का उपयोग करके लिनक्स फाइल सिस्टम की संरचना और संगठन का अध्ययन करने के बाद, मैंने दूसरे खंड का अध्ययन करना शुरू किया।

जैसा कि आप अनुभाग तालिका से देख सकते हैं, दूसरा खंड सेक्टर 16016805 से शुरू होता है। EXT2 फाइल सिस्टम मैनुअल तथाकथित सुपरब्लॉक की उपस्थिति को इंगित करता है, जो कि अनुभाग की शुरुआत से 1024 बाइट्स पर स्थित है (यानी शुरुआत से दो सेक्टर)। हालाँकि, सेक्टर 16016805 + 2 = 16016807 खाली था। लेकिन इसकी संरचना में पहला सेक्टर 16016805 सुपरब्लॉक जैसा था। लेकिन इसकी सामग्री पूरी तरह से मैनुअल से सुपरब्लॉक की सामग्री के विवरण के अनुरूप नहीं थी। सुपरब्लॉक मुख्य ब्लॉक है, जिसमें फ़ाइल सिस्टम के कामकाज के लिए विभिन्न स्थिरांक और मापदंडों की एक प्रकार की तालिका होती है: विशेष रूप से अन्य आवश्यक ब्लॉकों के पदों और आकारों के पते, फ़ाइल रिकॉर्ड और निर्देशिकाओं के शीर्षलेख। इस खंड में आगे के शोध ने मुझे केवल एक निष्कर्ष पर पहुंचाया: डीवीआर अपनी अनूठी फाइल प्रणाली का उपयोग करता है।

भविष्य में, मैंने पहले खंड (सेक्टर 63) के पहले क्षेत्र को देखने और नीचे स्क्रॉल करने का फैसला किया। यह सेक्टर 65 (नीचे दो सेक्टर) सामग्री पर पाया गया था जो पूरी तरह से एफएस EXT2 सुपरब्लॉक की सामग्री के समान है, जिसे मैनुअल में वर्णित किया गया है। आगे के शोध से यह निष्कर्ष निकला कि HDD DVR का पहला विभाजन EXT2 विभाजन है, जिसे Xxuntu OS पर प्रदर्शित किया गया था, सामग्री की तालिका में 0x08 (EXT) के निशान की परवाह किए बिना! इस प्रकार, डीवीआर की हार्ड ड्राइव का पहला विभाजन EXT2 विभाजन है, जिस पर एनवीआर फाइलें दर्ज की जाती हैं, जो आवश्यक वीडियो रिकॉर्डिंग की कुंजी हैं।

मैं .264 फाइलों की संरचना के बारे में संक्षेप में लिखूंगा, जिनकी मैंने पहले भी जांच की थी। भविष्य में एचडीडी के दूसरे खंड का अध्ययन करने के लिए इस जानकारी की आवश्यकता होगी। जैसा कि किसी भी मीडिया कंटेनर में, "264" में सेवा की जानकारी और मीडिया टैग के साथ एक हेडर होता है, साथ ही ऑडियो और वीडियो की धाराएँ भी होती हैं जो एक के बाद एक छोटे ब्लॉक में आती हैं। फ़ाइल की शुरुआत से 0x84 बाइट्स के ऑफसेट में, कीवर्ड "MDVR96NT_2_R" पंजीकृत है। इस शब्द से पहले रिकॉर्डिंग की तारीख और समय से संबंधित बाइट्स हैं। लेकिन यह जानकारी फ़ाइल नाम में निहित है, इसलिए, यह यहां विशेष ध्यान देने योग्य नहीं है। उसके बाद शून्य का एक बहुत बाइट आता है। ऑडियो और वीडियो स्ट्रीम के साथ मुख्य जानकारी 65,536 बाइट्स की भरपाई में उत्पन्न होती है। वीडियो स्ट्रीम ब्लॉक एक 8-बाइट हेडर "01dcH264" से शुरू होता है ("00dcH264" भी पाया जाता है)। निम्नलिखित 4 बाइट्स बाइट्स में वीडियो स्ट्रीम के वर्तमान ब्लॉक के आकार का वर्णन करते हैं। शून्य के 4 बाइट्स (00 00 00 00) के बाद, वीडियो स्ट्रीम ब्लॉक स्वयं शुरू होता है। ऑडियो स्ट्रीम ब्लॉक का शीर्षक "03wb" है (हालांकि, मेरी टिप्पणियों के अनुसार, कुछ मामलों में हेडर का पहला चरित्र आवश्यक रूप से "0" नहीं था)। सूचना के 12 बाइट्स के बाद जो मुझे अभी तक पता नहीं चला है। और 17 वें बाइट के साथ शुरू - 160 बाइट्स की एक निश्चित लंबाई का एक ऑडियो स्ट्रीम। फ़ाइल के अंत में कोई टैग नहीं हैं।

हम एचडीडी के पहले विभाजन पर स्थित फाइलों और निर्देशिकाओं की संरचना का अध्ययन करने के लिए आगे बढ़ते हैं। जैसा कि ऊपर उल्लेख किया गया है, अनुभाग की सामग्री को Xununtu OS में एक नियमित एक्सप्लोरर के माध्यम से एक अलग माध्यम में कॉपी किया गया था। प्रत्येक निर्देशिका (डायरेक्टरी) में, nvr फाइलों के अलावा, "file_list" नाम की एक बाइनरी फ़ाइल है। नाम से देखते हुए, इसमें वर्तमान निर्देशिका में फ़ाइलों की सूची के बारे में जानकारी है। इस फाइल को बाइनरी एडिटर में खोलें (नीचे आंकड़ा देखें)। मैंने इस फ़ाइल की संरचना की जांच की, और यहां मूल रूप से दिलचस्प कुछ भी नहीं है। फ़ाइल में वांछित मीडिया स्ट्रीम के स्थान के बारे में कोई जानकारी नहीं है। फिर भी, मैं इस संरचना के बारे में संक्षेप में लिखूंगा। पहले 32 बाइट्स कुछ स्थिरांक के साथ एक हेडर हैं। अगले 16 बाइट्स वर्तमान निर्देशिका में दिनांक और समय और फ़ाइलों की संख्या से संबंधित हैं। इसके बाद स्थिरांक के 48 बाइट्स होते हैं। अगले - लगातार 8 बाइट्स, फ़ाइल रिकॉर्ड की शुरुआत का संकेत। अगला, 96 बाइट्स nvr फ़ाइल के पूर्ण पथ को दर्शाता है, जिसमें उसका नाम भी शामिल है। अगला - समय से संबंधित 24 बाइट्स (दिन की शुरुआत, वीडियो की शुरुआत और अंत) और वीडियो की अन्य विशेषताओं से बीते हुए सेकंड की संख्या। और इसी तरह, मौजूदा निर्देशिका में सभी एनवीआर फाइलों के लिए सादृश्य द्वारा। उनकी संख्या वर्तमान दिन के वीडियो की संख्या के बराबर है, जिसे वर्तमान निर्देशिका के नाम से दर्शाया गया है। इस फ़ाइल के लिए क्या है? जाहिर है, DVR इंटरफ़ेस के भीतर वीडियो की खोज को गति देने के लिए।

चलो nvr फ़ाइलों की संरचना का अध्ययन करने के लिए स्वयं आगे बढ़ते हैं। बाइनरी में एक ऐसी फ़ाइल की उपस्थिति (अधिक सटीक रूप से, एक हेक्साडेसिमल में) संपादक को नीचे दिए गए चित्र में दिखाया गया है। सामग्री संरचना के विवरण (जो मेरे लिए एक रहस्य बना हुआ था) के विवरण में जाने के बिना, मैंने सबसे बुनियादी मापदंडों पर प्रकाश डाला, जो कि पाया जाना महत्वपूर्ण है। ये 32-बिट (4-बाइट) मान हैं, जो प्रत्येक 32 बाइट्स में स्थित हैं, बाइट 40 से ऑफसेट से शुरू होते हैं। चित्रा में उन्हें लाल रंग में हाइलाइट किया गया है। भविष्य में, मुझे विश्वास हो गया कि यह वीडियो की कुंजी के लिए पर्याप्त है। मैं आपको याद दिलाता हूं कि इस प्रमुख पैरामीटर के मूल्य के 4 बाइट्स निम्नतम से उच्चतम तक स्थित हैं, लेकिन इसके विपरीत नहीं! यह अंकन पीसी प्रोसेसर की वास्तुकला के कारण है। आकृति में उदाहरण पहली निर्देशिका की पहली एनवीआर फ़ाइल दिखाता है। यह डीवीआर द्वारा बनाई गई पहली वीडियो रिकॉर्डिंग से मेल खाती है। जाहिर है, मापदंडों के मूल्य, जिन्हें मैंने कुंजी कहा था, उपरोक्त उदाहरण में पूर्णांकों का एक क्रम बनता है, शून्य से शुरू होता है और आरोही क्रम में जाता है। अन्य एनवीआर फाइलों की जांच करना, और उनमें इन निर्दिष्ट बाइट्स को बिल्कुल देखते हुए, पूर्णांक भी देखा गया था, आरोही। लेकिन यह क्रम स्वाभाविक रूप से खरोंच से नहीं शुरू हुआ, और कुछ मामलों में स्थानों में एक या दो संख्या में अंतराल देखा गया। उदाहरण के लिए (बुलडोजर से संख्या): 435, 436, 438, 439, 442, ... (या हेक्साडेसिमल में: B3010000, B4010000, B6010000, B7010000, BA010000, ...)।

चूक के साथ ऐसा क्रम एनवीआर फ़ाइलों पर दो या अधिक चैनलों से एक साथ दर्ज किए गए वीडियो के अनुरूप होता है। उदाहरण के लिए, यदि अनुक्रम "435, 436, 438, 439, 442, ..." एक चैनल से वीडियो को संदर्भित करता है, तो लापता मान (437, 440, 441) दूसरे चैनल से वीडियो से संबंधित होगा, जो उसी में किया गया था। समय में इंगित करें। मैं स्वयं उनके नाम के आधार पर संबंधित nvr फ़ाइलों को देखने और उनकी तुलना करके इस बारे में आश्वस्त था। इसमें कोई संदेह नहीं है कि उपरोक्त संख्या वीडियो से संबंधित कुछ हिस्सों की संख्या बनाती है। यह केवल इन नंबरों और डिस्क स्थान के समन्वय के बीच संबंध को उजागर करने के लिए रहता है जिस पर डेटा स्थित है।

इसके अलावा, यह पता लगाना था कि उपरोक्त संख्या वाले खंडों में क्या डेटा विभाजित है? पहली धारणा - डेटा ऑडियो और वीडियो की धाराएँ हैं, जिन्हें कंटेनर 264 में छोटे ब्लॉकों द्वारा दर्शाया गया है, और, जैसा कि कहा गया है, वीडियो स्ट्रीम के ब्लॉक के अलग-अलग आकार हैं। उसी समय, डीवीआर इन धाराओं को एकत्र करता है और बाहरी मीडिया में वीडियो निकालने के चरण में उन्हें कंटेनर 264 में पैक करता है। दूसरी धारणा यह है कि डीवीआर ऑडियो और वीडियो की धाराओं को कंटेनर 264 में शुरुआत में और वीडियो कैप्चर के दौरान पैक करता है। और उसी समय, पहले से ही उत्पन्न .264 फ़ाइल डेटा एचडीडी को लिखा जाता है, जो बाहरी माध्यम से इसके निष्कर्षण के परिणामस्वरूप निकला होगा। दूसरे खंड के बीच में कहीं-कहीं HDD स्पेस की खोज, साथ ही ऑडियो और वीडियो स्ट्रीम और उनके हेडर कंटेनर 264 में बाइट्स के साथ, मैं कंटेनर के हेडर में भी आया: MDVR9680T_2_R। इस हेडर के बाद, शून्य के कई बाइट्स भी थे। सामान्य तौर पर, अध्ययन से पता चला है कि ऊपर दो का दूसरा विकल्प है। इसलिए, वांछित .264 फ़ाइल प्राप्त करने के लिए, सबसे अधिक संभावना है, आपको बस उन सभी खंडों को एक साथ जोड़ने की आवश्यकता है जिनकी संख्या संबंधित एनवीआर फ़ाइल में समाहित है।

आइए एचडीडी पर खंड संख्या और निर्देशांक के बीच संबंधों की खोज शुरू करें।

कंटेनर 264 के डेटा की शुरुआत बहुत पहले वीडियो रिकॉर्डिंग (जहां सेगमेंट की संख्या शून्य से शुरू होती है) के साथ होती है, मुझे सेक्टर 16046629 (अनुभाग की शुरुआत से 29824 सेक्टर) पर मिले सर्च टूल के साथ। हम तथाकथित पैरामीटर के बारे में एक धारणा बना सकते हैं प्रारंभिक पूर्वाग्रह, जो वांछित निर्भरता का वर्णन करने वाले सूत्र में भाग लेंगे।

आइए विभिन्न चैनलों से वीडियो के लिए दो एनवीआर फाइलें लेते हैं जो एक ही समय में डीवीआर पर कब्जा कर लेते हैं। ऐसा करने के लिए, फ़ाइल नामों पर एक नज़र डालें। उदाहरण के लिए, “ch00000000000001-150330-160937-161035-02p101000000.nvr” और “ch00000000000004-150330-160000-163000-00p004000000 .nvr” फ़ाइलों द्वारा बताए गए वीडियो एक साथ रिकॉर्ड किए गए थे। पहला रिकॉर्ड 1 चैनल से 16:09:37 से 16:10:35 समय की रिकॉर्डिंग है। दूसरा रिकॉर्ड 4 चैनल से 16:00:00 से 16:30:00 समय तक का रिकॉर्ड है। दोनों प्रविष्टियाँ 30 मार्च, 2015 को बनाई गई थीं। समयरेखा पर, जाहिर है, पहले रिकॉर्ड का समय अंतराल दूसरे रिकॉर्ड के समय अंतराल का सबसेट है। मैं इस तथ्य को भी ध्यान में रखता हूं कि कम समय के अंतराल में (दो अंतराल के चौराहे पर) डीवीआर ने अन्य 6 चैनलों में से किसी से वीडियो कैप्चर नहीं किया। इन nvr फ़ाइलों की सामग्री को ब्राउज़ करें। हम यह सुनिश्चित करेंगे कि दूसरी लंबी फ़ाइल में लापता संख्या (खंड संख्या) आवश्यक रूप से पहली छोटी फ़ाइल में मौजूद है, पूरी तरह से और पूरी तरह से। सामान्य तरीके से DVR का उपयोग करते हुए, आपको पहले से जांच की गई nvr फ़ाइलों द्वारा संदर्भित कम से कम एक .264 फ़ाइलों को निकालने की आवश्यकता होती है। मान लें कि "ch00000000000001-150330-160937-161035-02p101000000.264" निकाला गया था। इसे बाइनरी एडिटर में खोलें। जैसा कि पहले ही उल्लेख किया गया है, इस फ़ाइल की शुरुआत में, कीवर्ड "MDVR96NT_2_R" से पहले इस फ़ाइल में निहित वीडियो रिकॉर्डिंग की तारीख और समय के अनुरूप अद्वितीय बाइट्स हैं। हम इन सभी बाइट्स को लिखते हैं, जो नॉनज़ेरो से शुरू होता है और हेडर के साथ समाप्त होता है (इस वीडियो रिकॉर्डिंग के लिए अद्वितीय बाइट श्रृंखला, बेहतर)। इसके अलावा, फ़ाइल की शुरुआत से बाइट्स के इस स्ट्रिंग की ऑफसेट लिखें। यह ध्यान दिया जाना चाहिए कि निकाली गई .264 फ़ाइल की शुरुआत में शून्य के अतिरिक्त 4 बाइट्स हैं। .264 फ़ाइल के पहले 512 बाइट्स और डिस्क स्पेस के क्षेत्र की तुलना करने से यह ध्यान देने योग्य हो गया, जिसमें से .264 फ़ाइलों में से एक की सामग्री शुरू होती है (लगभग किसी भी फाइल सिस्टम की एक फाइल हमेशा सेक्टर, इसके अलावा, एक क्लस्टर) की शुरुआत में होती है। यही है, सूचना .264 फ़ाइल को 4 बाइट्स द्वारा दाईं ओर अग्रिम में स्थानांतरित कर दिया गया है। किसी भी .264 फ़ाइल का आकार (बाइट्स) 512 का एक गुणक है जो आकार से पहले नंबर 4 को घटाने के बाद ही होता है। आइए उस क्षेत्र की खोज शुरू करें जहां से जांच की गई ।264 फ़ाइल शुरू होती है। डिस्क संपादक में, खोज फ़ंक्शन शुरू करें। वांछित मूल्य के क्षेत्र में, पहले से लिखा बाइट्स का एक अनूठा स्ट्रिंग दर्ज करें। खोज को गति देने के लिए, पहले से घटाकर "ऑफसेट द्वारा खोज" फ़ील्ड में ऑफ़सेट मान दर्ज करें, खोज शुरू करें। कुछ घंटों बाद, खोज सफल रही। हम उस क्षेत्र की संख्या लिखते हैं जिसमें अद्वितीय शीर्षक पाया जाता है। इसे मान दें। हम इस वीडियो के लिए nvr फ़ाइल की सामग्री को देखते हैं। हम पहले खंड की संख्या (ऑफसेट 40 पर 4 बाइट्स) लिखते हैं। इसे b का मान बताएं। कुल मिलाकर, जबकि हम शून्य खंड संख्या (पहले वीडियो रिकॉर्डिंग में) के लिए डिस्क सेक्टर नंबर (16046629) जानते हैं और खंड संख्या बी के लिए डिस्क s के पाए गए सेक्टर की संख्या बस लिखी हुई है। आप अनुमानित खंड आकार की गणना कर सकते हैं: (s-16046629) / (b-0)। गणना करने के बाद, मुझे मान 128 मिला। इस प्रकार, खंड का आकार 128 डिस्क क्षेत्रों (LBA), या 128 * 512 = 65536 बाइट्स के बराबर है!

मैंने सभी संदेह को दूर करने के लिए एक और अतिरिक्त दिलचस्प प्रयोग किया। यह नीचे वर्णित है।

सेक्टर s की शुरुआत से, हम डिस्क पर एक क्षेत्र का चयन करते हैं, जिसका आकार .264 फ़ाइल के आकार के बराबर होता है जो इस क्षेत्र से शुरू होता है।यदि मेरा अनुमान सही है, तो दूसरे .264 फ़ाइल के सेगमेंट, जो पहले एक के साथ एक साथ एचडीडी पर कैप्चर किए गए थे, चयनित क्षेत्र में आ जाएंगे। इस क्षेत्र को एक फ़ाइल में सहेजें (एक छवि बनाएं)। 65,536 बाइट्स (खंड आकार) की फ़ाइलों में परिणामी छवि को काटें। यह कुल कमांडर में "स्प्लिट फाइल" फ़ंक्शन का उपयोग करके किया जा सकता है। इसे टुकड़े M1, M2, M3, ... होने दें। इसी तरह, हमने अध्ययन की गई .264 फ़ाइल को काट दिया (जो कि डीवीआर से उपयोगकर्ता के अनुकूल तरीके से निकाली गई थी), लेकिन पहले शून्य के 4 बाइट्स को हटा दिया। इसे K1, K2, K3, के टुकड़े होने दें ...। कुल कमांडर में "तुलना द्वारा सामग्री" फ़ंक्शन का उपयोग करना, हम छवि के टुकड़ों और टुकड़ों की तुलना .264 फ़ाइल से करते हैं। (K1 के साथ M1, K2 के साथ M2, आदि), इसी nvr फ़ाइल से खंड संख्या द्वारा निर्देशित। परिणाम निम्नलिखित है। मान लीजिए कि (बुलडोजर से संख्या), एनवीआर में संख्याओं की श्रृंखला इस प्रकार है: 435, 436, 438, 439, 442)... इस स्थिति में, M1 = K1, M2 = K2, M4 = K3, M5 = K4, M8 = K5, .... यही है, जिस टुकड़े में छवि फ़ाइल विभाजित की गई थी और .264 फ़ाइल अनुक्रम में चूक के अनुसार छवि फ़ाइल के टुकड़ों की संख्या में संबंधित अग्रिम को ध्यान में रखते हुए, एक दूसरे के बराबर हो जाती है। यहाँ यह है!

कुल में, हमने अनुमानित निर्भरता प्राप्त की: S = 16046629 + 128 * d, जहाँ d nvr फ़ाइल में खंड संख्या है, और S HDD पर सेक्टर संख्या है, जो डिस्क की शुरुआत से ही खंड की सामग्री से शुरू होती है। खंड का आकार - 128 सेक्टर। उपरोक्त सूत्र दूसरे खंड के अस्तित्व को ध्यान में नहीं रखता है। निर्भरता केवल HDD से 1TB तक के विशिष्ट उदाहरण के लिए पाई जाती है। शायद अगर आप DVR HDD में एक अलग क्षमता रखते हैं, तो स्थिरांक एक अलग रूप लेंगे।

सूत्र की वैधता को सत्यापित करने के लिए, हम इसी nvr फ़ाइल द्वारा निर्देशित, कुछ अन्य मनमाने ढंग से .264 फ़ाइल के पहले खंड की स्थिति की गणना करते हैं। फ़ाइल नाम में दिनांक और समय पर ध्यान देते हुए, गणना क्षेत्र पर स्थित .264 हेडर में पहले बाइट्स के साथ उनकी तुलना करें। बाइट्स व्यक्तिगत रूप से नंबर, माह, वर्ष, घंटे, मिनट, सेकंड, फ़ाइल नाम में अस्थायी डेटा के अनुरूप हैं। इसलिए, "नाखून मारा"! हम nvr फ़ाइल में .264 फ़ाइल के लिए अग्रिम में गणना करते हैं, सीएस सेगमेंट की संख्या। सामान्य तौर पर, उनकी संख्या cs = sf / 32-1 है, जहाँ sf nvr फ़ाइल का आकार है। यदि .264 फ़ाइल में सेगमेंट सेगमेंट होते हैं, तो उसका आकार cs * 65536 + 4 के बराबर होना चाहिए (बाइट्स में सेगमेंट साइज़ के सेगमेंट की संख्या, शून्य के समान बाइट्स के 4)। और यह वास्तव में है!

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

मैं 4-बाइट मापदंडों के एक भाग को डिक्रिप्ट करने में कामयाब रहा। विभाजन के बढ़ने की तिथि और समय को नीले रंग में हाइलाइट किया गया है। दिनांक और समय एक विशेष संकेतन "यूनिक्स समय" में प्रस्तुत किए गए हैं (1 जनवरी, 1970 को आधी रात के बाद से समाप्त सेकंड की संख्या)। उपरोक्त उदाहरण में, "03 7E 74 54" (दशमलव मान 1416920579) "ट्यू, 25 नवंबर 2014 13:02:59 GMT" से मेल खाती है। मूल्यों का अनुवाद करने के लिए, मैंने एक विशेष ऑनलाइन कैलकुलेटर का उपयोग किया। मान 65536 को बैंगनी फ्रेम में परिचालित किया गया है। यह संभव है कि DVR प्रोग्राम के अंदर फ़ाइल सिस्टम दुभाषिया सुपरब्लॉक की इस स्थिति को संदर्भित करता है जब ब्लॉक आकार पढ़ा जाता है (पिछले संदर्भ में, मुझे ब्लॉक सेगमेंट कहा जाता है)। मान 1 को हरे फ्रेम में हाइलाइट किया गया है। उनमें से एक संभवतः तथाकथित की शुरुआत की स्थिति को इंगित करता है। बिटमैप (खंड की शुरुआत से ब्लॉक की संख्या में)। वास्तव में,अग्रिम में, जानकारी की शुरुआत पाई गई, सेक्टर 16016933 (16016805 + 128 * 1) पर एक बिटमैप के समान कुछ। मान 233 को लाल फ्रेम में हाइलाइट किया गया है। यह ठीक इन खंडों की शुरुआत से .264 वीडियो रिकॉर्डिंग की स्थिति है: 16016805 + 128 * 233 = 16046629।

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

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

मैंने निर्देशिकाओं को स्कैन करने के लिए पुनरावृत्ति का उपयोग नहीं किया, यह देखते हुए कि निर्देशिकाओं का प्रारूप तय हो गया है और इसमें दो स्तरों का जुड़ाव है। तदनुसार, मैंने दो चक्र लागू किए: जब तक वे समाप्त नहीं हो जाते, तब तक फ़ोल्डर्स के माध्यम से चलाते हैं और प्रत्येक फ़ोल्डर में फ़ाइलों के माध्यम से उसी स्थिति में चलते हैं। फ़ाइलों को पढ़ने के लिए, मैंने फोपेन फ़ंक्शन का उपयोग किया। एचडीडी क्षेत्रों के साथ काम करने के लिए, मैंने फाइलों के साथ काम करने के लिए WinAPI कार्यक्षमता का उपयोग किया। प्रोग्राम कोड पर चलते हैं।

पुस्तकालयों को ऐसी जरूरत है।

#include <windows.h> #include <stdio.h> #include <string.h>

और मैंने कुछ फ़ोरम से इन फ़ंक्शंस को पूरी तरह से कॉपी किया।

 HANDLE openDevice(int device) { HANDLE handle = INVALID_HANDLE_VALUE; if (device <0 || device >99) return INVALID_HANDLE_VALUE; char _devicename[20]; sprintf(_devicename, "\\\\.\\PhysicalDrive%d", device); // Creating a handle to disk drive using CreateFile () function .. handle = CreateFile(_devicename, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); return handle; } HANDLE openOutputFile(const char * filename) { return CreateFile ( filename, // Open Two.txt. GENERIC_WRITE, // Open for writing 0, // Do not share NULL, // No security OPEN_ALWAYS, // Open or create FILE_ATTRIBUTE_NORMAL, // Normal file NULL); // No template file }

प्रतिलिपि फ़ंक्शन में एक रैखिक निर्भरता सूत्र होता है, जो ऊपर के सिद्धांत में दिखाई दिया।

 void copy(HANDLE device, HANDLE file, unsigned long int s){ LONG HPos; LONG LPos; __int64 sector; sector = 16046629+128*s; HPos = (sector*512)>>32; LPos = (sector*512); SetFilePointer (device, LPos, &HPos, FILE_BEGIN); DWORD dwBytesRead; DWORD dwBytesWritten; unsigned char buf[65536]; ReadFile(device, buf, 65536, &dwBytesRead, NULL); WriteFile(file, buf, dwBytesRead, &dwBytesWritten, NULL); }

मुख्य कार्य भी काफी सरल है।

 int main(){ HANDLE hdd = openDevice(1); //    HDD  DVR,    ; SetFilePointer (hdd, 0, NULL, FILE_BEGIN); DWORD dwBytesRead; char name[100]; unsigned int bl; //  ; unsigned int N; // ; unsigned long int pt; //  ; WIN32_FIND_DATA fld,fld1; //   nvr   ; HANDLE hf,hf1; hf=FindFirstFile("E:\\DVR\\*",&fld); FindNextFile(hf,&fld);// "."; FindNextFile(hf,&fld);// ".."; do{ char *str = new char; sprintf(str,"%s%s%s","E:\\DVR\\",fld.cFileName,"\\*.nvr"); printf("\n\nFOLDER: %s\n\n",str); hf1=FindFirstFile(str,&fld1); do{ FILE *nvr; sprintf(name,"%s%s%s%s","E:\\DVR\\",fld.cFileName,"\\",fld1.cFileName); nvr=fopen(name,"rb"); name[strlen(name)-3]='2'; //   ,  name[strlen(name)-2]='6'; // ; name[strlen(name)-1]='4'; HANDLE out = openOutputFile(name); SetFilePointer(out, 4, NULL, FILE_BEGIN); //  "",  4      (  ); bl=0; N=fld1.nFileSizeLow/32-1; //   (); printf("\t%s\n\t%i Blocks\n\n",fld1.cFileName,N); for(bl=0;bl<N;bl++){ //  ; fseek(nvr,40+32*bl,SEEK_SET); //; fread(&pt,1,4,nvr); // ; copy(hdd,out,pt); //  ; } CloseHandle(out); fclose(nvr); }while(FindNextFile(hf1,&fld1)); FindClose(hf1); delete str; }while(FindNextFile(hf,&fld)); FindClose(hf); CloseHandle(hdd); system("PAUSE"); return 0; }

पेंटियम 4 प्रोसेसर और पीसीआई एसएटीए नियंत्रक के साथ एक पुराने कंप्यूटर पर, कार्यक्रम सफलतापूर्वक 7 घंटे के औसत में कई हजार .264 फ़ाइलों के साथ पूर्ण एचडी पर अंत में स्थानांतरित हो गया। एक नए कंप्यूटर पर - तीन गुना तेज। जैसा कि मैंने पहले ही उल्लेख किया है, कार्यक्रम सार्वभौमिक नहीं है, सभी स्थिरांक और चर HDD से 1TB तक मेरे विशिष्ट मामले में समायोजित किए जाते हैं। हालांकि, आप थोड़ा अधिक काम कर सकते हैं और इसे सार्वभौमिक बना सकते हैं, इसके लिए एक ग्राफिकल इंटरफ़ेस बना सकते हैं।

लेख के दूसरे भाग में मैं लिखूंगा कि "264" कंटेनर से मानक "एवीआई" कंटेनर में वापस जाने के लिए "इसे स्वयं कैसे करें"।

DVR मॉडल QCM-08DL के फाइल सिस्टम HDD का अध्ययन

More articles: