Danxx444
Member
Have applied most of my patches in the qrc and rco now, so can make everything HEN compatible
PS3 [Research] Modifying the Coldboot/Gameboot Sequence (custom_render_plugin.sprx/rco)
sandungas
Developer
This is one of the things that can be made with the patching method i mentioned in my previous post
Replacing the FPO files is imposible because it should be made this way:
1) extract the files
2) swap the files (just renaming them)
3) inject the files
Only could work if the files are identical in size, right now i dont remember if the QRC structure keeps some padding after the files to align them, but even if that padding exist is going to be very small, something like 3 or 7 bytes as much
The difference of sizes of the "source" and "target" files that are going to be swapped should not be bigger than 7... and thats very unprobable to happen
So the only way to do it is with the method i said... is like patching the TOC of a CD-ROM... the software reads the TOC where is indicated the file position and size, and whatever that appears in the TOC is law
filenameone.bin located at offset=1234fe, size=2321
filenametwo.bin located at offset=1234fe, size=2321
The software thinks that is accessing different files, but it loads the same file
Anyway... for this specific case with the black background there is a setting to seems to indicate which FPO file is loaded
I think is what Cypher_CG89 is mentioning
Inside the BACKRGOUND.MNU, the COLOUR SHADER:int:0
As far i understood, by modifying that value you can load one of this shaders
lines.qrc/moyou/back_colours0.fpo <--- this is the modern one
lines.qrc/moyou/back_colours1.fpo
lines.qrc/moyou/back_colours2.fpo <--- this is the old black one
I was talking about it in other thread, but nobody confirmed if my brainstormings was right :'(
This rule is the most important, because we are injecting the MNU files, we need to respect his original size
Im just quoting you to mention that this applyes also to whole lines, with this i mean...
You can delete a line completly, and replace it by a different variable name, with different data type, and different value
The only rule is the new line should be exactly the same number of characters than the original, or smaller
And obviouslly, the variable names you can use are predefined, there is a list in wiki
https://www.psdevwiki.com/ps3/Lines.qrc#MNU_Settings
Just to mention an interesting one...
BACKGROUND.mnu allows to use the variable NEUTRINOS X
The only enviroment that changes the value of the neutrinos is gameboot2
Is not used in any other enviroment, the name only appears 1 time inside lines.qrc.... but as mentioned you can use it in the other BACKGROUND.mnu files for the other 21 enviroments
And i dont really know what does the value of the neutrinos... i just know that is sounds cool, lol, the wikipedia says that are particles that travels at the speed of light (or something like that)
There are some proofs that inside lines.qrc existed a file named RAYS.MNU (os something like that), but in the XMB thre are no rays
And... a neutrino traveling at speed of light is mostly... a ray, isnt it ?
Dunno, maybe the neutrinos are related with the rays
Anyway, too much brainstorming, this neutrinos are making me think in the dubstep gun of saints row 4
Last edited:
Cypher_CG89
Senior Member
These are sub atomic radiation particles that are given off by the Sun and travel at the speed of light, they pass through ordinary matter like its not their, not matter how dense the matter is, but they don't affect it, at least not in the amount that is given off by by the type of Star our Sun is..... If we have say a Neutron star instead of a Red Giant no life could exist on this planet because of the deadly amount of radiation given off by it.
Trillions upon trillions of these neutrinos pass through the planet, and everything on it per second...
sandungas
Developer
But i cant see them passing throught my XMB
If we take the concept of "speed of light" literally from the definition we can deduce that are moving very fast in the XMB, so i dont think is related with the "particles" animation because the particles moves slow
To me... a neutrino moving at the speed of light should look mostly like a foton... if we could record a video of it at superslow speed we would not see a lightpoint but a ray, like a laser
In the XMB there is nothing like that so... is a mistery
----------
Or maybe is related with the particles, and they just decided to use a catchy name for it
Anyway, is still interesting because as i said that value only appears in 1 enviroment (the gameboot2)... so whatever it does in it is unique
Last edited:
sandungas
Developer
Hmmm, im thiinking that... maybe the keyword is this ---> they pass through matter
Ok, lets forget about the speed of the neutrinos and focus in that characteristique of passing through matter
Also, lets think that the neutrinos are related with the "particles" animations
In the XMB the "matter" are the other objects we can see in the rco code, like a <Plane> (with a image texture, or filled with plain color), or maybe other objects
So... by modifying the value of the neutrinos we can allow the particles to pass through other images (located on top of the particles)
Not sure if this is correct, but sounds good to me
And looks like the kind of feature that could be handy... i mean, imagine you work at sony and have lot of programmers sending his work to you, one day one of them tells you "i imagined a feature to allow the partilcles to pass through the other objects". Most probably you are going to say "i like it, is approved", and... "we need it in our toolbox"
Ok, lets forget about the speed of the neutrinos and focus in that characteristique of passing through matter
Also, lets think that the neutrinos are related with the "particles" animations
In the XMB the "matter" are the other objects we can see in the rco code, like a <Plane> (with a image texture, or filled with plain color), or maybe other objects
So... by modifying the value of the neutrinos we can allow the particles to pass through other images (located on top of the particles)
Not sure if this is correct, but sounds good to me
And looks like the kind of feature that could be handy... i mean, imagine you work at sony and have lot of programmers sending his work to you, one day one of them tells you "i imagined a feature to allow the partilcles to pass through the other objects". Most probably you are going to say "i like it, is approved", and... "we need it in our toolbox"
@sandungas talking about the icons.qrc is possible to add new icons? like for the @DeViL303's mods ? to match a perfect xmb
sandungas
Developer
The tools used to customize qrc files are "injecting" the files in the QRC internal structure without modifying it
So technically that tools are "injectors"
But we cant rebuild/compile QRC files
Incase someone does a tool like this, or rebuilds the file manually with a hexeditor... sure is posible
But we dont know if the firmware is going to load it
I mean... like in the official .P3T compiler, that contains the names of the icons allowed to be used in a theme hardcoded inside the program
If you try to build a theme with an icon name different than the names of the list then the program refuses it
Is like a "whitelist", if your icon name is not in the whitelist then is not valid
For the icons.qrc the firmware could be doing something similar.... it could have a "whitelist" (somewhere else, not inside icontex.qrc) with the icons that can be loaded from icontex.qrc and only searches for that ones
Can you send me the already patched file?
i tried icons.qrc.cropout.zlibout.patched.zlibin.cropin renamed to icons.qrc and did not work.
The sad thing i need to reinstall the fw but without a tv HAHA
sandungas
Developer
Yes, that was it, what i did is to add a new file extension everytime i modifyed the file, so is like this:
icons.qrc <------------------------------------------------- original file
icons.qrc.cropout <------------------------------------------------- removed the first 8 bytes
icons.qrc.cropout.zlibout <------------------------------------------------- zlib decompressed
icons.qrc.cropout.zlibout.patched <------------------------------------------------- patched in hexeditor
icons.qrc.cropout.zlibout.patched.zlibin <------------------------------------------------- zlib compressed
icons.qrc.cropout.zlibout.patched.zlibin.cropin <------------------------------------------------- added the first 8 bytes
So... you can rename "icons.qrc.cropout.zlibout.patched.zlibin.cropin" to "icons.qrc" and copy it to the PS3
I been reviewing everything i did, and i need to mention a couple of things:
In the previous version of the "HowTo.txt" there was a couple of typos in the explanations about how to make the calculations, but this typos doesnt matters because the patches indicated at bottom of the .txt was fine
In other words... the patch i applyed to the file was fine
The problem i see is in the "HowTo.txt" im suggesting to remap 2 files (so is needed to apply 2 patches to do what i was explaining in the .txt), i named them PATCH1, and PATCH2... but in the file i only applyed PATCH2 (not PATCH1)
Code:
PATCH 1. Remap "icons_cheap_ss.fpo" to "icons_full_ss.fpo"
SEARCH: 0000914000001A10 (located at absolute offset 0x63C)
REPLACE: 0000C3D000004B10
PATCH 2. Remap "icons_cheap_ss_no_shad.fpo" to "icons_full_ss_no_shad.fpo"
SEARCH: 0000AB5000001880 (located at absolute offset 0x678)
REPLACE: 00010EE000004360So... im going to upload a new version with the 2 patches applyed
FILE: https://www.sendspace.com/file/qqf5sd
------------------------------
And i imagined an alternative way to find the data that needs to be patched... is very easy, there is no need to make any calculation, and it should work for all kind of files
My intention while doing this experiment was to write a tutorial, as you can see by reading the first version of the "HowTo.txt", i had this intention since begining... mostly because is very important, is the only way to do this remapping of files inside QRC structures
But for a tutorial is a lot better to use a different "guinea pig" for the samples... it should be something simple, popular, interesting, and worthy
So i would like to know which candidates you propose @LuanTeles @DeViL303 @Cypher_CG89 ...or any other interested in this
@DeViL303 you was doing lot of tests applying patches in the .sprx to redirect files that later are loaded from inside .qrc container, but with this method we can do the redirection inside the .qrc container so... there is something you need to patch inside the .qrc ?, i can do it, at this point it will not take me much time
Interesting stuff.. Can you use your method to enable the debug particles which I dubbed the "snow effect" (particles_quads_debug.fpo and particles_quads_debug.vpo)
In the sprx I can enable debug particles by editing the name of the vpo and fpo that gets called from the qrc but it would be nice if we could enable all the debug stuff including those without sprx patches..
Also please look at ways to enable the debugGUI.vpo/fpo too. If the actual debugGUI.vpo and fpo are just dummied out, maybe we can inject the DebugGUI vpo/fpo from the visualizer application if we can modify the TOC or something, I don't know. I guess its possible Q-Games used the same GUI files in that application.
BTW: In some of my tests using sprx patches I managed to get extra different effects by mixing and matching vpo with another fpo, surprised it worked at all but in at least one case it did and gave a nice new effect..
In the sprx I can enable debug particles by editing the name of the vpo and fpo that gets called from the qrc but it would be nice if we could enable all the debug stuff including those without sprx patches..
Also please look at ways to enable the debugGUI.vpo/fpo too. If the actual debugGUI.vpo and fpo are just dummied out, maybe we can inject the DebugGUI vpo/fpo from the visualizer application if we can modify the TOC or something, I don't know. I guess its possible Q-Games used the same GUI files in that application.
BTW: In some of my tests using sprx patches I managed to get extra different effects by mixing and matching vpo with another fpo, surprised it worked at all but in at least one case it did and gave a nice new effect..
sandungas
Developer
Remap "lib/particles/particles_quads.vpo" to "lib/particles/particles_quads_debug.vpo"
SEARCH: 00081750000014B0
REPLACE: 00082C0000001380
Remap "lib/particles/particles_quads.fpo" to "lib/particles/particles_quads_debug.fpo"
SEARCH: 0007F49000000E00
REPLACE: 0008029000000870
SEARCH: 00081750000014B0
REPLACE: 00082C0000001380
Remap "lib/particles/particles_quads.fpo" to "lib/particles/particles_quads_debug.fpo"
SEARCH: 0007F49000000E00
REPLACE: 0008029000000870
sandungas
Developer
That files inside lines.qrc are not dummies, and there is something interesting in them
Most important thing to mention is that have the exact same size so we can "inject" them inside lines.qrc
The second interesting thing is the FPO's from Q-games and from the PS3 firmware are identical, same MD5. So no fun with the FPO from Q-games
But the VPO's are different... there are 18 bytes that differs (spreaded along the file, i cant imagine what that bytes does)
-------------------------------------------------------------------------------------------
Q-games DebugGui.fpo
MD5: 57FA6B8C9483CA6CA2FE4A887BAB0A85
SIZE: 0x160
"lib/devgui/DebugGui.fpo"
MD5: 57FA6B8C9483CA6CA2FE4A887BAB0A85
SIZE: 0x160
TARGET: 00085F9000000160 <--- this is the value needed to be used to do a remap into it
--------------------------------------------------------------------------------------------
Q-games DebugGui.vpo
MD5: 5FFAB0E8B5CCE50939C8CCCCA9F40964
SIZE: 0x03E0
"lib/devgui/DebugGui.vpo"
MD5: 8D8061FD44EBD72A06A3BDB6E5849F8F
SIZE: 0x03E0
TARGET: 00085BB0000003E0 <--- this is the value needed to be used to do a remap into it
Perfect thanks!
I've attached the official lines.qrc here with just the debug particles enabled, NO other patches applied so this could be called a debug lines.qrc, would be even better if we could enable the debug GUI too most likely as it probably has interesting info for us and maybe even some control. At worst it will have some novelty value and be a nice little easter egg to find at this stage in the PS3s life cycle..
Already I can see how it would be easier to develop a new effect with just the debug particles enabled. In this video its much easier to see whats happening with the X/Y movement and sixaxis movement. In this video I let the XMB sit for 15 seconds to show normal motion, then I shake the DS3 for a few seconds then let it rest, then show some X/Y moves to demonstrate the icon interaction.
That files inside lines.qrc are not dummies, and there is something interesting in them
Most important thing to mention is that have the exact same size so we can "inject" them inside lines.qrc
The second interesting thing is the FPO's from Q-games and from the PS3 firmware are identical, same MD5. So no fun with the FPO from Q-games
But the VPO's are different... there are 18 bytes that differs (spreaded along the file, i cant imagine what that bytes does)
-------------------------------------------------------------------------------------------
Q-games DebugGui.fpo
MD5: 57FA6B8C9483CA6CA2FE4A887BAB0A85
SIZE: 0x160
"lib/devgui/DebugGui.fpo"
MD5: 57FA6B8C9483CA6CA2FE4A887BAB0A85
SIZE: 0x160
TARGET: 00085F9000000160 <--- this is the value needed to be used to do a remap into it
--------------------------------------------------------------------------------------------
Q-games DebugGui.vpo
MD5: 5FFAB0E8B5CCE50939C8CCCCA9F40964
SIZE: 0x03E0
"lib/devgui/DebugGui.vpo"
MD5: 8D8061FD44EBD72A06A3BDB6E5849F8F
SIZE: 0x03E0
TARGET: 00085BB0000003E0 <--- this is the value needed to be used to do a remap into it
Nice one, interesting too
Now we just need to try find out where it can be remapped to, for example the GUI will not be a background most likely. Its possible we could replace the actual wave or the particles with the GUI. Also this links in with PARTICLES_UI.MNU and particleshackmenu. We need to figure out all these pieces of the puzzle to enable it.
Maybe we can do a remap on PARTICLES_SPU to PARTICLES_UI or something like that rather than remapping the vpo/fpo directly?
Maybe there is even a button combo to enable it?
sandungas
Developer
In the video is used the lines.qrc with the patches i suggested ?... so is a confirmation that it works, right ?Perfect thanks!
I've attached the official lines.qrc here with just the debug particles enabled, NO other patches applied so this could be called a debug lines.qrc, would be even better if we could enable the debug GUI too most likely as it probably has interesting info for us and maybe even some control. At worst it will have some novelty value and be a nice little easter egg to find at this stage in the PS3s life cycle..
Already I can see how it would be easier to develop a new effect with just the debug particles enabled. In this video its much easier to see whats happening with the X/Y movement and sixaxis movement. In this video I let the XMB sit for 15 seconds to show normal motion, then I shake the DS3 for a few seconds then let it rest, then show some X/Y moves to demonstrate the icon interaction.
[/B]
Let me express my feelings like an adult man... with a proper meme
Btw, i dont get very well what they was trying to do in that debug shaders... to me it looks the particles that can be seen at back (that looks like "attached" to the wave) has been moved far away of the camera, and at the sides there are 2 "particle emitters" (the ones that reacts to the DS3 sensors) that has been moved closer to the camera
Btw... you are moving the D-pad too much fast in the video
Like... move to right... and 2 second later move to left
Is better to give them more time, lets say 5 seconds or more because the particles moves slow and some effects are more notable if you wait a bit
By now an easy thing we can do is to replace the official PS3 DebugGui.vpo inside lines.qrc by the DebugGui.vpo from the Q-games visualizer app
But to be honest, i think this change alone by itself is not going to do anything
The point is... it looks both the PS3 firmware and the Q-games visualizer have a debug GUI... but obviously are not enabled for the retail users
We cant see the debug GUI in the PS3 firmware... in the same way we cant see it in the Q-games visualizer app
So... not sure what to try next... by now it looks more important to try to figure which file could be used to do the remap
sandungas
Developer
Btw @esc0rtd3w you have a lot of experience reversing PSN apps in IDA, debugging them etc...
If at some point you have some free time, take a look at the visualizer app made by Q-games (there are some talks in the forum about it latelly), we know that program is closelly related with some features of PS3 XMB, actually that company designed some of the features of the XMB, they was working with sony, with the same tools, same libraries, etc...
We dont know how many useful things contains the visualizer app made by Q-games, but i think is a safe bet to tell that is hiding some easter eggs for sure
If at some point you have some free time, take a look at the visualizer app made by Q-games (there are some talks in the forum about it latelly), we know that program is closelly related with some features of PS3 XMB, actually that company designed some of the features of the XMB, they was working with sony, with the same tools, same libraries, etc...
We dont know how many useful things contains the visualizer app made by Q-games, but i think is a safe bet to tell that is hiding some easter eggs for sure
Last edited:
Yes, perfect patch first time. Nice one.
Your right, I will do another longer one to show it better. What exactly should I do, leave it sit for 30 sec, then just move one icon at a time, or move lots, but then stay still longer like 5 seconds after each move?Btw, i dont get very well what they was trying to do in that debug shaders... to me it looks the particles that can be seen at back (that looks like "attached" to the wave) has been moved far away of the camera, and at the sides there are 2 "particle emitters" (the ones that reacts to the DS3 sensors) that has been moved closer to the camera
Btw... you are moving the D-pad too much fast in the video
Like... move to right... and 2 second later move to left
Is better to give them more time, lets say 5 seconds or more because the particles moves slow and some effects are more notable if you wait a bit
Yeah, its not worth it. I think any small differences between them are probably specific to the item they were debugging, so the original lines.qrc debugGUI has more chance of working if we can enable it.
Can we look inside the DebugGUI vpo/fpo and maybe see some elements or anything like variable names, images, text etc? That might give us a clue for enabling it, or tell us something else?
I have a feeling that PARTICLES_UI is where we need to look, at a guess we need to load that instead of one of the other PARTICLES.MNU files.or as well as the other PARTICLES files.
It really could be a flag on hdd that enables it, like a simple txt file maybe in correct location.
I think this txt file is very important, it is right next to the dev_gui/debugGUI stuff. Is it possible that this txt file is inside the QRC?
Also check this, is there anything there that helps, its an Gamemoneky Script file from the visualizer application that mentions devgui.
Code:
//Devgui child
//Devgui
global g_devgui_layout = {};
global DevGuiMngLayout = function(_Name,_Func)
{
local opened = ?g_devgui_layout[_Name];
local new_value = Q.SIMGUICheckBox( opened, _Name );
if (new_value != opened)
{
if (opened)
{
g_devgui_layout[_Name].Release();
g_devgui_layout[_Name] = null;
}
else
{
local layout = _Func();
g_devgui_layout[_Name] = layout;
layout.SetName(_Name);
layout.EnableTitle( true );
}
}
};
global DevGuiDump = function()
{
DevGuiMngLayout(
"HDR Param",
function() { return Q.NewLayout( 80, 80, 700, 500, null, g_hdr_gui.Param.draw ); }
);
/*
DevGuiMngLayout(
"Camera",
function() { return Q.NewLayout(120,120,500,200,null,g_camera_gui); }
);
*/
/*
DevGuiMngLayout(
"Rumble Editor",
function() { return Q.NewLayout(300,120,500,500,null,g_rumble_debug_gui); }
);
*/
/*
if( Q.SIMGUIButton("GmDebugEntry") )
{
g_devgui_layout["GmDebugEntry"] = Q.NewLayout(120,120,300,300,null,GmDebugEntry);
g_devgui_layout["GmDebugEntry"].EnableCloseButton( true );
g_devgui_layout["GmDebugEntry"].EnableDebuggerLayout( true );
}
*/
// HDRMenu(this);
};Does the wave use gamemonkey too or something or ....?
sandungas
Developer
Im into a brainstorming... im going to read your post more calmly and will reply to it later
Look at this @DeViL303 inside canyon.qrc (one of the animations in the music player)
https://www.psdevwiki.com/ps3/Canyon.qrc#File_list
As example in this path... the name vis looks like a short form of the name "visualizer"... you know the same name of the "Q-games visualizer"
canyon.qrc/lib/vis/RandomCrapGrid.fpo <--- btw this are codenames, literally some official random crap
Look at this @DeViL303 inside canyon.qrc (one of the animations in the music player)
https://www.psdevwiki.com/ps3/Canyon.qrc#File_list
As example in this path... the name vis looks like a short form of the name "visualizer"... you know the same name of the "Q-games visualizer"
canyon.qrc/lib/vis/RandomCrapGrid.fpo <--- btw this are codenames, literally some official random crap
sandungas
Developer
Im going to quote myself for the record... what i said below is refered to the DebugGui files inside lines.qrc
But there are more, inside store.qrc
https://www.psdevwiki.com/ps3/Store.qrc#File_list
"lib/devgui/DebugGui.fpo"
MD5: 57FA6B8C9483CA6CA2FE4A887BAB0A85
SIZE: 0x160
TARGET: 0011095000000160 <--- this is the value needed to be used to do a remap into it
"lib/devgui/DebugGui.vpo"
MD5: 8D8061FD44EBD72A06A3BDB6E5849F8F
SIZE: 0x03E0
TARGET: 00110570000003E0 <--- this is the value needed to be used to do a remap into it
-------------
Long story short, the DebugGui.fpo/vpo files inside lines.qrc and store.qrc are identical
Not much interesting, but worthy to be mentioned
That files inside lines.qrc are not dummies, and there is something interesting in them
Most important thing to mention is that have the exact same size so we can "inject" them inside lines.qrc
The second interesting thing is the FPO's from Q-games and from the PS3 firmware are identical, same MD5. So no fun with the FPO from Q-games
But the VPO's are different... there are 18 bytes that differs (spreaded along the file, i cant imagine what that bytes does)
-------------------------------------------------------------------------------------------
Q-games DebugGui.fpo
MD5: 57FA6B8C9483CA6CA2FE4A887BAB0A85
SIZE: 0x160
"lib/devgui/DebugGui.fpo"
MD5: 57FA6B8C9483CA6CA2FE4A887BAB0A85
SIZE: 0x160
TARGET: 00085F9000000160 <--- this is the value needed to be used to do a remap into it
--------------------------------------------------------------------------------------------
Q-games DebugGui.vpo
MD5: 5FFAB0E8B5CCE50939C8CCCCA9F40964
SIZE: 0x03E0
"lib/devgui/DebugGui.vpo"
MD5: 8D8061FD44EBD72A06A3BDB6E5849F8F
SIZE: 0x03E0
TARGET: 00085BB0000003E0 <--- this is the value needed to be used to do a remap into it
But there are more, inside store.qrc
https://www.psdevwiki.com/ps3/Store.qrc#File_list
"lib/devgui/DebugGui.fpo"
MD5: 57FA6B8C9483CA6CA2FE4A887BAB0A85
SIZE: 0x160
TARGET: 0011095000000160 <--- this is the value needed to be used to do a remap into it
"lib/devgui/DebugGui.vpo"
MD5: 8D8061FD44EBD72A06A3BDB6E5849F8F
SIZE: 0x03E0
TARGET: 00110570000003E0 <--- this is the value needed to be used to do a remap into it
-------------
Long story short, the DebugGui.fpo/vpo files inside lines.qrc and store.qrc are identical
Not much interesting, but worthy to be mentioned
Im into a brainstorming... im going to read your post more calmly and will reply to it later
Look at this @DeViL303 inside canyon.qrc (one of the animations in the music player)
https://www.psdevwiki.com/ps3/Canyon.qrc#File_list
As example in this path... the name vis looks like a short form of the name "visualizer"... you know the same name of the "Q-games visualizer"
canyon.qrc/lib/vis/RandomCrapGrid.fpo <--- btw this are codenames, literally some official random crap
That's funny. Here are all the files like vpos/fpos and gm files inside that application. I think its ok to share in the name of research. No eboot or top folder files included and even if you had those you still need a valid licence so no piracy issues afaik.
There is more debug/dev related stuff in there, these 2 other files are in the devgui folder for example.
And these files mention debug or dev:
