Sponsored Links

Sponsored Links

Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21



  1. #11
    Banned User
    Join Date
    Mar 2008
    Posts
    303
    Sponsored Links
    Sponsored Links
    nice one, i hope you will improve it and make it more better

  2. #12
    Registered User ben2005's Avatar
    Join Date
    Dec 2010
    Posts
    12
    Sponsored Links
    Sponsored Links
    deanrr was just looking at the code, he didn't test it personally..

    Cheers
    Ben2005

  3. #13
    Registered User n4ru's Avatar
    Join Date
    Sep 2010
    Posts
    69
    Sponsored Links
    Sponsored Links
    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).

  4. #14
    Registered User modmate's Avatar
    Join Date
    Sep 2010
    Posts
    453
    LOL 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.
    Then LoL back to you... It was just an idea of what could happen... Remember that PsP emulator??

    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.

    Greets Modmate
    Last edited by modmate; 12-08-2010 at 01:46 PM

  5. #15
    Registered User n4ru's Avatar
    Join Date
    Sep 2010
    Posts
    69
    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.

  6. #16
    Registered User modmate's Avatar
    Join Date
    Sep 2010
    Posts
    453
    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.

    Greets

  7. #17
    Senior Member deank's Avatar
    Join Date
    Oct 2010
    Posts
    1,018
    Quote Originally Posted by n4ru View Post
    It IS very simple. There's no reason that at least the mounting part shouldn't work.

    I'm not sure why it's not working for you, but I know that with at least syscall35 there is no problem in mapping dev_flash, I've tested simply mounting usb003\cfw\dev_flash to dev_flash and it worked perfectly. Are you referring to using syscall8 to mount dev_Flash?
    You said you didn't test it and now you say you did. I actually didn't because I don't need to (I have a working solution with configurable paths, etc).

    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).

  8. #18
    Senior Member cfwprophet's Avatar
    Join Date
    Jul 2008
    Posts
    1,815
    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.

  9. #19
    Senior Member PSPSwampy's Avatar
    Join Date
    Jun 2005
    Posts
    795
    Quote Originally Posted by deanrr View Post
    You said you didn't test it and now you say you did. I actually didn't because I don't need to (I have a working solution with configurable paths, etc).

    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).
    Forgive me if this is wrong - i've not done any work on PS3 or linux coding and don't know much about the syscalls etc but...

    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!
    Last edited by PSPSwampy; 12-08-2010 at 05:41 PM

  10. #20
    Registered User n4ru's Avatar
    Join Date
    Sep 2010
    Posts
    69
    Quote Originally Posted by deanrr View Post
    You said you didn't test it and now you say you did. I actually didn't because I don't need to (I have a working solution with configurable paths, etc).

    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).
    I never said I tested this app, I said I tested mounting dev_flash from usb003.

    Quote Originally Posted by PSPSwampy View Post
    Forgive me if this is wrong - i've not done any work on PS3 or linux coding and don't know much about the syscalls etc but...

    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!
    You're absolutely right. As I was reading dean's last post I recalled a conversation I had with KaKaRoToKS and he told me the following:
    Quote Originally Posted by KaKaRoToKS
    and no, it doesn't support wildcards, but you could map /dev/path/ICO to replace all ICO* files..

 

Sponsored Links
Page 2 of 3 FirstFirst 123 LastLast
Advertising - Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News