Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Mam kopie binarną zaszyfrowanego dysku w którym straciło się kilka miliardów bajtów na początku (tablica partycji, naglowek luks oraz pierwsze bloki szyfrogramu zawierajace system plikow i poczatek danych). Mam też klucz zrzucony z pamięci, ponieważ dysk był odblokowany w czasie nadpisania.
chce przemapować ten zaszyfrowany obszar a następnie odzyskiwać dane ktore nie zostaly nadpisane za pomocą narzędzi do odzyskiwania usuniętych plików z niezaalokowanej przestrzeni (photorec i foremost) lub wycinać manualnie za pomocą hexedytora
Czy to jest technicznie możliwe ?
Oto moj klucz, tryb operacyjny i rodzaj szyfru zrzucony dmsetup'em:
0 195303985 crypt aes-xts-plain64 3e467673728dea29e13b6b8ff67973669463dea597492fafe3d6d0a05464e370d9295923a0f4c8c24f0bd4b91472ff22a4f0b3c307b71353ea63dc789580ebdf 0 8:33 65535
Czy może mi ktoś na początek powiedzieć co tutaj oznacza pierwsza i druga liczba oraz trzy ostatnie ?
Offline
[quote=morfik]Przeczytaj sobie pierw manual dmsetup[/quote]
A możesz mi przy okazji powiedzieć co to dokładnie te "backup superblocks" w EXT4 ?
https://www.cyberciti.biz/faq/linux-find-alternative-superblocks/
Czy to daje potencjalnie szanse na odzyskanie struktury katalogów i nazw plików w sytuacji gdy zostały stracone dane z początku partycji ?
Offline
Tak to dokładnie wygląda, cały obraz dysku ma 0x174a500000 bajtów i stracone są bajty od 0x0 do 0xb3bfffff:
[img]https://cdn3.imggmi.com/uploads/2018/8/3/213b13a995006dd1016c796377bcbb2f-full.png[/img]
Czy można coś na to poradzić ?
Ostatnio edytowany przez 091619EE (2018-08-03 11:42:53)
Offline
można, wyzerować do końca albo nadpisać losowymi będzie ładniej w przekroju :)
Offline
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.
Offline
czyli jednym słowem będziesz łapał losowy zapis pliczku na wyciągu, powodzenia. Gdyby struktura nie była piznięta zerami a tylko przykładowo tablica partycji to inna bajka z tym to możesz się pozdrowić bo nic z tego nie wyjdzie
Offline
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.
[img]https://opensource.com/sites/default/files/images/life-uploads/cylindergroup-01_1.png[/img]
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)
Offline
można bez problemu szereg plików odzyskać[/quote]
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 :)Ostatnio edytowany przez hi (2018-08-03 20:51:23)
"Jeśli wolność słowa w ogóle coś oznacza, to oznacza prawo do mówienia ludziom tego, czego nie chcą słyszeć."
Eric Arthur Blair
Offline
[url=https://www.youtube.com/watch?v=4iKLtfoP-wk]Każdy plik, który nie jest pofragmentowany i znane są wzory nagłówka i stopki[/url]
Offline
tak się składa, że jakieś mam i sam sobie odpowiedziałeś na pytanie o odzysk, które zwaldkowałem :)
ale ok może spytamy samego zainteresowanego czy coś zdziałał zamiast się wykłócać?
Ostatnio edytowany przez hi (2018-08-03 21:38:24)
Offline
tak a dlaczego?
Offline
no ok zobaczymy co udało się odzyskać zainteresowanemu na moje nic z tego nie wydobędzie ale ok
Offline
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 :)[/quote]
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[/quote]
Jak tylko ogarnę jak przemapować to na surowy obszar odszyfrowany to odzyskam co najmniej luźne pliki.Offline
[b]morfik[/b] Jak najlepiej w takim wypadku jak u mnie odtworzyć tablice partycji ?
[b]Czy komenda fdisk działa całkowicie deterministycznie ?[/b]
Robię tak:
podłączam loop device do pliku tego obrazu:
sudo losetup -P -f --show dimage.img
w lsblk est widoczny teraz jako [b]loop0[/b] ale jak można się spodziewać nie jest rozpoznawana tam żadna partycja.
Można jakoś przemapować te dane bez tworzenia tablicy partycji czy po prostu utworzyć ją fdisk'iem ?
Offline
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
Offline
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 [b]fdisk[/b] 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: [b]2048[/b]
nastepnie konwertuje klucz do postaci binarnej:
echo "3e467673728dea29e13b6b8ff67973669463dea597492fafe3d6d0a05464e370d9295923a0f4c8c24f0bd4b91472ff22a4f0b3c307b71353ea63dc789580ebdf" | xxd -r -p >~/masterkeyfile
Nastepnie tworze na tej utworzonej partycji zaczynajacej sie na [b]2048[/b] 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ę ?
Offline
Nie,
[b]kolejne eksperymenty potwierdzają, że wyżej opisany problem najprawdopodobniej nie wynika z błędnej pozycji pierwszego sektora tylko jak zwykle cryptsetup źle działa lub dokumentacja jest do kitu[/b]
jeżeli mamy przemapowany dysk i wyeksportujemy klucz z pamięci:
dmsetup table --showkeys /dev/mapper/encrypted | awk '{ print $5 }' | xxd -r -p > /tmp/master_key
to zgodnie z dokumentacją nadpisanie nagłówka na tej partycji w ten sposób:
cryptsetup luksFormat -v -y -c aes-xts-plain64 --master-key-file=/tmp/mkey /dev/sdd1
powinno prowadzić do takiej samej postaci przemapowanych danych czy o czymś nie wiem ?
U mnie tak nie jest,
jak zrobię luksFormat to te bajty po przemapowaniu są już inne pomimo że formatuje z opcją --master-key-file żeby używało tego poprzedniego klucza.
Offline
co to jest [b]plain64[/b] w nazwie trybu operacyjnego ?
gdziesz piszą, że jest to metoda wyprowadzenia wektora inicjującego, ale w XTS wektor inicjujący nie jest wymagany, bo postać bloku szyfrogramu niie zależy od wartości poprzednich bloków a jedynie od pozycji szyfrowanego bloku i odpowiadającego bloku danych jawnych
Offline
Time (s) | Query |
---|---|
0.00012 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00096 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.129.249.170' WHERE u.id=1 |
0.00072 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.129.249.170', 1732413979) |
0.00046 | SELECT * FROM punbb_online WHERE logged<1732413679 |
0.00086 | DELETE FROM punbb_online WHERE ident='18.224.73.124' |
0.00077 | DELETE FROM punbb_online WHERE ident='54.36.148.177' |
0.00073 | SELECT topic_id FROM punbb_posts WHERE id=320426 |
0.00149 | SELECT id FROM punbb_posts WHERE topic_id=30566 ORDER BY posted |
0.00064 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=30566 AND t.moved_to IS NULL |
0.00006 | SELECT search_for, replace_with FROM punbb_censoring |
0.00103 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=30566 ORDER BY p.id LIMIT 0,25 |
0.00078 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=30566 |
Total query time: 0.00866 s |