পরিচিতি

ডিজিটাল তদন্তে কোনো ফাইল তার মূল সংরক্ষণ মিডিয়া ছেড়ে গেলে তা অনিচ্ছাকৃত পরিবর্তনের দিকে প্রবণ হয়ে যায়। এমনকি একটি নিঃসন্দেহে নির্দোষ রূপান্তর—ডিস্ক ইমেজকে E01 থেকে RAW-এ পরিবর্তন করা, লগ ফাইল কম্প্রেস করা, অথবা আদালতে উপস্থাপনের জন্য PDF তৈরি করা—হ্যাশকে নষ্ট করতে পারে, টাইমস্ট্যাম্প মুছে ফেলতে পারে, অথবা লুকায়িত অ্যাট্রিবিউট মুছে দিতে পারে, যা পরে কোনও বিশেষজ্ঞের সাক্ষ্য দেওয়ার সময় গুরুত্বপূর্ণ হয়ে ওঠে। এই নিবন্ধটি পূর্ণ রূপান্তর জীবনচক্রের মধ্য দিয়ে অগ্রসর হয়, প্রমাণ প্রস্তুতি থেকে চূড়ান্ত আউটপুট যাচাই পর্যন্ত, পুনরুৎপাদনযোগ্যতা, অডিটযোগ্যতা এবং আইনি সুরক্ষার উপর জোর দিয়ে। এখানে বর্ণিত নীতিমালা আপনি কর্পোরেট লিক, আইন প্রয়োগ সংস্থার জব্দ, অথবা অভ্যন্তরীণ অডিট যেটি‑ই করুন, প্রযোজ্য, এবং এটা বিশ্বাসযোগ্য, গোপনীয়তা‑সম্মানজনক টুলের ব্যবহারের অনুমান করে, যেমন convertise.app‑এ প্রস্তাবিত ক্লাউড‑ভিত্তিক সেবা, যেখানে প্রয়োজন।

1. একটি নিয়ন্ত্রিত রূপান্তর পরিবেশ প্রতিষ্ঠা

প্রথম বাইট স্পর্শ করার আগে, অডিটরদের রূপান্তর যেখানে ঘটবে সেই পরিবেশকে লক‑ডাউন করতে হবে। এটি শুরু হয় একটি রাইট‑ব্লকড ওয়ার্কস্টেশন বা পরিচিত‑ভাল ফোরেন্সিক ইমেজ (যেমন BitLocker‑সুরক্ষিত রাইট‑অনস ইউএসবি) থেকে বুট করা ফোরেন্সিক ওয়ার্কস্টেশন দিয়ে। রূপান্তরের জন্য ব্যবহৃত সমস্ত সফটওয়্যার ইনভেন্টরি‑চেকেড, ডিজিটালি সাইনড এবং ভার্সন‑কন্ট্রোলেড হতে হবে। বাইনারি হ্যাশ যাচাইযোগ্য এমন ওপেন‑সোর্স টুলকে অগ্রাধিকার দেওয়া উচিত, কারণ ক্লোজড‑সোর্স বাইনারি অডকুমেন্টেড আক্রমণ পয়েন্ট উপস্থাপন করে। একবার ওয়ার্কস্টেশন আলাদা করা হলে, একটি নির্ধারিত, এনক্রিপ্টেড কর্ম ডিরেক্টরি তৈরি করা উচিত; তার পথ ও অনুমতি কেস‑লগে রেকর্ড করা হয়, এবং ডিরেক্টরিটিকে রাইট‑অনস মিডিয়ায় সংরক্ষণ করা যায় যখন সম্ভব। এই ধাপগুলি একটি পুনরুৎপাদনযোগ্য বেসলাইন তৈরি করে, যা রূপান্তর প্রক্রিয়া কোনও অতিরিক্ত ভেরিয়েবল প্রবেশ করায়নি তা প্রদর্শনকে সহজ করে।

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. বৃহৎ পরিমাণ ও ব্যাচ রূপান্তল পরিচালনা

অনুসন্ধান প্রায়শই শতগুলো গিগাবাইট প্রমাণ জড়িত করে। ব্যাচ রূপান্তর স্ক্রিপ্টগুলি নির্ধারিত ও পুনরাবৃত্তিযোগ্য হতে হবে। একটি সাধারণ প্যাটার্ন হল একটি ম্যানিফেস্ট ফাইল (CSV বা JSON) তৈরি করা, যেখানে প্রতিটি সোর্স ফাইল, তার বেসলাইন হ্যাশ এবং কাঙ্খিত টার্গেট ফরম্যাট তালিকাভুক্ত থাকে। স্ক্রিপ্টটি ম্যানিফেস্ট পড়ে, প্রতিটি এন্ট্রি প্রক্রিয়া করে, নিয়ন্ত্রিত আউটপুট ডিরেক্টরিতে রূপান্তরিত ফাইল লিখে, এবং ফলাফল লগে একটি নতুন লাইন যোগ করে যা উভয় হ্যাশ, একজিট কোড এবং যেকোনো ওয়ার্নিং ধারণ করে। ভার্সন‑কন্ট্রোলড ম্যানিফেস্ট ব্যবহার করলে আদালত রিকোয়েস্ট করলে একই রূপান্তর পুনরায় চালানো যায়, এবং অডিটরদের নিশ্চিত করতে পারে যে কোনও ফাইল বাদ দেয়া হয়নি বা দ্বিগুণ প্রক্রিয়াকৃত হয়নি।

8. এনক্রিপটেড বা সুরক্ষিত প্রমাণের সাথে মোকাবিলা

এনক্রিপটেড কন্টেইনার—TrueCrypt ভলিউম, BitLocker‑সুরক্ষিত ড্রাইভ, অথবা পাসওয়ার্ড‑প্রটেক্টেড PDF—একটি অনন্য চ্যালেঞ্জ উপস্থাপন করে। সঠিক ফোরেন্সিক পদ্ধতি হল এনক্রিপ্টেড কন্টেইনারকে তার রaw রূপে গ্রহণ করা এবং এনক্রিপশন প্যারামিটার (অ্যালগরিদম, কী দৈর্ঘ্য, সল্ট) ডকুমেন্ট করা, যন্ত্রে ডি‑ডিক্রিপশন না করে। যদি বিশ্লেষণের জন্য ডিক্রিপশন প্রয়োজন হয়, তবে তা একটি বিচ্ছিন্ন, এয়ার‑গ্যাপড সিস্টেমে করা উচিত, এবং ডিক্রিপশন কীকে সঠিকভাবে ডকুমেন্ট ও প্রমাণিত করা উচিত। ডিক্রিপশন সম্পন্ন হলে, উৎপন্ন প্লেইনটেক্সট ফাইল রূপান্তর করা যায়, তবে এনক্রিপ্টেড মূল ও ডিক্রিপ্টেড কপি উভয়েরই নিজ নিজ হ্যাশসহ সংরক্ষণ করতে হবে, যাতে প্রমাণের চেইন অক্ষত থাকে।

9. আইনি বিবেচনা এবং গ্রহণযোগ্যতা

স্থানীয় আদালত ডিজিটাল প্রমাণের যেকোনো রূপান্তরকে ঘনিষ্ঠভাবে পরীক্ষা করে। গ্রহণযোগ্যতার মানদণ্ড (যেমন Daubert, Frye) পূরণ করতে রূপান্তর প্রক্রিয়াটি হতে হবে:

1. বৈজ্ঞানিকভাবে সঠিক: ব্যাপকভাবে গৃহীত টুল ও পদ্ধতির ওপর ভিত্তি করে।
2. স্বচ্ছ: সমস্ত ধাপ সম্পূর্ণভাবে ডকুমেন্টেড এবং পুনরুৎপাদনযোগ্য।
3. বৈধতা নিশ্চিত: টুলের আউটপুট পরিচিত‑সুস্থ নমুনার বিপরীতে বেন্চমার্ক করা হয়েছে।
4. স্বতন্ত্র: ideally একটি দ্বিতীয় বিশ্লেষক বা বহিরাগত পিয়ার রিভিউ দ্বারা যাচাই করা।

যদি রূপান্তর তৃতীয় পক্ষের ক্লাউড সেবা ব্যবহার করে করা হয়, তবে তদন্তকারীর উচিত একটি সার্ভিস লেভেল এগ্রিমেন্ট (SLA) সংগ্রহ করা, যার মধ্যে ডেটা হ্যান্ডলিং ধারা অন্তর্ভুক্ত, এবং কোনও সার্টিফিকেশন ডকুমেন্ট (ISO 27001, SOC 2) সংরক্ষণ করা, যাতে প্রদানকারীর গোপনীয়তা ও অখণ্ডতার প্রতিশ্রুতি প্রমাণ হয়।

10. রূপান্তরিত প্রমাণের সংরক্ষণাগার

রূপান্তরের পর, আর্টিফ্যাক্টটি এমন একটি প্রমাণ রেপোজিটরিতে সংরক্ষণ করা উচিত যা রাইট‑অনস, রিড‑ম্যানি (WORM) নীতি প্রয়োগ করে। রেপোজিটরিটি প্রতিটি ফাইলের হ্যাশ জোড়া বজায় রাখতে হবে, এবং সংরক্ষণ মাধ্যমকে নিয়মিত ফিক্সিটি চেক (পুনঃহ্যাশিং) দিয়ে যাচাই করতে হবে, যাতে বিট‑রট সনাক্ত করা যায়। রেপোজিটরি যদি ভার্সনিং সমর্থন করে, তবে মূল ফাইল এবং প্রতিটি ডেরিভেটিভ রূপান্তরকে পৃথক সংস্করণ হিসেবে বিবেচনা করতে হবে, প্রতিটির নিজস্ব অমর মেটাডেটা রেকর্ড সহ। এই প্র্যাকটিস নিশ্চিত করে যে ভবিষ্যৎ পর্যালোচকরা কাঁচা অধিগ্রহণ থেকে প্রতিটি পরবর্তী ট্রান্সফরমেশন পর্যন্ত আর্টিফ্যাক্টের লাইনেজ ট্র্যাক করতে পারে।

11. সর্বোত্তম‑প্র্যাকটিস চেকলিস্টের সারাংশ

• আলাদা করুন রূপান্তর ওয়ার্কস্টেশনটি এবং সম্ভব হলে রাইট‑ব্লকিং ব্যবহার করুন।
• রেকর্ড করুন রূপান্তরের আগে বেসলাইন হ্যাশ ও পূর্ণ মেটাডেটা।
• নির্বাচন করুন এমন টার্গেট ফরম্যাট যেটি তদন্তের লক্ষ্য সঙ্গে সামঞ্জস্যপূর্ণ এবং গুরুত্বপূর্ণ অ্যাট্রিবিউট রাখতে পারে।
• সক্রিয় করুন প্রতিটি রূপান্তর কমান্ড বা API কলের জন্য বিস্তৃত লগিং বা অডিট ট্রেইল।
• গণনা করুন রূপান্তরের পর হ্যাশ এবং পূর্বনির্ধারিত যাচাই পরিকল্পনার সঙ্গে তুলনা করুন।
• ডকুমেন্ট করুন রূপান্তর ধাপটি চেইন‑অফ‑কাস্টডি লগে সম্পূর্ণভাবে, এবং মূল বিবরণগুলো ফাইলের নিজস্ব মেটাডেটায় এম্বেড করুন।
• ব্যবহার করুন নির্ধারিত ম্যানিফেস্ট ব্যাচ প্রসেসিংয়ের জন্য এবং সেগুলো ভার্সন কন্ট্রোলে রাখুন।
• একটি পৃথক প্রমাণ হিসেবে বিবেচনা করুন এনক্রিপ্টেড কন্টেইনার; প্রয়োজন অনুযায়ী ডিক্রিপ্ট করুন এবং এনক্রিপ্টেড ও ডিক্রিপ্টেড উভয় কপি রাখুন।
• বৈধতা নিশ্চিত করুন রূপান্তর টুলের আউটপুটকে পরিচিত‑সুস্থ টেস্ট ডেটার সাথে এবং পিয়ার ভ্যালিডেশন দিয়ে।
• সংরক্ষণ করুন রূপান্তরিত আর্টিফ্যাক্টকে WORM‑সামঞ্জস্যপূর্ণ রেপোজিটরিতে, নিয়মিত ফিক্সিটি চেক সহ।

এই ধাপগুলি অনুসরণ করলে একটি সাধারণ ফাইল রূপান্তরকে ফরেনসিকভাবে সাউন্ড একটি অপারেশনে রূপান্তর করা যায়, যা ডিজিটাল আর্টিফ্যাক্টের প্রমাণমূল্যকে জব্দের মুহূর্ত থেকে আদালতে উপস্থাপনা পর্যন্ত সংরক্ষণ করে।