[derako]

What about making it crash while playing Skirim? That game had to be patched to solve those crashing problems

Cheers

[sguerrini97]

Originally Posted by badhabit to trigger the core dump you could use samples/sdk/dbg/exception_handler in the 4+ sdk for example using liblv2dbg

Thanks for the info.
I've compiled the exception_handler sample
Then I've made an mself (samples\sdk\lv2\multi-self) that contains as first self the "exception_handler_main.ppu.self" and as second self the original EBOOT (renamed EBOOT.self) of COD MW3 (BLES01430).

Here is it: http://www.mediafire.com/?otqtt5lq97t58be

If I'm right this should cause a core dump of both selfs.
I can't test it until tomorrow evening.. If someone wants to test just update to DEX 4.20, put the files from the archive to the fileserving dir (app_home) and execute from the target manager "/app_home/mself-main.ppu.self" then wait..

[IngPereira]

I recommend that the fastest way is to swap some sprx (which can be activated from the XMB, like the music player is activated by playing any music in the usb).

audioplayer_plugin.sprx

With the SDK 3.70 you can create one sprx (It will trigger a Core dump) with FSELF in 4.11 and you can use a homebrew to remount the dev_flash with writing allowed (You can do this obviously with the SC 837 and 838 not need poke) so you can swap the sprx of the music player with your own!.

Now swap your new sprx, rename it to audioplayer_plugin.sprx (Ready to make a trigger that will call a Core dump) then run a game in bd-emu or original disc, later go back to XMB (The eboot remain in memory) and trigger the Core dump by trying to play any mp3 stored on usb with the modified audioplayer_plugin.sprx.

The sprx don't use much memory because this they are great to something like this(Documented on the SDK)...

I will try to do this because i have the 3.70 SDK...

Edit:The better way to do this is swapping xmb_ingame.sprx because you can call INGAME and trigger a Core dump while you are in the game, this will work better...

[tweetymr]

Originally Posted by IngPereira I recommend that the fastest way is to swap some sprx (which can be activated from the XMB, like the music player is activated by playing any music in the usb). audioplayer_plugin.sprx With the SDK 3.70 you can create one sprx (It will trigger a Core dump) with FSELF in 4.11 and you can use a homebrew to remount the dev_flash with writing allowed (You can do this obviously with the SC 837 and 838 not need poke) so you can swap the sprx of the music player with your own!. Now swap your new sprx, rename it to audioplayer_plugin.sprx (Ready to make a trigger that will call a Core dump) then run a game in bd-emu or original disc, later go back to XMB (The eboot remain in memory) and trigger the Core dump by trying to play any mp3 stored on usb with the modified audioplayer_plugin.sprx. The sprx don't use much memory because this they are great to something like this(Documented on the SDK)... I will try to do this because i have the 3.70 SDK...

Sounds like a nice work-around I think it's worth a try.

[ps3hen]

The full quote of the post by cfwprophet from 'that site':

Hmm.. ok.. so only fake self or NPDRM fake self well then take MultiMan 04.02 which is a Retail NPDRM >> enable core dump function >> start MultiMan >> exit to XMB and be surprised. Just only one little present. And now start to use your brains. There is always a way.

That was part of an argument, cfwprophet was having with another member about the functionality of core dump. One member was saying that core dump would only work with fselfs, cfwprophet disagreed, with the above post. But in saying that multiman was a retail NPDRM self, showed great ignorance on the matter and was pointed out by a few members. cfwprophet has stayed quite since. Now I've never used core dump before, so I don't know either way. But information from someone who thought multiman was a proper retail NPDRM self, should be taken with a pinch of salt.

[harryoke]

we need to make a RSX exception i think....mess with some game files....textures ingame maybe?

[KDSBest]

TeaM_AC1D are doing alot research in that direction. If you know any way or got ideas tell me. Sibce we are waiting for some Hardware to get crafted for us, this is our time filler

[DEFAULTDNB]

Originally Posted by KDSBest Since we are waiting for some Hardware to get crafted for us, this is our time filler

Hardware??

[IM1990]

I've heard that anons working on this method have been able to fix Lollipop Chainsaw too.I really think this is the way TB team was going for with their patches

[kilom]

Originally Posted by mellss Sorry to said that but if you see a black sheep in irish, you will say that all sheep are black? Readself RELOAD.SELF (MULTIMAN): Control info control flags: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --> flag DEBUG file digest: 62 7c b1 80 8a b9 38 e3 2c 8c 09 17 08 72 6a 57 9e 25 86 e4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Why i say that: because i investigate in it a long time ago. If you don't trust duplex and me, that they don't use coredump is when you decrypt DUPLEX EBOOT the last section is present (in coredump there are no the last section). I think they got others keys (3.60+) or someone in their team have reversed drm eboot.

He is right, the last section (segment) isn't present in lv2coredump

- Comparison between decrypted reload.self and coredump reload.self with winhex doesn't match.
- I also tried to reencrypt my extracted coredump EBOOT.BIN and it said "read: elf error".

Moreover, liblv2coredump.sprx is user mode app, so it couldn't dump lv2 (kernel) or lv1 memory(hypervisor).
To hack full ram you need, to pwnage before hypervisor...

"People should attempt to hack hypervisor mode to get a debug cfw hen", like someone said me who have pwnage TB a long time ago.