[zadow28]

Remember all this is still in the testing face.
I managed to sniff local network. via the app_home folder from pc.
Yes you get decrypted eboot also this way

the goal here is offcouse to do the same with and 4.2+ game with the update trick.

im on 4.2 dex some could try sniff local on 3.55 dex see if any info get out that way.

Also

Originally Posted by Another_Anon Congrats, you miss just a little part to decrypt retail self :P You "just" jave to build a fself that run an external retail self, than you can read it from ram (decrypted) via core dump, via debugger or directly using the fself itself! SDK samples explain how to do that, you just have to read them! :P

this above could be an solution also.

This is an theory, may work, may not.

Only test will show.

The thing is when an game is loaded, the eboot stays in the ram, until next is loaded.
this would also happend to the 4.2 games via update trick.
the eboot is in ram, just have to get to it.

Regards

[DEFAULTDNB]

Great work @zadow28 , look forward to seeing what comes from this.

[uncharted angel]

i have some question ----please answer them

locate the eboot.bin decrypt it, and resign with Fself one ---what this mean??? what must i do???

where is target manager???

how i open tuner from the sdk????

what debugging full game ??? what changes???

[mathieulh]

You need to understand a few things:

1. Coredump is by design, meant not to trigger when a process flagged as "not debuggable" (that's a capability flag in the EBOOT's metadata) is running.

2. It's easy to run an actual disc eboot in debug mode, it usually doesn't require anything more than using a static path for the eboot (and to have the original disc in the drive because the self is flagged with "discbind" capabilities), the thing is if it is flagged as not debuggable, even though you can run it, you cannot attach to the process and thus dump it, and coredump will be disabled.

3. The only thing that can trigger a coredump on a not debuggable process is an exception, but to have any process flagged as not debuggable copied to ram, you need to run it (you cannot load and not start a process flagged as not debuggable, unlike ones issued from fself or regular processes) The issue is that once the said process is running, since it's obviously loaded from a signed and encrypted executable, you do not have any control of what runs there, you also cannot have your own process running on the background while this one gets started because all the sprx/processes you would have had loaded get unloaded as soon as the new executable starts (they don't have the proper cflags to stay loaded)
This means you cannot trigger the exception on your own, you have to rely on an existing bug in the actual game code (good luck with that)

Finally I don't see what wireshark has to do with this.
For your intel, all 2.20+ game selfs are flagged as "not debugable"

Oh ! and even on DECR-1000A, if you are running a process as "not debugable" the foot switch coredump will not work/trigger.

Sorry to disapoint you all.

[zadow28]

thx for clearing it up
but any suggestions then mathieulh

The Damage Inc Pacific Squadron WWII PS3 3.55/3.41 EBOOT Fix
was done with hardware
But if loaded as an fself, it contains core dump, handles that havent been removed proberly,
when rebuilding the elf.
is there some way to inject the liblv2dbg library that handles the coredump.?

[MARA87]

Originally Posted by uncharted angel i have some question ----please answer them locate the eboot.bin decrypt it, and resign with Fself one ---what this mean??? what must i do??? where is target manager??? how i open tuner from the sdk???? what debugging full game ??? what changes???

If you have so many questions... this may not be for you

[Abkarino]

Originally Posted by mathieulh You need to understand a few things: 1. Coredump is by design, meant not to trigger when a process flagged as "not debuggable" (that's a capability flag in the EBOOT's metadata) is running. 2. It's easy to run an actual disc eboot in debug mode, it usually doesn't require anything more than using a static path for the eboot (and to have the original disc in the drive because the self is flagged with "discbind" capabilities), the thing is if it is flagged as not debuggable, even though you can run it, you cannot attach to the process and thus dump it, and coredump will be disabled. 3. The only thing that can trigger a coredump on a not debuggable process is an exception, but to have any process flagged as not debuggable copied to ram, you need to run it (you cannot load and not start a process flagged as not debuggable, unlike ones issued from fself or regular processes) The issue is that once the said process is running, since it's obviously loaded from a signed and encrypted executable, you do not have any control of what runs there, you also cannot have your own process running on the background while this one gets started because all the sprx/processes you would have had loaded get unloaded as soon as the new executable starts (they don't have the proper cflags to stay loaded) This means you cannot trigger the exception on your own, you have to rely on an existing bug in the actual game code (good luck with that) Finally I don't see what wireshark has to do with this. For your intel, all 2.20+ game selfs are flagged as "not debugable" Oh ! and even on DECR-1000A, if you are running a process as "not debugable" the foot switch coredump will not work/trigger. Sorry to disapoint you all.

So please math guide us to the right way, i know that you know much about that process also what about your bootloader exploit?

[ttz]

thank math, always clear
I think u are able to play all 4.xx games, isn't it?

[Isleofdoom]

Math is correct on this and I found a thread on this that was fixed by Sony so its kinda old. Unles zadow28 did something else to some files
************* [ - Post Merged - ] *************
It is possible for this to work with dongles and have been tryn my own methods with lots of research and editing. Havnt got an exploit to work but got a kick back cuz the files DRM prevent from doin a dump

[stuck?]

@uncharted angel maybe you should just hold on a bit and wait until things get a little easier instead of going balls deep right away.

Obviously these procedures are a bit too advanced for you (at the moment perhaps), so you should just be a bit patient and wait for some easier steps.

Chill, play some games This is all work in progress so everybody will run into some bumps.