О декомпиляции, клонировании, 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]

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

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

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

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

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

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

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

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

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

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

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

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

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

← →
DrPass © (2007-06-23 13:50) [33]

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

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

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

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

← →
IMHO © (2007-06-23 14:02) [34]

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

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

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

← →
isasa © (2007-06-23 14:06) [35]

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

← →
IMHO © (2007-06-23 14:07) [36]

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

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

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

← →
KSergey © (2007-06-23 14:46) [38]

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

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

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

← →
DrPass © (2007-06-23 16:39) [39]

> 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++){};

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

← →
Anatoly Podgoretsky © (2007-06-23 20:47) [41]

> P (23.06.2007 20:02:40) [40]

> for(trjrtjk3443 = 10; trjrtjk3443 < 34; trjrtjk3443++){};

Чего сложного

for(i = 10; i < 34; i++){};

← →
iZEN © (2007-06-23 20:53) [42]

> IMHO © (23.06.07 14:02) [34]
>
> Делая EXE-бинарник, я могу быть относительно спокоен в этом,
> но делая JAR - где гарантия???

Ты наверно начинащий джавист.
Поэтому не слышал ещё об обфускаторах, которые с разной степенью качества "запутывают" бинарный байт-код, подменяют имена переменных, методов, классов, попутно ужимают код.

Один из известных свободный обфускаторов для Java-кода — ProGuard: http://proguard.sourceforge.net/

← →
P (2007-06-23 22:01) [43]

> Anatoly Podgoretsky © (23.06.07 20:47) [41]
>
> > P (23.06.2007 20:02:40) [40]
>
> > for(trjrtjk3443 = 10; trjrtjk3443 < 34; trjrtjk3443++){};
>
> Чего сложного
>
> for(i = 10; i < 34; i++){};

Только данный код проще написать самому чем разгребать подобное.

← →
Panel (2007-06-24 00:41) [44]

Только данный код проще написать самому чем разгребать подобное.

Средства рефакторинга в руки... и не надо ничего разгребать.

← →
Иа (2007-06-24 06:45) [45]

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

← →
iZEN © (2007-06-24 07:42) [46]

> Иа (24.06.07 06:45) [45]

Э...
Не надо переносить понимание проблем .Net на Яву.
Там несколько всё по-другому.

← →
Иа (2007-06-24 10:42) [47]

> iZEN © (24.06.07 07:42) [46]
>
> > Иа (24.06.07 06:45) [45]
>
> Э...
> Не надо переносить понимание проблем .Net на Яву.
> Там несколько всё по-другому.

Во-первых, я не считаю это проблемой. Во-вторых, не могли бы вы озвучить отличие Java VM от .NET CLR в возможностях и механизмах обфускации кода?

← →
iZEN © (2007-06-24 22:16) [48]

> Иа (24.06.07 10:42) [47]
>
> Во-первых, я не считаю это проблемой. Во-вторых, не могли
> бы вы озвучить отличие Java VM от .NET CLR в возможностях
> и механизмах обфускации кода?

В Java исполняемой единицей является .class-файл. В .Net исполняемой единицей является сборка. Сборка .Net содержит несколько типов и код исполнения, но из неё не удастся выделить отдельные типы (классы) и сохранить их в отдельных файлах для последующей обработки обфускатором и построения из них новой сборки.

В .class-файле Java:
имена переменных и методов хранятся в том виде, каком их определил программист (подмножество ASCII, допустимы имена членов на национальном языке, коды символов которого имеют отображение в ASCII-набор);
значения строковых типов хранятся в Unicode (UTF-8, UCS-2 и UCS-4 в Java 5.0);
class-файл имеет CRC-последовательность, подтверждающую корректность байткода файла.
Всё это и ещё куча вещей должны учитываться обфускатором. И это гораздо легче, чем работать с бинарной сборкой .Net.

Кроме того, Java VM каждый раз производит верификацию байткода загружаемого .class-файла. А .Net CLR верификацию делает(делает ли?) один раз при первоначальном запуске сборки и генерирует из неё бинарный нативный код, который кэширует GAC для будущего использования CLR.

← →
Иа (2007-06-25 02:21) [49]

> Сборка .Net содержит
> несколько типов и код исполнения, но из неё не удастся выделить
> отдельные типы (классы) и сохранить их в отдельных файлах
> для последующей обработки обфускатором и построения из них
> новой сборки.

Неверно

> В .class-файле Java:

То же самое, за исключением локальных переменных.

> Всё это и ещё куча вещей должны учитываться обфускатором.
> И это гораздо легче, чем работать с бинарной сборкой .Net.

Не вижу как одно вытекает из другого

>А .Net CLR верификацию делает(делает ли?)

Задавая такой вопрос вы демонстрируете свое незнание в вопросе, который взялись осветить.

>один раз при первоначальном запуске сборки

Неверно.

>и генерирует
> из неё бинарный нативный код, который кэширует GAC для будущего
> использования CLR.

Неверно.

← →
iZEN © (2007-06-25 03:07) [50]

> Иа (25.06.07 02:21) [49]

Отвечая на ваш вопрос, основывался на выкладках, почерпнутых из книжки Пол Гиббонз "Платформа .NET для Java-программистов". Допускаю, что с тех пор многое в .Net переменилось -- не изучал вопрос досконально и не претендую на знание последней версии .Net CLR.

← →
iZEN © (2007-06-25 03:25) [51]

> IMHO © (23.06.07 11:11)
>
> JAR-файл, в который можно залезть и изменить его.

class-файлы можно защитить от реинжиниринга кода обфускацией. Ресурсы (текст, картинки, аудио, видео) невозможно проверить на достоверность кроме как использованием подписанного JAR-файла цифровой подписью со сверкой MD-5 и SHA-1 контрольных сумм файлов архива на этапе запуска приложения.

← →
Иа (2007-06-25 03:49) [52]

> как использованием подписанного JAR-файла цифровой подписью

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

← →
Иа (2007-06-25 03:54) [53]

> > Иа (25.06.07 02:21) [49]
>
> Отвечая на ваш вопрос, основывался на выкладках, почерпнутых
> из книжки Пол Гиббонз "Платформа .NET для Java-программистов".
> Допускаю, что с тех пор многое в .Net переменилось -- не
> изучал вопрос досконально и не претендую на знание последней
> версии .Net CLR.

В нет пунктах которые вы затронули выше принципиальных изменений с 1.0- 2.0 не произошло. Предполагаю, что вы могли запутаться в терминологии или запоминили не то. К примеру, компиляцию в native и кэширование в GAC как вы описывали можно устроить с помощью ngen, при обычной работе такого не происходит. Читать по CLR можно и нужно Рихтера.

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

> Игорь Шевченко (25.06.2007 12:30:54) [54]

Ну можно же заплатить взломщику.

Ради того, что бы проявили интерес хотя бы за деньги.

> Иа (25.06.07 03:49) [52]
>
>
> > как использованием подписанного JAR-файла цифровой подписью
>
>
> Что изменится если я уберу цифровую подпись с чужого файла
> и подпишу его заново моим ключом? Предполагая, что в коде
> приложения нет специальной проверки на публичный ключ автора?
>

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

← →
Petr V.Abramov (2007-06-26 00:47) [59]

> Ничего, если ваш сертификат будет находится в хранилище сертификатов пользователя в списке доверенных.
а сколько надо заплатить пользователю, чтоб он послушал такие слова?

← →
Иа (2007-06-26 02:42) [60]

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

Мой или родительский? Если мой, то каким образом происходит добавление моего сертификата легально - во время инсталляции? И как тогда делать xcopy deployment? Что произойдет если ресурс подписан самодельным сертификатом? А если файл с кодом?

Вообще же, общие принципы описаны здесь:
http://khpi-iip.mipk.kharkiv.edu/library/extent/prog/jar/TOC.html

Более наглядно:
http://www.rudometov.com/security/03_01_26_Java_Crypto/Java_Crypto.html

> Иа (26.06.07 02:42) [60]
> > Ничего, если ваш сертификат будет находится в хранилище
> > сертификатов пользователя в списке доверенных.
> Мой или родительский?
Ваш.

> Если мой, то каким образом происходит
> добавление моего сертификата легально - во время инсталляции?
Ну да.
Панель управления -> Java -> вкладка Security -> диалог Certificates -> добавляете сертификат производителя подписанного продукта в одну из категорий.

> И как тогда делать xcopy deployment?

Использовать утилиты jarsigner, keytool и средство автоматизации типа Ant или скриптов командного процессора операционной системы.

http://www.javaportal.ru/java/articles/jar.html

> Что произойдет если
> ресурс подписан самодельным сертификатом? А если файл с
> кодом?

Выброс java.security.DigestException или java.security.SignatureException -- в зависимости от ситуации. В общем случае -- потомок java.security.GeneralSecurityException.

Подробнее: http://java.sun.com/javase/reference/api.jsp

← →
Иа (2007-06-26 09:59) [62]

> Вообще же, общие принципы описаны здесь:
> http://khpi-iip.mipk.kharkiv.edu/library/extent/prog/jar/TOC.
> html

"А в версии 1.2 платформы Java подписанные приложения, вызываемые с опцией интерпретатора -jar, будут проверяться средой выполнения. "

? То есть если я не вызову с ключем, то не проверится? 8()

Более наглядно:
http://www.rudometov.com/security/03_01_26_Java_Crypto/Java_Crypto.html

А тут вообще про криптографию в принципе. Мне не надо объяснять как public/private ключи работают и что такое x509 сертификаты. Я, э, это знаю :) Меня интересует как цифровая подпись используется java vm, в сравнении с .NET. Первая ссылка с цитаой выше меня просто потрясла. Это афтар курил чего-то?

> > И как тогда делать xcopy deployment?
>
> Использовать утилиты jarsigner, keytool и средство автоматизации
> типа Ant или скриптов командного процессора операционной
> системы.

Ничего из вышеперечисленного к моему вопросу отношения не имеет.
Собственно, вы уверены что вы не java аплеты только имеете ввиду обобщая их на все java приложения? Потому как аплеты, так же как и .NET thin controls в IE живут своей особой жизнью.

Можно воспользоваться компилятором Excelsior Jet и получить exe-шник.

> Иа (26.06.07 09:59) [62]
>
> "А в версии 1.2 платформы Java подписанные приложения, вызываемые
> с опцией интерпретатора -jar, будут проверяться средой выполнения.
> "
> ? То есть если я не вызову с ключем, то не проверится? 8()

У вас что-то с логикой?
Опция "-jar" нужна для запуска jar-файла на выполнение ВООБЩЕ.

> Иа (26.06.07 09:59) [62]
>
>
> Более наглядно:
> http://www.rudometov.com/security/03_01_26_Java_Crypto/Java_Crypto.
> html
>
>
> А тут вообще про криптографию в принципе. Мне не надо объяснять
> как public/private ключи работают и что такое x509 сертификаты.
> Я, э, это знаю :) Меня интересует как цифровая подпись
> используется java vm, в сравнении с .NET. Первая ссылка
> с цитаой выше меня просто потрясла. Это афтар курил чего-
> то?

Там картинки. Всё ясно.

А причём здесь сравнение с .NET?

> Иа (26.06.07 09:59) [62]
>
> > > И как тогда делать xcopy deployment?
> >
> > Использовать утилиты jarsigner, keytool и средство автоматизации
> > типа Ant или скриптов командного процессора операционной
> > системы.
>
> Ничего из вышеперечисленного к моему вопросу отношения не
> имеет.

К какому вопросу?

> Иа (26.06.07 09:59) [62]
> Собственно, вы уверены что вы не java аплеты только имеете
> ввиду обобщая их на все java приложения? Потому как аплеты,
> так же как и .NET thin controls в IE живут своей особой
> жизнью.

В Java одна и та же система безопасности для апплетов и приложений. Правда, модели безопасности Java v.1.1.x и Java v.2 отличаются.

http://www.rudometov.com/security/03_01_26_Java_Crypto/Java_Crypto.html
Рисунки:
Рис. 3. Последовательность действий при подписи jar-архива.
и
Рис. 4. Последовательность действий при верификации полученного jar-архива.
Достаточно наглядны.

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

Элементарно.
После дешифровки дешифрованная информация должна появиться где-нибудь в памяти в открытом виде.

> После дешифровки дешифрованная информация должна появиться
> где-нибудь в памяти в открытом виде

говорят, что есть такие крипторы с вирт. машинами, где инфа никогда не появляется полностью в памяти.

← →
Иа (2007-06-26 16:37) [68]

> > Иа (26.06.07 09:59) [62]
> >
> > "А в версии 1.2 платформы Java подписанные приложения,
> вызываемые
> > с опцией интерпретатора -jar, будут проверяться средой
> выполнения.
> > "
> > ? То есть если я не вызову с ключем, то не проверится?
> 8()
>
> У вас что-то с логикой?
> Опция "-jar" нужна для запуска jar-файла на выполнение ВООБЩЕ.
>

В той же ссылке рассказывается о JavaRunner классе. На мой взгляд никакой опции -jar там не видно. Будет ли выполнятся проверка при таком варианте запуска?

> Там картинки. Всё ясно.
>
> А причём здесь сравнение с .NET?

Вы говорили выше о то что в Java "немного не так". Вот я и пытаюсь выяснить, что именно. Кстати, вы говорили о .class как минимальной единице. Но подписать .class нельзя. Я правильно понимаю, что ограничить права для кода выполняемого не из .jar нельзя?

> > Иа (26.06.07 09:59) [62]
> >
> > > > И как тогда делать xcopy deployment?

> К какому вопросу?

Теперь видите? Из ваших слов следовало что если моего сертификата нет в списке, код не запустится. Я пытаюсь выяснить у вас как тогда его распространять.

Иа (26.06.07 16:37) [68], такое ощущение, что я зря ссылки выкладывал.

Там же всё написано!

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

Думаю, что даже делая EXE-бинарник быть спокойным нельзя, гарантии не даст никто. Можно немного усложнить процесс, но думаю, что лучшим средством защиты будет соответствующее лицензионное соглашение :)

> IMHO © (23.06.07 11:11)
> вы не сильно беспокоитесь о том, что кто-то декомпилирует вашу программу

Флаг ему в руки! Несколько миллионов строк asm-кода...

> oldman (26.06.2007 19:08:11) [71]

Из которых менее процента своего кода.

← →
Иа (2007-06-27 02:24) [73]

> Иа (26.06.07 16:37) [68], такое ощущение, что я зря ссылки
> выкладывал.
>
> Там же всё написано!

Пока все что я понял о "security" в Java это

1) При запуске jar файла через networkloader и иже с ними никакой проверки не происходит
2) Никакой проверки на наличие сертификата в разрешенных не происходит если это не апплет. То есть по умолчанию.
3) Что бы распространить полиси с апплетов на запускаемое приложение надо сделать это ручками java -Djava.security.manager MyLoader
4) До 1.2 все было ГОРАЗДО хуже.

Вывод: правила безопасности на основе цифровой подписи в java по прочности в подметки не годятся .NET security policy.
Собственно, это меня и интересовало. Спасибо.

Возможность декомпиляция это очень большая проблема для таких программ.
В частности для .net есть утилита Lutz Roeder"s .NET Reflector которая для любой сборки генерирует очень даже неплохой код на любом из языков (c#, vb, delphi, c++). Для исследования стандартных классов это полезно, но ...

MS насколько помнится обещала принять меры, только что они хотели предпринять я уже не помню..

> Иа (27.06.07 02:24) [73]
> Пока все что я понял о "security" в Java это
>
> 1) При запуске jar файла через networkloader и иже с ними
> никакой проверки не происходит

Тем не менее, все class-файлы (кроме системных классов из пакетов java*), которые участвуют в загрузке, проходят верификацию. Процесс выполнения их кода контролируется диспетчером безопасности (java.lang.SecurityManager, java.security.AccessController) и регулируется текущей политикой безопасности (java.security.Policy). Всё очень гибко устроено так, что система управления доступом обеспечивает механизмы, которые используют права доступа и политики безопасности, чтобы разрешить или запретить доступ к определённым ресурсам от файлов на локальном диске до сетевых соединений (включая домены) и защищённых объектов среды выполнения.

> Иа (27.06.07 02:24) [73]
> 2) Никакой проверки на наличие сертификата в разрешенных
> не происходит если это не апплет. То есть по умолчанию.
> 3) Что бы распространить полиси с апплетов на запускаемое
> приложение надо сделать это ручками java -Djava.security.
> manager MyLoader

Пока не определена новая политика безопасности в системе Java, используется базовая политика безопасности. В каталоге [JAVA_HOME]/lib/security/ находится файл java.security, в котором по мимо прочего есть две записи, указывающие, где находится файл политики безопасности. Пример:policy.url.1=file:${java.home}/lib/security/java.policy policy.url.2=file:${user.home}/.java.policy Приведу так же содержимое стандартного файла политики [JAVA_HOME]/lib/security/java.policy: // Standard extensions get all permissions by default grant codeBase "file:${{java.ext.dirs}}/*" { permission java.security.AllPermission; }; // default permissions granted to all domains grant { // Allows any thread to stop itself using the java.lang.Thread.stop() // method that takes no argument. // Note that this permission is granted by default only to remain // backwards compatible. // It is strongly recommended that you either remove this permission // from this policy file or further restrict it to code sources // that you specify, because Thread.stop() is potentially unsafe. // See "http://java.sun.com/notes" for more information. permission java.lang.RuntimePermission "stopThread"; // allows anyone to listen on un-privileged ports permission java.net.SocketPermission "localhost:1024-", "listen"; // "standard" properies that can be read by anyone permission java.util.PropertyPermission "java.version", "read"; permission java.util.PropertyPermission "java.vendor", "read"; permission java.util.PropertyPermission "java.vendor.url", "read"; permission java.util.PropertyPermission "java.class.version", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "os.version", "read"; permission java.util.PropertyPermission "os.arch", "read"; permission java.util.PropertyPermission "file.separator", "read"; permission java.util.PropertyPermission "path.separator", "read"; permission java.util.PropertyPermission "line.separator", "read"; permission java.util.PropertyPermission "java.specification.version", "read"; permission java.util.PropertyPermission "java.specification.vendor", "read"; permission java.util.PropertyPermission "java.specification.name", "read"; permission java.util.PropertyPermission "java.vm.specification.version", "read"; permission java.util.PropertyPermission "java.vm.specification.vendor", "read"; permission java.util.PropertyPermission "java.vm.specification.name", "read"; permission java.util.PropertyPermission "java.vm.version", "read"; permission java.util.PropertyPermission "java.vm.vendor", "read"; permission java.util.PropertyPermission "java.vm.name", "read"; };
Вообще же, общий формат файла политики таков:[keystore "URL_хранилища_ключей", "тип_хранилища";] grant [SignedBy "список_подписавших"] [, CodeBase "URL_базы_кода"] { permission имя_класса_права_доступа ["имя_объекта"] [, "действие"] [, SignedBy "список_подписавших"]; .... }(в именах допустимы шаблоны: ${user.home}, ${file.separator} и т.д.).
При задании новой политики для приложения можно определить: класс Провайдера политики безопасности, класс собственного Диспетчера безопасности, файл Политики безопасности или же оставить что-то из них по умолчанию. Всё это похоже на управление расширенным доступом на основе ACL в операционных системах UNIX.

> Иа (27.06.07 02:24) [73]
> 4) До 1.2 все было ГОРАЗДО хуже.

Не надо абсолютизировать.
До v.1.2 нельзя было задать свою политику безопасности и права доступа для выполнения приложения в JVM. В Java 1.0.x всё походило на политику безопасности Microsoft для ActiveX (которые можно было либо вырубить, либо разрешить им всё) и EXE-приложения. В Java 1.1: апплеты выполнялись в песочнице с максимальными ограничениями; подписанные апплеты имели определённые права и доступ к файловой системе (как приложения пользователя); приложения же были ничем не ограничены. Всё это было не очень гибко. Сейчас же (начиная с версии Java 1.2) всё гораздо гибче -- появилась возможность создания конфигурируемых прав доступа.

> Иа (27.06.07 02:24) [73]
> Вывод: правила безопасности на основе цифровой подписи в
> java по прочности в подметки не годятся .NET security policy.

Если не хотите разбираться, что ж, думайте так и дальше. :))

> Иа (27.06.07 02:24) [73]
> Собственно, это меня и интересовало. Спасибо.

Пожалуйста.

P.S.
Сертификаты служат для идентификации производителя продукта и определения принадлежности продукта конкретному производителю. Дайджест (MD-5, SHA-1) удостоверяет целостность продукта. Напоминаю, что в данной теме разговор ведётся именно о защите контента от дизассемблирования и обеспечения его целостности -- о защите от модификации.

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