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)