|
home page priv msg forum sieci newbie obrona windows linux i inne systemy hardware software delphi, pascal, vb c, c++, assembler inne języki php, sql, js, xml forum projektów matura z informatyki hydepark bazar strona śmietnik artykuły newbie/faq sieci obrona windows linux i inne systemy programowanie webmasters irc/komunikatory hardware felietony inne download archiwum newsów strona rejestracja kanał IRC kanały rss faq/dokumentacja squad |
|
| użytkownicy | |
| 0 użytkowników online ostatni zarejestrowany: ginekolog | |
:. Spis Forum -> Software -> Inny sposób na trwałe kasowanie plików?
Temat: Inny sposób na trwałe kasowanie plików? (czytań tematu: 1447) | |
| Autor | Data: 2009-02-28 22:42; Post #1 |
radmen   moderator [offline] [dołączył] | Hej, Od pewnego czasu zastanawia mnie jedno pytanie. Wiadomym jest, że najlepszym sposobem na skasowanie pliku jest wielokrotnie zamazanie sektorów w których się znajdował. Po kilku takich nadpisaniach nie można go odzyskać. Ja natomiast wymyśliłem sobie inny sposób - wielokrotnie nadpisanie zawartości pliku, a nie jego sektorów na dysku. Pytanie teraz, dlaczego ta metoda jest gorsza? Czyżby tutaj chodziło o to, że system plików w jakiś sposób pozwala na przywrócenie poprzedniej zawartości, tudzież jej odzyskanie ? Mówię gorsza, bo domyślam się, że ma istotne wady dla których nie stosuje się tego sposobu. Jestem po prostu ciekaw dlaczego  Pozdrawiam, [ EDIT: 1 raz, 2009-02-28 22:43:50 ] Parade, laugh, rejoice, sing We are the victors of nothing |
| [profil] [pm] [email] [gg] | |
| Autor | Data: 2009-03-01 00:37; Post #2 |
jqNfY3CbENtn6UoC   [offline] [dołączyła] | Prawdopodobnie winny jest mechanizm księgowania. Zmiany nie są wprowadzane bezpośrednio w pliku właściwym tylko tworzony jest plik tymczasowy opisujący zmiany. Nowy fragment pliku jest zapisywany na dysk w wolnym miejscu, następnie system zmienia MFT by wskazywała na nowy fragment, stary fizycznie zostaje na dysku jako miejsce nie przydzielone. Chodzi o to, by w przypadku awarii np. zasilania w trakcie zapisu do pliku właściwego przez system nie zostały utracone dane. Pamiętaj też, że mówimy o systemach wielozadaniowych więc w danym momencie kilka procesów może korzystać z dysku a to w połączeniu z księgowaniem daje nam dodatkowy podział pliku na fragmenty. Po scaleniu w MFT fragmenty pliku po nadpisaniu mogą znajdować się fizycznie w innym miejscu niż przed operacją. Podsumowując.. używając do operacji dyskowych systemowego API nie masz gwarancji, że plik zostanie zastąpiony sektor po sektorze a nie po prostu przepisany w inne miejsce na dysku. BTW. Wielokrotne nadpisywanie pliku to chwyt marketingowy. Nawet OnTrack nie odzyskuje plików fizycznie nadpisanych choćby jeden raz bo możliwość odzyskania takiego pliku jest tylko czysto teoretyczna i nie może zostać zautomatyzowana. PS. Nie napisałeś o jaki system plików chodzi więc zakładam, że NTFS  Chociaż ext3 i ReiserFS też korzystają z księgowania.. |
| [profil] [pm] | |
| Autor | Data: 2009-03-01 08:50; Post #3 |
| radmen moderator [offline] [dołączył] | Hash frau: dziękuję za wyczerpującą odpowiedź Odnośnie systemu plików to jest tak naprawdę mało znaczące, bo miałem ogólnie na myśli te z księgowaniem. Cytat: BTW. Wielokrotne nadpisywanie pliku to chwyt marketingowy. Nawet OnTrack nie odzyskuje plików fizycznie nadpisanych choćby jeden raz bo możliwość odzyskania takiego pliku jest tylko czysto teoretyczna i nie może zostać zautomatyzowana. Czyli mam rozumieć, że teoria teorią, a w praktyce są problemy z odzyskaniem takich plików? Parade, laugh, rejoice, sing We are the victors of nothing |
| [profil] [pm] [email] [gg] | |
| Autor | Data: 2009-03-01 16:53; Post #5 |
| leniwa j (gość) | Cytat: Czyli mam rozumieć, że teoria teorią, a w praktyce są problemy z odzyskaniem takich plików? |
| Autor | Data: 2009-03-01 19:00; Post #6 |
| radmen moderator [offline] [dołączył] | Dzięki W takim razie, dlaczego nie stosuje się takich metod ? Wydają się być pewniejszy niż zamazywanie sektorów (jest cała masa sposobów na znalezienie tych plików). Czyżby to był, jak wspomniałaś, "chłyt makertingowy"? Parade, laugh, rejoice, sing We are the victors of nothing |
| [profil] [pm] [email] [gg] | |
| Autor | Data: 2009-03-01 21:46; Post #11 |
Beowulf  moderator [offline] [dołączył] | Jak masz pliki ciągłe, bez wyraźnego nagłówka, binarne i stracisz tablicę plików (info systemu plików), to potem dzielenie iluś GB na pojedyncze pliki, bez nazw, bez dodatkowych informacji, będzie bardzo uciążliwe (niewykonalne?), przy czym, do odzyskania pełnej sprawności, będą potrzebne ich nazwy, których nie masz, więc pliki się nie załadują. To tak optymistycznie, na temat skasowania informacji o plikach, teraz gorzej, bo nie dość, że pliki nie istnieją, oraz miejsce istnienia pliku jest nieznane, to na nich, widnieją inne pliki, z czego część obszaru może być nadpisana inną ilość razy niż reszta fragmentów. Tak jak napisała jqNfY3CbENtn6UoC nie masz historii zmian. Nie masz informacji początkowej. tak jak teoretycznie możesz sprawdzić jakie jest namagnesowanie i ile różni się od tego wzorcowego, teoretycznie nawet do 7 razy, jeśli jednak na dysku pojawiły się jakiekolwiek zmiany, nawet jednokrotne użyciu każdego bitu, losową informacją, to obraz już jest zaciemniony. A co do nadpisywania, czy może funkcja abswrite z C pomoże ? Ελευθερία ή θάνατος |
| [profil] [pm] | |
| Autor | Data: 2009-03-01 21:52; Post #12 |
| radmen moderator [offline] [dołączył] | Beowulf: nie miałem na myśli zamazywania partycji, ani jej usuwania. Chodzi jedynie o kilkukrotne nadpisanie pliku. Nie chcę też nadpisywać partycji, chcę nadpisywać pojedynczy plik (nawet kilkukrotnie), a dopiero po tym go kasować. Parade, laugh, rejoice, sing We are the victors of nothing |
| [profil] [pm] [email] [gg] | |
| Autor | Data: 2009-03-01 22:29; Post #13 |
| jqNfY3CbENtn6UoC [offline] [dołączyła] | Możliwe, że się nie zrozumieliśmy. Zamazywanie sektorów zajętych przez plik jest stosowane (skuteczne) i wystarczy jednokrotne. Chwyt marketingowy polega na tym, że producenci takich programów reklamują się, że ten program zamazuje dane 3 razy a tamten 5 czy 14. Raz wystarczy. Natomiast próba nadpisania pliku z poziomu systemu operacyjnego przez API (wczytanie pliku, zmiana pliku na np. same zera i zapis pliku na dysk) jest nieskuteczna, bo stara wersja pliku może pozostać na dysku (dzięki księgowaniu) jako miejsce nieprzydzielone i być łatwo odczytana. W oproszczeniu: Przyjmijmy, że masz plik tekstowy, który zajmuje jeden klaster 16KB i chcesz go nadpisać. Otwierasz plik do zapisu, nadpisujesz plik np. samymi zerami i zamykasz plik. Otwierasz plik ponownie i widzisz same zera. Co robi system operacyjny: Gdy otwierasz plik do zapisu i nadpisujesz dane system szuka w MFT wolnego klastra i wszystkie dane zapisuje w nim. Następnie przy zamykaniu pliku zmienia w MFT adres starego klastra na ten nowy. Z poziomu systemu widzisz, że plik jest nadpisany ale tak naprawdę jest już w innym miejscu. Stary klaster widnieje teraz w MFT jako miejsce niezajęte i może zostać nadpisany ale puki co dane pliku nadal w nim są. Dlatego nadpisywanie pliku z poziomu OSa jest mało skuteczne. Prościej nie umiem |
| [profil] [pm] | |
| Autor | Data: 2009-03-01 22:32; Post #14 |
| radmen moderator [offline] [dołączył] | He, no o to mi właśnie chodziło  Trudno, przynajmniej przypomniałem sobie przy okazji Pythona (a propo tego tematu napisałem se skrypta) Parade, laugh, rejoice, sing We are the victors of nothing |
| [profil] [pm] [email] [gg] | |
| Autor | Data: 2009-03-01 22:42; Post #15 |
illusion  moderator [offline] [dołączył] | Cóż, nadpisywanie na poziomie sektorów zajmowanych przez plik też nie jest do końca bezpieczne. System nie jest informowany o otwarciu pliku do zapisu, więc pozwoli na otwarcie go do odczytu w innych aplikacjach i zbuferowaniu jego zawartości w pamięci, a więc dosyć często także w swapie. Warto wspomnieć też o metadanych zapisywanych w bazach programów użytkowych (niektóre narzędzia wyszukujące potrafią "zaindeksować" całą zawartość plików tekstowych). Co prawda, nie należy popadać w panikę, jednak warto być świadomym możliwych przecieków starannie wykasowanych danych. Bądź niczym rzeka, stopniowo drąż koryto, swojego losu. Tea lover. |
| [profil] [pm] [www] | |
| Posty usunięte z tego tematu |
| Post #4, napisany przez Eli_Wunderwave został usunięty przez autora postu, 2009-03-01 16:15 |
| Post #7, napisany przez (gość) został usunięty przez vitaR, 2009-03-01 19:59 |
| Post #8, napisany przez (gość) został usunięty przez vitaR, 2009-03-01 20:05 |
| Post #9, napisany przez (gość) został usunięty przez vitaR, 2009-03-01 20:08 |
| Post #10, napisany przez (gość) został usunięty przez vitaR, 2009-03-01 20:09 |
engine & gfx by konrad_vme
GZIP enabled