So Whats the difference with Waninkoko 3.55 and WutangRZA's 3.55 CFW?

[empirexdude]

Hi guys, so I have the Geohot 3.55 CFW on my FAT Ps3 and I hear that with Waninkoko 3.55 it allows Backup Managers to run games like Call of Duty Black Ops online and stuff. Does WutangRZA's CFW do the same thing as the Waninkoko 3.55? I'm quite confused haha, and as far as I know the Waninkoko 3.55 CFW isn't compatible with my model of the ps3 since its 256MB Nand.

I would love to know and will upgrade to WutangRZA's CFW if it works as Waninkoko's. Thanks!!

[Qraze]

don't get wankoff's cfw no matter what you hear about that one guy who got it not brick his fatty phat playstation.

Wutangs though i have high hopes for but as of yet we really need to wait to see if any goodies are programmed to use the features it has. just ridw the storm out like me and don't jump in until you have read and learned all the downsides and good sides.

right now, the only worth a shit for 3.55 is the geobreak firmware.

[empirexdude]

don't get wankoff's cfw no matter what you hear about that one guy who got it not brick his fatty phat playstation.

Wutangs though i have high hopes for but as of yet we really need to wait to see if any goodies are programmed to use the features it has. just ridw the storm out like me and don't jump in until you have read and learned all the downsides and good sides.

right now, the only worth a shit for 3.55 is the geobreak firmware.

Yeah that's pretty much what I'm thinking so far until Waninkoko fixes his 3.55 CFW and finally make it work on 256MB Nand flashes. Thanks.

[empirexdude]

Anyone???

[chesh]

Ok, if the above wasn't enough (as you're still asking what the difference is):

Waninkoko's CFW: Played with the memory space of lv2. This is a big no no. The reason he did so was to fit the PL3 payload right in the lv2 space so that it would be loaded on startup. What does this mean to you? Dongleless JB that has all the needed syscalls for backup loading.

Wutangrza's (fluke's) CFW: Took a hash check out of lv1 memory that was preventing editing of lv2 memory. Now that we have access to lv2 memory, we can "poke" code directly into the running system. What does this mean to you? It means that without actually changing the size of any of the important parts of the firmware, we have full access to the memory again. With this, developers can push needed code right into memory to make different functionality of their programs work. Ex. Poke the syscall into memory in an empty space so that the BM can use it to load backups (much safer!).

Right now, no one has written the appropriate code to poke the syscall into memory for the Wutangrza (fluke's) CFW. Until that is done, there won't be a BM that works appropriately on that firmware.

[empirexdude]

Thank you! That makes a lot more sense. I appreciate it, will wait it out for a BM then.

[trueicecold]

Ok, if the above wasn't enough (as you're still asking what the difference is):

Waninkoko's CFW: Played with the memory space of lv2. This is a big no no. The reason he did so was to fit the PL3 payload right in the lv2 space so that it would be loaded on startup. What does this mean to you? Dongleless JB that has all the needed syscalls for backup loading.

Wutangrza's (fluke's) CFW: Took a hash check out of lv1 memory that was preventing editing of lv2 memory. Now that we have access to lv2 memory, we can "poke" code directly into the running system. What does this mean to you? It means that without actually changing the size of any of the important parts of the firmware, we have full access to the memory again. With this, developers can push needed code right into memory to make different functionality of their programs work. Ex. Poke the syscall into memory in an empty space so that the BM can use it to load backups (much safer!).

Right now, no one has written the appropriate code to poke the syscall into memory for the Wutangrza (fluke's) CFW. Until that is done, there won't be a BM that works appropriately on that firmware.

Thanks for the explanation, I was thinking of opening a new thread with some question, but while we're at explaining stuff, maybe I'll have a go in here:

Wutangrza + Geohot Patch - BM = OFW3.55 + Geohot Patch, right? at least until we have a working BM. Right now I have OFW3.55 with Geohot patch, so I can remain in it until I have a real reason to move from this? or is there an added value for Wutangrza's CFW as of now?

[chesh]

Nope, you're correct with your assumption. You're essentially in the same boat as Geohot MFW w/o a BM. Though, the BM is going to need Fluke's (Wutangrza's) CFW in order to work (because of the peek/poke support).

[trueicecold]

Nope, you're correct with your assumption. You're essentially in the same boat as Geohot MFW w/o a BM. Though, the BM is going to need Fluke's (Wutangrza's) CFW in order to work (because of the peek/poke support).

This I understand, and when the time comes, I'm going to upgrade to Wutangrza's CFW. Until a working BM is out for his FW, I'd rather not risk anything

Thanks a lot

[TitaniumL]

Ok, if the above wasn't enough (as you're still asking what the difference is):

Waninkoko's CFW: Played with the memory space of lv2. This is a big no no. The reason he did so was to fit the PL3 payload right in the lv2 space so that it would be loaded on startup. What does this mean to you? Dongleless JB that has all the needed syscalls for backup loading.

Wutangrza's (fluke's) CFW: Took a hash check out of lv1 memory that was preventing editing of lv2 memory. Now that we have access to lv2 memory, we can "poke" code directly into the running system. What does this mean to you? It means that without actually changing the size of any of the important parts of the firmware, we have full access to the memory again. With this, developers can push needed code right into memory to make different functionality of their programs work. Ex. Poke the syscall into memory in an empty space so that the BM can use it to load backups (much safer!).

Right now, no one has written the appropriate code to poke the syscall into memory for the Wutangrza (fluke's) CFW. Until that is done, there won't be a BM that works appropriately on that firmware.

Problem is, as Deank stated, no one of the payload makers, whether hermes or kakaroto or whoever, want to cooperate and give aid to backup creators and tell them what to do etc. I'm not sure why they're doing so.