परिचय

डिजिटल जांचों में जब कोई फ़ाइल अपने मूल संग्रह माध्यम से बाहर निकलती है, तो वह अनपेक्षित बदलाव के लिए संवेदनशील हो जाती है। यहाँ तक कि एक दिखने में मामूली रूपांतरण—जैसे डिस्क इमेज को E01 से RAW में बदलना, लॉग फ़ाइल को संपीड़ित करना, या कोर्टरूम प्रस्तुति के लिए PDF तैयार करना—हैश को भ्रष्ट कर सकता है, टाइमस्टैम्प हटाकर दे सकता है, या छुपे हुए गुणों को मिटा सकता है जो बाद में विशेषज्ञ के गवाही में महत्वपूर्ण हो जाते हैं। यह लेख सम्पूर्ण रूपांतरण जीवनचक्र को कवर करता है, साक्ष्य तैयार करने से लेकर अंतिम आउटपुट को सत्यापित करने तक, पुनरुत्पादनीयता, ऑडिटेबिलिटी और कानूनी प्रतिरक्षा पर ध्यान केंद्रित करते हुए। यहाँ प्रस्तुत सिद्धांत उन सभी स्थितियों में लागू होते हैं चाहे आप कॉरपोरेट ब्रीच, कानून‑प्रवर्तन की जप्ती या आंतरिक ऑडिट पर काम कर रहे हों, और यह मानते हैं कि आप भरोसेमंद, गोपनीयता‑सुरक्षित उपकरणों का उपयोग कर रहे हैं, जैसे क्लाउड‑आधारित सेवा convertise.app जहाँ उपयुक्त हो।

1. नियंत्रित रूपांतरण वातावरण स्थापित करना

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

2. बेसलाइन हैश और मेटाडेटा कैप्चर करना

फ़ॉरेंसीक अखंडता की रीढ़ मूल साक्ष्य पर किसी भी रूपांतरण से पहले गणना किया गया हैश (MD5, SHA‑1, SHA‑256, या बेहतर बनाम SHA‑512) है। हैश गणना को NIST SP 800‑90 मानकों के अनुरूप टूल से किया जाना चाहिए, और प्राप्त मान को फ़ाइल के मूल मेटाडेटा के साथ रिकॉर्ड किया जाना चाहिए: निर्माण, संशोधन और एक्सेस टाइमस्टैम्प; फ़ाइल सिस्टम गुण; और डिस्क इमेज के लिये सेक्टर‑स्तर के विवरण जैसे पार्टिशन टेबल और फ़ाइल सिस्टम सिग्नेचर। सर्वोत्तम अभ्यास है कि कम से कम दो स्वतंत्र हैशिंग युटिलिटीज़ से हैश कैप्चर किया जाए, और किसी भी विसंगति को संभावित छेड़छाड़ के साक्ष्य के रूप में दस्तावेज़ किया जाए। रिकॉर्ड किया गया हैश हर आगे के सत्यापन चरण का रेफ़रेंस पॉइंट बन जाता है।

3. सही लक्ष्य प्रारूप चुनना

हर रूपांतरण समान नहीं होता। रूपांतरण का निर्णय जांच के लक्ष्य पर आधारित होना चाहिए: संरक्षण, विश्लेषण, या प्रस्तुति। संरक्षण के लिये, RAW (dd) या E01 जैसे लॉसलेस, सेक्टर‑दर‑सेक्टर प्रारूप को प्राथमिकता दी जानी चाहिए; ये स्रोत माध्यम की सटीक बाइट अनुक्रम को बरक़रार रखते हैं। जब विश्लेषण के टूल केवल किसी विशिष्ट कंटेनर (जैसे AFF पढ़ने वाला फॉरेंसिक सूट) को स्वीकार करते हैं, तो उस स्वरूप में रूपांतरण न्यायसंगत है, लेकिन मूल की अपरिवर्तित कॉपी ज़रूर रखनी चाहिए। प्रस्तुति के लिये PDF‑/A या TIFF फाइल उपयुक्त हो सकती है, फिर भी रूपांतरण पाइपलाइन को स्रोत का चेकसम आउटपुट फ़ाइल के मेटाडेटा में एम्बेड करना चाहिए, ताकि दोनों के बीच एक सत्यापन योग्य लिंक बन सके। वह स्वरूप चुनें जो स्वाभाविक रूप से मेटाडेटा को सपोर्ट करता हो (जैसे AFF), इससे यह लिंक आसान हो जाता है।

4. ऑडिट ट्रेल के साथ रूपांतरण करना

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

5. रूपांतरण‑पश्चात अखंडता सत्यापित करना

सत्यापन केवल सरल हैश तुलना से अधिक है। लॉसलेस स्वरूपों के लिये बाइट‑दर‑बाइट तुलना (जैसे Unix पर cmp) संभव और आवश्यक है, जब लक्ष्य स्वरूप इसकी अनुमति देता हो। लॉसी या परिवर्तनित स्वरूपों के लिये, सत्यापन को साक्ष्यात्मक मूल्य को संरक्षित करने पर केंद्रित होना चाहिए: सुनिश्चित करें कि टाइमस्टैम्प, एम्बेडेड EXIF या NTFS के वैकल्पिक डेटा स्ट्रीम, और कोई भी छुपी फ़ाइल गुण रूपांतरण में जीवित रहे। exiftool या fsstat जैसे टूल्स इन गुणों को पूर्व‑और‑पश्चात निकाल कर तुलना कर सकते हैं। किसी भी विचलन को दस्तावेज़, समझाया और जहाँ संभव हो सुधारना चाहिए (उदाहरण के लिए, मूल हैश को नई फ़ाइल के मेटाडेटा में कस्टम XMP टैग के माध्यम से एम्बेड करना)।

6. पूरे प्रक्रिया में चेन‑ऑफ‑कस्टडी दस्तावेज़ीकरण

चेन‑ऑफ‑कस्टडी लॉग वह कालक्रमीय रिकॉर्ड है जिसमें हर व्यक्ति, हर क्रिया और हर स्थान शामिल है जहाँ साक्ष्य रहा। रूपांतरण चरण इस श्रृंखला में एक नया नोड जोड़ता है। रूपांतरण के लिये लॉग एंट्री में होना चाहिए:

• रूपांतरण की तिथि, समय और UTC ऑफ़सेट।
• विश्लेषक का नाम और कार्यस्थल पहचानकर्ता।
• प्रयुक्त सटीक कमांड लाइन या API अनुरोध।
• रूपांतरण से पहले स्रोत फ़ाइल का हैश।
• रूपांतरण के बाद प्राप्त फ़ाइल का हैश।
• रूपांतरण का कारण (संरक्षण, विश्लेषण, या प्रस्तुति)।
• उपयोग किए गए संपीड़न सेटिंग्स या क्वालिटी पैरामीटर।

इन जानकारियों को सीधे परिवर्तित फ़ाइल में, एक समर्पित मेटाडेटा ब्लॉक में एम्बेड करने से एक स्व‑वर्णनात्मक वस्तु बनती है, जिसे बाहरी लॉग खो जाने पर भी बाद में जाँचा जा सकता है।

7. बड़े पैमाने पर और बैच रूपांतरण संभालना

जांचें अक्सर सैकड़ों गीगाबाइट साक्ष्य शामिल करती हैं। बैच रूपांतरण स्क्रिप्ट को निर्धारक (deterministic) और पुनरावृत्त्य (repeatable) होना चाहिए। एक आम पैटर्न है कि एक मैनिफेस्ट फ़ाइल (CSV या JSON) बनायी जाए जिसमें प्रत्येक स्रोत फ़ाइल, उसका बेसलाइन हैश, और इच्छित लक्ष्य स्वरूप सूचीबद्ध हो। स्क्रिप्ट मैनिफेस्ट पढ़ती है, प्रत्येक प्रविष्टि को प्रोसेस करती है, रूपांतरित फ़ाइल को नियंत्रित आउटपुट निर्देशिका में लिखती है, और एक परिणाम लॉग में नई पंक्ति जोड़ती है जिसमें दोनों हैश, एग्ज़िट कोड, और किसी भी चेतावनी शामिल हों। संस्करण‑नियंत्रित मैनिफेस्ट यह सुनिश्चित करता है कि किसी कोर्ट द्वारा पुनः चलाने की माँग पर एकदम वही रूपांतरण दोबारा किया जा सके, और साथ ही ऑडिटर यह सत्यापित कर सकें कि कोई फ़ाइल छूटी न गई हो या दो बार प्रोसेस न हुई हो।

8. एन्क्रिप्टेड या सुरक्षित साक्ष्य से निपटना

एन्क्रिप्टेड कंटेनर—TrueCrypt वॉल्यूम, BitLocker‑सुरक्षित ड्राइव, या पासवर्ड‑सुरक्षित PDFs—एक विशिष्ट चुनौती प्रस्तुत करते हैं। सही फ़ॉरेंसिक दृष्टिकोण यह है कि एन्क्रिप्टेड कंटेनर को उसकी कच्ची (raw) अवस्था में प्राप्त किया जाए और एन्क्रिप्शन पैरामीटर (एल्गोरिद्म, कुंजी लंबाई, सॉल्ट) का दस्तावेज़ किया जाए, बिना अधिग्रहण मशीन पर डिक्रिप्शन किए। यदि विश्लेषण के लिये डिक्रिप्शन आवश्यक है, तो इसे एक अलग, एयर‑गैप्ड सिस्टम पर किया जाना चाहिए, जहाँ डिक्रिप्शन कुंजी को ठीक‑ठाक दस्तावेज़ित और प्रमाणीकरण किया गया हो। डिक्रिप्शन के बाद उत्पन्न प्लेनटेक्स्ट फ़ाइल को रूपांतरित किया जा सकता है, लेकिन एन्क्रिप्टेड मूल और डिक्रिप्टेड कॉपी दोनों को अपने‑अपने हैश के साथ बरकरार रखा जाना चाहिए, ताकि साक्ष्य त्रेस सुरक्षित रहे।

9. कानूनी विचार और स्वीकृति

अदालतें डिजिटल साक्ष्य के किसी भी रूपांतरण की तीव्रता से जांच करती हैं। स्वीकृति मानकों (जैसे Daubert, Frye) को पूरा करने के लिये रूपांतरण प्रक्रिया को होना चाहिए:

1. वैज्ञानिक रूप से सुदृढ़: व्यापक रूप से स्वीकृत टूल्स और तरीकों पर आधारित।
2. पारदर्शी: सभी चरण पूर्ण रूप से दस्तावेज़ित और पुनरुत्पादनीय।
3. मान्यीकृत: टूल का आउटपुट ज्ञात‑अच्छे नमूनों के विरुद्ध बेंचमार्क किया गया हो।
4. स्वतंत्र: आदर्श रूप से दूसरे विश्लेषक या बाहरी पीयर रिव्यू द्वारा सत्यापित।

जब तीसरे‑पक्ष क्लाउड सेवा का उपयोग हो, तो जांचकर्ता को एक सर्विस लेवल एग्रीमेंट (SLA) प्राप्त करना चाहिए जिसमें डेटा‑हैंडलिंग क्लॉज़ हों, और any certification documents (ISO 27001, SOC 2) को रखे जो प्रदाता की गोपनीयता और अखंडता के प्रति प्रतिबद्धता दर्शाते हों।

10. रूपांतरित साक्ष्य का अभिलेखीय भंडारण

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

11. सर्वोत्तम‑प्रैक्टिस चेक‑लिस्ट का सारांश

• आइसोलेट करें रूपांतरण कार्यस्थल को और जहाँ संभव हो राइट‑ब्लॉकिंग उपयोग करें।
• रिकॉर्ड करें बेसलाइन हैश और पूर्ण मेटाडेटा किसी भी परिवर्तन से पहले।
• सेलेक्ट एक लक्ष्य स्वरूप जो जांच लक्ष्य के अनुरूप हो और आवश्यक गुणों को बरकरार रखे।
• एनेबल करें विस्तृत लॉग या ऑडिट ट्रेल प्रत्येक रूपांतरण कमांड या API कॉल के लिए।
• कम्प्यूट करें पोस्ट‑रूपांतरण हैश और इसे पूर्वनिर्धारित सत्यापन योजना से तुलना करें।
• डॉक्यूमेंट करें रूपांतरण चरण को चेन‑ऑफ‑कस्टडी लॉग में विस्तृत रूप से, और मुख्य विवरण फ़ाइल में एम्बेड करें।
• उज़ करें निर्धारक मैनिफेस्ट बैच प्रोसेसिंग के लिये और उन्हें वर्शन कंट्रोल के तहत रखें।
• ट्रीट एन्क्रिप्टेड कंटेनर्स को अलग साक्ष्य मानें; केवल आवश्यक होने पर डिक्रिप्ट करें और एन्क्रिप्टेड व डिक्रिप्टेड दोनों कॉपी रखें।
• वैलिडेट करें रूपांतरण टूल का आउटपुट ज्ञात‑अच्छे टेस्ट डेटा से और प्राप्त करें पीयर वैरिफिकेशन।
• स्टोर करें रूपांतरित वस्तुओं को WORM‑कम्प्लायंट रिपॉज़िटरी में, नियमित फ़िक्सिटी चेक के साथ।

इन चरणों का पालन करने से एक सामान्य फ़ाइल रूपांतरण एक फ़ॉरेंसिक‑साउंड ऑपरेशन बन जाता है, जिससे डिजिटल वस्तुओं का साक्ष्यात्मक भार उनके जप्ति से लेकर कोर्ट में प्रस्तुतिकरण तक संरक्षित रहता है।