how do you update webkits?

[Linux-Lord]

I was reading some stuff in the forums, and realized the recent public kexploit is good up to 7.02, and the bad_hoist webkit is good for 6.50 (specifically?). But it also says it was patched in 7.00.

Needless to say it won't work for 7.02 as that's beyond 7.00, but what has to be done to update the webkit past 6.50?

For example to use this on 6.72, is it as simple as finding different offests, kind of like USA/EU mod menu offsets, and such?

Just curious how difficult the road ahead may be.

 

[Izofeu]

It's not that simple. The <=6.72 webkit exploit takes advantage of a different vulnerability. You need to find a new vulnerability in the webkit that lets you execute code. From there you can execute a payload (a kernel exploit) and then you can execute code with kernel-level permissions. It's a two-step process.
Sidenote - I am not a developer so take this with a grain of salt. Someone feel free to correct me if I'm wrong.

 

[pinky]

kinda, but a new exploit has to be found. there's already a good starting point since the ps4 uses freebsd. in fact, as a joke, the flow said if you want to help, then linked to a bible of sorts for freebsd. its shortcomings are well documented.

 

[Linux-Lord]

A new exploit has to be found, to use the 7.02 Kexploit on 6.72?

My question is, how to make 6.50 webkit work on 6.72?

Does it already work cause it supports 6.xx? Or is there a difference between 6.50 and 6.72 and you can't use the same webkit without a new webkit exploit, to hook the Kexploit through?

I feel like the webkit should be universal to all firmwares it supports, but understand more about kernel RW than the ways you achieve it, and am not sure. Being it supports 6.xx it doesn't exclude 6.72, so can you run it on 6.72?

Edit: if you cannot run the bad_hoist on 6.72, why and how can't you?

I reread what you said about you need to find a new exploit to execute code. bad_hoist is then a webkit that DOES NOT allow code execution? Then why would the flow link this to it, claiming kernel RW primitives? And what was the exploit.c code, if not something executed in the webkit?

Not saying fl0w is lying, just saying if he got kernel RW primitives, I would assume he had done so by using exploit.c to develop and push a payload, which could be coupled with HEN like previously.

So then you cant just push a 6.50 payload through bad_hoist?

 

[pinky]

4.55 and 5.05 use the same kernel exploit I believe. 5.05 was hacked first, but it was back peddled to 4.55. 6.72 will be ready when it's ready. I read that specterdev is working on it, but he may have gone on vacation 'til september 14th. I don't know though. be patient. it's already been about two years, so it's not like another week or two will matter much. I've heard the most used payloads have already been updated, so we're just waiting on this.

 

[Linux-Lord]

I'm definitely not asking for an ETA of sorts. Just tryna understand how the webkit functions, and I guess how it differs from a normal payload loading webkit? I no longer own a PS4 and don't care about when, I care more about the quality of work. I don't mind waiting 10 years if all the games can be preserved in a neat fashion. And emulators on top would also be nice.

I mean, look at the recent PS2 development, I haven't even touched a PS2 in over a decade and it'd be nice to get my hands on one now that the hacks and backups are nothing more than a burnt disc, similar to just storing PS4 games on your HDD with extra steps.

 

[pinky]

I've never tested an emulator, only ps4 games. I have a screenshot in the ps4 thread about theflow with me using the webkit exploit on 4.07. you're limited in what you can do, but it's kinda fun to play around with.

 

[bguerville]

Here is the general theory (only a very short summary lol).

If you have a webkit vulnerability & an exploit leveraging it on specific version & you wish to use the same vulnerability on another version, you need to port the exploit.
The exploit code may require few or many modifications, it is usually impossible to know in advance without investigating.

As to executing a kernel exploit on a system, it depends on the outcome of the webkit exploit implementation you use & the system you are on, there are usually 2 possibilities:
if you cannot get hold of executable & writable memory you need to reproduce the C code using js & ROP otherwise you can use the compiled C code as payload.

Also afaik the C code provided by theflow is a poc that triggers the kernel UAF, not a kernel payload loader so that's not the end of the story for a ps4 public release.
Once both webkit & kernel exploits are chained & the kernel UAF triggered, you still need to implement some krop to take control of execution & execute a payload & restore system execution.

 

[pinky]

@bguerville is correct. it's a poc from theflow. the specterdev has been showing daily status reports, but I don't know if the vacation rumor is true or what that means for the project. speaking of the ps4, I might have to see if atreyu knows about this. he told me his ps4 updated by itself which is why I wrote that first ps4 tutorial. I'm not sure what firmware he's on, but I know he recently platinumed his favorite game bloodborne, which he talked me into buying. I opened its package just to make a backup but have yet to play the game. don't tell atreyu.

 

[pinky]

btw, atreyu had download and install set to off, so I'd strongly suggest anyone to disconnect from the internet or block connections. I had mine set to off as well, but my system would still download the update. I think you can with 5.05, but in the past, you couldn't delete an update without reformatting the hdd.

 

[Linux-Lord]

Here is the general theory (only a very short summary lol).

If you have a webkit vulnerability & an exploit leveraging it on specific version & you wish to use the same vulnerability on another version, you need to port the exploit.
The exploit code may require few or many modifications, it is usually impossible to know in advance without investigating.

As to executing a kernel exploit on a system, it depends on the outcome of the webkit exploit implementation you use & the system you are on, there are usually 2 possibilities:
if you cannot get hold of executable & writable memory you need to reproduce the C code using js & ROP otherwise you can use the compiled C code as payload.

Also afaik the C code provided by theflow is a poc that triggers the kernel UAF, not a kernel payload loader so that's not the end of the story for a ps4 public release.
Once both webkit & kernel exploits are chained & the kernel UAF triggered, you still need to implement some krop to take control of execution & execute a payload & restore system execution.

Literally the exact answer I was looking for, thanks a million.

I was aware his exploit.c doesn't drop you into an "awaiting payload" state, but was unsure if it just needs to be integrated with existing webkits that have a "click to hack" button, rewritten completely, only used for informational purposes, etc.

So when you can't load payloads, is it basically running C code with a JIT compiler like approach? And would this act of "converting" C to JS/ROP have to be accounted for when coding in C, or would this reproducing of code be transparent to the C Dev?

Also you said if you wanna use the exploit on a higher firmware it has to be ported to higher firmware. So to clarify, if I wanted to use bad_hoist on 7.00 instead of 6.50, I would have to port the exploit.c code?

Or would I have to wait for an actual payload loader and port that exploit?

 

[bguerville]

Hacking is improvising, no one size fits all answer. Each exploit leads to making different choices based on the vulnerability, its surrounding code, available resources & architecture specifics.

But again, generally speaking, if you have a userland exploit using js jit or regex jit or whatever jit, you should have writable & executable memory.
So assuming your webkit exploit copies the binary data gotten from compiling C code from theflow to that jit executable memory area, triggers a vulnerability, takes control of userland using rop & launches execution of the exploit binary data, it should be enough to trigger the UAF then the ps4 would crash!

The next step is to add appropriate code in the C poc to take control of execution at kernel level, just like in userland but with kernel gadgets. To do that, in the poc, you will need to find a way to plant data in the kernel memory area where the UAF occurs so that the crash can be avoided & execution control taken, it will most likely require pivoting the kernel stack to a kernel planted custom krop stack.
The custom kstack will lead execution into preparing a memory area to store the payload in kernel memory, load the kernel payload from userland, then launch it & finally restore kernel execution with properly filled registers.

The vulnerability used in the exploit from theflow is found at least on 4 freebsd major revisions (9 - 12), possibly more, I received the freebsd cve mailing about it a few days ago. It is possible that he just developed the exploit on PC & ported it to ps4 with little modifications. It's one of the advantages of working on ps4 kernel, you can test many things on freebsd 9 x64 on PC, it should also be an advantage for writing a ps4 emu for pc..

 

[Linux-Lord]

Hacking is improvising, no one size fits all answer. Each exploit leads to making different choices based on the vulnerability, its surrounding code, available resources & architecture specifics.

But again, generally speaking, if you have a userland exploit using js jit or regex jit or whatever jit, you should have writable & executable memory.
So assuming your webkit exploit copies the binary data gotten from compiling C code from theflow to that jit executable memory area, triggers a vulnerability, takes control of userland using rop & launches execution of the exploit binary data, it should be enough to trigger the UAF then the ps4 would crash!

The next step is to add appropriate code in the C poc to take control of execution at kernel level, just like in userland but with kernel gadgets. To do that, in the poc, you will need to find a way to plant data in the kernel memory area where the UAF occurs so that the crash can be avoided & execution control taken, it will most likely require pivoting the kernel stack to a kernel planted custom krop stack.
The custom kstack will lead execution into preparing a memory area to store the payload in kernel memory, load the kernel payload from userland, then launch it & finally restore kernel execution with properly filled registers.

The vulnerability used in the exploit from theflow is found at least on 4 freebsd major revisions (9 - 12), possibly more, I received the freebsd cve mailing about it a few days ago. It is possible that he just developed the exploit on PC & ported it to ps4 with little modifications. It's one of the advantages of working on ps4 kernel, you can test many things on freebsd 9 x64 on PC, it should also be an advantage for writing a ps4 emu for pc..

Ok perfect, that clears it up.