Hide android что это

Для функционирования программы необходимы права root пользователя.

Краткое описание:
Скрытие любых значков с рабочего экрана, защита паролем для их восстановления.

Требуется Android: 2.3 и выше
Русский интерфейс: Нет

Сообщение отредактировал iMiKED — 03.08.21, 14:54

AppHider — Hide App только русская версия: 1.4.1 AppHider.Rus.apk ( 2.91 МБ )

Сообщение отредактировал papasha55 — 09.05.16, 19:33

Сообщение отредактировал dmitriy-inf — 18.05.16, 23:09

камрады, а есть ли аналогичное приложение, которое только скрывает иконки, не выключая приложение
например, есть приложение погода BZ. на рабочем столе висит виджет, но елси скрыть иконку приложения то виджет обновлять погоду
или ( в моем случае) есть во флайме приложение My Account, иконка на рабочем столе. если с помощью Hide App спрятать иконку то в аккаунт флайм из настроек телефона мне не войти уже. в случае с погодой это совсем неудобно — нужно зайти в hide app, нажать unhide and start и олько тогда можно обновить погоду

в твиках xposed для miui есть такая возможность. твиках для flyme — не нашел (
может порекомендуете альтернативу Hide app

Источник

Вирус Android.HiddenAds.256

#1 radomir74

Members

1 Сообщений:

Не могу удалить вирус Android.HiddenAds.256 находится по адресу /system/CDA/items/com.aptoide.partners.id3_store/com.aptoide.partners.id3_store.apk

Вирус ли это или ложное срабатывание? Телефон Nokia 6. Система — Android 8.0

#2 Lvenok

Beta Testers

2 380 Сообщений:

Не могу удалить вирус Android.HiddenAds.256 находится по адресу /system/CDA/items/com.aptoide.partners.id3_store/com.aptoide.partners.id3_store.apk
Вирус ли это или ложное срабатывание? Телефон Nokia 6. Система — Android 8.0

#3 I.Zhilyakov

Virus Analysts

59 Сообщений:

Добрый день, это не ложное срабатывание.

Удалить его можно при наличии root прав (влечет возможную потерю гарантии) , либо откатившись на предыдущую версию прошивки.

Так же рекомендуем обратиться к производителю устройства за дополнительной информацией об этом приложении.

#4 den_204

Posters

8 Сообщений:

В телефоне появился вирус Android.HiddenAds.256 расположенный: storage/sdcard1/Android/data/com.redbend.dmClient/cache/push/auto01.fotapro.net_files_f2c1954ec750bd5b64a5012022de89fc/

Dr.web не удаляет и не переносит в карантин. Что делать? Помогите, пожалуйста.

Каждый день подключается какая-то платная услуга. Приходит смс уведомление. Отключение услуги не помогает.

И еще один вирусAndroid.Gmobi.1 расположение /system/app/DMClient.apk.

Вирус не удаляется. Только карантин.

#5 phantom83

Posters

640 Сообщений:

Удалить его можно при наличии root прав (влечет возможную потерю гарантии), либо откатившись на предыдущую версию прошивки.
Так же рекомендуем обратиться к производителю устройства за дополнительной информацией об этом приложении.

#6 den_204

Posters

8 Сообщений:

Удалить его можно при наличии root прав (влечет возможную потерю гарантии), либо откатившись на предыдущую версию прошивки.
Так же рекомендуем обратиться к производителю устройства за дополнительной информацией об этом приложении.

Откат что влечет за собой? Аккаунт удалится?

#7 den_204

Posters

8 Сообщений:

Возврат к заводским настройкам решит данную проблему?

Как выяснилось откатывать я не умею, root права — я вообще понятия не имею, что это и как оно работает )

#8 phantom83

Posters

640 Сообщений:

Под откатом на предыдущую версию прошивки подразумевается смена прошивки либо при помощи ПК или средствами самой ОС если это предусмотрено производителем.

А какой аппарат и версия ПО?

#9 den_204

Posters

8 Сообщений:

Источник

Работаем с USB Custom HID на Android

В современных Android — приложениях для взаимодействия с другими устройствами чаще всего используются беспроводные протоколы передачи данных, как например Bluetooth. В годы, когда часть устройств имеют беспроводную зарядку, сложно представить себе связку Android устройства и периферийного модуля, в которой необходимо использование проводных интерфейсов. Однако когда такая необходимость возникает, на ум сразу же приходит USB.

Давайте разберем с вами гипотетический кейс. Представьте, что к вам приходит заказчик и говорит: “Мне нужно Android приложение для управления устройством сбора данных и вывода этих самых данных на экран. Есть одно НО — приложение надо написать на одноплатный компьютер с операционной системой Android, а периферийное устройство подключено по USB”

Звучит фантастически, но и такое иногда случается. И тут как нельзя кстати пригодится глубокое знание USB стека и его протоколов, но данная статья не об этом. В данной статье мы рассмотрим, как управлять периферийным устройством по протоколу USB Custom HID с Android устройства. Для простоты напишем Android-приложение (HOST), которое будет управлять светодиодом на периферийным устройством (DEVICE) и получать состояние кнопки (нажатия). Код для периферийной платы приводить не буду, кому интересно — пишите в комментариях.

Читайте также: Android sdk jdk error

Итак, приступим.

Теория. Максимально коротко

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

Для общения по USB на периферийном устройстве необходимо реализовать интерфейс взаимодействия. Разные функции (например, USB HID, USB Mass Strorage или USB CDC) будут реализовывать свои интерфейсы, а некоторые будут иметь несколько интерфейсов. Каждый интерфейс содержит в себе конечные точки — специальные каналы связи, своего рода буферы обмена.

На моем периферийном устройстве реализован Custom HID с одним интерфейсом и с двумя конечными точками, одной для приёма, другой для передачи. Обычно информация с существующими на устройстве интерфейсами и конечными точками написана в спецификации на устройство, в противном случае определить их можно через специальные программы, к примеру USBlyzer.

Устройства в USB HID общаются через репорты. Что такое репорты? Так как данные передаются через конечные точки, то нам надо как-то идентифицировать, а также распарсить в соответствие с протоколом. Устройства не просто кидают друг другу байты данных, а обмениваются пакетами, имеющими четко определенную структуру, которая описывается на устройстве в специальном дескрипторе репорта. Таким образом, по дескриптору репорта, мы можем точно определить, какой идентификатор, структуру, размер и частоту передачи имеют те или иные данные. Идентификация пакета происходит по первому байту, который представляет из себя ID репорта. Например данные о состоянии кнопки, идут в репорта с а светодиодом мы управляем через репорт с >

Подальше от железа, поближе к Android

В Android поддержка USB устройств появилась начиная с API версии 12 (Android 3.1) Для работы с периферийным устройством нам необходимо реализовать режим USB host. Работа с USB достаточно неплохо описана в документации.

Для начала необходимо идентифицировать ваше подключаемое устройство, среди всего разнообразия USB девайсов. USB девайсы идентифицируются по сочетанию vid (vendor id) и pid (product id). Создадим в папке xml файл device_filter.xml со следующим содержимым:

Теперь необходимо внести соответствующие разрешения и action (если вам они необходимы) в манифест приложения:

В android:resource мы указываем файл с необходимыми фильтрами для устройств. Также, как я уже говорил ранее, можно назначить intent фильтры, для запуска приложения, к примеру, в результате подключения вашего устройства.

Для начала необходимо получить UsbManager, найти устройство, интерфейс и конечные точки устройства. Это необходимо делать при каждом подключении устройства.

Здесь мы видим те самые интерфейсы и конечные точки, речь о которых шла в прошлом разделе. Зная номер интерфейса, мы находим обе конечные точки, на прием и передачу, и инициируем usb соединение. На этом все, теперь можно читать данные.

Как я уже говорил ранее, устройства общаются через репорты.

В метод sendReport мы передаем массив байт, в котором нулевым байтом является репорт ID, берем текущее USB подключение к устройству и выполняем передачу. В качестве параметров в метод BulkTransfer передаем номер конечной точки, данные, их размер и таймаут передачи. Стоит отметить, что класс UsbDeviceConnection имеет методы для реализации обмена данными с устройством USB — методы bulkTransfer и controlTransfer. Их использование зависит от типа передачи, который поддерживает та или иная конечная точка. В данном случае используем bulkTransfer, хотя для HID чаще всего характерно использование конечных точек с типом control. Но у нас Custom HID, так что делаем что хотим. Про тип передачи советую почитать отдельно, так как от него зависит объем и частота передаваемых данных.

Для получения данных необходимо знать размер получаемых данных, который можно, как знать заранее, так и получить из конечной точки.

Метод получения данных по USB HID является синхронным и блокирующим и выполнять его необходимо в другом потоке, кроме того, репорты от устройства могут приходить постоянно, либо в любое время, поэтому необходимо реализовать постоянный опрос репорта, чтобы не пропустить данные. Сделаем это при помощи RxJava:

Получив массив байт, мы должны проверить нулевой байт, так как он является report ID и в соответствии с ним парсить полученные данные.

По завершении всех действий с USB нужно закрыть соединение. Можно выполнять это в onDestroy activity или в onCleared во ViewModel.

Заключение

В статье рассмотрен очень небольшой и примитивный, исключительно демонстративный код с реализацией для конкретного устройства. Конечно, классов USB существует много, не только HID и для них естественно реализация будет иная. Однако все методы достаточно неплохо документированы и имея хорошее представление о USB стеке можно легко разобраться в том, как их применять.

Источник

6 способов спрятать данные в Android-приложении

Привет, дорогой читатель, уже достаточно давно я изучаю мобильные приложения. Большинство приложений не пытаются как-то скрыть от меня свой «секретный» функционал. А я в это время радуюсь, ведь мне не приходится изучать чей-то обфусцированный код.

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

Под обфускацией в рамках этой статьи будем понимать приведение исполняемого кода Android-приложения к трудному для анализа виду. Существует несколько причин затруднять анализ кода:

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

Многие разработчики решают проблему простым форком конфига ProGuard. Это не лучший способ защиты данных (если вы первый раз слышите об этом, то см. вики).

Хочу привести показательный пример, почему предполагаемая “защита” с помощью ProGuard не работает. Возьмем любой простенький пример из Google Samples.

Подключив к нему ProGuard со стандартным конфигом, получим декомпилированный код:

«Ооо, ничего непонятно» – скажем мы и успокоимся. Но через пару минут переключения между файлами найдём подобные кусочки кода:

В этом примере код приложения выглядит затрудненным довольно слабо (логирование данных, создание видео захвата), поэтому некоторые методы, использованные в оригинальном коде, легко понятны и после обработки конфигом ProGuard.

Дальше больше, взглянем на data-классы в Kotlin. Data-класс по умолчанию создает метод “toString”, который содержит в себе названия переменных экземпляра и название самого класса.

Он может превратиться в лакомый кусочек для реверсера:

(автогенерация метода toString в Kotlin)

Выясняется, что ProGuard прячет далеко не весь исходный код проекта.

Если я все еще не убедил вас в нецелесообразности защиты кода таким способом, то давайте попробуем оставить в нашем проекте атрибут “.source”.

Эта строчка есть во многих opensource проектах. Она позволяет просматривать StackTrace при падении приложения. Однако, вытащив “.source” из smali-кода, мы получим всю иерархию проекта с полными названиями классов.

По определению, обфускация – это “приведение исходного кода в нечитаемый вид для того, чтобы противодействовать разным видам ресерча”. Однако, ProGuard (при использовании со стандартным конфигом) не делает код нечитаемым – он работает как минификатор, сжимающий названия и выкидывающий лишние классы из проекта.

Такое использование ProGuard – это легкое, но не совсем подходящее для хорошей обфускации решение на ”авось”. Хорошему разработчику нужно заставить ресерчера (или злоумышленника) испугаться “китайских символов”, которые трудно деобфусцировать.

Если вам интересно подробнее узнать про ProGuard, то предлагаю следующую познавательную статью.

Что прячем

Теперь давайте посмотрим, что обычно прячут в приложениях.

Специфическую логику приложения:

В коде часто может быть спрятано что-то более неожиданное (наблюдения из личного опыта), например:

Имена разработчиков проекта
Полный путь к проекту
“client_secret” для протокола Oauth2
PDF-книга “Как разрабатывать под Android” (наверное, чтобы всегда была под рукой)

Теперь мы знаем, что может прятаться в Android-приложениях и можем переходить к главному, а именно к способам сокрытия этих данных.

Способы сокрытия данных

Вариант 1: Ничего не скрывать, оставить все на виду

В таком случае я просто покажу вам эту картинку 🙂

“Помогите Даше найти бизнес-логику”

Это нетрудозатратное и совершенно бесплатное решение подойдет для:

Простых приложений, которые не взаимодействуют с сетью и не хранят чувствительную пользовательскую информацию;
Приложений, которые используют только публичное API.

Вариант 2: Использовать ProGuard с правильными настройками

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

Однако, нужно понимать, что такое решение после каждой сборки требует от разработчика декомпиляции и проверки, все ли нормально. Потратив несколько минут на изучение APK файла, разработчик (и его компания) могут стать увереннее в безопасности своего продукта.

Проверить приложение на наличие обфускации достаточно просто.

Для того, чтобы достать APK-файл из проекта существует несколько путей:

взять из директории проекта (в Android Studio обычно название папки “build”);
установить приложение на смартфон и достать APK с помощью приложения “Apk Extractor”.

После этого, пользуясь утилитой Apktool, получаем Smali-код (инструкция по получению здесь https://ibotpeaches.github.io/Apktool/documentation) и пытаемся найти что-нибудь подозрительно читаемое в строках проекта. Кстати, для поиска читаемых кодов можно запастись уже заранее готовыми bash-командами.

Это решение подойдет для:

Приложений игрушек, приложений интернет-магазинов и т.п.;
Приложений, которые действительно являются тонкими клиентами, и все данные прилетают исключительно с серверной стороны;
Приложений, которые не пишут на всех своих баннерах “Безопасное приложение №1”.

Вариант 3: Использовать Open Source Obfuscator

К сожалению, реально хороших бесплатных обфускаторов для мобильных приложений я не знаю. А обфускаторы, которые можно найти в сети могут принести вам много головной боли, поскольку собрать такой проект под новые версии API будет слишком сложно.

Исторически сложилось, что существующие крутые обфускаторы сделаны под машинный код (для C/C++). Хорошие примеры:

Например, Movfuscator заменяет все opcodes mov-ами, делает код линейным, убирая все ветвления. Однако, крайне не рекомендуется использовать такой способ обфускации в боевом проекте, потому что тогда код рискует стать очень медленным и тяжелым.

Это решение подойдет для приложений, у которых основная часть кода — NDK.

Вариант 4: Использовать проприетарное решение

Это самый грамотный выбор для серьезных приложений, так как проприетарное ПО:
а) поддерживается;
б) всегда будет актуально.

Пример обфусцированного кода при использовании таких решений:

В этом фрагменте кода можно увидеть:

Максимально непонятные названия переменных (с наличием русских букв);
Китайские символы в строчках, не дающие понять, что реально происходит в проекте;
Очень много добавленных в проект ловушек (“switch”, “goto”), которые сильно меняют codeflow приложения.

Это решение подойдет для:

Банков;
Страховых компаний;
Мобильных операторов, приложений для хранения паролей и т. д.

Вариант 5: Использовать React-Native

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

Кроме очень большого community, JS имеет очень большое количество открытых обфускаторов. Например, они могут превратить ваше приложение в смайлики:

Мне бы очень хотелось посоветовать вам данное решение, но тогда ваш проект будет работать самую малость быстрее черепахи.

Зато, уменьшив требование к обфускации кода, мы можем создать действительно хорошо защищенный проект. Так что гуглим “js obfuscator” и обфусцируем наш выходной bundle-файл.

Это решение подойдет для тех, кто готов писать кроссплатформенное приложение на React Native.

Было бы очень интересно узнать про обфускаторы на Xamarin, если у вас есть опыт их использования – расскажите, пожалуйста, о нем в комментариях.

Вариант 6: Использовать NDK

Мне самому часто приходилось использовать NDK в своем коде. И я знаю, что некоторые разработчики считают, что использование NDK спасает их приложение от реверсеров. Это не совсем так. Для начала нужно понять, как именно работает сокрытие с помощью NDK.

Оказывается, очень просто. В коде есть некоторая JNI-договоренность, что при вызове C/C++ кода в проекте он будет преобразовываться следующим образом.

Нативный класс NativeSummator:

Реализация нативного метода sum:

Реализация нативного статичного метода sum:

Cтановится понятно, что для вызова нативного метода используется поиск функции Java_

_ _ в динамической библиотеке.

Если заглянуть в Dalvik/ART код, то мы найдём следующие строки:

Сначала сгенерируем из Java-объекта следующую строку Java_

_ _ , а затем попытаемся разрезолвить метод в динамической библиотеке с помощью вызова “dlsym”, который попытается найти нужную нам функцию в NDK.

Так работает JNI. Его основная проблема в том, что, декомпилировав динамическую библиотеку, мы увидим все методы, как на ладони:

Значит, нам нужно придумать такое решение, чтобы адрес функции был обфусцирован.

Сначала я пытался записать данные напрямую в нашу JNI-таблицу, но, понял, что механизмы ASLR и разные версии Android просто-напросто не позволят мне сделать этот способ работающим на всех устройствах. Тогда я решил узнать, какие методы NDK предоставляет разработчикам.

И, о чудо, нашелся метод “RegisterNatives”, который делает ровно то, что нам нужно (вызывает внутреннюю функцию dvmRegisterJNIMethod).

Определяем массив, описывающий наш нативный метод:

И регистрируем наш объявленный метод в функции JNI_OnLoad (метод вызывается после инициализации динамической библиотеки, тыц) :

Ура, мы самостоятельно спрятали функцию “hideFunc”. Теперь применим наш любимый llvm-обфускатор и порадуемся безопасности кода в конечном виде.

Это решение подойдет для приложений, которые уже используют NDK (подключение NDK несет в проект большое количество сложностей, поэтому для не-NDK приложений это решение не так актуально).

Вывод

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

Я считаю, что обфускация – важная структурная часть любого современного приложения.

Обдуманно подходите к вопросам сокрытия кода и не ищите простых путей! 🙂

Кстати, спасибо пользователю miproblema за помощь в некоторых вопросах. Подписывайтесь на ее телеграм-канал, там интересно.

А так же огромное спасибо пользователям sverkunchik и SCaptainCAP за помощь в редактировании статьи.

Источник