node.js - 代码保护?

IT技术 javascript node.js source-code-protection
2021-02-24 16:07:18

我想在我的下一个项目中使用 node.js,但我的老板不喜欢我们的竞争对手可以阅读源代码。

有没有办法保护 JavaScript 代码?

6个回答

您可以使用节点的 NativeExtension 完成此操作

您将有一个boostrap.js为 .jse 文件添加扩展处理程序的文件

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

require("YourCode.jse");

YourCode.jse 将是您的源代码的加密版本(解密密钥不会以纯文本形式存在,因为解密过程发生在本机扩展中)。

现在您有了 NativeExtensionsdecrypt函数,可以将源代码转换回 javascript。只需让您的构建过程创建.jse所有文件的加密版本并将其发布给您的客户。他们还需要本机扩展,但现在您已经使修改代码变得更加困难而无需太多努力。您甚至可以让本地扩展回电并检查许可证信息以帮助防止盗版(请记住,这不会阻止盗版,没有解决方案)。

这是不安全的。密钥是否隐藏在二进制module中并不重要。一旦客户端解密并加载您的module,他们只需调用 console.log(yourmodule.yourmethod.toString()) 并打印出您的源代码。
2021-04-21 16:07:18
如果有人感兴趣,我已经将@Chris T 的想法打包到一个可用的github 存储库中但是,请注意,这仍然是锁定前门并将钥匙留在户外地毯下 - 看起来它已锁定,但实际上并非如此。
2021-05-01 16:07:18
没问题,让我知道进展如何,我也计划在我的一个项目中使用这种方法。有人应该为这种事情开发一个图书馆
2021-05-07 16:07:18
@dlongley 不会将您的函数源存储在闭包中并返回一个可公开访问的方法,该方法调用闭包中的内部私有方法会阻止通过简单地使用 toString() 来访问实际代码吗?
2021-05-08 16:07:18
@ChrisT 这并不总是关于实用性..一般来说,在分发之前运行 uglify 就足够了,即使使用 JS 美化器,你也不会得到评论或原始变量名,这确实使逆向工程变得更加困难. --- 即便如此,任何能够做到这一点的人,也可能是自己写的。
2021-05-18 16:07:18

只需包括一个许可协议并给他们源代码。无论如何,他们可能想要自定义它。

对我来说,这是个好主意,但对我的老板来说,这太危险了。如果世界可以不那么复杂...
2021-04-21 16:07:18
这是正确的答案,IMO。没有万无一失的方法可以阻止客户做你害怕的事情。如果您有兴趣让它变得更加困难,您可以尝试本线程中提出的一些混淆解决方案,或者查看 v8 的堆快照功能。但是,许可协议至关重要。-- 刚刚意识到这是 '11 而不是 '12,哦,好吧!希望它成功了:)
2021-05-16 16:07:18

因为我刚刚在 80 多个文件中完成了一个巨大的纯 Nodejs 项目,所以我遇到了与 OP 相同的问题。我的辛勤工作至少需要最低限度的保护,但 NPMjs 操作系统社区似乎没有涵盖这个非常基本的需求。雪上加霜 JXCore 包加密系统上周在几个小时内就被破解了,所以回到混淆......

所以我创建了完整的解决方案,处理文件合并、丑化。您可以选择不合并指定的文件/文件夹。然后将这些文件复制到合并文件的新输出位置,并自动重写对它们的引用。

node-uglifier 的 NPMjs 链接

node-uglifier 的 Github 仓库

PS:如果人们愿意做出贡献,让它变得更好,我会很高兴。这是小偷和像你这样努力工作的程序员之间的战争。让我们一起加油,增加逆向工程的痛苦!

我知道这是一篇旧帖子,但我仍在寻找一种解决方案来保护我的代码免受盗版。难道你没有找到一个更可靠的解决方案来达到这个目的吗?!田纳西州
2021-04-24 16:07:18
是否可以在没有混淆的情况下保留很少的关键字?
2021-04-27 16:07:18

非常清楚,客户端 Javascript(从远程服务器下载到标准 Web 浏览器中)无法防止查看和/或修改,无论您如何混淆它,因为原始源的重建(“去混淆”)在技​​术上是微不足道的。(Javascript混淆只是广泛使用的安全误称“通过默默无闻的安全”的另一个例子。)

如果您希望使用 Javascript 和 Node.js 来提供受保护的“产品”(在这种情况下是指需要在您的公司无法控制的服务器上安装的应用程序或服务),您也不能将其作为唯一可用的选项来保护您(混淆)不提供此类保护。

应该注意的是,即使您的产品是作为二进制可执行文件提供的,也不能保证您可以保护它所包含的知识产权,因为任何二进制文件都可以反编译为可理解的格式。在这种情况下,基于将低级机器代码(由反编译提供)转换为现代编程语言使用的高级逻辑结构所需的过多资源(时间/专业知识),我们享有一定程度的安全性。(这来自曾经将 CP/M 反编译成对其内部设计的理解的人。;)

然而,一切都没有丢失:如果我们假设可以以编程方式保护知识产权(陪审团仍在此问题上),则有一种方法可以以安全的方式提供基于 Node.js 的产品,但它不适用于技术上不冒险,因为它需要对 Node.js 源代码进行大量重构(添加对加密安全库的支持,并删除——或以其他方式保护——您的专有库的对象反射。)

虽然这是真的,但应该说,如果你可以使用 requirejs 对用 say coffeescript 编写的产品进行逆向工程,然后编译成单个 js,然后通过闭包运行......从加密到自定义扩展,使用经由支暴露module加载它...你可能没有NEED以反向工程它复制任何给定的功能。
2021-05-03 16:07:18

服务器端 javascript 代码是完全封闭的源代码。没有人能读懂。

客户端 javascript 代码是完全开源的。每个人都可以阅读它。

对于后者,您无能为力,但同样适用于 RoR、ASP.NET、PHP 等。

除非您公开提供,否则实际的服务器代码是关闭的。

如果您制作了一个库并试图将其作为第 3 方来源出售,那么它是开放的并且可能被盗。当然,您可以起诉他们侵犯版权。

有很多像extjs这样的大公司出售可能被盗的库,这就是为什么他们实际上向您出售的是代码和支持服务。

大多数建立在节点上的商业项目都是服务。

@FlashFan 所以你创建一个图书馆并出售它。它是开源的。
2021-04-20 16:07:18
这将是一个带有网络界面的服务。网络界面将是实时的,因此 node.js 将非常适合。但是,是的,它将是一种商业产品。我无法改变这一点;)
2021-04-25 16:07:18
@FlashFan 如果他们侵犯了您的版权未经许可使用您的代码,那么您可以起诉他们。欢迎盗版。
2021-04-28 16:07:18
我们想在产品中使用它。当竞争对手安装此产品时,他将看到源代码。
2021-04-30 16:07:18
这就是为什么所有 node.js 商业项目都是服务而不是产品的原因。您可以使用UglifyJS混淆您的源代码
2021-05-02 16:07:18