Fórum Root.cz
Hlavní témata => Software => Téma založeno: lklu 24. 04. 2018, 22:16:43
-
Zdravím, mám takový velmi nepříjemný problém.
Nemohu rozšifrovat disk na kterém je LUKS a pak btrfs.
V Ubuntu jej normálně vidím, ale chce po mě heslo a to neprojde. Ve správci disků se tváří divně, má prý mbr, ale jsem si jist, že měl guid. Výpis je pak takový:
sudo cryptsetup luksDump /dev/sda
Pozice 4 klíče LUKS není platná.
Pozice 5 klíče LUKS není platná.
Je ještě nějaká možnost jej připojit, nebo je vše ztraceno?
Díky moc za radu.
-
zalohu LUKS header mas? asi ne?
ve spravci disku myslis co? posli fdisk -l
-
Zálohu hlavičky nemám :(
Jedná se o ten 8TB disk.
Výpis je:
Disk /dev/sda: 489,1 GiB, 525112713216 bytes, 1025610768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6e950bba
Zařízení Zaveditelný Start Konec Sektory Size Id Druh
/dev/sda1 * 2048 713120611 713118564 340G 7 HPFS/NTFS/exFAT
/dev/sda2 713121790 1025609727 312487938 149G 5 Rozšířený
/dev/sda5 713121792 1009047551 295925760 141,1G 83 Linux
/dev/sda6 1009049600 1025609727 16560128 7,9G 82 Linux swap/Sola
Disk /dev/sdb: 7,3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x0df61b13
Disk /dev/mapper/cryptswap1: 7,9 GiB, 8478261248 bytes, 16559104 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
-
mas na mysli sdb? tam nejsou zadny partice, to tak ma byt? tam jsi mel GPT?
zkus sudo gdisk -l /dev/sdb
-
No, jestli tam buylo, ci je stale GPT, tak nevim, jestli se fdisk jiz GPT naucil. Podeziram, ze ne, takze ten vypis je na dve veci.
V kazdem pripad clovek muze obraz disku dd na jiny disk a pak zkusit testdisk.
-
no tam nejaky prazdny mbr je, asi to GPT protective mbr
jde o to, jestli tam je i GPT
ale odhaduju, ze cryptsetup luksDump /dev/sdb je spatne, melo by tam byt asi sdb1 nebo neco?
-
Vypis sudo gdisk -l /dev/sdb
Je to jen sdb a nevím, jak to bylo původně.
dd nemohu, nemám další volný tak veliký disk.
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************
Disk /dev/sdb: 15628053168 sectors, 7.3 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 78128D2C-C215-4450-B6E0-F585DC723CC0
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 15628053134
Partitions will be aligned on 2048-sector boundaries
Total free space is 15628053101 sectors (7.3 TiB)
Number Start (sector) End (sector) Size Code Name
-
Zálohu hlavičky nemám :(
Jedná se o ten 8TB disk.
Nevadi, tech 8TB porna si proste stahnes znova. ;) Ale ted vazne, pokud nemas zalohu hlavicky tak tech 8TB je pro tebe nedulezitych, tudiz si stahnes to porno znova. Jinak pokud tam bylo neco duleziteho, na 99.999% jsi o data prisel. Pro priste budes zalohovat nejenom hlavicku sifrovanych disku, ale naucis se taky pouzivat i zalohovaci nastroje a budes kupovat disky nejenom dle kapacity, ale dle toho aby jsi byl schopen mit i zalohu.
-
@Kkt1
Ale byla to fakt fajnová kolekce, vše v HD...
Zálohu mám, ale je celkem stará a zrovna když jsem ji chtěl aktualizovat, stane se mi tohle :( Jako už jsem těch pár desítek hodin oplakal, ale chtěl bych vyzkoušet co se dá, než ten disk natvrdo naformátuju a budu kopírovat starou zálohu.
Proto díky za případné návrhy.
-
dd nemohu, nemám další volný tak veliký disk.
Tak si ho budes muset aspon nekde pujcit. Jakekoliv laborovani bez zalohy nejspise povedek tomu, ze se zkurvi i to, co jeste zkurveno neni.
-
no tak GPT tam neni a mbr nema oddily, tak nevime, kde to zacinalo
co rekne file /dev/sdb a cryptsetup -v isLuks /dev/sdb
pripadne hledej z ruznyma offsetama od zacatku, dobry je zacit treba s offsetem 1MB
-
file /dev/sdb
/dev/sdb: block special (8/16)sudo cryptsetup -v isLuks /dev/sdb
Pozice 4 klíče LUKS není platná.
Pozice 5 klíče LUKS není platná.
Příkaz selhal s kódem 22: Pozice 5 klíče LUKS není platná.--offset=SEKTORY, kolik je to na 1MB? Díky.
-
Tak jsem spočítal 1024*1024/512=2048
sudo cryptsetup --offset=2048 -v isLuks /dev/sdb
cryptsetup: Přepínač --offset je podporován jen při otevírání zařízení plain a loopaes.Dál už nevím.
-
Tak mám to už vzdát, nebo ještě něco poradíte? Mám podezření, že mi ve Windows, které mám v dualboot, něco přepsalo disk na MBR...
Jako poslední možnost bych pak zkusil to znovu přehodit na GPT: https://www.quora.com/How-do-I-convert-my-drive-to-GPT-without-losing-data-and-my-partitions (https://www.quora.com/How-do-I-convert-my-drive-to-GPT-without-losing-data-and-my-partitions)
Poradíte ještě nějaký postup? Klidně napište, že už nevíte, ale ať mám jistotu, že jsem opravdu zkusil vše. Díky.
-
No, jestli na to sahly Widle, tak mozne je vsechno. Kurveni disku, kterym Widle nerozumi, je oblibeny Redmondsky sport.
Napada me udelat dd obraz, pak ten disk ze zacatku prepsat nejakym cisle, treba FF, znovu rozdelit, jak si myslis, ze byl, podivat se na to disk editorem, pokusit se najit kde je MBR a GPT a kde konci s tim, ze za nimi by mela byt datova oblast (kde mozna prezije par tech FF). Nasledne se pokusit vyhledat obdobne struktury (ci jejich zbytky) v obrazu, urcit co je asi datova oblast a tu nekopirovat do datove oblasti na disku. Behem kopirovani pak bez zapalit svicku do nejblizsiho kostela.
-
ten offset radeji pres
losetup -o
je ale potreba vyzkouset hodne hodnot, protoze nevime, kde ta partice zacinala, 2048 je dobrej zacatek, protoze to tak fdisk dela defaultne
GPT bude mit asi vetsi offset, dalo by se zjistit kolik, kdyz bys vyrobil stejny disk presne stejnym postupem
-
pro GPT koukam je bezny offset 8192, ten muzes zkusit
-
takhle?
losetup -o 8192 /dev/sdb
losetup: /dev/sdb: failed to use device: ÚspěchI pro 2048 to napíše to samé. Nemá to být v bajtech? Z --help jsem to nevyčetl.
GPT bude mit asi vetsi offset, dalo by se zjistit kolik, kdyz bys vyrobil stejny disk presne stejnym postupem
Mám totožný disk se zálohou, akorát je na něm pak LUKS+ext4. Jak to zjistím? Díky.
-
Na totožným disku udělej fdisk -l a zistíš offset.
Pro ten losetup se musí dát prvně třeba /dev/loop0. A nevím, jestli sežere /dev/sdb, nebo mu musíš dát soubor s obrazem disku.
Ten teda nemáš, protože nemáš místo, ale stačilo by si hrát s prvníma třeba 500M, tam ta hlavička musí být.
dd if=/dev/sdb of=image bs=1M count=500 skip=1
Offset tady je v tom skip, to měň. Případně můžeš změnit jednotky bs=512, seek=2048, count=1000000 (přibližně, na tom nefrčí). A pak udělat isLuks nebo file přímo na souboru image.
Záleží, jestli jsi měl standardní nebo nějakej divnej offset. Zkusil bych 1M=2048 a 4M=8192. Teď mě ještě napadlo, jestli seek nemá být o 1 míň náhodou, nevíte někdo? To by pak bylo 2047 a 8191
-
Tak na druhém disku je:
sudo fdisk -l /dev/sdc
Disk /dev/sdc: 7,3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: C24E7A9B-D473-4A5E-A5ED-67D2CAE2F8A6
Zařízení Start Konec Sektory Size Druh
/dev/sdc1 2048 15628053134 15628051087 7,3T Linux filesystemTen poškozený byl tvořen myslím:
parted /dev/sdc
mklabel GPTŽádné hodnoty jsem ručně neměnil.
Zkusím tedy ještě ten obraz. Chápu správně, že dd kopíruje bajt po bajtu? A pak musím trefit přesně ten počáteční (pokud ještě existuje), aby byla správně přečtena hlavička?
-
dd if=/dev/sdb of=image bs=1M count=500 skip=1
Offset tady je v tom skip, to měň. Případně můžeš změnit jednotky bs=512, seek=2048, count=1000000
Zkusil bych 1M=2048 a 4M=8192. 2047 a 8191
Jaký je rozdíl v mém použití při skip a seek? Manuál píše seek=N skip N obs-sized blocks at start of output
skip=N skip N ibs-sized blocks at start of input, kontrolní součet vzniklých souborů je jiný, takže co je lepší použít?
Jinak při použití skip a i seek =2047, 2048, 8191, 8192 to píše:
file image
image: data
cryptsetup -v isLuks image
Zařízení image není platným zařízením LUKS.
Příkaz selhal s kódem 22: Zařízení image není platným zařízením LUKS.
Bez skip je to už staré známé:
Pozice 4 klíče LUKS není platná.
Pozice 5 klíče LUKS není platná.
Příkaz selhal s kódem 22: Pozice 5 klíče LUKS není platná.
-
seek preskakuje ve vystupu
skip ve vstupu, chces teda skip
tak asi je ta hlavicka prepsana a bez ni to nepujde
jako zkouset muzes i jiny hodnoty skip, ale nevim, jestli to povede k uspechu
bs mas 512?
-
A LUKS si neudrzuje nekde druhou kopii hlavicky, ze ktere by si to clovek vycucnul?
-
Co tady jeste nezaznelo - jak se zalohuje LUKS hlavicka a jak se pripadne obnovuje?
Da se dumpnout a natahnout primo klic/IV kterym to sifruje?
Sifrovani jsem zatim nenasazoval prave z obav o situaci ke ktere prisel autor vlakna.. na jednom sektoru zalezi zbytek disku.
-
Co tohle? https://ubuntuforums.org/showthread.php?t=1643334
Vygrepovat hlavicku, pokud tam je a zkusit namontovat atd.
-
bs mas 512?
Ano
Co tohle? https://ubuntuforums.org/showthread.php?t=1643334
sudo hexdump -C -n 512 /dev/sda
00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69 |........xts-plai|
00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00 |n64.............|
00000040 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00 |........sha1....|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 20 |............... |
00000070 3d 2d 02 3f 42 54 63 83 71 4e 2b 75 7f 8f e6 57 |=-.?BTc.qN+u...W|Vypadá to podobně, jak tam. Jak to tedy moutnout? Díky
-
A LUKS si neudrzuje nekde druhou kopii hlavicky, ze ktere by si to clovek vycucnul?
Ne, pracuje se sice na tom, ale v současnosti je hlavička s klíčem bohužel jen jedna
-
Vypadá to podobně, jak tam. Jak to tedy moutnout? Díky
No tak to vypadá, že to máš fakt na samým začátku disku. Teda cryptsetup luksOpen /dev/sda nebo sdb by mělo jít
Ale asi něco přes ten LUKS zapsalo mbr (asi widle?) čímž se mohli poškodit ty klíče a jelikož jsou jen jednou, tak to vypadá blbě
Pro příště - disky co bude používat widle nebo někdo jinej by měli mít partition table, jinak widle říkaj: aha, neinicializovaný disk, něco tam honem lupnem
Jenom je mi divný, jak na začátku disku máš zarás LUKS a mbr. Mbr vypadá takto:
https://blog.philippklaus.de/2010/02/have-a-look-at-your-mbr-using-dd-and-hexdump (https://blog.philippklaus.de/2010/02/have-a-look-at-your-mbr-using-dd-and-hexdump)
-
Co tady jeste nezaznelo - jak se zalohuje LUKS hlavicka a jak se pripadne obnovuje?
Da se dumpnout a natahnout primo klic/IV kterym to sifruje?
Sifrovani jsem zatim nenasazoval prave z obav o situaci ke ktere prisel autor vlakna.. na jednom sektoru zalezi zbytek disku.
https://wiki.archlinux.org/index.php/dm-crypt/Device_encryption#Backup_and_restore
-
Vypadá to podobně, jak tam. Jak to tedy moutnout? Díky
LUKS neznam, tak se nebudu vytahovat, ale vidim tam 2 veci:
cryptsetup --verbose luksOpen /dev/sda7 sda7_crypt
a
losetup -o 0xf8200 -r -f /dev/sda7
losetup -a
/dev/loop0: (/dev/sda7), offset 1016320
cryptsetup luksOpen /dev/loop0 luksrecover
mount -o ro /dev/mapper/luksrecover /mnt/recover
Samozrejme, parametry treba upravit dle situace.
-
sudo cryptsetup luksDump /dev/sda
Pozice 4 klíče LUKS není platná.
Pozice 5 klíče LUKS není platná.
Tohle se typicky stane, kdyz hlavicku prepise signatura MBR (starsi Windows toto obcas delaji).
Zkopirujte/zalohujte si prvni 4 MB disku, pusttte na to cryptsetup repair <hlavicka>.
Pokud nebyl slot 4 a 5 pouzity, melo by se to opravit bez ztraty kyticky.
Jinak viz kapitola 4.1 ve FAQ: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
-
Zkopirujte/zalohujte si prvni 4 MB disku, pusttte na to cryptsetup repair <hlavicka>[/code
[/quote]
Pěkně, to jsem neznal
-
@Milan Broz
$sudo dd if=/dev/sda of=image bs=1M count=4
$sudo cryptsetup repair image
WARNING!
========
Opravdu se pokusit opravit hlavičku zařízení LUKS?
Are you sure? (Type uppercase yes): YES
Pozice 4 klíče LUKS není platná.
Pozice 5 klíče LUKS není platná.
Pozice klíče 4: poloha opravena (320599565 → 1032).
Pozice klíče 4: proklad opraven (0 → 4000).
Pozice klíče 4: sůl vymazána.
Pozice klíče 5: poloha opravena (0 → 1288).
Pozice klíče 5: proklad opraven (0 → 4000).
Pozice klíče 5: sůl vymazána.
Pozice klíče 6: chybná značka oddílu.
Pozice klíče 6: sůl vymazána.
$cryptsetup -v isLuks image
Příkaz úspěšně vykonán.
$file image
image: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: 66293fca-0110-4572-bf14-4ee3d113272bVypadá to nadějně. Mám stejný postup cryptsetup repair /dev/sda aplikovat přímo na ten disk, nebo ještě vyzkoušet něco jiného/jiný postup?
Díky moc.
-
image má hlavičku:
cryptsetup luksDump image
LUKS header information for image
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: 3d 2d 02 3f 42 54 63 83 71 4e 2b 75 7f 8f e6 57 bf 37 30 f7
MK salt: e8 14 5c af 04 7c 72 cb 5f 90 00 cb 8c 8c 7a d0
33 e4 a5 70 e7 fa 51 e5 ef ab d7 89 55 07 b0 a9
MK iterations: 40500
UUID: 66293fca-0110-4572-bf14-4ee3d113272b
Key Slot 0: ENABLED
Iterations: 165802
Salt: d5 0c f7 c0 92 21 de 48 74 01 e8 58 7d 8f e7 fc
98 cc 1a 94 ba ac ce f8 a8 d6 2e 49 67 30 ff 4f
Key material offset: 8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 156862
Salt: da 01 23 75 fe a3 79 33 46 75 ac 6f 8e 0d d6 9b
29 6a c0 60 8d d7 21 f3 53 75 08 bd 6f a3 8e 91
Key material offset: 264
AF stripes: 4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
A povedlo se ho i se správným heslem otevřít: cryptsetup luksOpen image imgJe na čase aplikovat to na /dev/sda ? :)
-
jo, udelej zalohu funkcni a strc ji do /dev/sda a melo by to fungovat
-
$cryptsetup luksHeaderBackup image --header-backup-file back.img
$cryptsetup -v --header back.img open /dev/sda test
Zadejte heslo pro /dev/sda:
Pozice klíče 0 odemknuta.
Příkaz úspěšně vykonán.test je úspěšně namountován a data jsou čitelná.
Udělal jsem tedy opravu na /dev/sda, která dopadla stejným úspěchem a disk je již čitelný. Wow.
Zbývá tedy udělat zálohu dat a tentokrát i hlaviček obou disků.
Zatím moc děkuji za rady a váš čas, který ušetřil ten můj.
-
Slava, sbirka porna je zachranena!
-
Slava, sbirka porna je zachranena!
Takže by snad moh tazatel nějaký zvlášť podařený kousek nasdílet za odměnu, ne? ;D 8)
-
Tak, záloha je aktuální, hlavičky zálohované. Ještě něco udělám s tím /dev/sdx, aby tam bylo sdx1 - pochopil jsem, že to s widlema není OK.
@JardaP LOL, jo hurá! :D
@Lol Phirae přišel po bitvě a chtěl by lízat smetanu :)
-
@Lol Phirae přišel po bitvě a chtěl by lízat smetanu :)
Tak teda lízání "smetany" jsem zrovna nemyslel... :P