В нативе я попробую получать этот хеш. Может, и проверять там буду.

Проверять надо обязательно в нативе, иначе проверку очень легко снять

Вообще основа защиты в проверке сертификата. Если он будет совпадать с оригиналом, то защита просто не сработает. Поэтому нужно, чтобы оригинальное приложение было перепаковано.

Жаба реверсится прям совсем хорошо

Информацию о подписи приложении тоже норм проверять, да

А либы скомпилированные разве нет? Выше написали, что легко подменить строку. Они могут подсунуть строку с сертификатом (ну хешем его верным) и всё.

Другое дело, что изменить код java и собрать apk можно за несколько минут.

А вот это уже не относится к чату.

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

ок. Спасибо за ответы.

Яву прям в кучу раз проще реверсить. Они практически до исходного состояния декомпилится, и smali ну очень высокий

Все, все, никакого оффтопа

Я вот ещё читал где-то, что для защиты (там было про защиту программ на ПК) вставляют ассемблерные вставки в код на C/C++. Интересно, что можно такого написать, чтобы это вызвало сложности при изучении дизассемблированного кода?

Например, логика может храниться в зашифрованном виде, и только в раму распаковаться. Типа upx

Есть разные приёмы защиты (и взлома). Чем они сложнее, тем меньше будет людей умеющих/желающих их сломать. Тем не менее, нужно понимать, что неломаемых защит нет, сломать можно всё, это надо понять (и простить). Вопрос в целесообразности. Если цена проги $1, а защита очень сложая, проще купить. Если ориентироваться на зарубежный рынок, там куда чаще покупают, чем ломают, нежели у нас.

Что касается ассемблерных вставок на C/C++, то можно и без них много чего сделать (а асм заменить интринсиками, когда очень надо, например).

Взлом/защита — это не такая тема, которую можно рассказать за 15 минут.

Пофантазируем. Я не очень шарю в мобайле, но подозреваю, что там всё примерно так же, как в x86/Windows.

Вот ты будешь шифровать весь файл, но опять же, каким алгоритмом и где ты будешь хранить ключ? Да и потом, крякер может расшифровать файл (например, отладчиком) и дальше пошёл стандартный крякинг.

Может возникнуть вопрос: чтобы крякнуть и сохранить крякнутый код, нужно же зашифровать его, что при сложном и нестандартном алгоритме шифрования довольно геморно? Необязательно. Можно пропатчить стандартный дешифровщик так, что он будет менять нужные байты после расшифровки. Либо он не будет расшифровывать, а будет тупо копировать код, который будет храниться сразу расшифрованным :)

Но в любом случае, лучше зашифроваться, т.к. это по крайней мере, усложнит крякинг и отпугнёт приличное кол-во кулхацкеров :)

«Что можно такого написать, чтобы вызывать сложности?»

Обычно это антиотладочные приёмы, которые приводят либо в крэшу/зависанию/выходу, либо к неправильному поведению (например, файл неправильно расшифровался). Но современные крякерские средства умеют обнаруживать и правильно работать со многими такими приёмами. Антиантиотладка, так сказать :). Но опять же, это умеют не все. Какой-то % отвалится.

Это какие средства? Ида, и гидра по-моему не могли такие штуки детектить автоматически

Какие «такие»? Скажем, IsDebuggerPresent легко перехватывается и выдаёт нужный результат (есть какие-то плагины под Олю, к примеру).

привет