Я хочу использовать node.js в своем следующем проекте, но моему начальнику не нравится, что наши конкуренты могут читать исходный код.
Есть ли способ защитить код JavaScript?
Я хочу использовать node.js в своем следующем проекте, но моему начальнику не нравится, что наши конкуренты могут читать исходный код.
Есть ли способ защитить код JavaScript?
Вы можете сделать это с помощью 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
версии всех ваших файлов и передать их вашим клиентам. Им также понадобится собственное расширение, но теперь вы немного усложнили процесс изменения кода без особых усилий. Вы даже можете сделать так, чтобы внутренний добавочный номер звонил домой и проверял информацию о лицензии, чтобы предотвратить пиратство (имейте в виду, что это не остановит пиратство, для этого нет решения).
m._compile(MyNativeExtensions.decrypt(..))
, но тогда все, что нужно сделать, чтобы изменить ваш источник, - это изменить m._compile
на console.log
- person Christopher Tarquini; 07.02.2012
require
для проверки ресурсов приложения перед проверкой файлов).
- person Christopher Tarquini; 13.06.2012
Function.prototype.toString
работать с кодом, который вы компилируете и добавляете в среду выполнения на C ++.
- person Christopher Tarquini; 10.01.2014
Просто включите лицензионное соглашение и предоставьте им исходный код. Они все равно могут захотеть его настроить.
Поскольку я только что завершил огромный проект на чистом Nodejs из 80+ файлов, у меня возникла та же проблема, что и у OP. Мне нужна была хотя бы минимальная защита для моей тяжелой работы, но, похоже, эта основная потребность не была покрыта сообществом ОС NPMjs. Добавьте соли в травму, система шифрования пакета JXCore была взломана на прошлой неделе за несколько часов, так что вернемся к обфускации ...
Итак, я создал законченное решение, которое обрабатывает слияние файлов, уравнивание. У вас есть возможность исключить указанные файлы / папки при слиянии. Затем эти файлы копируются в новое место вывода объединенного файла, и ссылки на них автоматически перезаписываются.
Github репозиторий node-uglifier
PS: Я был бы рад, если бы люди внесли свой вклад, чтобы сделать его еще лучше. Это война между ворами и трудолюбивыми программистами вроде вас. Давайте объединим наши силы и усложним реверс-инжиниринг!
Чтобы быть предельно ясным, клиентский Javascript (загруженный с удаленного сервера в стандартный веб-браузер) не может быть защищен от просмотра и / или модификации, независимо от того, как вы его запутываете с момента реконструкции («деобфускации») исходного источника. технически тривиально. (Обфускация Javascript - это просто еще один пример широко используемого неправильного названия безопасности "безопасность через неясность".)
Если вы хотите использовать Javascript и Node.js для предоставления защищенного «продукта» (который в данном контексте является приложением или сервисом, требующим установки на сервере, который не контролируется вашей компанией), вы не можете защитить его как единственный вариант, доступный для у вас (обфускация) такой защиты нет.
Следует отметить, что даже если ваш продукт предоставляется в виде двоичного исполняемого файла, это не гарантирует, что вы сможете защитить интеллектуальную собственность, которую он содержит, поскольку любой двоичный файл можно декомпилировать в понятный формат. В этом случае мы пользуемся некоторым уровнем безопасности, основанным на чрезмерных ресурсах (время / опыт), необходимых для преобразования машинного кода низкого уровня (как обеспечивается декомпиляцией) в логические конструкции более высокого уровня, используемые современными языками программирования. (Это от того, кто однажды декомпилировал CP / M, чтобы понять его внутреннюю структуру вручную.;)
Однако еще не все потеряно: если мы предположим, что интеллектуальную собственность можно защитить программно (жюри еще не принято), есть способ предоставить продукт на основе Node.js безопасным способом, но он не для технически несложный, поскольку потребует существенного рефакторинга исходного кода Node.js (для добавления поддержки криптографически безопасных библиотек и удаления - или иным образом защиты - отражения объектов для ваших проприетарных библиотек).
Код javascript на стороне сервера полностью закрыт. Никто не может это прочитать.
Код javascript на стороне клиента полностью открыт. Это может прочитать каждый.
В последнем случае вы ничего не можете сделать, но то же самое относится к RoR, ASP.NET, PHP и т. Д.
Фактический серверный код закрыт, если вы не сделаете его общедоступным.
Если вы создаете библиотеку и пытаетесь продать ее как сторонний источник, она открыта и может быть украдена. Конечно, вы можете подать на них в суд за нарушение авторских прав.
Существуют различные крупные компании, такие как extjs, которые продают библиотеки, которые могут быть украдены, поэтому то, что они на самом деле продают вы код и служба поддержки.
Большинство коммерческих проектов, построенных на узле, являются сервисами.
JXcore (дистрибутив node.js 0.11.X) имеет собственную функцию упаковки JX, которая защищает исходный код и ресурсы. Вы даже можете выбрать, можно ли использовать этот конкретный пакет из других приложений или нет. (автономная библиотека OR)
Допустим, у вас много файлов JS и т. Д., И точка входа в ваш модуль выглядит примерно так:
exports.doThis = function() { ...... };
если вы просто вызовете метод ниже и скомпилируете его в пакет JX, исходный код будет безопасным.
jxcore.utils.hideMethod(exports.doThis);
это (скрытие метода) требуется только для входного файла, поскольку все остальные вспомогательные файлы JS недоступны из вызывающего приложения.
Для запуска пакетов JX вам понадобится JXcore.
Дополнительную информацию можно получить на сайте JXcore.
Упакуйте свою основную логику в модули. Эти модули можно собрать, а затем запустить через закрытие Google. Вы даже можете сделать это как Grunt task как часть процесса сборки.
Это старый вопрос, но на него стоит обратить внимание. Примечание: ничто из того, что вы делаете, не скроет ваш код по-настоящему, но и через .Net (C #) или Java, если на то пошло, тоже ничего не будет. В общем, простого использования такого инструмента, как uglify или closure, должно быть достаточно для запутывания. Будучи модульным и используя закрытие, вы действительно можете выполнять множество оптимизаций, которые в противном случае были бы затруднены.
Вы можете использовать EncloseJS - компилятор для проектов node.js. Он действительно компилирует JavaScript в собственный код, а ваши исходные коды не включаются в двоичный код.
"license": "ISC"
в package.json? Удалите это, чтобы избавиться от источников.
- person Markus Pscheidt; 13.02.2021
вы можете использовать packer для nodejs для обфускации вашего скрипта ...
Вы не можете быть абсолютно уверены, что никто не сможет прочитать ваш код. Однако вы можете использовать обфускацию или минификацию, что может значительно усложнить декодирование вашего кода. Одним из примеров обфускатора / минификатора является Closure Compiler для JavaScript от Google.
Кто-нибудь пробовал nexe или pkg?
Это кажется хорошим вариантом. Утилита командной строки, которая компилирует ваше приложение Node.js в один исполняемый файл.
Прочтите эту статью.
Я покажу вам, как «по-настоящему» скомпилировать код Node.js (JavaScript) в байт-код V8. Это позволяет вам скрыть или защитить исходный код лучше, чем обфускация или другие не очень эффективные трюки (например, шифрование вашего кода с помощью секретного ключа, который будет встроен в двоичные файлы вашего приложения, поэтому я сказал «верно» выше).
Итак, используя инструмент bytenode, вы можете распространять двоичную версию .jsc ваших файлов JavaScript. Вы также можете объединить все свои файлы .js с помощью Browserify, а затем скомпилировать этот единственный файл в .jsc.
Проверьте репозиторий bytenode на Github.
Пригодится Pkg.
Чтобы убедиться, что источники не включены в сгенерированный выходной файл, убедитесь, что package.json
не указывает license
(например, "license": "ISC"
), который принудительно включал бы источники. Подробнее см. https://github.com/vercel/pkg/issues/190. .
У меня есть идея. Защищайте cpp
или java
приложение вместо js.
utf-8
файловый ресурс.cpp
или java
для загрузки всего файла в linux pc
или arm computer
, убедитесь, что у вас есть надежный пароль, или закройте ssh port
или отключите видеопорт и просматривайте ПК с Linux только через Интернет.Это очень похоже на черный ящик: клиенты ничего не могут сделать с вашим кодом.