О декомпиляции, клонировании, Dephi и Java

← →
IMHO © (2007-06-23 11:11) [0]

Господа, поправьте, если неправ.

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

А как обстоят подобные делаю с Джавой? Что получаем на выходе? JAR-файл, в который можно залезть и изменить его.

Слышал про какие-то обфускаторы... Насколько они действенны?

← →
Инс © (2007-06-23 11:18) [1]

> изменит ряд авторских и прочих данных, склонирует и выложит
> под своим именем.

Тем самым, он расскажет всем как его зовут и где его искать. А законы об авторских правах слава Богу еще пока действуют. Другое дело, когда взломщику нужно не прославиться, а получить коммерческую выгоду от взлома или просто спортивный интерес, при этом он остается анонимным - так от этого существуют специальные методы защиты. Их нужно применять, если конечно, ваша программа чего-то стоит и может заинтересовать взломщика, а ее взлом принесет вам какой-либо урон.

← →
IMHO © (2007-06-23 11:29) [2]

> так от этого существуют специальные методы защиты.

Для Java существуют методы защиты?

← →
KSergey © (2007-06-23 11:57) [3]

> IMHO © (23.06.07 11:29) [2]
> Для Java существуют методы защиты?

Зашить небольшую, но критическую часть логики во внешний бинарный модуль?

← →
Инс © (2007-06-23 11:57) [4]

Да, с Java есть проблема, она связана с тем, что полученный исполняемый файл представляет собой не готовый к исполнению машинный код, а нечто, что еще будет транслироваться. Поэтому для Java существуют декомпиляторы, которые позволяют достаточно успешно получить исходный код Java из промежуточного байт-кода. Исполняемый файл, собранный в Delphi же, представляет собой полноценный готовый к исполнению PE-модуль, полностью декомпилировать его назад в код на Delphi невозможно. Частично конечно можно повытаскивать RTTI, еще что-нибудь, но не более того. Можно дизассемблировать - получить код на ассемблере. Именно так взломщики и поступают, но как я уже сказал, есть методы защиты. Самый мощный (ИМХО) - шифрование кода. Думаю, для Java существуют какие-либо методы защиты от модификации, но тут я не компетентен.

← →
KSergey © (2007-06-23 12:08) [5]

> Инс © (23.06.07 11:57) [4]
> Самый мощный (ИМХО) - шифрование кода.

А по-моему - довольно бестолковый, т.к. в любом зшифрованной коде будет обязательно присутсвовать нешифрованный расшифровщик.

← →
Инс © (2007-06-23 12:16) [6]

> А по-моему - довольно бестолковый, т.к. в любом зшифрованной
> коде будет обязательно присутсвовать нешифрованный расшифровщик.

Алгоритм шифрования не нужно ни от кого скрывать. Секретным должен быть ключ. Если защита построена на том, что алгоритм никто не знает - это плохая защита. Алгоритмы рекомендую использовать стандартные, всем известные - DES, 3DES, RC2, RC4, RC6 и другие. А ключ нужно генерить с помощью ассиметричных алгоритвом (RSA, например). Могу привести полную схему защиты, буду рад, если вы укажите на узкие места, о которых я не знаю.

← →
KSergey © (2007-06-23 12:20) [7]

> Инс © (23.06.07 12:16) [6]
> Могу привести полную схему защиты,
> буду рад, если вы укажите на узкие места, о которых я не знаю.

Самому думать лень -так что было бы интересно

← →
DrPass © (2007-06-23 12:23) [8]

> Инс © (23.06.07 12:16) [6]

> Алгоритм шифрования не нужно ни от кого скрывать. Секретным
> должен быть ключ

А каким образом ключ будет секретным, если для выполнения "зашифрованного" кода он все равно должен присутствовать в исполняемом файле?

← →
KSergey © (2007-06-23 12:27) [9]

> DrPass © (23.06.07 12:23) [8]
> А каким образом ключ будет секретным, если для выполнения
> "зашифрованного" кода он все равно должен присутствовать
> в исполняемом файле?

зачем торопиться с вопросами? пусть раскажет.
именно ответ на этот вопрос я и хотел увидеть ответ :)

← →
Инс © (2007-06-23 12:28) [10]

Здесь я приводил схему:

http://www.delphikingdom.com/asp/answer.asp?IDAnswer=51289

← →
Инс © (2007-06-23 12:30) [11]

> А каким образом ключ будет секретным

А таким, что ключ не нужно давать кому попало, а только тому, кто за него заплатил ;)

← →
DrPass © (2007-06-23 12:34) [12]

> А таким, что ключ не нужно давать кому попало, а только
> тому, кто за него заплатил ;)

А что это даст? Я ведь и исполняемый файл могу давать только тому, кто заплатил. Но безопасность от этого никак не возрастет - ключ и зашифрованные данные будут распространяться вместе.

← →
Инс © (2007-06-23 12:36) [13]

Не вместе, а раздельно. Никогда не приобретали ПО через интернет? Скачиваем триальную версию, юзаем 30 дней, понравилось - платим деньги - получаем ключ.

← →
DrPass © (2007-06-23 12:43) [14]

> Инс © (23.06.07 12:36) [13]

Слушай, к чему ты здесь приплел триальные версии и интернет? Автор темы сформулировал вполне конкретную задачу - как защитить свой Java-код от декомпиляции? Ты решение лучше в рамках данной задачи предложи. А как триал сделать - есть миллион способов, эффективных против обычных пользователей и неэффективных против заинтересованных профессионалов (твой, кстати, ничем не лучше других... только геморроя с ним намного больше)

← →
Инс © (2007-06-23 12:46) [15]

> Автор темы сформулировал вполне конкретную задачу - как
> защитить свой Java-код от декомпиляции?

Я же сказал - шифрование кода. Убивает дизассемблер наповал. А вы мне пытаетесь доказать, что этот метод неэффективен. Пока не убедили.

> твой, кстати, ничем не лучше других... только геморроя с
> ним намного больше

А это не мой, это вполне стандартный и общеизвестный ;)

← →
Инс © (2007-06-23 12:49) [16]

> А как триал сделать - есть миллион способов, эффективных
> против обычных пользователей и неэффективных против заинтересованных
> профессионалов (твой, кстати, ничем не лучше других... только
> геморроя с ним намного больше)

Отлично. Наезд я услышал, а теперь, хотелось бы, чтобы Вы в подтверждение своих слов привели аргументы. Я с самого начала попросил, что если считаете неэффективным, укажите на слабые места. Внимательно слушаю!

← →
Инс © (2007-06-23 12:51) [17]

Только, опять таки, к Java это не относится, я говорил про Delphi, впрочем, об этом я тоже писал.

← →
DrPass © (2007-06-23 12:57) [18]

> Я же сказал - шифрование кода. Убивает дизассемблер наповал.
> А вы мне пытаетесь доказать, что этот метод неэффективен.
> Пока не убедили

> Наезд я услышал, а теперь, хотелось бы, чтобы Вы в подтверждение
> своих слов привели аргументы

Без проблем. Итак, разработчик А выпускает Java-продукт, в котором применяем свою крутую авторскую технологию. Алгоритм он шифрует, а ключ для дешифровки даже не распространяет в открытом виде, а для пущей крутизны помещает на eToken и продает эту железку только лицензированным пользователям
Разработчик В заинтересован в крутой авторской технологии. Поэтому он покупает лицензионную копию (1 шт), получает eToken в свое распоряжение. Дальше он дизассемблирует приложение (к Java-софту термин "дизассемблирование" не особо клеится, но ладно, оставим его)... находит зашифрованный участок, выясняет чем шифровалось (DES, 3DES, RSA - больше eToken аппаратно ничего не поддерживает)... ну а потом пишет простую утилитку, которая работает с eToken, подсовывает ей зашифрованный код и своим же ключиком и расшифровывает. И все. А дальше он может подарить всем своим друзьям уже исправленное расшифрованное приложение (оно ведь от ключика уже отвязано - попробуй выясни, от какого клиента была утечка информации). И использовать ту самую крутую авторскую технологию в своем софте и т.д.
Так как твой метод поможет скрыть алгоритм от профессионала?

← →
Virgo_Style © (2007-06-23 13:04) [19]

Инс © (23.06.07 12:49) [16]
укажите на слабые места

Забить в Readme.txt вместо одной строки
S/N: AAAA-BBBB-CCCC-DDD
две
UserName: ABCDEF S/N: AAAA-BBBB-CCCC-DDD
не намного сложнее, по-моему.

← →
Инс © (2007-06-23 13:17) [20]

> [18] DrPass © (23.06.07 12:57)

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

← →
Anatoly Podgoretsky © (2007-06-23 13:19) [21]

> Инс (23.06.2007 12:36:13) [13]

Да, да, крякеры так и поступают, оплачивают по ворованой кредитке и что интересно не ждут окончания 30 дневного срока, сразу покупают :-)

← →
Anatoly Podgoretsky © (2007-06-23 13:19) [22]

> DrPass (23.06.2007 12:23:08) [8]

Цифровая подпись, распространяется только открытый ключ

← →
KSergey © (2007-06-23 13:22) [23]

> Инс © (23.06.07 12:30) [11]
>
> > А каким образом ключ будет секретным
>
>
> А таким, что ключ не нужно давать кому попало, а только
> тому, кто за него заплатил ;)

Я вот не видел, чтобы MS раздавала свои ключи тем, кто не заплатил. Однако изучив ассортимент ларька и следуя вашей логике прихожу к выводу, что таки раздавала. Это верно? Я где-то просмотрел раздачу?

PS
Хотя вру.
Я участвовал в одной раздаче: Windows Server 2000, пробная версия. Серийник был на всех дисках одинаковый, однако он подходил и к полной версии, чем пираты и воспользовались немного позднее.

← →
Anatoly Podgoretsky © (2007-06-23 13:22) [24]

> Инс (23.06.2007 12:46:15) [15]

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

Ты пока мыслишь по ламерски, не с точки зрения хакера и поэтому тебе кажется что все ОК.

← →
Инс © (2007-06-23 13:23) [25]

> [21] Anatoly Podgoretsky © (23.06.07 13:19)

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

← →
Anatoly Podgoretsky © (2007-06-23 13:26) [26]

> DrPass (23.06.2007 12:57:18) [18]

Вот это грамотный подход, крякерский, а не ламерский.
Главное зачем самому то расшифровывать, если все необходимое для этого уже содержится в самой программе.
Без ВЕБ сервисов надежной защиты не существует, а веб сервисы часто совмещают с онлайн информацией, правда там и защищать уже как бы не надо, просто отключают пользователя и все и как правило там подписка, а не пользование.

← →
Anatoly Podgoretsky © (2007-06-23 13:33) [27]

> Инс (23.06.2007 13:17:20) [20]

Переходить на промышленные маштабы, например про WinZip наверно слышал?
Про маштабы его воровства наверно тоже знаешь, но это не мешало автору получать порядка миллиона долларов в месяц или в неделю (не помню точно).

← →
DrPass © (2007-06-23 13:38) [28]

> Инс © (23.06.07 13:23) [25]

Речь не о том, что защита в программе не нужна. Нужна. Но потраченное время, усилия и средства на разработку защиты должны, скажем так, себя оправдывать. Не так то просто реализовать шифрование части кода приложения да еще и с расшифровкой "на лету". И лишь для крохотного процента приложений такая защита будет актуальной.

> Переходить на промышленные маштабы, например про WinZip
> наверно слышал?

Да и Windows сюда тоже подходит :) Некоторые еще делают программные продукты бесплатными для ExUSSR, в расчете на то, что большинство взломщиков как раз оттуда, чтобы отбить интерес ко взлому. А продают пользователям из тех стран, где в общем-то покупать, а не воровать, общепринято. Некоторые еще и прилагают к программе подробную инструкцию по взлому - с той же самой целью, отбить спортивный интерес. Но это мы отошли от темы, действительно, вопрос был как скрыть код. Решение с ВЕБ-сервисами надежно, но не всегда удобно для пользователя.

> Но потраченное время, усилия и средства на разработку защиты
> должны, скажем так, себя оправдывать.

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

> Инс (23.06.2007 13:40:29) [29]

Ты это скажи взломщикам FAR :-)
Веб сервисы конечно надежны, но и применимость ниже

> Ты это скажи взломщикам FAR :-)

Я не могу судить насколько это эффективно. Я лишь констатировал факт, что некоторые так делают из расчета на снижение кряков.

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

Это как бы уже давно определено и без нас. Не секрет, что правило

> цена ключа меньше, чем полученная потом выгода от кражи
> алгоритма

для крупнотиражного массового ПО (того, где действительно применяются уникальные алгоритмы) действует почти всегда
Крупные промышленные системы (типа SAP R3, ITM и т.д.) не воруют :)
А вот сегмент специализированного "наукоемкого" ПО действительно может нуждаться в такой защите. Это всякие конструкторские, математические и т.п. приложения, которые стоят тысячи/десятки тысяч у.е. и продаются небольшими тиражами.

Я вот что имел в виду, когда создавал тему.
Вы, господа, сразу увлеклись темой shareware, покупкой по ворованным картам и отошли от главного.

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

Делая EXE-бинарник, я могу быть относительно спокоен в этом, но делая JAR - где гарантия???

DrPass © (23.06.07 13:50) [33]
Ну в таком случае, мы тихо подходим к мысли о том, что такой код размещается в отдельном маленьком дивайсе, продаваемом индивидуально заказчику. Ключ.

А даже если говорить о shareware.
Продавая ключик (за полнофункциональный EXE), я всего лишь даю возможность пользоваться программой неограниченно, а не возможность рыться в ней.

Интересно мнение Юрия Зотова в этом вопросе. Ведь он (дельфист до мозга костей) перешел на Java и Eclipse.

> IMHO © (23.06.07 14:02) [34]
> но я не
> хочу делать доступными некоторые реализации, имею на то
> право как автор.

Мдя...
Очевидно алгоритмы в моих программах столь тривиальны (и сделуны на всем доступных источниках), что такая мысль мне даже в олову не приходила... :(
Жалею о бесцельно прожитых годах :(

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

> IMHO © (23.06.07 14:02) [34]

> но делая JAR - где гарантия???

Гарантии нет, но обфускатор более-менее защитит. По крайней мере, разобрать кашу из кода не намного проще, чем исполняемый файл

← →
P (2007-06-23 20:02) [40]

>
> IMHO © (23.06.07 11:11)
> А как обстоят подобные делаю с Джавой? Что получаем на выходе?
> JAR-файл, в который можно залезть и изменить его.
>
> Слышал про какие-то обфускаторы... Насколько они действенны?

например просто понять такой код:
jksdjkds754 += rer43438943 -(dfjdfl5 + rrrttr474)/rthewrjwk493;
for(trjrtjk3443 = 10; trjrtjk3443 < 34; trjrtjk3443++){};

Ну и тому подобное. Имеем полное запутывание имен переменных.

О декомпиляции, клонировании, Dephi и Java Найти похожие ветки