Just thinking

[Xian Nox]

There is always a chance Sony will let it happen.

No, just no. Past history shows this will not happen.

"I have never died before, therefore there is zero chance of it ever happening to me" - this is how ridiculous your statement is.

And how do you know you've never died so far? I know this is too philosophical, but so is your example.

As for Sony releasing one for home devs: I wouldn't bet on it. The PS Suite SDK will I think be a lower entry level SDK for smaller devs (e.g. the sort of devs behind iOS apps, on tight budget) which may help small indie devs get involved with developing for the Vita, but I doubt it will be released for free or will really be useful for homebrew - chances are it'll still need to be approved by Sony before it gets onto devices other than a registered test device, owned by the developer.

It is closed in and needs Sony approval. Read above.

Pretty sure there is no PS Suite SDK that works with Vita at the present.

And I'm pretty sure there is one, and it is not released yet. I expect it to be the Vita analog of the PSP Mini SDK.

Advertising

[SifJar]

It is closed in and needs Sony approval. Read above.

Pretty sure there is no PS Suite SDK that works with Vita at the present.

And I'm pretty sure there is one, and it is not released yet. I expect it to be the Vita analog of the PSP Mini SDK.

Well that's pretty much what I meant. Now you're just nitpicking

Advertising

[tombraiderwes]

Wait so would we be able to play PSP games with the VHBL software?

[Xian Nox]

Wait so would we be able to play PSP games with the VHBL software?

NO! (V)HBL has never, does not, and will never allow you to play ISOs on a PSP/PSV, no matter whether you own them or not. It is just not possible to implement.
You will be able to use some PSP homebrew. That's what HBL is about.

[tombraiderwes]

Oh okay, some of the wording was confusing!
I am just sad because I still have a useless UMD of Kingdom Hearts

[pokerbob05]

I was under the impression that you had to be a licensed dev to own the SDK anyway so $ony would see this as an act of piracy, as you wouldnt be getting it by legit means. Second of all, even though the VHBL isnt directly seen as piracy, the technique used to gain access to the software side of the console could be.

All thats needed once this VHBL is released is for someone to use it to cause a memory overflow or something similar to then re-write the flash, just like the psp.

So i think $ony will be keeping a close eye on this one, thats just what i think.

[Xian Nox]

All thats needed once this VHBL is released is for someone to use it to cause a memory overflow or something similar to then re-write the flash, just like the psp.

I don't remember there being a memory overflow kernel mode exploit. They mostly relied on unchecked k1 values iirc.
To find kernel exploits, we need a better understanding of the firmware. With the PSP, it included reversing portions of the firmware to look for vulnerabilities. At current, no one has released any tools to decrypt the firmware. So, we are a long long way from a CFW, if one is even possible on the Vita. Also, no kernel mode == no flash0 access.
Sony long ago found a way to counter such flash rewrites: encrypting and signing. The 1.50 OFW was the last to not include these security measures completely iirc.
So, before you get your hopes up: no CFW, not for some time at least.

[pokerbob05]

All thats needed once this VHBL is released is for someone to use it to cause a memory overflow or something similar to then re-write the flash, just like the psp.

I don't remember there being a memory overflow kernel mode exploit. They mostly relied on unchecked k1 values iirc.
To find kernel exploits, we need a better understanding of the firmware. With the PSP, it included reversing portions of the firmware to look for vulnerabilities. At current, no one has released any tools to decrypt the firmware. So, we are a long long way from a CFW, if one is even possible on the Vita. Also, no kernel mode == no flash0 access.
Sony long ago found a way to counter such flash rewrites: encrypting and signing. The 1.50 OFW was the last to not include these security measures completely iirc.
So, before you get your hopes up: no CFW, not for some time at least.

True, but there always has to be that starting point, youve got to trip the system up to expose the holes. You're right the memory overflow "TIF" exploit wasnt for kernel access it was solely for rolling back to the 1.50 firmware. Pretty cool stuff though.

[SifJar]

All thats needed once this VHBL is released is for someone to use it to cause a memory overflow or something similar to then re-write the flash, just like the psp.

I don't remember there being a memory overflow kernel mode exploit. They mostly relied on unchecked k1 values iirc.
To find kernel exploits, we need a better understanding of the firmware. With the PSP, it included reversing portions of the firmware to look for vulnerabilities. At current, no one has released any tools to decrypt the firmware. So, we are a long long way from a CFW, if one is even possible on the Vita. Also, no kernel mode == no flash0 access.
Sony long ago found a way to counter such flash rewrites: encrypting and signing. The 1.50 OFW was the last to not include these security measures completely iirc.
So, before you get your hopes up: no CFW, not for some time at least.

1.50 had security measures, they were just easily bypassed by kxploit - extracting DATA.PSP from an EBOOT and putting it in a separate folder named the same as the first but with a % at the end or something along those lines (the exact details escape my memory). IIRC, 1.00 was the only firmware to have no security measures and allow completely unsigned code to run without problems.

[pokerbob05]

1.50 had security measures, they were just easily bypassed by kxploit - extracting DATA.PSP from an EBOOT and putting it in a separate folder named the same as the first but with a % at the end or something along those lines (the exact details escape my memory). IIRC, 1.00 was the only firmware to have no security measures and allow completely unsigned code to run without problems.

Thats right, thats when we had to have the two folders in the one directory so one folder would show up as corrupt using the Kxploit.