设为首页收藏本站|繁體中文

Project1

 找回密码
 注册会员
搜索
查看: 5767|回复: 22
打印 上一主题 下一主题

[讨论] 加密素材的简单方法

[复制链接]

Lv5.捕梦者 (版主)

梦石
1
星屑
23994
在线时间
3339 小时
注册时间
2011-7-8
帖子
3926

开拓者

跳转到指定楼层
1
发表于 2017-10-5 21:39:13 | 只看该作者 |只看大图 回帖奖励 |倒序浏览 |阅读模式

加入我们,或者,欢迎回来。

您需要 登录 才可以下载或查看,没有帐号?注册会员

x
本帖最后由 guoxiaomi 于 2017-10-5 21:46 编辑

之前考虑过单独加密图片素材的方法,于是在论坛上找到了这个:https://rpg.blue/forum.php?mod=viewthread&tid=87968原贴楼主是柳之一,这是08年的陈年老贴。

这个帖子里介绍了 bitmap marshal 的技术,所有的截图存档里也都有类似功能的代码。于是利用一点点小trick就可以用这个来做素材加密。

因为已经决定不加密素材,所以就把这个trick公开了。

修改 RPG::Cache 中的 load_bitmap 方法,在直接调用 Bitmap.new(path) 前,检查一下是否有加密的素材。加密的素材保存在 Resource 文件夹下,并且文件名是 path 的 md5 值,其实我这里也没有算 md5 值,就是拿 crc32 随便糊了个假的。

RUBY 代码复制
  1. module RPG
  2.   module Cache
  3.     def self.load_bitmap(folder_name, filename, hue = 0)
  4.       path = folder_name + filename
  5.       #----------------------------------------------------------------
  6.       # 优先从 resource 里加载
  7.       #----------------------------------------------------------------
  8.       if not @cache.include?(path) or @cache[path].disposed?
  9.         if filename != ""
  10.           resource = 'Resource/' + md5(path)
  11.           if FileTest.exist?(resource)
  12.             @cache[path] = load_data(resource)
  13.           else
  14.             @cache[path] = Bitmap.new(path)
  15.           end
  16.         else
  17.           @cache[path] = Bitmap.new(32, 32)
  18.         end
  19.       end
  20.       if hue == 0
  21.         @cache[path]
  22.       else
  23.         key = [path, hue]
  24.         if not @cache.include?(key) or @cache[key].disposed?
  25.           @cache[key] = @cache[path].clone
  26.           @cache[key].hue_change(hue)
  27.         end
  28.         @cache[key]
  29.       end
  30.     end
  31.  
  32.     def self.md5(string)
  33.       # 这里简单的用 crc32 值取代 md5 值
  34.       sprintf('%08x%08x', Zlib::crc32(string.downcase), Zlib::crc32(string.downcase.reverse))
  35.     end
  36.   end
  37. end


上面说的是解密的方法,关于加密直接看工程吧~范例工程中的 Graphics/Pictures/biaoti.png 可以删掉,但是仍然能正常读取 Resource 文件夹里的内容。
resource.zip (732.09 KB, 下载次数: 171)
只要把输出的内容字符串在写入/读取之前进行加/解密就可以实现加密,毕竟 marshal / zlib.deflate 等于是明文保存。
我写了一个dll用来对每个 byte 进行单字符替换的加密,经测试,这个运算跟 zlib.inflate 的耗时是一样的,30M 的文件大概需要 0.05s。但是用 ruby 直接做字符串的替换就很慢了。

这个trick的一个缺点是,只能针对使用 RPG::Cache 创建的 Bitmap 对象进行加密,如果直接使用 Bitmap.new(path) 方法创建就没办法了。所以需要仔细检查脚本,尽可能用 RPG::Cache 创建 bitmap,或者对特定的素材文件夹不进行加密处理。

评分

参与人数 3+3 收起 理由
hyrious + 1 塞糖
congwsbn + 1 精品文章
水母书亚 + 1 塞糖

查看全部评分

熟悉rgss和ruby,xp区版主~
正在填坑:《膜拜组传奇》讲述膜拜组和学霸们的故事。
已上steam:与TXBD合作的Reformers《变革者》
* 战斗调用公共事件 *
* RGSOS 网络脚本 *

Lv5.捕梦者

梦石
0
星屑
33479
在线时间
5108 小时
注册时间
2012-11-19
帖子
4878

开拓者

2
发表于 2017-10-5 23:44:41 | 只看该作者
嘛,以前就试验过,用 get_pixel 把每点颜色记录储存,然后生成空白Bitmap逐点画。
这是个笨办法,但还原得还不错。就是还原的时候有点慢,图大的话要等2,3秒。





点评

你可以用 RtlMoveMemory 一次拿到所有的像素信息(属于开黑科技了)  发表于 2017-10-15 11:40
一个个点画效率还是太低了= =  发表于 2017-10-6 00:29

评分

参与人数 1+1 收起 理由
guoxiaomi + 1 塞糖

查看全部评分

xp vx va mv  va mz 各类型脚本/插件定制
回复 支持 反对

使用道具 举报

Lv1.梦旅人

梦石
0
星屑
70
在线时间
22 小时
注册时间
2011-3-21
帖子
1
3
发表于 2020-5-19 02:28:55 | 只看该作者
试了一下加密 jpg 图档,发现档案大小增加很多。合计 300M 大小的 jpg 档,在有经过 zlib.deflate 的情况下还是爆增成了 2.5G。
推测是在 marshal dump Bitmap 时,是将每个点的像素信息存下来,因此大小比原本 jpg 格式还要大很多。

不知道有什么可以有效减少容量的方式?

点评

我觉得我可能找到合适的方案了……过几天做好了提醒你一下……  发表于 2020-7-1 00:26
我也发现了文件变大很多,感觉当时也只是开了个脑洞,暂时想不出好的方案  发表于 2020-5-19 03:32
回复 支持 反对

使用道具 举报

Lv5.捕梦者 (版主)

梦石
1
星屑
23994
在线时间
3339 小时
注册时间
2011-7-8
帖子
3926

开拓者

4
 楼主| 发表于 2020-7-1 17:49:03 | 只看该作者
本帖最后由 guoxiaomi 于 2020-7-2 18:05 编辑
war202122 发表于 2020-5-19 02:28
试了一下加密 jpg 图档,发现档案大小增加很多。合计 300M 大小的 jpg 档,在有经过 zlib.deflate 的情况下 ...


试试看我这个最新的范例?我把图片压缩成了PNG,然后再保存以减少体积。同时还把png文件的前1024个字节加密以防止直接解析png文件。对这个640x480的范例,读取速度似乎比原生的要慢1倍,完全可以接受。不知道读一些巨大的图片会不会更慢?

按照 SixRC 的建议用 -static 编译,并且使用了memcpy,效率有明显提升(~20%)
resource.zip (1.18 MB, 下载次数: 70)
效率:如果不进行加密直接保存成png文件,读取的时间比原生的多 50%。作为对比,主楼中的方法应该只比原生多10-20%的时间。aes解密的耗时正比于被加密的字节数,个人控制aes解密耗时在原生的50%左右就可以了。
加密:到底需要加密多少字节才比较合适?如果说只是阻止操作系统识别文件,那只要加密前16个字节就够了。密码学上有个说法是不要混用不同破解难度的加密算法,再对其他的地方进行弱加密显得没有必要了。何况密钥写在了脚本里,理论上只能用跟默认加密一样难度的算法,否则就是把房门钥匙放在门框上一样搞笑。总之应对傻瓜解包器肯定是足够了,进一步可以把这段内容base64一下塞到那种很长的脚本里eval,玩一个捉迷藏的游戏……

尝试加密了RTP,从12.3M增加到了27.3M(+122%),我发现RTP里不少文件都是jpg格式,可能无损压缩就是会增加大小吧……不知道咋办了,只能看具体情况再处理了。

点评

本来还准备把标题改成“很NB的加密方法”,现在……  发表于 2020-7-2 15:47
hhh过早优化是万恶之源  发表于 2020-7-2 15:44
我觉得现在这样就很好了!RM天生劣势 脚本明文 要把加密手段整合进去就很难 不过你的初衷就是简单加密方法 现在这个已经很好很好了!  发表于 2020-7-2 15:33
现在其实只是需要防止玩家直接读取游戏文件而已 完全可以自己糊一个基于异或或别的简单的加密 一切从简 从效果上看也是一样的 甚至可能更好  发表于 2020-7-2 15:15
其实我是觉得AES对于游戏加密太"过"了 因为游戏数据迟早都是明文的 当需要传递数据而怕被别人截获时AES才有必要吧  发表于 2020-7-2 15:14
熟悉rgss和ruby,xp区版主~
正在填坑:《膜拜组传奇》讲述膜拜组和学霸们的故事。
已上steam:与TXBD合作的Reformers《变革者》
* 战斗调用公共事件 *
* RGSOS 网络脚本 *
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 注册会员

本版积分规则

拿上你的纸笔,建造一个属于你的梦想世界,加入吧。
 注册会员
找回密码

站长信箱:[email protected]|手机版|小黑屋|无图版|Project1游戏制作

GMT+8, 2024-11-25 12:25

Powered by Discuz! X3.1

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表