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

Project1

 找回密码
 注册会员
搜索
查看: 5191|回复: 22

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

[复制链接]

Lv5.捕梦者 (版主)

梦石
1
星屑
23963
在线时间
3338 小时
注册时间
2011-7-8
帖子
3925

开拓者

发表于 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, 下载次数: 168)

评分

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

查看全部评分

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

Lv5.捕梦者

梦石
0
星屑
31688
在线时间
5077 小时
注册时间
2012-11-19
帖子
4877

开拓者

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


捕获.PNG

点评

你可以用 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
发表于 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
星屑
23963
在线时间
3338 小时
注册时间
2011-7-8
帖子
3925

开拓者

 楼主| 发表于 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)

点评

本来还准备把标题改成“很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-3-29 17:20

Powered by Discuz! X3.1

© 2001-2013 Comsenz Inc.

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