Безопасно подписываем Android сборки из Jenkins

[akadone]

Это всё конечно безумно интересно, но есть ли возможность какого-то практического применения этой подписи? Например для защиты приложения от изменения? Только без этих всяких «мы ща обратимся к java… что бы проверить...» это бред. Что-то реальное?

[juztoss]

Она везде практически применяется. И защищает приложение от изменения. Изменить что-то в подписанном файле уже не получится. Соответсвенно не получится, например, добавить какой-то код чтобы следить за пользователем в приложение известной социальной сети и установить его не приложение жертвы. За подленностью сертификата и подписанного им кода будет следить система Android, которая в итоге и не даст изменённое приложение запустить.

[akadone]

Это известная рекламная телега от гугла, которая ни как не связана с реалиями. Ведь если бы это было так, то не наводнили 4пда и прочие сайты взломанные версии ПО с гугльплея.
У меня тот же скайп в телефоне мало того, что отвязан от рекламы, да ещё добавлены ништяки типа кнопки выхода, которых в оригинальной версии нет.
Понятно, что если писать проверку подписи на интерпретируемых языках, то любой школьник её может убрать за пол часа. Что бы проверить целостность apk нужно писать проверку на c++ иди Delphi. Но всё равно этот код обращается к функциям ОС через java прослойку, которую не сложно изменить, и возвращать требуемое значение, а не реальное. Вот мне и интересно: есть ли способы борьбы с этим — что бы ndk обращалось к ос непосредственно, а не через Dalvik/ART. Что бы хоть кулхацкеров отсеять.

[juztoss]

Всё дело в том, что Android в принципе разрешает ставить приложения из сторонних источников. Чтобы это убрать нужно делать как на iOS, но я до конца не знаю как там всё устроено. Во всяком случае как раз таки jailbreak ломает проверку устанавливающихся приложений.

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

[punksta]

В общем случае нет. Вы можете запутывать (obfuscate) код в том числе код проверки подписи приложния. Есть dexguard, например. Еще можете реализовать проверку лицензии developer.android.com/google/play/licensing/overview.html. Последняя выполняется с помощью google play services, в другом процессе. Конечно можно декомпильнуть и вырезать эти проверки, но тогда часть функционала приложения(платные фичи) могут перестать работать. И каждый новый релиз придется взламывать заново. В итоге забивают на часть юзеров, что юзает 4пда.

[akadone]

Обфускация — это лишь замена настоящих названий функций/переменных на слабо воспринимаемое человеком. Плюс запутывание кода. Она полезна для защиты от читеров в играх, но обращения к api запутать нельзя.
Вот хочу я, например, показать баннер. За это отвечает пара классов. Взломщик их просто вычищает, не разбираясь с хитросплетениями запутанного кода. Тоже самое с вызовом проверки лицензии, или проверки подписи. Надо просто вызов функции одного класса заменить на вызов другого. Время работы взломщика увеличится минут на 20, не более.
Поэтому было бы интересно подобные вещи опустить на уровень ndk, который полезет не к java-прослойке, а сразу к api OS. Специалистов, которые поломают .so на много порядков меньше, чем школьников, которые могут поменять пару байт в интерпретируемом языке.

[punksta]

Пишите под ios)

[kolipass]

Можно запутать обращение к api:

• весь трафик пускаем по доверенному каналу;
• модуль api шифруем и загружаем через кастомный класслоадер;
• ключ от шифрованного блока можно запрятать с помощью стеганографии

либо

• сгенерировать открытый\закрытый ключ, обменяться с сервером по доверенному каналу связи и каждый раз получать новый, зашифрованный открытым ключём блок с модулем api.

[MikailBag]

Нет.
При желании, программу на любом языке можно защитить, например, засунув в виртуалку.
Единственный вопрос — в скорости (медленности)) работы защиты.

[akadone]

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

[MikailBag]

1) Пишем код на C++.
2) Накатываем Denuvo или что там сейчас модно)
3) Пишем на Java симулятор процессора.
4) PROFIT — Java-прослойку ломать бессмысленно (сломается примерно все приложение).

[akadone]

API всё равно на Java. Всё равно из этой «коробочки» будут вызовы понятных вещей. Максимум можно обфускацировать этот «симулятор процессора», но всё равно всё сведётся к замене пары байт обращения к api, только байты будут не стандартные. Ну потратит человек 2 вечера, а не пол часа как в других случаях. И опять написать защиту будет дольше, чем её сломать.

[kolipass]

Почему нет, вполне себе существует очень простой вариант проверить текущие сигнатуры (подписи):

Signature[] signatures = getPackageManager().getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNATURES).signatures;
    for (Signature signature : signatures) {
        // checkig
    }

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

[amarao]

У jenkins есть система управления credentials. С андроидными подписями я не сталкивался, а всё остальное, что мы делаем, идёт либо через inject environment variables, либо через ssh-ключи на слейвы, которые могут что-то делать (например, подписывать пакеты).

Вообще, если говорить про сертификаты, то логично, чтобы jenkins всего лишь делал request, а сертификат ему делал сторонний CA.

[ivan2kh]

Мне нравится идея выдавать Jenkins временный токен для отдельного сервера подписывания.