[Asure]

Originally Posted by JonahUK @Asure I'm currently in work but should be able to take a look at this later on this evening (hopefully) and try and get some dumps done. Meanwhile, if anyone else on DEX can get some dumps uploaded to get things rolling?

I'm seeing some differences in the elf / eboot from the dump, and the cracked eboot i have from exetrimal, but i'm not sure if this is for bles/blus and which exact version i have here. Also at work, so i can't see/confirm maybe a bad dump? Exetrimall used different eboot?

In order to go further, we need dumps from DEX, 4.x game, unmodified eboot/disc. i.e. original games running on dex. Preferably also something that has already been dumped, in the exact version/variation (BLES/BLES v1.0 for example..)

[sguerrini97]

I was trying to get some core dumps of newer games from about a week.
I'm on DEX 4.20 and I was able to enable the "Trigger Core Dump" option in the target manager but it seems to work only with debug eboots (fself).

However i'm experimenting another way but i need to execure a retail self.
I think that DEX machines can launch retail selfs only from original discs or BD-EMU+Update..
Does anyone know if it's possibile to execute a retail self without an original disc and/or without any update data? Thanks and sorry for my english.

[erexx]

I have been saying for almost 2 years that the PS3 is wide open.
New retail custom firmware is not needed to get what ever you want out of it.
Too bad ego and greed have made it difficult to bring it all together.

[Asure]

If anyone manages to make a dump similar to what @harryoke provided for me to take a look at, i'll need to know the exact details of the game/version you did it with, and if possible, include the original eboot.bin (encrypted) that you made the dump from. (Otherwise i can't attempt to reconstruct anything.)

[BIade]

Hi!
Its a long time
Im on DEX (switching FW-Version in 5min through internal-hdd-update)
1st) Whats the problem core-dumping with DEX4.20, BD-EMU-USB & update to start a new game?
2nd) CORE-DUMP is selectable in Debug Settings. Do we need to dump via target-manager or is it just another method?
3rd)If Core-dump is possible without target-manager, how do we create a crash, and where is the dump gonna be?

If I got a safe way to core-dump with my dex, i can spam u with dumps ...

Cheers
Blade

[MARA87]

I will get my dex ps3 back from my friend tonight.. i have a few bdemu games that i can test the dump_coreOS stuff on.

I will report back later today.. meanwhile, pls keep us updated on the progress!




EDIT: now if anyone can give us a detailed walkthrough on this, (especially on the crash after MM part) i would be very grateful.

greets!

[SiLENTGame]

This seems to be very interesting.

I'll try to run Child of Eden on my 3.55 DEX in about 2 hours. I will let you know if I have been successful or not.

[BIade]

Why 3.55??
Update to 4.20DEX and start a game with bd-emu-usb or retail disc so u can start a <=4.20 game

Cheers
Blade

Perhaps we can create the crash by pluggin out the usb-stick/hdd while playing via bd-emu-usb, cant imagine it wont crash...

[cik959]

Easy way to crash on dex-
Install rebug spoofer 3.72 or 411
Do not activate, just install.
Launch game in MM.
Once back in XMB, activate spoofer.
Now go back to the MM icon, when u click to launch it, MM will crash.
I have done this several times and the worst that happened was I had to hard reboot and once restarted you deactivate the spoofer before launching MM again.

Obviously leave it installed and you can reactivate whenever a crash is needed

Problem: I'm not sure if it'll work because when you activate it, it might "unload" the needed...

Does anyone have an easier way to "crash"? This is the first thing that came to mind from my experience.

Im not responsible for any harm done to your system. This is just an idea on crashing that I've encountered

[baargle]

Originally Posted by Asure I think i have all the information i need, to do it by hand right now, if i wanted. But i don't do cracks. Your original comment holds true, you can get the needed information from the original eboot.bin. From the raw copy of the dumped elf, we're missing some info that is present in a normal, decrypted eboot. From the ELF, missing is ELF64 Section Headers (seems to start at 0x914B17 in the original eboot.bin) Note, SCEtool can read this info without any keys So i guess, the procedure then becomes as simple as: 1. Grab ELF from core dump (determine where it ends, from scetool..) 2. Dump the ELF64 section header info from the original eboot. 3. cobble both together into a new eboot.elf 4. ??? 5. Profit! This does _NOT_ cover sprx loading EBOOTS!@@#!#@

SPRX are basically dynamic link libraries, no? They wouldn't exist in memory until called by the eboot. I'm no programmer but that's how it's been explained to me.