Project1

标题: 继续咸鱼 [打印本页]

作者: SixRC 时间: 2021-1-5 01:38
标题: 继续咸鱼
关于xp的代码和资源保护
有一些小想法
不过没有动力也没有激情去做
所以只是讲一下这些想法
1.关于代码
   之前提过把ruby代码转换为相应的c 然后编译不过局限性很大因为一个动态一个静态一个运行时才知道一个既定类型等等
  仅仅是把部分逻辑c化还是不错的
   其实把ruby的抽象语法树提取出来再放回去也应该有不错的效果也就是只保留语法树删掉了源码或者是提取token 送给语法分析段
  难点是不能直接拷贝语法树因为很多东西是运行时确定的比方字符串符号量所以也要运行时建构只是方式不一样了
  但应该不难达成毕竟ruby源码就在那  然后逆向拿关键地址 hook关键函数提取加构建就行
  缺点是也能根据语法树生成代码不过应该需要更多精力和对ruby源码的理解而且可以在提取构建时进行混淆/增加垃圾代码等加大分析难度
   另一个想法是替换ruby版本高版本可以直接保存编译的字节码然后加载运行可以自己编译一个改改字节码的指令码等虽然文档说不能在不同电脑间迁移我了解不多
  或者换成jruby 直接转java 然后继续混淆走起

2.关于资源
   其实打包是必然可以解包的但是可以让打包无法被一键解包也就让解包更加繁琐耗时
  思路很简单就是让文件名成为key 并在封包内删除文件名信息只有读取时给出具体信息才能解码出文件
矛盾点在于没有文件名怎么定位文件数据
  一个思路是根据文件名hash来定位并根据文件名生成另一个hash来作为key
  其他方法也有就不展开了
   缺点是如果有大量文件名的暴露口就能直接提取资源了这对常规打包也是致命的
  通常代码防线炸了资源防线也炸了因为所有调用接口在代码里都一览无余

除此以外的是反逆向反调试检测内存/文件是通用保护手段我没什么好讲的

总结:搞得越麻烦破解就越烦保护也就有意义了

虽然乱七八糟是想了一些
不过没有以前的心态去做了
继续咸鱼了

作者: 89444640 时间: 2021-1-5 07:38
本帖最后由 89444640 于 2021-1-5 07:44 编辑

我觉得图像资源可不可以这样，把图像进行随机切割，随机切成很碎的非矩形小块，多切几次，类似于这样的拼图

然后程序运行时候再去拼接，即使解包出来也是碎的，重新拼接一遍难度极大。偏移xy坐标，混乱文件名，乱改配色什么的，像素图无法旋转，不然可以再加个角度旋转，提出来的必定歪曲的一塌糊涂，甚至故意让不是程序自带“解码器”解码出来的图像是13%这种非偶数倍缩放的，像素图一旦奇数缩放必定出虚边，虚的根本没法用，造成用肉眼查找拼接资源难度极大。比如切成圆形有角度的图，等于做一个上万块的不能查看也不知道全图的拼图，让他们必须手动拼接拼，这个工作量累死人。
只要拼接规则这段代码能让人难以推断出在哪里，就可以了。
作为免费个人游戏，资源质量本身理论上不会高于商业游戏，只要解资源者所需的精力时间消耗，大于上传那些所谓的资源网站获取的微量所得，只要不是程序运行就能把资源处理成能用状态，必须通过手动处理并且消耗大量时间才可以把资源拼回去，他们就会转而去攻击好解包并且获得盈利更大的游戏，这样就安全了。

其实计算机法不让改用户计算机内容，不然验证是不是在运行游戏，不是的话直接执行反安装多省事。

作者: saterick 时间: 2021-1-5 08:47

89444640 发表于 2021-1-5 07:38
我觉得图像资源可不可以这样，把图像进行随机切割，随机切成很碎的非矩形小块，多切几次，类似于这样的拼图 ...

可能是我心态比较好，加密反正能防最低限度的破解（指RGSSAD解包）就够了。想要拆RM游戏的人，一般都是小年轻想要里面的素材什么的，反而是技术实力达到一定程度的人不屑于去拆了。

欢迎光临 Project1 (https://rpg.blue/)