Какие разделы md входят в массив mdadm?

Android использует рыночную модель безопасности, :различные приложения поступают от разных (полу-доверенных )поставщиков и должны быть изолированы от защищенных ресурсов и друг от друга. Большинство приложений распространяются -на основе прибыли :, они продаются (платное ПО ), показывают платную рекламу или «монетизируют» своих пользователей, продавая их данные третьим лицам. Существует высокая мотивация заниматься незаконным доступом к данным, даже если их поймают.

Большинство приложений в Debian, Red Hat и подобных «классических» дистрибутивах Linux распространяются в виде исходного кода. :После того, как приложения с открытым исходным кодом набирают достаточное количество оборотов, они вручную выбираются для включения сопровождающими дистрибутива. Существует небольшая мотивация для незаконного доступа к данным — потенциальная выгода не оправдывает усилий.

Стоит отметить, что передовая модель безопасности Android является одной из причин, по которой она завоевала такую ​​популярность, легко вытеснив iOS на мобильных рынках. Современные настольные дистрибутивы Linux не просто «другие», они на самом деле сильно отстают от времени с точки зрения своих моделей безопасности и распространения.

Некоторые дистрибутивы Linux предлагают улучшения в своей системе распространения программного обеспечения :централизованные сторонние репозитории программного обеспечения (AUR ),специализированные форматы пакетов для распространения стороннего -программного обеспечения (AppImage, Snappy, Flatpack ), системы вторичного репозитория (Docker ). К сожалению, со временем эти улучшения не получили должного развития. :AppImage был изобретен в 2004 г., первая версия AUR была выпущена в 2005 г., однако ни один из современных дистрибутивов Linux официально не принял их функции более чем через 10 лет.

1
14.01.2020, 00:00
1 ответ

Таким образом, это, кажется, случай случайного неправильного обнаружения фиктивной таблицы разделов -.

Вот пример таблицы разделов 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|

Таким образом, интересным битом является один из строк GEM, BGM, LNX, SWP, RAW со смещением 0x1c0/0x1d0, что можно увидеть в block/partitions/atari.c #L27 -L32:

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 полностью изменились по сравнению с предыдущими, поэтому, если повезет, ваша фиктивная таблица разделов также исчезнет (после повторного -чтения таблиц разделов ). В то же время на это стоит обратить внимание, так как любые будущие изменения в заголовке могут вернуть его...


Я предполагаю, что вы используете LUKS2, потому что старый заголовок LUKS1 не хранит случайные данные по этому смещению, а luksFormatтакже обнуляет его вот так:

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.

1
27.01.2020, 23:40

Теги

Похожие вопросы