Forum Debian Users Gang

Przeczytaj sobie pierw manual dmsetup

Tak to dokładnie wygląda, cały obraz dysku ma 0x174a500000 bajtów i stracone są bajty od 0x0 do 0xb3bfffff:



Czy można coś na to poradzić ?

Ostatnio edytowany przez 091619EE (2018-08-03 11:42:53)

Masz kopię dysku, która ma wyczyszczony początek obszaru ~3GiB? I chcesz użyć jednego sektora (superbloku) do naprawy wszystkich danych na tym dysku, by je odzyskać? A co z pozostałą strukturą danych na dysku, tj. wszelkimi metadanymi opisującymi np. które bloki są przypisane pod jakie i-node?  Nie, superblok ci sam nic nie pomoże jak masz rozwaloną strukturę dysku albo losowo nadpisane bloki z pominięciem systemu plików -- te dane są stracone. Resztę można by pewnie odzyskać używając w fsck alternatywnego superbloku, który jest przechowywany w różnych miejscach dalej na dysku.

Z tego co ja rozumiem, to ext4 nie ma wszystkich metadanych ulokowanych na początku dysku. W zasadzie to są tego typu kawałki jak na tym obrazku.



I każda taka grupa zawiera 128MiB (metadane + dane). Jak teraz sobie nadpiszesz zerami pierwsze 3GiB, to uszkodzisz tylko 24 grupy bloków, a nie wszystkie. I tylko dane w tych blokach szlag trafi, no chyba, że plik jest pofragmentowany i jego części znajdują się też w innych grupach, to też ten plik będzie do wywalenia. xD

Ostatnio edytowany przez morfik (2018-08-03 21:01:42)

Każdy plik, który nie jest pofragmentowany i znane są wzory nagłówka i stopki (nie pamiętam czy stopka jest wymagana) można odzyskać z pominięciem systemu plików.

Widzę, że kompletnie nie masz pojęcia czym jest system plików. xD

Nie masz.

Nie wiem, wróżką nie jestem. xD

jakich? chyba jpegów i txt w dodatku częściowo uszkodzonych o skompresowanych plikach (zip,7z,rar,tar.gz,iso itp.) czy av (mp3,mp4,mkv,avi itp) nawet nie wspominam i to jeszcze z luźną strukturą, powodzenia w sklejaniu to tak jakbyś wypierdolił papier w niszczarce a jakiś pies by to próbował posklejać frendzel po frendzlu z całej torby frendzlów no origami z tego nie złoży :)

Próbowałeś kiedyś ? W moich testach dla niezaszyfrowanego dysku, PhotoRec i ForeMost bardzo ładnie odzyskują dane z kompletnie zniszonego systemu plików (początek dysku wyzerowany przez dd). Pobaw się to sobie sam zobaczysz i się zdziwisz. Trochę ciężej będzie z egzotycznymi typami plików, bo dla nich nie zawsze są gotowe narzędzia, ale "nie da się" to trochę za dużo powiedziane.

no ok zobaczymy co udało się odzyskać zainteresowanemu na moje nic z tego nie wydobędzie ale ok

Jak tylko ogarnę jak przemapować to na surowy obszar odszyfrowany to odzyskam co najmniej luźne pliki.

na wiki cryptsetupa piszą, że można odtworzyć nagłówek luksa z surowej postaci klucza wywołując luksformat z oryginalnymi paramerami i opcją --master-key-file przyjmującą postać binarną klucza:

cryptsetup luksFormat --master-key-file=<master-key-file> <luks device>

https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions (rodział 6.10)

Ale <luks device> odnosi sie do partycji i nie moge tego wywolac jezeli tablica partycji tez jest nadpisana

Układ partycji był najprostrzy jaki jest mozliwy czyli jedna partycja primary wypelaniajaca dostepną przestrzen. Oczywiscie nie pamietam jaka byla dokladnie pozycja pierwszego sektora itd ale pamietam ze byla wybrana ta domyslna. Dlatego pytam czy fdisk dziala calkowicie deterministycznie, nawet na roznych werjsach systemu ?, na jakiej podstawie wybierana jest pozycja pierwszego sektora ?


I tak dzialam na kopii, wiec po prostu probuje tak:

sudo fdisk /dev/loop0

wybieram proponowaną domyślnie pozycje pierwszego sektora: 2048

nastepnie konwertuje klucz do postaci binarnej:

echo "3e467673728dea29e13b6b8ff67973669463dea597492fafe3d6d0a05464e370d9295923a0f4c8c24f0bd4b91472ff22a4f0b3c307b71353ea63dc789580ebdf" | xxd -r -p >~/masterkeyfile

Nastepnie tworze na tej utworzonej partycji zaczynajacej sie na 2048 sektorze naglowek luksa z powyzszym kluczem:

sudo cryptsetup -v -y -c aes-xts-plain64 -s 512 -h sha512 -i 5000 --master-key-file=~/masterkeyfile luksFormat /dev/loop0p1

otwieram:

sudo cryptsetup luksOpen /dev/loop0p1 vol001

następnie próbuje wyszukiwać w przemapowanych bajtach spodziewane fragmenty plików tekstowych, ktore byly na tym dysku zapisane:

sudo strings /dev/mapper/vol001 | grep "krotkie_czesto_wysepujace_spodziewane_slowo"

bezskutecznie

Czy ja coś źle robię ?

Nie możesz zrobić czegoś na wzór w tym artykule?
https://morfikov.github.io/post/jak-odszyfrowac-zaw … -z-androidem/