V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
hxy91819
V2EX  ›  程序员

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

  •  
  •   hxy91819 · 5 天前 · 1329 次点击

    不瞒大家,接到这个需求的时候我第一感觉是离谱。

    在我的认知里,只有客户端程序需要避免被反编译,重新打包,常见的处理方法是混淆。如果是为了防止软件被破解,可以增加注册码,或者全程联网。

    现在接到的这个需求是后端微服务也要考虑安全性、防泄漏。我琢磨着后端程序不都是放在自家机房或者是云服务器上吗?怎么还要考虑泄漏问题?

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

    好吧,就算开发出来的代码被拷贝走了,一般后端微服务部署方案非常复杂,不是单单拷贝了一个部署包或者镜像就能用的啊?

    要是说反编译导致商业机密泄漏,好吧,参考这个知乎问题,我觉得没多大反编译的价值: https://www.zhihu.com/question/306333255

    所以我现在非常怀疑是不是我出发点就错了,求指点迷津!

    27 条回复    2021-01-18 10:20:05 +08:00
    murmur
        1
    murmur   5 天前
    服务器端尽可能多,风控、律师函,好调试的地方干脆不服务

    参考微信就行了
    hxy91819
        2
    hxy91819   5 天前
    @murmur 服务器端尽可能多,指的是尽可能拆分微服务吗?

    好调试的地方干脆不服务?指的是什么?
    murmur
        3
    murmur   5 天前
    @hxy91819 意思是不提供 web 端。。。

    我没写对,就是说把 app 做成严重依赖服务器的那种,本地功能尽可能少,只要在本地的很容易被破解
    fengpan567
        4
    fengpan567   5 天前
    反编译没有什么可读性了,甚至一堆报错,让原来的开发来反编译还原代码,估计都够呛
    murmur
        5
    murmur   5 天前
    哦我看错了,微服务这个得把关键服务写到 dll 里,然后 jni 调用,这部分代码最好还有密钥加密,密钥是 u 盘,只有插了 key 才能还原核心代码

    这么折腾还不满意就没法了,拆分也是可以的,拿到一部分代码跑不起来
    flywith24
        6
    flywith24   5 天前
    个人认为没有绝对的安全,对于大部分产品来说,如果破解成本大于收益,则可以认为是相对安全的。因此权衡好保证安全所付出的成本与收益,自身被破解付出的成本,以及破解者破解付出的成本与收益即可。
    hxy91819
        7
    hxy91819   5 天前
    @murmur 这个我能理解,本地尽量不要有关键业务逻辑
    imn1
        8
    imn1   5 天前
    按这个时代来说,防软件拷贝是一种较旧的思维方式,不能说落后,至少跟时代不相配
    现在很多服务型的软件,软件本身不值钱(或者占比少),数据才是重要的

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

    1/2 都较难解决,建议在第三点下手,将部分核心内容交由客户自己部署(通过密码或 key ),就是拷贝部署后的成品不能用,只能通过掌控密码的人重新部署这部份
    注意:说的不是部署后要 key 运行,而是部署本身就需要 key,部署后的模块换设备就不能运行,要重新部署
    hxy91819
        9
    hxy91819   5 天前
    @flywith24 有没有哪些常见的可以提高破解成本的方法?
    fengjianxinghun
        10
    fengjianxinghun   5 天前
    @hxy91819 vmprotect
    hxy91819
        11
    hxy91819   5 天前
    @imn1 感觉我这个项目 1 和 2 的原因都有,只能尽量提高盗取者的成本了。第三点在部署上着手,限制只能在有 key 的地方部署感觉可行。
    murmur
        12
    murmur   5 天前
    @hxy91819

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

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

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

    只要你的东西足够诱惑,防是防不住的,律师团队肯定得有
    murmur
        13
    murmur   5 天前   ❤️ 1
    知道谁偷走了代码还好说,就怕别人偷走了代码开了公司产品都开发好了甚至比你先申请软件著作权你还不知道
    hxy91819
        14
    hxy91819   5 天前
    @murmur 感谢,收获不少。
    mlhadoop
        15
    mlhadoop   5 天前
    技术不能解决的就用法律手段
    namelosw
        16
    namelosw   5 天前
    > 答曰:需要避免运维人员在发布过程中拷贝……

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

    听起来像拍脑袋的决定, 运维能碰机器大不了给机器打个镜像在家里倒出来谁防得住?
    xuanbg
        17
    xuanbg   5 天前
    防不住,运维完全可以镜像整个服务器,你拿什么防?
    hxy91819
        18
    hxy91819   5 天前
    @namelosw 嗯,确实问题多多,更需要跟需求方再多沟通确认下。
    hxy91819
        19
    hxy91819   5 天前
    @xuanbg 是的,有道理。
    taro0822
        20
    taro0822   5 天前
    歪个楼,后端加密我都能理解,我遇到过把接口返回的 json 用 des 加个密,前端再来解密,而且密钥直接写死在 js 里……
    lewis89
        21
    lewis89   5 天前
    放心,没有人会去破解你的屎山,有这个功夫随便收买几个关键的人就完事了,讲一下业务逻辑
    zypy333
        22
    zypy333   5 天前
    我们公司就要做这个功能,说是给客户发的许可证是有时间期限的,怕他们改代码,或者把代码卖给别人
    然后公司采购加密狗,采购回来发现那个是前端加密的,服务端不支持,现在暂时搁置了

    在调研过程中找到这个,我没试,你可以看看
    https://github.com/core-lib/xjar
    zypy333
        23
    zypy333   5 天前
    @taro0822 这种是防止报文被嗅探吧,有些安全检查要求报文里不能有明文密码
    zeni123
        24
    zeni123   5 天前
    加钱可以避免新的需求... 特别是不合理的需求
    murmur
        25
    murmur   5 天前
    @taro0822 估计是为了应付检查吧,des 算专业的了,水的 base64 也算加密
    hxy91819
        26
    hxy91819   4 天前
    @zypy333 感觉不错,学习下
    hxy91819
        27
    hxy91819   1 天前
    @zypy333 谢谢,这个看起来不错。
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2588 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 00:37 · PVG 08:37 · LAX 16:37 · JFK 19:37
    ♥ Do have faith in what you're doing.