Uses permission android name android permission wake lock

Страшная сказка на ночь для пользователей Android

Каждый, наверное, сталкивался с сайтами, предлагающими пользователю платную подписку на ту или иную услугу. В силу специфики моей работы мне иногда приходится проверять подобные ресурсы. Чаще всего они наспех набиты контентом, фальшивыми комментариями и созданы специально для обмана пользователя. Создатели обещают золотые горы, а на деле все заканчивается банальным разводом на деньги. Данная статья — один из частных случаев анализа фейк-сайта с приложением для Android.

Все началось с того, что мне прислали на проверку сайт. По виду — обычный варезный блог с громкими заголовками типа “Бесплатные обои и картинки для андроида”, “Самые умные программы на андроид” и тому подобное. Сразу бросилось в глаза, что во всех постах одинаковые комментарии, оставленные “разными людьми”. Содержание примерно следующее:

— Сайт просит ввести номер телефона, это нормально?
— Да, это для регистрации, проверка, что ты не бот.
— О, круто, спасибо!

В общем факт обмана виден сразу, но я решил копать дальше. При попытке загрузить приложение из любого поста с помощью стационарного компьютера, меня перекидывает на другой ресурс. Ссылка вида http://****/**/?sub_id=* (ага, возможно партнерочка). Там мне предлагают купить за деньги Google Chrome (и ведь ведутся же люди!).

Допустим… Но ведь ресурс посвящен приложениям для Android устройств, значит, нужно попробовать зайти с девайса. Как и следовало ожидать: вместо предложения купить супер-браузер загружается install.apk. “Вот это уже интересно” — подумал я и не ошибся.

Первое, что бросилось в глаза — огромное количество потенциально опасных разрешений.

Не слабый набор, правда? Мне стало интересно, что же приложение делает со всеми этими разрешениями.

Не буду описывать сам процесс декомпиляции, лишь упомяну, что использовал apktools, dex2jar, JD-GUI и jad. В итоге я получил декомпилированные ресурсы и набор классов.

Первое, на что я обратил внимание, это, разумеется, AndroidManifest.xml.

Коротко о разрешениях:

READ_PHONE_STATE — получение информации о телефоне (номер телефона, серийник, информация о вызовах);
SEND_SMS — отправка sms-сообщений;
RECEIVE_SMS — прием sms-сообщений и последующее удаление их (именно поэтому приоритет у MainReceiver наивысший);
INTERNET — использование интернета;
WAKE_LOCK — отключает спящий режим (видимо для повышения стабильности :);
ACCESS_NETWORK_STATE — информация о сетевых соединениях;
RECEIVE_BOOT_COMPLETED — получать сообщения о загрузке устройства, что позволяет выполнять приложение при запуске;
WRITE_EXTERNAL_STORAGE — запись/удаление информации на карте памяти;
INSTALL_PACKAGES — приложение может устанавливать или обновлять пакеты;
DELETE_PACKAGES — приложение может удалять пакеты;
READ_CONTACTS — доступ к контактам;
CALL_PHONE — осуществляет телефонные вызовы;
CALL_PRIVILEGED — осуществляет телефонные вызовы, в том числе по экстренным номерам;
GET_TASKS — получение данных о запущенных приложениях;
SYSTEM_ALERT_WINDOW — показывает сообщения поверх всех окон;
RESTART_PACKAGES — способно завершать фоновые процессы других приложений (официальное описание);
KILL_BACKGROUND_PROCESSES — способно завершать фоновые процессы других приложений (официальное описание);
READ_LOGS — чтение конфиденциальных данных из журнала.

Так же есть ресивер, который срабатывает на следующие намерения:

SMS_RECEIVED — получено sms-сообщение;
custom.alarm — внутреннее событие;
BOOT_COMPLETED — загрузка завершена;
USER_PRESENT — пользователь разблокировал устройство;
PHONE_STATE — изменение состояния сотовой сети (не знаю, как выразиться корректней, также позволяет мониторить вызовы пользователя);
SCREEN_OFF — при отключении экрана;
SCREEN_ON — при включении экрана.

Так как времени на изучение приложение у меня было немного (стояла задача в общих чертах узнать, что делает приложение), я не стал вдаваться во все тонкости. Почти все URL там зашифрованы, и для расшифровки нужно просидеть не один час. Можно, конечно, получить их с помощью WireShark, но в этом нет необходимости.

Работа приложения

Пришло время заглянуть в декомпилированные классы. Начнем пожалуй с MainActivity. Я прокомментирую функции, на которые стоит обратить внимание:

При детальном анализе можно увидеть, что сообщение отправляется сразу, а не после нажатии кнопки “Далее” (как это обычно принято). Лицензионное соглашение есть, но оно очень хорошо запрятано. Но отправка сообщения — это не самая страшная проблема. Помните большое количество разрешений? Давайте посмотрим, зачем они все-таки нужны приложению.

Чтобы сэкономить место и ваше время, я не буду выкладывать MainReceiver. Сразу скажу, что он обрабатывает и удаляет (!) входящие сообщения, а в случае необходимости еще и отвечает.

Самое интересное находится в MainService. При запуске сервис подключается к серверу, запрашивает оттуда данные, получает нечто в json и при успешном ответе запускает метод executeCommands(jsonobject1). И тут начинается магия:

Фактически это троянский конь. Классический такой троянский конь, позволяющий сливать данные пользователя и управлять его телефоном.

Резюме

На хабре не тот контингент, которому стоит читать нотацию на тему “не ставьте не проверенные приложения”, поэтому данную часть своего выступления я опущу.

Первые вредоносные приложения просто отправляли платные sms-сообщения, потом начали рассылать себя всем из списка контактов, а теперь — мы имеем полноценную троянскую лошадь, которую можно дергать за поводья удаленно. Эволюция…

Перечислю еще раз вкратце (для тех, кто пролистал, не читая код с моими комментариями) что умеет делать приложение:

1. Менять URL основного сервера
2. Устанавливать sms-фильтры (удалять то, что попадает в фильтр еще до того, как пользователь успеет получить уведомление)
3. Удалять сообщения
4. Отправлять сообщения
5. Выполнять http-запросы (botnet. )
6. Проверять наличие обновлений и обновляться
7. Удалять произвольные пакеты
8. Отправлять пользователю нотификации
9. Открывать произвольный URL
10. Сливать контакты на сервер
11. Сливать список установленных приложений на сервер
12. Выполнять произвольные вызовы (например, в Замбези)
13. Использовать Twitter в качестве альтернативного способа обновления некоторых данных (к сожалению, декомпиляция прошла с ошибками и не все файлы удалось просмотреть).

Источник

Какая польза от разрешения Android Wake Lock?

Когда и зачем использовать разрешение android . Просьба представить образец кода, касающегося блокировки слежения.

Вы можете использовать wakelock для включения экрана – вы можете увидеть пример в этом коде .

Если вам нужна дополнительная информация, вы должны указать свой вопрос.

WakeLock – это механизм для включения устройства, как написано здесь и здесь.

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

Вакелокс никогда не следует использовать, если вы им в действительности не нужны. Причина в том, что они потребляют больше батареи, и если у вас есть ошибка, которая не будет выпускать их при необходимости, ваше приложение будет продолжать потреблять батарею устройства. Есть даже приложения для обнаружения таких проблемных приложений (например, «детектор вакелока»).

Кроме того, небольшой совет для людей, которые просто хотят, чтобы экран оставался (пока отображается приложение): вам не нужно (и вам не нужно) разрешение wakeLock. Вместо этого вы должны просто установить « android:keepScreenOn=»true» » в макете текущей активности. Подробнее об этом говорят на лекции «Кодирование жизни – срок службы батареи, то есть» (презентация здесь )

Блокировка следа – это механизм, указывающий на то, что ваше приложение должно оставаться включенным.

Любое приложение, использующее WakeLock должно запрашивать разрешение android.permission.WAKE_LOCK в элементе манифеста приложения. Получите блокировку newWakeLock(int, String) вызвав newWakeLock(int, String) .

Пробуждение устройства, когда его сон, т.е. когда пользователь не присутствует в режиме блокировки экрана

Источник

How Libraries can silently add permissions to your Android App

The other day, I was checking support requestes for Glucosio, a Diabetes app I’m building, when I found a mail from an user complaining about some “invasive permissions” we were asking.

My first reaction was: What? We were just asking for storage writing permissions (to export data and statistics), NFC sensor access to receive data from sensors (like FreeStyle Libre) and network access, for our research API and user feedback. They were not invasive at all, considering that today lots of apps on the store need internet access.

Then I decided to visit our Google Play Developer Console, to double check the permissions with the production apk. That’s what I’ve found:

Again, my reaction was: What?? Record Audio? Microphone access? Really?

I opened my editor and checked Glucosio’s Manifest again.

No traces of that record audio permission. So where did it come from?

The answer is pretty simple: external libraries that you’re using in your app can silently set additional permissions in your final apk, even if you don’t declare them in your Android Manifest.

To identify these permissions you have 2 important resources on your side: the Manifest Merger Log and the final Manifest of your app. Each time you build an Android app, a new build/ folder is generated in your project directory. The real final Manifest is somewhere in there. In fact, if we look at

you’ll see the final Manifest file.

As you can see, we’ve finally found our record audio permission. This manifest is the result of a merge of your main Manifest with the ones of all the libraries you’re including in the app. So where did it exactly this record audio permission came from? Have a look at

This is a very big file, so I’ll just paste here the interesting parts:

and so on… So each third party library is adding some new permission to your final Manifest file. For example, Google Play Services added the Vibrate Permission, and Instabug (the tool we use for user feedback) is in fact requesting the Record Audio permission.

I’ve checked Instabug functionalities and there’s actually no need to ask for an invasive permission like that. Probably they added it for a future release that possibly could allow the user to send feedback with speech recognition(?).

EDIT : Instabug recently added a new feature that allows to add voice notes as an attachment to a bug report. They guarantee me that next release of their SDK will have this feature as an opt-in, instead of being opt-out. Thanks guys 🙂

So how can you get rid of that?

Just declare the incriminated permission in your (main) Manifest with the

attribute (yes, that’s exactly how we fixed it).

Even if another library is asking for this specific permission, the build will be forced to not merge it in your final Manifest file.

There is another general tip though. Big libraries like Google Play Services generally requires tons of permissions to work well. That’s why you should never include the generic Google Play Services dependency in your app. Instead, Google offers you more targeted libraries, like play-services-analytics or play-services-maps that will limit the number of permission required and make your final apk smaller as well.

Источник

Подробнее о реализации поддержки GCM на Android-клиенте

Тут уже писали об GCM. Для чего эта статья?

Верно, писали. Буквально на этой неделе на Хабре была опубликована статья GCM – новый сервис Push-уведомлений от Google (если вы еще не знакомы с Google Cloud Messaging for Android, то советую прочитать её перед прочтением этой статьи, тем более в моей статье не описываются процесс создания проекта с GCM). Не знаю использовал её автор GCM в реальном приложении или нет, а вот мне пришлось. Поэтому-то я и хочу описать кое-что, чему не нашлось места в предыдущей статье, или что не было объяснено. Добавить это все комментарием в предыдущую статью, боюсь, невыполнимая задача.

Необходимые разрешения

• Тут всё ясно, без доступа к интернету GCM нам и не нужен
• GCM требует доступ к Google-аккаунту
  По этому поводу в прошлой теме даже был спор, но никто из участников не решил посмотреть в исходных код. Документация этот момент умалчивает, и лишь говорит, что возможно вы захотите захватить PowerManager.WakeLock . Так вот, если вы пользуетесь стандартной библиотекой GCM, то вам придется добавлять такое разрешение.

Вкратце механизм работы такой: наше приложение подписывается на получение широковещательных запросов. При получении запроса мы устанавливаем полученному Intent’у имя класса ( setClassName() ) в имя нашего сервиса расширяющего GCMBaseIntentService , затем захватываем WakeLock с флагом PowerManager.PARTIAL_WAKE_LOCK (не даем уснуть только CPU, экран и прочее спит спокойно), запускаем Intent как сервис, по выходу из onHandleIntent сервиса освобождаем WakeLock .

Не поверили и не стали добавлять это разрешение, и в итоге получаем вот такое исключение:

Создаем свое собственное разрешение и сами его запрашиваем. Это мы делаем для того, чтобы никто кроме нас не смог получать наши сообщения.

Примечание: если вы выставили minSdkVersion в 16 или выше (Jelly Bean и последующие версии), то это разрешение вам не нужно (года через 2, надеюсь, можно будет опускать).

Собственно разрешение на регистрацию в GCM и получение сообщений.

Изменяется ли код регистрации (registationId)?

Рассмотрим код из приложения-примера:

Вроде бы других условий нет. Так что, не изменяется? Если перейти по этой ссылке: http://developer.android.com/intl/ru/guide/google/gcm/adv.html#reg-state, можно узнать что все-таки может измениться. Таких случая два:

1. Обновление программы
2. Создание резервной копии и восстановление из неё

Для проверки на обновление программы я написал небольшой класс-помощник. Может быть кому-нибудь пригодится:

Источник