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

关于源码保密性及仿篡改方案的思考

  •  
  •   xiaotuzi · 2019-09-02 00:03:49 +08:00 via iPhone · 3962 次点击
    这是一个创建于 1670 天前的主题,其中的信息可能已经有所发展或是发生改变。
    很多时候,软件源码要授权及保密措施,为防止篡改,经常把源码加密,但是加密在如今好像没什么用,花钱都能解决。我想到一个方案,在系统检测到源码或者授权被更改后,随机修改某个系统类,导致一些莫名其妙的错误,使篡改后的软件不能正常运行,而 debug 只能找到某段代码出错,却不能找到真正原因所在,因为每次出错的文件都是不固定的,从而达到仿篡改的目的。(前提,检测源码是否被更改,可以检测授权文件的修改时间及大小,代码可以嵌套在系统的某个地方隐藏,随机修改文件的代码也容易写),大家觉得这个策略如何?或者有什么更好的方案能讨论一下吗?
    34 条回复    2019-09-02 14:57:03 +08:00
    imdong
        1
    imdong  
       2019-09-02 00:08:41 +08:00
    如果,把你检测被更改的代码干掉了呢。
    脚本语言的话,人肉跑一下代码,就搞定了。
    编译语言的话,基本上 od 加断点或者直接跳过你的检测...

    对于客户端的保密性,只能说提高到能破解但没有意义为止。
    msg7086
        2
    msg7086  
       2019-09-02 00:26:38 +08:00
    二十多年前我们常用的一款输入法「中文之星」就是这么实现的。

    你可以看下他们坟头草多高了。
    crab
        3
    crab  
       2019-09-02 01:28:07 +08:00
    现在相对安全也是把关键数据放云端,但还是存在被本地破解。
    Mitt
        4
    Mitt  
       2019-09-02 01:43:50 +08:00
    你能想到的,市场上那些做挂的基本都实现过一遍了,但也只是伤敌一千自损八百,破解只是时间和精力问题,一旦摸透了就没有任何用处了
    chinvo
        5
    chinvo  
       2019-09-02 01:50:30 +08:00 via iPhone
    native 程序基本上是增加逻辑复杂度、埋暗桩、加花、加壳、上 vmp

    但是也只是增加破解难度而已,不能杜绝
    geelaw
        6
    geelaw  
       2019-09-02 01:54:12 +08:00   ❤️ 1
    第一个问题是:什么叫做代码“不可篡改”?

    我暂时没有一个直观且有意义的定义。

    关于代码“保密”,自然就是说程序混淆了。

    一个自然的想法是 virtual black-box obfuscation,意思是说:看到经过混淆之后的(机器)代码等同于对原来的代码具有黑箱访问。但已经证明该形式的混淆对一般程序不可行,而且目前已知的该类混淆都是很弱的程序类。

    另一个目前学界正在研究的问题是如何构建 indistinguishability obfuscation (iO),意思是说:有两段等价、等长度的代码,其中一个被混淆了,看到混淆的代码后无法有效推断是哪段代码被混淆了。
    稍微夸张地说,目前已知的、对一般程序的 iO 通常需要 几年 才能执行原来程序的 一个 CPU 周期,并且人们对构建 iO 的底层原材料掌握还不是很好。
    xiaotuzi
        7
    xiaotuzi  
    OP
       2019-09-02 06:12:26 +08:00 via iPhone
    @imdong @msg7086 @Mitt @chinvo 我这不是混淆视听的做法嘛,如果你真跟着跑一遍程序,所有类及加载类都走一遍,那肯定无死角的。🌚
    xiaotuzi
        8
    xiaotuzi  
    OP
       2019-09-02 06:15:20 +08:00 via iPhone
    @crab 放云端的话,那就是要云端执行一段代码,然后返回数据吗?那如果后面打印一下数据,那就直接把云端的东西拿出来了,除非全部用 api,那就当我没说。api 确实方便很多,但挂了的话,就是灾难性的。
    xiaotuzi
        9
    xiaotuzi  
    OP
       2019-09-02 06:20:24 +08:00 via iPhone
    @geelaw 第一个问题,不可篡改是在于用户协议上,源码及程序有法律限制不可修改。后面你说的没有看懂…🤣
    greed1is9good
        10
    greed1is9good  
       2019-09-02 06:20:26 +08:00 via iPhone
    类似.net 签名验证?
    xiaotuzi
        11
    xiaotuzi  
    OP
       2019-09-02 06:22:38 +08:00 via iPhone
    @greed1is9good 嗯,实现类似签名验证的功能,检测用户是否授权。
    boob
        12
    boob  
       2019-09-02 07:04:14 +08:00 via Android
    一般不是校验 hash 吗
    boob
        13
    boob  
       2019-09-02 07:07:38 +08:00 via Android
    修改时间和大小都可以随时改的
    dangyuluo
        14
    dangyuluo  
       2019-09-02 07:20:20 +08:00
    哈哈放在虚拟机里跑?给客户提供一个虚拟机硬盘文件?
    xenme
        15
    xenme  
       2019-09-02 07:46:18 +08:00 via iPhone
    随便弄弄防君子够了
    qilishasha
        16
    qilishasha  
       2019-09-02 07:54:55 +08:00 via iPhone
    没有必要花时间精力干这个
    love
        17
    love  
       2019-09-02 08:44:40 +08:00 via Android
    然后大家都传说你这个软件不稳定,经常出莫名其妙的问题
    firefox12
        18
    firefox12  
       2019-09-02 08:46:37 +08:00
    除了核心代码放在服务器上执行,其他的办法被破解都只是时间问题。
    waruqi
        19
    waruqi  
       2019-09-02 08:56:59 +08:00
    如果是 android 的话,我之前整过一个 dex 的 vmp,native/dex 里面涉及敏感代码,检测代码的局部 method 上 vmp,然后跟 native 配合运行避免整体加固导致启动性能受损,一些敏感类,例如 string,全部在 vm 里面重新实现,防止 jni 被 hook 导致数据被窥视,以及防止 memory dump,native 里面还可以开编译混淆,加点花指令,反调试等常规措施
    stoneabc
        20
    stoneabc  
       2019-09-02 09:22:40 +08:00
    @geelaw 怎么现在都喜欢搞 differential privacy 那套 indistinguishability …… hhhhh
    xiaotuzi
        21
    xiaotuzi  
    OP
       2019-09-02 09:27:49 +08:00 via iPhone
    @boob 嗯,也行。hash 准确一点
    xiaotuzi
        22
    xiaotuzi  
    OP
       2019-09-02 09:28:20 +08:00 via iPhone
    @dangyuluo 动态语言…虚拟机不太现实
    xiaotuzi
        23
    xiaotuzi  
    OP
       2019-09-02 09:28:55 +08:00 via iPhone
    @love 买授权就没问题🌚
    xiaotuzi
        24
    xiaotuzi  
    OP
       2019-09-02 09:31:09 +08:00 via iPhone
    @firefox12 一般都是发源码包,所以还是要做源码仿篡改啥的
    xiaotuzi
        25
    xiaotuzi  
    OP
       2019-09-02 09:31:29 +08:00 via iPhone
    @waruqi 你这操作,应该很少人会花心思破解了
    catcalse
        26
    catcalse  
       2019-09-02 09:34:54 +08:00
    不做 c/s
    augustheart
        27
    augustheart  
       2019-09-02 09:37:13 +08:00
    如果是正规商业软件,把心思放在如何增加营收上才是正理。天天纠结被人修改破解的那是黑产圈子。
    你看 adobe,jetbrains 他们什么时候把心思放在防破解上了。
    Huelse
        28
    Huelse  
       2019-09-02 09:37:42 +08:00
    其实从现在互联网的发展情况来看很少有去保护到用户本地的源码了,

    更注重的时服务端的保护和通讯过程的加密,也是现在开源比较盛行的原因之一,

    除非是非常稀少的特种设备所需要的软硬件,

    而且逆向破解界有句话说的好,加密就是用来破解的 (手动滑稽
    codingBug
        29
    codingBug  
       2019-09-02 11:03:32 +08:00
    想想迅雷。我觉得可以修改变量名,像前端打包之后的代码,一位字母、两位字母变量。当然断点还是能找到你想要的数据。增加破解的难度、不定期(静默)更新代码,必须更新版本才能使用,增加破解的成本。破解成本 大于 破解收益
    akira
        30
    akira  
       2019-09-02 11:35:23 +08:00
    先不讨论这个方案的效果如何,我只想知道怎么实现
    "系统检测到源码或者授权被更改"
    taobibi
        31
    taobibi  
       2019-09-02 13:47:53 +08:00
    给楼主讲个半真实、半杜撰的故事。过去我们公司做过一条运送跟踪系统的程序,当时我们总工程师写了很多意义不大和各种怪怪的注释。后来,我们当时的同行公司抄袭了我们的软件,这种标记性的“水印”就没删除干净,最后被我们发现,打官司起诉他们。后来,我们同行的公司险些输了官司,即将很狼狈的收场。最后他们从后台爸爸手里拿了钱,把我们收购了。
    xiaotuzi
        32
    xiaotuzi  
    OP
       2019-09-02 14:02:44 +08:00 via iPhone
    @taobibi 666,只要能检测出证明的标记,也就好办
    geelaw
        33
    geelaw  
       2019-09-02 14:17:37 +08:00
    @xiaotuzi #9 因为你想要“防止篡改”,我假设的是这种防止是技术上而不是法律上的,因为如果你相信大家会遵守协议,那么根本没必要问这个问题。

    @xiaotuzi #32 如果你想要达到“可以检查出标记”,那么你可以用 software watermarking 的技术。

    @stoneabc #20 密码学里的 IND-based security 自“古”以来(“古”基本上是“基于计算复杂性理论的密码学的开始”)就是这样定义的。而且 iO 比 DP 的定义至少早 5 年。

    @xiaotuzi #11 我觉得你没有搞清楚你想要解决的问题,目前出现的几个词:篡改、授权、保密。这是三个(至少表面上)不同的问题,你需要弄清楚对于每个问题你想要达到的目标,然后再考虑每个目标是否可以达到、如何达到。
    Youngxj
        34
    Youngxj  
       2019-09-02 14:57:03 +08:00
    我用 md5 试过了,解密之后一样会被 GG
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   4384 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 10:05 · PVG 18:05 · LAX 03:05 · JFK 06:05
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.