Hey there.

So... you use an ad blocker. That's cool. Sometimes we do too.

But without ad revenue, we wouldn't even be here. And we might not be here much longer.

Please disable your ad blocker and click to continue.

Page 5 of 26 First ... 45615 ... Last
  1. #41
    Transient Guest
    Quote Originally Posted by technodon View Post
    thats not true, all keys are inside lv0 also he wont calulate the private key since sony fixed the sign fail bug in 3.60, guess he was trolling
    lv0 key can't be inside lv0 though, can it? How would the PS3 decrypt it in the first place? It has to be available before then.

  2. #42
    technodon Guest
    no, the key to decrypt lv0 is found in bootloader, then inside lv0 you will find apploader keys and all other loader keys for lv1 and lv2 etc.. ask him to upload a decrypted lv0.elf and we can have a look our ourselves

  3. #43
    geoduk Guest
    Don't waste your time ... It's fake

    Just look at encrypted ps3swu.self ofw4.25, offset 0x0020401C

  4. #44
    jabberosx Guest
    so i'm going to guess this is a bummer too. oh well.. back to gangnam style!

  5. #45
    boxbundy Guest
    really makes me wonder what pleasure some get from making fake cfw on youtube and talking rubbish on ps3 websites. there's so many of them out there. it's pretty childish really. just amazes me. Why would you do it? I don't get it

  6. #46
    JOshISPoser Guest
    you said it. they're children. it gives them their jollies from other people's misery. i get poking fun every now and then with buddies, but as you grow up, you realize the world is much nicer when everyone is nicer.

  7. #47
    Join Date
    Apr 2005
    Agreed, on that until "anonymous" replies back with new information (if he ever does, that is) we will close this up as from the sound of things the key doesn't appear valid anyway. Back to the waiting game it seems

  8. #48
    randomstuff Guest

    PS3 LV0 Keys Leaked: 4.21, 4.25 and 4.30 CFW Updates Incoming!

    Following up on the PS3 3.60 Keys leak comes a bright light at the end of the PlayStation 3 tunnel, as today an anonymous user has leaked the PS3 LV0 Keys meaning 4.21, 4.25 and 4.30 CFW updates are incoming!

    Download: PS3 SCETool v0.2.9 + Keys for LV0 (125.2 KB)

    [Register or Login to view code]

    To recap, below are the confirmed legit and working PlayStation 3 LV0 Keys:

    ERK = CA7A24EC38BDB45B98CCD7D363EA2AF0C326E65081E0630CB9 AB2D215865878A
    RIV = F9205F46F6021697E670F13DFA726212
    PUBLIC = A8FD6DB24532D094EFA08CB41C9A72287D905C6B27B42BE4AB 925AAF4AFFF34D41EEB54DD128700D
    PRIVATE = 001AD976FCDE86F5B8FF3E63EF3A7F94E861975BA3
    CURVE_TYPE = 0x33

    PS3 Key dump from appldr 4.25 in SCETool format:

    [Register or Login to view code]

    From zadow28 comes lv0.elf: yep working: http://rghost.net/41097133 (4.21) / http://rghost.net/41097551 (4.25)

    I've extracted and decrypted some off the loaders, go search for keys: http://rghost.net/41097829 (the 4.elf I uploaded is the appldr.elf)

    [Register or Login to view code]

    Some files inside that could be not be decrypted: http://rghost.net/41097841

    Going throw appldr 4.25 dosen't look like there are revision 1C keys in there for 4.25 eboots.

    One thing i found out thats interesting.. the lv0 had 6 files inside. 3 that could be decrypted = appldr/isoldr/lv2ldr. 3 that couldn't. But if you look in hex you would notice that the 3 unknown files is simply headers. I also noticed in the rest of the lv0 files there are encrypted hex sections.

    So my guts says that you should try match the headers with some of the encrypted data/hex there you would probably find the missing lv1ldr if you succeed.

    From haz367: added to scetool, decrypts fine

    scetool 0.2.9 <public build> (C) 2011-2012 by naehrwert
    NP local license handling (C) 2012 by flatz
    • Loaded keysets.
    • Loaded loader curves.
    • Loaded vsh curves.
    • Using keyset [lv0ldr 0x0000 04.25]
    • Header decrypted.
    • Data decrypted.
    • ELF written to C:\cygwin\home\xxx\425ofw\update_files\CORE_OS\lv0 .elf

    From zecoxao: https://dl.dropbox.com/u/35197530/lv0.elf this one is from 3.55, since i didn't have any other than this and the jig one. https://dl.dropbox.com/u/35197530/keys and updated keys file

    Usage: scetool -d lv0 lv0.elf

    From aldostools: add this to keys file:

    [Register or Login to view code]

    Please the leaked keys in: home\username\.ps3

    Name them:
    • lv0-ctype
    • lv0-iv-key
    • lv0-key-key
    • lv0-priv-key
    • lv0-pub-key

    No version number required.

    From Cyberskunk: Just be patient people... WE HAVE 100% WORKING solutions with no brick risk or complications.. tested for the last month not just spat out as fast as possible. After OFW 4.30 release.. not long..

    From danixleet: Can we add these (https://dl.dropbox.com/u/35197530/keys) to SCETool to resign 4.x games for 3.55? Appldr needs to be reversed before us end user's get the updated keys file for SCETool...

    Anyway Lv0 now decrypted for ever but it still need a lot of RE work to be able to get decrypted loaders from it since Sony had changed a lot of security algorithms to protect this loaders inside Lv0. Also we will not find 4.xx appldr keys inside the decrypted Lv0 so it still need more work to figure out how Sony store this keys right now.

    1) Yes with the leak of lv0 keys we can decrypt lv0 > extract appldr > decrypt appldr with metldr keys > locate the keysets >> unicorns

    This then enables us to decrypt any eboot / sprx etc for games and resign them with 3.55 keys .. (That is what is what you're looking to do)

    2) fail0verfl0w exposed a flaw in sonys encryption ECSDA or whatever its called lol...
    • what does this mean? it means we can calculate the private keys
    • what are private keys ? there used to encrypt sony files.. aka SELF. SPRX etc, etc

    So up until 3.55 we can calculate every key sony used to SIGN there files, thus making valid application, thus enabling homebrew etcc or whatever. 3.56+ that has been fixed and we can no longer calculate the private key... but yes we can still grab the public keys, as they are within the FW..

    Public Keys Decryption / Private Keys Encryption

    3) geohot released hes NPDRM tools which had static private keys, sony apparently blocked them keys, once npdrm was worked out, new tools had been released to select different keys, aka dont use geohots tools, there flop, even math stated this..

    4) you can use any sony npdrm private key in scetool and produce homebrew with will execute on any OFW... aka 3.60++ .... sony can't block there own keys, cause then all there old psn games etc would not work unless updated and there not gonna back date the updates for extremely old games lol..

    5) yes we can decrypt all current games and resign them for 3.55 if needed..

    6) lv0 private key cant be changed as bootldr cant be updated, so for example, every new fw out can now become CFW... or for instance step 1)... aka you download 4.30 extract the pup or install and nor dump... decrypt lv0 etc etc (step 1) and add the new appldr keys to scetool... their chain of trust was "fixed" in 3.60 but once you pwn bootldr its game over, as bootldr would hold lv0 keys and lv0 signing cant be updated.. so pwnddd for lifeeee !!!

    From KaKaRoToKS (via pastie.org/private/3np6uj6md1occbctdeir6a) comes an update on his previous exploit as well:

    Since the LV0 keys have now been leaked, I believe I can now share this info with you, to help out those who are trying to build their own 4.x CFW:

    The NPDRM ECDSA signature in the SELF footer is checked by lv2. It first asks appldr to tell it whether or not the signature is to be checked, and appldr will only set the flag if the SELF is a NPDRM with key revision from 3.56+ (the ones without private keys). This means that the SELF files signed with the new 3.56+ keys still don't have their ecdsa checked (probably to speed up file loading).

    If appldr says the ecdsa signature must be checked, then lv2 will verify it itself, and return an error if it's not correct. There are many ways to patch this check out.

    1 - Patch out the check for the key revision in appldr
    2 - Patch out the "set flag to 1" in appldr if the key revision is < 0xB
    3 - Patch out the code in lv2 that stores the result from appldr
    4 - Patch out the actual sigcheck function from lv2.
    5 - Ignore the result of the ecdsa from lv2.

    Here is one of the patches (the 4th one, patching out the check function from lv2) :
    In memory 0x800000000005A2A8, which corresponds to offset 0x6a2a8 in lv2_kernel.elf, replace :

    [Register or Login to view code]

    With :
    [Register or Login to view code]

    This is for the 4.21 kernel (that was the latest one when I investigated this), I will leave it as an exercise to the reader to find the right offsets for the 4.25 and upcoming 4.30 kernel files.

    And here's another bit of info... in 4.21 lv2, at memory address 0x800000000005AA98 (you figure out the file offset yourself), that's where lv2 loads the 'check_signature_flag' result from appldr, so if you prefer implementing method 3 above, just replace the 'ld %r0, flag_result_from_appldr' by 'ld %r0, 0' and you got another method of patching it out. Either solutions should work just the same though. Enjoy homebrew back on 4.x CFW....

    p.s: Thanks to flatz and glu0n who helped reversed this bit of info.

    From marcan42 (a PS3 dongle developer): The correct name for the PS3 keys that were released is "bootldr keys", not "lv0 keys": named after the verifier, not what is verified. bootldr is the name of the code living at address 0 in Flash (which is loaded by the SPU isolated mode boot ROM). Keys are named after the verifier because we decided so originally, and everyone else stuck to it. No point in changing it now.

    To quote (via games.slashdot.org/comments.pl?sid=3205473&cid=41747075):

    "The first-stage bootloader is in ROM and has a per-console key which is effectively in tamper-resistant silicon. The second-stage bootloader (bootldr) is encrypted with the per-console key, but is not upgradable and is the same for all consoles (other than the encryption wrapper around it). This second-stage bootloader verifies lv0.

    Sony signed lv0 using the same broken process that they used for everything else, which leaks their private key. This means that the lv0 private key was doomed from the start, ever since we demonstrated the screwup at the Chaos Communication Congress two years ago.

    However, because lv0 is also encrypted, including its signature block, we need that decryption key (which is part of bootldr) before we can decrypt the signature and apply the algorithm to derive the private key. We did this for several later-stage loaders by using an exploit to dump them, and Geohot did it for metldr (the "second root" in the PS3's bizarre boot process) using a different exploit (we replicated this, although our exploit might be different).

    At the time, this was enough to break the security of all released firmware to date, since everything that mattered was rooted in metldr (which is bootldr's brother and is also decrypted by the per-console key). However, Sony took a last ditch effort after that hack and wrapped everything after metldr into lv0, effectively using the only security they had left (bootldr and lv0) to attempt to re-secure their platform.

    Bootldr suffers from the same exploit as metldr, so it was also doomed. However, because bootldr is designed to run from a cold boot, it cannot be loaded into a "sandboxed" SPU like metldr can from the comfort of OS-mode code execution (which we had via the USB lv2 exploit), so the exploit is harder to pull off because you don't have control over the rest of the software.

    For the exploit that we knew about, it would've required hardware assistance to repeatedly reboot the PS3 and some kind of flash emulator to set up the exploit with varying parameters each boot, and it probably would've taken several hours or days of automated attempts to hit the right combination (basically the exploit would work by executing random garbage as code, and hoping that it jumps to somewhere within a segment that we control - the probabilities are high enough that it would work out within a reasonable timeframe). We never bothered to do this after the whole lawsuit episode.

    Presumably, 18 months later, some other group has finally figured this out and either used our exploit and the hardware assistance, or some other equivalent trick/exploit, to dump bootldr. Once the lv0 decryption key is known, the signing private key can be computed (thanks to Sony's epic failure).

    The effect of this is essentially the same that the metldr key release had: all existing and future firmwares can be decrypted, except Sony no longer has the lv0 trick up their sleeve. What this means is that there is no way for Sony to wrap future firmware to hide it from anyone, because old PS3s must be able to use all future firmware (assuming Sony doesn't just decide to brick them all...), and those old PS3s now have no remaining seeds of security that aren't known. This means that all future firmwares and all future games are decryptable, and this time around they really can't do anything about it.

    By extension, this means that given the usual cat-and-mouse game of analyzing and patching firmware, every current user of vulnerable or hacked firmware should be able to maintain that state through all future updates, as all future firmwares can be decrypted and patched and resigned for old PS3s. From the homebrew side, it means that it should be possible to have hombrew/linux and current games at the same time. From the piracy side, it means that all future games can be pirated. Note that this doesn't mean that these things will be easy (Sony can obfuscate things to annoy people as much as their want), but from the fundamental security standpoint, Sony doesn't have any security leg to stand on now.

    It does not mean that current firmwares are exploitable. Firmware upgrades are still signed, so you need an exploit in your current firmware to downgrade. Also, newer PS3s presumably have fixed this (probably by using newer bootldr/metldrs as trust roots, and proper signing all along)."

    In summary, you can sign homebrew with old NPDRM keys which haven't been revoked. We don't have 3.60+ private keys for RETAIL signing (not NPDRM), but we don't need them as NPDRM keys can be used instead and the homebrew signed as NPDRM content.

    In conclusion, according to afiser while Sony can update lv0 they must use the same keys to encrypt it each time or else bootldr wouldn't be able to load it. PlayStation 3 3k+ consoles have LV0.2 so it's not the same key. For those interested in examining them some LV0 dumps can be found via ps3devwiki.com/wiki/Loaders#Loader_encapsulation_in_lv0 as well.

    Update: From woulph_alfa via Spanish site (ps3sos.com/showthread.php?29532-Keys-LV0-liberadas/page23) comes the following theory on the encryption, roughly translated:

    I bring you good info compiled by me. I've been throwing a couple of hours to file the 4.25 appldr good here's a short summary of what is the content of. Elf

    I will explain:

    [1] - WA (Writing and Assignment) is not interested in a lot ... But do not rule ...
    [2] - AX (allocation and execution) party quite important since it is the only part of "executable" You can look at the content from 100 to 01ba10 Possibly OFFSET is the one responsible for making the decryption of the RIV and ERK. Apart from checks ...
    [3] - A (Assignment) and finally the most interesting part of the file, in this section I think is where the KEY to decrypt the RIV and ERK (See the second image there is the structure)
    [4, 5, 6] - WA (Writing and Assignment) Here are the keys of the appldr from 4.25 up to the first keys appldr


    [Register or Login to view code]

    What is the encryption method that uses NO IDEA AS IF WE HAD A LONG AND THE ....

    Possibly a little further investigation, if anyone wants me to help out ... welcome! OJO not expect great progress on my part, because currently I have no means eager.

    More PlayStation 3 News...

  9. #49
    kokotas Guest
    • Loaded keysets.
    • Loaded loader curves.
    • Loaded vsh curves.
    • Using keyset [lv0ldr 0x0000 04.25]
    • Header decrypted.
    • Data decrypted.
    • ELF written to C:\scetool\lv0.elf.

    Seems legit!

  10. #50
    garine Guest
    Nice news

Page 5 of 26 First ... 45615 ... Last

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Log in