about cfw and 3.55

**Slynk** · 01-09-2011,10:29 PM

I wonder how hard it would be to put something in the load chain...

lv0->lv1->recover->lv2 ...

I mean is it as simple as finding where lv1 kernel hands off the reigns to lv2 and making a small recovery kernel that hands the reigns to lv2? Then the kernel is portable, someone could move it to lv0->recover->lv1 if they could decrypt lv0.

**Pockets69** · 01-09-2011,10:32 PM

yeah i was thinking about it, but is it feasable??

**flex360** · 01-09-2011,10:36 PM

wow nice
you should release a beta of the 3.41 :P

**Slynk** · 01-09-2011,10:41 PM

Originally Posted by Pockets69

yeah i was thinking about it, but is it feasable??

Should be... you find the way lv1 loads lv2... alter it to load the recovery... copy lv1's load method to load lv2 from the recovery. As for recovery... there's a lot of potential... test removable media for Lv2diag.self or just lv2kernel.self...

**Pockets69** · 01-09-2011,10:45 PM

and why not write the recovery to lv1 instead? meaning lv0--> recovery-->lv2

wouldn't that be much simplier, i mean we wouldn't need to use something in between like you said, but still i think your idea is great.

**Slynk** · 01-09-2011,10:53 PM

Originally Posted by Pockets69

and why not write the recovery to lv1 instead? meaning lv0--> recovery-->lv2

wouldn't that be much simplier, i mean we wouldn't need to use something in between like you said, but still i think your idea is great.

Because editing a file path in the kernel is safer than editing the kernel the add recovery support.

And putting it after lv0 is fine but as far as I know, we don't have the lv0 keys public. (I could be wrong about that though).

**Pockets69** · 01-09-2011,10:59 PM

ah you are right, so our best options would be lv0-->lv1-->recovery-->lv2

being the recovery a small kernel inbetween.

I am not able to do such a thing, but i am glad to know that it is possible, hope someone gets their hands on doing this.

**strictlyfocused** · 01-09-2011,11:10 PM

Originally Posted by moose123

Originally Posted by netkas

not me borked it, mine lv2 self for 3.41 worked fine.

So you already have a Jailbroken 3.41 firmware with the poke syscall? :o

THIS!

Ive got Multiman booting untethered on my 3.41 by copying the 3.55 signed eboot.bin over to the USRDIR. Sadly my external drive isnt visible and many games dont work. The missing puzzle piece to make everything work is peek/poke right?

**rdbrooks** · 01-09-2011,11:15 PM

Originally Posted by strictlyfocused

THIS!

Ive got Multiman booting untethered on my 3.41 by copying the 3.55 signed eboot.bin over to the USRDIR. Sadly my external drive isnt visible and many games dont work. The missing puzzle piece to make everything work is peek/poke right?

Peek poke may no longer be necessary as both deank and now riku have proven that games will work without it

**strictlyfocused** · 01-09-2011,11:24 PM

Originally Posted by rdbrooks

Peek poke may no longer be necessary as both deank and now riku have proven that games will work without it

But its still a viable option for users on 3.41, why put all the eggs in one basket?
We already know backup managers will work on 3.41 assuming a payload with peek/poke is used. On those grounds I would think that if peek/poke are put into 3.41 we should be able to run the backup managers without a dongle.
IMO this is HUGE for people on 3.41 if it works.

User Tag List

Thread: about cfw and 3.55

Tweet

LinkBack

Thread Tools

Display


	Would you like to get all the new info from PSX-Scene in your email each day? Subscribe to our Daily Digest! Want to learn more about the team keeping you up to date with the latest scene news? Read about them now! Check out our Developer bios, too!