如何保障程序的安全性？避免程序包被反编译之后泄漏？

服务器端尽可能多，风控、律师函，好调试的地方干脆不服务

参考微信就行了

@murmur 服务器端尽可能多，指的是尽可能拆分微服务吗？

好调试的地方干脆不服务？指的是什么？

@hxy91819 意思是不提供 web 端。。。

我没写对，就是说把 app 做成严重依赖服务器的那种，本地功能尽可能少，只要在本地的很容易被破解

反编译没有什么可读性了，甚至一堆报错，让原来的开发来反编译还原代码，估计都够呛

哦我看错了，微服务这个得把关键服务写到 dll 里，然后 jni 调用，这部分代码最好还有密钥加密，密钥是 u 盘，只有插了 key 才能还原核心代码

这么折腾还不满意就没法了，拆分也是可以的，拿到一部分代码跑不起来

个人认为没有绝对的安全，对于大部分产品来说，如果破解成本大于收益，则可以认为是相对安全的。因此权衡好保证安全所付出的成本与收益，自身被破解付出的成本，以及破解者破解付出的成本与收益即可。

@murmur 这个我能理解，本地尽量不要有关键业务逻辑

按这个时代来说，防软件拷贝是一种较旧的思维方式，不能说落后，至少跟时代不相配
现在很多服务型的软件，软件本身不值钱（或者占比少），数据才是重要的

客户的这种担心，源自几个原因：
1. 开发成本很大（占比）
2. 主要的 idea 就包含在软件中，copy 走就连同 idea 一起盗取了
3. 部署简单，偷盗者或者购脏者能迅速“华丽转身”变成竞争对手

1/2 都较难解决，建议在第三点下手，将部分核心内容交由客户自己部署（通过密码或 key ），就是拷贝部署后的成品不能用，只能通过掌控密码的人重新部署这部份
注意：说的不是部署后要 key 运行，而是部署本身就需要 key，部署后的模块换设备就不能运行，要重新部署

@flywith24 有没有哪些常见的可以提高破解成本的方法？

@hxy91819 vmprotect

@imn1 感觉我这个项目 1 和 2 的原因都有，只能尽量提高盗取者的成本了。第三点在部署上着手，限制只能在有 key 的地方部署感觉可行。

@hxy91819

java 的无非是代码混淆，重写 classloader，jni，c 的部分混淆就多了，问题是混淆加密花指令垃圾代码可能微微影响性能，甚至混淆的不好直接挂了都有可能

如果是不太涉及性能可以用 lua 等动态语言写一部分代码，lua 的解析器可以完全定制，你拿不到映射关系是没法反编译的

然后如果是 web 服务这种可以插暗桩，比如特殊的 header 和输出，记得以前有个 ftp 服务器就用这种起诉别人用盗版

只要你的东西足够诱惑，防是防不住的，律师团队肯定得有

知道谁偷走了代码还好说，就怕别人偷走了代码开了公司产品都开发好了甚至比你先申请软件著作权你还不知道

@murmur 感谢，收获不少。

技术不能解决的就用法律手段

> 答曰：需要避免运维人员在发布过程中拷贝……

等会, 那开发拷贝源码你们是怎么避免的? 源码不是比包更要紧吗?

听起来像拍脑袋的决定, 运维能碰机器大不了给机器打个镜像在家里倒出来谁防得住?

防不住，运维完全可以镜像整个服务器，你拿什么防？

@namelosw 嗯，确实问题多多，更需要跟需求方再多沟通确认下。

@xuanbg 是的，有道理。

歪个楼，后端加密我都能理解，我遇到过把接口返回的 json 用 des 加个密，前端再来解密，而且密钥直接写死在 js 里……

放心，没有人会去破解你的屎山，有这个功夫随便收买几个关键的人就完事了，讲一下业务逻辑

我们公司就要做这个功能,说是给客户发的许可证是有时间期限的,怕他们改代码,或者把代码卖给别人
然后公司采购加密狗,采购回来发现那个是前端加密的,服务端不支持,现在暂时搁置了

在调研过程中找到这个,我没试,你可以看看
https://github.com/core-lib/xjar

@taro0822 这种是防止报文被嗅探吧,有些安全检查要求报文里不能有明文密码

加钱可以避免新的需求... 特别是不合理的需求

@taro0822 估计是为了应付检查吧，des 算专业的了，水的 base64 也算加密

@zypy333 感觉不错，学习下

@zypy333 谢谢，这个看起来不错。