Android-приложение не должно работать на рутированных устройствах - PullRequest
8 голосов
/ 22 января 2011

Я пишу приложение, которое не должно работать на рутированных устройствах. Я хочу сохранить некоторые защищенные данные, что возможно только на устройствах без прав доступа, поскольку никто не может получить доступ к файлам в / data / data / package-name .

Кто-нибудь знает:

1) Можно ли предотвратить установку приложения на рутированных устройствах? Я читал кое-что о «механизме защиты от копирования» в Android Market. Эта функция устарела и заменена функцией лицензирования. Однако лицензирование возможно только для платного приложения, а мое бесплатное ...

2) Можно ли программно проверить, является ли устройство рутованным или нет? Если бы это было возможно, я мог бы просто остановить приложение, если устройство рутировано.

Любая помощь по этой теме приветствуется!

Ответы [ 7 ]

9 голосов
/ 22 января 2011

Выполнить

Runtime.getRuntime().exec("su");

и проверить код результата.

Другими словами, если вы можете выполнить su, то у вас есть root-доступ.не имеет значения, если пользователь разрешает или отрицает это, у вас есть свой ответ.

6 голосов
/ 22 января 2011

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

Если вы заботитесь о безопасности данных, не помещайте их на устройство.Поскольку Android является сетевым устройством (да, я знаю, это субъективно, но изначально оно было разработано и позиционировано как таковое), доступ к данным в Интернете не является редкостью.

4 голосов
/ 14 мая 2013

Что я бы сказал, это запустить su и затем проверить вывод. Если пользователь разрешает вашему приложению иметь root, используйте root для удаления своего собственного приложения (одним из способов может быть помещение скрипта в init.d и принудительная перезагрузка).

Если пользователь НЕ разрешает запускать ваше приложение от имени пользователя root, то:

  1. Они ОТКЛОНЕН разрешения вашего приложения.
  2. Они не рутированы.

Теперь отказ в разрешениях (и root) означает, что у них есть какое-то приложение управления SUPERUSER, и вот тут-то и появится следующая часть.

Затем я бы использовал PackageManager для получения списка всех пакетов, а затем проверил их по нескольким доступным приложениям управления SuperUser, а именно Koush, ChainsDD и Chainfire

Соответствующие имена пакетов:

  1. com.noshufou.android.su
  2. eu.chainfire.supersu
  3. com.koushikdutta.superuser
3 голосов
/ 30 мая 2014

Используйте те методы, которые помогут вам проверить наличие root

public static boolean findBinary(String binaryName) {
        boolean found = false;
        if (!found) {
            String[] places = { "/sbin/", "/system/bin/", "/system/xbin/",
                    "/data/local/xbin/", "/data/local/bin/",
                    "/system/sd/xbin/", "/system/bin/failsafe/", "/data/local/" };
            for (String where : places) {
                if (new File(where + binaryName).exists()) {
                    found = true;

                    break;
                }
            }
        }
        return found;
    }

    private static boolean isRooted() {
        return findBinary("su");
    }

Теперь попробуйте проверить, рутировано ли устройство.

if (isRooted() == true){
//Do something to prevent run this app on the device

}
else{
//Do nothing and run app normally
}

Например, вы можете принудительно остановить приложение, еслиустройство рутировано

3 голосов
/ 23 января 2011

Если вы пытаетесь защитить данные для пользователя, их дело беспокоиться о других приложениях.Если вы пытаетесь защитить данные от пользователя, какие у вас дела, когда вы помещаете их на свое устройство?

Чтобы ответить на ваш вопрос, они контролируют машину, поэтому ожидайте, что онибыть в состоянии перехватить любой вызов API, проверяющий "Это укоренено?"и врать тебе.Вместо этого зашифруйте данные на клиенте с помощью ключа, известного клиенту, но сделайте неочевидным, где и как вы это делаете.Как правило, делайте вещи раздражающими для тех, кто ищет.

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

Не боритесь против свободы - зачем вам вообще отказывать клиентам в бесплатных устройствах?- вместо этого, если вы хотите получить конкретный результат, сделайте так, чтобы «Получить данные»> «Значение получения данных».Тогда этого не произойдет.Если вы действительно должны иметь надежную защиту, сохраняйте данные на стороне сервера.

0 голосов
/ 07 июня 2017

1) нет. как бы вы отрицали установку? почему рутированное устройство отказывает в установке чего-либо, что пользователь хочет установить на fs? В этом и заключается смысл рутирования: вы можете заставить устройство делать все, что угодно.

2) нет. не для ваших целей. Вы можете проверить, можете ли вы получить root для своего приложения обычными методами. так что вы можете проверить положительный результат, но вы не можете программно доказать, что он не рутирован из вашего приложения.

также, что вы спрашиваете, можете ли вы создать идеальную систему защиты от копирования drm - вы также можете упустить момент, когда пользователь может изменить ваше приложение, удалив вашу корневую проверку. если у вас есть какая-то контрольная сумма / контрольная сумма, пользователь также может подделать результат.

0 голосов
/ 08 апреля 2012

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

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

...