PS3 Gameboot & XMB Modify Collections w/ Installer by bitsbubba

Want an easy way to change up the look of your XMB and more? Well, with these two new Installers that were released by bitsbubba; GameBoot Collection & XMB Modify it's very easy to do so, with these installers that contain great collections from various Contributors from around the communities. Includes some of the best Custom Coldboots, Gameboots, System Start-Up Sounds, & also some [break]..[/break] Custom XMB waves that the scene has to offer. This is v1.00 of the collection and it's contents can be seen below and in the forums via these links that contain additional information;( GameBoot Collection & XMB Modify)

​

Contents of Collections

---

• Custom Coldboots - 30+
• Custom GameBoots - 17+
  
• Custom Start-up Sounds - 12
  
• Custom XMB Waves - 7

DOWNLOADS:
Gameboot Collection Installer - MIRRORs
XMB Modify Collection Installer - MIRRORs

---

Checkout Additional information on these by clicking the title:
GameBoot Collection & XMB Modify
​

 

As a constructive critic, for the .qrc files what i would do is to try to deduce wich firmware was used when the author created it

But is needed to know what sony was changing in the different versions... and for this is needed to extract the official files and compare them to see if the changes was not important (a value changed will not break compatibility... but if they added something new that didnt existed before probably this will break compatibility)
Initially it could be posible to deduce from wich firmware belongs by the timestamp of the files, but this is not much accurate, i guess is needed to test all them in a working firmware to see if they loads

This is the way i see to save all these nice custom waves to use them in the future
But at some point sony will change again the file lines.qrc and all them will be incompatible :/ so the good way to preserve all these work is to find what setttings they changed (in the .MNU files)
I planned to look at all this and document and explain all the settings used to make custom waves in wiki, but i went lazy just thinking in the amount of work is it, heheh
But someone will have to do it some day, because this is the only way to use the same settings (to create the same waves intended by the author) when rebuilding lines.qrc for future firmwares

yeah, I do remember when glowball started releasing his waves - there were a lot of people saying that his waves had bricked their consoles. a soft-brick, obviously, but there were some people claiming that reinstalling the fw didn't work or going into the recovery menu resulted in a black screen. ...must've been something more serious going on with those consoles. what I usually do is hex compare waves between firmwares. and, I always test them out before uploading them. I had thought about researching/testing what each value did, but it'd take way too long to do that. plus, aside from me, u, and a handful of other people, most wouldn't be interested anyway. I do believe it's possible to make a wave that can make ur system unstable though, so some combination of values should be cautionary. if u increase the length and the perturbation values enough, the wave will actually break apart into hundreds of miniature waves. the system crawls along slowly while on the xmb when that happens. :p

anyway, my rule of thumb has always been the first eight bytes. if they're different, they always seem to result in a brick. I don't know what those bytes reference at all.

 

yeah, I do remember when glowball started releasing his waves - there were a lot of people saying that his waves had bricked their consoles.

I tested some his waves (can't remember my fw version but it was Rebug) and my console allways froze in XMB after maybe minute or more. With waves from XMB Modify Collection all is fine (Rebug 4.70.1), but all waves (and Glowballs too) after startup takes place near left side and after some time going to normal.

Spoiler: Why this happening?

 

anyway, my rule of thumb has always been the first eight bytes. if they're different, they always seem to result in a brick. I don't know what those bytes reference at all.

In the original lines.qrc file (exactly as is stored in the flash) the first 8 bytes are divided in 2 groups of 4
First group of 4 bytes is the container identifyer = QRCC (it means... Qt Resource Container Compressed)
Next 4 bytes = The size of the QRCF file generated when a QRCC is decompressed

If you decompress it with zlib (after removing these 8 bytes) you have a new file with different data (should be considered another container) and the first 8 bytes are divided again in 2 groups of 4
First group of 4 bytes is the container identifyer = QRCF (it means... Qt Resource Container Flat)
Next 4 bytes = The version of the QRCF structure (usually 00000110)

-------------
Is info about the different container formats, his size and structure... but cant be used to determine the compatibility between firmwares
The firmware uses this info to make room in ram for the decompression and to identify the container type

 

I tested some his waves (can't remember my fw version but it was Rebug) and my console allways froze in XMB after maybe minute or more. With waves from XMB Modify Collection all is fine (Rebug 4.70.1), but all waves (and Glowballs too) after startup takes place near left side and after some time going to normal.

Spoiler: Why this happening?

that's caused by the perturbation. if the value is too high, the wave will shift towards the left side of the screen.

In the original lines.qrc file (exactly as is stored in the flash) the first 8 bytes are divided in 2 groups of 4
First group of 4 bytes is the container identifyer = QRCC (it means... Qt Resource Container Compressed)
Next 4 bytes = The size of the QRCF file generated when a QRCC is decompressed

If you decompress it with zlib (after removing these 8 bytes) you have a new file with different data (should be considered another container) and the first 8 bytes are divided again in 2 groups of 4
First group of 4 bytes is the container identifyer = QRCF (it means... Qt Resource Container Flat)
Next 4 bytes = The version of the QRCF structure (usually 00000110)

-------------
Is info about the different container formats, his size and structure... but cant be used to determine the compatibility between firmwares
The firmware uses this info to make room in ram for the decompression and to identify the container type

okay. thanks. the second group of four bytes might have something to do with compatibility if the size of the flattened qrc is different.

 

About the waves that crashes the firmware... this happens because the values that has been changed belongs to some math operation (inside the .elf i guess)
The values we change should be in a range we dont know (and trying to imagine them could be imposible, even reversing the .elf we will not know the range of values we are safe to "play" with)
When the math operation is performed in real time... the resulting value gets "out of range"... this is something you could see while debugging it in target manager
Im pretty sure sony debugged the wave while they was creating it... but i still not sure how they made it (probably they extracted the .elf and his .mnu settings from the .qrc and booted it standalone as a normal app)

There must be a way to run the wave as a standalone app and debugging it in real time, this way we could see what all the values in the .mnu files does and how they modifyes the wave visually in real time

 

the wave is extremely complicated. the values of the crests and dips r predetermined, but I think some of the other values work in concert to alter the points at which the wave crests or dips. that's kinda how the coldboot script works. where on the screen 0 is is determined by the value of the camera, so when the coldboot appears initially, it'll be fixed at that point. then it shifts to the beginning x, y, and z value; after which, it'll move towards the ending values. I'm thinking the wave is similar to that. however, it's obviously gonna be as complicated as one of those thousand-line plus dynamic coldboot scripts.

edit: it's probably true that there's some sort of range within the elf file. one thing I learned while messing with a coldboot script was that u could change the decimal place. I'm not sure if the same is true with the wave (never tried), but doing so would likely make the system unstable (if it worked at all) requiring a reinstall of the fw. within the wave mnu, u can't turn a negative into a positive either which lends credence to their being some sort of range.

 

I feel like im derailing the thread a bit, this message is a bit offtopic but i think you will find it interesting, look at this video ---> https://www.youtube.com/watch?v=CR1Mhthfd8g
The guy is trying to mimic a ps3 wave... but with 3D max in real time, using a "cloth" surface and lot of "fine tunned" settings

Initially seems not related with what we can do in PS3... but the fact is he made a wave pretty close to the one used in PS3, and i bet some of the settings (and ideas like the cloth surface) he used are correct... not all of course otherway it would look exactly like the one used in PS3. But the point is pretty similar
In PS3 the wave is animated thanks to openGL, its libraries, the wave .elf of course and the settings loaded by the .elf that are the .mnu files
And these settings should be pretty similar than what this guy used... not the same names of course, but in 3D the way the things works is always the same across any program, and openGL is not an exception
As example, maybe the setting we can see in PS3 inside the .mnu files named perturbation.... in 3d max is named disturbation, or vibration, or whatever, the name doesnt matters because it does the same in all 3D programs

I mention this just as a curiosity, because in the practise is very hard to know how the PS3 wave has been made but what this guy is doing in the video i bet is pretty close to what sony did, and you are right when saying is very complex, it does lot of math operations (and the sparks too)... are calculations related with particles, gravity, fluids, etc... so things can get out of control easylly when changing the settings

 

I feel like im derailing the thread a bit, this message is a bit offtopic but i think you will find it interesting, look at this video ---> https://www.youtube.com/watch?v=CR1Mhthfd8g

hey don't worry about derailing this thread, you guys are very knowledgeable and informative (and waves in on topic anyhow)

 

I feel like im derailing the thread a bit, this message is a bit offtopic but i think you will find it interesting, look at this video ---> https://www.youtube.com/watch?v=CR1Mhthfd8g
The guy is trying to mimic a ps3 wave... but with 3D max in real time, using a "cloth" surface and lot of "fine tunned" settings

Initially seems not related with what we can do in PS3... but the fact is he made a wave pretty close to the one used in PS3, and i bet some of the settings (and ideas like the cloth surface) he used are correct... not all of course otherway it would look exactly like the one used in PS3. But the point is pretty similar
In PS3 the wave is animated thanks to openGL, its libraries, the wave .elf of course and the settings loaded by the .elf that are the .mnu files
And these settings should be pretty similar than what this guy used... not the same names of course, but in 3D the way the things works is always the same across any program, and openGL is not an exception
As example, maybe the setting we can see in PS3 inside the .mnu files named perturbation.... in 3d max is named disturbation, or vibration, or whatever, the name doesnt matters because it does the same in all 3D programs

I mention this just as a curiosity, because in the practise is very hard to know how the PS3 wave has been made but what this guy is doing in the video i bet is pretty close to what sony did, and you are right when saying is very complex, it does lot of math operations (and the sparks too)... are calculations related with particles, gravity, fluids, etc... so things can get out of control easylly when changing the settings

and, to think, I thought I was the "wave" person in the scene since I've done innumerable tests with it. I can't imagine how long it too to mimic it on the pc. ur probably right in that they (sony) probably debugged the wave in order to fine tune it. perturbation = disturbance, possibly. perturbation makes the wave look fluid, so it pulsates from one end to the other. if the length is too high as well as its perturbation, the wave collapses. it's very difficult to fine-tune that as it can be to the hundredths or even thousandths decimal place to tune it exactly as u'd like without the aforementioned issue happening. the particle configuration is in the MNU files as well, but u only start seeing it near the bottom. I think the wave is retroactive in that it begins a specific point with its crest and dips being specific points in relation to its original point which changes due to other variables. the beginning wave once u start the system is the first MNU after line 300 btw, so that's when it shifts to another MNU.

 

hey don't worry about derailing this thread, you guys are very knowledgeable and informative (and waves in on topic anyhow)

Well, my interest of writing here is two sided, first i thought it was a good timing for talking about the problem of compatibility between firmwares (is something i noticed lot of time ago, not only in your release but in others like brunolee, etc...), second i want to promote this kind of modding a bit because this way more people will be interested

and, to think, I thought I was the "wave" person in the scene since I've done innumerable tests with it. I can't imagine how long it too to mimic it on the pc. ur probably right in that they (sony) probably debugged the wave in order to fine tune it. perturbation = disturbance, possibly. perturbation makes the wave look fluid, so it pulsates from one end to the other. if the length is too high as well as its perturbation, the wave collapses. it's very difficult to fine-tune that as it can be to the hundredths or even thousandths decimal place to tune it exactly as u'd like without the aforementioned issue happening. the particle configuration is in the MNU files as well, but u only start seeing it near the bottom. I think the wave is retroactive in that it begins a specific point with its crest and dips being specific points in relation to its original point which changes due to other variables. the beginning wave once u start the system is the first MNU after line 300 btw, so that's when it shifts to another MNU.

There is another interesting effect used by the wave and sparks... in few words... they are taking inputs from the pad controller (yes, the dualshock is readed by them)
Is hard to explain with my crappy english, and very hard to notice when you look at the wave animation, but do this test:
- Change theme to "original" (with wave + sparks)
- In XMB, place the cursor at top of the left column (users)
- Press D-pad to right direction and keep it pressed until it moves to right column (friends)

Note how the directions of the sparks and the whole wave tends to move to the left (to the oppposite direction of the cursor)
This is trying to mimic the movement of air fluids... is like an turbulence that happens in the "air"
So... the wave and the sparks (the .elf's) knows where is located the cursor in XMB... it means are constantlly reading the position of the cursor... and this is weird, lol, and maybe usefull for us

*It works the same if you move in opposite direction from right to left. Also it works when you move UP-DOWN in any column where you have a long list of items displayed (try in XMB game column up and down)

----------
This gave me an idea when thinking about it...
We could replace the .elf's by 100% custom code.... because .elf's are programs... we could build a "cobra plugin manager" with it
Some of the features we need are actually supported, the most important are:
-Is displaying stuff in XMB... so is using his own display buffer where we can display anything we want... it will not generate any conflict with other display modes
-Is taking inputs from pad... so we can interact with it... this way we could navigate menues or turn on/off settings

 

that might explain y high perturbation causes the wave to move to the left as well. I believe the proc_iridiscent (the particles) tga is overlayed on top of the normal background. the backgrounds r upside down in the flash, so I think a mirroring effect is happening. the elf files inside the lines.qrc may also be responsible for other qrc files. there's no config or elf files in the icontex.qrc, and iirc, there's only a config (at least one) and no elf inside the icon file. I know they all work in unison considering the light passing through the icons is channeled by the wave itself.

 

alright, I've decrypted the latest rebug firmware's wave, and hex compared with the same on 4.46. the differences r in the ELF itself, not the config. however, significant differences could be attributed to a change, then compression. the configuration has nothing to do with it. only the ELF has been changed which could be as simple as a moderate change with the base of a particular value; then, compression alters the hex comparison significantly. that's usually obvious if subsequent hexes change over and over again.

 

just tested, but my vertical wave and icontex with the cobra on the users' tier work on 4.75.

 

so guys has this XMB modify installer been updated to 4.75/4.76?

from what I read from you guys here, the installer can be used to change start sound and the coldboot right? since the coldboot raf hasn't changed since 2.70 then if on 4.76 we can still install the cold boot raf and technically should still work ?

and the sound should work on all cfw 4.xx as well?

what can't be changed is the xmb waves? if you haven't, are there any plans for an update to make them work?

thanks in advance

 

so guys has this XMB modify installer been updated to 4.75/4.76?

from what I read from you guys here, the installer can be used to change start sound and the coldboot right? since the coldboot raf hasn't changed since 2.70 then if on 4.76 we can still install the cold boot raf and technically should still work ?

and the sound should work on all cfw 4.xx as well?

what can't be changed is the xmb waves? if you haven't, are there any plans for an update to make them work?

thanks in advance

Just checked out the coldboots, sound & waves they seem to work fine for me on REBUG 4.75 (which should work 4.76 also). Did notice a issue with installer though so I replaced/re-signed Eboot & updated icon as it wasn't very visible on green background:

XMB Modify Collection Installer v1.5.pkg

Edit: if I have time maybe I'll add a few more items to the collection & maybe update Gameboots

 

lol you saved me some time, I was gonna do it the old fashion way...I unpacked the pkg and saw the files were pretty simple just 1 coldboot raf and in the sound folders theres just 2. and so I when i went into mmOS looked in the dev_flash/vsh/resource folder there are all 3 files right next to each other...so I figured either through ftp or usb just to replace the raf with any one of the ones in your collection and the 2 audio files with the 2 from any of the sound folders! Im guessing that should've worked being that there were no other files in each of the cold boot folders nor in the audio .

then I was gonna test out the waves by just putting that one lines.qrc in the in the dev_flash/vsh/resource/qgl folder since the waves folder have just that one file each I figured thats all that needed. I even put my windows to show "hidden" files to make sure there was nothing else there.

I did install ferrox 4.76 and got the lines.qrc out of that one and did the md5 checksum, compared and verified it to what was listed in the lines.qrc page on ps3 dev wiki, and they're exactly the same. so no change since 4.60

lastly I was gonna just simply reassign the eboot for 4.76 and pack it all up again if everything i did above worked... so the steps I did or was going to do, would they have worked? sorry i just started exploring all this so not to familiar....yet :No0bZiLLa:

and thanks BITS for your response and your update, I know it wasn't necessary for you to do it and you're busy --so it is appreciated! and yeah, more items would be sweet!!

 

well after checking all the waves ...everything looked good. im on 4.76 ferrox.. did a few sounds...that was ok, did a few coldboots , but now im trying to change the coldboot and its saying there is an error!

error: not enough space to copy the file (coldboot.raf) to destination path (/All-All- Anonymous(shado 1664)/ PS3~dev_flash~vsh~resource/).

back up will be restored?

any ideas? seems to only be doing it for Anonymous coldboot

figured it out...didnt notice you could delete backups! :p

 

lastly I was gonna just simply reassign the eboot for 4.76 and pack it all up again if everything i did above worked... so the steps I did or was going to do, would they have worked? sorry i just started exploring all this so not to familiar....yet :No0bZiLLa:

this wouldn't have worked as somehow I got a bad EBOOT, the one in there now is signed 3.40 NPDRM and works fine (and should on new FWs)

 

nice!!! I was thinking when I did it of 4.21 but 3.40 is better still !! but like you said it was a bad eboot anyway...

alright thanks for letting me know...

hey and that error I mentioned above is still coming back with the "anonymous" coldboot raf and the Alienware raf as well! the backups are competely empty . do you know what it could be? I cycled through absolutely everything, all sounds, all waves, all rafs, and those are the only 2 that were problematic for me! on ferrox 4.76

thnx

 

nice!!! I was thinking when I did it of 4.21 but 3.40 is better still !! but like you said it was a bad eboot anyway...

alright thanks for letting me know...

hey and that error I mentioned above is still coming back with the "anonymous" coldboot raf and the Alienware raf as well! the backups are competely empty . do you know what it could be? I cycled through absolutely everything, all sounds, all waves, all rafs, and those are the only 2 that were problematic for me! on ferrox 4.76

thnx

I've had it say that to me once or twice on different files also, it seems a bug with installer as it's random. Try to exit then restart it and make that the first choice, I just tried and it worked for me