Zerowanie dysku poleceniem dd

0

Jeżeli wielkość bloku na danych systemie plików wynosi 4096, to jest sens ustawienia mniejszej probki?
Jeśli sektor ma 512 to co się stanie jak ustawię mniejszą próbkę i jak to się ma do urządzeń z pamięcią flash?

2

Wartość 4096 jest optymalna dla dysków z dużą ilością małych plików. Generalnie próbkowanie ma za zadanie optymalizację pojemności pod kątem przyszłego przechowywania danych. Im pliki większe, tym wartość wyższa - jednak 4 KB wydają się idealnym kompromisem.

0

No tak, 10 000 plików po 1KB, będzie zajmowało(na urządzeniu) 10 000 * rozmiar bloku, gdy wielkość pliku < rozmiar bloku.

Więc zerowanie z próbką X, zmienia wielkość bloku na danych systemie plików na X? Przecież jak wyzerujesz dysk to nie ma systemu plików, a blok nie jest fizyczny, tylko system plików sobie go tworzy xD

Myślałem że wielkość próbki = ile mam wziąć danych na raz.
Np jeżeli wielkość bloku wynosi 4096, to on nadpiszę od razu równo cały blok i mniejsze wartości nie mają sensu, a większa nie może być wartość niż prędkość zapisu, bo bufor się zapełni? xD

Jakoś nie mogę pojąć czemu wielkość próbki przy zerowaniu definiuje rozmiar bloku.

I dlaczego niektórzy twierdzą, że jeden przebieg zerowania to za mało?
Jak normalnie z systemu usuwasz plik, to te dane tam są, tylko po prostu te bloki są oznaczone jako do napisania tak?
Jak wszystkie wypełnisz zerami to jakim cudem może to nie wystarczyć?

Ciężka ta informatyka xD

0

I dlaczego niektórzy twierdzą, że jeden przebieg zerowania to za mało?

Nie za mało. Ale po jednokrotnym zerowaniu teoretycznie jest możliwość odzyskania danych - przy pomocy profesjonalnego sprzętu.
Jeśli na dysku były dane tajne-przez-kompromitujące i chcesz go sprzedać, w ramach paranoi możesz go wymazać kilka razy - ale nie zerami, tylko raczej losowymi wartościami.

0

Dzięki, właśnie się zastanawiałem dlaczego się robi szum, skoro zerowanie jest szybsze i i tak usuwa dane.
Te odzyskiwanie profesjonalnym sprzętem to też się tyczy też pamięci flash?

Jeśli chodzi o tę próbkę, to NIE MA znaczenia, ważne tylko żeby nie była większa niż prędkość zapisu urządzenia, bo wtedy będzie wolniej, a najlepiej jak będzie najbliższą prędkości zapisu?

Jeśli chodzi ogólnie o urządzenie blokowe, to przeważnie wszystkie mają sektor/blok fizyczny o rozmiarze 512? Flash też?

0

akurat odzyskiwanie w przypadku flash jest bardziej skomplikowane z racji różnych pamięci, kontrolerów, firmware, i innych, na pewno przeszkadza w tym nawet najprostsze szyfrowanie jakimś zwykłym aes128

0

Z tego co patrzę, to programy do odzyskiwania danych, odzyskują dane z hdd, pendrivów itp.
Więc jest różnica tylko w odzyskiwaniu danych, które fizycznie kiedyś były na nośniku, tak?

Ciekawi mnie, czy jak posiadasz system plików, który nie ma księgowania(lub je wyłączysz jeśli jest taka możliwość), to czy wtedy odzyskiwanie danych, których fizycznie NIE MA, jest możliwe? Albo czy w ogóle jest możliwość odczytanie ich?

1
Zimny Pomidor napisał(a):

Ciekawi mnie, czy jak posiadasz system plików, który nie ma księgowania(lub je wyłączysz jeśli jest taka możliwość), to czy wtedy odzyskiwanie danych, których fizycznie NIE MA, jest możliwe? Albo czy w ogóle jest możliwość odczytanie ich?

Napisałem: przy pomocy profesjonalnego sprzętu. Nie tymi programami, które nic nie odzyskają już po jednokrotnym wyzerowaniu.

HDD jest nośnikiem magnetycznym: obrotowy dysk (dlatego się nazywa „dysk”), którego różne obszary są w różnym stopniu namagnesowane.
Upraszczając, wyobraź sobie że bit 0 to namagnesowanie «tak», a bit 1 to namagnesowanie «siak». Ale gdy przyjrzeć się analogowemu odczytowi z głowicy magnetycznej, okaże się że zero zeru nierówne, i może nieść ślad poprzedniego stanu: jeśli wyzerowano zero to mamy taki poziom sygnału, a jeśli wyzerowano jedynkę to podobny - wciąż liczący się jako „zero” - ale dający się odróżnić od zera które zerem było.

Firmy zajmujące się odzyskiwaniem danych potrafią takiej operacji odczytu poprzedniej zawartości dokonać za odpowiednio grube pieniądze.
Kilkakrotne zamazanie dysku losowymi danymi (za każdym razem innymi) ma za zadanie wprowadzić jak największy szum, by to uniemożliwić albo przynajmniej utrudnić.

0

Dzięki za dokładne wytłumaczenie.
Wyżej pytałem o pamięci flash, bo kolega napisał że zależy od firmwaru itp, a te programy odzyskują dane z pamięci flash.

A jak jest z demagnetyzacją, ona jest w 100% skuteczna?

Przekwalifikowuje się xD

0

Mam problem z ułożeniem sobie tego wszystkiego.

Pomijając już odzyskiwaniu danych, które normalnie fizycznie są na dysku, to czy system plików ma coś do tego i jak to działa w ogóle?

Plik składa się z 0 i 1 tak? Ok. Przy pomocy profesjonalnego sprzętu, z dysku magnetycznego, można odczytać te zera i jedynki.
I co?
Odzyskujesz w ten sposób tablice partycji i systemy plików? Bo inaczej nie wiesz jaki to jest plik. Poza tym, pliki są porozrzucane i musisz wiedzieć od pozycji do pozycji jakiej masz czytać te jedynki i wiedzieć co one tworzą.

No więc czytasz sobie zera i jedynki od 446 do 512, masz tablice partycji, a potem to z górki? xD

0

Poza tym, powiedziałeś, że może nieść ślady poprzedniego stanu, no ale jak to zaszumujesz w kilku cyklach, to wtedy co? Masz listy stan poprzedni, stan jeszcze bardziej poprzedni i sobie czytasz całą historię dysku od dekady wcześniej? xD

0

Nie mogę tego ogarnąć, że po kilku cyklach zapełnienia dysku losowymi danymi, prawdopodobne jest, że te dane można jeszcze odzyskać.

Po mojemu, np jeżeli mam dysk twardy z dwoma partycjami o systemie plików NTFS, to wystarczy przejechać kilka razy po MBR, i tam gdzie były partycje, po File Allocation Table i powinno być po wszystkim.

Dlatego ciągle drążę, chciałbym to zrozumieć.

0

No z GPT to akurat lipa, bo masz porozrzucane po całym dysku.

Ale spam xD
Obiad robię i tak co chwile mi się coś przypomina.

0

dysk twardy z dwoma partycjami

dwiema

to wystarczy przejechać kilka razy po MBR, i tam gdzie były partycje, po File Allocation Table i powinno być po wszystkim.

Przecież wtedy dane pozostają na dysku nienaruszone. Zamazana jest tylko informacja gdzie one są - ale przy odrobinie trudu przecież można je znaleźć, zwłaszcza jeśli wiadomo co chce się znaleźć.

i “File Allocation Table” to raczej w FAT, stąd nazwa.

0

No właśnie tego nie mogę pojąć xD

Ja sobie to wyobrażam tak:

Co ja czytam? - dajmy na to mam mapę, w której mam sygnatury binarne pliku, i możliwe, że to nie jest przypadek, i faktycznie wiem co ja czytam xD

No już wiem, ale dokąd mam czytać? - może i można jakoś odczytać wielkość pliku, może taka struktura formatu pliku, może jakiś charakterystyczny koniec, nie wiem xD

Skończyłem czytać blok, a plik nadal nie kompletny. - i tutaj ch*j, czytając następny blok nie wiem co ja czytam xD

Jeżeli zniszczysz logiczną budowę dysku, to nie mogę pojąć jakim cudem jest to możliwe.
No już nawet zostawmy tą strukturę systemów plików, przecież chyba danych w bloku nie można mieszać, więc załóżmy że zostawimy tylko grupę bloków z czystymi danymi, a tablicy partycji nie da się odzyskać bo przejechaliśmy po niej 37razy(Gdzieś czytałem, że ktoś czytał xD, że nasa jeździ 37 razy po dysku i wtedy już jest nie do odczytania, chociaż wiadomo, że to są losowe wartości, więc nie da się tak obliczyć xD, więc pewnie dodali profilaktyczne 'ileś', chociaż w to nie wierzę).

1

Po pierwsze w tablicy partycji nie ma nic magicznego. Tablica partycji mówi tylko gdzie się zaczyna i kończy dana partycja oraz jakiego jest rodzaju (co ma znaczenie beardziej tylko porządkujące i nie jest istotne przy interpretacji danych). Większość systemów ma jedną, góra dwie partycje, więc odtworzenie tablicy partycji na podstawie innych danych jakie były zawarte w systemie plików oraz wiedzy o tym, jaki system operacyjny był użyty do utworzenia tablicy partycji i sformatowania dysku nie jest trudne.

A MBR to już w ogóle nie ma znaczenia dla danych na dysku. Zamażesz MBR to co najwyżej nie wystartuje system. Naprawienie MBRa to kwestia wybrania odpowiedniej opcji w instalatorze odpalonym z płytki ratunkowej systemu.

Nawet jeżeli uszkodzisz metadane samego systemu plików, to nadal będzie można odzyskać wiele ciekawych danych. Pliki są przechowywane w blokach, a bloki mają okrągłe adresy początków, więc łatwo znaleźć, które dane należą do jednego bloku. Wiele rodzajów plików ma też charakterystyczne sygnatury na początku lub na końcu, które będzie można szybko znaleźć. Jeśli dysk nie był mocno zapełniony, to bloki jednego pliku są na ogół alokowane obok siebie dla zwiększenia wydajności, więc łatwo będzie odzyskać taki plik.

Poza tym wcale nie trzeba odzyskiwać całego pliku, aby było to dla kogoś użyteczne. To, że nie uda się odzyskać logo na wyciągu bankowym, nie oznacza, że nie da się odzyskać danych przelewu... ;)

A, i jeszcze taka ciekawostka - ważne metadane wielu systemów plików występują w kilku kopiach i nie znajdują się w początkowej części obrazu dysku.

0

A MBR to już w ogóle nie ma znaczenia dla danych na dysku. Zamażesz MBR to co najwyżej nie wystartuje system. Naprawienie MBRa to kwestia wybrania odpowiedniej opcji w instalatorze odpalonym z płytki ratunkowej systemu.

MBR zawiera tablice partycji i bootloader(chociaż nie wiem czy musi xD bo jak żadna partycja nie jest boot to po co).

A, i jeszcze taka ciekawostka - ważne metadane wielu systemów plików występują w kilku kopiach i nie znajdują się w początkowej części obrazu dysku.

No program by musiał wiedzieć co ma wymazywać, musi zależnie od systemu plików, nadpisywać odpowiednie bloki.

Poza tym wcale nie trzeba odzyskiwać całego pliku, aby było to dla kogoś użyteczne. To, że nie uda się odzyskać logo na wyciągu bankowym, nie oznacza, że nie da się odzyskać danych przelewu... ;)

Może i takie drobne tak. A już w ogóle w SSD dane mają się tak rozkładać, żeby równo dysk był wykorzystywany, dłużej żył.

No przekonaliście mnie, ale według mnie przynajmniej ten paranoiczny kowalski nie musi zerować całego dysku, chyba że chce porządek xD
Jechać po całym dysku, a po fragmentach, to jednak dużo różnica czasu, a i tak uważam że będzie po wszystkim.

Dzięki za udział xD

I dzięki za ten link, ale nie znam angielskiego xD

1 użytkowników online, w tym zalogowanych: 0, gości: 1