12-08-2010 #11Banned User
- Join Date
- Mar 2008
nice one, i hope you will improve it and make it more better
deanrr was just looking at the code, he didn't test it personally..
To clear up some confusion for those who don't understand where to put their dev_flash:
X:\cfw\dev_flash <- Place all files from dev_flash here
X:\cfw\dev_flash\cfw <- Empty folder needed for removing the CFW so you don't have to restart the PS3 to test multiple times.
I will eventually just run a recursive search for a dev_flash folder on any device (except dev_flash itself).
12-08-2010 #14LOL at the suggestion that my app could brick a console. Try not to make stuff up when posting, especially when you don't know what you're talking about.
I have a PS3, I've even posted a small library for it already and a few other apps. I simply don't have access to mine until Monday. Don't make baseless assumptions.
Anyway, apps should run at least ONCE before make it public. I don't know any dev who give stuff to public without testing!
And one last thing, i respect your work and efford but test it anyway next time.
We don't even have permanent write access to the PS3's firmware right now, I couldn't write a bricking app if I tried.
Obviously I'd have tested it if I had the chance, but I don't until monday. The source is extremely simple, it should work anyway, so I see no problem in releasing it.
I wouldn't release toilet paper before i test it myself. Seriously , even if it's simple and could not brick something you need to verify your app before release.
The problem was that if you use PL3 to redirect /dev_flash to /1234_456 you also get /dev_flash2 and /dev_flash3 redirected to /1234_456.
It is possible that the payload I was using had issues (I reverted to hermes4b) but one flavor of the PL3 implementation didn't work as expected.
I mean it WORKED by replacing the table and /dev_flash with the new path, but one has to take care for other flashes because they share the SAME names (up to the 2/3).
12-08-2010 #18Banned User
- Join Date
- Jul 2008
Hmmm... nice one... but i can smell something that maybe in near - near future we will not need this CFW/USB/Firm loaders any more.
Could be a hacked installable .pup.
Isn't this simply a case of the string that is being matched?
If the syscall used to replace the path isn't specific enough then "/dev_flash" could match with "/dev_flash", "/dev_flash2" and "/dev_flash3" (Proof of this would be if you replaced "/dev_flash" with "/test" and found that flash 2 ended up being "/test2")
So surely the all round solution would be to replace the path "/dev_flash/" as it is more specific and would only match with "/dev_flash/" - it won't match with "/dev_flash2/" ?
Maybe i just missed the point entirely - but being a windows programmer i wouldn't be at all suprised!
(I'm assuming the syscall usage is kinda like a string Replacement) ?
p.s. That is of course assuming /" isn't some kind of escape character!
Originally Posted by KaKaRoToKS