Need users with Slim TA-085-v2 MoBo's to test something for me :)

[Hellcat]

Hi folks!

I am looking for a few ppl with a PSP S&L with the new TA-085-v2 mainboard.
You know, the one incapable of making Pandora batteries.

I want to add a notification/warning to my Pandora Installer to avoid confusion that I recently encountered a lot with ppl trying to patch the battery but not succeeding due to that mobo and not knowing about the issue.

If you all of sudden feel urged to try my warning screen, here's a link:
http://fserv.skill-club.com/get_525_756c.html

If you have a TA-085-v2, plz tell me if you get the warning when launching the app

[Ryu60]

Hello,

I have tested and I have got the warning when I launch the program

I have taken a photo (Click here)

[Hellcat]

Nice!

So my littel MoBo detection indeed is working like it's supposed to

Thanks for testing!
That was just the confirmation I needed.

[Ryu60]

No soucy,

Thanks for your work

[Torch]

Why dont you modify the app to call all the syscon addresses from 0 and wait till it succeeds, then we might find the new hardware address. Unless they made it something really weird, or that the new hardware is hardwired to check the battery on boot without the function ever being callable via syscon.
-= Double Post =-
I see you already tried bruteforcing.

[Hellcat]

Originally Posted by Torch

I see you already tried bruteforcing.

Yep.
Not me, tho, but it has been tried and didn't come out with any success

[Sullivan]

I have not really stayed in touch with the slims lately.
So I see they have a new motherboard, does this mean I should get one soon?
I would hate to get a Non-Hackable Slim. Although I am sure in the future it will be.

[Torch]

Yes, the next logical step would be for them to block the battery check on power on = no more service mode.

[Hellcat]

Originally Posted by Torch

Yes, the next logical step would be for them to block the battery check on power on = no more service mode.

They can't do THAT. They would only screw themselfes, service mode is there for a reason.... which is not to be hopefully not found by us *lol*

[headlesslizard]

They could make a new one, like a reset button under the battery. Like the one on the back of a calculator, heh no one would be any wiser.

[zeroxorxdiexskater]

Originally Posted by Sullivan

I have not really stayed in touch with the slims lately.
So I see they have a new motherboard, does this mean I should get one soon?
I would hate to get a Non-Hackable Slim. Although I am sure in the future it will be.

no they can still be hacked
sony just blocked access to the EEPROM making it so they cant make pandoras battery on the new slim

[Torch]

Originally Posted by Hellcat

They can't do THAT. They would only screw themselfes, service mode is there for a reason.... which is not to be hopefully not found by us *lol*

I meant once all the service centres have been updated with the new method.

[zeroxorxdiexskater]

so will this be in the next pandora installer for 3.xx??

[Hellcat]

Originally Posted by zeroxorxdiexskater

so will this be in the next pandora installer for 3.xx??

Yes.
It will spit out the warning when it detects the new MoBo to avoid ppl wondering why the battery isn't working.

Nothing big, but should keep ppl from getting too cunfuzzed

[SilverSpring]

Originally Posted by Torch

I meant once all the service centres have been updated with the new method.

Of course the smart thing to do is just fix the exploit in the preipl code. That way they dont have to change their service mode, it will prevent pandora from working while still letting their official service mode work. No need to update their batteries or even their methods (which would have been rather expensive).

The actual pandora battery will still enable service mode, but it just wont boot anything from the ms without the exploit. Only their own magic ms will run successfully.

I fully expect them to have already done this and will probably show up in stores once their current stock of psp's have been exhausted.

[Hellcat]

Originally Posted by SilverSpring

I fully expect them to have already done this and will probably show up in stores once their current stock of psp's have been exhausted.

Yah.... NOW I'm officially scared....
But the smart guy among us will find another exploit, yes?

[SilverSpring]

Originally Posted by Hellcat

Yah.... NOW I'm officially scared....
But the smart guy among us will find another exploit, yes?

Judging from history, zero of their attempts in increasing the psp's security have been successful.

[Torch]

Originally Posted by SilverSpring

Of course the smart thing to do is just fix the exploit in the preipl code. That way they dont have to change their service mode, it will prevent pandora from working while still letting their official service mode work. No need to update their batteries or even their methods (which would have been rather expensive).

That was exactly what I suggested in an earlier discussion (wasnt aware of the preipl terminology n stuff), but then FreePlay said that the the pandora code was signed as authentic using a KIRK related exploit and it was as valid as officially signed boot code. (Under the presumption that the EBOOT signatures are a totally unrelated method of signing which is why we cant sign EBOOTs)

So am I correct in understanding that the pandora code is NOT signed, but just that we are able to execute it due to an exploit?

[SilverSpring]

Originally Posted by Torch

That was exactly what I suggested in an earlier discussion (wasnt aware of the preipl terminology n stuff), but then FreePlay said that the the pandora code was signed as authentic using a KIRK related exploit and it was as valid as officially signed boot code. (Under the presumption that the EBOOT signatures are a totally unrelated method of signing which is why we cant sign EBOOTs)

So am I correct in understanding that the pandora code is NOT signed, but just that we are able to execute it due to an exploit?

The actual pandora code isnt signed, just a tiny fake block is signed (just enough to make use of the exploit in the preipl to make your unsigned code run). If it were possible to sign whole chunks of code there would be no need for pandora (EBOOT's are signed the exact same way), just sign your homebrew and run.

So if they fixed the exploit in the preipl, the pandora battery would still enter service mode, would still try to run the IPL off the ms, the fake signed block would still appear valid and will decrypt properly but then wont jump to your unsigned code. That's as far as it'll go, without the exploit no unsigned code will be run.

[Torch]

Originally Posted by SilverSpring

The actual pandora code isnt signed, just a tiny fake block is signed (just enough to make use of the exploit in the preipl to make your unsigned code run).

But is the signature actually as valid as being signed by Sony's private keys?
Since the keys are unknown, the only thing I can think of is that the chunk of fake code was so small, even smaller than the length of the private key itself, that it could be bruteforced without knowing the key, in less time.

If not that, do you know how exactly the whole exploit thing works?

[SilverSpring]

Originally Posted by Torch

But is the signature actually as valid as being signed by Sony's private keys?
Since the keys are unknown, the only thing I can think of is that the chunk of fake code was so small, even smaller than the length of the private key itself, that it could be bruteforced without knowing the key, in less time.

If not that, do you know how exactly the whole exploit thing works?

Yes the block was small enough to bruteforce (hence why you couldnt sign a whole EBOOT, would have to bruteforce the whole thing). The private key wasnt bruteforced though (not that it would matter if it were though, the algorithms are still unknown).

How the decryption works is this, the data is first encrypted and then the encrypted data is signed. When passed to the crypto engine, first it checks the signature and if it's valid it will decrypt the data (algorithms for both the encryption & signature are unknown, not that I know of anyway, maybe someone knows...or not ).

The fake encrypted data is bruteforced to decrypt into your chosen data (to be able to exploit the preipl). And the signature for your fake encrypted data is bruteforced again to make it appear valid in the eyes of the crypto engine so that it will will go ahead and decrypt your fake encrypted data.

The preipl exploit works like this:

First a decrypted ipl block:
0x00: load address
0x04: data size
0x08: entry address
0x0C: checksum of previous block
0x10: data

A typical example might be
0x040F1EA0
0x00000F50
0x00000000
0xB71C6EBA
...data...

Which means load 0xF50-byte data to 0x040F1EA0. 0xB71C6EBA is the checksum of the previous block. Then entry address is 0 since it hasnt reached the end yet and there are more blocks to load. Once it has loaded all the ipl blocks the very last block will have entry address of where the whole ipl has been loaded (typically 0x040F0000). And will then jump to that address.

Preipl pseudocode for loading & decrypting the ipl:

    int iplBlockNumber = 0;
    u32 checksum = 0;

    // load/decrypt all encrypted ipl blocks
    while(1)
    {
        // copy an encrypted ipl block to 0xBFD00000-0xBFD01000 (4KB embedded cpu ram)
        if (LoadIplBlock(iplBlockNumber, block) < 0)
            while(1);

        // decrypt the ipl block in place (uh oh...)
        if (DecryptIplBlock(block, block))
            while(1);

        // first block will have zero as its checksum since there is no previous block (another uh oh...)
        if (block->checksum != checksum)
            while(1);

        // load the 'data' section of the ipl block to the specified address (0x040Fxxxx range)
        if (block->loadaddr)
            checksum = memcpy(block->loadaddr, block->data, block->blocksize);

        // reached the end of the ipl, jump to the entry address (0x040F0000)
        if (block->entry)
        {
            // clear caches
            Dcache();
            Icache();

            // jump to ipl - do not return
            block->entry();
        }

        iplBlockNumber++;
    }

As the preipl loads the first ipl block (the fake one), it decrypts the block in-place, ie. the decrypted block just overwrites your encrypted block. The fake block only decrypts into four bytes of all 0's so it ends up only overwriting the first four bytes of your fake block (with four 0's) after decryption.

The fake signed block:

00000000: 00 00 00 00 00 00 00 00 00 01 D0 BF 00 00 00 00
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: 52 A1 05 CD 3A 52 59 28 0A D1 31 F1 BD 87 2E CC
00000030: 14 DA 02 2F 77 88 C7 66 F3 32 07 BD 1A 08 9E 4C
00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000070: 04 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000A0: 00 00 00 00 00 00 00 00 00 00 00 01 C6 5F 74 12

The most important parts to note:
0x20-0x3F is the bruteforced hash signatures
0xA0-0xAF is the bruteforced encrypted data
0x70-0x73 is the size of the decrypted data (only 4 bytes)

A slight flaw in the crypto engine allowed the bruteforce to be performed on a magnitude-times smaller scale than normally required.

After decryption, the preipl thinks the data is now a decrypted ipl block.
So note the first 0x10 bytes:
0x00000000 (load address which was faked to four 0's when decrypted)
0x00000000 (size of the block to load, none)
0xBFD00100 (the entry address, the most important part, where your unsigned code is located)
0x00000000 (checksum)

It passes the checksum test (with 0x00000000), it skips the loading of any data (since the loadaddr has been faked to 0x00000000), see's the entry address of 0xBFD00100 and thinks it has reached the end of the ipl and so goes jumps to that address (which is where your unsigned code will be).

So that's essentially it in a nutshell. But dont let a quick 5 min. summary of the exploit underestimate the enourmous effort involved in bringing it to fruition (as the final product known as Pandora).

[Torch]

Wow finally understood it properly. Nothing explains it like some sample code..

So from what I see, the bottom line is, the ultimate goal of all PSP exploits (and most other signed code situations) as of now was simply to get a Jump to address to execute in your favour, whether it was though Pandora, or the Lumines/GTA exploits.

Whereas in the case of the PS3 and the 360, every bit of code that the CPU is going to execute is checked to be authentic and remaining parts of the ram marked as non-executable and so on, so even if you manipulated an exploitable game, your code still wouldnt be able to run right? Even if an official game blatantly had an button saying "Click here to execute ms0:\cfwinstaller.elf" it wouldnt execute right? So (if implemented correctly) they are theoritically impossible to hack using software alone?

[Hellcat]

That's how I understood it as well, yes....

And aboves explanation of the PreIPL exploit.... well, can't be better, thanx!

[Torch]

SilverSpring's explanation should be made into a separate thread for those curious people to read up on.

[SilverSpring]

Originally Posted by Torch

SilverSpring's explanation should be made into a separate thread for those curious people to read up on.

Yea sorry Hellcat for hijacking your thread . Torch yea feel free to start a new thread (can continue discussion there).

[Torch]

Originally Posted by SilverSpring

Yea sorry Hellcat for hijacking your thread . Torch yea feel free to start a new thread (can continue discussion there).

http://forums.qj.net/f-psp-hacks-9/t...ng-135970.html

[Hellcat]

Originally Posted by SilverSpring

Yea sorry Hellcat for hijacking your thread . Torch yea feel free to start a new thread (can continue discussion there).

You're welcome Info like that is always welcome, and it wasn't too much off the original topic, it somehow comes alltogether

I'll now subscribe to the new thread, to not miss anything

[babyboi828]

yay a new program to throw in my face that i cant pandoraize batteries with my psp the shame :'(