در حال بارگذاری 0%
// منو.exe
خانه رزومه بلاگ تماس سفارش
English فارسی
~/blog / technology / how-deleted-files-are-recovered

راز فایل‌هایی که حذف می‌کنیم اما واقعاً پاک نمی‌شوند

فرض کنید یک هارددیسک قدیمی که سال‌ها در انباری مانده، به دست یک متخصص بازیابی اطلاعات برسد. صاحب هارد مطمئن است همه‌چیز را حذف کرده: عکس‌ها، اسناد، فایل‌های شخصی و هر چیزی که زمانی روی آن ذخیره شده بود. اما بررسی هارد نتیجه دیگری نشان می‌دهد. نام بسیاری از فایل‌ها دیگر در سیستم دیده نمی‌شود، بااین‌حال بخش قابل‌توجهی از عکس‌ها و اسناد هنوز از میان فضای به‌ظاهر خالی استخراج می‌شوند. اشکال از دکمه Delete نیست؛ مسئله این است که ما «حذف‌شدن فایل از دید سیستم‌عامل» را با «نابودی فیزیکی اطلاعات» یکی می‌دانیم.

راز فایل‌هایی که حذف می‌کنیم اما واقعاً پاک نمی‌شوند

# تصور ما از Delete و اتفاقی که واقعاً می‌افتد

تصور رایج ما از حذف فایل معمولاً این است:
assumption.txt
فایل Delete نابودی کامل
اما روی بسیاری از حافظه‌ها، اتفاق واقعی در لحظه اول بیشتر شبیه این است:
reality.txt
فایل حذف یا آزادشدن نشانی قابل‌استفاده اعلام‌شدن فضا
داده ممکن است هنوز جایی روی رسانه ذخیره‌سازی مانده باشد. سیستم‌عامل فقط دیگر آن را یک فایل فعال نمی‌داند. همین یک تفاوت، پایه و اساس تمام دنیای بازیابی اطلاعات است.

# ابتدا یک تفاوت مهم: سطل بازیافت با حذف دائمی یکی نیست

وقتی در ویندوز یا محیط‌های گرافیکی دیگر دکمه Delete را می‌زنیم، فایل ممکن است ابتدا به Recycle Bin یا Trash منتقل شود. در این حالت حتی اطلاعات مدیریتی فایل نیز معمولاً حفظ شده و بازیابی آن فقط به معنی برگرداندن فایل از سطل زباله است.
موضوع اصلی این مقاله از جایی شروع می‌شود که سطل بازیافت خالی شده، از Shift + Delete استفاده کرده‌ایم یا برنامه‌ای فایل را مستقیماً حذف کرده است. اینجا فایل از فهرست عادی سیستم‌عامل خارج می‌شود، اما هنوز معلوم نیست محتوای فیزیکی آن نیز از بین رفته باشد.
R
Recycle Bin / Trash
به محل دیگری منتقل شده و همچنان مدیریت می‌شود — شانس بازگشت: بسیار زیاد
D
حذف دائمی از فایل‌سیستم
ورودی فایل آزاد یا نامعتبر می‌شود — وابسته به نوع حافظه و بازنویسی
بازنویسی / Sanitize / Crypto Erase
دسترسی به محتوای قبلی عمداً از بین می‌رود — بسیار کم یا عملاً ناممکن

# حافظه کامپیوتر را مثل یک کتابخانه تصور کنید

یک کتابخانه بزرگ را در نظر بگیرید. هر کتاب روی قفسه‌ای قرار دارد و شماره قفسه آن در یک فهرست ثبت شده است. کتابدار برای پیدا کردن کتاب، ابتدا سراغ فهرست می‌رود و سپس با استفاده از نشانی ثبت‌شده به قفسه مناسب می‌رسد.
حالا اگر کارت یک کتاب را از فهرست خارج کنیم، چه می‌شود؟ کتابدار دیگر مسیر عادی پیدا کردن آن را ندارد، اما خود کتاب ممکن است همچنان روی قفسه باشد. فقط آن جای قفسه از این پس «آزاد» در نظر گرفته می‌شود و کتابدار اجازه دارد کتاب دیگری را روی همان محل بگذارد.
1
کتاب روی قفسه — کارت در فهرست موجود است
2
کارت حذف می‌شود — حذف همین‌جا رخ می‌دهد
3
کتاب هنوز آنجاست — تا وقتی کتاب دیگری جای آن را نگیرد
فایل‌سیستم نیز نقشی شبیه همین فهرست دارد. برای هر فایل، اطلاعاتی مانند نام، اندازه، زمان‌ها، مجوزها و محل بلوک‌های داده نگهداری می‌شود. حذف فایل در بسیاری از فایل‌سیستم‌ها ابتدا همین ساختار مدیریتی را تغییر می‌دهد و فضای متعلق به فایل را برای استفاده دوباره آزاد اعلام می‌کند. تا زمانی که داده جدیدی روی آن فضا نوشته نشده باشد، بخشی از محتوای قبلی ممکن است هنوز قابل خواندن باشد.

# فایل‌سیستم دقیقاً چه چیزی را نگهداری می‌کند؟

هارددیسک یا SSD در پایین‌ترین سطح فقط مجموعه بزرگی از واحدهای ذخیره‌سازی است. چیزی که از این واحدها «فایل» می‌سازد، فایل‌سیستم است. در NTFS ویندوز، اطلاعات فایل‌ها در ساختاری به نام Master File Table (MFT) ثبت می‌شود. در فایل‌سیستم‌های خانواده ext در لینوکس، inodeها بخش مهمی از فراداده فایل را نگهداری می‌کنند. FAT نیز جدول تخصیص خوشه‌های خودش را دارد.
پیش از حذف
نام فایل → رکورد فراداده → بلوک‌های داده
پس از حذف
رکورد = آزاد/نامعتبر · بلوک‌ها = قابل استفاده مجدد · محتوا = شاید هنوز باقی باشد
به همین دلیل دو فایل حذف‌شده شرایط یکسانی ندارند. ممکن است رکورد مدیریتی یکی هنوز تقریباً کامل باشد و نام، اندازه و محل تمام بخش‌های آن را نشان دهد. از فایل دیگر شاید فقط تکه‌هایی خام باقی مانده باشد که دیگر نام و مسیر اصلی‌شان مشخص نیست.

# نرم‌افزارهای بازیابی اطلاعات چگونه فایل را پیدا می‌کنند؟

ابزارهای بازیابی معمولاً از دو مسیر اصلی استفاده می‌کنند:
مسیر اول: آثار باقی‌مانده در فایل‌سیستم
  • خواندن رکوردهای بازمانده MFT / inode / FAT
  • پیدا کردن بلوک‌های فایل از روی فراداده
  • بهترین حالت: نام، پوشه، اندازه و تاریخ‌ها هم برمی‌گردند
مسیر دوم: File Carving
  • جستجوی فضای خام برای الگوهای شناخته‌شده
  • بدون اتکا به نام و پوشه
  • تراشیدن فایل از میان جریان خام بایت‌ها
مسیر اول شبیه پیدا کردن کارت قدیمی کتاب در بایگانی کتابخانه است: فهرست رسمی دیگر آن را نمایش نمی‌دهد، اما اطلاعات کافی برای رسیدن به قفسه هنوز وجود دارد. ابزارهایی مانند The Sleuth Kit و Autopsy دقیقاً برای تحلیل تصویر دیسک و بررسی شواهد فایل‌سیستمی ساخته شده‌اند.
مسیر دوم — File Carving — وقتی وارد می‌شود که فراداده از بین رفته باشد. بسیاری از فرمت‌ها در ابتدای فایل، ساختار یا امضای مشخصی دارند. برای نمونه، یک فایل JPEG معمولاً با این سه بایت آغاز می‌شود:
jpeg-signature.hex
start: FF D8 FF   |   end: FF D9
برنامه بازیابی می‌تواند به‌دنبال شروع احتمالی JPEG بگردد، ساختار داخلی آن را بررسی کند و تا رسیدن به پایان فایل پیش برود. این روش File Carving نام دارد؛ یعنی ابزار تلاش می‌کند فایل را از میان یک جریان بزرگ و بدون فهرستِ داده بیرون بکشد.

# یک آزمایش کوچک با پایتون

برای دیدن ایده اصلی، می‌توانیم یک برنامه بسیار ساده بنویسیم که داخل یک فایل خام به‌دنبال نخستین تصویر JPEG بگردد. این کد یک نرم‌افزار حرفه‌ای بازیابی نیست و نباید آن را مستقیماً روی دیسکی اجرا کرد که اطلاعات مهمی دارد؛ آزمایش را فقط روی یک کپی یا فایل ساختگی مانند memory.bin انجام دهید.
carve.py
from pathlib import Path
 
JPEG_START = b"\xff\xd8\xff"
JPEG_END   = b"\xff\xd9"
 
raw_data = Path("memory.bin").read_bytes()
 
start = raw_data.find(JPEG_START)
if start == -1:
    raise SystemExit("هیچ شروع احتمالی برای JPEG پیدا نشد.")
 
end = raw_data.find(JPEG_END, start + len(JPEG_START))
if end == -1:
    raise SystemExit("شروع JPEG پیدا شد، اما پایان آن مشخص نیست.")
 
recovered = raw_data[start : end + len(JPEG_END)]
Path("recovered.jpg").write_bytes(recovered)
 
print("یک JPEG احتمالی استخراج شد.")
print("شروع داده:", start, "| اندازه فایل:", len(recovered), "bytes")
1
خواندن — کل داده خام
2
جستجو — دنبال امضای شروع JPEG
3
پیدا کردن — نخستین نشان پایان پس از آن
4
نوشتن — بایت‌های بین این دو نقطه در فایل جدید
همین سادگی محدودیت‌های مهمی دارد: یک توالی بایت ممکن است تصادفاً شبیه امضای JPEG باشد. ممکن است فایل اصلی تکه‌تکه شده باشد و بخش‌های آن پشت‌سرهم قرار نگرفته باشند. شاید داخل خود تصویر داده‌ای شبیه نشان پایان دیده شود یا فایل ناقص باشد. ابزار حرفه‌ای علاوه بر امضا، ساختار داخلی فرمت، طول بخش‌ها، سیستم فایل، مرز بلوک‌ها و چندین نشانه دیگر را بررسی می‌کند.

# چرا بعضی فایل‌ها سالم و بعضی خراب برمی‌گردند؟

بازیابی یک وضعیت صفر و یک ندارد. نتیجه ممکن است یکی از این حالت‌ها باشد:
1
کاملاً سالم
فایل با نام و پوشه اصلی کاملاً سالم بازمی‌گردد
2
سالم اما بی‌نام
محتوا سالم است، اما نام به چیزی مانند recup_00123.jpg تبدیل شده
3
نیمه‌کاره
تنها بخشی از عکس دیده می‌شود و نیمه دیگر خراب یا خاکستری است
4
سند ناقص
سند استخراج شده، اما بعضی صفحه‌ها یا اشیای داخلی آن از بین رفته‌اند
5
تکه‌های بی‌معنی
فقط چند قطعه غیرقابل‌استفاده از داده باقی مانده است
هیچ‌چیز
هیچ داده قابل‌استفاده‌ای پیدا نمی‌شود
مهم‌ترین عامل، بازنویسی است. وقتی فایل‌سیستم فضای فایل حذف‌شده را آزاد اعلام می‌کند، داده‌های تازه می‌توانند همان بلوک‌ها را اشغال کنند. ممکن است فقط یک قسمت کوچک بازنویسی شود، اما همان قسمت هدر، جدول داخلی، آرشیو فشرده یا بخش مهمی از تصویر باشد و کل فایل را غیرقابل‌استفاده کند.
عامل دوم Fragmentation یا تکه‌تکه‌شدن است. اگر یک فایل در چند نقطه جدا از دیسک ذخیره شده باشد و اطلاعات اتصال این تکه‌ها از بین برود، File Carving ساده شاید فقط بخش اول را پیدا کند. بازیابی ویدئوها، فایل‌های فشرده و اسناد پیچیده در این وضعیت دشوارتر می‌شود.
رمزگذاری نیز تعیین‌کننده است. اگر داده روی یک دیسک رمزگذاری‌شده باقی مانده باشد اما کلید در دسترس نباشد، استخراج بایت‌های خام الزاماً محتوای قابل‌خواندن تولید نمی‌کند.

# HDD و SSD یک داستان ندارند

بخش زیادی از تصور مشهور ما درباره بازیابی فایل، از دوران هارددیسک‌های مغناطیسی آمده است. در HDD، سیستم می‌تواند سکتورهای فایل حذف‌شده را دوباره برای نوشتن انتخاب کند، اما تا پیش از آن معمولاً محتوای قبلی در همان محل باقی می‌ماند. به همین دلیل خاموش‌کردن سریع دستگاه می‌تواند شانس بازیابی را حفظ کند.
SSD رفتار پیچیده‌تری دارد. حافظه NAND داده را در Page می‌نویسد، اما پاک‌سازی در واحدهای بزرگ‌تری به نام Block انجام می‌شود. کنترلر SSD نیز با لایه‌ای به نام Flash Translation Layer، نشانی‌های منطقی سیستم‌عامل را به محل‌های فیزیکی نگاشت می‌کند. Wear Leveling و Garbage Collection مرتباً محل داده‌ها را مدیریت می‌کنند.
اینجاست که TRIM وارد می‌شود. سیستم‌عامل با فرمان TRIM به SSD اطلاع می‌دهد که بعضی محدوده‌های منطقی دیگر حاوی داده موردنیاز نیستند. کنترلر می‌تواند آن صفحه‌ها را نامعتبر بداند و هنگام Garbage Collection کنار بگذارد یا بلوک مربوط را پاک کند.
1
حذف فایل — کاربر فایل را پاک می‌کند
2
TRIM — سیستم‌عامل به SSD اطلاع می‌دهد
3
نامعتبرسازی — کنترلر صفحه‌ها را علامت می‌زند
4
Garbage Collection — بلوک‌ها برای استفاده مجدد پاک می‌شوند
HDD

سکتورهای مغناطیسی

  • داده اغلب تا بازنویسی باقی می‌ماند
  • در نبود بازنویسی، File Carving معمولاً بهتر جواب می‌دهد
  • بازنویسی کامل رسانه می‌تواند یک Clear مؤثر باشد
SSD

Page و Blockهای NAND + کنترلر

  • TRIM ممکن است داده را سریع از دسترس خارج کند
  • پس از TRIM، شانس Carving اغلب بسیار کم می‌شود
  • Sanitize / Secure Erase / Crypto Erase ابزار درست این‌جاست
نکته ظریف: TRIM همیشه به این معنی نیست که همان لحظه تمام سلول‌های فیزیکی صفر می‌شوند؛ زمان و نحوه پاک‌سازی به سیستم‌عامل، رابط، کنترلر، Firmware و وضعیت Garbage Collection بستگی دارد. بااین‌حال SSD ممکن است در پاسخ به خواندن آدرس‌های TRIMشده، صفر یا داده نامعتبر برگرداند و بازیابی نرم‌افزاری عادی را خیلی زود ناممکن کند. جمله دقیق این است: اگر TRIM و پاک‌سازی کنترلر روی محدوده فایل اعمال شده باشند، شانس بازیابی معمولاً به‌شدت کاهش می‌یابد و گاهی عملاً صفر می‌شود.

# فلش، کارت حافظه، موبایل و فضای ابری چطور؟

فلش USB و کارت حافظه نیز از حافظه Flash استفاده می‌کنند، اما رفتار آن‌ها بسته به کنترلر، فایل‌سیستم و پشتیبانی از فرمان‌های حذف متفاوت است. نباید صرفاً چون رسانه Flash است، نتیجه SSD داخلی رایانه را برای آن قطعی بدانیم.
در گوشی‌های جدید، رمزگذاری دستگاه، حافظه Flash، مدیریت داخلی سیستم‌عامل و پاک‌سازی کلیدها می‌توانند بازیابی مستقیم را بسیار دشوار کنند. از طرف دیگر ممکن است نسخه‌ای از عکس در پوشه Recently Deleted، نسخه پشتیبان، پیام‌رسان، فضای ابری یا دستگاه دیگری باقی مانده باشد. آنچه کاربر «یک فایل» می‌بیند، گاهی چند نسخه در چند سیستم مختلف است.
در سرویس‌های ابری نیز Delete الزاماً حذف فوری همه نسخه‌ها نیست. سطل زباله، Version History، Snapshot، Backup و سیاست نگهداری سرویس می‌توانند نسخه‌هایی از داده را برای مدتی حفظ کنند — البته دسترسی کاربر عادی به این نسخه‌ها همیشه ممکن نیست و سیاست هر سرویس متفاوت است.
دستگاه شما
Recently Deleted
ابر / همگام‌سازی
نسخه پشتیبان
پیام‌رسان‌ها
Version History

# اگر فایلی را اشتباهی حذف کردیم، چه کنیم؟

مهم‌ترین کار، جلوگیری از نوشتن داده جدید است. هر دانلود، نصب برنامه، به‌روزرسانی، کپی فایل یا حتی فعالیت عادی سیستم می‌تواند از فضای آزاد استفاده کند.
1
استفاده را متوقف کنید — اگر حافظه جانبی است جدا کنید؛ اگر درایو سیستم بوده، دستگاه را خاموش کنید
2
سطل‌ها را ببینید — Recycle Bin / Trash / Recently Deleted
3
Backup و ابر را بررسی کنید — File History، Time Machine، Snapshot
4
برنامه بازیابی را روی همان درایو نصب نکنید — نصب می‌تواند دقیقاً همان فضا را بازنویسی کند
5
فایل بازیابی‌شده را جای دیگری ذخیره کنید — هرگز روی همان رسانه ننویسید
6
برای داده حساس، ابتدا Image بگیرید — روی کپی بیت‌به‌بیت کار کنید تا رسانه اصلی دست‌نخورده بماند
7
صدای تق‌تق یا قطع‌ووصل؟ دست نگه دارید — مشکل مکانیکی کار آزمایشگاه تخصصی است

# اگر می‌خواهیم فایل واقعاً غیرقابل‌بازیابی شود چه؟

اینجا دیگر Delete کافی نیست. حتی Quick Format نیز الزاماً تمام محتوای رسانه را پاک نمی‌کند؛ ممکن است فقط ساختارهای مدیریتی را دوباره بسازد. استاندارد NIST SP 800-88 Revision 2 سه سطح کلی برای پاک‌سازی رسانه تعریف می‌کند:
C
Clear
پاک‌سازی با روش‌های منطقی استاندارد، متناسب با استفاده دوباره در سطح ریسک پایین‌تر
P
Purge
روشی قوی‌تر که بازیابی را حتی با تکنیک‌های آزمایشگاهی پیشرفته بسیار دشوار می‌کند؛ Crypto Erase می‌تواند یکی از روش‌ها باشد
Destroy
نابودی فیزیکی رسانه به‌گونه‌ای که دیگر قابل‌استفاده نباشد
برای HDD، بازنویسی کامل همه فضای قابل‌آدرس‌دهی می‌تواند در بسیاری از سناریوهای معمول روش مؤثری برای Clear باشد. برای SSD، بازنویسی چندباره یک فایل یا حتی فضای ظاهراً خالی تضمین خوبی نیست؛ Wear Leveling و فضای Over-Provisioned ممکن است باعث شوند بعضی سلول‌های فیزیکی هرگز از مسیر عادی سیستم‌عامل بازنویسی نشوند. در این رسانه‌ها باید از قابلیت Sanitize، Secure Erase یا Crypto Erase معتبرِ خود دستگاه و راهنمای سازنده استفاده کرد.
رمزگذاری کامل دیسک از ابتدای استفاده نیز مزیت بزرگی دارد: اگر تمام داده‌ها همیشه با کلید قوی رمز شده باشند و عملیات Crypto Erase کلید را به‌طور قابل‌اعتماد نابود کند، داده باقی‌مانده بدون کلید قابل‌فهم نخواهد بود. البته رمزگذاری‌ای که کلیدش هنوز در Backup، حساب کاربری یا تراشه دیگری موجود است، به‌تنهایی به معنی پاک‌سازی کامل نیست.

# پنج باور اشتباه درباره فایل‌های حذف‌شده

باور ۱
  • «هر فایل حذف‌شده‌ای قابل بازیابی است»
  • بازنویسی، TRIM، خرابی و کلید گم‌شده این‌طور نمی‌گویند
باور ۲
  • «Delete تمام بایت‌ها را صفر می‌کند»
  • معمولاً ابتدا فقط فراداده تغییر می‌کند
باور ۳
  • «Format همیشه اطلاعات را نابود می‌کند»
  • Quick Format معمولاً فقط ساختار را بازسازی می‌کند
باور ۴
  • «ده‌ها بار بازنویسی لازم است»
  • نسخه جادویی و یکسان برای همه رسانه‌ها وجود ندارد
باور ۵
  • «TRIM همان لحظه همه سلول‌ها را پاک می‌کند»
  • زمان پاک‌سازی فیزیکی متفاوت است — اما دسترسی سریع قطع می‌شود
درباره باور چهارم: روش باید متناسب با HDD، SSD، قابلیت‌های Firmware و سطح حساسیت انتخاب شود. چندین Pass بازنویسی روی SSD حتی می‌تواند فقط نوشتن اضافی ایجاد کند، بی‌آنکه تمام سلول‌های پنهان را پوشش دهد.

# حذف‌کردن با نابودکردن فرق دارد

دو جمله زیر شبیه‌اند، اما معنی یکسانی ندارند:
«سیستم‌عامل دیگر فایل را نمایش نمی‌دهد»

گزاره‌ای درباره دیده‌شدن

«اطلاعات فایل دیگر روی هیچ بخش قابل‌بازیابی وجود ندارد»

گزاره‌ای درباره نابودی

دکمه Delete در بسیاری از مواقع شبیه خارج‌کردن نام کتاب از فهرست است، نه سوزاندن خود کتاب. این تفاوت هم امیدبخش است و هم هشداردهنده: امیدبخش، چون ممکن است عکس یا سندی که اشتباهی حذف کرده‌ایم هنوز قابل بازگشت باشد؛ هشداردهنده، چون فروش یا دور انداختن یک حافظه بدون پاک‌سازی درست می‌تواند اطلاعات خصوصی ما را در اختیار نفر بعدی قرار دهد.
فایل‌های حذف‌شده «زنده» نمی‌شوند؛ آن‌ها گاهی از ابتدا نمرده‌اند. فقط مسیر رسمی رسیدن به آن‌ها از بین رفته است. ابزار بازیابی این مسیر را دوباره پیدا می‌کند یا با بررسی مستقیم داده خام، قطعات باقی‌مانده را کنار هم می‌گذارد.
takeaway.txt
Delete یعنی سیستم فایل را فراموش کرده است؛
Sanitize یعنی داده طوری از بین رفته
که دیگر هیچ راهی برای رسیدن به آن نباشد.

# مقالات مرتبط