作者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