Android использует рыночную модель безопасности, :различные приложения поступают от разных (полу-доверенных )поставщиков и должны быть изолированы от защищенных ресурсов и друг от друга. Большинство приложений распространяются -на основе прибыли :, они продаются (платное ПО ), показывают платную рекламу или «монетизируют» своих пользователей, продавая их данные третьим лицам. Существует высокая мотивация заниматься незаконным доступом к данным, даже если их поймают.
Большинство приложений в Debian, Red Hat и подобных «классических» дистрибутивах Linux распространяются в виде исходного кода. :После того, как приложения с открытым исходным кодом набирают достаточное количество оборотов, они вручную выбираются для включения сопровождающими дистрибутива. Существует небольшая мотивация для незаконного доступа к данным — потенциальная выгода не оправдывает усилий.
Стоит отметить, что передовая модель безопасности Android является одной из причин, по которой она завоевала такую популярность, легко вытеснив iOS на мобильных рынках. Современные настольные дистрибутивы Linux не просто «другие», они на самом деле сильно отстают от времени с точки зрения своих моделей безопасности и распространения.
Некоторые дистрибутивы Linux предлагают улучшения в своей системе распространения программного обеспечения :централизованные сторонние репозитории программного обеспечения (AUR ),специализированные форматы пакетов для распространения стороннего -программного обеспечения (AppImage, Snappy, Flatpack ), системы вторичного репозитория (Docker ). К сожалению, со временем эти улучшения не получили должного развития. :AppImage был изобретен в 2004 г., первая версия AUR была выпущена в 2005 г., однако ни один из современных дистрибутивов Linux официально не принял их функции более чем через 10 лет.
Таким образом, это, кажется, случай случайного неправильного обнаружения фиктивной таблицы разделов -.
Вот пример таблицы разделов 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.