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

[xiaotuzi]

很多时候，软件源码要授权及保密措施，为防止篡改，经常把源码加密，但是加密在如今好像没什么用，花钱都能解决。我想到一个方案，在系统检测到源码或者授权被更改后，随机修改某个系统类，导致一些莫名其妙的错误，使篡改后的软件不能正常运行，而 debug 只能找到某段代码出错，却不能找到真正原因所在，因为每次出错的文件都是不固定的，从而达到仿篡改的目的。(前提，检测源码是否被更改，可以检测授权文件的修改时间及大小，代码可以嵌套在系统的某个地方隐藏，随机修改文件的代码也容易写)，大家觉得这个策略如何？或者有什么更好的方案能讨论一下吗？

[imdong]

如果，把你检测被更改的代码干掉了呢。
脚本语言的话，人肉跑一下代码，就搞定了。
编译语言的话，基本上 od 加断点或者直接跳过你的检测...

对于客户端的保密性，只能说提高到能破解但没有意义为止。

[msg7086]

二十多年前我们常用的一款输入法「中文之星」就是这么实现的。

你可以看下他们坟头草多高了。

[crab]

现在相对安全也是把关键数据放云端，但还是存在被本地破解。

[Mitt]

你能想到的，市场上那些做挂的基本都实现过一遍了，但也只是伤敌一千自损八百，破解只是时间和精力问题，一旦摸透了就没有任何用处了

[chinvo]

native 程序基本上是增加逻辑复杂度、埋暗桩、加花、加壳、上 vmp

但是也只是增加破解难度而已，不能杜绝

[geelaw]

第一个问题是：什么叫做代码“不可篡改”？

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

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

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

另一个目前学界正在研究的问题是如何构建 indistinguishability obfuscation (iO)，意思是说：有两段等价、等长度的代码，其中一个被混淆了，看到混淆的代码后无法有效推断是哪段代码被混淆了。
稍微夸张地说，目前已知的、对一般程序的 iO 通常需要 几年 才能执行原来程序的 一个 CPU 周期，并且人们对构建 iO 的底层原材料掌握还不是很好。

[xiaotuzi]

@imdong @msg7086 @Mitt @chinvo 我这不是混淆视听的做法嘛，如果你真跟着跑一遍程序，所有类及加载类都走一遍，那肯定无死角的。🌚

[xiaotuzi]

@crab 放云端的话，那就是要云端执行一段代码，然后返回数据吗？那如果后面打印一下数据，那就直接把云端的东西拿出来了，除非全部用 api，那就当我没说。api 确实方便很多，但挂了的话，就是灾难性的。

[xiaotuzi]

@geelaw 第一个问题，不可篡改是在于用户协议上，源码及程序有法律限制不可修改。后面你说的没有看懂…🤣

[greed1is9good]

类似.net 签名验证？

[xiaotuzi]

@greed1is9good 嗯，实现类似签名验证的功能，检测用户是否授权。

[boob]

一般不是校验 hash 吗

[boob]

修改时间和大小都可以随时改的

[dangyuluo]

哈哈放在虚拟机里跑？给客户提供一个虚拟机硬盘文件？

[xenme]

随便弄弄防君子够了

[qilishasha]

没有必要花时间精力干这个

[love]

然后大家都传说你这个软件不稳定，经常出莫名其妙的问题

[firefox12]

除了核心代码放在服务器上执行，其他的办法被破解都只是时间问题。

[waruqi]

如果是 android 的话，我之前整过一个 dex 的 vmp，native/dex 里面涉及敏感代码，检测代码的局部 method 上 vmp，然后跟 native 配合运行避免整体加固导致启动性能受损，一些敏感类，例如 string，全部在 vm 里面重新实现，防止 jni 被 hook 导致数据被窥视，以及防止 memory dump，native 里面还可以开编译混淆，加点花指令，反调试等常规措施

[stoneabc]

@geelaw 怎么现在都喜欢搞 differential privacy 那套 indistinguishability …… hhhhh