Имеется диск, есть подозрение, что на нем криптоконтейнер luks с отдетаченным хидером. Есть какие-либо форенсик тулзы, которыми это можно проверить?

Делал тут клон приложения с помощью App Cloner, он ругнулся на то,что приложение использует нативные либы (NDK, C/C++) и предложил их пропустить, и вот тут у меня возник вопрос: а нативный код может работать в обход permissions, ну т.е. даже не давать права,например,к камере, можно сделать снимок из нативного кода? Насколько я понимаю,скорее всего нет, так как это была бы дыра в безопасности, но так как я не андроид-разраб, хотелось бы услышать мнение/подтверждение спеца.

А есть ли в природе решение под Android, которое при нажатии комбинации аппаратных клавиш (например, POWER+VOL_UP+VOL_DOWN) трет файлы и удаляет приложения по списку? Что-то в гугле ничего не находится.

Всем привет! В теме криптографии (и в LUKS в частности) я нуб, поэтому при реализации LUKS Full disk encryption возникло пара вопросов, ответы на которые не удалось найти в интернетах, поэтому надеюсь,что поможете.

• PBKDF2 и выбор хэша. Я правильно понимаю,что данные параметры влияют только при использовании пароля для криптоконтейнера, а при использовании keyfile нет? (поскольку PBKDF2 это стандарт формирования ключа на базе пароля)
• Опция –align-payload, которая управляет смещением криптоконтейнера от начала тома/диска. Может использоваться в качестве дополнительной меры security through obscurity. В man’е сказано,что по дефолту выбирается оптимальное выравнивание, опираясь на информацию от ядра. Поэтому вопрос, может ли указание данного параметра вручную повлиять на производительность чтения/записи на диск (стоит ли оставить по дефолту?)
• LUKS поверх RAID/LVM (с detached header). Опять же вопрос про security through obscurity. Стоит ли так реализовывать (например, RAID -> LUKS), ведь на диске в таком случае кроме криптоконтейнера будут распологаться служебные структуры LVM/RAID, по которым можно будет определить, что на диске может присутствовать данные (а не что диск просто стерт/пуст)?