bigboss

people with real problems with ps4link should open an issue in github repository. I can't be here often sorry. memory error on loading is signal for wrong configuration in : custom kern call address $0x93a4FFFF8 (hitodama and me we are using that now) and binary loader position we are using that: Text ?= 0x93a300000 Data ?= 0x93a400000 so checkout last sources from ps4link and libps4 Without info and logs about your error i can help you. As i say open an issue in repository with all your detailed info about your problem. Anyway there is a new sdk in town(ps4sdk) at ps4dev repository , it is not finished but it has very promising features, and we wait to add more with help of people really interested in collaborate in an open source sdk for ps4 homebrew. If your interest is only run pirated games then it will not be the right place for you, ask other people/places for that. There is a branch in (ps4link ) supporting it , documentation is not updated but developers are smart people so you can learn how to port your own code to ps4sdk. There are issues opened at ps4sdk, so fork , code and we wait your pull requests Advice: don't run code downloaded in binary without sources, compile it yourself.If you are running as root on your ps4, that code can make really nasty and bad things on it. codec off

are you using libps4 from my repository or from ps4dev's repository? i am using custom values for syscall address and ps4-bin.mk for my environment different than ps4dev or cturt values. check if the problem can be there and use your own.

updated ps4link, now i wait you will not have problems compiling all

hello there, i updated ps4link with new stuff for developers. https://github.com/psxdev/ps4link Enjoy

thank you guys i updated ps4link with good stuff for developers

struct proc and cred is wrong , now that you can dump kernel , you can figure out why that 40 is wrong. I told you a function called procfs_doprocstatus at FFFFFFFF823C3C00 check his code (https://github.com/freebsd/freebsd/blob/0f2211c30ded7871b441bfaa1647843f1b4fd0c2/sys/fs/procfs/procfs_status.c) and compare with your dump all offset you need are there clear like water

if you look for ps2vfs original readme file you will see that i was released on my birthday struct members for cred and proc are all wrong it doesn`t matter PS2-SDK or libps4. Check funtion i told you on ida.

Sure, First at all, check https://github.com/CTurt/PS4-SDK/issues/13 i told to kR105 and Cturt that queue type can't be int. i like more before kernel allocation stuff find the right fd. I suppose that Cturt write his initial code with bug in funcion close so he believed that calling close does not decrease fd internal counter, i show him that this is false and he fixed code and doc. Check https://github.com/ps4dev/libps4-examples/issues/1 So basically first look for right fd number( 3840) second allocation part avoiding socket open/close stuff check https://gist.github.com/psxdev/7da7d16186a735569558 when you get kernel execution you must figured out return address: void * (*mimemcpy)(void *restrict s1, const void *restrict s2, size_t n)=0xFFFFFFFF82613BC0; mimemcpy(dump, __builtin_return_address(0), 0x1000); you must compare with your full kernel dump and you will see that Triggering part in https://cturt.github.io/dlclose-overflow.html is wrong in orbis function who call payload is knote_fdclose you can check with dumped code. finally guys address from members structure cred and proc are completely wrong on leaked badiret code a good function in orbis kernel to check right offsets for these members is procfs_doprocstatus I don't know why code is not released. Perhaps i will give you a present for my birthday and release something for that date libps4 is more developer friendly than PS4-SDK but i have not write access to ps4dev repository and hitodama is missing. If he does not contact with me i will commit all changes in my own repository happy hacking

Hi, new in the this forum