True Blue ELF Dumper Released; Source Code Also Found After A Failed Deletion Attempt

[PatrickBatman]

Yes! This infomation needs to be forwarded to the right people if you know what I mean.

I sent this info to Dean, but he's away right now, so we will see what happens.

[Piratan]

if we can decrypt sprx too now then that is great news. When this started I didn't know how far it would go since it talked only about dumping the eboot, since most newer TB games also have those sprx too.

Great progress.

by chance, in the newer DEX firmware with the VITA options, those are sprx files as well isn't it? I may be the only one that actually wants to bring in that VITA stuff to the lower firmwares. ( I love my vita even if the rest of the world hates it. )

[Abkarino]

if we can decrypt sprx too now then that is great news. When this started I didn't know how far it would go since it talked only about dumping the eboot, since most newer TB games also have those sprx too.

Great progress.

by chance, in the newer DEX firmware with the VITA options, those are sprx files as well isn't it? I may be the only one that actually wants to bring in that VITA stuff to the lower firmwares. (I love my vita even if the rest of the world hates it. )

A *.sprx is a dynamic link library for PlayStation 3 software like *.dll for windows so it exist in most games if this games uses additional shared functions that is not included in firmware libraries so a lot of games need this sprx files.
Its a code blocks that developers decide to reuse it in other software so no need to rewrote it every time, so to made using it easier and updating/debugging it easier its written to a separate library so it can be called when needed.
Also a game developer may use a third party sprx (library) that was written by some one else without knowing how it already coded like using Sony's SPRX or maybe a SPRX coded by games studios like BINK for example to handle *.BIK video files that we can found in a lot of current games.
We need a working way to dump all of this info from memory since this method will not work while TB dongle inserted, also i had tried it with JB-King with 2.5 fw but the same result, black screen after launching any game from MultiMan.

I have an idea also but it need to be tested first.
If we know the sprx file that show in game XMB options or can be called after loading the game EBOOT to PS3 memory then after starting the game we call it from in game XMB menu or something like that i think it will work then we can have a working or maybe full ELF dump for game eboot, but this is a theory only and it may not work any more.

[AlbedoAtoned]

They can't. The game eboot has to be loaded into ram so there's no way they can patch a ram exploit. As the game has to be completely unencrypted when it's ran through the ram. (I could be mistaken.) So unless there's some technique for PC's/consoles that allows you to basically obfuscate(is that the right word? Sorry still learning programming and while I know how ram functions for the most part I don't know the lower level stuff yet. Hell I can't even find a way to describe what knowledge I'm lacking in that department.) the ram contents, it's impossible. Once it's in ram, it's fair game for everything.

EDIT: Because as far as I am aware the PS3's security is setup in a way that it unencrypts the eboots before "booting" them. As like I said I don't believe you can run games or anything for that matter encrypted in the ram. Unless maybe you add additional routines that encrypts the eboot in realtime as it's playing. (Basically the PS3 verifies the eboot is valid, then rencrypts the eboots and unecrypts the eboot in realtime as you are playing. But considering I'm not an expert in ram on even PC's this is just a theory.) In which case the bugs that shit will create will FAR outweigh the "piracy implications."

EDIT2: But take all of this with a grain of salt as like I said my knowledge isn't complete in regards to ram on even PC's. So maybe it could be possible. Hopefully someone with more expertise can correct, clarify, and/or add to what I said above.

I'm no programmer myself, but I think the eboot has to be in one way or another, decrypted. Perhaps the eboot could stay encrypted and only specific parts that are in use could be decrypted, but even that way could still yield dumps. Also, I think such a measure of it having to decrypt certain parts and re-encrypt them may cause games to suffer performance problems. Some games may have to be optimized to handle the extra encryption/decryption.

A much more likely solution TB may take is to stop the software RAM dumper, or even bring back the hdd wipe or other "features" to turn away people from trying. At that point hackers would need to try something hardware, which could still be detected by either Sony or TB if they tried.

It is looking more and more likely though that nothing will be done about it. TB is probably gone by now, and won't come back. Though that is not reason enough to quit. The market still has open spots and if the scene doesn't fill them, another business will.

[Abkarino]

@DeanK,
Would you please provide me a full source code for your modified tool (main.c + MakeFile), i want to mod it to use PS3L1ght V2.0 SDK.
Also i have some improvement idea that i want to test it.

[oneofthem]

SDK must be installed in C:\usr\local\cell

makefile:

CELL_SDK ?= /usr/local/cell
CELL_MK_DIR ?= $(CELL_SDK)/samples/mk
PRX_SAMPLES_DIR ?= $(CELL_SDK)/samples/sdk/prx
include $(CELL_MK_DIR)/sdk.makedef.mk
include $(PRX_SAMPLES_DIR)/mk/prx.mk

PPU_SRCS 	= orig.c
PPU_PRX_TARGET 	= simple-c-prx.prx
PPU_PRX_LDFLAGS += $(PRX_LDFLAGS_EXTRA)
CLEANFILES 	= $(PRX_DIR)/$(PPU_SPRX_TARGET)

stub:

include $(CELL_MK_DIR)/sdk.target.mk
include $(PRX_SAMPLES_DIR)/mk/prx_target.mk

After compilling(with errors), just execute this batch file:

C:\usr\local\cell\host-win32\ppu\bin\ppu-lv2-g++.exe -mprx  objs/orig.ppu.o -zgenprx -zgenstub -zfix-rel24 -llv2_stub -lfs_stub -o simple-c-prx.prx
C:\usr\local\cell\host-win32\bin\make_fself.exe simple-c-prx.prx libsysutil_np_trophy.sprx

It works on DEX, as i've tested it.

[JLM]

In general terms, copy and pasting makefiles from online sometimes adds an unseen blank space in a file causing an error when the make command invokes the makefile.
Possible error message:
warning null character seen; rest of line ignored.
missing separator. Stop.

Retyping the text into a new file will fix it.

[Yayo]

hi @oneofthem how did you make it work on dex?
it keep sending me back to xmb...
I've tested it on 3.55 DEX p'n p enabled (this one multiman not launching)
And 4.20 DEX with Sleeping dogs and the same...
Nothing is there in hdd0...

[oneofthem]

hi @oneofthem how did you make it work on dex?
it keep sending me back to xmb...
I've tested it on 3.55 DEX p'n p enabled (this one multiman not launching)
And 4.20 DEX with Sleeping dogs and the same...
Nothing is there in hdd0...

That's because you don't have access to write directly to dev_hdd0 on dex, but if you'll change path to save the dunmp file(in source code), it will dump the memory, but only on 3.55, on other firmwares it can only dump multiman, don't know why...

[Yayo]

That's because you don't have access to write directly to dev_hdd0 on dex, but if you'll change path to save the dunmp file(in source code), it will dump the memory, but only on 3.55, on other firmwares it can only dump multiman, don't know why...

Ok thanks for these indications. But so its of any use for 3.60+ games if i understand?