hello there.

Just wanted to know why the payloads end with a memory error if we try to load them without the mira loader and doing it via mira_blob.

the exploit runs very fast all time success but whenever you exit the browser or go to settings
it K.P

dear sleirsgoevy, do you plan to do this for firmware 9.00?

Currently, the branches on this repo are setup like this:

• master: Contains a README and a git module pointing to an active branch (therefore needs maintaining). (Side note: Maybe a subtree would make more sense here).
• 75x: Contains the 75x exploit
• No branch for 6.72, 7.02 (as it's hosted in another repo)

Here is what I would do:

• Cleanup master, keep the readme (for those landing on github)
• Create a 6.72 branch, subtree from PS4jb
• Create a 7.02 branch, subtree from PS4jb, clean up 6.72 index.html to point naturally to 7.02
• Optionally cleanup 6.72 branch from 7.02 content.
• Create a gh-pages branch, which is automatically built and publish from the branches above.

Reasons:

• Static web content is more obvious
• One person willing to create new content can simply create a new branch (without the need to change master)
• Hosting multiple branches could be consistent, by publishing github pages on folders based on (pre-defined) list of branches.

Would you accept PR to clean those up?

I am happy to get the ball rolling there.

What about it ?

Comments based on appearance in blob.js:

Not sure if below variables defined twice intentionally
var sys_exit_addr = sys_1_addr;
var _umtx_op_addr = sys_454_addr;
var execve_addr = sys_59_addr;
var sigprocmask_addr = sys_340_addr;

Below variables defined with two values
var sys_340_addr | libkernel_base + 0x27833;
var sys_340_addr | libkernel_base + 0x26860;
var sys_59_addr | libkernel_base + 0x2859d;
var sys_59_addr | libkernel_base + 0x273c0;
var sys_1_addr | libkernel_base + 0x27ed0;
var sys_1_addr | libkernel_base + 0x274ea;

I have introduced (alert) function to the JB file to test specific things.
The test involved recording things manually from the screen to my note, so the JB execution was paused every time I conduct a test.
However, I have noticed that all JB executions went successfully!
I redid the test for 11 times on my Pro with pausing from 1 - 2 minutes each and found 9 of them went successfully compared by 20 – 30% success rates with the same JB release but without the pause.

I posted this info to the followers to verify if that is a placebo.
According to at least 10 reports received from followers, below pause introduced to the JB code has improved the success rate of the JB 7.5X up to 75% across all variants.

Alert function added to pause the execution of the JB, the pause shall be 2 minutes (I tested one and jumped to 2 minutes, I didn’t test in between)

Please verify this finding.

Below is your JB coding in addition to the added alert function (you may replace the alert with a timer for convenient).

var ropchain_array = new Uint32Array(498282);
var ropchain = read_ptr_at(addrof(ropchain_array)+0x10);

alert ("Please Wait 2m ... @MSZ_MGS");

var ropchain_offset = 2;
function set_gadget(val)
{
ropchain_array[ropchain_offset++] = val | 0;
ropchain_array[ropchain_offset++] = (val / 4294967296) | 0;
}

Does createElement use fastMalloc? I modified the following lines and felt like the webkit has a higher probability of working but that might be my imagination. Any thoughts on this. I'm currently using this as my default since it seems like it works better.

        /*
	 * This spray is not perfect, "element.cloneNode" will trigger a fastMalloc
	 * allocation of the node attributes and an IsoHeap allocation of the
	 * Element. The virtual page layout will look something like that:
	 * [IsoHeap] [fastMalloc] [IsoHeap] [fastMalloc] [IsoHeap] [...]
	 */
	//textarea_div_elem.appendChild(element.cloneNode());
	textarea_div_elem.appendChild(document.createElement("textarea"));

For info!
Following the update on jb.js @ March 27. (Replace printf with stub for less code size), below is sequence of jail breaking attempts (before and after) the update on PS4 Pro 7.55.

Note: It is known that the success rate of the jailbreak can't be predicted, bug quality based and completely random.

Old jailbreak attempts
1- Success, HEN V1.1 success, fpkgs success, rest mode success.
2- Kernel Panic
3- Success, HEN V1.1 success, fpkgs success, rest mode success.
4- Jailbreak Failure Message
5- Freeze
6- Kernel Panic

New jailbreak attempts
1- Kernel Panic
2- Jailbreak Failure Message
3- Success, HEN V1.1 success, fpkgs success, rest mode Kernel Panic.
4- Jailbreak Failure Message
5- Kernel Panic
6- Kernel Panic

Thank you for the excellent work!

Dear Sleirsgoevy,

I and homer243, have already tried your new exploit, and it works wonders, fast exploit, no more random KP until now, and above all, on previous exploits, I notice a very little lag on going to settings, and game library, now it looks like is working on stock, what an achievement.

I truly believe this could equal or even take the crown of stability from the famous 5.05 ps4 exploit.

Congratulations

I just checked the size of Mira blob inside mira.js file with the original mira755.bin file (tweeted by AlAzif). The blobs are same, but the actual length of .bin file is 49244. So, where the 65536 come from? Is this correct?

CVE-2021-29627
In FreeBSD 13.0-STABLE before n245050, 12.2-STABLE before r369525, 13.0-RC4 before p0, and 12.2-RELEASE before p6, listening socket accept filters implementing the accf_create callback incorrectly **freed a process supplied argument string. Additional operations on the socket can lead to a double free or use after free.**

CVE-2021-29626
In FreeBSD 13.0-STABLE before n245117, 12.2-STABLE before r369551, 11.4-STABLE before r369559, 13.0-RC5 before p1, 12.2-RELEASE before p6, and 11.4-RELEASE before p9, copy-on-write logic failed to invalidate shared memory page mappings between multiple processes allowing an unpriivleged process to maintain a mapping after it is freed, allowing the process to read private data belonging to other processes or the kernel.