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

Я хочу использовать node.js в своем следующем проекте, но моему начальнику не нравится, что наши конкуренты могут читать исходный код.

Есть ли способ защитить код JavaScript?


person Van Coding    schedule 10.05.2011    source источник
comment
возможный дубликат безопасного распространения приложений NodeJS   -  person Artjom B.    schedule 31.07.2015
comment
проверьте jscrambler.com   -  person Carl Rck    schedule 24.11.2015
comment
Кажется, хороший алгоритм для проектов Node.js: enclosejs.com   -  person Unitech    schedule 01.03.2016


Ответы (14)


Вы можете сделать это с помощью NativeExtension для узла

У вас будет 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 версии всех ваших файлов и передать их вашим клиентам. Им также понадобится собственное расширение, но теперь вы немного усложнили процесс изменения кода без особых усилий. Вы даже можете сделать так, чтобы внутренний добавочный номер звонил домой и проверял информацию о лицензии, чтобы предотвратить пиратство (имейте в виду, что это не остановит пиратство, для этого нет решения).

person Christopher Tarquini    schedule 06.02.2012
comment
Нет проблем, дайте мне знать, как это происходит, я планирую использовать этот метод и в одном из своих проектов. Кто-то должен разработать библиотеку для такого рода вещей - person Christopher Tarquini; 07.02.2012
comment
Имейте в виду, что собственное расширение также должно использовать v8 для преобразования источника в объект javascript для использования узлом. Вы также можете использовать m._compile(MyNativeExtensions.decrypt(..)), но тогда все, что нужно сделать, чтобы изменить ваш источник, - это изменить m._compile на console.log - person Christopher Tarquini; 07.02.2012
comment
Это небезопасно. Неважно, что ключ спрятан в двоичном модуле. После того, как клиент расшифровывает и загружает ваш модуль, он может просто вызвать console.log (yourmodule.yourmethod.toString ()) и распечатать ваш исходный код. - person dlongley; 07.06.2012
comment
^ Что ж, ему нужно только порадовать своего босса;). Очевидно, что нет способа решить эту проблему на таком языке, как javascript. Самый безопасный способ, который я могу придумать, - это ustom node-binary, связанный с вашими скриптами, которые только запускают их (возможно, загрузить их в ОЗУ? Что может потребовать изменения функции require для проверки ресурсов приложения перед проверкой файлов). - person Christopher Tarquini; 13.06.2012
comment
Нет ли для этого какой-либо библиотеки / расширения / проекта с открытым исходным кодом? - person Mark; 15.08.2012
comment
Вам не нужно собственное собственное расширение для шифрования / дешифрования, это делает развертывание запутанным. Я бы предложил использовать собственное дешифрование узлов в сочетании с опциями min / obfuscation, такими как closure или uglify. Если ваш исходный источник - coffeescript, это еще один уровень ... - person Tracker1; 01.01.2013
comment
Краткое примечание: @dlongley Не цитируйте меня по этому поводу, но я считаю, что если у вас есть метод дешифрования, написанный в собственном расширении узла, вы можете запретить Function.prototype.toString работать с кодом, который вы компилируете и добавляете в среду выполнения на C ++. - person Christopher Tarquini; 10.01.2014
comment
@ Tracker1 Все, что есть в мире JS, будет тривиально побеждено чем-то вроде JSBeautifier. Использование собственного дешифрования узла также не подходит, потому что вы можете просто изменить его, чтобы распечатать расшифрованный исходный код, а не исключать его. На самом деле, когда дело доходит до этого, вы не собираетесь далеко уйти с защитой кода с помощью узла, тем более что V8 использует исходный код во время выполнения и нуждается в AST в памяти. - person Christopher Tarquini; 10.01.2014
comment
@ChrisT Дело не всегда в практичности ... в общем, достаточно запустить uglify перед распространением, и даже с JS beautifier вы не получите комментариев или исходных имен переменных, что действительно затрудняет обратное проектирование чего-либо . --- Даже тогда любой, кто мог зайти так далеко, вероятно, мог бы написать это сам. - person Tracker1; 15.01.2014
comment
@ Tracker1 Верно, но это не ответ на вопрос. В идеале вам никогда не придется этого делать, но он хотел способ шифровать, а не запутывать - person Christopher Tarquini; 04.05.2014
comment
Я превратил идею @Chris T в рабочий репозиторий github, если кому-то интересно. Однако имейте в виду, что это все еще запирание входной двери и оставление ключа под уличным ковриком - похоже, что он заперт, но на самом деле это не так. - person Pawel Sledzikowski; 06.11.2014
comment
@dlongley Не будет ли ваш источник функции сохранен внутри замыкания и не будет ли возвращен общедоступный метод, который вызывает внутренний частный метод в закрытии, чтобы предотвратить доступ к фактическому коду, просто используя toString ()? - person Johny Jose; 26.01.2015
comment
@JohnyJose, хм, да, это может помешать доступу toString () на каком-то уровне. Возможно, вы все еще сможете распечатать его другим способом, но я особо не задумывался об этом. Правильным решением по-прежнему является лицензирование, но это интересная идея. - person dlongley; 26.01.2015
comment
@PawelSledzikowski немного опоздал, но ваш код работает как вред. Я сделал некоторые модификации для работы с nan. Большое спасибо за ваш проект! - person kostas ch.; 10.06.2018

Просто включите лицензионное соглашение и предоставьте им исходный код. Они все равно могут захотеть его настроить.

person Mike Blandford    schedule 10.05.2011
comment
Для меня это отличная идея, но для моего начальника это слишком опасно. Если бы мир мог быть менее сложным ... - person Van Coding; 10.05.2011
comment
Это правильный ответ, ИМО. Нет надежного способа помешать клиенту сделать то, чего вы боитесь. Если вы заинтересованы в том, чтобы сделать его более сложным, вы можете попробовать некоторые из решений обфускации, предложенные в этом потоке, или взглянуть на функцию моментального снимка кучи v8. Однако лицензионное соглашение жизненно важно. - Только что понял, что это 11 год, а не 12 год, да ладно! Надеюсь, все получилось :) - person dlongley; 07.06.2012

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

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

Ссылка NPMjs на node-uglifier

Github репозиторий node-uglifier

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

person user2667976    schedule 07.07.2014
comment
Я знаю, что это старый пост, но я все еще ищу решение для защиты моего кода от пиратства. Вы не нашли для этого более надежного решения ?! Tnx - person eArmin; 11.06.2018
comment
Можно ли оставить несколько ключевых слов без обфускации? - person mahesh; 08.07.2018

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

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

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

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

person Rob Raisch    schedule 10.05.2011
comment
Хотя это правда, следует сказать, что если вы можете реконструировать продукт, написанный с помощью, скажем, coffeescript, с использованием requirejs, а затем скомпилировать в один js, а затем запустить закрытие ... из этого зашифрованного в настраиваемое расширение с помощью отображение модуля, загружающего его через заглушку ... вам, вероятно, не НЕОБХОДИМО перепроектировать его, чтобы воспроизвести любую заданную функциональность. - person Tracker1; 01.01.2013

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

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

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

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

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

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

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

person Raynos    schedule 10.05.2011
comment
Мы хотим использовать это в продукте. Когда конкурент установит этот продукт, он увидит исходный код. - person Van Coding; 10.05.2011
comment
Вот почему все коммерческие проекты node.js - это услуги, а не продукты. Вы можете скрыть свой источник с помощью UglifyJS. - person Giacomo; 10.05.2011
comment
@FlashFan, значит, вы создаете библиотеку и продаете ее. Это открытый исходный код. - person Raynos; 10.05.2011
comment
это будет сервис с веб-интерфейсом. Веб-интерфейс будет работать в режиме реального времени, поэтому node.js действительно подойдет. Но да, это будет коммерческий продукт. Я не могу это изменить;) - person Van Coding; 10.05.2011
comment
@FlashFan, если вы физически не предоставляете клиентам исходный код на стороне сервера, тогда в безопасности. Они могут видеть код на стороне клиента, и им всегда удавалось это сделать. Это ошибка веб-программирования. - person Raynos; 10.05.2011
comment
@Raynos: Проблема в том, что мы не размещаем эту услугу. Наши клиенты установят его на свои серверы и запустят. Нашим конкурентам будет очень легко получить код. Они просто скачают сервис и установят его. - person Van Coding; 10.05.2011
comment
@FlashFan, если они нарушают ваши авторские права или используют ваш код без разрешения, вы можете подать на них в суд. Добро пожаловать в пиратство. - person Raynos; 10.05.2011
comment
Вы так правы;) Может, мне еще раз придется поговорить со своим боссом ... Оно того стоит! Node.js намного проще в использовании и в 100 раз увлекательнее: P - person Van Coding; 10.05.2011
comment
@FlashFan 1) как указывает Райанос, javascript-код node.js на стороне сервера ПОЛНОСТЬЮ закрыт, даже ваши html-файлы по умолчанию в / view. публично доступны только css и js на стороне клиента (в папке / public). 2) клиентская сторона js является общедоступной, даже зашифрованной. Но есть методы (например, загрузка по запросу), которые затрудняют для ppl кражу ваших js-файлов на стороне клиента. 3) чтобы защитить ваш код node.js, вы не можете скрыть 100%. Однако есть еще способ скрыть частичный код node.js. - person murvinlai; 11.05.2011
comment
@FlashFah, как указано выше в пункте 3), может быть способ сделать это. Во-первых, я этого не делал, это просто концепция. По тому, как данные хранятся в MongoDB (да… теперь mongo) и как данные возвращаются в Node.js, вы можете фактически хранить функцию в mongodb. Итак, идея, шаг а), только зарегистрированный клиент имеет логин / пароль для подключения к mongo. шаг b) некоторые основные функции хранятся в db (вы можете зашифровать его, если хотите). шаг c) когда приложение nodejs запускается, оно аутентифицируется и подключается к mongo и получает функции. Конечно, вам решать, кому предоставить доступ. - person murvinlai; 11.05.2011
comment
@murvinlai стоит отметить, что вы можете просто отключить аутентификацию в сервисе mongo, чтобы получить доступ к базовым данным ... если вы контролируете оборудование, у вас есть доступ. - person Tracker1; 01.01.2013
comment
@murvinlai - эта строка. Наши клиенты установят ее на свои серверы и запустят. Нашим конкурентам будет очень легко получить код, даже не говорится о том, что js на стороне сервера закрыты, клиенты действительно имеют доступ к коду сервера. если только кодирование фургона не реализует что-то вроде этого en.wikipedia.org/wiki/Always-on_DRM тогда исходный код всегда доступен, есть причина, по которой в некоторых играх требуется интернет для входа в систему - person ianace; 30.07.2013

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

Допустим, у вас много файлов JS и т. Д., И точка входа в ваш модуль выглядит примерно так:

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

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

jxcore.utils.hideMethod(exports.doThis);

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

Для запуска пакетов JX вам понадобится JXcore.

Дополнительную информацию можно получить на сайте JXcore.

person Nuray Altin    schedule 29.01.2014
comment
Обратите внимание: jxcore не защищает источник (по крайней мере, больше): github. com / jxcore / jxcore / issues / 857 # event-579583412 - person Ashwin; 07.03.2016

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

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

person Tracker1    schedule 31.12.2012

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

person Igor Klopov    schedule 16.02.2015
comment
Лицензия EncloseJS не разрешает коммерческое использование. - person aleung; 20.08.2015
comment
Самая первая возможность на сайте: сделать коммерческую версию вашего приложения без исходных текстов. Кроме того, это платный продукт / продукт по подписке, поэтому кажется, что он намерен использовать его в коммерческих целях. - person Blisterpeanuts; 04.01.2016
comment
Уважаемые пользователи EncloseJS. Я настоятельно рекомендую вам перейти на github.com/zeit/pkg. Это переписанный преемник EncloseJS. Это открытый исходный код, и все улучшения будут там - person Mladen Oršolić; 20.04.2018
comment
Кажется, что PKG ничего не скрывает, вы можете открыть двоичный файл в VIM и увидеть весь исходный код. просто мой опыт. - person Jason; 17.07.2018
comment
@Jason Это решено здесь: github.com/vercel/pkg/issues/190 . Tldr: Есть ли шанс, что "license": "ISC" в package.json? Удалите это, чтобы избавиться от источников. - person Markus Pscheidt; 13.02.2021

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

person oshimin    schedule 10.05.2011
comment
У вас есть информация о том, насколько безопасным будет упакованный код? - person Van Coding; 10.05.2011
comment
Packer устарел. obfuscator.io - это хорошая и более безопасная альтернатива с открытым исходным кодом. - person Erfan Azhdari; 13.03.2020

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

person jwueller    schedule 10.05.2011
comment
значительно сложнее вы имеете в виду незначительно сложнее. Обфускация вам почти не поможет. - person Raynos; 10.05.2011
comment
Райнос: И вдобавок к этому вам будет сложнее отлаживать позже. - person John; 11.05.2011
comment
@John исходные карты;) - person James; 17.08.2017

Кто-нибудь пробовал nexe или pkg?

Это кажется хорошим вариантом. Утилита командной строки, которая компилирует ваше приложение Node.js в один исполняемый файл.

person Ligo George    schedule 17.03.2018
comment
nexe и pkg не добавляют никакой защиты кода. код написан на чистом javascript в двоичном виде, который они создают - person Félix Brunet; 21.02.2019

Прочтите эту статью.

Я покажу вам, как «по-настоящему» скомпилировать код Node.js (JavaScript) в байт-код V8. Это позволяет вам скрыть или защитить исходный код лучше, чем обфускация или другие не очень эффективные трюки (например, шифрование вашего кода с помощью секретного ключа, который будет встроен в двоичные файлы вашего приложения, поэтому я сказал «верно» выше).

Итак, используя инструмент bytenode, вы можете распространять двоичную версию .jsc ваших файлов JavaScript. Вы также можете объединить все свои файлы .js с помощью Browserify, а затем скомпилировать этот единственный файл в .jsc.

Проверьте репозиторий bytenode на Github.

person ho raj    schedule 06.12.2019

Пригодится Pkg.

Чтобы убедиться, что источники не включены в сгенерированный выходной файл, убедитесь, что package.json не указывает license (например, "license": "ISC"), который принудительно включал бы источники. Подробнее см. https://github.com/vercel/pkg/issues/190. .

person Markus Pscheidt    schedule 13.02.2021

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

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

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

person 张铁男    schedule 26.05.2016
comment
Это совсем не безопасно. Приложения C ++ можно легко реконструировать с помощью IDA Pro (с плагином шестнадцатеричных лучей) или Ghidra или Cutter, а приложения java можно реконструировать с помощью JDAX или JD-GUI. - person Erfan Azhdari; 13.03.2020