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 4 of 7 First ... 345 ... Last
  1. #31
    Brenza Guest
    sony can read pretty much anything they want. everytime you connect the ps3 to internet (NB: internet, non psn) it automatically uploads the log files

    these files contains the all ps3 activity, sony's fw are 175MB of code (compressed) and they could put some checker everywhere in the firmware, if one of these checks finds out that your ps3 is running a non-original firmware sony'll know it.

    the only thing we can do is locate these checks and find out a way to bypass all of them

  2. #32
    Join Date
    Apr 2005

    PS3 IDPS Changer v1.1 Homebrew Application is Now Available

    Following up on the PS3 IDPS Proj3ct, today PlayStation 3 developer Joris (aka JorisD33) has made available PS3 IDPS Changer version 1.1 followed by v1.3 and IDPSet v0.6 and some updates with details below.

    Download: PS3 IDPS Changer v1.1 / PS3 IDPS Changer v1.1 (Mirror) / PS3 IDPS Changer v1.3 / IDPS_Changer.zip (Latest Version) / idpstool.pkg / IDPSet_v0.6.pkg (IDPSTool and IDPSet by Zar to change PS3 IDPS) / IDPSet_v0.62.pkg / IDPSet_v0.75.pkg / IDPSet_v0.76.pkg / IDPSet_v0.77.pkg / IDPSet_0.78.pkg / IDPSet_v0.79.pkg / IDPSet_v0.80.pkg / IDPSet_0.82.pkg / IDPSet_v0.83.pkg / IDPSet_v0.84.pkg / IDPSet_v0.85.pkg / IDPSet_v0.86.pkg / IDPSet_v0.87.pkg by Zarh / EIDROOT.rar by Joonie

    From the ReadMe File: What do this application do?

    This application will change your IDPS and optionally your MAC address into your flash dump.

    How can I use it?

    Just put a VALID(!) NOR/NAND dump called dump.bin and your eEID Root Key called eid_root_key.bin into the same directory, run the program and enter your new IDPS.

    Your modified dump will be created as dump_patched.bin, you just have to flash it back to your console.

    How can I dump my eEID Root Key?


    How can I dump my flash?
    • Hardware flasher (E3, Teensy, Progskeet...)
    • Multiman
    • ...

    How can I byte-reverse my dump?

    Flowrebuilder: FlowRebuilder v. / FlowRebuilder v. (Mirror) Changelog:
    • added support to manage NAND preloader dumps
    • message user about the type of dump
    • message the user if bootloader are missing
    • auto-recognize if dump is normal or byte swapped and automanage them

    If you byte-reverse your dump before using this application, remember to byte-reverse it back after the procedure.

    CHANGELOG 1.0:
    • Initial release

    From haz367: proper eid0 section/part conversion so the new idps at least has correct values after it (cex2dex offsets 002F090-2F14F//omac hash)

    offset 2F077/2F07F (new idps)

    offsets/block: 2F090-2F14F - new values calculated/added to have valid idps change? at least better then only changing IDPS line

    offset 303D7/303DF (new idps)

    offset 3F040-3F045 (new mac)

    tested offline and trashed with my own dumps. not needed but people deserve second change right, only need to brick another PS3 to get new idps. great share for that.

    Update: PS3 IDPS Changer v1.3 Changelog: Here is the latest version of this sweet little app. I had troubles using all versions prior and now I have permanently installed new IDPS on over 30 systems. Make sure you have openssl installed via cygwin, enable XP SP2 compatibility on openssl.exe. Then grant admin access to openssl.exe as well as IDPS Changer then drop these files in the cygwin directory to ensure all the needed dll files are present.

    Name your eEID Root Key - eid_root_key.bin (obtained via FW 3.55)
    Name your NOR/NAND dump - dump.bin

    Then place these in the cygwin folder as well with the other stuff we just installed/added

    Then simply run the IDPS Changer.exe and follow instructions, this also allows changing of your MAC address. After the app is done simply rename the dump_patched.bin to the following depending on your flash type NAND or NOR.



    Once you have named the file copy on to a flash drive and open mM and go to mMOS then open the drive with the newly patched dump. Double click on it and wait for it to install. Once done reboot your system and go back to mM and the settings and look at your new MAC/IDPS on your freshly unbanned PS3.

    Update #2: IDPSTool become IDPSet v0.6 is now available (linked above) by Zar from the PS3Gunz French site.

    With this new version, you can permanently change your console IDPS (NAND and NOR). You just have to run IDPSet on your CFW (with Eid Root Key and valid IDPS on your USB key).

    Finally, Zarh made available IDPSet v0.62 PKG with the following updates and further revisions:
    • added the default paths of FLATZ's eid_root_key dumpers
    • added a check of eid_root_key
    • and now it's display the region matching with the target ID
    • fix name of dumps

    IDPSet v0.75 / v0.76 Changelog:
    • Support fw 4.65
    • New UI
    • Remove PSID stuff (it's useless)
    • Remove Save/load to/from file (it's useless)
    • New option: Convert to DEX/CEX only for rebug
    • New option : "Dump eid_root_key" only for cex fw: 4.65, 4.53, 4.50, 4.46, 4.21 to "/dev_usb000/eid_root_key" else "/dev_hdd0/tmp/eid_root_key"

    IDPSet v0.77 Changelog:
    • better check on rebug firmware
    • added swap kernel in ros1 too
    • added check if syscall lv2 peek&poke are available

    IDPSet v0.78 Changelog:

    Indeed, sorry i forgot to tell you v0.78 is out.. I hope this one will be the last update

    IDPSet v0.79 Changelog:

    Hi, I have updated IDPSet to v0.79: Changelog since last official release of v0.62
    • Add : version nb in TITLE
    • Add : progress bar
    • Add : nouveau UI
    • Removed : all PSID stuff
    • Removed : save/load from/to file
    • Add : "dump eid_root_key" only for 421C, 450C, 446C, 453C, 465C (ty flatz and zecoxao)
    • Add : "Convert to DEX/CEX" only for rebug
    • Add : "Make CEX/DEX dumps" is faster
    • Add : support fw 4.65 (4.66 too btw)

    Previous changes from v0.62:
    • Added the default paths of FLATZ's eid_root_key dumpers
    • Added a check of eid_root_key
    • And now it's display the region matching with the target ID
    • Fix name of dumps

    The idps.bin and eid_root_key must be in the root of the USB.

    Known issue:

    Dumps & the root_key file have the attribut "system", i don't know why, and i don't know how to remove it with the ps3 system. But here the cmd to remove it with windows.

    [Register or Login to view code]

    I've made a batch for the lazy ones: remove_attrib.bat. Just put this file in the root of usb and click on it. it will remove all the attributes.

    Thanks to all testers.

    PS: If someone know why these files have this fcking "system" attribute or how i can remove it, plz help me

    IDPSet v0.80 Changelog:

    Thanks to badboy and matsumoto, i have updated to v0.80:

    Changelog v0.80:
    • The dumps no longer have the attribute "system"

    Changelog v0.82:

    I have updated IDPSet to v0.82 thanks to baileyscream and jonnyjaeger

    NEW Changelog - version 0.82:
    • Fix: No more freeze when making CEX&DEX dumps with a DEX system

    Changelog v0.83 (JAN/3/15):
    • Fix: random freeze

    I fixed random freezes described by Tactik-knife. Thanks.

    Changelog v0.84 (FEB/21/15):
    • Added: Swap of "software_update_plugin.sprx"

    Changelog v0.85 (JUL/26/15):
    • Added: Background image (a PNG is: /USRDIR/BG.PNG)
    • Added: Homebrew is compatible with fw 4.70 and 4.75
    • Added: The dumper for the root key is compatible with fw 4.70C, 4.70D and 4.75

    This is just a little update to support new firmware.

    Changelog v0.86 (JUL/27/15):
    • fix: no more freeze when you dump your key for firmware under 4.65.

    FYI. I wasn't in hurry because you still can do it wit the rebug toolbox (that's also why i didn't ported it to every fw) but just to have something proper, I think I solved this issue with this update, can you try ?

    Changelog v0.87 (SEP/23/15): (adds 4.75 DEX support)
    • Added : fw independent
    • Added : root key dumper 4.75D (thanks to Joonie who ported it)
    • Added : more message in the log to be more aware of what's going on and also to allow me to know precisely what's causing some 'random' freeze (thanks to your feedbacks ofc)

    • The root key dumper and Converter are not fw independent
    • We can't write PSP IDPS in the EID0 without bricking the system.

    More PlayStation 3 News...

  3. #33
    s25s Guest
    great work

    we need also update for change (psid) because some of ban in psid

  4. #34
    onik Guest
    is there any brick possibilities while reflashing??

  5. #35
    mahidi Guest
    DLL files is missing after downloading the dll it still asking me for ssleay32.dll why they couldn't make this program perfectly??

  6. #36
    Join Date
    Apr 2005

    PS3 IDPS / PSID Changer by Zecoxao, Permanently Change IDPS / PSID

    Following up on the previous PS3 IDPS Changer and ChangePSID, today PlayStation 3 developer zecoxao has released an updated PS3 IDPS / PSID Changer alongside Dump_Sbmmio.pkg with details below.

    Download: idps_psid_changer.zip / cygwin1.dll / idps_psid_changer.zip (Mirror) / idps_psid_changer.zip (Mirror #2) / Private Key Bruteforcer / dump_sbmmio.pkg / EID Root Key Dumper (Updated) / Dump_EEID / Flash_EEID

    To quote: Ok guys, so here's something I have for you. This is an idps/psid changer.

    This changes the idps in section 0 or section 6 and the psid in section B (not A sorry, i corrected that on the wiki) PERMANENTLY on flash. so, you know the drill. be VERY careful when using this tool and always take precautions with a flasher.

    You're going to need 5 things: root_key, a backup of your nor flash (only nor is supported at the moment but you can easily make it compatible for nand consoles by changing the offsets at merge_section as well as change the name to whatever you wish to call your flash), a back up of eid (you can obtain this with flow rebuilder or using memdump) and, obviously, the idps and the psid you want to use on your console.

    As for the final hash in each section, the libeeid creator was kind enough to take care of that, so don't worry about that but PLEASE use valid idps and psid files!!!

    Any questions, please ask. and yes, that handles cex2dex too.

    [Register or Login to view code]

    Anyways, i figured this might be easier to use than c2d, because you can take a look at the source yourself and see and do your own changes, in case there's anything wrong.


    Finally, in related news zecoxao has also made available a PPU Binary Backup Manager but it needs testing.

    To quote: I have a binary of a backup manager precompiled a long time ago. I'm not sure if it's even possible to boot it but I'm convinced this binary is meant either for 3.41 or 3.55, but i need someone to test it.

    Here's the binary.. please report if it works signed as disc eboot/npdrm eboot on 3.55 or 3.41. Thanks.

    Download: test.elf

    To avoid creating unnecessary new threads i'll just post this here. i need also someone who can test this pkg.

    PLEASE be careful about this one and keep a flasher with a backup of your flash with you! this is dump_flash from gitbrew in psl1ght v1.

    This contains two changes. there's an aditional poking in the memory for NAND flash dumping to allow the bootldr unmasking (as per a specific wiki section on the Hardware flashing page), and there are no debug outputs with udp_printf, so it should be faster to dump. This is ONLY for 3.55!

    You can see the code on wargio's repository (github.com/wargio/dump_flash), but it's adapted to v2. to use it on v1, simply change the file lv2_syscalls.h to the one on gitbrew on the common git and the Makefile must have the respective include for ppu.mk in v1 (it differs in v2). if you just want to use the repository you can clone it or fork it. Careful with it though. it's not guaranteed it works !

    What remains...

    mc_iso and me_iso individuals seed (unknown what this does at the present time)

    [Register or Login to view code]

    F2 33 6E 25 63 B6 03 07 7A 76 65 71 26 CA E4 DB
    82 0E 92 85 6B 69 3C E8 14 22 E9 FB 1C 1C A5 B3
    E9 43 38 8E 4B 48 03 50 AA 24 A5 FB FA BF D1 72
    D9 7A 1E 25 DE 3E 64 A0 A7 A4 82 52 84 56 B1 74[/code]EID1 and EID5 still uncovered
    EID0 sections 2,3,4,5,6,8,9,10 (marked as 1,2,...11) still uncovered. BD Drive Firmware (any kind) can't be decrypted yet through the computer. SYSCON Firmware (any kind) can't be decrypted yet through the computer.

    Private Keys can't be obtained (unless somehow someone had a quantum computer with >1000 qubits processing power and Shor's Algorithm at hand...) AES can't be compromised (maybe in a near future)

    Per-console key 0 can't be obtained so far. What you see here is what remains. If anything happens that makes any of these things possible or understandable or achievable to be done, i'll delete the respective part of them.

    Debunking the idps

    Here's my debunking of the idps or console id as you know.

    Combinations: pastie.org/private/61rdfam68ipwtmvrmgnixg#10

    [Register or Login to view code]

    9th byte list (from wiki): pastie.org/private/lqwgs1qzh1jd14kmbea8a

    [Register or Login to view code]

    10th byte list (from wiki): pastie.org/private/ftr9f5yw164jhndy3ieoa

    [Register or Login to view code]

    Notes: if you notice, cechgs appear in almost all possibilities of the 9th byte list, except in the static idps 9th byte.

    Banned idps list from "Free IDPS" thread: pastie.org/private/mk0ipzwuo9woejakc45sa

    [Register or Login to view code]

    Buffer Overflow on Save Games

    This comes back from the psp era. usually, you'd insert a disc, load a certain save and it'd load a data that'd have a very long string. at the end or the middle of that string you'd see a binary loader (hbl.bin) that would load the main menu of HBL. In the case of the ps3, before the crypto fail was publically announced, little to nothing was possible in regards to load a binary of a savegame. now, thanks to that and thanks to flatz 's amazing tools, it might be a possibility in the near future

    Since there isn't a tool that handles savegame crashes (yet), so far we can only manage ourselves with a DEX/Convert and eth debug to know what happens at the time of the crash/freeze.. in my case, i don't have access to such tools, but there are people who do

    So, you can try this for yourselves.. this was made in fifa 09. i turned auto-save off (so it didn't overwrite the crafted save i made), made a savegame profile, and loaded the disc. The result was that it crashed while loading the save.

    The only thing i changed was SYS-DATA. i opened it in HxD, and filled my name (zecoxao) with o's until it matched Ronaldo's string entry. that caused the game to crash.

    Theoretically, you can most likely load a disc-bind 3.55 and below signed self from a register that returns an address and it'll just load the self (i think) although i didn't try this myself yet, because i can't debug it properly on a superslim. Anyone who wishes to give it a go is welcome to do so.

    Printing Things to the Screen

    As you all know, neither the sdk nor the psl1ght environment allow you to print things natively to the screen , at least not without using rsx. fortunately, inside the cobra sources of their usb, there is something that enables that, making debug output MUCH easier.

    The specified functions are debug_install and debug_printf. debug_install patches the necessary offsets and redirects tty output to the screen, and then debug_printf simply prints the thing you want. this might not sound much but it's a VERY useful feature, specially when you want to debug code and you like to visually see what is happening. also, this could turn things such as memory patching and dumping much easier to look at.

    I'd like to compile it myself and test for results but i don't have a working hackable console. so i'd like to ask any of you devs to test it and check if it works or not. as i was told it does seem to work, so i hope that this gets adapted to PSL1GHT very soon.

    U$er , i'd like you to be the first person to test this, since you have understood the plugin loading and adapted it for ourselves.

    Buffer Overflow on Save Games

    This comes back from the psp era. usually, you'd insert a disc, load a certain save and it'd load a data that'd have a very long string. at the end or the middle of that string you'd see a binary loader (hbl.bin) that would load the main menu of HBL.

    In the case of the ps3, before the crypto fail was publically announced, little to nothing was possible in regards to load a binary of a savegame. now, thanks to that and thanks to flatz 's amazing tools, it might be a possibility in the near future.

    Since there isn't a tool that handles savegame crashes (yet), so far we can only manage ourselves with a DEX/Convert and eth debug to know what happens at the time of the crash/freeze.

    In my case, i don't have access to such tools, but there are people who do

    So, you can try this for yourselves.. this was made in fifa 09. i turned auto-save off (so it didn't overwrite the crafted save i made), made a savegame profile, and loaded the disc.

    The result was that it crashed while loading the save.. the only thing i changed was SYS-DATA. i opened it in HxD, and filled my name (zecoxao) with o's until it matched Ronaldo's string entry. that caused the game to crash.

    Theoretically, you can most likely load a disc-bind 3.55 and below signed self from a register that returns an address and it'll just load the self (i think) although i didn't try this myself yet, because i can't debug it properly on a superslim.. anyone who wishes to give it a go is welcome to do so.

    From pastie.org/private/p1mxjrd6xbmv3hrphazxsw (the freeze):

    [Register or Login to view code]

    LR is what matters to us. it's called Link Register and returns the address of what we want to load.

    IT'S A TARP! Thanks flatz for the debugging)

    FIFA 08 (props to NiceShot for the logs) (via pastie.org/private/9iqksaxgxpo8kdqxc87g):

    [Register or Login to view code]

    Register control in GPR0 (0x31) (via pastie.org/private/hqi53jdrhltfvdaezn3png):

    [Register or Login to view code]

    Controlling r0 is pretty much the same as controlling the link register. if we control r1 we can control the rop.

    Here are the core dumps for fifa 08 and 09. r0 is controllable in both games (it's probably hitting the stack)

    Download: fifacoredumps.tar.7z

    It'll take some minutes to upload them, so please wait.

    Lv2diag.self bricking consoles?

    I told myself i wasn't going to post any more about ps3s but this is really bugging me so... i was hanging out in skype when suddenly vapour barges in and says a self he created with Objective Suites bricked his ps3.

    Naturally, for a person who bricked 7 consoles by flashing ways, i thought he was kidding, since nowhere in the world Sony would do such a thing. then i asked hellsing9 to test it somewhere. he tested the self. it bricked. he tested again, bricked again. then i asked greysmoke. he tested the self. it didn't brick.

    My question is this: in which consoles can the brick be caused, what causes the brick to be triggered, and most importantly, can we intercept the process of the command of bricking and replace it with something else?

    This is the self (3.42 appldr signed): https://dl.dropboxusercontent.com/u/...0/Lv2diag.self

    Needless to say flashers can and MUST be used before doing anything. They can unbrick. E3 flasher can be used as any regular flasher. as for the pinouts, i believe they are available on the wiki (NiceShot has the picture).

    From NiceShot: Uhm... you should have the original dump before trying this, I'm not sure if dumping it, byte swapping and flashing it back will solve the problem but it is worth trying, I had a broken e3 flasher clip so I had to map the whole points to use e3 linker but if you have an e3 flasher with e3 clip you can do the job the same way, but there you have the pinout for MSX-001:



    PS3 IDA Stuff

    So, i was bored and i decided to open ida pro and take a look at things. then, someone told me that i could open idb files in ida. so i went to graf's bible and opened a few. fun. anyways, here are some scripts/updates of scripts.

    HV Dump script has "new" function names instead of the usual "undocumented_function" crap and export script prints all the function names to the screen (the ones that don't start with sub_) consider this a release of sorts. i'll try to take care of syscall_names.idh tomorrow for the lv2 dump script.

    Download: stuff_for_ida.zip
    GIT: github.com/zecoxao/ps3ida

    Github contains precompiled loaders, plugins, signatures, and the new scripts. i've updated the zip. you should have now two aditional export functions. one for the syscalls, and another for the hvcalls. gonna see if i can take care of syscall_names, idh today.

    Edit: taken care of: github.com/zecoxao/ps3ida/blob/master/syscall_names.idh

    Kinda piggish but it does the trick

    Added some more signatures. had to use a trick. They're on github: github.com/zecoxao/ps3ida/tree/master/sig/ppc

    eEID5 Keyseed and Section Keys Found

    [Register or Login to view code]

    Edit: some corrections: psdevwiki.com/ps3/Keys#KIRK (thanks euss)



    location: in lv2_kernel.self

    More KIRK keys
    AES requires a 16 byte multiple message.. i have no idea of what unk_keyseed is.

    [Register or Login to view code]

    Interesting info on KIRK 0xC, 0xD, 0x10, and 0x11 functions by Proxima

    [Register or Login to view code]

    Download: ps3_decrypt_tools-master.zip

    To quote(from pastie.org/private/hzqhpgaxgdybq3zjudqpva):

    [Register or Login to view code]

    Finally, from LiquidManZero (via psx-scene.com/forums/f153/new-63886/index28.html#post992654):

    Welp. I'm just going to leave these here... Also Rand, I know you're watching.

    [Register or Login to view code]

    From zecoxao: Euss right next to this (psdevwiki.com/ps3/Seeds#sc_iso_key_seeds) there's a chunk of data, size 0x290, which is loaded twice in two separate functions. i'm guessing that this is some sort of eid1 in disguise? this is on the jig firmware btw.

    There is also a third value which i don't recognize (next to be2sc and sc2be keys):

    [Register or Login to view code]

    Dump_Sbmmio.pkg (linked above)

    Dumps sbmmio to any usb port. i need to know what lies at offset 0xC000 in different consoles. so, bring me your dumps (they don't come with personal information AFAIK) or you can just tell me the first 0x14 bytes of offset 0xC000.

    You need:
    • usb stick in ps3
    • lv1 peek and poke by graf

    That's the southbridge dump. i was using it to know what the hell was wrong with syscon by flatz. Turns out it wasn't the device/distro/linux kernel/firmware version it was the code, and he fixed it.

    Now a friend of mine is trying to overflow packets sent to the syscon in order to obtain the syscon content keys.. btw, here is the fixed code:

    Download: https://dl.dropboxusercontent.com/u/.../zip/syscon.7z

    These last days I've been trying to make the syscon command work on linux, only to find out it didn't work as it should. Here are the proper sources (linked above).

    More PlayStation 3 News...

  7. #37
    JAYRIDER666 Guest

    VTRM crypto and Blu-ray playback

    I have a working idps but i have no program to put this to my ps3 cfw rogero 4.46 do anyone can help?

    Also below is some VTRM crypto and Blu-ray playback from zecoxao, as follows:

    This is already known info but i figured i'd make it into a nice post so let's start.

    There are two VTRM blocks at the flash. Each block corresponds to each ros. Essentially one VTRM is a backup of the other.

    Inside the VTRM block there are encrypted blocks. there might be 4,5,6,etc blocks. The reason why the number of blocks changes we don't know. The blocks have a size of 0x40 bytes.

    There are two ways to decrypt the blocks: using aes-xts and sherwood_ss_seed and ss_seed_one more OR (recommended) using aes cbc and keyseed_for_srk2.

    Method is the following:

    First, encrypt root key with sc_iso metadata seeds. key is at 0x20, size 0x10, iv is at 0x10. then, encrypt (pick one) either sherwood_ss_seed(for data) and ss_seed_one_more (for tweak) or keyseed_for_srk2 (this is a string used as a seed) with aes cbc-128 for block key (iv is 0).

    After obtaining the data and tweak keys (or the block key) use the keys and decrypt each block.

    Most of the blocks contain nothing inside, except for the very first one.

    First block contains a hash of DRL (0x14 bytes) followed by a hash of CRL(0x14 bytes) in sha1 format. If you just remarried your console, you can fix bluray playback by replacing the hashes there with the ones you currently have.

    There's another set of hashes in plain sight, and they're probably all sha1. First hash is repeated in a set of patterns. second hash is cleverly hidden among the patterns, and third hash is at the VTRM header. Corruption of these hashes is very likely to cause RSOD. There has been a debate wether replacing a corrupted hash with another equal hash would be advisable ( it fixes the RSOD error, but we don't know the direct consequences of this)

    Oh, forgot the link to glevand's mastery: psdevwiki.com/ps3/Fixing_DRL_and_CRL_Hashes

    I i just had a word with flatz.. two of the 3 hashes can be calculated already:

    [Register or Login to view code]

    Empty sector:

    [Register or Login to view code]

    User i asked you about the method to dump srk and srh, but unfortunately, even with your help, i wasn't able to dump the data. running the code with your pokes hangs at a black screen. if you're interested in sharing that package to dump srk and srh that would be very cool of you

    From u$er: the prx has been tested on 446 dex in debug mode. it should work on cex as well, but you won't see any result... just connect to port 4546 and type "dumpsrk".

    Download: test.sprx (load with prx loader) / pastie.org/private/kfbm2w1dzjddczxvdonba (src)

    [Register or Login to view code]

    It should look like this:

    [Register or Login to view code]

    From zecoxao: Thanks u$er. i got the encrypted srk, srh, and something else

    Alright, here's the structure of the decrypted data (i'm going to upload the algorithm to generate the backup key and iv to decrypt the data using aes-cbc to my decrypt_tools)

    First 0x10 bytes of data are unknown. we don't know what they are basically then comes srh, then srk and finally a padding of 8 zeroes. I've verified this myself

    Now what's left to analyze are those 0x10 bytes. flatz wondered if they could be any master key, but i highly doubt it. either way, it's worth checking it out.

    Edit: srh is the hash of the signature table (the giant table with the repeated hashes and the hidden one) hashed with srk key

    Edit2: header hash is just a hmac sha1 of hmac sha1 of vtrm section without header (0x28 bytes) and signature table (again, with srk key, hashed twice)

    More info from flatz: syscon data (total size: 0x400 bytes) includes:

    management block:
    0x00 - syscon state/status (0x10 bytes with padding)

    root info block:
    0x10 - key (0x10 bytes)
    0x20-0x34 - srh (0x14 bytes)
    0x34-0x48 - srk (0x14 bytes)
    0x48-0x50 - padding

    0x50-0x80: encrypted stuff (???)

    updater block/region data block:
    0x80-0x380 - system version, coreos hashes (?), etc
    each block have a size of 0x30 bytes (?)

    From zecoxao:

    [Register or Login to view code]

    This is the block key.

    [Register or Login to view code]

    Those are hashes of SC Encrypt Keys using CMAC/OMAC1 mode[/code]They probably use this key:

    [Register or Login to view code]

    To generate the hash.

    eeprom: https://dl.dropboxusercontent.com/u/35197530/eeprom.bin

    The INDEXAREAISHERE parts are written like that because they might (or not) have to do with perconsole info, so they were left like that.

  8. #38
    dyceast Guest

    Dump Sysrom and the masked bootldr on NANDs

    PSNope 1.05 is all you need.

    Also from zecoxao: Dump Sysrom and the masked bootldr on NANDs

    as you can see here (psdevwiki.com/ps3/Talk:Sysrom.bin), dump sysrom was originally released by glevand in an attempt to dump the bootldr in his MFW OTHEROS++. he could do it with graf's payload, so he originally thought of porting it over to psl1ght and trying it on OTHEROS++. the thing is, there is some patch that breaks this, and he failed to find out the cause. as an alternative, memdump was released, and so an alternative method was developed for it (maybe it's the same method, but i don't know for sure).

    so, what is the purpose of dump sysrom?

    well, like i said before, it dumps the bootldr (the system rom) located at address 0x2401FC0000 on NANDs (in the reset vector and mapped in MMIO) and in some other address on NOR, which doesn't matter because we can fully dump NOR, bootldr included, anyways.

    i decided to test it one last time, to see if it'd work differently from the expected FF FF FF FF 80 01 00 03 (not implemented) error, but this time, by launching the self on rebug 4.46. it turns out, it dumped the bootldr in its encrypted form on my NAND. great!

    to anyone else decided to do something constructive with this information, i've asked sguerrini97 to set up a github repository of what we successfully ported to psl1ght v2 (which wasn't much)

    it's called psl1ghtv2_ports, and contains some of the code used by glevand in the early days of the scene.


    to anyone concerned, anyone who wants to include this piece of coding, take into consideration that you need lv1 peek poke in order to achieve this. also, dumping random MMIO offsets is very fun to do and you might encounter something cool

    Finally, from mind: I just compiled dump_sysrom.self and run it on my CECHA01 (NAND) console - works great. I'm using 455 cfw and multiman v.4.55.00 to run the self.

    Download: dump_sysrom.self

    I just made a standalone pkg and it works great on 4.55 cfw, without multiman. Thanks.

    Download: Dump_SYSROM.pkg

    I just tested preloader advance too. I dumped my nand (Backuprflash.bin). 256MB

    I expected two bootldrs on it, but... there are No bootldrs on that "backup".

  9. #39
    JAYRIDER666 Guest

    Obtaining Packet IDs from Game_OS Syscall Interfaces The Easy Way (RE)

    i tried but ps nope 1.05 don't work on my rogero 4.46

    Also from zecoxao: Obtaining Packet IDs from Game_OS Syscall Interfaces The Easy Way (RE)

    What is required:
    • IDA
    • PS3 Elf Loader
    • Kakaroto's analyze_self64.idc
    • Notepad++
    • lv1.self.elf processes (see SELFs inside ELFs on devwiki)
    • HxD


    Obtain the processes through table at 0x1D0000 (regular elf) or 0x1F0000 (factory elf)
    Extract processes.

    Load each through IDA with PS3 Elf Loader. Never undefine database and use kakaroto's idc to correctly define the offsets. In the end define the RTOC value in IDA's preferences.

    Export each database to an assembly file.

    Open the assembly file in IDA (any of them) search for this:

    [Register or Login to view code]

    The sub HAS to contain only that instruction AND a blr.

    Save the offsets in each sub for each asm file. Now, go to ida and load any process elf. Go to the specified offset (pick any). Go to the function, highlight it in IDA-View... ctrl-X (xrefs) it'll show up a list of possible xrefs (most of them are Packet IDs)


    Hykem, for the work being currently done
    deroad, for the help at the weekends
    and of course, graf chokolo

    Here's a list of offsets of the get_* functions from factory JIG lv1

    Download: factory243.zip

    I'll start using this thread to post my findings, even if they are off-topic.. for starters:

    [Register or Login to view code]

    there are a lot of these under special areas of the ps3. here are a few examples.

    [Register or Login to view code]

    perconsole nonce is also an interesting bit to watch. it's in metldr,bootldr,eid0,eid3 and eid5. perconsole revision key however, is only on 4 of these and not in eid3.

    [Need Testers] Get logs from initialization with Juan Nadie's bootldr exploit

    So yesterday i had a very interesting conversation with a friend of mine from irc. He had a theory about the initialization of the ps3. He also had logs, obtained from a modification of Juan Nadie's bootldr exploit. Unfortunately, he had to format the hdd, so the logs were lost. And this happened a long time ago.

    right now we're trying to reproduce the same thing. so far:

    I've uncommented line 912 ( //createLog(0); )
    I've added these lines

    [Register or Login to view code]

    in function getPointer

    Download: rr7_355.zip

    this is the code so far. peekpoke is already precompiled, but btldr8 needs recompiling. red ribbon rc7 was the version used. this only works on NOR consoles though (my biggest difficulty, since i have a NAND) so, i'll need some testers for this.

    also, notice that this may not be complete. my friend says that he's still trying to remember what he did to enable logging so we don't know if it might work or not.. and i just need to check the logs.

    logging of the instalation of pups. not of dumping bootldr.

    logs galore: http://pastebin.com/LLWSbAQT


    [Register or Login to view code]

    MANY MANY thanks to my friend without whom this wouldn't have been possible.

    it can help us understand how the chain of trust works at its very early stages. this is useful for documenting purposes, and possibly to find other hidden secrets. here's how it looks like it's working.

    first stage:

    [Register or Login to view code]

    second stage:

    [Register or Login to view code]

    next stages:

    [Register or Login to view code]

    It might be possible that bootldr and metldr headers are seeds.

    [0x10-0x20] -> seed for iv
    [0x20->0x40] -> seed for key

    My friend thinks the most plausible possibility is this: psdevwiki.com/ps3/Flash:Individual_System_Data_-_cISD some of this data (CID for example) is used to generate two sets of keys.

    The ldrkey (used to decrypt metldr and lv0ldr) located at cell. this key encrypts metldr header as a seed and generates another key, used for decrypting metldr blocks and it does the same with bootldr.
    the eidkey (copied to LS at the beginning of chain of trust) also located at cell. this is known as the eid_root_key and is used to decrypt the HDD, authenticate for SYSCON, decrypt the eEID, and of course generate Backup and VTRM seeds for the hashes in cVTRM.

    My friend was able to hang Runtime Secure Boot stating:

    The good thing: while hang spu is running in isolation load mode. i'm trying to determine what causes this hang and i have some thoughts about time when decryption and verification happens.. if i'm right then i'm able to modify encrypted btldr after verification but before decryption. also i know that encrypted loader contains only this loader and no other data after it.

    So, i got a little early christmas gift and i checked inside it and saw a really old lv1 from version 0.83. since this thread is about the embedded selfs, i figured i might post what i found inside it. And it turns out, Sony stored every manager inside lv1 instead of only a couple of them with the functions bulked up. here they are:

    Download: embedded_files_083.zip

    [Register or Login to view code]

    Dumping EEPROM from lv2 (graf's payload used)

    Download: dump_eeprom.self

    This is a program that simply dumps some of the eeprom offsets using only the lv2 update manager interface syscall and a few patches applied.

    It currently works only on 4.46 mfw, and it's for debugging purposes, although this doesn't help much because lv1 has higher access than lv2 (sorry for the mess flatz , i hope you can forgive me).

    What can be dumped:

    [0x2F00] <- no signs of minimal downgrade version here
    [0x48C00] <- some things like the spu number, other things, not so much
    [0x3000]<- everything could be dumped, but it's all 0xFF

    What can't be dumped:


    It was developed by sguerrini and myself. Alex gave us a hand with the code, Also. however, i can't release the source of it because it only worked when compiled with the oficial sdk. i have no idea why this happened.

    The fail char is 0xBE. you'll see it in the fail offsets. The dumps and the log go to /dev_usb000, so just plug a usb device in the rightmost port near the bd drive. Sure. i'll just leave the code here, since they're both illegal lol.
    • pastie.org/private/switlfzehknqgosckb6zka
    • pastie.org/private/szj5r5darigrj9loidfrcq

    Small update. We were only trying to dump 5 offset areas, there are 6 of them. The link is the same, but the self has been updated.. the 6th area still doesn't return anything though.

    It can work with any firmware, as long as the correct offsets are there. Smhabib, maybe you can help me out verifying why this freezes on 3.55 rebug?

    Download: read_eprom.zip

    I tried porting the payload to a working psl1ght app, but i failed at making it run properly. I have no idea of what could be wrong.. it freezes when running the app in a black screen. Didn't work, even with all the patches enabled. i'll port the offsets to 4.46 and check there, since it's a better version to test for me.

    Edit: Smhabib we found out why it wasn't working. Apparently the lv1 hvcalls aren't executed, and we don't know why. Perhaps it's something that only otheros ++ has and rebug doesn't have. We just don't know what... in the meantime, me and sguerrini (via github.com/sguerrini97/psl1ghtv2_ports) have ported a couple more things from glevand to psl1ght v2 (recover_mode_toggle, reboot, get_token_seed):

    Download: psl1ghtv2_ports-master.zip

    Customer ID and Perconsole Crypto by zecoxao

    This is what i know so far, either from chatting with other people or by doing assumptions (a lot of this info is an assumption, quite a big one, but most of the info people have gathered over the years seems to be correct)

    In the Cell BE CPU chip, there are 48 efuses. each of the efuses holds a bit. there are, therefore, 6 bytes of information stored in those efuses. these 6 bytes may or may not contain what Sony calls it the Serial Number or Customer ID. the Customer ID is a unique 6 byte ID that defines every single bit of perconsole information stored in the ps3 console.

    It is believed that this Customer ID is tied to metldr/bootldr/eid/perconsole keys/etc. Sony most likely uses a custom algo to forge every bit of information from the Customer ID, together with some statics and variables they have created and which they use, such as the revision key and the perconsole nonce, the statics and variables inside the cISD1, amongst other things.

    There would only exist two ways of obtaining the algo Sony uses. one of them would be by decapping the chip and analyzing it and finding the necessary information. That would cost thousands of dollars, so it wouldn't be a viable way. Another way would be to access sony servers and test until the algo is figured out (change bits in the statics and the variables, to see what would change, and fetch the algo that way).

    Unfortunately, due to the leak of Objective Suites, Sony changed authentication procedures and unfortunately it's not possible to access that info anymore (unless someone else has a newer version of the tool and is able to do those tests).

    This is completely annoying because, since we can't figure out the algo, we can't do anything on unhackables. If we had that information we could sign our own bootldrs and metldrs, and forge our own keys. that doesn't seem to be the case.

    This is just for clarification. Most of what i've said here are assumptions, because we can't know without the algorithm. Please take them as such. And here (psdevwiki.com/ps3/Flash:Individual_System_Data_-_cISD#example_4) is the wiki page that displays the location of the Customer ID.

    Update: Corrected bytes information. Customer ID is actually 6 bytes. i'm an idiot. thanks tiefputin2 for the information

    Adding more information, here's an example of a similar ID but on psp:

    Check fuse id. 6 bytes. however. check this: code.google.com/p/kirk-engine/source/browse/trunk/libkirk/kirk_engine.c#366

    And this: code.google.com/p/kirk-engine/source/browse/trunk/libkirk/kirk_engine.c#434

    8 bytes are used. so fuse id is 6 bytes of info padded with zeroes. it also has the name fuse in it which suggests it could be inside efuses. but who knows... both the psp fuse id and ps3 customer id can be read in mmio. depends if you have the right permissions to do so.

    Private Key Bruteforcer by zecoxao (via pastie.org/private/u0gxobslhxvez7tjemitvg)

    Download: p2p.7z

    [Register or Login to view code]

    You can modify the range at will.. selected curve type and x,y points are for the latest npdrm private key (4.65) good luck (maybe you'll have it)

    Credits: Flatz, for helping me out in like 5 minutes.. AlexAltea, for a quick hand as well. Enjoy!

    Well, from what i can tell, you just need to port offsets. this goes valid to two things:
    • symbols.h from the payload folder
    • main.c from the source folder (most specifically the make_patches function)

    This is what i've been doing for the past minutes:


    Together with Abkarino. The only issue is that metldr fails to load the self. figure that out and you have a working dumper. he just resigned the self?


    In case someone wants to test. happy bricking ^w^. load it with iris on the file manager in 4.65

    socat: https://dl.dropboxusercontent.com/u/...0/zip/socat.7z

    i'm using a custom scetool with mingw. just discard -p ~/data if you use the windows scetool

    Btw, there's something missing. it's the spu self source.

    Here it is: https://mega.co.nz/#!Q18UlC6b!5N5mZv...gWUxstSan8bxBA

    Thanks. you need 4.65 for this. i'll upload it.


    Load it with Iris Manager or any other app that can load selfs

    Hold on, let me check if i did something wrong. in the meantime, use the socat zip to get debug output from the payload, and check if you see anything on screen (you need the same connection in ps3 and pc)

    Let's try again: https://dl.dropboxusercontent.com/u/.../zip/EBOOT.BIN , try that one. btw, see if there's some file called eid_root_key on /dev_hdd0/tmp

    In case you still wish to test (and use habib's mfw this time):


    ok, my mistake. it should be on USRDIR of the dumper, NOT tmp.

    I'll give up on the project for now. here are the sources with new build scripts


    Here's another attempt: https://dl.dropboxusercontent.com/u/...PER0000000.pkg

    This time flatz compiled it himself so i'm assume that one should work. I'm going to need some dumps from 4.46 from lv1 and lv2. don't worry that i won't share.

    I double checked. looks like we have to see with socat.


    Tun the command in listen.sh to see where it fails. put the log here. pc and ps3 must share the same Internet connection. In case you don't know the command:

    [Register or Login to view code]

    Nevermind, logs don't work. ok, i think we should do it like this. FIRST we test 4.50, THEN we test the firmwares closest to 4.50 (4.53/4.46) and after that, and only THEN, we go to 4.65.

    This one is for 4.50. i know it's redundant but we have to start slow first:


    ok, next we try with rebug 4.46. I'm uploading the pkg. good luck:


    Hold on, let me check if i signed it properly.

    Try now: https://dl.dropboxusercontent.com/u/...30/PKG/446.pkg

    I've updated it again. now it works on 4.46

    Here it is: https://dl.dropboxusercontent.com/u/...30/pkg/446.pkg
    Source: https://dl.dropboxusercontent.com/u/...ootkey_446.zip

    U'll now take care of 4.53

    I couldn't do this without the help of haxxen, playerkp420, harryoke and flatz. Props to them for the help and testing.

    4.53, confirmed working: https://dl.dropboxusercontent.com/u/...30/pkg/453.pkg

    Source: https://dl.dropboxusercontent.com/u/...ootkey_453.zip

    PKG and source for 4.21:


    If you guys want to help me with 4.65, just port symbols.h and i'll take care of the rest

    Just a warning. in case you haven't noticed, i left a readme in each of the source links i distributed. That readme explains how to port to the different firmwares. once you follow it it'll work for other firmwares such as 4.65 or even a dex firmware like 4.46 DEX.

    Just ported to 4.65:


    I'm done porting. you can get through this yourselves Also, cobra might interfere. don't use it

    Could you pack them all together, with sources, as soon you finished porting?

    Yes, i can sinsizer. i'm done porting.


    Finally, from haxxxen: The built pkg for 4.21 does not work, that i can confirm. thus i have made new ones for cex and dex kernel.

    Download: rootkey_421.zip

    To dump to /dev_usb000/ : pastie.org/private/n8hxkaikdpiihljfluenw

    PKG: https://dl.dropboxusercontent.com/u/...kg/446_usb.pkg

    Dump_EEID and Flash_EEID (NOR and NAND) by zecoxao and sguerrini97

    Dump_eeid dumps eeid to a file called eeid.bin (if there's a usb stick in the ps3 it'll copy from the hdd to there, if not it'll stay in the hdd). Flash_eeid flashes a file called eeid.bin (the eEID) to your flash. The code is universal, meaning it works in any mfw with enough permissions.






    It says BUILD_4.46 but the packages are universal.. be free to test on any mfw and see for yourself. NOR and NAND supported.


    I forgot to mention that without sguerrini's help i wouldn't have gotten very far. kudos to him

    Props to glevand for the original sources. Kudos to the authors of PSL1GHT for making such a great working environment. Props also to 3141card for finding the right offsets and sizes of eeid (3 simple rule )

  10. #40
    zant Guest
    Can somebody make a working NAND version, please? I have been waiting to use something like this for a while now since Joris' didn't work.

Page 4 of 7 First ... 345 ... Last

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