Damage Inc Pacific Squadron WWII PS3 3.55 / 3.41 EBOOT Fix Out

36w ago - This weekend we received word from a PlayStation 3 developer who wishes to remain anonymous news of a Damage Inc Pacific Squadron WWII (Firmware 4.11) PS3 EBOOT fix for 3.55 and 3.41 Custom Firmware (CFW) users.

Download: Damage Inc Pacific Squadron WWII PS3 3.55 / 3.41 EBOOT Fix / Damage Inc Pacific Squadron WWII PS3 3.55 / 3.41 EBOOT Fix (Mirror) / Damage Inc Pacific Squadron WWII PS3 3.55 / 3.41 EBOOT Fix (Mirror #2) / Damage Inc Pacific Squadron WWII PS3 3.55 / 3.41 EBOOT Fix (Mirror #3) / Decrypted Original ELF by PSFreak

From the author on the release: Hello, I want to share an unreleased EBOOT with everybody but I want to be anonymous.

The EBOOT is for the game Damage Inc Pacific Squadron WWII (FW 4.11) and works on 3.41 / 3.55 CFW.

Everybody with a DECR and extra hardware to dump the RAM can get his hands on those decrypted EBOOTs.

Greetz

Below is a brief guide from zadow28, as follows:

This is great news, 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 obtain the decrypted eboot several ways. I really played around today, and I manages to get full game debugging.. also on the PS3 you can play the game under debugger mode.

Since EBOOTs stays in ram to the next is loaded the entire 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.. when the debugging starts you can sniff with "software."

Even works on 4.11 games but prepare for huge files like 1GB when sniffing, so hope for any good suggestions. Funny that you can debug both TB and Cobra this way, all the updates an dongle updaters, just wised that DEX was around before

• 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
  
• Congrats you are debugging full game
  

So of course you say why debug the game:

1) Well the debugged of the game is done by decrypting and fself the EBOOT. Not the other files sSPRX/SELF ones they can still be signed with higher keys. This method also allowed full coredump from ram.

2) Other way i found is simply sniff with wireshark 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.

So basically 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 debug info in the EBOOT, for the debugger to load the EBOOT.

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 dosen't 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.

Haven't tried yet on the nodrm games since I don't have any off those.. so if any have those try it out. I've made an small video that shows how to debugg the dongle updates I don't have any dongle attach... all updates and apps made can be done this way.





Also made this one about how to sniff the game, minus is that you get huge files, but you get the EBOOT decrypted.. so of course the next is to sniff emu/iso games. Also I'm 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.





Another thing i noticed is when running different EBOOTs. Is that the EBOOTs depends on many different files mostly sprx one, from dev flash from the console. So they also show in the debugger, decrypted or in the core dump.

Now i have many thought og doing this, one is maybe debug an game while it patches an game online.. not sure. Best is if we could build an debug self that runs the actuall eboot. Not unlike the eboots thats runs the signed files from console.those get decrypted. Remember if loaded from the debugger insteed of the target there is an nice little function called force coredump.

If you haven't figured it out yet you can debugg patches also .Like nodrm ones, or games. When you get the patches. you have to set the folders strait.

Make Ps3_Game folder, copy the USRDIR inside ,put the app_home ,then debug as normal. the nodrm patch would show up as any other patch for an game. (remember to Fself the EBOOT) if you want redump as nodrm did it, rebuild eboot.elf the elf would get decrypted right this time.and off coause this eboot work on any rip games.

I managed to dump sdat packed files also:
Now first when i debugged the patched the target was looking for game.psarc.sdat it gave an error since it wasn't there. so i replaced the game.psarc.sdat with files that was finallyzes encrypted, just rename the files i wanted to game.psarc.sdat then in debugger, do core dump extract the sdat decrypted.

And to math flags explaination, that you cant dump files without prober flags. I haven't come across and game or app that i havent been able to dump yet, maybe you can elaborate on that, since maybe the core isn't visible but, if stepping one by one into memory you are able to just dump the last executable one.

I've made an video sometime ago on another topic, but this would go for all the sdk.. new quick video:





I was looking at the sequence from make self, making fself, making E/Adat to examine the different algorythms. This is the way to debug and reverse it in ida pro, now this stuff is to hard for me to calculate the algorythm. now i highlight on video on right mouse what to look for, so if you get the video you get the point.

I admit this is to hardcore for me.. actually you would need some one like math to calculate the sequence, even with it being wide open.

The games that needs to run as emu, actually don't. After you build the emu in ps3gen, press verify. Then select emu you just build. then select all files and folders, then decrypt. Now in Target manager set app _home. to the folder you created. IN release mode play via XMB.

From Abkarino: You do not need all this steps to just decrypt SDAT files. You can use this application (asmodean.reverse.net/misc/_/extttdpk.zip) to do this. Also you can look at this article it take about SDAT decryption and this code is tested and work fine. You can build your app to decrypt any SDAT files and run it in any DEX or CEX with CFW console.

From RangerRus (via forum.xentax.com/viewtopic.php?f=21&t=7610): sdat files (PlayStation 3) decryption method:

Hello. Today we'll talk about .sdata encrypted files and HOW to decrypt and then "encrypt" them back.

First, i've to say about why we should know about this. There are many games which included such file types on ps3, many of them not supported another languages (ie. russian). And for their translation we need to decrypt this type of files (for example Red Dead Redemption or Demon's Souls).

Second, here is some information about encryption. Even if .sdata files encrypted, we can create .sdata file without encryption from decrypted file and it will work in a game. For this purpose you should use a standart SDK programm "make_sdata.exe". This (and other files we will talk about) here, in sdata-archive: * snip

Next, about how to decrypt them. Well, this is hard - you need: 1) jailbroken ps3 for real tests (or smbd. who got it) 2)SONY PS3 SDK (I think, you should take DUPLEX 3.40 version) 3) an encrypted file (examples in my sdata-archive). When the SDK would be downloaded, make all preparations to work with it and go next part:

To decrypt this files we should create a special "game" and run it from game manager, like Multiman. The question is how to build eboot.bin file we need it for. Well, some part of the answer is here: asmodean.reverse.net/pages/extttdpk.html

Let's try to understand what is this all in extttdpk.zip (included in my sdata-archive). First, we should to read SDATA-Overview_e.pdf (take it from my sdata-archive). It says that decryption of this file can be proceed by a function cellFsDataOpen() and other functions, which must be used when you create a game, i.e. EBOOT.BIN.

Ok, let's open extttdpk.zip:

1) extttdpk_v1.exe, extttdpk_v2.exe, extttdpk.cpp are files we no need in them.

folder decrsdat:

2) decrsdat.cpp - source C file we will need to create EBOOT.BIN
3) PS3_GAME folder: it's done folder of our "game"
4) decrsdat.conf & decrsdat.build we no need to modify - it have to use while compiling EBOOT.BIN with decrsdat.cpp.

folder game -> usrdir:

5) decrsdat.lst - simple file where we write about what file we need to decrypt (open with Notepad++). Example:

Here we need to decrypt file "datadkh.sdat" (which have placed in /dev_hdd0/game/LAUN12345/GAMEZ/BLJM60166/PS3_GAME/USRDIR/) and place decrypted copy "datadkh" of it in /dev_usb/ (ie. external HDD).

So, here is instruction:

1) Make eboot.bin with SDK & decrsdat.cpp & decrsdat.conf & decrsdat.build.
2) Edit decrsdat.lst with what files you want to decrypt.
3) Place compiled EBOOT.BIN in PS3_GAME\USRDIR
4) Place PS3_GAME folder on internal HDD
5) Run "game" and catch decrypted files on ext.HDD.

From 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 dissappoint you all.

Finally, if any other anonymous PlayStation 3 developers out there wish to have us share your work feel free to Contact Us or PM Me and we will be happy to do so of course!