[poorguy]

Originally Posted by tjhooker73 It wouldn't work The spoofed file would need the keys from 3.60+ too.

tjhooker73 is right. the method you are referring to used to work on the samsung bada 1.2 platform but even that was later patched by the 2.0 update and u need a proper cert to resign the packages. therefore the KEY factor is important.

[DEFAULTDNB]

http://en.wikipedia.org/wiki/NOP_slide

[JustThatDude]

Originally Posted by DEFAULTDNB http://en.wikipedia.org/wiki/NOP_slide

Thats basically what I'm talking about maybe we could split it then grab the keys because they are decrypted in the system correct? If we were successful at splitting, wouldn't the keys be decrypted once we run a pkg and all we would have to do is extract them while its running or is that impossible. Also whatever happend GitBrew decrypting the meldr and bootldr back in the good days

[DEFAULTDNB]

Split is not the correct word here.

NOP slide principle would require a vulnerability, after which it redirects to a known area rather than crash.

Your principle is to replace files called by an eboot? I'm unclear on "splitting"

Do you mean (for example) swap a 3.60 eboot with a donor 3.55 one, and hex/edit the 3.55 one to point at known 3.60 files? Essentially using the 3.55 eboot as a signed shell?

I doubt this would work.

[JustThatDude]

Originally Posted by DEFAULTDNB Split is not the correct word here. NOP slide principle would require a vulnerability, after which it redirects to a known area rather than crash. Your principle is to replace files called by an eboot? I'm unclear on "splitting" Do you mean (for example) swap a 3.60 eboot with a donor 3.55 one, and hex/edit the 3.55 one to point at known 3.60 files? Essentially using the 3.55 eboot as a signed shell? I doubt this would work.

Completly what your talking about but we wouldn't know until we try. In all essence looking at it it doesn't seem hard to do we just need to know where all the stuff is and knowledge to do it. If someone has an idea and we are not close to homebrew why not try other way like this.

[DEFAULTDNB]

Cool, I understand now.

I have looked on devwiki about how eboots/selfs work, and paths within eboots, but I continue to find nothing useful.

@euss will know exactly where to look, he has encyclopedic knowledge of PS3 wiki.

what is interesting is:

* 0x1C retail (4.20-) * 0x1D unknown (npdrm1?) * 0x1E unknown (npdrm2?)

from: http://www.ps3devwiki.com/wiki/SELF_...and_Decryption under ~SCE header struct....

[JustThatDude]

Originally Posted by DEFAULTDNB Split is not the correct word here. NOP slide principle would require a vulnerability, after which it redirects to a known area rather than crash. Your principle is to replace files called by an eboot? I'm unclear on "splitting" Do you mean (for example) swap a 3.60 eboot with a donor 3.55 one, and hex/edit the 3.55 one to point at known 3.60 files? Essentially using the 3.55 eboot as a signed shell? I doubt this would work.

And by spliting i mean replacing the eboot like you said. Now im just throwing this one in the ballpark what if we used No_One idea but look elsewhere if we can NOP slide then we could possibly extract the keys in its process. Again just saying I just like to throw around idea's cause who knows it could work.

[JustThatDude]

Originally Posted by DEFAULTDNB Cool, I understand now. I have looked on devwiki about how eboots/selfs work, and paths within eboots, but I continue to find nothing useful. @euss will know exactly where to look, he has encyclopedic knowledge of PS3 wiki. what is interesting is: from: http://www.ps3devwiki.com/wiki/SELF_...and_Decryption under ~SCE header struct....

Yeah I wouldn't have any idea or skills on how to look into that stuff. Just a stoner over here. Most i have done is create a iso for World at War and Gta 4 lol

[DEFAULTDNB]

Originally Posted by DEFAULTDNB NOP slide principle would require a vulnerability, after which it redirects to a known area rather than crash. /snip I doubt this would work.

Without a vulnerability NOP slide is useless afaik.

I once spoke to comex about SSBB expliot on wii and he explained nop slide to me. You need to find a vuln that you can padd out and exploit.

I dont think hypervisor will allow this to happen. Kind of like how the tiff header exploits of psp fame used to work. Sony learned from this.

[JustThatDude]

Originally Posted by DEFAULTDNB Without a vulnerability NOP slide is useless afaik. I once spoke to comex about SSBB expliot on wii and he explained nop slide to me. You need to find a vuln that you can padd out and exploit. I dont think hypervisor will allow this to happen. Kind of like how the tiff header exploits of psp fame used to work. Sony learned from this.

Maybe thats how TB did it they found a vunerbilaty and a idea like NOP to run games above 3.56 FW hell NOP could be our answer to some of our games not working on higher FW