Node.js - Защита кода?

Ответ 1

Вы можете выполнить это с помощью NativeExtension для node

У вас будет файл boostrap.js, который добавит обработчик расширения для файлов .jse

// register extension
require.extensions[".jse"] = function (m) {
 m.exports = MyNativeExtension.decrypt(fs.readFileSync(m.filename));
};

require("YourCode.jse");

YourCode.jse будет зашифрованной версией вашего исходного кода (ключ для дешифрования не будет нигде в текстовом формате, потому что процесс дешифрования имеет место в родном расширении).

Теперь у вас есть функция NativeExtensions decrypt, которая преобразует исходный код обратно в javascript. Просто создайте процесс создания зашифрованных версий .jse всех ваших файлов и отпустите их для своих клиентов. Они также нуждаются в родном расширении, но теперь вам было немного сложнее изменить код без особых усилий. Вы даже можете сделать родной внутренний звонок и проверить информацию о лицензии, чтобы предотвратить пиратство (помните, что это не остановит пиратство, для этого нет решения).

Ответ 2

Просто включите лицензионное соглашение и дайте им исходный код. Возможно, они захотят настроить его.

Ответ 3

Чтобы быть предельно ясным, клиентский Javascript (загруженный с удаленного сервера в стандартный веб-браузер) не может быть защищен от просмотра и/или модификации независимо от того, как вы запутываете его с момента восстановления ( "de-obfuscation" ) исходный источник технически тривиален. (Обфускация Javascript - это просто еще один пример широко используемой "неправильной" безопасности "безопасность через неясность".)

Если вы хотите использовать Javascript и Node.js для обеспечения защищенного "продукта" (который в этом контексте является приложением или услугой, требующей установки на сервере, которую ваша компания не контролирует), вы не можете защитить ее либо как единственный доступный вам вариант (обфускация) не обеспечивает такую ​​защиту.

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

Все, однако, не потеряно: если мы предположим, что можно программно защитить интеллектуальную собственность (жюри по-прежнему отсутствует), есть способ обеспечить продукт Node.js безопасным образом, но это не для технически unadventurous, поскольку это потребует существенного рефакторинга исходного кода Node.js(чтобы добавить поддержку криптографически защищенных библиотек и удалить или иным образом защитить - отражение объекта для ваших собственных библиотек).

Ответ 4

Поскольку я только что завершил огромный чистый проект Nodejs в 80+ файлах, у меня была такая же проблема, как и у OP. Мне нужна была минимальная защита для моей тяжелой работы, но, похоже, эта основная проблема не была охвачена сообществом OS NPMjs. Добавьте соль к травме. Система шифрования пакетов JXCore была взломана на прошлой неделе в течение нескольких часов, чтобы вернуться к обфускации...

Итак, я создал полное решение, которое обрабатывает слияние файлов, uglifying. У вас есть возможность оставить определенные файлы/папки, а также от слияния. Затем эти файлы копируются в новое местоположение вывода объединенного файла, а ссылки на них переписываются автоматически.

Ссылка NPMjs node -uglifier

Github repo node -uglifier

PS: Я был бы рад, если бы люди помогли сделать его еще лучше. Это война между ворами и трудолюбивыми программистами, такими как вы. Давайте присоединимся к нашим силам, увеличим боль обратного проектирования!

Ответ 5

JXcore (node.js 0.11.X distro) имеет свою собственную функцию упаковки JX, которая защищает исходный код и активы, Вы даже можете выбрать, может ли этот конкретный пакет использоваться из других приложений или нет. (автономная библиотека OR)

Скажем, у вас много файлов JS и т.д., и точка входа в ваш модуль - это что-то вроде:

exports.doThis = function() { ...... };

если вы просто вызываете метод ниже и компилируете его в пакет JX, исходный код будет безопасным.

jxcore.utils.hideMethod(exports.doThis);

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

Вам нужно JXcore для запуска пакетов JX.

Более подробную информацию можно найти в JXcore

Ответ 6

Код JavaScript на стороне сервера полностью закрыт. Никто не может его прочитать.

Клиентский код javascript полностью открыт. Все могут прочитать его.

Для последнего вы можете ничего не делать, но то же самое относится к RoR, ASP.NET, PHP и т.д.

Фактический код сервера закрыт, если вы публично не сделаете его доступным.

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

Существуют различные крупные компании, такие как extjs, которые продают библиотеки, которые могут быть украдены, поэтому то, что они на самом деле продают вам, это код и служба поддержки.

Большинство коммерческих проектов, построенных на node, являются службами.

Ответ 7

Поместите свою основную логику в модули. Эти модули можно построить, а затем выполнить через закрытие Google. Вы даже можете сделать это как задачу Grunt как часть процесса сборки.

Это старый вопрос, но стоит отметить. Примечание. Ничто из того, что вы сделаете, действительно скроет ваш код, но ничто не будет отправлено через .Net(С#) или Java, если на то пошло. В общем, просто используя инструмент, например uglify или закрытие, должно быть достаточно точки обфускации. Будучи модульным и использующим закрытие, вы действительно можете сделать много оптимизаций, которые в противном случае были бы трудными.

Ответ 8

Вы можете использовать EncloseJS - компилятор для проектов node.js. Он действительно компилирует JavaScript на собственный код, а ваши источники не включены в двоичный файл.

Ответ 9

вы можете использовать packer для nodejs для обфускации вашего script...

Ответ 10

Вы не можете быть абсолютно уверены, что никто не сможет прочитать ваш код. Вы можете использовать обфускацию или минимизацию, что может значительно затруднить декодирование вашего кода. Одним из примеров обфускатора / minifier является Google Closure Compiler для JavaScript.

Ответ 11

У меня есть идея. Защитите приложение cpp или java вместо js.

• Оберните свой код в формате шифрования и скомпилируйте его как utf-8 файловый ресурс.
• Используйте приложение cpp или java для загрузки всего файла в linux pc или arm computer, убедитесь, что у вас есть надежный пароль или закрыть ssh port или отключите видеопорт и просмотрите файл linux. только через Интернет.
• Существует программа cpp для дешифрования файла на компьютере linux.
• Создайте веб-сервер для управления вашим компьютером linux.

Так что это очень похоже на черный ящик, клиенты ничего не могут сделать с вашим кодом.