Tym razem kilka słów o tym, jak skutecznie usunąć plik na NTFS z poziomu działającego systemu operacyjnego. Po co? By zatrzeć za sobą ślady. Chodzi na przykład o taką sytuację, gdy zlecenie jest wykonywane na sprzęcie zleceniodawcy, bo istniejące polityki nie pozwalają na podpięcie własnego sprzętu. A przy okazji chodzi mi o pokazanie jak łatwo jest odzyskać usunięte (nie zamazane) dane. Nie będę się zajmował rozważaniami ile razy trzeba coś nadpisać, by oni nic nie odzyskali.
O usuwaniu plików (na NTFS)
Narzędzia...
Tym razem wykorzystam fajny zestaw narzędzi o nazwie Sleuthkit. Co prawda można ułatwiać sobie życie korzystając dodatkowo z Autopsy, ale obejdzie się bez tego.
Całość testów wykonuję na pamięci USB, dla oszczędności czasu 256MiB przestrzeni w zupełności wystarczy.
No to zaczynamy...
Na początku kilka informacji o systemie plików, które można uzyskać za pomocą narzędzia fsstat. Jak widać system plików to NTF w wersji z Windows XP. Świeżo sformatowany.
Za pomocą narzędzia fls można obejrzeć co jest w tej chwili "na dysku":
Po założeniu katalogu test i utworzeniu w nim pliku test.txt całość wygląda tak (czasami trzeba chwilę zaczekać, by system zrobił sync na pena):
Jak widać pojawił się zarówno założony katalog, jak i plik. Teraz można obejrzeć dokładniejsze informacje (metadane) na temat stworzonego pliku za pomocą polecenia istat:
To samo polecenie po usunięciu pliku (standardowym poleceniem del) pokaże coś takiego:
Jak widać jedyną różnicą między plikiem usuniętym, a istniejącym jest to, że rekord w MFT został oznaczony jako niewykorzystany. Niezmienione pozostały natomiast wszelkie informacje o pliku (metadane), jak i sama zawartość pliku, którą łatwo odczytać za pomocą narzędzia icat podając adres strumienia $DATA, czyli w tym przypadku 28-128-1:
Jednym z narzędzi, które pozwalają na nadpisanie usuwanego pliku jest sdelete z Sysinternals. Standardowo nie jest ono dostępne w systemie, ma jednak taką zaletę, że nie wymaga instalacji. Po usunięciu pliku za jego pomocą, stosowny rekord w MFT wygląda tak (wcześniej zawartość nośnika odtworzyłem z obrazu stworzonego na samym początku):
Jak widać zmian jest zdecydowanie więcej niż w przypadku zwykłego usunięcia. Dodatkowo nadpisana została nazwa pliku. Nie można odczytać również zawartości pliku, bo została nadpisana:
A jak wyczyścić dane po usunięciu?
W tym celu trzeba nadpisać całą wolną przestrzeń dysku. Wada jest taka, że mogą pozostać metadane o plikach. Aby to dokładniej pokazać, utworzę dodatkowo kilka plików:
Po usunięciu plików (łączenie z katalogiem) całość wygląda tak:
Informacje o starych plikach można uzyskać na przykład przy pomocy narzędzia ils (rezultat trochę uproszczony):
W pierwszej kolumnie znajduje się informacja gdzie szukać danych o danym obiekcie. Dla przykładu pod numerem 27 kryje się informacja o katalogu:
A pod numerem 38, informacja o jednym z plików:
Dla porządku odczytajmy jego zawartość:
To teraz pora na wyczyszczenie wolnego miejsca. Dla odmiany do tego zadania użyję narzędzia, które jest w systemie, a mianowicie polecenia cipher /w:nazwa_dysku. Powoduje to nadpisanie całości wolnego miejsca trzy razy:
Rezultat polecenia ils na nadpisanym dysku nie różni się bardzo od poprzedniego rezultatu (choć można zauważyć różnice w kolumnach oznaczających daty, a także różnicę w kolumnie określającej rozmiar):
Odczytajmy jednak metadane dotyczące rekordu 27:
Jak widać polecenie cipher samo do swojej pracy zakłada katalog (a w nim tworzy pliki), do których pisze. Tak się więc złożyło, że wcześniejszy katalog został "ponownie wykorzystany" i w MFT znajdują się dane dotyczące katalogu stworzonego w trakcie czyszczenia. Wracając do rezultatów polecenia ils można zauważyć, że zmodyfikowane zostały rekordy od 27 do 35 włącznie. Dla pewności istat dla 35:
Jednak sprawdzany wcześniej rekord 38 pozostał niezmieniony:
Nadal można odczytać metadane o pliku, w szczególności:
Co więcej okazuje się, że zawartość części plików nadal można odczytać (w szczególności dla rekordu 38):
Dlaczego? Dlatego, że rozmiar pliku jest mały, całość danych mieści się w MFT, a rekord MFT nie jest nadpisywany podczas pisania do pliku. Ups... Co potrafi zrobić sdelete? Uruchamiam go na dysku wcześniej wyczyszczonym (jak się okazuje - nie do końca skutecznie) przy pomocy cipher. Rezultat? Najpierw ils:
Jak widać zmian jest sporo, przede wszystkim plików jest więcej. Wynika to z zasady działania sdelete opisanej na stronie narzędzia.
Co się kryje więc w nieszczęsnym rekordzie 38?
Jak widać założony został nowy plik, jego zawartość (720 bajtów) to losowe śmieci:
Sukces!
Cel został osiągnięty. Usunięte zostały nie tylko informacje zawarte w pliku, ale również metadane opisujące usunięte pliki. Co prawda wiadomo, że coś było, nie wiadomo jednak dokładnie co i kiedy...
Tym razem wykorzystam fajny zestaw narzędzi o nazwie Sleuthkit. Co prawda można ułatwiać sobie życie korzystając dodatkowo z Autopsy, ale obejdzie się bez tego.
Całość testów wykonuję na pamięci USB, dla oszczędności czasu 256MiB przestrzeni w zupełności wystarczy.
No to zaczynamy...
Na początku kilka informacji o systemie plików, które można uzyskać za pomocą narzędzia fsstat. Jak widać system plików to NTF w wersji z Windows XP. Świeżo sformatowany.
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: NTFS
Volume Serial Number: 28545FF7545FC66A
OEM Name: NTFS
Version: Windows XP
METADATA INFORMATION
--------------------------------------------
First Cluster of MFT: 170666
First Cluster of MFT Mirror: 255999
Size of MFT Entries: 1024 bytes
Size of Index Records: 4096 bytes
Range: 0 - 31
Root Directory: 5
CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 512
Total Cluster Range: 0 - 511998
Total Range in Image: 0 - 498014
Total Sector Range: 0 - 511998
$AttrDef Attribute Values:
$STANDARD_INFORMATION (16) Size: 48-72 Flags: Resident
$ATTRIBUTE_LIST (32) Size: No Limit Flags: Non-resident
$FILE_NAME (48) Size: 68-578 Flags: Resident,Index
$OBJECT_ID (64) Size: 0-256 Flags: Resident
$SECURITY_DESCRIPTOR (80) Size: No Limit Flags: Non-resident
$VOLUME_NAME (96) Size: 2-256 Flags: Resident
$VOLUME_INFORMATION (112) Size: 12-12 Flags: Resident
$DATA (128) Size: No Limit Flags:
$INDEX_ROOT (144) Size: No Limit Flags: Resident
$INDEX_ALLOCATION (160) Size: No Limit Flags: Non-resident
$BITMAP (176) Size: No Limit Flags: Non-resident
$REPARSE_POINT (192) Size: 0-16384 Flags: Non-resident
$EA_INFORMATION (208) Size: 8-8 Flags: Resident
$EA (224) Size: 0-65536 Flags:
$LOGGED_UTILITY_STREAM (256) Size: 0-65536 Flags: Non-resident
Za pomocą narzędzia fls można obejrzeć co jest w tej chwili "na dysku":
r/r 4-128-4: $AttrDef
r/r 8-128-2: $BadClus
r/r 8-128-1: $BadClus:$Bad
r/r 6-128-1: $Bitmap
r/r 7-128-1: $Boot
d/d 11-144-4: $Extend
r/r 25-144-2: $Extend/$ObjId:$O
r/r 24-144-3: $Extend/$Quota:$O
r/r 24-144-2: $Extend/$Quota:$Q
r/r 26-144-2: $Extend/$Reparse:$R
r/r 2-128-1: $LogFile
r/r 0-128-1: $MFT
r/r 1-128-1: $MFTMirr
r/r 9-128-8: $Secure:$SDS
r/r 9-144-6: $Secure:$SDH
r/r 9-144-5: $Secure:$SII
r/r 10-128-1: $UpCase
r/r 3-128-3: $Volume
Po założeniu katalogu test i utworzeniu w nim pliku test.txt całość wygląda tak (czasami trzeba chwilę zaczekać, by system zrobił sync na pena):
r/r 4-128-4: $AttrDef
r/r 8-128-2: $BadClus
r/r 8-128-1: $BadClus:$Bad
r/r 6-128-1: $Bitmap
r/r 7-128-1: $Boot
d/d 11-144-4: $Extend
r/r 25-144-2: $Extend/$ObjId:$O
r/r 24-144-3: $Extend/$Quota:$O
r/r 24-144-2: $Extend/$Quota:$Q
r/r 26-144-2: $Extend/$Reparse:$R
r/r 2-128-1: $LogFile
r/r 0-128-1: $MFT
r/r 1-128-1: $MFTMirr
r/r 9-128-8: $Secure:$SDS
r/r 9-144-6: $Secure:$SDH
r/r 9-144-5: $Secure:$SII
r/r 10-128-1: $UpCase
r/r 3-128-3: $Volume
d/d 27-144-1: test
r/r 28-128-1: test/test.txt
Jak widać pojawił się zarówno założony katalog, jak i plik. Teraz można obejrzeć dokładniejsze informacje (metadane) na temat stworzonego pliku za pomocą polecenia istat:
MFT Entry Header Values:
Entry: 28 Sequence: 1
$LogFile Sequence Number: 1056000
Allocated File
Links: 1
$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Created: Fri Feb 01 12:54:07 2008
File Modified: Fri Feb 01 12:54:07 2008
MFT Modified: Fri Feb 01 12:54:07 2008
Accessed: Fri Feb 01 12:54:07 2008
$FILE_NAME Attribute Values:
Flags: Archive
Name: test.txt
Parent MFT Entry: 27 Sequence: 1
Allocated Size: 0 Actual Size: 0
Created: Fri Feb 01 12:54:07 2008
File Modified: Fri Feb 01 12:54:07 2008
MFT Modified: Fri Feb 01 12:54:07 2008
Accessed: Fri Feb 01 12:54:07 2008
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-2) Name: N/A Resident size: 82
Type: $DATA (128-1) Name: $Data Resident size: 18
To samo polecenie po usunięciu pliku (standardowym poleceniem del) pokaże coś takiego:
MFT Entry Header Values:
Entry: 28 Sequence: 2
$LogFile Sequence Number: 1057735
Not Allocated File
Links: 1
$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Created: Fri Feb 01 12:54:07 2008
File Modified: Fri Feb 01 12:54:07 2008
MFT Modified: Fri Feb 01 12:54:07 2008
Accessed: Fri Feb 01 12:54:07 2008
$FILE_NAME Attribute Values:
Flags: Archive
Name: test.txt
Parent MFT Entry: 27 Sequence: 1
Allocated Size: 0 Actual Size: 0
Created: Fri Feb 01 12:54:07 2008
File Modified: Fri Feb 01 12:54:07 2008
MFT Modified: Fri Feb 01 12:54:07 2008
Accessed: Fri Feb 01 12:54:07 2008
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-2) Name: N/A Resident size: 82
Type: $DATA (128-1) Name: $Data Resident size: 18
Jak widać jedyną różnicą między plikiem usuniętym, a istniejącym jest to, że rekord w MFT został oznaczony jako niewykorzystany. Niezmienione pozostały natomiast wszelkie informacje o pliku (metadane), jak i sama zawartość pliku, którą łatwo odczytać za pomocą narzędzia icat podając adres strumienia $DATA, czyli w tym przypadku 28-128-1:
E:\test\test.txt
Jednym z narzędzi, które pozwalają na nadpisanie usuwanego pliku jest sdelete z Sysinternals. Standardowo nie jest ono dostępne w systemie, ma jednak taką zaletę, że nie wymaga instalacji. Po usunięciu pliku za jego pomocą, stosowny rekord w MFT wygląda tak (wcześniej zawartość nośnika odtworzyłem z obrazu stworzonego na samym początku):
MFT Entry Header Values:
Entry: 28 Sequence: 2
$LogFile Sequence Number: 1063254
Not Allocated File
Links: 1
$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Created: Fri Feb 01 12:54:07 2008
File Modified: Fri Feb 01 13:10:24 2008
MFT Modified: Fri Feb 01 13:10:24 2008
Accessed: Fri Feb 01 13:10:24 2008
$FILE_NAME Attribute Values:
Flags: Archive
Name: ZZZZ.ZZZ
Parent MFT Entry: 27 Sequence: 1
Allocated Size: 24 Actual Size: 18
Created: Fri Feb 01 12:54:07 2008
File Modified: Fri Feb 01 13:10:24 2008
MFT Modified: Fri Feb 01 13:10:24 2008
Accessed: Fri Feb 01 13:10:24 2008
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-28) Name: N/A Resident size: 82
Type: $DATA (128-1) Name: $Data Resident size: 18
Jak widać zmian jest zdecydowanie więcej niż w przypadku zwykłego usunięcia. Dodatkowo nadpisana została nazwa pliku. Nie można odczytać również zawartości pliku, bo została nadpisana:
▬\║żE+wKťq ę}‼Ć↕
A jak wyczyścić dane po usunięciu?
W tym celu trzeba nadpisać całą wolną przestrzeń dysku. Wada jest taka, że mogą pozostać metadane o plikach. Aby to dokładniej pokazać, utworzę dodatkowo kilka plików:
r/r 4-128-4: $AttrDef
r/r 8-128-2: $BadClus
r/r 8-128-1: $BadClus:$Bad
r/r 6-128-1: $Bitmap
r/r 7-128-1: $Boot
d/d 11-144-4: $Extend
r/r 25-144-2: $Extend/$ObjId:$O
r/r 24-144-3: $Extend/$Quota:$O
r/r 24-144-2: $Extend/$Quota:$Q
r/r 26-144-2: $Extend/$Reparse:$R
r/r 2-128-1: $LogFile
r/r 0-128-1: $MFT
r/r 1-128-1: $MFTMirr
r/r 9-128-8: $Secure:$SDS
r/r 9-144-6: $Secure:$SDH
r/r 9-144-5: $Secure:$SII
r/r 10-128-1: $UpCase
r/r 3-128-3: $Volume
d/d 27-144-5: test
r/r 29-128-1: test/1.txt
r/r 38-128-1: test/10.txt
r/r 30-128-1: test/2.txt
r/r 31-128-1: test/3.txt
r/r 32-128-1: test/4.txt
r/r 33-128-1: test/5.txt
r/r 34-128-1: test/6.txt
r/r 35-128-1: test/7.txt
r/r 36-128-1: test/8.txt
r/r 37-128-1: test/9.txt
r/r 28-128-1: test/test.txt
Po usunięciu plików (łączenie z katalogiem) całość wygląda tak:
r/r 4-128-4: $AttrDef
r/r 8-128-2: $BadClus
r/r 8-128-1: $BadClus:$Bad
r/r 6-128-1: $Bitmap
r/r 7-128-1: $Boot
d/d 11-144-4: $Extend
r/r 25-144-2: $Extend/$ObjId:$O
r/r 24-144-3: $Extend/$Quota:$O
r/r 24-144-2: $Extend/$Quota:$Q
r/r 26-144-2: $Extend/$Reparse:$R
r/r 2-128-1: $LogFile
r/r 0-128-1: $MFT
r/r 1-128-1: $MFTMirr
r/r 9-128-8: $Secure:$SDS
r/r 9-144-6: $Secure:$SDH
r/r 9-144-5: $Secure:$SII
r/r 10-128-1: $UpCase
r/r 3-128-3: $Volume
d/- 0: test
Informacje o starych plikach można uzyskać na przykład przy pomocy narzędzia ils (rezultat trochę uproszczony):
27|f|0|0|1201868630|1201868630|1201868630|40777|1|4144|0|0
28|f|0|0|1201866847|1201866847|1201866847|100777|1|18|0|0
29|f|0|0|1201868555|1201868555|1201868555|100777|1|33|0|0
30|f|0|0|1201868555|1201868555|1201868555|100777|1|48|0|0
31|f|0|0|1201868555|1201868555|1201868555|100777|1|63|0|0
32|f|0|0|1201868555|1201868555|1201868555|100777|1|78|0|0
33|f|0|0|1201868555|1201868555|1201868555|100777|1|93|0|0
34|f|0|0|1201868555|1201868555|1201868555|100777|1|108|0|0
35|f|0|0|1201868555|1201868555|1201868555|100777|1|123|0|0
36|f|0|0|1201868555|1201868555|1201868555|100777|1|138|0|0
37|f|0|0|1201868555|1201868555|1201868555|100777|1|153|0|0
38|f|0|0|1201868555|1201868555|1201868555|100777|1|169|0|0
W pierwszej kolumnie znajduje się informacja gdzie szukać danych o danym obiekcie. Dla przykładu pod numerem 27 kryje się informacja o katalogu:
MFT Entry Header Values:
Entry: 27 Sequence: 2
$LogFile Sequence Number: 1066176
Not Allocated Directory
Links: 1
$STANDARD_INFORMATION Attribute Values:
Flags:
Owner ID: 0
Created: Fri Feb 01 12:54:00 2008
File Modified: Fri Feb 01 13:23:50 2008
MFT Modified: Fri Feb 01 13:23:50 2008
Accessed: Fri Feb 01 13:23:50 2008
$FILE_NAME Attribute Values:
Flags: Directory
Name: test
Parent MFT Entry: 5 Sequence: 5
Allocated Size: 0 Actual Size: 0
Created: Fri Feb 01 12:54:00 2008
File Modified: Fri Feb 01 12:54:00 2008
MFT Modified: Fri Feb 01 12:54:00 2008
Accessed: Fri Feb 01 12:54:00 2008
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-2) Name: N/A Resident size: 74
Type: $INDEX_ROOT (144-5) Name: $I30 Resident size: 48
Type: $INDEX_ALLOCATION (160-3) Name: $I30 Non-Resident size: 4096
170655 170656 170657 170658 170659 170660 170661 170662
Type: $BITMAP (176-4) Name: $I30 Resident size: 8
A pod numerem 38, informacja o jednym z plików:
MFT Entry Header Values:
Entry: 38 Sequence: 2
$LogFile Sequence Number: 1065344
Not Allocated File
Links: 1
$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Created: Fri Feb 01 13:22:35 2008
File Modified: Fri Feb 01 13:22:35 2008
MFT Modified: Fri Feb 01 13:22:35 2008
Accessed: Fri Feb 01 13:22:35 2008
$FILE_NAME Attribute Values:
Flags: Archive
Name: 10.txt
Parent MFT Entry: 27 Sequence: 1
Allocated Size: 0 Actual Size: 0
Created: Fri Feb 01 13:22:35 2008
File Modified: Fri Feb 01 13:22:35 2008
MFT Modified: Fri Feb 01 13:22:35 2008
Accessed: Fri Feb 01 13:22:35 2008
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-2) Name: N/A Resident size: 78
Type: $DATA (128-1) Name: $Data Resident size: 169
Dla porządku odczytajmy jego zawartość:
E:\test\1.txt
E:\test\10.txt
E:\test\2.txt
E:\test\3.txt
E:\test\4.txt
E:\test\5.txt
E:\test\6.txt
E:\test\7.txt
E:\test\8.txt
E:\test\9.txt
E:\test\test.txt
To teraz pora na wyczyszczenie wolnego miejsca. Dla odmiany do tego zadania użyję narzędzia, które jest w systemie, a mianowicie polecenia cipher /w:nazwa_dysku. Powoduje to nadpisanie całości wolnego miejsca trzy razy:
- wartością 0x00
- wartością 0xFF
- wartością losową
Rezultat polecenia ils na nadpisanym dysku nie różni się bardzo od poprzedniego rezultatu (choć można zauważyć różnice w kolumnach oznaczających daty, a także różnicę w kolumnie określającej rozmiar):
27|f|0|0|1201869267|1201869267|1201869267|40777|1|48|0|0
28|f|0|0|1201869311|1201869311|1201869311|100777|1|258990592|0|0
29|f|0|0|1201869311|1201869311|1201869311|100777|1|736|0|0
30|f|0|0|1201869311|1201869311|1201869311|100777|1|736|0|0
31|f|0|0|1201869311|1201869311|1201869311|100777|1|736|0|0
32|f|0|0|1201869311|1201869311|1201869311|100777|1|736|0|0
33|f|0|0|1201869311|1201869311|1201869311|100777|1|736|0|0
34|f|0|0|1201869311|1201869311|1201869311|100777|1|0|0|0
35|f|0|0|1201869267|1201869267|1201869267|100777|1|0|0|0
36|f|0|0|1201868555|1201868555|1201868555|100777|1|138|0|0
37|f|0|0|1201868555|1201868555|1201868555|100777|1|153|0|0
38|f|0|0|1201868555|1201868555|1201868555|100777|1|169|0|0
Odczytajmy jednak metadane dotyczące rekordu 27:
MFT Entry Header Values:
Entry: 27 Sequence: 5
$LogFile Sequence Number: 1757094
Not Allocated Directory
Links: 1
$STANDARD_INFORMATION Attribute Values:
Flags:
Owner ID: 0
Created: Fri Feb 01 13:34:27 2008
File Modified: Fri Feb 01 13:34:27 2008
MFT Modified: Fri Feb 01 13:34:27 2008
Accessed: Fri Feb 01 13:34:27 2008
$FILE_NAME Attribute Values:
Flags: Directory
Name: EFSTMPWP
Parent MFT Entry: 5 Sequence: 5
Allocated Size: 0 Actual Size: 0
Created: Fri Feb 01 13:34:27 2008
File Modified: Fri Feb 01 13:34:27 2008
MFT Modified: Fri Feb 01 13:34:27 2008
Accessed: Fri Feb 01 13:34:27 2008
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-2) Name: N/A Resident size: 82
Type: $INDEX_ROOT (144-1) Name: $I30 Resident size: 48
Jak widać polecenie cipher samo do swojej pracy zakłada katalog (a w nim tworzy pliki), do których pisze. Tak się więc złożyło, że wcześniejszy katalog został "ponownie wykorzystany" i w MFT znajdują się dane dotyczące katalogu stworzonego w trakcie czyszczenia. Wracając do rezultatów polecenia ils można zauważyć, że zmodyfikowane zostały rekordy od 27 do 35 włącznie. Dla pewności istat dla 35:
MFT Entry Header Values:
Entry: 35 Sequence: 4
$LogFile Sequence Number: 1594460
Not Allocated File
Links: 1
$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Created: Fri Feb 01 13:34:27 2008
File Modified: Fri Feb 01 13:34:27 2008
MFT Modified: Fri Feb 01 13:34:27 2008
Accessed: Fri Feb 01 13:34:27 2008
$FILE_NAME Attribute Values:
Flags: Archive
Name: 13.E
Parent MFT Entry: 27 Sequence: 3
Allocated Size: 0 Actual Size: 0
Created: Fri Feb 01 13:34:27 2008
File Modified: Fri Feb 01 13:34:27 2008
MFT Modified: Fri Feb 01 13:34:27 2008
Accessed: Fri Feb 01 13:34:27 2008
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-2) Name: N/A Resident size: 74
Type: $DATA (128-1) Name: $Data Resident size: 0
Jednak sprawdzany wcześniej rekord 38 pozostał niezmieniony:
MFT Entry Header Values:
Entry: 38 Sequence: 2
$LogFile Sequence Number: 1065344
Not Allocated File
Links: 1
$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Created: Fri Feb 01 13:22:35 2008
File Modified: Fri Feb 01 13:22:35 2008
MFT Modified: Fri Feb 01 13:22:35 2008
Accessed: Fri Feb 01 13:22:35 2008
$FILE_NAME Attribute Values:
Flags: Archive
Name: 10.txt
Parent MFT Entry: 27 Sequence: 1
Allocated Size: 0 Actual Size: 0
Created: Fri Feb 01 13:22:35 2008
File Modified: Fri Feb 01 13:22:35 2008
MFT Modified: Fri Feb 01 13:22:35 2008
Accessed: Fri Feb 01 13:22:35 2008
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-2) Name: N/A Resident size: 78
Type: $DATA (128-1) Name: $Data Resident size: 169
Nadal można odczytać metadane o pliku, w szczególności:
- Jego nazwę,
- Daty utworzenia, modyfikacji, dostępu,
Co więcej okazuje się, że zawartość części plików nadal można odczytać (w szczególności dla rekordu 38):
E:\test\1.txt
E:\test\10.txt
E:\test\2.txt
E:\test\3.txt
E:\test\4.txt
E:\test\5.txt
E:\test\6.txt
E:\test\7.txt
E:\test\8.txt
E:\test\9.txt
E:\test\test.txt
Dlaczego? Dlatego, że rozmiar pliku jest mały, całość danych mieści się w MFT, a rekord MFT nie jest nadpisywany podczas pisania do pliku. Ups... Co potrafi zrobić sdelete? Uruchamiam go na dysku wcześniej wyczyszczonym (jak się okazuje - nie do końca skutecznie) przy pomocy cipher. Rezultat? Najpierw ils:
27|f|0|0|1201870875|1201870875|1201870875|100555|1|258990592|0|0
28|f|0|0|1201871159|1201871159|1201871159|100555|1|728|0|0
29|f|0|0|1201871159|1201871159|1201871159|100555|1|720|0|0
30|f|0|0|1201871160|1201871160|1201871160|100555|1|720|0|0
31|f|0|0|1201871161|1201871161|1201871161|100555|1|720|0|0
32|f|0|0|1201871161|1201871161|1201871161|100555|1|720|0|0
33|f|0|0|1201871161|1201871161|1201871161|100555|1|720|0|0
34|f|0|0|1201871161|1201871161|1201871161|100555|1|720|0|0
35|f|0|0|1201871162|1201871162|1201871162|100555|1|720|0|0
36|f|0|0|1201871162|1201871162|1201871162|100555|1|720|0|0
37|f|0|0|1201871162|1201871162|1201871162|100555|1|720|0|0
38|f|0|0|1201871162|1201871162|1201871162|100555|1|720|0|0
39|f|0|0|1201871163|1201871163|1201871163|100555|1|720|0|0
40|f|0|0|1201871163|1201871163|1201871163|100555|1|720|0|0
41|f|0|0|1201871164|1201871164|1201871164|100555|1|720|0|0
42|f|0|0|1201871164|1201871164|1201871164|100555|1|720|0|0
43|f|0|0|1201871164|1201871164|1201871164|100555|1|720|0|0
44|f|0|0|1201871164|1201871164|1201871164|100555|1|720|0|0
45|f|0|0|1201871165|1201871165|1201871165|100555|1|720|0|0
46|f|0|0|1201871165|1201871165|1201871165|100555|1|720|0|0
47|f|0|0|1201871166|1201871166|1201871166|100555|1|720|0|0
Jak widać zmian jest sporo, przede wszystkim plików jest więcej. Wynika to z zasady działania sdelete opisanej na stronie narzędzia.
Co się kryje więc w nieszczęsnym rekordzie 38?
MFT Entry Header Values:
Entry: 38 Sequence: 3
$LogFile Sequence Number: 8562839
Not Allocated File
Links: 1
$STANDARD_INFORMATION Attribute Values:
Flags: Hidden, Archive
Owner ID: 0
Created: Fri Feb 01 14:06:02 2008
File Modified: Fri Feb 01 14:06:02 2008
MFT Modified: Fri Feb 01 14:06:02 2008
Accessed: Fri Feb 01 14:06:02 2008
$FILE_NAME Attribute Values:
Flags: Hidden, Archive
Name: SDELMFT000009
Parent MFT Entry: 5 Sequence: 5
Allocated Size: 0 Actual Size: 0
Created: Fri Feb 01 14:06:02 2008
File Modified: Fri Feb 01 14:06:02 2008
MFT Modified: Fri Feb 01 14:06:02 2008
Accessed: Fri Feb 01 14:06:02 2008
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-2) Name: N/A Resident size: 92
Type: $DATA (128-1) Name: $Data Resident size: 720
Jak widać założony został nowy plik, jego zawartość (720 bajtów) to losowe śmieci:
§B ŹůŕCKÚ!│ű↨▬ĺb‼đťŮ◄┬Gť┌čI♂poZŧŃ;|╔ň¸;ˇti╬┬»■{│/Ż├ľÜäöÝuö└Ľ:O«ĘźAPíe^T┴ŞŐč▓Â_¸
kŐ* S♀6ięĺNg}bŇC↑´Uĺ■ ↔ľ▼U0T;>☺ëý|É=šâÍŤ⌂Ŕc k▬FR╚C-ôbó═Â/┌ä▒∟Ş=Ë♀ ĽX▲J<;/+ŁKí0┴ü
Z2pĹ☼žÜ┐┬§÷˘ë═Ú◄ĺŇęâd&ó↑g↨↓►ž→☼xŇŽh│ĆtLZÓţ╬F♂ň╦ŕä駊@⌂Đ┌.ľ▲x♠:°ŮAć["hsź.ĺMS╬)hşý
☼"ź:Żĺ*ŹÉ§źE˙C[ž║ĺ♣%
~ń▀→╬ÁkżU☼Đc§¸┌Hź░őŰšđý┴║Ö♫)UůKúĆ#đ=ç"YOőź|â↓â4♣Ň╩.Š
űäg6ĺô♥G˛ ]×ű°xćŮ╗&Ë0[├Ă>┴"0í˝╚┌↕ÉX%⌂úOţ^Ü˝┤AŹäř¬┼╗§!~uYůŰĘôá{Ś'ř[LM■
RłB˝{ç§EYóŕöEÜ♫H
ÓŻ¨¸WŢJ3ZÝ♫Q☺8░$áNĐŇĹ┤224█ŇI3O_6♂1┴9╚š↨♀☼↕đsb└►¶áńRë╦♥R┤♫/*R 9╗Ë!#Njşď{`ĺ☼Kş║ŽÖ╔
ĆŰż└żhmů:đ█łů5#Ő+zŕ░Ć♀>ÎÚ═─(ÉQ‼ýuM[íLJM└Ą0↕Męa♥/ █6˘¸(→▲3ć♂l)F$[˝rUŰ↑▓ÁŽĽp↓▀■;ň
8Ři"gř☺Đ9(ě⌂Íľ¨→H┐J♥72md÷Őň──Łz┘K÷ŮŁmć
Sukces!
Cel został osiągnięty. Usunięte zostały nie tylko informacje zawarte w pliku, ale również metadane opisujące usunięte pliki. Co prawda wiadomo, że coś było, nie wiadomo jednak dokładnie co i kiedy...
Musisz mieć tu prawa administratora.