Page 65 of 87 FirstFirst ... 155564656675 ... LastLast
Results 641 to 650 of 863

Thread: Rumor: PS3 JailBreak 2 v3.55 Dongle Plays v3.60+ Game Backups?

  1. #641
    Ezio Guest
    I suppose the upcoming True Blue dongle firmware updates will be only directed to protect the dongle from clones.

  2. #642
    Bartholomy Guest
    Yep. New CFW and new updates are mostly against clones.

    11 - 1 – 2012

    Just a quick update to let everyone know that yes, we are still alive and we apologize for the slowed pace of releases over the holiday period and any inconvenience this may have caused our valued customers. Our entire team is now back to work after the holiday break, working hard to prepare the next round of EBOOT releases which will include some highly anticipated titles. Stay tuned for further updates.

    -True Blue Team

  3. #643
    Karl69 Guest

    Does anybody here have access to a USB sniffer and could send me a log of the TB?



  4. #644
    Bartholomy Guest
    Quite an expensive toy, an usb sniffer. A serious one, i mean. Neither on the wiki something is posted, so maybe you got your answer

  5. #645
    Karl69 Guest
    I know, mate... But I remember when the first JB came out, USB logs were available a short time later...

  6. #646
    RiseOfCthulu Guest

    How to pwn TB dongle the easy way

    hello ... I can't believe the true blue dongle hasnt been open sourced yet ... seems sony could learn some things from the true blue team regarding drm and how to secure a product ...

    do you guys remember the dev "descrambler" who sniffed the first ps3 jailbreak device via usb sniffer .. (yeah it was reversed before but it helped a lot ...)

    I know usb sniffers are very expensive (300 $) so there has to be another way to do it ... so here is my idea ....

    just take the Rebug TB CFW and patch it to support linux ... mfw builder will get a key error so you have to do it "oldschool" ... shouldnt be that hard ... after patching it, just resign the pup und update your console ...

    install a linux distribution of your choice and then follow this Tutorial: to sniff the usb traffic on the port with the dongle ...

    put your log (the USB protocol) on the wiki and see what happens ..

  7. #647
    Join Date
    Apr 2005
    I have now merged your post into this thread, as it is our ongoing one for that topic.

  8. #648
    DeVil3o3 Guest
    Intresting info, I didn't know linux had built in USB sniffing. Why hasn't this been done already, where all the hackers when you need em. This sounds like even I could do it if I owned a TB and could figure out how to patch Rebug TB FW... on second thoughts i'll leave it to the pros on here instead, lol!

  9. #649
    Join Date
    Apr 2005

    Post Guide to Ripping and Burning Your True Blue Disc Games

    Below is a Guide to Ripping and Burning your True Blue Disc Games from GraVoX via:

    This is SO easy I can't believe no one has done it already! Follow these steps EXACTLY and you can backup your disc games. You will see your precious ISOs pop up in the regular places in the next day or two.

    I must state that I don't own a True Blue dongle, or any of their discs. Sorry for cutting into your cash cow guys, its nothing personal! Information should be free!
    • Install KMEAW CFW
    • Install multiMAN 2.09.00 or later, BDEMU is not required
    • Start multiMAN
    • Go to "SETTINGS"
    • Press [TRIANGLE]
    • Enable DIRECT DISC ACCESS mode
    • Insert the TB Disc
    • Wait for mm to detect it -> it will show in the GAME column
    • Press [SELECT]+[START] to switch to FILE MANAGER
    • Open /dev_hdd0 in the RIGHT pane and go to a folder where you'll backup the ISO
    • Put the mouse pointer over /dev_bdvd on the LEFT side
    • Press [CIRCLE]
    • Select "Create ISO"

    Once that has finished, transfer the ISO to your PC Then follow the tutorial by Mark Webber attached below. Pr0fit!

    Download: DECRSDAT.PKG (SDAT PKG Decrypter for PS3) by Asmodean

    EDIT: Also with TB ISO the Burning tools will show an error because of the modified TB files, ignore it

    A few shoutouts, djbubba for first capturing my attention with this and then trying to screw me over at every turn! My anonymous friend for pointing out this has been a feature of multiMAN for AGES! Naughtydog for actually following the method I had posted at least 5 different times and confirming it works.

    Mark Webber for his second half of the tutorial. Blame him for making me laugh my butt off on MSN and delaying this further. DeanK for multiMAN, its awesome! Graf for his work on the hypervisor and documenting everything that has made this possible! Lastly My own head for holding up when I banged it against a wall, trying to get help from the same people who whined about paying for discs!

    Finally, from deank: Actually that's not entirely true. Anyone who knows anything about programming (pc/mac *nix ps2/ps3) would spot discrepancies. I'll try to put a very noob-friendly explanation below.

    We can drop the big-ass words like SPRX/SELF/EBOOT.BIN and just use "executables" (selfs/elfs/eboot.bins) and "libraries/modules" (sprx/prx). To make it even easier to understand one can think of the executables as "EXE" and the libraries/modules as "DLL" in the windows environment.

    Anyway, when talking about the SPRX you may have to differentiate GAME sprx files and FIRMWARE sprx files, because they are a bit different, because of the way they're used.

    Yes, we did - even the ebootFIX / ebootMOD applications process all game sprx+self+eboot.bin files - otherwise nothing would work. Since you can think of a game sprx file as a DLL, it is just a number of functions exported in a separate file, so you don't have to load all of them along with your executable (EBOOT.BIN or blabla.exe). Whenever you need a function from the (sprx/dll) library - you load the library, call the function and unload the library. That's all about the game sprx files.

    The firmware sprx files... The explanation above can be used for these too, but the main difference is that all applications use these system-wide libraries. It could be games, the video player, the PS Store application or the photo-album slideshow. So each of these applications would at one point load a firmware sprx/library because it needs its functions (to access files and folders, to access the network, to process jpg/png images, to read/mount/use psarc archives).

    Let's for a moment forget about keys and encryption, and focus on firmwares and the differences between the libraries/sprx.

    We have a console (we name it THE_BOX), running firmware version 3 and we create an application for it, which prints a fancy text on screen. Such imaginary application will look like this:

    Load system module: lib_screen.sprx (so we can use its functions)
    Load system module: lib_text.sprx
    Initialize screen: using init_screen(1920, 1080, 3D) function from system library lib_screen.sprx)
    Draw fancy text: using draw_text(x, y, "Hello World", red_color, vertically, with_water_effect) from system library lib_text.sprx
    Wait for 30 seconds and exit

    So we test our cool app on firmware version 3 and everything works as expected: a nice text is drawn in fullHD in 3D mode and has a nice water shader applied to it, so it really looks like made of water.

    By accident we have a second console (THE_BOX_2), running firmware version 1 (rather old, but we need to test nonetheless). We load our cool app and launch it then we get:
    • Black screen or
    • Not so cool looking "Hello World" text in 2D, horizontally and not vertically, with the dull gray color and no effects applied).

    What happened?!

    We know that THE_BOX_2 is running an older version of the firmware and PROBABLY (most definitely) some internal/system modules are quite different. After a later investigation we find that the firmware version 1 has these two sprx libraries, but they provide much limited functionality:
    • init_screen(1920, 1080) (it is missing the 2d/3d parameter)
    • draw_text(x, y, "Hello World") (no extended parameters)

    It is pure miracle that our sample app even started on that OLD firmware version 1 and produced any results at all.

    That should explain why FIRMWARE LIBRARIES (SPRX in the PS3) may affect games, performance and compatibility.

    Now back to the reality. Back in the day (and even at the moment) there are games released for firmwares beyond 3.55, but we were still able to play them on 3.55. In most of these cases the games didn't require nor used any special functions presented in the system libraries/modules of the newer firmware. Luckily even now with the PS3 firmware 4.00 there are games, which use the same functions that are available in the modules/sprx of FW 3.41-3.55.

    So let's say we have the keys and the game in question doesn't use any of the firmware 4.0 functions - we process our 4.0 game with some tools and we get decrypted (from 4.0) + changed + encrypted/signed (for 3.55) all the eboot.bin/self/sprx fiels. Profit. Game works on 3.55.

    Now we find another game and apply the same steps as above. But it happens that that particular game (like most that will follow) actually uses the NEW functions provided by the NEW modules/sprx files in the new firmware 4.0. We test that game and we find that it either doesn't start at all (black screen) or starts with major glitches, locks after 2mins, etc. etc.

    So we decide to make everything right. Since we're really experienced, we're going to find what SYSTEM modules from fw 4.0 that particular game requires. It is obvious that our 'stock' sprx files miss some functions and we have to find a way to add them or just use the newer module (hoping it won't brake any other app installed on your loved ps3). We start looking at the game executables (eboot.bin/self) and game libraries (sprx) to find what modules are used.

    Of course these are not listed in plain text and most of the time you may not even see anything readable, but you'll have to find the actual assembler functions which call for loading system modules with specific IDs. After couple of days/weeks we find all of the module IDs, so now we know which modules need to be replaced or further edited (because the usually call/use functions from OTHER system modules).

    Once we're absolutely sure we've got all that right, we sign (and encrypt if desired) the files for our THE_BOX_2 console (running the older firmware) and we enjoy the result.

    Now back to the keys. Since the "S" in SPRX and SELF means "Signed" one must find a way to remove the protection of these system sprx files, of the game sprx/self/eboot.bin files and then work with their contents. Once you finish, you sign them again for your desired firmware with the desired keys (be it for 3.41, 3.55 or 4.0).

    That's about it.

    I don't own a TB dongle and the reason I posted this wall of text is to present a REALLY SIMPLIFIED explanation of what one may have to do EVEN if he has the keys for 4.0 firmware.

    Not to dare or challenge anyone, but all of you have the opportunity to prove yourself by installing firmware 3.15 to your PS3 and then try to process UNCHARTED 3 to work on it. Basically everything is the same. If you can make UC3 to work on FW 3.15 - you're a hero and the scene will love you.

    I hope it wasn't boring for you to read all that, but as a programmer and as someone who watched and learned I decided to clarify something that "anyone" should now.


  10. #650
    HeyManHRU Guest
    This is great news for TB users who want to play the original TB disc games (PES 12, FIFA 12, etc) since people will just upload the .ISO files and they can then burn it to a disc and play it. I just got one question though (for anyone who knows the answer), is it possible to burn the .ISO file to a DVD instead of a blu-ray disc? Because most people don't have access to a Blu ray burner.

Page 65 of 87 FirstFirst ... 155564656675 ... LastLast

Tags for this Thread

Posting Permissions

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