Хотелось бы задать вопрос, а ответили ли Вам как-нибудь разработчики в связи с этой статьей? Или это конфеденциальная информация? Можете сказать, купили ли какие-либо компании ваш анализатор после того, как был проанализирован код их приложений?
Я старался так объяснять, чтобы было понятно как это работает с примерами кода (хотя я много лишнего опускал). Вы предлагаете ещё глубже объяснять как устроена система?
Даешь «Создание эффективных Android приложений с учетом специфики платформы» ;)
Ну, здесь я не специалист. Как Вы могли заметить, по своей работе я занимаюсь больше модификацией самой операционной системы. Конечно же, мне иногда приходится писать приложения, но они в основном предназначены для тестирования моих модификаций.
Странно, как-то очень мало комментариев к статье. У меня несколько предположений по этому поводу:
Либо мало людей занимается программированием внутренностей Андроида
Либо слишком сложно написаны статьи
Либо цикл статей сильно затянулся, и интерес пропал
Свое...
Дорогие хабраюзеры, оставьте хотя бы несколько строчек фидбэка, а так совсем непонятно, стоит ли писать продолжение. Что Вам понравилось, что не понравилось, какие моменты остались не совсем раскрытыми?
А ещё хочется спросить, может у кого был опыт с визой O-1. Вроде в случае если ты заканчиваешь PhD, у тебя скорее всего есть все предпосылки подаваться на этот тип визы, если едешь продолжать работать по специальности.
А будут ли доступны какие-то материалы после встречи? Мне очень бы хотелось услышать и посмотреть как устроен внутри Tizen. Да, наверное, и не мне одному, учитывая сколько новинок было представлено основанных на этой операционной системе.
Так здесь же описывается, как защитить свое приложение от того, чтобы к нему не подключались другие. Как мне кажется, в этом случае лучше использовать разрешения с уровнем signature. В этом случае, только приложения подписанные вашим ключом смогут получать доступ к компонентам, защищенным данным разрешением.
Пользователю показываются только разрешения, у которых уровень соответствует dangerous.
Поищите приложение AppOps. По-моему, оно работает на версиях Android'a 4.2-4.4 и позволяет для разных приложений выбрать некоторые разрешения. Запрещенные разрешения будут эмулироваться, например, если запретить чтения контактов приложению, то ему система будет выдавать пустой лист контактов.
Тема довольно интересная и не такая уж и простая :) Я бы посоветовал начать вот отсюда, а дальше лучшее, что я нашел в свое время, это вот это. А вообще, лучше всего читать исходники, но, к сожалению, это делать довольно сложно (возможно только мне).
Во-первых, меня не покидает ощущение, что я уже где-то это читал. Я бы всё-таки советовал давать ссылки на источники. В данном случае, мне кажется, что это книга Karim Yaghmour «Embedded Android» и презентации Marakana group (сейчас их можно найти здесь).
А во-вторых, несотрудники Google тоже имеют право отправлять свои патчи. Если они пройдут ревью, то их включат в основную ветку.
Вы меня не совсем правильно поняли. Я понимаю, что он решает другую задачу. Просто хотел показать, каким образом скрывает строки DexGuard, т.к. мне показалось, что эту статью уместно упомянуть в контексте проблемы, которую Вы решаете.
Что же касается Вашего способа, то он усложняет жизнь только человеку, который будет вручную анализировать, как работает Ваша программа. Любой статический анализатор сразу покажет связи между компонентами.
Насколько я понимаю, в статье упоминается про DexGuard. Совсем недавно натолкнулся на статью, которая описывает алгоритм работы со строками этого инструмента. Посмотрите, очень интересно.
Очень смеялся когда-то со следующего комментария, который встретил в исходниках Android:
/**
* @hide
* Private impl for avoiding a log message... DO NOT USE without doing
* your own log, or the Android Illuminati will find you some night and
* beat you up.
*/
Насколько я помню, в конец init.rc добавятся последовательно комманды из init.usb.rc, init.${ro.hardware}.rc, init.trace.rc, init.carrier.rc и т.д. Т.е. сначала выполняться комманды из init.rc, а потом последовательно комманды из всех импортируемых файлов.
Не совсем. В этом случае, тогда не надо было выделять «международная степень доктора Ph.D.», а просто использовать анналог. Т.е. результат получения Ph.D. есть в опроснике, тогда как пункта для процесса получения этой степени нет. Ну и после аспирантуры человек становится кандидатом, а после окончания Ph.D. программы — доктором.
Такой критический баг с описанием в багтрекере привел бы к тому, что очень много пользователей Android стали бы под угрозой. Поэтому я считаю, что баг есть, но он только во внутреннем багтрекере (если вы разработчик Android, то должны знать, что есть AOSP и внутренняя ветка в Google, где они разрабатывают свою систему. Более того, у них есть внутренний багтрекер). Более того, именно поэтому код для исправления бага и не появляется в AOSP, потому что не все производители смогут быстро сделать обновления для их продуктов. Поэтому я предполагаю, что этого доклада на конференции не будет, потому что он затрагивает интересы очень многих пользователей и корпораций. Bluebox хотела славы — она её получила, особенно, если Google официально попросит не представлять этот доклад.
Хотя, как уже отмечали здесь, информации, которую раскрыла Bluebox, достаточно, чтобы начать поиск этой уязвимости, и мне кажется, что в ближайшее время мы услышим (или увидим) подтверждение тому. Сам вчера целый день копался в исходниках и у меня есть догадка, где зарыта собака.
Я старался так объяснять, чтобы было понятно как это работает с примерами кода (хотя я много лишнего опускал). Вы предлагаете ещё глубже объяснять как устроена система?
Ну, здесь я не специалист. Как Вы могли заметить, по своей работе я занимаюсь больше модификацией самой операционной системы. Конечно же, мне иногда приходится писать приложения, но они в основном предназначены для тестирования моих модификаций.
Дорогие хабраюзеры, оставьте хотя бы несколько строчек фидбэка, а так совсем непонятно, стоит ли писать продолжение. Что Вам понравилось, что не понравилось, какие моменты остались не совсем раскрытыми?
signature. В этом случае, только приложения подписанные вашим ключом смогут получать доступ к компонентам, защищенным данным разрешением.Пользователю показываются только разрешения, у которых уровень соответствует
dangerous.А во-вторых, несотрудники Google тоже имеют право отправлять свои патчи. Если они пройдут ревью, то их включат в основную ветку.
Что же касается Вашего способа, то он усложняет жизнь только человеку, который будет вручную анализировать, как работает Ваша программа. Любой статический анализатор сразу покажет связи между компонентами.
Хотя, как уже отмечали здесь, информации, которую раскрыла Bluebox, достаточно, чтобы начать поиск этой уязвимости, и мне кажется, что в ближайшее время мы услышим (или увидим) подтверждение тому. Сам вчера целый день копался в исходниках и у меня есть догадка, где зарыта собака.