Мы используем ProGuard для обфускации кода, но он не скрывает жестко запрограммированные строки, присутствующие в коде. Он изменяет имена классов, имена методов и имена переменных, но не значения переменных. Здесь проблема начинается, потому что любой может реконструировать apk и получить файлы java. Даже если код запутан, это просто затрудняет его чтение людьми. Путем поиска в двойных кавычках («») любой может получить все жестко запрограммированные строки, присутствующие в коде.
Многие разработчики сталкиваются с этой проблемой, потому что им приходится жестко кодировать некоторые строки в процессе разработки. Так что есть много способов решить эту проблему.
- Использование алгоритма шифрования:
Это один из простейших подходов к решению этой проблемы. Мы используем алгоритм шифрования, например Цезарь шифр. Мы шифруем строковые литералы и жестко кодируем зашифрованное значение в коде. Перед использованием во время выполнения мы расшифровываем значение, используя тот же алгоритм.
Недостаток: главный недостаток этого метода - хакеры могут легко расшифровать зашифрованную строку и получить исходное значение. Другая проблема заключается в том, что запутанный код алгоритма дешифрования можно понять с некоторыми усилиями.
2. Использование шифрования по умолчанию для Android
Другой подход к решению этой проблемы - использование алгоритмов платформы по умолчанию, например. SHA-1, MD-5 и др.
Недостаток: главный недостаток этого подхода заключается в том, что у нас должен быть хотя бы ключ для шифрования и дешифрования (будь то алгоритм шифрования по умолчанию для платформы или ваш собственный алгоритм). Этот ключ жестко запрограммирован где-то внутри кода. Хакеру это легко достать, так как запутанный код сложно понять.
3. Использование сторонней библиотеки
Следующий подход заключается в использовании внешних библиотек, таких как Dex-Gaurd, Stringer и т. Д. В настоящее время эти библиотеки надежны, и большинство крупных компаний используют их.
Недостаток: большинство этих библиотек являются коммерческими. Однако это постоянная гонка между людьми, пытающимися скрыть код, и взломщиками. они могут взять на себя вашу ношу, но рано или поздно они, скорее всего, также будут реконструированы.
Все вышеперечисленные методы являются традиционными решениями, но ни один из них полностью не скрывает жестко запрограммированные строковые литералы. нашел решение этой проблемы.
Мы можем использовать код c / c ++ для решения этой проблемы. Я продолжаю определять свои строковые литералы в файлах c / c ++ и строю с использованием NDK, который строит файлы .so. Ниже приведен пример.
Я создаю файл constant.c в папке jni параллельно с папкой java и добавляю файл .mk для NDK.
jstring BASE_URL_PROD = "https://abcd.com/";
JNIEXPORT jstring JNICALL
Java_com_dunzo_utils_JniHandler_getProdBaseUrl(JNIEnv *env, jobject instance) {
return (*env)->NewStringUTF(env, BASE_URL_PROD);
}
используя «ndk-build», я получаю файлы .so, которые мы храним в папке lib.
Чтобы связать это с Java-кодом, мы должны загрузить файл внутри библиотеки, используя
System.loadLibrary(“<lib-module name>”);
и, в конце концов, я пишу нативную java-функцию для подключения кода библиотеки к java-коду.
public native String getProdBaseUrl();
Теперь я могу вызвать этот метод, используя его объект, и перейду к строке, жестко закодированной в файле c.
Мораль истории…
Итак, если вы хотите сохранить голые строки в коде внешнего интерфейса, существуют методы их получения. Методы могут сделать его сложным, но это буквальная игра в кошки-мышки. Чем лучше метод вы потратите, тем больше времени вы его взломаете.
