Re: [PS3 ] PS3 全裸了嗎？

看板Modchip (改機)作者cassine (Savannah)時間13年前 (2011/11/09 11:21)推噓6(6推 0噓 0→)

留言6則, 6人參與討論串5/7 (看更多)

http://lan.st/showthread.php?p=22446 妖嬌嘴砲王 Mathieulh的發言： How to pwn metldr the "easy" way 如何「傻瓜地」破解metldr Because some ungrateful person leaked my metldr exploit files I will now be explaining how it actually works, see this as my ultimate release of all times for an ungrateful scene (and scenes in the future) 因為有些忘恩負義的傢伙把我紀錄metldr漏洞相關的檔案流出去了，我只好跳出來解釋該怎麼用〔先承認你就是那些傢伙吧XD〕，把這些檔案當成是我最後的作品吧，尤其是對你們這些忘恩負義的傢伙。（扭動ing ） That's about how I am pissed off right now, because of course the person that leaked these files has no idea of how they actually work. 氣話先講到這裡，因為這些抓耙子根本不知道這些東西要怎麼用。（插腰貌） How to pwn metldr the "easy" way: 該如何「傻瓜地」破解metldr呢？ This is most likely how geohot exploited it in the first place, this takes (give or take) about 10 minutes to be performed. (yeah, not so much of a "I hacked the ps3 all on my own work", especially not when it partially relies on Segher's work, one of the reason geohot never shared the way he exploited metldr to anyone) 這個破解的手法，可能跟geohot第一次破解時如出一轍，大概要花個10分鐘吧（沒錯，但不完全是我的共獻，有些部份是靠Segher完成的，而且我也不會特別指出都是因為geohot不告訴別人，所以我才靠Segher手法完成） I will assume here, that you do not have the loader keys that were made readily available by geohot. This little tutorial also assumes that you have a working .self generating tool 讓我們做些佈置，假設你沒有那堆geohot釋出的loader金鑰，同時你能夠自己生成 .self檔案〔譯註：二選一，要嘛就是用官方 SDK，不然就是ps3toolchain〕 Now You want to gain code execution to metldr, you know that metldr loads loaders to its own space, but you cannot run a loader because the loader needs to be signed and even though you know about the sign fail that Segher introduced at the CCC, you cannot use it because you don't have decrypted signatures to calculate a private key and to get signatures you need keys which you are currently trying to dump, so far you are stuck in a chicken and egg scenario. 現在你打算把自己的程式片段送進metldr裡頭，同時你也知道metldr會把那堆 loader載到各自的空間去，但是你沒辦法存取那堆loader，因為所有送去給 loader的程式都得先簽證過。就算你知道簽證的方法好了，你也沒辦法簽，因為你沒辦法從解密的簽證推算私鑰，而要解密簽證，則需要你非常想得到的那些金鑰，所以你跌入了雞生蛋、蛋生雞的邏輯陷阱裡了。〔譯註：Mathieulh 是說：如果能夠得到解密的簽證，就可以用暴力法推算私鑰，但是要得到解密的簽證，則需要公鑰〕 The question is, do you really need keys to get a decrypted signature? 揪～竟～是否真的需要金鑰才能解密呢？讓我們繼續看～下～去～（盛竹如貌） Well the real answer is no, thanks to a nifty fail that sony left in in metldr (and the bootloader), you can have the ldr to decrypt the metadata for you, isn't that neat? 答案是：不用。感謝SONY在metldr跟bootloader裡頭留下的nifty 錯誤〔我也不懂〕，我們可以靠這個漏洞取得解密後的metadata。 Here's how it works: 看看是怎麼辦到的： STEP I) 第一步： In a self file, at address 0x0C a value is used to calculate where the metadata is going to be decrypted, the "offset" is at self header +0x0C 在一個標準的self檔案裡頭，在檔案位址0x0C處有個值指向真正主程式的資料起始位址，偏移量是self檔頭加上0x0C。 its the "meta header offset" in the SCE structure, it takes the SCE offset + that value, so what you have to do is to have a calculation that is equal to 0x3E01F0 which happens to be where metldr copies over the shared metadata from the mailbox (which is sent over by the ppu), the trick is to have metldr to decrypt the metadata located at. 在SONY設計的檔案結構裡，這叫做資料檔頭偏移，把SONY的檔頭加上這個值。所以我們只要想辦法把這個資料檔頭偏移的值湊成0x3E01F0，這個值恰好是metldr 把 ppu送來的資料抓去解密的位址，於是呢，metldr就會自動幫我們把加密的資料解密。 So basically you have to 簡單說我們只要： 1) set the offset += 0x2000 將偏移量加上0x2000 dump shared lsa and keep increasing 0x2000 把分享的 lsa讀出，然後再加0x2000 until somewhere in the shared lsa changes 0x40 byte 直到分享的 lsa裡頭某個值改變了0x40位元 2) when it changes 0x40 bytes, you can add/subtract the proper amount to make it decrypt the proper locations 當改變了0x40位元後，我們就可以透過加減的方式讓他自己開始解我們要的位址裡頭的東西 3) then dump shared lsa and we have decrypted header 然後再把分享的 lsa讀出，裡頭就有我們要的解密過的檔頭 knowing that metldr uses SCE header 0xECF0, you could calculate it knowing the address 0x3E01F0 - 0xECF0 = the value you would patch at SCE header + 0x0C 既然知道metldr的檔頭有0xECF0這麼長，我們就可以把位址指到0x3E01F0減去0xECF0這邊，然後把這個位址填到SCE 的檔頭加上0x0C的位置。 ROM:0000F6C0 D2 68 87 E6 metadata_erk: .int 0xD26887E6 ; DATA XREF: ROM:0000F178o for example in CECHA , the address you want to decrypt it to is 0x3E1F0 so it should be 0x3E1F0 - 0xF6C0 舉例，在CECHA 主機裡，metadata的起始位址在0xF6C0，要把這個位址的資料解到 0x3E1F0，必須把偏移量指到0x3E1F0 減去0xF6C0的位置。 Once you get the decrypted header, you have the key to decrypt the rest of the metadata. Here you go, you have your decrypted signature. 得到解密的檔頭後，就有解密其他資料的金鑰了，當然也包含了解密後的簽證了。 So far so good, now what's next? 似乎一帆風順，那下一步咧？ STEP II) 第二步： Contrary to popular beliefs, you do not need to know the public key to calculate the private key, you just need two decrypted signature, you now know how to dump these, so let's assume you just did, now all you have to do is to bruteforce the curve type by constantly reloading a self to metldr, the curve type being only 1 byte, that would be 64 possibilities. 非常詭異，違背一般密碼學的信條，我們竟然不需要公鑰就能推出私鑰。我們只需要兩個不同解密後的簽證，就能辦到，我相信你已經知道該怎麼做了。那我先假設你已經完成了，現在呢，就是透過連續把self載到metldr裡，不斷地用暴力法去踹(try) 橢圓加密的曲線族，曲線族只有一個位元組，所以只有64種可能。 CONGRATULATION, you just signed a loader! 恭喜老爺賀喜夫人，於是我們就能夠自己簽一個loader了。 Now what? 然後咧？ Well Your first reflex would be to sign a loader and use it to dump whatever is in your Isolated Local Store, the first thing you will notice is that you have a bit of metldr's code as a leftover, after a few seconds of disassembly you will figure it's actually some piece of code that clears metldr's code and registers and jumps to some address which is matches your signed loader's entrypoint. 於是我們就能隨便簽一個loader，然後用他來把整台主機裡面隔離空間中的東西全部讀出來。第一個目標當然就是還有一點沒解出來的metldr程式碼，稍微花點時間研究後，發現就是用來把metldr清掉，並把暫存器歸零然後跳回我們剛剛簽好loader起始位置的片段程式。 This seems like a more than likely candidate to exploit, as in your goal would be to overwrite that piece of code with your own, that way you would have the whole metldr code right before the point where everything gets cleared out. 呵，看來這邊可能又有漏洞了，因為我們也能把這邊的程式換掉，比如說換成在 metldr被清掉之前，先複製一份到記憶體某處的程式，這樣可以省很多事。 Let's try to do just that, from your previous dump, you obviously know that the clear code is located from 0x400 to 0x630, (0x410 being where metldr jumps when it clears) your first attempt would naturally be to have a loader section to load at 0x400, well not so surprisingly, it fails, because you are not without a brain (at least you aren't supposed to be if you're reading and understanding this), you will assume that it is likely that metldr checks if you aren't loading your loader/self section below a certain address, which considering you know the loaders' entrypoint is most likely to be 0x12C00, this assumption is in fact correct as metldr will make sure you cannot load any loader at 0x12BFF and below, seems like a huge let down... 那就開工吧！從之前讀出的東西裡頭，你可以知道那段metldr自爆的程式位址在 0x400 到0x630 間（0x410 這裡是清除後跳走的片段），當然很自然地會先嘗試直接載入位在0x400 的程式，但是失敗了，不意外。但人並不笨，如果你能看得懂這篇文章的話，應該就有辦法解決。你會想說，也許metldr在執行程式前會先檢查我們的loader是否嘗試執行某段位於某個特定位址以前的程式？因為一般的 loader，其進入位址多半在0x12C00 ，所以我們可以假設，metldr不會讓我們用 loader載入起始位址在0x12BFF （含）以前的程式，真掃興……。 Well, maybe not, because yet again, you are not without a brain, you check out the hardware properties for the Local Store, and you find out that the memory wraps around (memory is a donut as someone once said at some ccc conference). 嗯，但別急著投降，畢竟你是有頭腦會思考的人，檢查了硬體之後，你會發現其實記憶體這個東西是環狀的，像是個甜甜圈，所以超過某個值後會從頭填起。 So what happens when you load your loader at let's say from 0x3F000 to 0x40000+some address? (like 0x40410 for example) ? 哼，所以要是我們要求我們的loader嘗試載入一個非常高的位址的程式會怎樣？比如說載入一個位在0x3F000 加上某個偏移量的程式，不如就載入位在0x40410 那邊的程式好了。〔譯註：這是典型的溢位攻擊，記憶體只有0x40000 ，因此載入更高的位址就會溢位，被重新對到0x40410 - 0x40000 = 0x410 ，然後metldr 只有檢查下界，沒有檢查上界，所以就變成漏洞。〕 Well, it WORKS! 哇喔，給跑了耶～ You could put the section at 0x3F000, if you made the length 0x1414 and the last instruction branches "up" to the dump code 所以你可以把程式擺在0x3F000 的位置，假設長度是0x1414，然後最後一個指令是跳到「讀出程式」的程式。 ROM:000008AC 33 7F 6C 80 brsl lr, cleanup_and_jump_entry ROM:000008B0 32 00 11 80 br loc_93C ROM:00000410 cleanup_and_jump_entry: ; CODE XREF: main+4Cp ROM:00000410 32 7F FF 80 br sub_40C this is what the exploit that got leaked (yeah that's not really their work eh but you figured that much by now did you not? ) does. It overwrites from 0x000 to 0x480 because I originally loaded the section o size 0x880 to 0x3FC00 這就是這次外流的漏洞（雖然不完全是他們的功勞但你有更進一步認識了吧？） So now you get code execution on metldr at the best time possible because your code executes right after metldr copies the root keys from 0x00 to 0x30, which means you get to dump these too. (Although they are hardcoded in metldr's code anyway) 所以說最好跑程式的機會，就是在metldr把主機管理員金鑰從0x00複製到0x30的時候，這樣也可以一併讀出來（儘管可能還是有加密） Here you go, you have a metldr dump ! 總之，總算把整個metldr讀出來了！ Now as a final line, I'd like to say screw leakers, screw the scene, and this is my last contribution to it EVER. It seems I can't even trust fellow developers to keep my work safe and not leaking it. (Not like any of them would have been able to tell you how all this even works in the first place) 最後，我必須聲明，這是我最後的成果了。看來我在也沒辦法相信有人能夠乖乖的把我的研究成果擺在一個安全的地方，而不是大方地流出，結果害我必須出來收拾殘局，教大家要怎麼用。 So long, everyone. Remember, don't ever bite the hands that feed you. 再會了，各位。記住，千萬別恩將仇報。 P.S. Oh! and btw, if you talented enough to make hardware to dump the shared lsa, you can decrypt any lv0 using this technique. 噢對了，如果你夠聰明，能夠利用硬體讀出分享的 lsa區間，那也能用同樣的手法把 lv0解密。 -- ○ ____ _ _ _ _ ____ _ _ ____ _____ ____ 。 ★(_ _)( \( )( \/ )( ___)( \( )(_ _)( _ )( _ \ ｏ _)(_ ) ( \ / )__) ) ( )( )(_)( ) / ● ‧ (____)(_)\_) \/ (____)(_)\_) (__) (_____)(_)\_) ★ ｏ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.120.31.137 ※ 編輯: cassine 來自: 140.120.31.137 (11/09 12:07)