mdadm 배열 아래의 md 파티션은 무엇입니까?

Question

따라서 이는 무작위로 위조된 파티션 테이블을 오탐한 경우인 것으로 보입니다.

다음은 Atari/AHDI 분할 테이블(parted를 사용하여 생성됨)의 예입니다.

# hexdump -C -n 512 /dev/loop0 
000001c0  00 00 00 03 20 00 01 4c  4e 58 00 00 08 00 00 00  |.... ..LNX......|
000001d0  08 00 01 4c 4e 58 00 00  18 00 00 00 60 00 00 50  |...LNX......`..P|
000001e0  41 52 54 45 44 41 54 41  52 49 00 50 41 52 54 45  |ARTEDATARI.PARTE|
000001f0  44 41 54 41 52 49 00 00  00 01 00 00 00 01 fa 70  |DATARI.........p|

따라서 흥미로운 비트는 block/partitions/atari.c#L27-L32에 표시된 대로 오프셋 0x1c0/0x1d0 라인에 있는 GEM, BGM, LNX, SWP, RAW 중 하나입니다.

static inline int OK_id(char *s)
{
    return  memcmp (s, "GEM", 3) == 0 || memcmp (s, "BGM", 3) == 0 ||
        memcmp (s, "LNX", 3) == 0 || memcmp (s, "SWP", 3) == 0 ||
        memcmp (s, "RAW", 3) == 0 ;
}

다음은 LUKS2 헤더의 예입니다.

# hexdump -C -n 512 /dev/loop1
00000000  4c 55 4b 53 ba be 00 02  00 00 00 00 00 00 40 00  |LUKS..........@.|
00000010  00 00 00 00 00 00 00 03  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000040  00 00 00 00 00 00 00 00  73 68 61 32 35 36 00 00  |........sha256..|
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  a4 43 6c 13 63 6b 33 da  |.........Cl.ck3.|
00000070  c8 f5 1d 7d 82 b3 9e dc  15 b2 ff 55 d2 4c 3e 8c  |...}.......U.L>.|
00000080  62 08 ec 0f 56 b2 bc 89  86 f0 e8 c0 e6 a2 d8 12  |b...V...........|
00000090  56 93 68 2f 83 82 e6 90  18 57 7b 23 34 d7 96 92  |V.h/.....W{#4...|
000000a0  ab ad 67 a5 d9 7d dd 6c  32 36 37 36 35 63 39 32  |..g..}.l26765c92|
000000b0  2d 34 34 37 34 2d 34 36  37 64 2d 62 39 62 62 2d  |-4474-467d-b9bb-|
000000c0  64 36 30 36 63 61 64 31  32 61 62 64 00 00 00 00  |d606cad12abd....|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  55 85 e9 50 c2 46 1e 16  27 a7 ce a5 9d e9 46 17  |U..P.F..'.....F.|
000001d0  fb 30 9a ae 53 74 39 8a  c5 2c d2 21 4b 86 ad 20  |.0..St9..,.!K.. |
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

따라서 동일한 0x1c0 / 0x1d0 줄에 임의의 데이터가 있는 경우가 있습니다.

내 생각엔 GEM, BGM, LNX, SWP, RAW 중 하나를 무작위로 굴려서 커널의 파티션 테이블처럼 보였고 따라서 이상한 파티션을 발견한 것 같습니다.

좋은 소식은 LUKS2 헤더의 경우 이 오프셋이 헤더 체크섬을 나타내는 것으로 보인다는 것입니다. LUKS2 헤더에서 무엇이든 변경할 때마다 완전히 변경되므로... 예를 들어 다른 암호 문구를 추가하면 됩니다. (실제로 필요하지 않은 경우 제거하십시오.)

# cryptsetup luksAddKey /dev/loop1
Enter any existing passphrase: 
Enter new passphrase for key slot: 
Verify passphrase:

실행 후 동일한 LUKS2 헤더 cryptsetup luksAddKey:

# hexdump -C -n 512 /dev/loop1
00000000  4c 55 4b 53 ba be 00 02  00 00 00 00 00 00 40 00  |LUKS..........@.|
00000010  00 00 00 00 00 00 00 05  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000040  00 00 00 00 00 00 00 00  73 68 61 32 35 36 00 00  |........sha256..|
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  a4 43 6c 13 63 6b 33 da  |.........Cl.ck3.|
00000070  c8 f5 1d 7d 82 b3 9e dc  15 b2 ff 55 d2 4c 3e 8c  |...}.......U.L>.|
00000080  62 08 ec 0f 56 b2 bc 89  86 f0 e8 c0 e6 a2 d8 12  |b...V...........|
00000090  56 93 68 2f 83 82 e6 90  18 57 7b 23 34 d7 96 92  |V.h/.....W{#4...|
000000a0  ab ad 67 a5 d9 7d dd 6c  32 36 37 36 35 63 39 32  |..g..}.l26765c92|
000000b0  2d 34 34 37 34 2d 34 36  37 64 2d 62 39 62 62 2d  |-4474-467d-b9bb-|
000000c0  64 36 30 36 63 61 64 31  32 61 62 64 00 00 00 00  |d606cad12abd....|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  2a 11 50 fd 0b 8a 05 b6  67 1a e5 2f 2b a7 de d5  |*.P.....g../+...|
000001d0  2c b3 17 7c a5 21 b5 a1  5a f3 86 5c 96 9e 16 c0  |,..|.!..Z..\....|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

보시다시피 0x1c0/0x1d0 행의 데이터는 이전과 완전히 다르기 때문에 운이 좋으면 가짜 파티션 테이블도 사라집니다(파티션 테이블을 다시 읽은 후). 앞으로 제목을 변경하면 다시 돌아올 수 있으므로 계속 지켜봐야 할 사항입니다...

luksFormat이전 LUKS1 헤더는 이 오프셋에 임의의 데이터를 저장하지 않고 다음과 같이 0으로 설정하기 때문에 LUKS2를 사용한다고 가정합니다.

000001c0  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

따라서 이전 LUKS1 헤더 형식에는 이러한 문제가 전혀 발생하지 않습니다.

Answer 1