This console are dex or retail console
WebKit ROP Chain Tutorials [Creation/Editing/Debugging] - PS3 Development
@esc0rtd3w i see this progress its amazing but iv been seeing lots of questions lately by friends and other mates on different forums but i cant answer by myself so i hope you answer will these testing files eventually turn to a hdd writer that will write any file from usb to hdd?
The million dollar question again?
You guys are relentless... Lol
Can it copy/move/delete files anywhere? Yes
Can it create/copy/move/delete folders anywhere?
Yes
But as you ask, here is my opinion on the hdd writer matter, unrelated to esc0rtd3w's efforts to share ROP data & techniques.
For starters, such a writer would only allow one operation at a time so far.. If you cannot exit ROP gracefully, without crashing or rebooting, you will never get a proper file manager as is...
Additionally, writing a real file manager in ROP would be a job for maniacs imho...
Like we said many times, ROP is not the best way forward at all. It should only be a stepping stone to run homebrew, not a replacement for it.
Homebrew execution must remain the object of our focus here, not a half baked file writer project in ROP...
And remember that this a tutorial thread to learn ROP basics, not a collective project leading to putting together a release...
Ulquiorra-Sama
Member
So to be even more clear, the HDD Writter itself will no make your PS3 run your Backups, wait for some homebrew.
Well, a file copier may help with certain things, you could customise the XMB for instance or even copy files DTU won't let you do.
But that changes nothing to the situation.
We cannot work on everything at once, there are priorities & this project is not considered worthy enough because we wish & strive for something much much better...
However, I said it before, if anyone wishes to take our work & elements of this tutorial to make a file copier, we would actually be delighted. esc0rtd3w is making it easy for anyone who wishes to learn...
To be perfectly frank, if anything, getting other people on board of this train is the ultimate reward, well that's how I feel anyway & I am guessing esc0rtd3w would agree... That's why he started this thread after all... Lol
@bguerville i get you bro you are saying that ROP is a waste of time to use for writing files and other stuff because its going to take a lot of time to be able to do such things with it and its a derail from the main project , you are saying we should use it to enable homebrew and then pretty much everything can be done faster and without ROP chaining so it will be much easier but i think @esc0rtd3w point if view is that making those videos and the hdd writer will cut down the questions being asked about the HEN progress because people will be busy running backups so then you guys will work freely on the main project (HEN) .
The purpose of all of esc0rtd3w's tutorials, related to ps3xploit or not, is to share knowledge & teach. Other considerations are all secondary.
People can ask as many questions as they want about hen & discuss it to death, as long as they create their own threads.
The only thing that matters to us is to contribute something worthy as well as bring more developers & development to our scene if ever possible.
I agree that @esc0rtd3w main purpose is to teach us those stuff and the best proof is those videos being made no other dev or user made videos on how to make a ROP chain to do anything with your ps3 or ps4 and as for you guys caring about bringing more dev and developments to the scene i think you guys already did a great job with that .
Whats great about @esc0rtd3w also is that he always finishes what he starts no matter what it is so those videos are important because they teach us how to become a developer and how to contribute to the scene i thank you guys for everything.
esc0rtd3w
Developer
so many comments in one day lol
first thing, i never care about backups running, ever! if anyone wants to pursue that, then all the resources are available to them, and as @bguerville said, ROP is not the best way to do anything!!! But it is very powerful!
@bguerville pretty much summed it up for the most part! we do have the same end goal, but he knows that i like to try random shit sometimes and wander a bit....idk why....curiosity haha
last note....ROP is super awesome and can do so much....who knew haha
@k9mo thanks for the kind words
first thing, i never care about backups running, ever! if anyone wants to pursue that, then all the resources are available to them, and as @bguerville said, ROP is not the best way to do anything!!! But it is very powerful!
@bguerville pretty much summed it up for the most part! we do have the same end goal, but he knows that i like to try random shit sometimes and wander a bit....idk why....curiosity haha
it already is technically an HDD writer...and its a tutorial, as stated....so you can actually use and edit this to test some stuff if you would like to write things!
yes
well...... i try haha
i like spewing knowledge lol
yes
yes, this is true, although it will inevitably create other things just from its pure nature
last note....ROP is super awesome and can do so much....who knew haha
@k9mo thanks for the kind words
Last edited:
U r console is dex
Apostol
Member
My console CEX
The unknown knight
Forum Noob
@esc0rtd3w watching some videos and reading your comments i realized that the db rebuilder writes 20 bytes to dev_hdd0/mms/db.err am i right? So can i change that path to say dev_hdd0/photos and change the 20 bytes being written to another file from usb?
esc0rtd3w
Developer
DB Rebuilder writes only 4 bytes
DB rebuild values loaded here (size shown with arrows)
the rebuild bytes variable is put in chain here at usb_fp
bytes are here
path is loaded here from /js/api/paths.js
path variable is added to chain here from /js/chains/loader.js
DB rebuild values loaded here (size shown with arrows)
the rebuild bytes variable is put in chain here at usb_fp
bytes are here
path is loaded here from /js/api/paths.js
path variable is added to chain here from /js/chains/loader.js
Last edited:
The unknown knight
Forum Noob
Great info bro i have a bit of experince in editing these ROP chains and this kind of stuff the question is if i edit this file now will it be able to write to the hdd i mean i can edit the path in 5 minutes but will it work?DB Rebuilder writes only 4 bytes
DB rebuild values loaded here
the rebuild bytes variable is put in chain here at usb_fp
bytes are here
path is loaded here from /js/api/paths.js
path variable is added to chain here from /js/api/loader.js
Thanks for this info your the greatest bro
Edit: taking a look at the info i see that editing the path that it writes to is very easy bro but i might have a problem with changing the bytes being written from 4 bytes to a file from usb (i guess the size of the file doesnt matter right??)
Last edited:
esc0rtd3w
Developer
i know the videos are not the best lol
i will add some text/pic info in spoiler to main OP soon to make things more clear and easier to follow along. I will keep it a bit more organized!
the bytes being written is also just a pointer to an address that reads this value.
about the path, it can be changed to anything in that variable, or make a new one.
it is recommended to use the end of usb_fp hex to add as many paths as you want (path_fp is first custom one that you should start with), or other hex. this way it does not interfere with the chain for gadget #1
the whole size of the usb_fp unescape hex is read from here (see below pic), so anything you append to end will add bytes to this for memory search
by setting the offset to match where it is from the beginning of usb_fp will allow you to set pointer addresses for other paths and data
i will be setting up the variables for some pointers and file descriptors in the template and you will be able to see more clearly when i get it updated!
last thing...you cannot set usb_fp additional pointers until after the search for usb_fp_addr has found the location in memory, by that i mean all usb_fp+0xXX must be done after the search is complete. before searching, the address wil be 0x00000000 and is not valid
something like this...this is untested thus far, but should work
i will add some text/pic info in spoiler to main OP soon to make things more clear and easier to follow along. I will keep it a bit more organized!
the bytes being written is also just a pointer to an address that reads this value.
about the path, it can be changed to anything in that variable, or make a new one.
it is recommended to use the end of usb_fp hex to add as many paths as you want (path_fp is first custom one that you should start with), or other hex. this way it does not interfere with the chain for gadget #1
the whole size of the usb_fp unescape hex is read from here (see below pic), so anything you append to end will add bytes to this for memory search
by setting the offset to match where it is from the beginning of usb_fp will allow you to set pointer addresses for other paths and data
i will be setting up the variables for some pointers and file descriptors in the template and you will be able to see more clearly when i get it updated!
last thing...you cannot set usb_fp additional pointers until after the search for usb_fp_addr has found the location in memory, by that i mean all usb_fp+0xXX must be done after the search is complete. before searching, the address wil be 0x00000000 and is not valid
something like this...this is untested thus far, but should work
Last edited:
The unknown knight
Forum Noob
Thank you very much for the info bro its really helpful .i know the videos are not the best lol
i will add some text/pic info in spoiler to main OP soon to make things more clear and easier to follow along. I will keep it a bit more organized!
the bytes being written is also just a pointer to an address that reads this value.
about the path, it can be changed to anything in that variable, or make a new one.
it is recommended to use the end of usb_fp hex to add as many paths as you want (path_fp is first custom one that you should start with), or other hex. this way it does not interfere with the chain for gadget #1
the whole size of the usb_fp unescape hex is read from here (see below pic), so anything you append to end will add bytes to this for memory search
by setting the offset to match where it is from the beginning of usb_fp will allow you to set pointer addresses for other paths and data
i will be setting up the variables for some pointers and file descriptors in the template and you will be able to see more clearly when i get it updated!
last thing...you cannot set usb_fp additional pointers until after the search for usb_fp_addr has found the location in memory, by that i mean all usb_fp+0xXX must be done after the search is complete. before searching, the address wil be 0x00000000 and is not valid
something like this...this is untested thus far, but should work
Right now i changed the path that its writing to it now should write to dev_hdd0/game ill be trying to change the bytes being written to an acctual file from usb but i might have trouble with that because i always had a weakness in that area of ROP ill post results later.
Thanks again for the info bro its really helpful
Edit:
Ok i give up i cant seem to know how to change the bytes being written but i changed the path that it writes to (its now /dev_hdd0/game) i noticed there is source path and destination path boxes in the index i see that only source is working so does source path means where the bytes that are being written come from if so i can change it to say /dev_usb001/NPEB1234 and i already changed the destination to /dev_hdd0/game so will it write the NPEB1234 from usb001 to the games folder on hdd ??
In other words if change the path it writes-to to dev_hdd0/game and then save path.js and then host the webkit on ps3 and then i select db_rebuild in the select ROP chain Hex and go to source path and type say /dev_usb001/NPEB1234 then will it write the NPEB1234 folder from usb to the game folder on hdd??
Edit 2: i get it now the source and destination path boxes are for the mem.dump not for the db_rebuilder in that case no other way but to change the path of the bytes being written to do that i just need to understand one thing which is the usb_fp_addr+0x2E does it mean that its writing the offsets 0x2E but that offset is a hex offset but from which file i mean which file should i open in hex editor and search for offset 0x2E and then i either change that offset content to another path or add a whole new offset right? But that offset can i change its value to a path say /dev_usb001/ instead of a the 4 bytes being written?
edit 3: ok watched your videos its making sense now those offsets are from the ps3 memory you got them using the debugger and also i think editing the db_rebuilder to write a file from USB to HDD is hard so i looked at the memory.dump its easier to edit to write to hdd from USB because it already does the opposite it writes from HDD to USB i saw its path in path.js i can edit it so instead it will write a file from USB to HDD its much easier than editing the db_rebuilder so ill do it since i have some experience in c++ so the question that is left is if i do it can i test immediately on CEX since i don't have DEX i mean its just writing an empty file so if anything goes wrong ill be able to format HDD right ?
and again thx for the videos bro sorry for this extremely long reply but i thought it better than writing a new reply every time.
Last edited:
esc0rtd3w
Developer
no problem
yes all gadgets are set for 4.81 CEX/DEX and 4.82 CEX and will jump to the same offsets to set registers and make sc call/export. you can find here (CEX 4.82 is after those in text file):
toc and g_1 should not be changed unless you know what you are doing! the TOC must match the VSH you are using and the gadget #1 which is mr r1, r11 then blr can be changed to anything you want, but recommended, at first, at least to use the default one. if you want to do other register actions before moving into new stackframe, you can but you must move r11 or another controlled register into r1, which iirc is only like 4 of them! haha
the g_sc_80, g_sc_90, and g_sc_A0 are all sc (system call) offsets that will pad r0 value out with different sizes, if needed. they all do the same sc. for example (this is not one used, but could be used) uses 0x80, so if your next jump was not working or re-using another gadget value, you could use an sc that adds 0x90, 0xA0, or higher, then set your own new padding with unescape JS and then set r0 to put into lr (link register)
Example from debugger
address | hex value | instruction
0037FFE8 44000002 sc <- makes syscall
0037FFEC E8010090 ld r0,0x90(r1) <- loads our new r0 (next jump from lr) at offset 0x90
0037FFF0 EBC10070 ld r30,0x70(r1) <- loads an 8 byte value for r30 from r1+0x70
0037FFF4 EBE10078 ld r31,0x78(r1) <- loads an 8 byte value for r31 from r1+0x78
0037FFF8 7C0803A6 mtspr lr,r0 <- moves our above r0 into link register
0037FFFC 38210080 addi r1,r1,0x80 <- adds 0x80 to our r1 stackframe (basically add padding to compensate)
00380000 4E800020 blr <-return to lr
btw, the multiple g_fopen_write_close jumps for mem_dump_test, only one is actually used, as during testing i had to find where in stackframe it was.
/js/chains/loader.js
/js/chains/stackframe.js
i will clean up stackframe before next video and make it easier to understand!
you can also check these offsets in the vsh.self for each respective version, using IDA
Last edited:
Ulquiorra-Sama
Member
@The unknown knight What's your intention? I'm curious
Similar threads
-
PS3 4.92 Evilnat Custom Firmware (w/ Cobra v8.5) Released - CEX,PEX,D-PEX,DEX builds- Started by STLcardsWS
- Replies: 41
-
PS3 {CFW Release} 4.92.2 Evilnat Custom Firmware (w/ Cobra v8.5) - Includes: CEX/PEX/D-PEX) + noBD/BT- Started by Evilnat
- Replies: 1
-
PS3 qCFW - Arrives to Slim (2500-3000) & SuperSlim (4000-NOR) PlayStation 3 Models
- Started by STLcardsWS
- Replies: 265
-
PS3 PS3HEN 3.4.0 + HFW 4.92 - Officially released by esc0rtd3w of Team PS3Xploit
- Started by STLcardsWS
- Replies: 46