HEN means Hombrew Enabler. It basically turns off signing checks in the firmware to allow one to launch homebrew.
E] Ah, I see I'm too late![]()
My take on this is that if a HEN is to be released it should be for this exploit... Not that I'm discounting the work made by the people who worked on the GS exploit but, not everyone has the money to buy the darn game at the price it is sold right now (when I wanted to buy it, it was $80+).
Whatever way to unlock Kernel Mode that was found with the GS exploit, if DaX wanted to save it for later, I say let it. The hombrew scene right now has the break of the year.
Still we should respect whatever choice the dev's make and let them decide what they believe is best.
thank you, so if they make one I would be able to downgrade my PSP and install M33 or another? Any information about when it might be released?
I tried several times to get this to execute properly on my Rachet & Clank slim this morning before work. Didn't work once. I upgraded to official 5.03 just to try it out.
I'll try again after work today.
No one should update to 5.03 just to try a PoC. If they do and this hits a dead end (although I think there's a 100% chance homebrew will come of the exploit), they deserve it.
Don't bother with earlier firmware until someone says "Right chaps, looks like version 5.03 is a no go". Then maybe other options should be looked at.
A lot of the code in the h.bin looks compiled >_>
Of course, the assembly in the TIFF is hand-written. No real other way to do it.
It should be possible to compile a homebrew to work as the h.bin, but it's quite difficult. You need to pull out the .text segment, basically not use any of the other segments (I think it would be possible to use a .data segment, but it would require to post-process the binary a lot), and stick only that in the binary. You'd need to be very cautions of absolute jumps and probably replace them with relative branches, and absolute memory access is also asking for a disaster, but without a .data or .bss segment, these probably won't happen unless you're actually messing around with a specific portion of memory. You basically need to abide by these rules yourself when you're writing the h.bin in assembly anyway, but it's easier because you can do the branches yourself and avoid use of other segments already.
If you don't know what segments or relative branches are, you probably shouldn't try to write an h.bin![]()
Resetting settings back to default seems to increase the chances of it working. I couldn't get it to work initially either, but after doing that, it always works after around 5 tries now.
I tried several times to get this to execute properly on my Rachet & Clank slim this morning before work. Didn't work once. I upgraded to official 5.03 just to try it out.
I'll try again after work today.
The HEN hasn't been released yet.
Is anyone working on it?? How long it takes for being realesed?? :huh:
The HEN hasn't been released yet.
The HEN is not directly related to Gripshift or the Tiff exploit.
The issue is not Gripshift VS Tiff, but the fact that there is apparently a new Kernel exploit. It sort of made it to the same news as the Tiff exploit so people are confused, but it is a separate piece of news, really.
This is completely unrelated to the TIFF exploit or the Gripshift exploit. As far as I know, if a HEN is made out of this, there could be a version for both GS and the Tiff exploit actually.