Sponsored Links

Sponsored Links

Page 5 of 5 FirstFirst ... 345
Results 41 to 49 of 49



  1. #41
    Banned User SenorPickle's Avatar
    Join Date
    Aug 2005
    Posts
    11
    Sponsored Links
    Sponsored Links
    Quote Originally Posted by waleed View Post
    noob here, what does that mean and what outcome can happen for end users?
    Advice: Read the entire thread before asking a question that was already answered. That way you don't look like a dumbass.

    Actually I take that back, you quoted the answer you were looking for when you posted your question. If you don't understand what "running unsigned code from the XMB" means perhaps you should do some googling.
    Last edited by SenorPickle; 03-16-2010 at 10:05 PM

  2. #42
    Contributor Raze1988's Avatar
    Join Date
    Dec 2009
    Posts
    221
    Sponsored Links
    Sponsored Links
    Oh wow, once again all eyes are upon CJPC and his team

    But it's really interesting that things like that turn up out of nowhere. Shows that the "well known" PS3 sceners aren't the only ones who can achieve something.

  3. #43
    Banned User r3pek's Avatar
    Join Date
    Feb 2007
    Posts
    54
    Sponsored Links
    Sponsored Links
    Quote Originally Posted by PS3 News View Post
    CJPC said he would once the missing details are available (what the read/write u32 functions are, which functions to add to the XorHack, etc) so no worries.
    Don't think there's anything to add to XorHack's code. Just compile a new module to be "modprobed" after the hack is done (i'm not sure even if the hack has to be done).

    anyway, read_uXX(in_address) reads a 32/64 bit value from in_address. write_uXX does the exact opposite. The problem you have are not the functions, it's the constants SPU_PX(XXXXX), but they could be already defined in the kernel, really don't know...

  4. #44
    Toucan Sam CJPC's Avatar
    Join Date
    Apr 2005
    Posts
    2,174
    Quote Originally Posted by r3pek View Post
    Don't think there's anything to add to XorHack's code. Just compile a new module to be "modprobed" after the hack is done (i'm not sure even if the hack has to be done).

    anyway, read_uXX(in_address) reads a 32/64 bit value from in_address. write_uXX does the exact opposite. The problem you have are not the functions, it's the constants SPU_PX(XXXXX), but they could be already defined in the kernel, really don't know...
    Actually the SPU_PX() is defined in the released code - however, both read/write_u32 do need to be added in to XorHack - namely the author says it does, plus it's not there.

    But the hack does need to be done first, as xorlosers code provides the nice set of tools to interact between kernel and user mode, and adds in functions that the SPU isolation code calls.

  5. #45
    Banned User r3pek's Avatar
    Join Date
    Feb 2007
    Posts
    54
    Quote Originally Posted by CJPC View Post
    Actually the SPU_PX() is defined in the released code - however, both read/write_u32 do need to be added in to XorHack - namely the author says it does, plus it's not there.

    But the hack does need to be done first, as xorlosers code provides the nice set of tools to interact between kernel and user mode, and adds in functions that the SPU isolation code calls.
    Ok, then it's solved

    I suppose that those functions are for I/O i can only program them on x86/64 asm... not ppc asm... If you stil want them, just post

  6. #46
    Contributor MimmoD360's Avatar
    Join Date
    Mar 2010
    Posts
    16

    What next?

    I would like to know what's the next step in order to run unsing code has isoloader or homebrew

    Thx

  7. #47
    Senior Member SCE's Avatar
    Join Date
    Jan 2009
    Posts
    172
    Quote Originally Posted by MimmoD360 View Post
    I would like to know what's the next step in order to run unsing code has isoloader or homebrew

    Thx
    Instead of consuming your time with subscribing, you should have read the entire thread to get the answer.

  8. #48
    Contributor DaweedFTW's Avatar
    Join Date
    Feb 2010
    Posts
    8
    Quote Originally Posted by MimmoD360 View Post
    I would like to know what's the next step in order to run unsing code has isoloader or homebrew

    Thx
    Looks like we're quite far far away from running unsigned code, at least on every unit. My guess is that we first need to dump lvl2 gameOS, reverse it to find exploitables holes, use a hole to software-kick isolated SPU and replace it with a custom one that would automatically "validate" each pkg/self thrown at it.

    We are not yet having the lvl2 dump, so there's still a loooong way to go for a simple hello world, and the dev most prolly are working on the second step toward the full hack of the PS3 (the first one being geohot exploit to R/W ram), dumping GameOS.

    Just wondering, and maybe CJPC can tell, if it wouldn't be easier, once the lvl2 hole is found, to have some sort of "re-signed" firmware update to convert every retail PS3 to a debug/test unit, with the possibilities it would offer.

  9. #49
    Member Siggy12's Avatar
    Join Date
    Oct 2009
    Posts
    112
    Quote Originally Posted by DaweedFTW View Post
    Just wondering, and maybe CJPC can tell, if it wouldn't be easier, once the lvl2 hole is found, to have some sort of "re-signed" firmware update to convert every retail PS3 to a debug/test unit, with the possibilities it would offer.
    Yeah .. I'm totally agree... for me CJPC know very well debug and tool firmware so for him will be very easy convert a retail in a debug system or find a hole for execute code in a retail firmware, I hope that we will have LV2 dump very soon.

 
Sponsored Links

Page 5 of 5 FirstFirst ... 345
Advertising - Affiliates - Contact Us - PS3 Downloads - PS3 Forums - Privacy Statement - Site Rules - Top - © 2015 PlayStation 3 News