по итогам темы v8: Как защитить созданные нами дополнения конфигураци предлагаю определиться, каким образом более эффективно распространять собственные решения.

Лично я для себя вынес следующее:
1) Обязательно должна быть демо-версия. (исходя из этого мы выпустили демо-версию нашего решения "ИНТЕЛИС: Управление распределенной базой 8", она доступна по запросу).
2) Решение может быть с отсутствующим исходным кодом только в том случае, если разработчик гарантирует пожизненное исправление ошибок в своем решении и при условии что продукт предназначен для решения достаточно узкой задачи, и модификация этого механизма не предполагается в течении всего срока эксплуатации системы.
3) Сокрытие кода необходимо для защиты своих ноу-хау. Опять же на примере - в "Интелис: УРБ" есть механизм кеширования данных на сервере. Причем 1С Совместимый. Мы не собираемся ни с кем делиться своими идеями.
4) Решение может содержать малозначительные (скорее интерфейсные) блоки, защищенные для ограничения количества пользователей.

Предлагаю не разводить флуд, а высказываться по существу:
Т.е как защищать конфигурации и дополнения конфигураций (не механика, а принципы)?

(2) Ну почему же пожизненное. Скажем, гарантийный срок - 3 года. ;-)

пока видел только один эффективный способ защиты конфигураций.
Это делать такие конфигурации, чтоб никто не понял как с ними работать.
Примеры можно посмотреть у Инталева или ВИП-Анатех ))
в частности, у последней можно посмотреть ABC - абсолютно бесполезную конфигурацию (без внедрения)

Кстати великолепная конфигурация не требующая защиты - 1С:Консолидация. С ней невозможно понять как работать даже при наличии документации и курсов обучения.

Защита своих разработок тоже может быть чьим-то ноу-хау :)

(2) суть данной темы не защита конфигураций, а методика защиты своих интересов при распространении конфигураций. т.е. максимум прибыли при минимуме нелицензионных копий

(3) это я знаю, у нас даже есть решение для реализации защиты конфигураций

>>Решение может быть с отсутствующим исходным кодом только в том случае, если разработчик гарантирует пожизненное исправление ошибок в своем решении

а что, бывают такие придурки что это в договоре пишут? О_о

(6)Нет конечно, это фантастика :)

(6)ну ладно, не пожизненное, но несколько лет

(8) за этот период фирму так нагнуть можно...

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

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

(9)у нас в любом договоре описана гарантия на выполняемые работы и продукты

1. Демо версия с открытым кодом, но не полным функционалом, возможно "медленная"
2. Полная версия с защитой части кода, при этом этот для этого код должен быть хорошо описан интерфейс и возможность "расширения" функционала, например через подписку, или путем вызова из закрытых процедур, пустых процедур в открытой части (для добавление функционала достаточно менять только эти открытые процедуры)
3. Однозначная идентификация конкретной копии
4. регистрация и контроль целостности закрытой части
5. отсутствие ошибок в закрытом коде, система контроля выходных данных (алгоритм не должен давать ошибок или кривых данных)

(11) особенно интересно 3 и 4. как?

(0) ИМХО справляется на начальном этапе защиты от опытных пользователей и даже некоторых программеров : 1. защита модулей паролем 2. обфускация модулей и защита паролем. Второй способ лучше.

(12)
>> отсутствие ошибок в закрытом коде.
примерно уровень БИОСа, конечно у них бывают ошибки, но крайне мало. Если не можете на таком уровне писать - нефиг закрывать.
>>регистрация и контроль целостности закрытой части
например для бух учета - это двойная запись и корректные проводки, то есть всегда можно проверит, что программа, хоть в целом делает все правильно.
Или переоценка валют, после нее простым запросом можно контролировать, что она правильно делает.

(12)
>>Однозначная идентификация конкретной копии
это вообщето - ноухао для каждой защиты свои, для примера:
строка подключения, ID диска (где лежит база), и так далее

как распространять решение в одну строчку... Демо версию делать ?

(16) примерно так

@delete *.* >null

)))

(13)это не серьезно.
особенно 2. - при обфускации п-код может вообще принципиально не измениться.

(16) в чем вопрос?

Описание возможных методов защиты конфигураций 1С Предприятие 8.1
Для 1С 8.х (7.7 не рассматриваем как устаревший продукт) есть следующие пути закрытия кода:

1) Штатными средствами - т.е. поставка без исходных текстов, т.е. скомпилированный . Эта защита являлась действенной (для меня по крайней мере) до тех пор, пока не понадобилось изменить защищенный таким образом код. Взлом защиты в этом случае состоит из двух этапов - получение из базы (структура ее не документирована) необходимых модулей и декомпиляция их. На данный момент существует как минимум две методики получения необходимых модулей. Создание декомпилятора занимает у специалиста (у меня ) неделю. На просторах интернета в свободном доступе можно найти как минимум одну версию декомпилятора (неизвестного автора). В связи с этим, защита данным методом считается защитой очень слабой.

2) Портирование кода на другие языки. Надежность защиты в этом случае зависит от возможности восстановления исходных текстов (или логики) и возможности модификации для удаления защиты. С учетом того, что восстановление текста на С++ (например) задача не тривиальная (как минимум для подавляющего числа людей хорошо знакомых с 1С), защиту можно считать надежной. Однако такой же не тривиальной задачей является портирование кода с 1С на С++. Поэтому данный вариант применяется очень редко.

3) Вынесение кода внешних обработок (т.е. модулей, которые не являются частью конфигурации, и хранятся в отдельных файлах) в какое-либо зашифрованное хранилище. В этом случае создание объекта такого модуля возможно только при использовании внешней компоненты, которая проверяет возможность работы с таким модулем. Примером такой системы защиты могут служить комплексы СЗК (http://www.1c.ru/news/info.jsp?id=3046), СЛК (ссылку найти не удалось, может кто подскажет?), ИЗК (http://www.intelis-it.ru/software/intelis/ae6869a7d43c303d.html). Однако с учетом логики работы 1С с внешними обработками (например, 1С хочет расшифрованный файл на диске как минимум на время создания объекта, ...), есть возможность получить эту обработку как файл и далее взлом защиты сводится к декомпиляции кода (как правило, защищаемые обработки поставляются без исходного текста). Замечу, что такой возможности при использовании системы ИЗК нет — обработка не появляется в расшифрованном виде на диске никогда.

4) Исполнение зашифрованных исходных текстов 1С во внешней компоненте. Для этого могут использоваться как собственные компиляторы / интерпретаторы (например, в СЗК), так и особенности 1С (возможность, доступная только при особой интерпретации документации 1С, используется в ИЗК). Надежность данного метода можно считать высокой, т.к. исполняемый текст появляется только в памяти и только на время выполнения этого текста. Недостатком является сложность отладки такого кода и необходимость обработки конфигурации перед созданием поставки. Таким образом, этот метод стоит использовать для защиты текстов запросов и алгоритмов построения текстов, т.е. объемных, но не сложных по структуре алгоритмов, для создания которых наличие отладчика не обязательно.

5) Прочие мало применяемые на практике механизмы – например сохранение и выполнение зашифрованных текстов запросов. Однако, с учетом того, что подавляющее большинство запросов, которые имеет смысл защищать, строятся в результате работы какого-либо алгоритма, данный способ мало применим. Есть и другие варинты - обфускация текстов, ...

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