求助前端JS都是用什么加密的
发布网友
发布时间：2022-04-22 08:20
共2个回答
懂视网
时间：2022-04-22 20:13
Web前端JS代码需要保护吗？
这得具体情况具体分析。
1、如果只是写一段web页面图片轮播，或是跑马灯效果等等之类简单的功能。那不需要保护。
2、如果是精心设计一个绚丽的特效，如果想要保护这段自己付诸幸苦实现的特效代码不被他人随意拿去使用，那应该保护这段JS代码！
3、如果页面上有重要的功能是用JS代码管控的，比如交易逻辑、帐号密码信息、个人隐私、甚至有与远程服务器或数据库的通信等等，那么相关的js代码非常应该被保护、应该做JS代码防盗保护！
否则可能引起被黑客分析、攻击等严重问题。安全相关的事情，从来都要防患于未然、不可心存侥幸。除非它对你毫不重要。
如何保护Web前端JS代码？
1、打包&压缩
有人认为打包、压缩就是对JS代码的保护。确实，打包在一定程度上可以起码些许保护作用，好像看起来是如此。但打包、压缩的目的并不是为了保护JS代码，而是为了使用方便、减小代码体积，方便使用、便于传输。比如模块化的编程可能产生200个JS文件，如果使用时逐一用“script src”进行引用……这是种折磨，不管是对于代发人员，还是网络加载（浏览器也会生气！x_x）。
类似Webpacket、Gulp进行打包，可以将这些多个JS合成到一个文件，并且可能会进行回车、换行、空格的删除，以实现代码压缩，也有一些简单混淆操作：把长变量名改为统一风格的短变量名等。然后，最终生成的一个文件。代码总量减小了、可读性差了、使用方便了。同时让有些人认为这也实现了JS代码保护。其实、实际上、当然的代码并没有被保护：可读性依旧，只是代码量大了一些而已，只要稍稍耐心的读代码，会发现，代码依然是很易理解的，没有多少安全性可言。
2、混淆&加密
前端JS代码的保护，必需要混淆和加密共用。
单独的JS源代码加密，是行不通的，更不可能有所谓的JS不可逆加密。因为代码在浏览器端执行时，必须转解密还原成原始代码，才能被浏览器的JS引擎识别和运行。在解密后，会存在完整的原始JS代码。这是非常不安全的存在，有多种方法可将原始的JS代码显示出来。
JS代码混淆被不少开发人员认为是不够高端的JS代码保护方式，听起来不如JS源码加密更具安全性。事实上，混淆也有多个级别。比如比较低端的字符搜索和串替换、随机插入伪僵尸代码、字符串十六进制化等等。而也有高端的手法，会先进行语法分析、词法分析，重建语法树，相当于已经实现了一个JS引擎，在引擎中处理代码，那么，就可以在其中任意一步进行自由度极高的操作，比如在语法树中插入新的语法结构、比如可以将字符串全部提取并进行加密、可以对变量进行整体有规则化的重定义使无意义化等等。这样就可以实现真正的代码重建。这样重建的JS代码安全性，将会有一个质的提升。
当正真的混淆和加密联合使用，如JShaman JS保护，
可以实现真正的JS代码安全保护。JS混淆中融入JS加密，JS加密中又嵌入JS混淆。这样保护后的代码，即使在客户端执行环境中被逆向还原，得到的也是大量含义不明的函数、代码、字符串。特别重点是：代码已经经过了重建，这时逆向得到的也是分离后的重建的无意义JS代码、大量的僵尸代码、混淆的字符串、不明含意的变量。可读性与原始代码相比……天壤之别。
固执的人或许还会说：没有破解不了的保护方案，只要我认真、用心、用时的分析，还是能分析出原始代码含意的，确实，可能如此。
但是，原本的代码，可能只需要读10分钟，而从这样保护后的JS代码读取原始含意，可能需要……10个月。而这时候，我们的JS代码可能已经更新到下一版了。
JS代码保护的目的已经达到了，不是吗？
热心网友
时间：2022-04-22 17:21
写过 js混淆器，谈一些浅显的个人看法。
个人认为，js的不可读化处理分为三个方面：压缩（compression）、混淆（obfuscation） 和加密（encryption）。 （不可读化处理，这是我自己发明的术语，一切会增加代码不可读性的代码转换, 都可以这么叫，“增加代码不可读性”可能是代码转换的结果或者目的）.
1. 压缩
这一操作的目的，是让最终代码传输量 （不代表代码量, 也不代表文件体积）尽可能小。压缩js的工具，常见的有：YUI Compressor、UglifyJS、Google Closure Compiler 等。
通常在代码压缩的过程中，只改变代码的语法，代码的语义和控制流不会有太大改变。
常见做法是把局部变量缩短化，把一些运算进行等价替换等。代码压缩对于代码保护有一些帮助，但由于语义和控制流基本没变，起不了太大作用。
在压缩层面上，代码不可读只是一种附带伤害，不是最终目的。
2. 混淆
这一操作的目的，是让代码尽可能地不可读，主要用作代码保护。
让代码不可读，增加分析的难度，这是唯一目的。混淆过后文件体积变大一倍也没关系，代码量变多也没关系，运算慢50% 也没关系。
常见的做法有：分离常量、打乱控制流、增加无义代码、检查运行环境如果不对就罢工，等等。
在混淆层面上，代码不可读是最终目的。
值得一提的是，Google Closure Compiler 的 Advance Level Compression 会压缩类和对象的成员，其压缩结果很难分析，也可以认为是一种混淆，但兼容性不太好。
广告时间：我写的 js混淆器，中文名叫 “看起来很厉害的 JS 编译器”， 英文名叫做 The Impressive JS.Segment.Compiler ， 看起来很厉害的 JS 编译器 。
3. 加密
说实话我很难对加密做一个定义，因为加密在Web界有太多歧义了。
有加密就有解密，意味着加密操作可逆，密文可以明文化。
就这样看来，在Web界，可以称之为加密的东西包括：HTTPS传输、JavaScript实现对称加密或者不对称加密等等。
这样看来，不可逆的代码压缩和混淆就不能列入加密这个范畴了。
非要找一个可以称之为加密，又经常被人误解为压缩和混淆的东西，Dean Edwards 的 Dean Packer/Unpacker 可以拿来做个例子。
比如我们把 var num=1;alert(num);
输入 Dean Packer，pack 一下，得到这么一串东西，是不是看着非常像被压缩和混淆过的代码？
把上面那串意义不明物拿来 unpack 一下，得到了原文。
实际上 Dean Packer 只是对源码进行了一个字符串变换，没有深入到代码语法层面，你可以拿 "Hello world, 你好师姐" 来试试。
用Online JavaScript beautifier 能轻松把这串东西还原为 “Hello world, 你好师姐”。
可以看出，代码加密意味着：将代码明文进行可逆的变换（加密），生成密文；将密文进行逆变换（解密），可以还原明文；最终运行环境运行的是解密代码。
结语
实际上大家对压缩、混淆、加密这三个概念还是挺不清晰的，我在这里说一些个人见解，希望有帮助。
在现实项目中，我是多种手段结合的：
对于不需要做代码保护的项目，比如个人博客，做代码压缩，加快载入速度，这就够了。
对于需要做一些代码保护，防止抄袭的项目，可以在源码中加入一些开发者的信息和防护代码，然后混淆和压缩。很不幸的是，我这方面总是做得不太好，防君子防不了小人啊哈哈。
对于需要严格加密的项目，可以用 混淆、压缩、加密、签名检查 等多种手段，这我就不清楚了，等大婶来补充。
