মেমরি ও ডিস্ক ফরেনসিক্স পরিচিতি

Introduction to memory & disk forensics

৭ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

ডিস্ক ফরেনসিক্স: ডিলিট করা ফাইল সাধারণত তাৎক্ষণিকভাবে মুছে যায় না — ফাইলসিস্টেম শুধু জায়গাটিকে "পুনর্ব্যবহারযোগ্য" চিহ্নিত করে, ওভাররাইট না হওয়া পর্যন্ত ডেটা পুনরুদ্ধারযোগ্য থাকে।
মেমরি (RAM) ফরেনসিক্স: চলমান প্রসেস, নেটওয়ার্ক কানেকশন, ডিক্রিপ্টেড ডেটা ও শুধুমাত্র-মেমরিতে-বাস-করা ম্যালওয়্যার প্রকাশ করে — এমন তথ্য যা কখনো ডিস্কে লেখা হয় না।
এই কারণেই লাইভ ইনসিডেন্ট রেসপন্সে মেমরি সবার আগে সংগ্রহ করা হয় — সিস্টেম বন্ধ করলে সব volatile প্রমাণ চিরতরে হারিয়ে যায়।
Order of volatility: সবচেয়ে দ্রুত হারিয়ে যাওয়া প্রমাণ সবার আগে সংগ্রহ করতে হয়, তারপর ধীরে-হারিয়ে-যাওয়া প্রমাণ।

এই পাঠে যা শিখবেন

কেন ডিলিট করা ফাইল প্রায়ই পুনরুদ্ধারযোগ্য থাকে, এবং কেন এটি একই সাথে ফরেনসিক্সের সুযোগ ও গোপনীয়তার ঝুঁকি
মেমরি ফরেনসিক্স কী প্রকাশ করে যা ডিস্ক ফরেনসিক্স কখনো পারে না
কেন লাইভ রেসপন্সে মেমরি ক্যাপচার সবার আগে অগ্রাধিকার পায়
"Order of volatility" নীতি — সংগ্রহের সঠিক ক্রম কীভাবে নির্ধারণ করা হয়

১ · ডিস্ক ফরেনসিক্স — ডিলিট করা মানেই হারিয়ে যাওয়া নয়

একটি সাধারণ ভুল ধারণা হলো, একটি ফাইল ডিলিট করলে তা তাৎক্ষণিকভাবে ডিস্ক থেকে মুছে যায়। বাস্তবে, বেশিরভাগ ফাইলসিস্টেম শুধু সেই স্থানটিকে "পুনর্ব্যবহারযোগ্য" হিসেবে চিহ্নিত করে — প্রকৃত ডেটা তখনও ডিস্কে থেকে যায়, যতক্ষণ না নতুন কোনো ডেটা সেই একই জায়গায় লেখা হয়। এই কারণেই —

ফরেনসিক টুল দিয়ে "ডিলিট করা" ফাইল প্রায়ই পুনরুদ্ধার করা সম্ভব — তদন্তকারীদের জন্য এটি একটি মূল্যবান সুযোগ।
সংবেদনশীল ডেটার প্রকৃত, নিরাপদ ধ্বংসের জন্য secure deletion টুল প্রয়োজন — যা সাধারণ ডিলিটের বদলে সেই স্থানে বারবার এলোমেলো ডেটা ওভাররাইট করে, যাতে মূল তথ্য সত্যিই অপ্রাপ্য হয়ে যায়।

২ · মেমরি (RAM) ফরেনসিক্স — যা কখনো ডিস্কে লেখা হয় না

মেমরি ফরেনসিক্সMemory Forensicsএকটি সিস্টেমের চলমান, volatile RAM-এর একটি স্ন্যাপশট ক্যাপচার ও বিশ্লেষণ করার কৌশল, যা ডিস্ক-ভিত্তিক ফরেনসিক্স থেকে সম্পূর্ণ ভিন্ন তথ্য প্রকাশ করে। একটি চলমান সিস্টেমের RAM ক্যাপচার করে এমন তথ্য প্রকাশ করে যা কখনো ডিস্কে স্পর্শ করে না —

চলমান প্রসেস
এই মুহূর্তে সিস্টেমে ঠিক কী চলছে তার সম্পূর্ণ তালিকা।

নেটওয়ার্ক কানেকশন
সক্রিয় সংযোগ ও কোন প্রক্রিয়া সেগুলো ব্যবহার করছে।

ডিক্রিপ্টেড ডেটা ও কী
এনক্রিপশন কী যা শুধুমাত্র ব্যবহারের সময় মেমরিতে ডিক্রিপ্টেড থাকে, ডিস্কে কখনো প্লেইনটেক্সটে থাকে না।

ফাইললেস ম্যালওয়্যার
কিছু আধুনিক ম্যালওয়্যার শুধুমাত্র মেমরিতে থাকে, ডিস্ক-ভিত্তিক ডিটেকশন এড়াতে কখনো ডিস্কে নিজেকে লেখে না।

এই কারণেই লাইভ ইনসিডেন্ট রেসপন্সে মেমরি ক্যাপচার সবার আগে করা হয় — সিস্টেম বন্ধ (power off) করলে RAM-এর সব তথ্য স্থায়ীভাবে হারিয়ে যায়, কিন্তু ডিস্কের তথ্য থেকে যায়। তাই ভুল ক্রম (আগে power off, তারপর মেমরি ক্যাপচারের চেষ্টা) মূল্যবান, অপুনরুদ্ধারযোগ্য প্রমাণ চিরতরে ধ্বংস করে দেয়।

গুরুত্বপূর্ণ সতর্কতা · অনুমতি ও গোপনীয়তা

মেমরি ও ডিস্ক ফরেনসিক বিশ্লেষণ শুধুমাত্র প্রতিষ্ঠানের নিজস্ব অনুমোদিত নীতি অনুযায়ী বা আইনি কর্তৃপক্ষের অনুমতিক্রমে করা উচিত — এই প্রক্রিয়া প্রায়ই ব্যক্তিগত ও সংবেদনশীল তথ্য প্রকাশ করতে পারে (ব্যবহারকারীর কার্যকলাপ, ব্যক্তিগত বার্তা), তাই যথাযথ অনুমোদন ও গোপনীয়তা নীতি ছাড়া এটি পরিচালনা করা উচিত নয়।

৩ · Order of Volatility — সংগ্রহের সঠিক ক্রম

যেহেতু বিভিন্ন ধরনের প্রমাণ বিভিন্ন গতিতে হারিয়ে যায়, ফরেনসিক সংগ্রহ সবসময় সবচেয়ে volatile (দ্রুত হারিয়ে যাওয়া) প্রমাণ আগে সংগ্রহ করার নীতি অনুসরণ করে — CPU রেজিস্টার ও ক্যাশে থেকে শুরু করে ধীরে ধীরে কম volatile ব্যাকআপ মিডিয়া পর্যন্ত।

Python

# প্রতিটি এন্ট্রি: (evidence_type, typical_lifetime, volatility_rank)
# volatility_rank যত ছোট, তত দ্রুত হারিয়ে যায় -> তত আগে সংগ্রহ করতে হবে
evidence_types = [
    ("ব্যাকআপ / আর্কাইভাল মিডিয়া",              "মাসের পর মাস থেকে বছরের পর বছর স্থায়ী",     6),
    ("ডিস্ক স্টোরেজ (হার্ড ড্রাইভ / SSD)",         "নতুন ডেটা দিয়ে ওভাররাইট না হওয়া পর্যন্ত স্থায়ী", 5),
    ("রানিং প্রসেস তালিকা",                      "রিবুট হলেই হারিয়ে যায়",                     4),
    ("সক্রিয় নেটওয়ার্ক কানেকশন / রাউটিং টেবিল",   "কয়েক সেকেন্ড থেকে মিনিট স্থায়ী",             3),
    ("RAM (চলমান মেমরি — কী, ডিক্রিপ্টেড ডেটা)",  "পাওয়ার অফ হলেই সম্পূর্ণ হারিয়ে যায়",         2),
    ("CPU রেজিস্টার ও ক্যাশে",                    "ন্যানোসেকেন্ডের মধ্যে পরিবর্তিত হয়",          1),
]

# volatility_rank অনুযায়ী সাজানো -> সবচেয়ে volatile আগে
collection_order = sorted(evidence_types, key=lambda entry: entry[2])

print("=== ফরেনসিক সংগ্রহের অগ্রাধিকার ক্রম (সবচেয়ে volatile আগে) ===")
for priority, (evidence_type, lifetime, rank) in enumerate(collection_order, start=1):
    print(f"{priority}. {evidence_type} — {lifetime}")

লক্ষ্য করুন — তালিকাটি CPU রেজিস্টার/ক্যাশে দিয়ে শুরু হয়ে (সবচেয়ে volatile) ব্যাকআপ মিডিয়া দিয়ে শেষ হয় (সবচেয়ে কম volatile)। বাস্তবে CPU রেজিস্টার সাধারণত ফরেনসিক্যালি ক্যাপচার করা হয় না (এত দ্রুত পরিবর্তিত হয় যে ব্যবহারিকভাবে অসম্ভব), কিন্তু এটি স্কেলের একটি প্রান্ত হিসেবে দেখানো হয়েছে যাতে RAM ঠিক কতটা "জরুরি" তা বোঝা যায় — ডিস্কের তুলনায় বহুগুণ বেশি।

মূল কথা · Key takeaway

একটি ঘটনার সময় "প্রথমে কী সংগ্রহ করব" প্রশ্নের উত্তর নির্ধারণ করে কতটুকু প্রমাণ আদৌ টিকে থাকবে। Order of volatility নীতি মনে রাখলে — সবচেয়ে দ্রুত হারিয়ে যাওয়া প্রমাণ (মেমরি) সবার আগে, সবচেয়ে স্থায়ী প্রমাণ (ব্যাকআপ) সবার শেষে — একজন রেসপন্ডার কখনো ভুলবশত এমন প্রমাণ হারাবে না যা আর কখনো ফিরে পাওয়া যাবে না।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একজন নতুন IT স্টাফ একটি সম্ভাব্য ম্যালওয়্যার-আক্রান্ত সার্ভার দেখে সাথে সাথে পাওয়ার বাটন চেপে বন্ধ করে দিলেন। এই সিদ্ধান্ত কেন ফরেনসিক দৃষ্টিকোণ থেকে ক্ষতিকর হতে পারে?

সার্ভার বন্ধ করার সাথে সাথে RAM-এ থাকা সব volatile প্রমাণ — চলমান প্রসেস, সক্রিয় নেটওয়ার্ক কানেকশন, ফাইললেস ম্যালওয়্যার (যদি থাকে), এবং যেকোনো ডিক্রিপ্টেড ডেটা — স্থায়ীভাবে হারিয়ে যায়। যদি ম্যালওয়্যারটি শুধুমাত্র মেমরিতে থাকে (ডিস্কে কখনো লেখা না হয়), তাহলে বন্ধ করার সাথে সাথে সেই ম্যালওয়্যারের একমাত্র প্রমাণও চিরতরে মুছে যায় — সঠিক পদ্ধতি হতো প্রথমে মেমরি ক্যাপচার করা, তারপর প্রয়োজনে সিস্টেম আইসোলেট/বন্ধ করা।

প্র ০২ একটি কোম্পানি একটি পুরনো ল্যাপটপ বিক্রি করার আগে শুধু ফাইলগুলো "ডিলিট" করে দিয়েছে, ফরম্যাট বা ওভাররাইট করেনি। এটি কেন একটি ডেটা-লিক ঝুঁকি?

যেহেতু সাধারণ ডিলিট শুধু ফাইলসিস্টেমকে সেই জায়গাটি "পুনর্ব্যবহারযোগ্য" হিসেবে চিহ্নিত করে, প্রকৃত ডেটা তখনও ডিস্কে থেকে যায় যতক্ষণ না নতুন ডেটা সেই জায়গায় লেখা হয়। যে কেউ সাধারণ ডেটা-পুনরুদ্ধার টুল দিয়ে সেই "মুছে ফেলা" ফাইলগুলো ফিরিয়ে আনতে পারে — সংবেদনশীল তথ্যের নিরাপদ নিষ্পত্তির জন্য secure deletion (বারবার ওভাররাইট) বা ফিজিক্যাল ধ্বংস প্রয়োজন, শুধু "Delete" চাপা যথেষ্ট নয়।

প্র ০৩ উপরের কোড সেলে CPU রেজিস্টার/ক্যাশেকে সবচেয়ে উঁচু অগ্রাধিকারে (rank 1) রাখা হয়েছে, যদিও নোটে বলা হয়েছে বাস্তবে এটি সাধারণত ক্যাপচার করা হয় না। এই আপাত বৈপরীত্য কীভাবে ব্যাখ্যা করা যায়?

Order of volatility একটি তাত্ত্বিক স্কেল যা প্রমাণ কতটা দ্রুত হারিয়ে যায় তা র‍্যাংক করে — CPU রেজিস্টার সত্যিই সবচেয়ে volatile, কিন্তু ব্যবহারিকভাবে এত দ্রুত পরিবর্তিত হয় (ন্যানোসেকেন্ডে) যে ফরেনসিক টুল দিয়ে অর্থপূর্ণভাবে ক্যাপচার করা প্রায় অসম্ভব। তালিকায় এটি রাখার উদ্দেশ্য স্কেলটি সম্পূর্ণ দেখানো, যাতে RAM (rank 2) ঠিক কতটা জরুরি তা প্রেক্ষাপটসহ বোঝা যায় — ব্যবহারিক অগ্রাধিকার এবং তাত্ত্বিক র‍্যাংকিং সবসময় হুবহু একরকম প্রয়োগযোগ্য নয়।

অনুশীলন

চিন্তা করুন: একটি ইনসিডেন্ট রেসপন্স দল একটি সন্দেহভাজন সার্ভারে পৌঁছেছে। ডিস্ক ইমেজ ও মেমরি ক্যাপচার — দুটোই দরকার, কিন্তু কোনটি প্রথমে করা উচিত এবং কেন?

মেমরি ক্যাপচার প্রথমে করা উচিত। ডিস্কের ডেটা তুলনামূলকভাবে স্থিতিশীল থাকে (সিস্টেম চালু থাকা অবস্থায় সহজে হারায় না), কিন্তু RAM-এর প্রতিটি মুহূর্ত মূল্যবান — সিস্টেম বন্ধ হয়ে গেলে, ক্র্যাশ করলে, বা এমনকি দীর্ঘ সময় ধরে চলতে থাকলেও মেমরির অবস্থা ক্রমাগত পরিবর্তিত হতে থাকে। Order of volatility নীতি অনুযায়ী সবচেয়ে দ্রুত হারিয়ে যাওয়া প্রমাণ আগে সংগ্রহ করা উচিত।
পরীক্ষা করুন: উপরের কোড সেলে তালিকায় নতুন একটি এন্ট্রি যোগ করুন — ("সোয়াপ/পেজ ফাইল", "ডিস্কের সাথে একই রকম স্থায়ী, কিন্তু RAM-এর সাম্প্রতিক ডেটা ধারণ করতে পারে", 4.5) — এবং আবার সাজিয়ে দেখুন এটি কোথায় স্থান পায়।

rank 4.5 হওয়ায় এটি "রানিং প্রসেস তালিকা" (rank 4) এবং "সক্রিয় নেটওয়ার্ক কানেকশন" (rank 3)-এর মাঝামাঝি নয়, বরং rank 4 (প্রসেস তালিকা) এবং rank 5 (ডিস্ক স্টোরেজ)-এর মাঝে বসবে। এটি বাস্তবে যুক্তিসঙ্গত — সোয়াপ ফাইল ডিস্কে থাকে (তাই মোটামুটি স্থায়ী) কিন্তু RAM থেকে সম্প্রতি "উপচে পড়া" ডেটা ধারণ করতে পারে, যা একে বিশুদ্ধ ডিস্ক স্টোরেজের চেয়ে সামান্য বেশি volatile করে তোলে।