Discussion in 'Ps3Xploit [Official Forum]' started by esc0rtd3w, Dec 18, 2017.
Practically too, it's easily done!
bguerville thank you for useful information!
@esc0rtd3w did a test on v005-TEST-VERSION-2 4.81 DEX,after a successful initialization beep test freezing.
Ive been trying these versions with little success . I'm on 4201a 4.82 which should be eMMC. But with v8 i still couldn't get it to work 100% then I tried selecting NOR instead of emmc and it works nearly 100% of time.
Beep, power lights mount hard drive, read/write, etc... still a few lock ups on some stuff. But hey I'm getting happy.
I figure it some program error that you must select nor instead of emmc. Just reporting bugs i find.
Anything else I can test on emmc 4.82 4201a ?
Everything you mentioned ie beeps, leds, hdd mount, file read/write stuff is entirely unrelated to the flash memory type in use.
Nor/nand/emmc only matters when it comes to accessing the flash memory area like we do for dumpers & flasher. In over 99% of other cases, it's mostly irrelevant.
We I don't know then.
It's getting nearly 100% success rate now getting execute chain to pop up compared to 1 out of every couple of hours (many hours) . And i haven't changed any other settings or the way I try to get excute chain button.
So it's finding offsets ALOT better !
I dunno how the code is now set up in the test file tbph, I assume that it's using a different chain for different flash type for part of the features that use the flash memory.
Like I explained before, different chains = different initialization success rates.
Tut chains might need separated in a more efficient way..
currently the flash type checkboxes just sets a flag. this can be used to determine if needed. it is also used to setup custom search params, if needed for different flash types.
the stackframe is the same for any chain used. the dropdown boxes and other GUI options just set params that are used in a case statement to set values before init. the success rate should be the same. no matter which chain used, although not 100% confirmed!
the most recent versions will show when searching and verifying, separately, to see where the stalling is happening, if any. also stackframe verify is off by default, but can be enabled by checkbox.
all flash types are currently using the same setup though, no matter which is chosen
Yep hence the issue I think.
I think the best way would be to make all tut features independent from each other but keeping the option to merge any of them together in one chain if required.
This way you will get efficient initialization with shorter chains overall.
Created a pull request on github for french translations hope it helps ,Thank you for all the hard work I'm waiting for the next video on youtube big fan !
a live version can be viewed here https://humanshield89.github.io/pett
@humanshield85 thank you. it has been added
Hi everybody. Before i write here, i read and followed many many tutorials on the web, and obviously the hard work of @esc0rtd3w .
I tried a lot with my PS3, a superslim cech4004A, with OFW 4.82. I made all the stuffs from the russian team from pspx ru, i converted a game with updates, made backup under TrueAncestor 2.20 / 2.30, made all stuffs with PETT 0.1.4 . After all i run chain button..read "Success!" ..so execute..and all's ok. But when i close browser and try to open game ( i tried FIFA18, F1 14 , mostwanted, Farming Simulator 15) i read error 80010006 . All the adresses /dev_hdd0/game/npub.... are correct, i saw that after extract backup with my IDPS.
Help me dudes!!! Thanks for all your hard work
Did you inject edat file after you restored backup?
Farm simulator 15 works
Sure man, with PETT 0.1.4
Bro, this thread is not to talk about loading backups.
First of all this thread isn't about loading backups
Second of all ,if the file got transferred to your ps3 then the tool provided in this tutorial has done his job and there is no thing more to say here
third of all if you search the error code you will find this https://www.playstation.com/en-gb/get-help/help-library/error-codes/80010006/ according to sony this error happens when :
"There was a problem accessing the file"
this means either
- your hard drive is corrupted or files are corrupted (highly unlikely but still possible)
- your game backup is corrupted (recheck it )
- your game backup has files that was modded and resigned since you are under OFW that will throw this error
so check your backup integrity (hint : download the ird for your game and check it with ps3 ISO rebuilder
hope this helps
I am sorry if answering this question here is against the rules
This error occurs just because the file was not transferred. The system does not find it, because it is missing. When you transfer a file, you need to specify its size exactly, after you have exposed the source and destination paths.
I'll try all these stuff, specially this things of file size in hex, i tried with 0x10400 and 0x10190. whatever, Dudes, i appreciate all your helps, i'm really grateful to all of you. Sorry for my off topic, i didnt know that. If I can help someone with my experience...I'm available to do!!!
since he said his lic.edat were in fact in his ps3 (he said he pulled a backup and checked with his idps) i don't think that's the problem
and the Error is not just because a file is not found ,because I used to have this error with my Cobra ODE when I used moded backups specially "duplex" versions ,that's why i learned to make my own backups and check their integrity before use (way in the days where cobra didn't need a swap ,swap lol the whole point was playing games whithout the need to get up and change the disk xD yep i'm that lazy )
anyway @superhoe13 ,I think you will get better assistance if you ask here http://www.psx-place.com/threads/4-...new-method-for-injecting-backups.11480/page-5 just to keep this thread clean for our fellow devs and hackers
Believe me, I know what he's talking about and I know that in this case the file is not found. Because he did not send this file to his destination. He does not even know what size to write 0x10400 or 0x10190 or 0x10140, although there is no need to guess, but simply enter the real size of the file that he decided to transfer.
The size can be written as in decimal form (for example 65936), and in hexadecimal (for example 0x10190). And if you do not write the actual file size, the program will still answer Success! But in fact the file will not be transmitted. Hence the error, because there is no file there.
Separate names with a comma.