PS3 XForge PS QRC Tool - Modifying aspects of the XMB is now easier then ever.

We have seen many XMB visual mods published so far in the lifetime of the PS3 but the QRC format (a type of container) has been always problematic, tricky, and very restricted. XForge is intended to solve all this problems once for all, it allows full freedom to rebuild the QRC files and modify all his contents

There are many files inside the QRC containers that are candidates to be modified, XForge is the first tool that allows to modify them in a "noob friendly" way, everything made from a intuitive interface with preview panels

Say goodbye to the previous manual methods that required dealing with zlib compressed files or injecting them with a hex-editor to create a custom wave, to replace XMB main icons, to change background wallpapers, etc... XForge supersedes all that tutorials, manuals methods, and tools, there is a long list of features supported by XForge, for more detailed descriptions see the feature list below​

-@sandungas​

Download: XForge​

Feature List_________________________________________________________________________________________

• All QRC file types supported (QRCC and QRCF)
• ZLIB compression and decompression transparent management (no user interaction needed)
• Individual extraction/injection of files of any size
• Full extraction of all files, using an additional xml control file for rebuilding purposes
• Full rebuilding from the xml control file, generates QRC files identicals to the originals
• QRCC to QRCF, and QRCF to QRCC conversions, generates files identicals to the originals
• Build custom QRC files 100% from scratch, or adding/removing files from the officials
• Several display panels: FileList (all types), TextViewer (MNU, TXT, INI, PATH), ImageViewer (BMP, JPG, TGA, DDS), HexViewer
• Compatibility with sce-cgcdisasm.exe (tool not included in XForge releases) to dissassemble FPO and VPO files on the fly
• Syntax highlighting in the TextViewer for MNU, TXT, INI, PATH (and optionally FPO and VPO)
• MD5 hash info of QRC files and all his file contents, with identification of official files (initial support)
• Advanced QRC internal structure file info (for debugging, development or research purposes)
• Optional custom file extension system icons for QRC.ico and QRCF.ico
• Optional custom file extension renaming at extraction time
• Extensive drag and drop features - Drag files into XForge from Windows explorer, and out of XForge to Windows explorer.
• Ability to open 2 or more XForge instances with different QRC's and drag-and-drop files between them.
• Double click files on filelist to open them in your preferred editor application that's associated with that file type
• Compatible with Microsoft Windows XP onwards (requires .Net framework 4.0)

[TABLE STYLE=class:prefix prefixBlue, border-width:0px, width:100%][TR][TD]Screenshots_________________________________________________________________________________________[/TD][/TR][/TABLE]
System icons

MNU, TXT, INI, PATH viewer with syntax highlighting

FPO/VPO viewer and dissassembler with syntax highlighting

BMP, JPG, TGA, and DDS imageviewers

Hexviewer

Videos________________________________________________________________________________________________

[TABLE STYLE=class:prefix prefixBlue, border-width:0px, width:100%][TR][TD]Tutorials______________________________________________________________________________________________[/TD][/TR][/TABLE]

Full build Individual file replacements QRC/QRCF direct conversions

• 
  This building method is inspired by rcomage, at extraction time XForge generates a XML control file for rebuilding purposes (located at root of the extraction path). The QRC file is built by loading the XML control file
  
  1) Open the QRC file with [File]>[Open]
  2) Extract all contents from the QRC file with the option [File]>[Extract All]. This will create a control XML file
  3) At this point you can modify or replace all extracted files
  4) Build the new QRC file by using the control XML file with the option [File]>[Open]
  
• 
  This method allows to replace individual files by using the buttons in XForge interface
  
  1) Open the QRC file with [File]>[Open]
  2) Extract files individually with the button [Extract File]
  3) Replace files individually with the button [Replace File]
  4) Save QRC file with the button [Save QRC File]
  
• 
  This is a direct conversion in between QRC and QRCF
  
  1) Open the QRC/QRCF file with [File]>[Open]
  2) Convert the file with [Tools]>[Convert]>[QRC to QRCF] or [QRCF to QRC]
  

Credits, History, and Changelog________________________________________________________________

Credits History Changelog

• 
  First our team
  @pink1 Programming & development, research of the qrc format
  @sandungas For texting, icons/images, research of the qrc format & development consulting
  @DeViL303 For getting the team together with the idea of making the app, researching modding the qrc, texting & development consulting
  @Berion For texting & development consulting
  I can't thank these guys enough for all of the time and energy they put into this.
  
  We'd like to give credit to all of the other developers and members from over the years who have helped in any way.
  
• 
  Working with @sandungas @DeViL303 & @Berion over the past few weeks we have been able to make a few good jumps with the ps3 QRC file(mainly the earth.qrc).
  
  1. First we were able to replace files the same size or smaller(cool but not really new).
  2. After looking at the wiki for awhile we thought why not try editing the TOC (we know all of the values from the work of the amazing guys that reversed the format). This worked! We were able to expand the size of the files inside of the qrc.
  3. After playing with that we decided to try extracting the qrc to a folder then building a new one from it. To do this we also create a xml file with the a list of the qrc files in the order they are inside the qrc.
  4. This xml is used to build the new qrc. We have two spaces for each file first we have the source file then we have the id(the name in the qrc). By editing this file we can build a custom qrc only needing to extract & then build in the program after editing.
  5. Specific imageviewer preview modes for the special DDS file formats (mimicking the look of PS3 XMB)
     
  6. Specific textviewer syntax corrections for problematic files (EOL windows to unix conversions, standarization of control characters)
• 
  Initial release
  

 

It's live

 

Really amazing work @pink1.

 

Amazing tool, thanks!

 

If someone have a suggestion, finds a problem, or have some doubt about how to use XForge just tell, all feedback is welcome

 

Maybe this should be turned into a resource and also front paged, I think its awesome.

Anyone know what to look for when swapping vpo/fpos, what kind of things need to match to be compatible replacements? I have had some luck but just random really.

 

I forgot to mention that I don't have this up on GitHub yet but if anyone needs the source before I get it done let me know and I'll try getting you a copy.

 

I don't have this up on GitHub yet but if anyone needs the source before I get it done let

Have you removed all that white space and its optimised.....??

If you'd updated what's there as you went along I would've looked into adding stuff for the VPO and FPO's, if it could be done at all without basically having to make new ones ( which could have been added to the tool as options anyways ), but tbh I gave up after I saw it wasn't being updated and stopped trying to reverse engineer the FPO's and VPO's and haven't touched them since I did the first basic disassembly of them.

And now for the moment I have lost all interest in it, and anything PS3 related for that matter, but the basics have been done and uploaded to the OG thread in my posts on the GIA QRC thread, disassembly wise, for anyone else who might want to take a crack at it.

For other's reading...

A word to the wise... If you have no clue in CG Programming or or not familiar with OpenGL, OpenGL ES 2.0 or PSGL then don't bother unless your willing to learn this, or at very least the basics, as you will not get very far as it's not as simple as swapping them about, you might be able to find a few patches to change things and a few swaps but that will be for the attributes in them that are already hardcoded in them and nothing else and they must corresponding to the environment of GIA you are swapping them to or it will have no effect or adverse effects.

One tool I can tell you that you will need thats free, if you don't have the SDK, is Nvidia CG Toolkit which you can download from their site under Legacy Downloads, it might not be fully adequate but it will help.

 

A word to the wise... If you have no clue in CG Programming or or not familiar with OpenGL, OpenGL ES 2.0 or PSGL then don't bother unless your willing to learn this, or at very least the basics, as you will not get very far as it's not as simple as swapping them about, you might be able to find a few patches to change things and a few swaps but that will be for the attributes in them that are already hardcoded in them and nothing else and they must corresponding to the environment of GIA you are swapping them to or it will have no effect or adverse effects.

Swapping will do me until you publish all your data

If you'd updated what's there as you went along I would've looked into adding stuff for the VPO and FPO's, if it could be done at all without basically having to make new ones ( which could have been added to the tool as options anyways ), but tbh I gave up after I saw it wasn't being updated and stopped trying to reverse engineer the FPO's and VPO's and haven't touched them since I did the first basic disassembly of them.

Just so you know. The app does not do anything with VPO and FPO files except display the EXACT SAME data that you copy and pasted from the SDK tool, so there is nothing in the source that will help you or hinder you when it comes to reverse engineering FPOs and VPOs.

So I'm not really sure why pink1 not publishing source "as he went along" (before the apps release) is your reason to give up reverse engineering them.....

 

This is nothing special, but I swapped out ToneApplyDisplay.fpo in lines.qrc with a different fpo.It gives these vertical lines and 1 diagonal line behind the XMB icons layer but above the wave layer.

It also creates this kind of liquidy effect where the wave overlaps itself:

 

Small thing while i think of it.

Can we get rid of this extra confirmation pop up? because that along with the yes no dialogue it is slowing me down. We don't need both really. Just the yes no pop up would probably do IMO.

 

This is nothing special, but I swapped out ToneApplyDisplay.fpo in lines.qrc with a different fpo.It gives these vertical lines and 1 diagonal line behind the XMB icons layer but above the wave layer.

View attachment 25169

It also creates this kind of liquidy effect where the wave overlaps itself:

View attachment 25170

Nice effect in the wave, if we can have this effect without those lines would be cool

 

The app does not do anything with VPO and FPO files except display the EXACT SAME data that you copy and pasted from the SDK tool, so there is nothing in the source that will help you or hinder you when it comes to reverse engineering FPOs and VPOs

I never said anything like it did or did not.... If you read correctly I wanted ADD stuff to do with these files.

Copy and pasted LOL.... I used no tool from the SDK to dismantle these so your assumption is incorrect, I use the SDK to compile only, there is tools in there for this but I not a fan of CMD Line tools for bulk work that takes hours, the tools I used have a GUI and more features than the tools in the SDK and are not made by S@ny but are for the PS3 and are made by Nvidia for the RSX and given only to Dev's, they are the tools I used at work when learning CG Programming, and XForge does not display the exact same info as the tool's I used, far from the same amount of info and neither does it show the same info as the tools in the SDK either.

XForge show's a fraction of the info compared to the tools I use for the VPO and FPO's.

There are more tools than just the ones in the SDK for doing things on the PS3, plenty of dev companies create their own tools for the various jobs and tasks.

Also I never said anything about the source for the tool help with these files in any way. Only to add things to do with these files and knowing the direction the app was evolving helps.

So I'm not really sure why pink1 not publishing source "as he went along" (before the apps release)

And didn't say publish either, pink1 knows exactly what I am on about.

your reason to give up reverse engineering them.....

Part of the reason, the others are, no offence, none of anyone's business so I said nothing about these.

 

Ok man.

I look forward to seeing these VPO/FPO skills some day on my PS3 in a QRC.

 

I had misunderstood and thought I had sent you what you were needing & was having trouble with GitHub. I would have been happy to share if you had said something. I'm old and forgetful lol

 

Some suggestions for new features. I have more but here are 3 for now.

1. More accurate drag and drop so you can drag one file from the list to another file easily. This would require auto scrolling when you get to top and bottom of window while dragging.

2. To be able to edit an mnu in preview window, then save qrc with one button without having to save the mnu edit with another button. So you could edit a load of mnus, then click "save qrc" and it will save all edits and build qrc? or something like that.

3. Ability to push the currently opened qrc to a specified FTP path in one button. Maybe just add a "send" button and maybe a user customisable path in settings for people who are running qrcs from hdd etc?

 

The FTP thing could just be done through windows explorer really. No need to add any ftp stuff really is there?

 

Just a clarification about FPO and VPO files
The tools either in the SDK or other alternative tools like the ones cypher mentioned from nvidia are generating "intermediate" files, the only purpose of that files is to deduce how it was looking the original source code
But after you deduce the source code of a file all that "intermediate" files are pointless, you dont need them anymore

What you see in that "intermediate" files is the dissassembled code, in "machine language" (the language used by the processor, in this case the RSX, composed by a very limited amount of instructions)
Our goal is to convert the files from original VPO/FPO ---> to dissassembled ---> to source code

But that conversion in between dissassembled to source code is a high jump, is required technical documentation to know what means each instruction, to have some C programming knowledge, and a bit of CG too
Keep in mind the whole list of instructions, and C and CG functions are not going to be used by the VPO and FPO files... lets say if the total is 100% the PS3 probably is going to be using an small set of 40% or so... so is not needed to be an expert and to understand everything, you can focus in the "most used" stuff

Also, the tools and the RSX profile files to compile that VPO and FPO files are available in internet (dont ask where) so you can use the old tactic of "test and error"
To do this you need to understand a bit what the original file was doing though, but just as example...
If you know the first function most at top is doing some kind of "if-else" then you can start writing your source code in CG with an if-else most at top... then compile it and compare the original VERSUS your file in a hexeditor
If you did it right you are going to see the bytes most at top in the files are identical

And so on... from top of the file down to the botton, function by function writing your owns manually, and compiling and comparing the files in hexeditor tenths of times
It works... but get ready to lost a bit of your humanity in the process, lol

 

Also, the tools and the RSX profile files to compile that VPO and FPO files are available in internet (dont ask where) so you can use the old tactic of "test and error"
To do this you need to understand a bit what the original file was doing though, but just as example...
If you know the first function most at top is doing some kind of "if-else" then you can start writing your source code in CG with an if-else most at top... then compile it and compare the original VERSUS your file in a hexeditor
If you did it right you are going to see the bytes most at top in the files are identical

And so on... from top of the file down to the botton, function by function writing your owns manually, and compiling and comparing the files in hexeditor tenths of times
It works... but get ready to lost a bit of your humanity in the process, lol

Well, i forgot to add another super important step in this "test-error" procedure

After you create your guinea_pig.c (source code) you need to compile it, and use a tool to "dissassemble" it (as example sce-cgcdisasm.exe)
The goal is to write a source code that generates the same "dissassembled" output in both

Comparing the output of that tools is a lot easyer than comparing the compiled files in the hexeditor, both methods could come in handy though

 

Btw, the files particles.elf and spline.elf inside lines.qrc are a huge attack vector to trigger exploits

I dont really know which signature or keys are using, or if they have some kind of specific "antihacking" protection, but i guess they have some special protection

Since the release of XForge is very easy to replace the .elf files inside lines.qrc by any other .elf compiled from 100% custom source code

 

Our goal is to convert the files from original VPO/FPO ---> to dissassembled ---> to source code

That is partially done already and in the zip files I uploaded to @DeViL303 s OG thread on this, on the the functions remain to be turned into source. They are any file with the header file extensions > .h. I have another tool for breaking down the functions to source. So there is a very good base for anyone else to have a go at it.

to compile that VPO and FPO files are available in internet (dont ask where)

Nvidia CG Toolkit > it free on the site under legacy downloads for anyone to download so saying don't ask where is pointless when its allowed to be downloaded by anyone.

Its the info on how to code for the RSX that is not to be told where it is, if you don, have this info then it's pointless useing the CG ToolKit as you need RSX - PSGL specific coding and instructions.

100% the PS3 probably is going to be using an small set of 40% or so...

I have already said all this.... In the OG thread and I found plenty of evidence of strippped functions from most of the files, it's much better to compile to OG file > test and strip not used or needed functions then recompile with the striped functions removed properly and not left in the file, this to me is just laziness and the part of the OG devs of this.

have some C programming knowledge, and a bit of CG too

That helps but you cannot just get away with " just " knowing this, you need to know PSGL for the PS3.

After you create your guinea_pig.c (source code) you need to compile it, and use a tool to "dissassemble" it (as example sce-cgcdisasm.exe)
The goal is to write a source code that generates the same "dissassembled" output in both

If your goal is to create your own VPO and FPO files then the disassembled info is NOT going to be the same as the OG files.

Seriously what is it with you and overcomplicating EVERYTHING....?