Olygame


ModChipCentral

Results 1 to 1 of 1
  1. #1
    Administrator
    Join Date
    Jun 2011
    Location
    Tropical Island
    Posts
    1,785
    Total Thanks Given
    210
    Total Thanks Received
    6,153
    Total Thanked Posts
    1,362
    Gamer IDs

    Gamertag: garyopa PSN ID: opagary

    ps3 Debugging full retail PS3 games?

    A tutorial by 'Zadow28'

    Crunching developer 'Zadow28' has posted info on how to invoke the PS3 debugger on full retail games...


    Sometimes we get so busy with daily chores and other amazing news we miss things happening right on our own forums as recently crunching forum member 'Zadow28' had posted a small tutorial on how to get the PS3 debugger to work on full retail games by resigning eboot.bin and using SDK tools.

    Also, by using this same method, he shared ideas of how to dump RAM on newer games...

    Here's his original post:

    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 haven't been done as yet
    It always have frustrateted me that you couldn't debugg retail eboots/games
    Normally when loading just fself in debugger, is just nothing happens.
    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 .

    [...]

    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 don't care about war on sites, just help each other

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

    regards
    He also posted a video on how to 'sniff' a game.


    On the flip side, ex-scene developer Mathieulh has his two cents to add into why this is not your golden ticket:

    Quote 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 join into the fun and debate about this subject or just try it yourself and get more info about all this at Zadow28's official Crunching thread!

  2.          
  3. The Following 9 Users Say Thank You to GaryOPA For This Useful Post:

    AlbedoAtoned (09-21-2012), el-Cid (09-20-2012), gDrive (09-19-2012), kgb (09-20-2012), Misfit (09-19-2012), nextbike (09-20-2012), pete_uk (09-19-2012), STLcardsWS (09-20-2012), Yuu (09-20-2012)


 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
EachGame