[gregory2590]

Originally Posted by Goon3r way to call rank their im far from a troll, im a long time follower of the site who instead of posting crap in each n every thread, takes a back seat and watches/waits for developments quiety/politely. im also learning to code, and the signs are positive, first's in all university assignments modules based on coding wether its web or software, i move onto to studying C and C++ half way through this year, so hopefully in the future i will be able to contribute more to the scene rather than having to explain myself to a quite frankly rude staff member. if that makes me a troll to you though, ill welcome the title. I know people are saying this will lead to a 3.73 cfw or new games on the current firmwares, but in my last post i meant currently what people are waiting for realistically. I dont think we will see some new cfw anytime soon, id love to be proven wrong on this though.

Your avatar says otherwise!

...wait ****, doesn't that mean mine does otherwise as well?!

[bost7]

We will make an organised attack to mathieulh twitter asking for the CFW.

We will gather some ppl, lets say 500-600 and we will post 600 times "Please release your CFW 3.73 annonymously."

It's gonna work fellas.It's gonna work.

[GregoryRasputin]

Originally Posted by Goon3r so hopefully in the future i will be able to contribute more to the scene rather than having to explain myself to a quite frankly rude staff member.

Its a pity you don't contribute, instead of harrasing me, which half your posts do, as i said before, removing you is not a problem....

[denxing]

Originally Posted by bost7 We will make an organised attack to mathieulh twitter asking for the CFW. We will gather some ppl, lets say 500-600 and we will post 600 times "Please release your CFW 3.73 annonymously." It's gonna work fellas.It's gonna work.

except that he doesn't have a 3.73 cfw

[fouzi]

Originally Posted by bost7 We will make an organised attack to mathieulh twitter asking for the CFW. We will gather some ppl, lets say 500-600 and we will post 600 times "Please release your CFW 3.73 annonymously." It's gonna work fellas.It's gonna work.

wont gonna work with math

[side21]

As i was reading through every single post, i frankly had enough after reading up to the 70th page and now decided to post a small message myself.

PLEASE STOP THE FLAMING ****.

Majority of the posts are either attacks or counter attacks in regards to Mathileu which is worthless. I'm no expert in this scripting but I am damn interested on how Math could come up with a solution for the release of lv0 (even if it not legit). If you feel it's not legit then please do something more productive like clicking on the TUTORIAL pages on these forums and goggling! to start getting a hold of in-depth knowledge about the software/hardware architecture, so you yourself can learn something about decrypting or creating application to achieve something which will be useful to the scene.

People who already know how to do this stuff but just attacking/defending Math should start a new topic under a debate or IMHO under a spam section so you can have your keyboard warrior feuds with one another.

Reserve posts for something which is actually worth reading.

[bost7]

Originally Posted by denxing except that he doesn't have a 3.73 cfw

I believe he has it.

I have a feeling.

[daveyp187]

omg of corse he has it..

just look at all the things math has done for the scene.

[baargle]

Originally Posted by daveyp187 How to pwn metldr the "easy" way 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) That's about how I am pissed 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: This is most likely how geohot exploited it in the first way, 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) 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 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. 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 ? 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 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. So basically you have to: 1) set the offset += 0x2000 dump shared lsa and keep increasing 0x2000 until somewhere in the shared lsa changes 0x40 byte 2) when it changes 0x40 bytes, you can add/subtract the proper amount to make it decrypt the proper locations 3) then dump shared lsa and we have decrypted header 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 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 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. CONGRATULATION, you just signed a 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. 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. 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... 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) ? 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. 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) Here you go, you have a metldr dump ! 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. // verify metadata offset is not too big //if (data->self_header->metaOffset >= 0x800) //return 0x20; // OOPS: COMMENTED OUT! ALMOST AS KOOL AS get_rand() { return 4; } From the PS3 Metldr Exploit ReadMe file: # insmod ./spp_verifier_direct.ko # cat metldr > /proc/spp_verifier_direct/metldr # cat isoldr > /proc/spp_verifier_direct/isoldr # cat RL_FOR_PROGRAM.img > /proc/spp_verifier_direct/rvkprg # cat EID0 > /proc/spp_verifier_direct/eid0 # cat spp_verifier.self > /proc/spp_verifier_direct/spu # cat default.spp > /proc/spp_verifier_direct/profile # echo "1" > /proc/spp_verifier_direct/run # cat /proc/spp_verifier_direct/debug Also from Mathieulh attempting to defend himself from PS3 Scene Devs: Oh ! and to people who might doubt it's a leak (As in 2 people who might by some miracle have found the very same exploit), the leaked appldr-metldrexploit350.self file not only bares the same name but the same hash and obviously the same signature as the file I've given out to the few people that had it. If you don't know about this, because of the rand functions involved, the chances of getting an identical signature on a self file are one to trillions, so yeah, definitely my stuff. To people still claiming that the leaked files weren't crafted by me, look at "run.sh" the "/proc/metldrpwn/mathldr" line is a dead giveaway. IRC Log here: http://pastebin.com/HwkP0Bfg Oh ! and just so you know, because the "donut fail" requires a signed ldr to work and gain code execution in metldr doesn't mean there is no way to pwn metldr.2 though obviously you can't use that particular exploit for this) Not like you really need to dump a metldr with an updated keyset, a hardcoded 3.60 min ldr version and some useless gcc optimizations though. By the way, to Sony engineers' credit, they did check if you'd load a ldr at 0x40000+ they just didn't check if you'd load it at 0x3FFFF or below and have it a positive size I wonder if people noticed the metldr.spu.cecha.elf, metldr.spu.cech2500.elf and the 1.3MB metldr-cecha.idb in my metldr's collection pic From Sony PS3 hacker adrianc: I hate to burst everyone's bubble but this means nothing. The chain of trust was fixed by moving loaders into lv0. Until lv0 is either dumped or decrypted, the loaders, and therefore the keys will remain just out of reach. Cold boot exploits are not possible because lv0 sets up the loaders table before passing execution to lv1. Decrypting lv0 requires pwning the bootloader_PE, which is very difficult. If you could sniff the flexio you might be able to dump it that way. Or you could use what is known about the CBE secure boot to preempt bootldr. I suggest the IBM docs as reading material. They are encrypted with the same key, which is burnt into the CBE efuses. This key is never passed along the chain of trust, so neither metldr or bootldr ever sees their own key. Metldr dumps will give you some perspective on how secure loaders work, and possibly stimulate some ideas for how you might be able to pwn bootldr. However, there is no easy 'find a key, use a key' solution to be found inside metldr. This exploit does not enable you to find the hardware root key, merely a much weaker derivative which exists to prove the secure loader has been authorised by hardware. Unconfirmed PS3 Bootldr Key: http://pastebin.com/pWVav1qK D7 EA 42 1B 73 87 15 97 D7 7C D7 7C E3 E5 50 F5 37 30 96 30 From naehrwert: http://pastie.org/2858016 74 92 E5 7C... AB CA AD 17... B0 D6 55 76... 3E C2 0C 17... D9 2D 65 DB... F2 33 6E 25... 52 38 D0 FA... Related Tweets: 7492E57C2C7C63F44942268FB41C58ED... I found out a lot more too 94D100BE6E24991D65D93F3DA938858CEC2D133051F47DB4287AC86631719B31573EF7CCE071CA8A (placeholder for the future) eidtool "eid0_hash_encrypt_section_0" aes_omac1(section_in + 0xA8, section_in, 0xA8, key, 0x80); From xorloser: The "metldr exploit" had already been replicated long ago by many ppl who feel no need for public acknowledgement. Finally, from lunuxx via JailBreakScene: Well it works, go get your root key. http://pastebin.com/8ZCqqsQq tail -n +2 dump.txt | cut -b 11-58 | tr -d " \n" | xxd -r -p > output.txt Well in the first 3 lines of my dump: root riv: 00000020 7d 6a 3a e5 37 ba 48 4c fe bd 26 5c f5 b1 28 1f |}j:.7.HL..&\..(.| root erk: 00000000 66 4d ee 51 65 6f 68 28 38 98 83 ea df ea 90 04 |fM.Qeoh(8.......| 00000010 01 f3 79 09 d6 a6 52 d9 ea 6d ef 04 51 69 ec 7b |..y...R..m..Qi.{| 13:15:33 Mr_SaMSa • 00000010 01 f3 79 09 d6 a6 52 d9 ea 6d ef 04 51 69 ec 7b |..y...R..m..Qi.{| 13:15:33 Mr_SaMSa • 00000020 7d 6a 3a e5 37 ba 48 4c fe bd 26 5c f5 b1 28 1f |}j:.7.HL..&\..(.| 13:15:33 Mr_SaMSa • 00000030 32 7f ff 80 32 7f ff 80 32 7f ff 80 32 7f ff 80 |2...2...2...2...| 13:15:33 Mr_SaMSa • these are root key From IRC: [eussNL] that is how you can verify your metldr dump, by looking for http://pastebin.com/erEdEF6Q ERK+RIV: [eussNL] Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F [eussNL] 0000C740 C0 CE FE 84 C2 27 F7 5B D0 7A 7E B8 46 50 9F 93 ����'�~�FP�" [eussNL] 0000C750 B2 38 E7 70 DA CB 9F F4 A3 88 F8 12 48 2B E2 1B �8çp���£��. [eussNL] 0000C760 47 EE 74 54 E4 77 4C C9 B8 96 0C 7B 59 F4 C1 4D G�tT�wLɸ-.{Y�� [eussNL] 0000C770 04 05 06 07 80 80 80 80 0C 0D 0E 0F 80 80 80 80 ....����....���� [eussNL] 0000C780 FF FF FF FF FF FF FF E0 00 00 00 00 00 00 00 00 ��������........ PUBLIC: [eussNL] Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F [eussNL] 0000EC30 C2 D4 AA F3 19 35 50 19 AF 99 D4 4E 2B 58 CA 29 ���.5P.���N+X�) [eussNL] 0000EC40 25 2C 89 12 3D 11 D6 21 8F 40 B1 38 CA B2 9B 71 %,�.=.�!.@�8ʲ�q [eussNL] 0000EC50 01 F3 AE B7 2A 97 50 19 00 00 00 00 00 00 00 00 .�®�*--P......... Now we just need a way to do it ourselves without having to install linux on our PS3. They are different for each PS3 (box-specific key that Metldr is signed with, which has new keys for the rest). Lunuxx was just showing us that it is possible and safe to try. It also gives us reference to what a proper dump should look like

You're a bit late to the party, it's trivial to dump metldr with his exploit...any foold could do it. But a total waste of time.

[RickDangerous]

Originally Posted by bost7 I believe he has it. I have a feeling.

No, he doesn't! I'm sure he has the root key however, but I don't think he cares about CFW, pirated games, and so on. To him, it's all about the challenge of hacking the unhackable.