​

Earlier today, Yifan Lu, a well-known member of the Vita hacking scene famous for the Rejuvenate hack for the Dev Assistants, has announced that a new (native!) Vita homebrew enabler for the latest firmware version, as of writing (3.60), will be arriving tomorrow at "9:00AM UTC".

The new hack, known as "HENKaku", will require the following:

• A Vita/PSTV running 3.60
• A memcard with at least 10MB of free space (internal memory is currently not supported!)
• An FTP client
• An internet connection**

**Offline support is now available! Launch the exploit straight from the email app without the need for internet access at all! See the unofficial release thread for more details. (Internet connection still required for installation)


This is a small paragraph of Yifan Lu himself explaining what the properties of this new homebrew enabler does:

HENkaku simply lets you install homebrew as bubbles in LiveArea. It is a native hack that disables the filesystem sandbox. It installs molecularShell, a fork of VitaShell that lets you access the memory card over FTP and install homebrew packages (which we create as VPK files). With vita-toolchain, developers have access to the same system features licensed developers have access to as well as undocumented features that licensed developers cannot use (including overclocking the processors).

The hack has been released at http://henkaku.me ~ Furthermore, the hack is said to be exclusive to 3.60, and there is to be no backports for the time being.

Source: http://yifan.lu/2016/07/28/henkaku-vita-homebrew-for-everyone/

 

[perkel]

No, he's wrong. You don't have to hijack arm9 before system boot.

But you can't switch to emunand while in original system. You need to restart system which means hack must be very early in booting process so kernel access alone won't give you emunand as i understand it.

Imo getting into kernel is only half the job here. Now people will need to study kernel and try to find hole where they can run hack early.

 

[Swiftloke]

But you can't switch to emunand while in original system. You need to restart system which means hack must be very early in booting process so kernel access alone won't give you emunand as i understand it.

Imo getting into kernel is only half the job here. Now people will need to study kernel and try to find hole where they can run hack early.

Sigh.... NO
You DON'T have to hijack the system before the system runs. Though you're probably right about doing a reboot (I don't know how emuNAND works) you could do a soft reboot with your code running instead of the regular code. Once your code is running, it will stay running unless your deliberately hand over control back to the system or you turn off the console.

 

[DrDaxxy]

Sigh.... NO
You DON'T have to hijack the system before the system runs. Though you're probably right about doing a reboot (I don't know how emuNAND works) you could do a soft reboot with your code running instead of the regular code. Once your code is running, it will stay running unless your deliberately hand over control back to the system or you turn off the console.

...right, yeah, the 3DS lets you soft-reboot, so hijacking arm9 at any time is sort of "during the boot process"

Whether something like that is possible on the Vita remains to be seen.

 

[DPyro]

So:
- Do all of the above except change to this : build.sh http://10.37.86.113:80/vita/stage2.php http://10.37.86.113:80/vita/pkg
- Run: http://10.37.86.113:80/vita/exploit.html

Is that correct?
Nothing changed. I get the same result..

A user on wololo comments reported having success only with GO, and that the PHP didn't work with IIS for him on windows 8

Thanks for the help

PHP works fine http://vita.dpyro.tk/

 

[cearp]

cool, i just read on wololo that henkaku really does use a kernel exploit
so, vita piracy should be possible, with devs and work!

 

[laharl22]

cool, i just read on wololo that henkaku really does use a kernel exploit
so, vita piracy should be possible, with devs and work!

At this times its useless for user?

 

[cearp]

At this times its useless for user?

henkaku useless for users? no, we can make use of it now, people have been playing homebrew, that persona ndub etc...
but there is no deep dark piracy hacks for vita yet, but since we have kernel access we should be able to get signature patches etc, it's just a matter of time.

before henkaku was decrypted further, we weren't sure if henkaku contained a kernel exploit or not. but now we know

 

[laharl22]

henkaku useless for users? no, we can make use of it now, people have been playing homebrew, that persona ndub etc...
but there is no deep dark piracy hacks for vita yet, but since we have kernel access we should be able to get signature patches etc, it's just a matter of time.
before henkaku was decrypted further, we weren't sure if henkaku contained a kernel exploit or not. but now we know

i talking of the kernel exploit lol not henkaku

 

[Deleted User]

i talking of the kernel exploit lol not henkaku

What he's trying to say is that HENkaku IS essentially a kernel exploit. (It contains one, anyway...)

 

[Madridi]

PHP works fine http://vita.dpyro.tk/

Can you explain how you got it to work?

 

[chocoboss]

Henkaku is kernel exploit, but you will have to find a way to rerevers kernel functions order to bypass encryption and licence checking this will not be easy at all ... And since henkaku's dev are against piracy it will be hard to get someone with enought knowledgement to do it ...

For 3ds it don't required boot access soft reboot is enought so only kernel access is needed. For those that dunno what it was, just look to what was devhook, get this to pour vita would be really nice

 

[yifan_lu]

@yifan_lu

Just a follow up on the above. The setup you explained works fine with stage2.go .. php still doesnt work for whatever reason.
Now I'd need to figure out why PHP doesnt work..

Others have also reported the PHP one not working. It's not surprising because we did most of our tests with go. If someone fixes it, send a pull request.

Also, even if you get a kernel exploit, a bootloader exploit, and a secure kernel exploit, you still won't be able to run emunand (at least not with any lower or higher FW version). Why? Because sony isn't nintendo, they know how to do these things.

 

[Cinnamon]

I'm reading an article from Yifan some years ago and then I read this:

It’s still unknown how much control we would have if kernel mode is compromised, but me and some others think that we MAY at least be able to do something like a homebrew enabler (HEN) that patches signature checks temporarily until reboot, allowing for homebrews with no sandbox limitations (access to camera, BT, etc) and POSSIBILITY system plugins and themes. It is very unlikely at any keys will be found at this point or being able to create or run a CFW.

From http://yifan.lu/2012/12/12/playstation-vita-the-progress-and-the-plan/

That's damn accurate to what is happening now.

 

[Madridi]

@yifan_lu

One problem I found with go, is that everytime you run this command:
"go run stage2.go -payload stage2.bin -port 60"
Go generates stage2.exe file in:
"user/(username)/appdata/local/temp/go-buildxxxxxxxx/command-line-arguments/_obj/exe"
Where xxxxxxxx stands for a different unique number everytime.

And since stage2.exe is blocked by windows firewall, it asks us to unblock it everytime in the firewall, generating a new entry for it in the firewall everytime because it's in a different location! So if I run it 10 times, I'll get 10 entries!

Anyway to get around that?

 

[yifan_lu]

@yifan_lu

One problem I found with go, is that everytime you run this command:
"go run stage2.go -payload stage2.bin -port 60"
Go generates stage2.exe file in:
"user/(username)/appdata/local/temp/go-buildxxxxxxxx/command-line-arguments/_obj/exe"
Where xxxxxxxx stands for a different unique number everytime.

And since stage2.exe is blocked by windows firewall, it asks us to unblock it everytime in the firewall, generating a new entry for it in the firewall everytime because it's in a different location! So if I run it 10 times, I'll get 10 entries!

Anyway to get around that?

Yeah compile it instead of running it.

 

[Duo8]

@yifan_lu

One problem I found with go, is that everytime you run this command:
"go run stage2.go -payload stage2.bin -port 60"
Go generates stage2.exe file in:
"user/(username)/appdata/local/temp/go-buildxxxxxxxx/command-line-arguments/_obj/exe"
Where xxxxxxxx stands for a different unique number everytime.

And since stage2.exe is blocked by windows firewall, it asks us to unblock it everytime in the firewall, generating a new entry for it in the firewall everytime because it's in a different location! So if I run it 10 times, I'll get 10 entries!

Anyway to get around that?

Not using Windows seems to be the most practical.

 

[Duo8]

@yifan_lu you mentioned some time ago that there might be a security coprocessor. Was that ever confirmed?

 

[Madridi]

Yeah compile it instead of running it.

Could you maybe provide instructions on how to do so?

Not using Windows seems to be the most practical.

Yeah because people will ditch their whole OS for one program..

 

[Duo8]

Could you maybe provide instructions on how to do so?


Yeah because people will ditch their whole OS for one program..

Hah, I have a small sbc as a homeserver for things like this. More useful than people might think.

 

[Swiftloke]

Others have also reported the PHP one not working. It's not surprising because we did most of our tests with go. If someone fixes it, send a pull request.

Also, even if you get a kernel exploit, a bootloader exploit, and a secure kernel exploit, you still won't be able to run emunand (at least not with any lower or higher FW version). Why? Because sony isn't nintendo, they know how to do these things.

Oh? Do tell.