Комментарии 14
Т.е. эта штука за 150$ только строки шифрует?
А dex2jar падает — это не показатель, его пофиксят.
А dex2jar падает — это не показатель, его пофиксят.
Все верно. Я писал в этом контексте на StackOverflow: stackoverflow.com/a/10137205/1398289.
Кратко: большая часть логики содержится в строках, в подавляющем большинстве приложений мы не используем секретные алгоритмы, которые нам нужно было бы защищать, т.о. строки — самое уязвимое место.
Цена здесь, как ни странно, не является определяющим фактором, но тем не менее: можно использовать Stringer + ProGuard за 150$ или другой схожий по возможностям продукт, который будет стоить минимум 300$ (Allatori например).
Пофиксят — поменяем алгоритм.
Кратко: большая часть логики содержится в строках, в подавляющем большинстве приложений мы не используем секретные алгоритмы, которые нам нужно было бы защищать, т.о. строки — самое уязвимое место.
Цена здесь, как ни странно, не является определяющим фактором, но тем не менее: можно использовать Stringer + ProGuard за 150$ или другой схожий по возможностям продукт, который будет стоить минимум 300$ (Allatori например).
Пофиксят — поменяем алгоритм.
Actually Strings is about 50-80% of logic of our applications.
Это вы как так посчитали?
А как вообще дела обстоят с потерей производительности? Все-таки строки приходится расшифровывать в рантайме.
Это вы как так посчитали?
Отношение Constant Pool к общему размеру class-файла.
Например, аналогичные выкладки от University of Victoria, Canada:
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.3939&rep=rep1&type=pdf — раздел 2.1
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1.2047&rep=rep1&type=pdf — раздел «DEVELOPING A TAILORED SOLUTION FOR JAVA CLASS FILES»
А как вообще дела обстоят с потерей производительности? Все-таки строки приходится расшифровывать в рантайме.
Если не шифровать всё подряд — можно свести потери на нет, а если в цикле складывать миллион строк, то, соответственно, ничего хорошего не получится.
Мы используем AES с максимальным развернутым S-box, и для еще большей оптимизации в качестве входного блока мы используем char, не производя конвертацию в байты туда и обратно.
Отношение Constant Pool к общему размеру class-файла.
Например, аналогичные выкладки от University of Victoria, Canada:
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.3939&rep=rep1&type=pdf — раздел 2.1
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1.2047&rep=rep1&type=pdf — раздел «DEVELOPING A TAILORED SOLUTION FOR JAVA CLASS FILES»
А как вообще дела обстоят с потерей производительности? Все-таки строки приходится расшифровывать в рантайме.
Если не шифровать всё подряд — можно свести потери на нет, а если в цикле складывать миллион строк, то, соответственно, ничего хорошего не получится.
Мы используем AES с максимальным развернутым S-box, и для еще большей оптимизации в качестве входного блока мы используем char, не производя конвертацию в байты туда и обратно.
Ага, ну так понятнее, вы просто считаете, что constant pool — это «logic of our applications» :) Мне кажется, что логика приложения — это все-таки оставшиеся 20-50%, которые приходятся в class-файлах на методы.
Если в цикле складывать миллион строк — то ничего хорошего не получится и без волшебного Stringer Java Obfuscation Toolkit :)
Так а конкретных цифр для Dalvik у вас нет? Есть ли разница между Dalvik и JVM? Все-таки в dex пул констант общий.
Если в цикле складывать миллион строк — то ничего хорошего не получится и без волшебного Stringer Java Obfuscation Toolkit :)
Так а конкретных цифр для Dalvik у вас нет? Есть ли разница между Dalvik и JVM? Все-таки в dex пул констант общий.
И еще небольшой вопрос :)
Не эксперт в криптографии, но AES же симметричный, ключ должен хранится в приложении — разве его сложно расшифровать?
Не эксперт в криптографии, но AES же симметричный, ключ должен хранится в приложении — разве его сложно расшифровать?
Здесь вы правы, но ключ сначала нужно найти и правильно собрать. Stringer работает как хороший вирус, динамически встраивая части своего кода в разные class-фалы.
Естевственно нужно понимать, что софтверная защита никогда не сможет стать «не взламываемой», но мы сделали все, что бы максимально усложнить эту задачу.
Естевственно нужно понимать, что софтверная защита никогда не сможет стать «не взламываемой», но мы сделали все, что бы максимально усложнить эту задачу.
НЛО прилетело и опубликовало эту надпись здесь
Благодарю за комментарий. В скором времени опубликую статью об обфускаторах-шифровальщиках class-файлов и тотальной бессмысленности их существования.
НЛО прилетело и опубликовало эту надпись здесь
Как и обещал: habrahabr.ru/post/144957/
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Stringer Java Obfuscation Toolkit: защита Java и Android-приложений