Debugging full games + sniffing

[zadow28]

i moved the thread here

i just think there are other ways also to do it like full game debugging.

I research this option myself , and i can see also there are ways to to optain the decrypted eboot several ways.

I really played around today, and i manages to get full game debugging.

And that havent been done as yet

It always have frustrateted me that you couldent debugg retail eboots/games

Normally when loading just fself in debugger, is just nothinh happends.

So i played around.

here is an small tut.

First reset in debugger mode.

locate the eboot.bin decrypt it, and resign with Fself one.

then in target manager set app_home to the BLES or BLUS folder.

reset target

Then load executable then locate the eboot.bin

load it

then open Tuner from the SDK.

then load executable there also .

when you do this you get kicked to the ps3 debugger.

then in debugger you press go under options ..

concrats you are debugging full game .

movie intro

Attachment 3312

gameplay

Attachment 3313

also on the ps3 you can play the game under debugger mode .

since eboots stays in ram to the next is loaded the intire game can be debugged.

so there for only the eboot have to be decrypted and not the sprx if the game os needed off that

just since an monkey like me can figure it out so can you.

PS when the debugging starts you can sniff with "software."

even works on 4.11 games but prepare for huge files like 1 gb when sniffing, so hope for any good suggestions.

really dont care about war on sites, just help eachother

funny shit is that you can debugg both TB and cobra this way, all the updates an dongle updaters, just wised that dex was around before

regards

[zadow28]

so offcouse you say why debugg the game.

1 ) Well the debugged of the game is done by decrypting and fself the eboot. Not the other files sprx/self ones they can still be signed with higher keys.

This method also allowed full coredump from ram.

2) Othere way i found is simply sniff with wireshack on local network, the game can be either set up as emu or just app_home.

just sniff then load game. then in the log of the sniffer, the binary is there.(HEX)

still some testing

[zadow28]

So basicly my theory is load 4.1 games with the update trick, load it in the debugger, when game is running make full dump with ram.
This should work since eboots are stored in ram till the next is loaded.

still you need some kind off debugg info in the eboot, for the debugger to load the eboot.

[lolong]

first of all, I'll call zadow28's method is 'A Conspiracy Theory without a Proof'

zadow28,
if this method can make an eboot TB or Cobra,
why not you try it with making an eboot TB for Sleeping Dogs and Darksiders2, also Transformer fall cybertron ?

Note: Please don't tell to the F**king Gregory Rasputin and Hellsing9, because they have a F**king mind problems with sleepingdogs.

[zadow28]

all the cobra and TB updates all the way up to the last can be debugged.
Its pretty easy to do, just decrypt the updates and fself them.Run them in the debugger easy peacy.
Just remember to make an folder PS3_GAME and put the USR dir inside+ set app_home to the dir where PS3_folder is.

regarding the games all games is possible to debug. only the eboot have to be an fself one, then it dosent matter if the other files are signed with greater keys.
the challenge is to build an fself that launch the higher eboots 3.61+ ones, but still there are many ways.
can be if then game have an 3.60 patch but the rest is 4.21, then it should be apple to get some info there.
No exact answer here. thats why i posted this thread, the more testing the faster we get answer.

havent tryed yet on the nodrm games since i dont have any off those. so if any have those try it out.

[zadow28]

ive made an small video that shows how to debugg the dongle updates i dont have any dongle attach.
http://www.youtube.com/watch?v=FkjRK...ature=youtu.be

all updates and apps made can be done this way.

[zadow28]

Also made this one about how to sniff the game, minus is that you get huge files, but you get the eboot decrypted.




so offcause the next is to sniff emu/iso games

Also im on dex 4.21(affraid to downgrade, since i broke one console)
If any on 3.55 can try sniffing the 4.21 emu games there and give some feedback.

[chr15m]

first of all, I'll call zadow28's method is 'A Conspiracy Theory without a Proof'

zadow28,
if this method can make an eboot TB or Cobra,
why not you try it with making an eboot TB for Sleeping Dogs and Darksiders2, also Transformer fall cybertron ?

Note: Please don't tell to the F**king Gregory Rasputin and Hellsing9, because they have a F**king mind problems with sleepingdogs.

Please dont turn this into a HAX drama thread, Devs came here to get away from the children, and further their work
keep up the good work zadow28

[lolong]

I watched your youtube, but sorry, I dont believe it, and I'm gonna to say it again,

still a theory, no proof, also no one try it ? and no one's successfully with this or dump method to get a decrypt TB/Cobra eboot such as fw 4.11 games.

I've a conspiracy theory too, i can proof it, if I get the debug (devkit) keys

"TB team found the keys 80 00 for DEBUG (devkit), this keys was using by developers games to decrypt and encrypt the games, and for testing the games (without using firmware keys revision)"

also I found inside every TB's Eboot, they are using the same hex and text

1. offset 08, 09 with hex 80 00 <-- DEBUG (Devkit)
it can not decrypt without the keys SELF of DEBUG (Devkit)

2. in every TB's Eboot, there was the same hex number, offset 430, 431, 432, 433, 434, 436.
with hex number "6F 8A 81 B0 87 9A 32" and text 'oŠ.°‡š2' ?? I don't know, what it is ? maybe TB special code ?

3. Eboot TB's was using uncompress method, so you could see, the bytesize inside eboot.bin was the same bytesize of eboot.elf.

I could not find this 3 method above, inside N0DRM and Duplex and KMEAW eboot
because their eboot was using firmware keys, not DEBUG (Devkit) keys !

also I don't believe, Duplex found TB's DRM ?!?
if Duplex was really removing TB's DRM, then I could not play MaxPayne's Duplex eboot with TB dongle, right ?

a theory, I hope, I'm wrong and Sony changes his DRM, LOL

[Abkarino]

I watched your youtube, but sorry, I dont believe it, and I'm gonna to say it again,

still a theory, no proof, also no one try it ? and no one's successfully with this or dump method to get a decrypt TB/Cobra eboot such as fw 4.11 games.

I've a conspiracy theory too, i can proof it, if I get the debug (devkit) keys

"TB team found the keys 80 00 for DEBUG (devkit), this keys was using by developers games to decrypt and encrypt the games, and for testing the games (without using firmware keys revision)"

also I found inside every TB's Eboot, they are using the same hex and text

1. offset 08, 09 with hex 80 00 <-- DEBUG (Devkit)
it can not decrypt without the keys SELF of DEBUG (Devkit)

2. in every TB's Eboot, there was the same hex number, offset 430, 431, 432, 433, 434, 436.
with hex number "6F 8A 81 B0 87 9A 32" and text 'oŠ.°‡š2' ?? I don't know, what it is ? maybe TB special code ?

3. Eboot TB's was using uncompress method, so you could see, the bytesize inside eboot.bin was the same bytesize of eboot.elf.

I could not find this 3 method above, inside N0DRM and Duplex and KMEAW eboot
because their eboot was using firmware keys, not DEBUG (Devkit) keys !

also I don't believe, Duplex found TB's DRM ?!?
if Duplex was really removing TB's DRM, then I could not play MaxPayne's Duplex eboot with TB dongle, right ?

a theory, I hope, I'm wrong and Sony changes his DRM, LOL

Allow me to correct your info first,
TrueBlue not using any kind of Debug keys since in Debug/DevKits there is no need for encryption at all the key revision 0x800 you talked about is just to let GameOS know that they will launch debug self and its not encrypted at all.
you can do it your self by just unself any retail self then use make_fself.exe tool from official SDK then you will have a EBOOT.BIN or SELF file that looks like TrueBlue Eboots except that all its sections are not encrypted and it has no metadata embedded into it.
This revision key value maybe used only by TB to trigger its payload to load and decrypt the DRMed eboots only and use normal payload or normal keys for non 0x800 flaged eboots.