مقدمه

در تحقیقات دیجیتال، به محض این‌که فایلی از وسیله ذخیره‌سازی اصلی خود جدا شود، در معرض تغییرات ناخواسته قرار می‌گیرد. حتی تبدیل به‌نظر بی‌ضرری—مانند تغییر یک تصویر دیسک از E01 به RAW، فشرده‌سازی یک فایل لاگ، یا رندر کردن یک PDF برای ارائه در دادگاه—می‌تواند هش‌ها را خراب کند، برچسب‌های زمانی را حذف کند یا خصوصیات پنهانی را پاک کند که بعدها برای شهادت یک کارشناس اهمیت حیاتی پیدا می‌کند. این مقاله تمام چرخه‌ی تبدیل را، از آماده‌سازی شواهد تا تأیید خروجی نهایی، مرور می‌کند و بر قابلیت بازتولید، حسابرسی‌پذیری و دفاع‑پذیری قانونی تأکید دارد. اصول بیان‑شده چه در یک نفوذ شرکت، چه در توقیف نیروی انتظامی و چه در یک ممیزی داخلی کاربرد دارد و فرض می‌کند که از ابزارهای قابل اعتماد و حفظ‑حریم‌خصوصی مانند سرویس ابری ارائه‌شده در convertise.app در صورت نیاز استفاده می‌شود.

1. ایجاد محیط کنترل‌شده برای تبدیل

قبل از اینکه اولین بایت دست‌کاری شود، حسابرسان باید محیطی را که تبدیل در آن انجام می‌شود، لغو دسترسی کنند. این کار با یک ایستگاه کاری مسدود‑نوشتن یا یک ایستگاه کاری Forensic که از یک تصویر Forensic شناخته‌شده (مثلاً یک USB نوشتن‑یکبار با BitLocker) بوت شده است، آغاز می‌شود. تمام نرم‌افزارهای مورد استفاده برای تبدیل باید فهرست‑موجودی شوند، امضای دیجیتال داشته باشند و تحت کنترل نسخه باشند. ترجیح باید به ابزارهای متن‌باز داده شود که هش بایناری آن‌ها قابل تأیید است، زیرا بایناری‌های بسته‑منبع سطح حمله‌ای مستند‑نشده دارند. پس از جداسازی ایستگاه کاری، یک پوشه کاری اختصاصی و رمزنگاری‌شده باید ایجاد شود؛ مسیر و مجوزهای آن در یک لاگ‑کیس ثبت می‌شود و خود پوشه هرچه ممکن باشد بر روی یک وسیله نوشتن‑یکبار ذخیره می‌شود. این مراحل یک مبنای بازتولیدپذیر ایجاد می‌کند و نشان دادن این‌که فرآیند تبدیل متغیرهای خارجی وارد نکرده، را آسان‌تر می‌سازد.

2. ثبت هش‌های پایه و متادیتا

ستون فقرهٔ یکپارچگی Forensic، مقدار هش (MD5، SHA‑1، SHA‑256 یا ترجیحاً SHA‑512) است که بر شواهد اصلی پیش از هر گونه تبدیل محاسبه می‌شود. محاسبه هش باید با ابزاری انجام شود که مطابق با استانداردهای NIST SP 800‑90 باشد و مقدار حاصل همراه با متادیتای اصلی فایل ثبت شود: زمان‌های ایجاد، اصلاح و دسترسی؛ خصوصیات سیستم‌فایل؛ و برای تصاویر دیسک، جزئیات سطح سکتور مانند جدول‌های پارتیشن و امضاهای فایل‌سیستم. بهترین روش این است که هش حداقل با دو ابزار هش‌گذاری مستقل گرفته شود و هر گونه اختلاف به‌عنوان شواهد احتمالی تقلب مستند شود. هش ثبت‑شده نقطهٔ مرجع برای هر مرحلهٔ تأیید بعدی می‌شود.

3. انتخاب فرمت هدف مناسب

هر تبدیل به یک اندازه یکسان نیست. تصمیم به تبدیل باید بر پایه هدف تحقیق باشد: حفظ، تجزیه‌وتحلیل یا ارائه. برای حفظ، فرمت بدون‌خسارت و سطح‑به‑سطحی مانند RAW (dd) یا E01 ترجیح داده می‌شود؛ این فرمت‌ها دنبالهٔ بایت دقیق منبع را نگه می‌دارند. وقتی ابزارهای تحلیل تنها یک کانتینر خاص (مثلاً یک مجموعه Forensic که AFF را می‌خواند) می‌پذیرند، تبدیل به آن فرمت توجیه‌پذیر است، اما باید همیشه یک نسخهٔ دست‌نخوردهٔ اصلی را نگه داشت. برای ارائه، ممکن است یک فایل PDF‑A یا TIFF مناسب باشد، اما لولهٔ تبدیل باید یک چک‌سام از منبع را در متادیتای فایل خروجی تعبیه کند تا پیوندی قابل تأیید بین دو فایل ایجاد شود. انتخاب فرمی که به‌طور ذاتی از متادیتا پشتیبانی می‌کند (مانند AFF) می‌تواند این پیوند را ساده‌سازی کند.

4. انجام تبدیل با ردیابی حسابرسی

ابزارهای تبدیل مدرن اغلب یک لاگ پرجزئیات فراهم می‌کنند که هر عملیات، شامل مسیرهای منبع و مقصد، زمان‌بندها و هر تبدیل اعمال‌شده (مثلاً سطح فشرده‌سازی، بازنمونه‌گیری تصویر) را ثبت می‌کند. هنگام استفاده از ابزار خط فرمان، پرچم --log باید فعال شود و فایل لاگ کنار artefact تبدیل‑شده ذخیره گردد. اگر تبدیل در یک سرویس ابری انجام شود، سرویس باید یک رکورد حسابرسی غیرقابل تغییر ارائه دهد (درخواست API زمان‌دار، هش منبع، فرمت مقصد). صرف‌نظر از روش، حسابرس باید بلافاصله پس از اتمام فرآیند، هش دوم را بر روی فایل تبدیل‑شده بگیرد. این هش دوم به همراه هش اصلی، یک جفت هش تشکیل می‌دهد که می‌تواند بعدها به یک ممتحن یا قاضی ارائه شود.

5. تأیید یکپارچگی پس از تبدیل

تأیید تنها مقایسهٔ سادهٔ هش نیست. برای فرمت‌های بدون‌خسارت، مقایسهٔ بایت‑به‑بایت (مثلاً cmp در یونیکس) امکان‌پذیر است و باید زمانی که فرمت هدف اجازه می‌دهد، انجام شود. برای فرمت‌های فشرده یا تبدیل‌شده، تأیید باید بر حفظ ارزش شواهد متمرکز باشد: اطمینان از این‌که زمان‌برچسب‌ها، EXIF جاسازی‑شده یا جریان‌های دادهٔ جایگزین NTFS، و هر خصوصیت پنهان فایل پس از تبدیل باقی مانده‌اند. ابزارهایی مانند exiftool یا fsstat می‌توانند این خصوصیات را پیش و پس از تبدیل استخراج و مقایسه کنند. هر انحراف باید مستند، توضیح داده و در صورت امکان جبران شود (برای مثال، تعبیهٔ هش اصلی در متادیتای فایل جدید با یک برچسب XMP سفارشی).

6. مستندسازی زنجیرهٔ custody در تمام مراحل

یک لاگ زنجیرهٔ custody، رکوردی زمان‌بندی‌شده از هر شخصی که شواهد را دست‌کاری کرده، هر عملیاتی که انجام شده و هر مکانی که شواهد در آن قرار داشته است، می‌باشد. مرحلهٔ تبدیل یک گرهٔ جدید به این زنجیره اضافه می‌کند. ورودی لاگ برای تبدیل باید شامل موارد زیر باشد:

• تاریخ، زمان و افست UTC تبدیل.
• نام تحلیل‌گر و شناسهٔ ایستگاه کاری.
• خط فرمان دقیق یا درخواست API استفاده‑شده.
• هش فایل منبع قبل از تبدیل.
• هش فایل حاصل پس از تبدیل.
• دلیل تبدیل (حفظ، تحلیل یا ارائه).
• هر تنظیمات فشرده‌سازی یا پارامترهای کیفیت اعمال‑شده.

تعبئ این اطلاعات به‌طور مستقیم داخل فایل تبدیل‑شده—در یک بلوک متادیتای اختصاصی—یک artefact خود‌توضیحی می‌سازد که حتی در صورت گم شدن لاگ خارجی، می‌تواند بعدها بررسی شود.

7. مدیریت حجم بزرگ داده‌ها و تبدیل‌های دسته‌ای

تحقیقات اغلب شامل صدها گیگابایت شواهد می‌شوند. اسکریپت‌های تبدیل دسته‌ای باید تعین‌پذیر و قابل تکرار باشند. الگوی رایج این است که یک فایل مانیفست (CSV یا JSON) تولید شود که هر فایل منبع، هش پایهٔ آن و فرمت هدف موردنظر را فهرست کند. اسکریپت مانیفست را می‌خواند، هر ورودی را پردازش می‌کند، فایل تبدیل‑شده را به یک پوشهٔ خروجی کنترل‌شده می‌نویسد و یک خط جدید به لاگ نتایج اضافه می‌کند که شامل هر دو هش، کد خروجی و هشدارهای احتمالی است. استفاده از مانیفست تحت کنترل نسخه اطمینان می‌دهد که همان تبدیل می‌تواند در صورت درخواست دادگاه دوباره اجرا شود و همچنین حسابرس می‌تواند تأیید کند هیچ فایلی حذف یا دوبار پردازش نشده است.

8. برخورد با شواهد رمزنگاری‌شده یا محافظت‌شده

کانتینرهای رمزنگاری‌شده—حجم‌های TrueCrypt، دیسک‌های حفاظت‑شده توسط BitLocker یا PDFهای محافظت‑شده با رمز عبور—چالش خاصی دارند. رویکرد Forensic صحیح این است که کانتینر رمزنگاری‌شده را به شکل خام به دست آورده و پارامترهای رمزنگاری (الگوریتم، طول کلید، نمک) را مستند کنید بدون اینکه در ماشین تهیه‑شده تلاش به رمزگشایی شود. اگر برای تحلیل نیاز به رمزگشایی باشد، باید بر روی سیستمی ایزوله و هوا‑قطع انجام شود پس از آن که کلید رمزگشایی به‌درستی مستند و تأیید شده باشد. پس از رمزگشایی، فایل متنی حاصل می‌تواند تبدیل شود، اما هر دو نسخهٔ اصلی رمزنگاری‌شده و نسخهٔ رمزگشایی‑شده باید نگه داشته شوند؛ هر کدام هش مخصوص خود را داشته باشد تا ردپای شواهد حفظ شود.

9. ملاحظات قانونی و پذیرش در دادگاه

دادگاه‌ها هر گونه تحول در شواهد دیجیتال را با دقت بررسی می‌کنند. برای تأمین معیارهای پذیرش (مانند Daubert یا Frye)، فرآیند تبدیل باید:

1. علمی sound: بر پایه ابزارها و روش‌های مورد پذیرش عمومی باشد.
2. شفاف: تمام مراحل به‌طور کامل مستند و بازتولیدپذیر باشد.
3. مُعتبَر: خروجی ابزار بر روی نمونه‌های شناخته‑شده آزمایش و ارزیابی شده باشد.
4. مستقل: ترجیحاً توسط یک تحلیل‌گر دوم یا بازبینی همتایان خارجی تأیید شود.

هنگامی که تبدیل توسط سرویس ابری شخص ثالث انجام می‌شود، محقق باید یک توافق‌نامهٔ سطح سرویس (SLA) دریافت کند که بندهای مربوط به مدیریت داده را شامل شود و هر مدرک‌گواهی (ISO 27001، SOC 2) که تعهد ارائه‑دهنده به حریم‌خصوصی و یکپارچگی را نشان می‌دهد، نگه دارد.

10. ذخیره‌سازی آرشیوی شواهد تبدیل‌شده

پس از تبدیل، artefact باید در مخزنی ذخیره شود که سیاست‌های نوشتن‑یکبار، خواندن‑متعدد (WORM) را اعمال می‌کند. مخزن باید جفت هش هر فایل را حفظ کند و واسطهٔ ذخیره‌سازی به‌صورت دوره‌ای با یک بررسی ثابت‌بودن (باز‑هش) مورد ارزیابی قرار گیرد تا از خراب‑شدن بیت‌ها جلوگیری شود. اگر مخزن از نسخه‌بندی پشتیبانی کند، فایل اصلی و هر تبدیل مشتق‌شده باید به‌عنوان نسخه‌های جداگانه در نظر گرفته شوند، هر کدام با رکورد متادیتای غیرقابل تغییر خود. این روش اطمینان می‌دهد که بازنگرندگان آینده بتوانند ریشهٔ artefact را از جمع‌آوری خام تا هر تحول بعدی ردیابی کنند.

11. خلاصهٔ فهرست نکات برتر

• ایزوله‌سازی ایستگاه کاری تبدیل و استفاده از مسدود‑نوشتن در صورت امکان.
• ثبت هش‌های پایه و تمام متادیتا قبل از هر تحولی.
• انتخاب فرمت هدف متناسب با هدف تحقیق و حفظ خصوصیات بحرانی.
• فعال‌سازی لاگ‌نویسی پرجزئیات یا ردپای حسابرسی برای هر فرمان یا درخواست API.
• محاسبه هش پس از تبدیل و مقایسه آن با برنامهٔ تأیید از پیش تعریف شده.
• مستندسازی کامل مرحلهٔ تبدیل در لاگ زنجیرهٔ custody و تعبیه جزئیات کلیدی داخل فایل.
• استفاده از مانیفست‌های تعین‌پذیر برای پردازش دسته‌ای و نگهداری آن‌ها تحت کنترل نسخه.
• برخورد با کانتینرهای رمزنگاری‌شده به عنوان شواهد جداگانه؛ رمزگشایی فقط در صورت ضرورت مطلق و نگهداری هر دو نسخهٔ رمزنگاری‌شده و رمزگشایی‑شده.
• اعتبارسنجی خروجی ابزار تبدیل با داده‌های تست شناخته‑شده و دریافت تأییدیه همتا.
• ذخیره‌سازی artefactهای تبدیل‑شده در مخزن سازگار با WORM به همراه بررسی‌های ثابت‌بودن دوره‌ای.

با پیروی از این گام‌ها، یک تبدیل فایل روتین به یک عملیات Forensic sound تبدیل می‌شود و وزن شواهد دیجیتال از لحظهٔ توقیف تا زمان ارائه در دادگاه حفظ می‌شود.