Комментарии 33
А чем собственно такой способ шифрования лучше стокового full encryption Android 4+?
Там так же шифруются целиком data и sdcard.
При загрузке поднимается временный Android — с data в RAM-drive — только для запроса пароля.
После чего он выгружается, data перемонтируется на настоящую и Android грузится вновь.
Там так же шифруются целиком data и sdcard.
При загрузке поднимается временный Android — с data в RAM-drive — только для запроса пароля.
После чего он выгружается, data перемонтируется на настоящую и Android грузится вновь.
Есть несколько ЗА в пользу описанного способа перед родным.
Во-первых он полностью работоспособен на 2.2+
Во-вторых он неочевиден. Используя устройство с большим объемом памяти можно легко скрыть сам факт наличия второго дна.
В третьих это гибкость настройки — можно масштабировать объемы шифрования как угодно.
В четвертых это опенсорс.
В пятых это совместимо со всеми прошивками и ядрами.
В шестых — удобно бэкапить и восстанавливать информацию.
Думаю достаточно аргументов за.
Во-первых он полностью работоспособен на 2.2+
Во-вторых он неочевиден. Используя устройство с большим объемом памяти можно легко скрыть сам факт наличия второго дна.
В третьих это гибкость настройки — можно масштабировать объемы шифрования как угодно.
В четвертых это опенсорс.
В пятых это совместимо со всеми прошивками и ядрами.
В шестых — удобно бэкапить и восстанавливать информацию.
Думаю достаточно аргументов за.
Не все устройства на android 4.x умеют шифровать внутреннюю память, пример тому htc sensation, плюс сделано это кривовато — придется вводить длинный криптостойкий пароль при каждой разблокировке экрана.
Eсть метод и замечательная тулза которая позволяет менять пароль на закриптованную внутреннюю память —
nelenkov.blogspot.com/2012/08/changing-androids-disk-encryption.html
nelenkov.blogspot.com/2012/08/changing-androids-disk-encryption.html
Имею DZ, разделы полностью аналогичны DHD.
Насчёт IMEI не всё просто… Вы проверили, что ОпСоС получает исправленный IMEI после изменения его в mmcblk0p7?
Дело в том, что где-то ещё я видел коипю IMEI, и в p7 он у меня лежит не полностью.
Весь IMEI (указан на коробке, в меню HBOOT и в служебной информации)
************822
А в p7 лежит почти он
************8201
Возможно, в конце что-то типа контрольной суммы, которая не влияет на код и потому можно конец хранить с искажением.
Насчёт IMEI не всё просто… Вы проверили, что ОпСоС получает исправленный IMEI после изменения его в mmcblk0p7?
Дело в том, что где-то ещё я видел коипю IMEI, и в p7 он у меня лежит не полностью.
Весь IMEI (указан на коробке, в меню HBOOT и в служебной информации)
************822
А в p7 лежит почти он
************8201
Возможно, в конце что-то типа контрольной суммы, которая не влияет на код и потому можно конец хранить с искажением.
А вот за рецепт перезапуска оболочки без ребута ядра — спасибо.
Я перенёс /data на отдельный раздел sd-card, монтируется он в исправленном в initrd init.rc-скрипте.
Переключаться между data-разделами без прошивки ядра я не умел, старый /data (mmcblk0p26) оказался незадействованным.
Теперь можно завести себе кнопку-переключатель для перевода девайса в режим «дай поиграться/позвонить», а шифрование для таких сценариев и не нужно.
Я перенёс /data на отдельный раздел sd-card, монтируется он в исправленном в initrd init.rc-скрипте.
Переключаться между data-разделами без прошивки ядра я не умел, старый /data (mmcblk0p26) оказался незадействованным.
Теперь можно завести себе кнопку-переключатель для перевода девайса в режим «дай поиграться/позвонить», а шифрование для таких сценариев и не нужно.
Остановка оболочки (точнее, всей виртуалки — далвика) командой stop, а запуск, соответственно, командой start — не то же самое?
Ещё killall system_server вызывает тот же результат. Или есть отличия?
Ещё killall system_server вызывает тот же результат. Или есть отличия?
kill system_server вызывает немедленный перезапуск системы.
нужно остановить, проделать изменения в точках монтирования, запустить.
нужно остановить, проделать изменения в точках монтирования, запустить.
Согласен. Интересный способ убийства зигот ) Не знал, что можно указывать оригинальное имя процесса.
А есть похожие статьи по iOS устройствам? Как у них с безопасностью?
Спасибо за статью, сам недавно сделал для своего htc sensation тотальное криптование через dm-crypt, правда я легких путей не искал, наваял утилиту позволяющую вводить пароль при самом включении телефона (дергаеться из init.pyramid.rc до монтирования data, cache и devlog, и далее скрипт уже монтируют устройства из /dev/mapper), все собираюсь написать тоже статью, но никак не дойдет ход, теперь точно возьмусь :-)
Интересно, через какое API делается ввод пароля, ведь кроме ядра ещё ничего не стартовало?
API — вот это самая большая Ж ;)
Если интерсно, исходники тут: github.com/quarck/csetup/tree/master/csetup/jni (код там далеко не идеальный, т.к. писалось в спешке, хотелось скорее получить результат, так что как следствие — в ряде мест забито на удаленее созданных обьектов, по принципу «все равно exit все подчистит» )
Из API исползуется по сути только open / read / write / mmap / select и memcpy, остальное все — ручками, ручками. Как — постараюсь расписать в статье, которую пытаюсь осилить.
Если интерсно, исходники тут: github.com/quarck/csetup/tree/master/csetup/jni (код там далеко не идеальный, т.к. писалось в спешке, хотелось скорее получить результат, так что как следствие — в ряде мест забито на удаленее созданных обьектов, по принципу «все равно exit все подчистит» )
Из API исползуется по сути только open / read / write / mmap / select и memcpy, остальное все — ручками, ручками. Как — постараюсь расписать в статье, которую пытаюсь осилить.
OMG! Библиотека для отрисовки UI и текста во фреймбуфер.
А как сейчас дела обстоят, мануал можно по установке?
Спасибо за интерес. Все никак не собирусь описать это в статье. Много шансов, что на устройствах отличных от HTC Sensation / Galaxy S3 будет нужно допиливание напильником. Я сейчас код адаптировал под Galaxy S3, на нем работает. Про остальные телефоны — не уверен.
Установка заключается в том, что-бы:
1. создать каталог /system/csetup, и скопировать туда: бинарник csetup, файлик letters.bmp, утилиты cryptsetup (сторонняя).
2. Выдрать так или иначе boot.img из прошивки, распаковать, и поправить скрипт загрузки, что-бы для /data монтировался раздел из /dev/mapper/data, и что-бы перед монтированием делался exec /system/csetup/csetup
3. Запаковать boot.img обратно, и прошить.
Более подробно — все это выйдет на огромную статью, к сожалению все нет времени на ее написание. Но вообще, код рабочий, сам пользуюсь, т.к. параноик, а встроенное шифрование на андроиде — очень неудобное. После выноса /data/dalvik-cache в /cache раздел, стало почти так-же шустро, как и без шифрования (т.е. далвик-кеш не шифруется, но в нем ничего приватного, кроме списка установленных приложений, нет).
Установка заключается в том, что-бы:
1. создать каталог /system/csetup, и скопировать туда: бинарник csetup, файлик letters.bmp, утилиты cryptsetup (сторонняя).
2. Выдрать так или иначе boot.img из прошивки, распаковать, и поправить скрипт загрузки, что-бы для /data монтировался раздел из /dev/mapper/data, и что-бы перед монтированием делался exec /system/csetup/csetup
3. Запаковать boot.img обратно, и прошить.
Более подробно — все это выйдет на огромную статью, к сожалению все нет времени на ее написание. Но вообще, код рабочий, сам пользуюсь, т.к. параноик, а встроенное шифрование на андроиде — очень неудобное. После выноса /data/dalvik-cache в /cache раздел, стало почти так-же шустро, как и без шифрования (т.е. далвик-кеш не шифруется, но в нем ничего приватного, кроме списка установленных приложений, нет).
Хочу добавить, что в 4.2 изменилась политика разрешений для работы с файловой системой. В данный момент мы работаем над криптосистемой под 4.2.2 и столкнулись с такой проблемой, что прежние алгоритмы монтирования, вызываемые из-под рута в приложении без всякой ошибки просто игнорируют монтирование в /data/. При этом вручную из-под рутового adb все работает без ошибок. Ну и в связи с доминированием моделей со встроенной памятью усложнилась процедура подмены /sdcard/, так как приходится обходить fuse, в 4.2.2 с этим наблюдаются те же проблемы, что и с монтированием в /data/
как будет время попробую на desire hd прошивка 4.2.2
мб получиться хотябы память зашифровать
мб получиться хотябы память зашифровать
Дело в концепции, а не в легкости. Вы выбрали путь явного шифрования, которое бросит вызов тому, кто захочет завладеть вашими данными. И тут у вас могут возникнуть проблемы разной вариативности, от применения терморектального криптоанализа, до случайно успешного брутфорса. На мой взгляд лучше выиграть битву, избежав ее — нет признаков крипторазделов, нет попыток в них проникнуть.
В моем случае есть 2 системы, одна — живет полностью на SD, другая — во внутренностях (точнее даже 3 — еще минималистическая с урезанными по размеру data и cache, доступная без пароля по кнопке emergency). В случае принуждения можно выдать пароль, который грузит в систему живущую на SD, это не спасет от случая предварительного анализа того, что творится в прошивке, но если кто просто силой здесь и сейчас попросит ввести пароль — то будет вариант. Да и я не думаю, что я лично попаду в такую ситуацию, когда меня будет кто-то терморектально атаковать ;) Просто не хочется что-бы свои приватные документы нечайно утекли, например при потере телефона, т.к. даже если не копаться с adb, то на одной только SD-шке приватных данных тьма, многие приложения без зазрения совести кешируют дофига всего туда, или вообще используют как хранилище основное, не заботясь о каком-либо мало-мальском криптовании (например evernote, для примера).
А есть опыт использования двойной конфигурации?
На практике в каком режиме телефон чаще всего находится?
Если в обычном — в любой момент может позвонить контакт, а в адресной книге его нет — неудобства.
От push придётся отказываться.
Переключение небыстрое (минуту-две). Перезагрузки, чтобы почту проверить, наверное будет терпимы поначалу, а потом станут раздражать и в итоге скорее всего телефон будет загружен всегда в секретном режиме.
И тогда атакующий будет видеть отличия режимов, аргумент незнания атакующего о «втором дне» слабеет. Особенно, если по совету статьи обои сменить и сделать режимы максимально различными визуально.
На практике в каком режиме телефон чаще всего находится?
Если в обычном — в любой момент может позвонить контакт, а в адресной книге его нет — неудобства.
От push придётся отказываться.
Переключение небыстрое (минуту-две). Перезагрузки, чтобы почту проверить, наверное будет терпимы поначалу, а потом станут раздражать и в итоге скорее всего телефон будет загружен всегда в секретном режиме.
И тогда атакующий будет видеть отличия режимов, аргумент незнания атакующего о «втором дне» слабеет. Особенно, если по совету статьи обои сменить и сделать режимы максимально различными визуально.
Скажем так, сильно ограниченным тиражом была выпущена тестовая партия криптофонов, одним из компонентов которых был как раз такой функционал оборотня. По отзывам пользующихся — они все время находятся в зищищенном режиме, переходя в открытый только в экстренных случаях или для наполнения фейк-контентом. Отзывы самые положительные, неудобством является только необходимость вручную синхронизировать данные между крипто-флешкой и открытой частью, чтобы потом видеть их при подключении к ПК по USB. Но это мелкая трудность, решаемая примитивным двухоконным файл-менеджером, где можно выбирать какие данные синхронизировать между открытым и закрытым режимами.
Конечно же тайна второго дна актуально только в том случае, если злоумышленник не находится в близком кругу владельца и не может знать, какие у него обои и значки на рабочем столе.
Тут сценарий простой — телефон попадает в чужие руки в состоянии пинлок-блокировки, чтобы обойти ее обязательно потребуется перезагрузка, а после перезагрузки данные автоматически запираются на амбарный замок. Повторяю, при использовании устройства с большим объемом единой памяти — догадаться, что какой-то из архивов или файлов является второй защищенной системой — очень непросто.
Конечно же тайна второго дна актуально только в том случае, если злоумышленник не находится в близком кругу владельца и не может знать, какие у него обои и значки на рабочем столе.
Тут сценарий простой — телефон попадает в чужие руки в состоянии пинлок-блокировки, чтобы обойти ее обязательно потребуется перезагрузка, а после перезагрузки данные автоматически запираются на амбарный замок. Повторяю, при использовании устройства с большим объемом единой памяти — догадаться, что какой-то из архивов или файлов является второй защищенной системой — очень непросто.
А есть такой Клип для Моторол? Конкретно — для Motorola Droid RAZR (XT910).
а где андроид хранит DRM ключи? можно ли здампить все содержимое eMMC?
Статья отличная — интересная и полезная. Карту памяти защищать надо — это всегда пригодится.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
За кулисами Android: что-то, чего вы можете не знать