SSD ကို Quick Format ဒါမှမဟုတ် SSD ထဲက Data တွေ ဖျက်လိုက်ရင် ဘယ်လိုရယူနိုင်မလဲ ?
SSD တစ်လုံးဆီက Data ပြန်ရဖို့ဆိုရင် L2P Table (Logical-to-Physical Table) အကြောင်းကို အရင်နားလည်ဖို့ လိုပါတယ်။
L2P Table ဆိုတာ ဘာလဲ ?
L2P Table ဆိုတာ SSD တစ်လုံးမှာ Computer မြင်ရတဲ့ address (Logical) နဲ့ Data တွေ တကယ်ရှိနေတဲ့ Flash Chip ထဲကနေရာ (Physical) ကို ချိတ်ဆက်ပေးထားတဲ့ မြေပုံ ဖြစ်ပါတယ်။ SSD တွေဟာ Data တွေကို နေရာချရင် (Static) အနေနဲ့ သိမ်းတာမဟုတ်ဘဲ Wear leveling အရအမြဲနေရာရွှေ့နေတဲ့အတွက် ဒီ Table မရှိရင် Data တွေကို ရှာမတွေ့နိုင်ပါဘူး။
ဘာကြောင့် L2P Table လိုအပ်တာလဲ ?
HDD တွေမှာတော့ ဒေတာတစ်ခုကို ဖျက်ပြီး အဲဒီနေရာမှာပဲ ပြန်ရေး (Overwrite) လို့ ရပါတယ်။
ဒါပေမဲ့ SSD မှာတော့ Data ရှိတဲ့နေတဲ့နေရာတွေမှာ နောက်ထပ် Data ထပ်ပြီး Write လို့ မရပါဘူး။
အရင်ဖျက် (Erase) လုပ် ပြီးမှ ပြန် Write လို့ ရပါတယ်။ Wear Leveling အလုပ်ကတော့ Flash chip တစ်နေရာတည်းကိုပဲ ခဏခဏ Data သွား Write နေရင် အဲဒီနေရာက မြန်မြန်ပျက်စီးသွားပါလိမ့်မယ်။ ဒါကြောင့် Controller က ဒေတာတွေကို SSD ရဲ့Chip တစ်ခုလုံးမှာ နှံ့နေအောင် လိုက်ဖြန့်သိမ်းပါတယ်။
Format ချလိုက်တဲ့အခါ ဒါမှမဟုတ် Delete လုပ်တဲ့အခါ ဘာဖြစ်သလဲ ?
TRIM Command ကြောင့် L2P Table ထဲမှာရှိတဲ့ Logical To Physical Address ချိတ်ဆက်မှု တွေကို ဖျက်ချလိုက်ပါတယ်။ အဲဒီအခါ OS က Data တွေဖတ်ဖို့ တောင်းဆိုရင် Controller က L2P ထဲမှာ ရှာမတွေ့တော့တဲ့အတွက် (00) တွေကိုပဲ ပြန်ပေးပါတော့တယ်။ ဒါကို ကျွန်တော်တို့က SSD ထဲမှာ Data တွေ ပျက်သွားပြီလို့ ထင်ကြတာပါ။
Professional Recovery နဲ့ Forensic Analysis မှာ ဘယ်လိုလုပ်လဲ ?
၁။ Techno Mode (Special Access)
SSD Controller ရဲ့ Safe Mode ထဲဝင်အောင် လုပ်လိုက်ပါတယ်။ ဒါမှ Firmware ရဲ့ ပုံမှန်အလုပ်လုပ်ပုံကို ကျော်ဖြတ်ပြီး Hardware ကို တိုက်ရိုက်ခိုင်းစေနိုင်မှာဖြစ်ပါတယ်။
၂။ Virtual Translator တည်ဆောက်တဲ့နည်း။
(L2P Table) က ပျက်သွားပေမဲ့ Flash Chip ထဲမှာ Data တွေက ရှိနေသေးတဲ့အတွက် Recovery Hardware or software က Chip တစ်ခုလုံးကို Scan ဖတ်ပြီး Virtual Translator (မြေပုံအတု) တစ်ခုကို ကိုယ်တိုင်ပြန်လည်တည်ဆောက်ပါတယ်။
၃။ Translator Version ဟောင်းများကို ပြန်ရှာတဲ့နည်း။
SSD ရဲ့ Internal Memory ထဲမှာ သိမ်းထားလေ့ရှိတဲ့ အရင်ကသုံးခဲ့ဖူးတဲ့ Translator Version ဟောင်းတွေ ကို ရှာဖွေပြီး Format မချခင်က အခြေအနေအတိုင်း (File Structure အတိုင်း) Data တွေကို ပြန်လည်ရယူတာဖြစ်ပါတယ်။
SSD တစ်လုံး အလုပ်မလုပ်တော့ရင် (ဥပမာ- Busy ဖြစ်နေတာ။ Data မြင်ရတယ် Copy or Access လုပ်ရင် လေးနေတာမျိူး)။ Capacity အမှားကြီးပြနေတာမျိုး။ ဒါမှမဟုတ် PC ကနေ SSD ကိုမသိတာမျိုး) ဖြစ်ရင် SSD အထဲက Controller လောင်သွားပြီ၊ ဒါမှမဟုတ် Data တွေ ပျက်ကုန်ပြီ" လို့ ယူဆလေ့ရှိကြပါတယ်။ ဒါပေမဲ့ တကယ်တမ်းမှာတော့ သူ့ရဲ့ Firmware ပျက်နေတာမျိုးက ပိုများပါတယ်။
ဖုန်းတစ်လုံးမှာ Android OS တက်မလာတော့ရင် ကျွန်တော်တို့ Fastboot Mode ဒါမှမဟုတ် Recovery Mode ထဲကို ၀င်ရပါတယ်။
SSD မှာလည်း အဲဒီလိုပဲသူ့ရဲ့ မူလ Firmware က NAND Flash ထဲကနေ တက်မလာတော့တဲ့အခါ ကျွန်တော်တို့က Techno Mode (Technological Mode) ထဲကို အတင်းဝင်ခိုင်းရပါတယ်။ ဒါက SSD ရဲ့ Factorty Service Mode ထဲကို ဝင်လိုက်တာပါပဲ။ ဒီ Mode ထဲရောက်မှသာ ကျွန်တော်တို့က ပြင်ပကနေ Loader (LDR) လို့ခေါ်တဲ့ Software အသေးစားလေးကို သူ့ရဲ့ RAM ထဲ ပို့ပေးလို့ရမှာပါ။
Phone Hardware သမားတွေဆိုရင် JTAG အကြောင်း သိကြမှာပါ။ CPU ဆီကို တိုက်ရိုက်လမ်းကြောင်း (Pin) တွေကနေတစ်ဆင့် ဝင်ပြီး Data ယူလို့ရရင်ယူတာ၊ Firmware ပြန်ရေးတာမျိုးပေါ့။
SSD မှာရှိတဲ့ Techno Mode Pins ဆိုတာကလည်း JTAG လိုပါပဲ။ PCB ပေါ်က သတ်မှတ်ထားတဲ့ Pins လေးတွေကို Short လုပ်လိုက်ခြင်းအားဖြင့် SSD ရဲ့ Controller ကို ပုံမှန်လမ်းကြောင်းအတိုင်း Boot မတက်နဲ့တော့၊ ငါပြောတာကိုပဲ နားထောင်တော့ လို့ Command ပေးလိုက်တာ ဖြစ်ပါတယ်။
Techno Mode သို့မဟုတ် Factory Service Mode ဆိုတာ SSD တိုင်းမှာ သီအိုရီအရတော့ပါဝင်ပါတယ်။ ဘာကြောင့်လဲဆိုတော့ SSD ထုတ်လုပ်သူတွေဟာ စက်ရုံကနေ မထုတ်ခင် Firmware တင်ဖို့နဲ့ စစ်ဆေးမှုတွေလုပ်ဖို့အတွက် Techno Mode ပါ၀င်ပါတယ်။
ဒါပေမဲ့ Manufacture အလိုက် Mode ထဲကို ၀င်ဖို့ သီးသန့် Command တွေရှိပါတယ်။ အတွေ့အကြုံအရ Budge SSD တွေက ပိုလွယ်ပါတယ်။ Techno Mode ထဲဝင်နိုင်လို့ ဒေတာတွေ မြင်ရပြီဆိုဦးတော့၊ ဈေးကြီးတဲ့ Update ဖြစ်တဲ့ SSD တွေမှာ နောက်ထပ် အတားအဆီးတစ်ခု ရှိပါသေးတယ်။
အဲဒါကတော့ Hardware Encryption ပါ။
Controller က ဒေတာတွေကို NAND Flash ထဲမှာ သိမ်းကတည်းက AES-256 လိုမျိုး Encryption နဲ့ သိမ်းတာပါ။ တကယ်လို့ Controller ကိုယ်တိုင် လောင်သွားလို့ တခြားအမျိုးအစားတူ SSD Drive က Controller နဲ့ လဲလိုက်မယ်ဆိုရင်တောင် Encryption Key မတူတဲ့အတွက် Data တွေကို Decrypt လုပ်လို့ ဖတ်လို့ ရမှာ မဟုတ်ပါဘူး။
ဒီနေရာမှာ Professional Recovery/ Forensic Tools တွေက Controller ရဲ့ RAM ထဲကနေ Encryption Keys တွေကို ဆွဲထုတ်နိုင်ဖို့ ကြိုးစားရပါတယ်။ Key မရရင်တော့ ဒေတာတွေက Zero တွေ ဒါမှမဟုတ် Garbage Data တွေအဖြစ်နဲ့ပဲ မြင်ရမှာပါ။
SSD တစ်လုံးဆီက Data ပြန်ယူတယ်ဆိုတာ ဖုန်းတစ်လုံးကို Fastboot သွင်းပြီး Firmware ပြန်တင်ရသလိုမျိုးပါပဲ။
၁။ Techno Mode Pin ကို ရှာရမယ် (Fastboot ဝင်သလိုမျိုးပါ။)
၂။ Loader တင်ရမယ် (Firmware တင်သလိုမျိုးပါ။)
၃။ Encryption ကို ကျော်ရမယ် (Password ကျော်သလိုမျိုးပါ။)
၄။ L2P Table ကို ပြန်ဆောက်ရပါမယ်။
၅။ SSD တိုင်း အခုလိုနည်းနဲ့ရတဲ့ SSD ရှိသလို မရတဲ့ SSD လဲရှိပါတယ်။
ပုံမှန်အားဖြင့်တော့ SSD ရဲ့ Translator Map က NAND Flash ထဲမှာ ရှိနေရမှာပါ။ ဒါပေမဲ့ Controller Corrupt ဖြစ်တာပဲဖြစ်ဖြစ် / Trim ကို ကျော်ချင်တာ /Data ပြန်ရချင်တဲ့အခါမျိုးမှာ
ကွန်ပျူတာရဲ့ RAM ပေါ်မှာ Virtual Translator Nap တစ်ခုကို အစကနေ ပြန်ဆောက်ယူရပါတယ်။
RAW Level မှာ Data ဖတ်နိုင်ဖို့ Controller ကို Techno Mode ထဲ သွင်းပြီး Loader တင်လိုက်တဲ့အခါ Controller ကိုကျော်ပြီး ကျွန်တော်တို့က NAND Flash Chips တွေထဲက Pages တိုင်းကို Raw Level အတိုင်း Scan ဖတ်ပါတယ်။
Hard Disk (HDD) တွေမှာ Data တစ်ခုကို ပြင်ချင်ရင် မူလနေရာမှာတင် ထပ်ရေး (Overwrite) လို့ ရပါတယ်။ ဒါပေမဲ့ SSD (NAND Flash) ရဲ့ သဘာက မူလနေရာမှာတင် ထပ်ရေးလို့ မရပါဘူး။ Data တစ်ခုကို ပြင်လိုက်တိုင်း Controller က SSD ရဲ့ နေရာအသစ် (Empty Block) တစ်ခုကို ရှာပြီး အဲဒီမှာပဲ သွားရေးပါတယ်။
ဥပမာ- စာတစ်ကြောင်း ပြင်လိုက်တိုင်း SSD ထဲမှာ အဲဒီစာရဲ့ Version အဟောင်းတွေ ကျန်နေခဲ့ပါတယ်။ ဒါကို Write-on-Modify လို့ ခေါ်ပါတယ်။
ဒီလိုနဲ့ Data တစ်ခုတည်း (ဥပမာ Logical Block - LBA - 500) အတွက် Physical နေရာတွေ အများကြီး ဖြစ်လာတာပါ။
NAND Flash ရဲ့ Page တစ်ခုမှာ User Data သိမ်းတဲ့နေရာ (ဥပမာ- SSD Data သိမ်းတဲ့ Page Size 4KB) အပြင်၊ ဘေးမှာ သာမန် User မမြင်ရတဲ့ Spare Area (Out-of-Band Area) ဆိုတာ ရှိပါတယ်။ ဒီနေရာလေးထဲမှာ Controller က Matadata Tag လေးတွေ ရေးပေးထားတာပါ။
LBA (Logical Block Address) - LBA 500
Sequence Number (SN) - 1000 (SSD စသုံးကတည်းက ရေးခဲ့တဲ့ အကြိမ်ရေ 1000 မြောက်မှာ ရေးတဲ့ ဆိုတဲ့ အမှတ်စဉ်။)
Chip တစ်ခုလုံးကို Scan ဖတ်တဲ့အခါ LBA 500 ဆိုတဲ့ နာမည်ကတ်နဲ့ ဒေတာ ၃ ခု သွားတွေ့တယ် ဆိုပါစို့။
နေရာ (1) LBA 500 | Sequence No: 1000
နေရာ (2) LBA 500 | Sequence No: 1025
နေရာ (3) LBA 500 | Sequence No: 1050
Algorithm က ဒီ Sequence နံပါတ်တွေကို တန်းစီကြည့်လိုက်ပါတယ်။ 1050 က အကြီးဆုံး (နောက်ဆုံးမှ ရေးထားတာ) ဖြစ်တဲ့အတွက် နေရာ (3) က Data ကိုပဲ အမှန် လို့ သတ်မှတ်ပြီး Virtual Translator မြေပုံထဲမှာ ထည့်လိုက်ပါတယ်။ ကျန်တဲ့ နေရာ (1) နဲ့ (2) ကိုတော့ Stale Data ( Data အဟောင်း) တွေအဖြစ် သတ်မှတ်ပြီး ချန်ထားခဲ့ပါတယ်။ Digital Forensics မှာဆိုရင် ဒီ Sequence Number နိမ့်တဲ့ Data တွေကိုပါ ယူပြီး အရင်က ဘာတွေ ရှိခဲ့သလဲဆိုပြီး Deleted Data တွေကိုပါ ပြန်ဖော်နိုင်ပါတယ်။
အချို့ Recovery Software တွေမှာ Map ဆောက်တာကို အလိုအလျောက် မလုပ်ပေးနိုင်ရင် hex pattern matching ဆိုတဲ့ နည်းနဲ့ ကိုယ်တိုင် Manual pattern လိုက်ရှာလို့ရပါတယ်။
Hex editor ထဲမှာ signature (ဥပမာ PDF တို့ JPEG တို့ရဲ့ Heard တွေကို ရှာပြီး metadata ဘယ်နားမှာလဲ၊ LBA က ဘယ်နေရာမှာလဲဆိုတာကို ကိုယ်တိုင်လိုက်တွက်ပြီး manual translator correction လုပ်နိုင်ပါတယ်။
Comments