Not sure what am I doing wrong here, cant find that HEX.
PS3 [Research] Modifying the Coldboot/Gameboot Sequence (custom_render_plugin.sprx/rco)
Not sure what am I doing wrong here, cant find that HEX.
Is there a way to open sprx or bin files with visual studio rather than working on HxD ? Maybe you need to decrypt that file.
sandungas
Developer
Are located at offset 0x21A8 and 0x2220
using IDA
Something wrong with my pc i think. Cant see it. I give up. its wasting too much time.
I'll let some other people mess for a while and move onto something else.
sandungas
Developer
Im checking it again and looks fine, maybe is your hexeditor, when searching are you telling it to "search hex values" instead of "search text stings" ?Something wrong with my pc i think. Cant see it. I give up. its wasting too much time.
Also, dont remove the zeroes at beginning of the search pattern, if you make the total lenght of the search pattern to a noun number of digits (like 1, 3, 5, 7, 9, 11, 13, etc...) then the hexeditor cant find it
OK, finally my HEX editor started working, really strange.Btw, this is the patch for the double wave, untested/frankensperimental, only for the braves
Remap "spurs/particles/particles/particles.elf" to "spurs/moyou/spline/spline.elf"
SEARCH: 00076DD0000086B4
REPLACE: 0005036000007264
So the Quin patch seems to make the wave a little more faded, its subtle.
original:
Quin:
Double wave patch is giving me a blackscreen, coldboot audio still played. Its not a brick or a freeze as I still have ftp access.
sandungas
Developer
What a little reward with the "quin" :/
Well a least it works, i guess it should do something more but we are missing something
What a shame with the double wave, that effect could be something nice, i was looking at the spline.elf and particles.elf, scetool doesnt gives info about them because are already decrypted
I dont know how to reverse them in IDA (not even take a peek at them), so this is a road end for me
But by looking at them in a hexeditor there is something that called my attention
At the end of both .elf files it can be seen that are using the string "spu_name", and there is another area where can be seen the names
-SPUNAME�particles.sym
-SPUNAME�spline.sym
---------
So im wondering... maybe there is some code somewhere else that is expecting to find that names... and the remapping doesnt works because that
In other words... we would like to play the spline.elf 2 times... but we cant load it 2 times with the same name
Not sure, but incase this theory is true, the remapping method is not going to allow to play 2 waves
If this theory is true a dirty trick that could work is to extract the spline.elf (29.284 bytes), patch it to change his name by "particles.sym" (it seems there is room in the .elf structure to make his name longer), then overwrite the area of the particles.elf with it (34.484 bytes)... and fill the gap with zeroes
--------------
Or someone could reverse the spline.elf and try to rewrite the source code of it... then compile it into .elf with some changes
Or replace the .elf by an exploit
Well a least it works, i guess it should do something more but we are missing something
What a shame with the double wave, that effect could be something nice, i was looking at the spline.elf and particles.elf, scetool doesnt gives info about them because are already decrypted
I dont know how to reverse them in IDA (not even take a peek at them), so this is a road end for me
But by looking at them in a hexeditor there is something that called my attention
At the end of both .elf files it can be seen that are using the string "spu_name", and there is another area where can be seen the names
-SPUNAME�particles.sym
-SPUNAME�spline.sym
---------
So im wondering... maybe there is some code somewhere else that is expecting to find that names... and the remapping doesnt works because that
In other words... we would like to play the spline.elf 2 times... but we cant load it 2 times with the same name
Not sure, but incase this theory is true, the remapping method is not going to allow to play 2 waves
If this theory is true a dirty trick that could work is to extract the spline.elf (29.284 bytes), patch it to change his name by "particles.sym" (it seems there is room in the .elf structure to make his name longer), then overwrite the area of the particles.elf with it (34.484 bytes)... and fill the gap with zeroes
--------------
Or someone could reverse the spline.elf and try to rewrite the source code of it... then compile it into .elf with some changes
Or replace the .elf by an exploit
I'm willing to try any files you want to patch but I'm not sure if i am able to do that myself.What a little reward with the "quin" :/
Well a least it works, i guess it should do something more but we are missing something
What a shame with the double wave, that effect could be something nice, i was looking at the spline.elf and particles.elf, scetool doesnt gives info about them because are already decrypted
I dont know how to reverse them in IDA (not even take a peek at them), so this is a road end for me
But by looking at them in a hexeditor there is something that called my attention
At the end of both .elf files it can be seen that are using the string "spu_name", and there is another area where can be seen the names
-SPUNAME�particles.sym
-SPUNAME�spline.sym
---------
So im wondering... maybe there is some code somewhere else that is expecting to find that names... and the remapping doesnt works because that
In other words... we would like to play the spline.elf 2 times... but we cant load it 2 times with the same name
Not sure, but incase this theory is true, the remapping method is not going to allow to play 2 waves
If this theory is true a dirty trick that could work is to extract the spline.elf (29.284 bytes), patch it to change his name by "particles.sym" (it seems there is room in the .elf structure to make his name longer), then overwrite the area of the particles.elf with it (34.484 bytes)... and fill the gap with zeroes
--------------
Or someone could reverse the spline.elf and try to rewrite the source code of it... then compile it into .elf with some changes
Or replace the .elf by an exploit
As this is a unencrypted elf loaded by the system, cant this be used to exploit OFW somehow by adding some code to it?
Danxx444
Member
Since you guys are playing with lines.qrc ... could you guys take a look at how the FW 2.80 wave used the "Original" theme as the black wave and at the same time, we had the option to choose colors too, if by chance, the user don't want to use the black wave ?
In short ... in FW 2.80 (or earlier) the "Original" theme was the black wave.
In short ... in FW 2.80 (or earlier) the "Original" theme was the black wave.
You can just swap colors in lines.qrc, the first one now is gray but it was the black one in the first firmwares.
the problem is the side menu will not match it, it will be gray, but a minor issue.
Danxx444
Member
hmm ... okay ... but if change the wave color from the "Original" theme to black, will you still be able to choose other colors? or it will be always black?
Last edited:
sandungas
Developer
I dont know how it was made in old firmwares, i never took a look at that files trying to figure how the wave was working, mostly because i never thought the wave was working in a different way
But i remember to read somewhere in the forum that @Cypher_CG89 was looking at it, maybe he can explain it
sandungas
Developer
I prepared the lines.qrc patched for the double wave... this time is not a remap
Are included all the intermediate files generated in every step of the process, this way you can compare them to see what im doing, also there is a small .txt where appears the values i needed to use to find his offsets and lengths to apply the patches accuratelly
Fingers crossed, i hope it works... i dont think i made any mistake
*You need to rename the file "lines.qrc.cropout.zlibout.clean.patched.zlibin.cropin"... to... lines.qrc
FILE: Link removed
sandungas
Developer
@DeViL303 i removed the download link... incase you or someone downloaded, dont try it, i think i need to patch another detail
The problem is... remember the values we was patching for the remappings ?... that values contains offset + length of the file
In this mod i replaced the file particles.elf by spline.elf (the file itself)... so his offset is the same
But the lenght is different... i did not realize about that... give me few minutes to patch it, and review everything again
The problem is... remember the values we was patching for the remappings ?... that values contains offset + length of the file
In this mod i replaced the file particles.elf by spline.elf (the file itself)... so his offset is the same
But the lenght is different... i did not realize about that... give me few minutes to patch it, and review everything again
sandungas
Developer
Oki, i think this is the final test, as usually im including all the files generated in intermediate steps of the process incase someone wants to review it and try other alternatives
FILE: https://www.sendspace.com/file/74s1yf
FILE: https://www.sendspace.com/file/74s1yf
Cypher_CG89
Senior Member
I haven't had a chance to fully look into it properly, just the lines files that @Danxx444 gave me, I made a few note's about them somewhere either on this PC or my other one.
And what I really want to do is to look at every lines qrc file upto 2.80 to see exactly where and when changes were made> eg like things added, MNU settings changed> stuff like that.
Then I want to look at all lines.qrc files from 2.80 to 4.40 from the same reasons, but not just the lines.qrc but the corisponding game_ext_plugin.sprx's and custom_render.rcos as well from 1.00 to 2.80 then 2.80 to 4.40.
As you can imagin that is a lot of files and stuff to look through but mainly want to start from 1.00 > 2.80's lines.qrc, game_ext_plugin.sprx and custom_render.rco first, and that still quite a few files.
Also any other files that could/are releated to this.... Any suggestions on other files to look at are welcome ... for example I forgot which file can be found info on the theme settings... this is also a good place to go looking at what exactly is been changed, called upon and any overides its applying to the lines.qrc.
I need to set aside some time to do this fully, nose to the grindstone so to speak (or nose to PC screen and keyboard in this case lol) and at the minute I don't have much spare time to fully dedicate to this, and just doing a bit here and a bit there will just do my head in and I will lose interest in doing it at all.
