Sponsored Links

Sponsored Links

PS3 IDPS Changer v1.1 Homebrew Application is Now Available


Sponsored Links
75w ago - 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 with details below.

Download: [Register or Login to view links] / [Register or Login to view links] (Mirror) / [Register or Login to view links] / [Register or Login to view links] (Latest Version) / [Register or Login to view links] / [Register or Login to view links] (IDPSTool and IDPSet by Zar to change PS3 IDPS) / [Register or Login to view links] by Zarh

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?

[Register or Login to view links]

How can I dump my flash?

  • Hardware flasher (E3, Teensy, Progskeet...)
  • Multiman
  • ...




How can I byte-reverse my dump?

Flowrebuilder: [Register or Login to view links] / [Register or Login to view links] (Mirror)

4.2.3.0 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.

Nor model = CEX-FLASH.FULL.EID0.NORBIN

Nand model = CEX-FLASH.FULL.EID0.NANDBIN

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: 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:

  • 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




Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter and be sure to drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene updates and homebrew releases!

Comments 40 Comments - Go to Forum Thread »

• Please Register at PS3News.com or Login to make comments on Site News articles. Thanks!

scousetomo's Avatar
#40 - scousetomo - 49w ago
i've got a working ps3 id, is there any tool available to use without a flasher? i'm on harib 4.50 cfw now on a banned slim but the id off a fat unbanned one

zant's Avatar
#39 - zant - 50w ago
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.

JAYRIDER666's Avatar
#38 - JAYRIDER666 - 50w ago
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

Tutorial:

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)

Credits:

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: [Register or Login to view links]

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
[code]
} else if (page >= (FLASH_SEGMENT + FLASH_OFFSET + BOOTLOADER_OFFSET) && page

dyceast's Avatar
#37 - dyceast - 50w ago
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.

[Register or Login to view links]

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: [Register or Login to view links]

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

Download: [Register or Login to view links]

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".

JAYRIDER666's Avatar
#36 - JAYRIDER666 - 50w ago
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: [Register or Login to view links] (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: [Register or Login to view links]

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

Sponsored Links

Sponsored Links
Sponsored Links

Sponsored Links







Advertising - Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News