Try to insert a function on lapse.mjs instead of binary fix

[viggen66]

Instead of waiting for full exploit rop, replace binary file to use this new function

function patch_aio_kernel(kmem, kbase) {
log("Applying AIO kernel patches to prevent game issues...");

// Array patches: [offset, bytes]
const patches = [
    [0x9f141, [0xeb, 0x48]],
    [0x9f183, Array(8).fill(0x90)], // 8x NOP
    [0x9f18b, [41, 83, 0xbf, 0xa0, 0x04, 0x00, 0x00, 0x00]],
    [0x9f199, [0x49, 0x8b, 0x87, 0xd0, 0x04, 0x00, 0x00]],
    [0x9f1a6, [0x49, 0x8b, 0xb7, 0xb0, 0x04, 0x00, 0x00]],
    [0x9f1be, [0x49, 0x8b, 0x87, 0x40, 0x05, 0x00, 0x00]],
    [0x9f1cb, [0x49, 0x8b, 0xb7, 0x20, 0x05, 0x00, 0x00]],
    [0x9f1e3, [0x49, 0x8d, 0xbf, 0xc0, 0x00, 0x00, 0x00]],
    [0x9f1ef, [0x49, 0x8d, 0xbf, 0xe0, 0x00, 0x00, 0x00]],
    [0x9f202, [0x49, 0x8d, 0xbf, 0x00, 0x01, 0x00, 0x00]],
    [0x9f20e, [0x49, 0x8d, 0xbf, 0x20, 0x01, 0x00, 0x00]],
    [0x9f21f, [0x49, 0x8b, 0xff]]
];

patches.forEach(([offset, bytes]) => {
    const addr = kbase.add(offset);
    bytes.forEach((byte, index) => {
        kmem.write8(addr.add(index), byte);
    });
});

log("AIO kernel patches applied successfully");

}

Call function on async function patch_kernel(kbase, kmem, p_ucred, restore_info), after version check

// AIO Fix
log('Applying critical AIO stability patches...');
patch_aio_kernel(kmem, kbase);`

This way the aio fix is applied as soon as possible, to avoid any further damage.

[kmeps4]

Thx I'll check it and accept your PR :)

[kmeps4]

Tried that approach but aio bugs persist.. seems using kmem do not fix it properly

[viggen66]

Thanks, probably function call, needs be moved to another place, since offsets and bytes are the same from patch_aio, the sooner the kernel is stabilized the better.

[kmeps4]

Yeah maybe inside kpatch

[mrdude2478]

@viggen66

Maybe you made a typo, but shouldn't your patches be this?

const patches = [
    [0x9f141, [0xeb, 0x48]],
    [0x9f183, [0xeb, 0x06]],
    [0x9f18b, [0x41, 0x83, 0xbf, 0xa0, 0x04, 0x00, 0x00, 0x00]],
    [0x9f199, [0x49, 0x8b, 0x87, 0xd0, 0x04, 0x00, 0x00]],
    [0x9f1a6, [0x49, 0x8b, 0xb7, 0xb0, 0x04, 0x00, 0x00]],
    [0x9f1be, [0x49, 0x8b, 0x87, 0x40, 0x05, 0x00, 0x00]],
    [0x9f1cb, [0x49, 0x8b, 0xb7, 0x20, 0x05, 0x00, 0x00]],
    [0x9f1e3, [0x49, 0x8d, 0xbf, 0xc0, 0x00, 0x00, 0x00]],
    [0x9f1ef, [0x49, 0x8d, 0xbf, 0xe0, 0x00, 0x00, 0x00]],
    [0x9f202, [0x49, 0x8d, 0xbf, 0x00, 0x01, 0x00, 0x00]],
    [0x9f20e, [0x49, 0x8d, 0xbf, 0x20, 0x01, 0x00, 0x00]],
    [0x9f21f, [0x49, 0x8b, 0xff]]
];

[viggen66]

Yes there's a mistake on two bytes, using a function probably is a more efficient than using a later bin loader, it's like having a fire and extinguish it before it gets a major problem, now is finding the correct stage to call the function.

[mrdude2478]

Yes there's a mistake on two bytes, using a function probably is a more efficient than using a later bin loader, it's like having a fire and extinguish it before it gets a major problem, now is finding the correct stage to call the function.

See here: https://github.com/Al-Azif/psfree-lapse/tree/main/src

When kpatch gets called is when those bytes get patched. (900.bin) in kpatch folder. It look like that bin is loaded into a buffer and gets injected in this function: async function patch_kernel(kbase, kmem, p_ucred, restore_info). Maybe make your function into async function and await a promise so you know it's fully executed before continuing the rest of the code.

[kmeps4]

The 2 bytes are a typo.. its just add 0x. I have it fixed on my bin. Now the reason I didn't choose kpatch to patch the aio ptor handle functions is because after kpatch the exploit continues doing some aio cleanup https://github.com/kmeps4/PSFree/blob/main/lapse.mjs#L1784. So my idea was to load the fix after exploit is fully completed. Same approach was used by Gezine on Bdjb.. dunno if aio fix on kpatch was fully tested. In my case I spent several days testing it on 800 & 900 before I decided to release the bin. The aio fix code was made by abc so all "different" aio fixes patches the same function. The other repo always develop stuff in "fast" mode, to release stuff quickly and (maybe) without decent and proper testing so I prefer to go my way having SiSTR0 and CTN advice

[mrdude2478]

@kmeps4

Does this patch work in the same way the aio fix for goldhen works? Apparently some were having issues with a Harry potter game, Hogwarts legacy I think? I didn't try as I don't have that game. Also these bytes are changed (instead of making 8 NOPS, it just jumps by 0x08, essentially doing the same thing but more efficiently).

[0x9f183, [0xeb, 0x06]],

I've been using Al-Azif version the last few days and didn't get any issues, Once the patches are executed and ps4 memory is patched, surely cleaning up these temp buffers/arrays isn't going to affect where the PS4 memory is patched, otherwise the patch wouldn't work? Or am I missing something? You may as well just put the patches in -https://github.com/kmeps4/PSFree/blob/main/rop/900.mjs and be done with it.

[kmeps4]

@mrdude2478 as I said the patch was released by ABC since July 2025.. we got suggestions to use the plugin which fixes lot of issues.. after by curiosity tested abc fix on 800 to embed it on host like 15 day ago.. then I ported to 900 and started to do several testing which resulted ok. So I decided to release the fix as a payload for 2 reasons.. can be automatically loaded by host payload loader or load it using from another bin server.. the way on kpatch was added after me and gezine released it to public.. so by the moment will leave my approach.. if I get some time will test on kpatch side and if I declare it as stable will swap strategy

[kmeps4]

@mrdude2478 the Harry Potter issues was with the plugin?

[costasto]

i wanna ask is the payload fix more efficient than goldhen plugins? or they achieve same thing?

[RandQalan]

@mrdude2478 the Harry Potter issues was with the plugin?

Hogwarts legacy has problems with plugin.
If I remember correctly the porter said has to work around prx audio problem to backport may be the reason.
The bin patch with a little testing by me shows no such problem.