谈谈源码保护著作

最近开始着手关注源码保护,具体原因则是产品的源码被窃取了。目前这种窃取的方式，大约估计了一下，就是下载了web端的源码。

这里首先必须声明一下，web端源码的窃取，目前是不影响app的。这是值得庆幸的地方，项目分两处存放，并且有80%的代码实现并不相同。所以拿到web源码，对于app是无影响的。这里要谈谈著作保护。

就法律而言，公司首先应该做的是申请著作权——软著。这是可以实施的最后方案。之所以不是最开始，考虑到每个人事情很多，也无暇顾及那些窃取的小打小闹。这种小打小闹到了一定程度，如果可以采取诉讼，请求法律保护，我想这是极好的。

为何大家对googlepay 或者 appstore 比较爱戴。最重要原因是平台大，可以发布个人产品，实现个人盈利收入。但是仅仅是这些优势是不够的。那么另外的优势就是两者平台可以给予个人或者公司产品实施保护机制。能够保护产品的源码不被窃取。当然这里的窃取值得是一般人，而不是非常人:google pay 或者appstore。前面两者既然能够获取我们的安装包，自然可以窃取了。那么还有哪些公司具备这个能力呢？各种第三方下载/提供浏览的平台。这些指的是app当然不涉及web。

web平台的产品，我们可以有哪些方式实施保护呢?

大家都知道，如果尽可能的把代码写进Js而不是html层，那么保护起来是不是更容易了。这个只是比之前的html稍微更方便保护了，但绝不是可以完全控制不被copy。我这里将说明三种方式，但是不是使用广泛的，这个未知。我曾经看过很多前端项目可以直接被拷贝下来，这点令人难以接受。

方案一:

实施代码加密。代码加密的机制，是很多论坛或者博客写得数量较多的。将可阅读的变成不可阅读的，将可以试图理解的转变为不可理解的,例如加密，又例如base64处理等等。看起来，方式确实OK,但是破解同样也是简单的。不过，我们可以控制流程的实现加密的key多变，加载的时候不同的Key进行解密，最后加载。方式虽然比之前一次性的加密解密要难度大，但是多花时间也是可以破解的。

方案二:

代码混淆。项目源码混淆，是一种有效的机制。不过此种方式的后果也是明显可见的，可维护性难度变大。甚至最后极其容易采坑。采坑的可能是自己，更有可能是他人。混淆的方式很多。简单的举例，将某一处变量进行逐渐分散被其他变量赋值，同时变量名字类似，

另外将用到的关键的function也进行类似的操作，function的不同名字多个实现。最后在catch处进行调用自己定义的function:例如调到自己的官网。如果仅仅是这种方式，也是不够，还是容易被直接发现。有心的一旦搜索Location则无处可盾。所以这个时候，将自己的关键处理代码进行加密或者base64或者其他方式处理，然后调用的时候eval即可。可见，这种混淆的方式实现起来要注意很多细节。不然自己运行的时候，也会指向自己一处，如果该产品具备两个url指向的时候。另外，项目之中进行这种操作，要多使用随机方法，这种益处在于窃取的对象使用过程中，会不定期不定时出现bug,但是窃取者一旦使用并且推荐重构的产品，那么他的产品不稳定性，必然会给他自己带来结果:信誉下降。

方案三:

这种方案是最不建议采用的，但是又是最有效的。在这里仍旧介绍一番。采用ws方式，框架分两层。基础一层，仅仅是被发下或者请求源码，源码到这里也就是在NetWor不可识别的二进制流。内存中显示出字符串，将源码文件内容的字符串进行加载。注意，这里是用到哪里就加载到哪里，不用的不需要加载。简单地说明一下，每个文件内容的下发都是数组形式，数组内部包括key,content,不用content的key不同。并且实施校验机制。校验key,key值可变。key值的产生源于时间戳。所以每个用户请求下发的内容因为时间戳的不同而变化，从而实现了动态变化。对于破解的而言，难度加大了许多。那么破解这个需要什么功底:抓取网络包，将包数据按照某种方式进行破解。这里的某种方式也是经过层层加密，加密必含参数时间戳。第二层：内存中获取content，进行加载。这样就实现了源码的保护。浏览这种web几乎看不到任何js代码，一切都在内存中进行。不过最好的方式还是各大浏览器进行支持吧。直接性的保护web源码，也许就不会有这么多盗窃项目的存在了。

另外盗窃产品思想，下次谈。