看了《立体忍者》漏洞介绍，一个重要原因是，本来有个函数是很安全的，当要拷贝的数据的长度大于目标内存块长度的时候就会拒绝拷贝，但是游戏开发人员用额外的参数强制忽略了这个安全性检查，所以直接就可以溢出攻击…

但是不是说主机游戏的一切内容都要通过第一方审核之后才能发布么，所以很多游戏连发个补丁都非常不容易…

那么这种游戏开发人员故意造成的安全漏洞到底有没有人管？是谁来管？

@SONIC3D

第一方审核的应该是游戏内容而不是源代码，源代码这种高度保密的东西肯定不会随便给别人审查，
一个项目这么大，BUG这种东西是不可能杜绝的，只能尽量减少BUG。。。

引用:

原帖由 Fludit 于 2015-1-20 13:43 发表
第一方审核的应该是游戏内容而不是源代码，源代码这种高度保密的东西肯定不会随便给别人审查，
一个项目这么大，BUG这种东西是不可能杜绝的，只能尽量减少BUG。。。

不审查源代码的话，为什么上个补丁都是特别的困难呢？

然后…人为制造安全漏洞，在公司里有没有人管？

引用:

原帖由 Boomer 于 2015-1-20 13:50 发表


不审查源代码的话，为什么上个补丁都是特别的困难呢？

然后…人为制造安全漏洞，在公司里有没有人管？

dlc也是审核内容，源代码是不会给其他公司看的

posted by wap, platform: SONY Z1
不是制造漏洞，是发现漏洞

posted by wap, platform: Chrome
这种漏洞本来就是很难以被发现的，即使给了你源代码也很难被检查出来，大多数此类问题被发现都是由于游戏中出现了某种不正常才被发现出来。

相比这个，这个漏洞是怎么被Hacker发现的，我也很好奇。

看了《立体忍者》漏洞介绍，一个重要原因是，本来有个函数是很安全的，当要拷贝的数据的长度大于目标内存块长度的时候就会拒绝拷贝，但是游戏开发人员用额外的参数强制忽略了这个安全性检查，所以直接就可以溢出攻击…


所以这个API函数应该改进增强, 拒绝不安全的行为.

引用:

原帖由 firesun 于 2015-1-21 18:30 发表
posted by wap, platform: Chrome
这种漏洞本来就是很难以被发现的，即使给了你源代码也很难被检查出来，大多数此类问题被发现都是由于游戏中出现了某种不正常才被发现出来。

相比这个，这个漏洞是怎么被Hacker发 ...

推荐你本书 看雪学院的《0day安全 软件漏洞分析技术》 网上有电子版 虽然我也看不明白 但是大致了解点了

最神的是当初PSP破解，必须玩某个特定游戏，特定操作才会引发漏洞

posted by wap, platform: 小米 红米 NOTE
源代码行数那么多，没人能够一看就看出所有的代码风险。很多风险只是理论上的。buffer溢出的debug一直是c c++程序的debug难点之一
再说代码本来都是机密，主机厂甚至很多时候代码外包方都是得不到源代码的，另外第三方中间件或者主机sdk也可能有代码风险。当年碰到过一个随机的bug，升级了fmod之后就没再出现了。

游戏测试基本上都是qa大规模打游戏，把所有理论情况都测试到而已。存档风险这个事儿基本很少有人管

本帖最后由 mieumieu 于 2015-1-24 12:47 通过手机版编辑

posted by wap, platform: iPhone

引用:

原帖由 @mieumieu  于 2015-1-24 12:44 发表
源代码行数那么多，没人能够一看就看出所有的代码风险。很多风险只是理论上的。buffer溢出的debug一直是c c++程序的debug难点之一
再说代码本来都是机密，主机厂甚至很多时候代码外包方都是得不到源代码的，另外第三方中间件或者主机sdk也可能有代码风险。当年碰到过一个随机的bug，升级了fmod之后就没再出现了。

游戏测试基本上都是qa大规模打游戏，把所有理论情况都测试到而已。存档风险这个事儿基本很少有人管

本帖最后由 mieumieu 于 2015124 12:47 通过手机版编辑

感觉你是我同事的感觉啊

引用:

原帖由 himura 于 2015-1-22 01:58 发表
看了《立体忍者》漏洞介绍，一个重要原因是，本来有个函数是很安全的，当要拷贝的数据的长度大于目标内存块长度的时候就会拒绝拷贝，但是游戏开发人员用额外的参数强制忽略了这个安全性检查，所以直接就可以溢出攻击 ...

这个是编程语言函数，不是游戏机OSAPI

而且只要开发人员想，可以不用这个函数直接进行操作

谁吃饱了给你审，出了问题要你厂商发补丁呗，否则把你产品全部下架，损失自担，合同里都写明了，有问题找你公司法务谈去，对了，损失大还要额外问你要补偿。。。

作为程序员我爱留几个彩蛋留几个彩蛋，爱调什么非公开函数就调(只要通得过自动审核校验)，策划你给我数据表里人物参数100，我代码里hardcode强改成120，最后攻略本出了，数据不对喷的反正是策划。

总结一句话，游戏项目经理千万不要惹程序员，基层工人半夜放把火就是可以把整栋楼烧了。:D

不过我告诉你，靠内存拷贝溢出导致执行有问题的，肯定最终责任在游戏机的OS系统，现代OS的数据内存地址范围应该不允许有可执行属性的，而可执行内存的的范围一般不应该有User级别代码可写入的属性，这样可以形成一种制约。所以现在既然让一块内存被拷贝溢出影响了，又让这些溢出数据构造的精妙合理的返回栈写入了可执行代码所在的内存范围，肯定还是OS对应的平台API里有地方没有考虑周全，被了解内情的程序员合理或者碰巧利用了。

Wii/3DS/DS/WiiU的破解大都是这类问题，而360/PS3的漏洞似乎都不属于内存越权执行或越权写入作为切入点来触发的。。。。

[ 本帖最后由 SONIC3D 于 2015-2-1 18:59 编辑 ]

游戏厂商对于源代码管理，审查以及提交比较随意，以前有个同事在ubi呆过，据说没有code review，都是直接check-in代码，早上来第一件事是修build break。

posted by wap, platform: iPad

引用:

原帖由 @OrochiZ  于 2015-2-1 16:02 发表
这个是编程语言函数，不是游戏机OSAPI

而且只要开发人员想，可以不用这个函数直接进行操作

所以正是此主机平台的责任。