Javascript 库:混淆还是不混淆 - 这就是问题

发布于 2024-09-02 05:17:57 字数 1539 浏览 8 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(10

未央 2024-09-09 05:17:57

如果他们可以解码它,他们应该拥有代码(他们很可能会发现他们自己可以编写更好的代码 - 他们只是没有商业意识将所有[普通]组件放入该特定订单)。

实际上,您正在尝试通过技术措施解决业务问题。

任何称职的 Javascript 程序员都应该能够通过查看产品本身轻松地重新创建您所做的任何事情,而不需要任何代码。这并不是说你正在发明一些以前从未见过的新的神奇东西,你只是以一种新的方式将各个部分组合在一起,正如你自己承认的那样。这只是 JavaScript。

即使您混淆了脚本,它仍然会按原样运行,竞争对手可以直接使用它并运行它。即使代码混乱,一些定制也不应该太难。

在您的利基业务中,如果有人“窃取”您的脚本,您可能很快就会注意到。如果发生这种情况,那就是一个法律问题。如果你的竞争对手想在法律上保持清白,他们无论如何都必须从头开始重写脚本,这会自动为你赢得一些时间。

如果您的竞争对手在技术上无法在不完全窃取代码的情况下复制您的产品,那么代码是明文还是混淆的都没有什么区别。

If they can decode it, they deserve to have the code (they'll most likely find out they could have written better code themselves - they just didn't have the business sense to put all the [plain vanilla] components in that particular order).

So really, you're trying to solve a business issue with technical measures.

Anybody worth his salt as a Javascript programmer should be able to recreate whatever you do pretty easily by just looking at the product itself, no code needed. It's not like you're inventing some new magical thing never seen before, you're just putting pieces together in a new way, as you admit yourself. It's just Javascript.

Even if you obfuscate the script, it'll still run as-is, competitors could just take it and run with it. A few customizations shouldn't be too hard even with obfuscated code.

In your niche business, you'll probably notice pretty quickly if somebody "stole" your script. If that happens, it's a legal issue. If your competitors want to be in the clear legally, they'll have to rewrite the script from scratch anyway, which will automatically buy you some time.

If your competitors are not technically able to copy your product without outright stealing the code, it won't make a difference whether the code is in the clear or obfuscated.

旧城空念 2024-09-09 05:17:57

虽然您可以走上混淆器的漫长而危险的道路,但您通常不会看到它们在真实的生产应用程序中使用,原因很简单,它们实际上并没有做太多事情。你会注意到,Google 应用程序实际上是一堆专有且非常有价值的 JavaScript,当你仔细研究时,它只是真正最小化而不是混淆,尽管最小化器现在的工作方式,它们与混淆一样好。你确实需要知道你在做什么才能从它们中提取意义,但有决心的人会成功。

另一个问题是,混淆的代码必须有效,如果它有效,人们可以在不了解其中大部分内容的情况下将其批量撕毁,并以他们认为合适的形式使用它。当然,他们不能直接修改它,但在一些补丁上分层并不难,这些补丁重新实现了他们不喜欢的部分,而不必深入研究。这就是 JavaScript 的本质。

Google 等公司之所以没有遭受大量剪切粘贴竞争对手的困扰,是因为 JavaScript 只是软件包的一部分。为了对这些东西的使用方式和位置进行一定程度的控制,大型组件需要基于服务器。好消息是,您可以利用 Node.js 等工具来相当轻松地拆分客户端和服务器代码,而无需使用完全不同的语言重新实现各个部分。

您可能想要研究的并不是那么令人困惑,而是将您的应用程序分成可以从某种服务按需加载的部分,并且因为这些部分可以高度相互依赖,并且如果没有这个核心,大部分都无法发挥作用服务器上,您可以更大程度地控制使用该库的时间和地点。

您可以从 Google 如何转向元库中看到这一点,该元库只是充当其他库的加载器。这是统一 Google Apps、Google AdSense、Google 地图、Google Adwords 等加载调用的一步。

如果你想聪明一点,你可以像 Google 地图一样,在你的 JavaScript 库中添加一个毒丸,因为它们是动态提供的,这样它们只能在特定的子域中运行。这需要根据需要生成它们,虽然可以通过足够的专业知识将其删除,但它会阻止 JavaScript 文件的大规模复制粘贴使用。插入一个验证 document.href 的巧妙调用并不难,而在一个极力最小化的文件中找到所有这些实例将特别令人恼火,并且可能不值得付出努力。

While you can go down the long, perilous road of obfuscators, you generally don't see them used on real, production applications for the simple reason that they don't really do much. You'll notice that Google apps, which is really a whole heap of proprietary and very valuable JavaScript when you get down to it, is only really minimized and not obfuscated, though the way minimizers work now, they are as good as obfuscated. You really need to know what you're doing to extract the meaning from them, but the determined ones will succeed.

The other problem is that obfuscated code must work, and if it works, people can just rip it wholesale, not understanding much of it, and use it as they see fit in that form. Sure, they can't modify it directly, but it isn't hard to layer on some patches that re-implement parts they don't like without having to get in too deep. That is simply the nature of JavaScript.

The reason Google and the like aren't suffering from a rash of cut-and-paste competitors is because the JavaScript is only part of the package. In order to have any degree of control over how and where these things are used, a large component needs to be server-based. The good news is you can leverage things like Node.js to make it fairly easy to split client and server code without having to re-implement parts in a completely different language.

What you might want to investigate is not so much obfuscating, but splitting up your application into parts that can be loaded on-demand from some kind of service, and as these parts can be highly inter-dependent and mostly non-functional without this core server, you can have a larger degree of control over when and where this library is used.

You can see elements of this in how Google is moving to a meta-library which simply serves as a loader for their other libraries. This is a step towards unifying the load calls for Google Apps, Google AdSense, Google Maps, Google Adwords and so forth.

If you wanted to be a little clever, you can be like Google Maps and add a poison pill your JavaScript libraries as they are served dynamically so that they only operate in a particular subdomain. This requires generating them on an as-needed basis, and while it can always be removed with sufficient expertise, it prevents wholesale copy-paste usage of your JavaScript files. To insert a clever call that validates document.href is not hard, and to find all these instances in an aggressively minimized file would be especially infuriating and probably not worth the effort.

半山落雨半山空 2024-09-09 05:17:57

Javascript 混淆事实:

  • 没有人能够提供 100% 破解免费的 javascript 混淆。这意味着,随着时间和知识的积累,所有的混淆都可以被“消除”。
  • 缩小!=混淆:当你缩小时,你的目标是:减少代码大小。缩小后的代码看起来完全不同,并且阅读起来更加复杂(提示:jsbeautifier.com)。混淆有一个完全不同的目标:保护代码。使用的转换试图保护混淆代码免遭调试和窃听。混淆甚至可以产生原始代码的更大版本,这与缩小的目标完全相反。
  • 混淆!=加密——这是显而易见的,但却是人们常犯的错误。
  • 混淆应该使调试变得更加困难,这是它的目标之一。因此,如果正确完成,您可能会花费大量时间来尝试调试混淆代码。也就是说,如果正确完成,引入新错误是一个罕见的问题,您可以通过以下方式轻松找到它是否是混淆错误:暂时用非混淆代码替换代码。
  • 混淆不是浪费时间——它是一种工具。如果使用正确,你可能会让其他人浪费大量时间;)

Javascript 混淆小说:(我将跳过本节;))

Q2 的回答 - 建议的混淆工具:

  • 有关 javascript 混淆器的详细列表: malwareguru.org。我个人的选择是 jscrambler.com。

Q3 的答案 - 使用混淆代码的经验

  • 迄今为止,混淆没有引入新的错误
  • 更好的客户保留率。他们必须到源头去获取源头;)
  • 一些防病毒工具偶尔会报告误报。可以在部署任何新代码之前使用 Virustotal.com 等工具进行测试

Javascript obfuscation facts:

  • No one can offer a 100% crack free javascript obfuscation. This means that with time and knowledge every obfuscation can be "undone".
  • Minify != obfuscation: When you minify your objective is: reduce code size. Minified code looks completly different and its much more complex to read (hint:jsbeautifier.com). Obfucation has a completly different objective: to protect the code. The transformations used try to protect Obfuscated code from debugging and eavesdropping. Obfuscation can even produce a even bigger version of the original code which is completely contrary to the objectives of minification.
  • Obfuscation != encryption - This one is obvious but its common mistake people make.
  • Obfuscation should make debugging much much harder, its one of it objectives. So if it is done correctly you can expect to loose a lot of time trying to debug obfuscated code.That said, if it is done correctly the introduction of new errors is a rare issue and you can easily find if it is an obfuscation error by temporarily replacing the code with non obfuscated code.
  • Obfuscation is NOT a waste of time - Its a tool. If used correctly you can make others waste lots of time ;)

Javascript obfuscation fiction: ( I will skip this section ;) )

Answer to Q2 - Sugested obfuscation tools:

  • For an extensive list of javascript obfuscator: malwareguru.org. My personal choice is jscrambler.com.

Answer to Q3 - experiences of using obfuscated code

  • To date no new bugs introduced by obfuscation
  • Much better client retention. They must come to the source to get the source;)
  • Occasional false positives reported by some anti-virus tools. Can be tested before deploying any new code using a tool like Virustotal.com
追星践月 2024-09-09 05:17:57

混淆问题的标准答案:使用混淆器足以保护我的 JavaScript 代码吗?

IMO,这是浪费时间。如果竞争对手可以清楚地理解您的代码(假设它超过几千行......),那么他们应该可以轻松地对其进行反混淆。

我如何管理这些风险(
能够调试有错误的代码,
确保/尽量减少
混淆错误)

混淆会导致更多错误,您可以通过花时间调试它们来管理它们。这取决于编写混淆的人(无论是你还是其他人),最终只会浪费大量时间。

您的使用体验如何
生产中的混淆代码
环境?

  1. 被旁道攻击、重放攻击等完全绕过。Bugs

Standard answer to obfuscation questions: Is using an obfuscator enough to secure my JavaScript code?

IMO, it's a waste of time. If the competitors can understand your code in the clear (assuming it's anything over a few thousand lines...), they should have no trouble deobfuscating it.

How can I manage those risks (being
able to debug faulty code,
ensuring/minimizing against
obfuscation errors)

Obfuscation will cause more bugs, you can manage them by spending the time to debug them. It's up to the person who wrote the obfuscation (be it you or someone else), ultimately it will just waste lots of time.

What are your experiences of using
obfuscated code in a production
environment?

  1. Being completely bypassed by side channel attacks, replay attacks, etc.
  2. Bugs.
倦话 2024-09-09 05:17:57

在您编写完代码后,Google 的 Closure Complier 会对其进行混淆。也就是说,编写代码,通过编译器运行它,然后发布优化(和混淆)的 js。

如果您使用与库交互的外部 js,您确实需要小心,因为它会更改对象的名称,因此您无法分辨什么是什么。

Google's Closure Complier obfuscates your code after you finish writing it. That is, write your code, run it through the compiler, and publish the optimized (and obfuscated) js.

You do need to be careful if your using external js that interfaces with the lib though because it changes the names of your objects so you can't tell what is what.

潦草背影 2024-09-09 05:17:57

到目前为止,自动全代码混淆仅在闭包编译器的高级模式下可用。

使用 Closure Advanced 模式编译的代码几乎不可能进行逆向工程,即使通过美化器也是如此,因为整个代码库(包括库)都被混淆了。平均也小 25%。

仅仅缩小的 JavaScript 代码(YUI Compressor、Uglify 等)在经过美化器后很容易进行逆向工程。

如果您使用 JavaScript 库,请考虑使用 Dojo Toolkit,它与 Closure Compiler 的高级模式编译兼容(经过少量修改)。

http://dojo-toolkit.33424 .n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t

Automatic full-code obfuscation is so far only available in the Closure Compiler's Advanced mode.

Code compiled with Closure Advanced mode is almost impossible to reverse-engineer, even passing through a beautifier, as the entire code base (includinhg the library) is obfuscated. It is also 25% small on average.

JavaScript code that is merely minified (YUI Compressor, Uglify etc.) is easy to reverse-engineer after passing through a beautifier.

If you use a JavaScript library, consider Dojo Toolkit which is compatible (after minor modifications) with the Closure Compiler's Advanced mode compilation.

http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t

千里故人稀 2024-09-09 05:17:57

您可以采用开源商业模式,并使用 GPL 或 Creative Commons BY-NC-ND 或类似协议来许可您的脚本

You could adopt an open-source business model and license your scripts with the GPL or Creative Commons BY-NC-ND or similar

银河中√捞星星 2024-09-09 05:17:57

虽然混淆通常是一件坏事,但恕我直言,对于 Javascript,情况有点不同。这个想法不是为了混淆 Javascript 本身,而是为了生成更短的代码长度(带宽很昂贵,而且首次使用的用户可能会因为等待 Javascript 第一次加载而感到恼火)。最初称为缩小(使用诸如 minify 之类的程序),它已经发展了很多,现在可以使用完整的编译器,例如 YUI 编译器和 Google Closure 编译器。这样的编译器执行静态检查(这是一件好事,但前提是您遵循编译器的规则)、缩小(例如用“ab”替换长变量名)和许多其他优化技术。最后,您得到的是两全其美的结果,即使用非编译代码进行编码,并部署编译的(缩小的和模糊的)代码。不幸的是,您当然还需要更广泛地测试它。

While obfuscation in general is a bad thing, IMHO, with Javascript, the story is a little different. The idea is not to obfuscate the Javascript itself but to produce shorter code length (bandwidth is expensive, and that first-time users may just be pissed off waiting for your Javascript to load the first time). Initially called minification (with programs such as minify), it has evolved quite a bit and now a full compiler is available, such as YUI compiler and Google Closure Compiler. Such compiler performs static checking (which is a good thing, but only if you follow the rules of the compiler), minification (replace that long variable name with 'ab' for example), and many other optimization techniques. At the end, what you got is the best of both worlds, coding in non-compiled code, and deploying compiled (, minified, and obfuscated) code. Unfortunately, you would of course need to test it more extensively as well.

鹿! 2024-09-09 05:17:57

不管事实是否是混淆器,任何称职的程序员都可以在大约花费您所花费的时间内重现您所做的任何事情。如果他们偷了你所做的事情,你可以起诉他们。因此,从业务角度来看,底线是,从发布那一刻起,您在竞争对手赶上之前实施设计所花费的时间大致相同。时期。这就是您获得的全部领先优势。剩下的就是你比竞争对手更快地创新,并且至少和他们一样营销。

The truth is obfuscator or not, any programmer worth his salt could reproduce whatever it is you did in about as much time as it took you. If they stole what you did you could sue them. So bottom line from the business point of view is that you have, from the moment you publish, roughly the same amount of time it took you to implement your design until a competitor catches up. Period. That's all the head start you get. The rest is you innovating faster than your competitors and marketing it at least as well as they do.

爱情眠于流年 2024-09-09 05:17:57

使用 Flash 编写您的网站,或者更好的是使用 Silverlight。这将为您的公司提供无与伦比的 GUI,让您的竞争对手垂涎欲滴。但是 flash/dotnet 的编译性质不允许它们轻松地进入您的代码。这对你来说是双赢的局面;)

Write your web site in flash, or better yet in Silverlight. This will give your company unmatched GUI, that your competitors will be salivating about. But compiled nature of flash/dotnet will not allow them easily pick into your code. It's a win/win situation for you ;)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文