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↨↓►ž→☼[email protected]:°Ů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...
Ostatnio pisałem o usuwaniu plików. Wyszło na to, że sdelete jest lepszy niż cipher. Ale jak się okazuje, nawet sdelete może zostawić na dysku sporo ciekawych danych...Jak sdelete czyści MFT Koncepcja działania jest prosta: załóż tyle pli
Przesłany: Lut 06, 21:57
Ostatnio na newsach (to takie coś, co było przed forami) pojawiło się pytanie czym wyczyścić dysk przed sprzedażą. Jedną z odpowiedzi było narzędzie cipher. Jak już miałem okazję się przekonać, nie działa ono zbyt skutecznie: O usuwaniu plików (na NTFS
Przesłany: Cze 06, 23:06