作者cassine (Savannah)
看板Modchip
标题Re: [PS3 ] Mathieulh补刀 Lv2 Loader与App. Load …
时间Sun Jan 2 22:48:20 2011
1F：→ tsairay:原po大概没在写code,变数用完是可以手动清记忆体的 01/02 14:09
2F：→ tsairay:麻烦而已,不是办不到 01/02 14:09
3F：推 f1234518456:那还不是要载到记忆体... 01/02 14:25
4F：推 tsairay:原po是写说会留存到其他资料盖掉为止,我是针对这点提出 01/02 15:32
5F：推 TAKO321:楼上说得就是被资料盖掉啊XD要嘛自己盖掉要嘛被系统盖掉 01/02 15:47
6F：→ TAKO321:所以原PO说得留存到被盖掉为止没错啊。 01/02 15:48
7F：推 tsairay:留存到被盖掉是被动,手动去清是主动 01/02 15:49
8F：推 f1234518456:那还不是自己手动去盖掉... 01/02 16:05
看来某人才真的是没在写程式， C语言里面处理可以释放的变数或阵列都是宣告
指标(pointer) ，宣告後电脑会去主记忆体里面找一块符合大小的记忆体，然後
把起始位置写回指标。
举个例子：如果今天我需要一个可释放的阵列 A，大小 8 bits ，那我宣告後程
式会去记忆体里面找个空间来存指标，假设指标记忆位址是0x0000，然後再去找
段够大的空间，假设从0x0100开始一直到0x0108，於是指向 A阵列的指标内容就
会是0x0100。
记忆体位址跟内容的关系是这样：
位址：0x0000┌→
0x0100 0x0101 ... 0x0107 0x0108
内容：
0x0100┘ 0x00 0x00 ... 0x00 0x00
然後我把某个解密金钥01 23 45 67 89 AB CD EF 写入这个阵列，所以0x0100到
0x0108的内容就会是01 23 45 67 89 AB CD EF 00。
於是乎，记忆体位址跟内容会变成这样：
位址：0x0000┌→
0x0100 0x0101 ... 0x0107 0x0108
内容：
0x0100┘ 0x01 0x23 ... 0xEF 0x00 ←假设0x00是终止字元
到这里为止0x0000里面储存的值会是0x0100，然後金钥存在 0x0100~0x0108。好
了，那我金钥用完要释放怎麽办？ C语言的作法是用delete，执行结果就是把
0x0000里面的值0x0100删掉，然後将0x0000标记成未占用。根本不会去管0x0100
到0x0107这段里面东西还在不在。
记忆体位址跟内容变成这样：
位址：0x0000 0x0100 0x0101 ... 0x0107 0x0108
内容：
null 0x01 0x23 ... 0xEF 0x00
所以只要把整个记忆体读出来，然後搜寻0x0100 ~ 0x0108 ，就可以得知金钥的
内容。於是有人就会想到说，那我释放时再重新宣告一个阵列 B，大小能够把刚
刚这段内容盖掉不就好了？是没错，但一般程式设计师根本不会去管刚刚阵列 A
到底是存在记忆体的哪个位置，自然也不会特别要求程式去填那个位置，那如果
去盖呢？
这叫做「此地无银三百两」，真的去填就等於告诉骇客「那边有我不想给你们看
的东西，没有我的允许，绝对绝对不可以去看喔！」，下次骇客就会让程式当在
填垃圾资料前，然後去把那段位址的内容读出。人天生就有收集资讯充实自己的
本能，不然某数字周刊怎麽可能卖得这麽好，有道理吧？
--
○ ____ _ _ _ _ ____ _ _ ____ _____ ____
。 ★(_ _)( \( )( \/ )( ___)( \( )(_ _)( _ )( _ \
ｏ _)(_ ) ( \ / )__) ) ( )( )(_)( ) / ● ‧
(____)(_)\_) \/ (____)(_)\_) (__) (_____)(_)\_) ★
ｏ
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 59.126.61.141
※ 编辑: cassine 来自: 59.126.61.141 (01/02 22:51)
9F：→ lostkimo:虽然我好几年没写程式了，C大说的跟我猜想一样 01/02 23:01
10F：→ lostkimo:只要存在~就有可能读出来~~ 01/02 23:01
11F：推 tsairay:你的看法太理想了吧,记忆体内就没有其他资料会变动吗 01/02 23:13
12F：→ tsairay:书读很多也要实际操作一下,真有那麽容易从mem读,早就读出 01/02 23:14
13F：→ tsairay:来了,还需要去拆解演算法吗 01/02 23:14
14F：→ cassine:这一点都不理想，现实状况就是如此，有很大的机会不被盖掉 01/02 23:14
15F：→ cassine:拆解演算法可以分析资料的格式，利用特殊的标记来加速搜寻 01/02 23:15
16F：→ cassine:不然要怎麽解释geohot的漏洞存在的事实？ 01/02 23:16
17F：→ tsairay:等着被盖掉是被动,主动去清掉是主动,操一点就是把所有变数 01/02 23:16
18F：→ cassine:照你这样讲geohot的漏洞应该不可能存在才对，那这样$QNY也 01/02 23:16
19F：→ cassine:没必要拿掉OtherOS，也才不会导致今天这种局面。 01/02 23:17
20F：→ tsairay:都这样处理,干扰的目标就能达成 01/02 23:17
21F：→ cassine:好啦，楼上赶快去教$QNY的程式设计师写程式，这样就不会被 01/02 23:19
22F：→ cassine:破解了。 01/02 23:19
23F：→ cassine:我想$QNY现在肯定非常後悔当初没有请到某t去当他的的顾问 01/02 23:22
24F：→ way7344:放大绝中… 01/02 23:33
25F：→ f1234518456:真那麽理想还会被人捞到喔... 01/02 23:44
26F：推 coolcliff01:蓝光影片一开始也是从windvd这软体的记忆体捞key才破 01/03 00:29
27F：→ coolcliff01:而anydvd则是a走powerdvd的key 所以实务上是有发生过 01/03 00:31
28F：→ tsairay:慢慢捞是捞的到啊,所以才要做防护 01/03 00:57
29F：→ toro1144:C大打这篇真辛苦 顺便学习一下 01/03 10:08
30F：推 f1234518456:每次进来都看到某个人在跳... 01/03 10:14
31F：推 ian1009:100分～（虽然看无） 01/03 13:46
32F：推 belion:推！ 01/03 16:40
33F：推 bug001:动不动在这边呛别人没写过code才会被打脸... 01/03 19:09
34F：→ bug001:不过新世代很多写code的人其实已经不需要懂底层了 01/03 19:10
35F：推 nfsong:感动阿 01/03 21:14
36F：推 JupIte:推cassine 大绝 GJ 01/04 01:57
37F：推 teabar:推两位！互相激荡才能让大家懂更多！ 01/07 08:38
38F：→ KevinR:你以为每次都会alloc到头一个位置吗? 01/07 12:32