What's new

Solved Custom XeBuild INIs for building Glitch Images of Lower Dashes?

  • Thread starter SGCSam
  • Start date
  • Views 13,665
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
Hey Everyone,

I thought I'd preface this with as I'm discussing XeBuild, my console is an RGH1 exploited Falcon and NOT a retail, just thought I'd get that out of the way :tongue: (Also, just in case it's needed, my CB is 5771, LDV is 7)

So essentially, correct me if I'm wrong, but here's my generic and brief understanding of how RGH works: We're sending a small electrical pulse to the CPU to slow it down, and trick the CD verification to return true, in order for us to run a modified CF image to allow the execution of unsigned code.

With that in mind, assuming the CD verification passes, what should stop me from running any hacked CF image, on any dashboard version?

So in context, assuming I can create my own glitch.ini file for a lower dash in XeBuild and I have the filesystem for the Dashboard in question, could I theoretically create a NAND flash image of, say, 2.0.9199 for my RGH1? This is an issue at the moment as I can only create JTAG images for this dashboard and not RGH1 images (because the dash is so old), hence I'm trying to solve that.

Now, you might ask why I'd want to do such a thing. I already know and am totally aware that I cannot run newer games if I was to go back to a kernal that old. The reason being is because I'm recreating several UI elements from the older dashes and would ideally like to use them as source material. There's most likely a better way as well in terms of accomplishing the task, but I feel it'd also be quite a cool technical achievement as well as being cool to see the older dashes again :tongue:. I don't intend to keep it massively long term, so I'm not wasting my RGH for the sake of an older dash.

But yeah, if I have the dashboard filesystem, would it be possible for me to create a glitch.ini and hence a glitch image of older dashes to run on my RGH1?

If so, would someone be able to explain briefly how I'd go about performing it and/or linking me to some resources where I could learn myself? I'm not wanting a step by step guide (as I don't want to take up your time), just simply some explanation of whether such a thing is possible.

tl;dr Can I run old dashboards like 9199 on an RGH1 by building my own glitch.ini file, as XeBuild can't create RGH1 images for these older kernals?

Thanks!
 
ImOx

ImOx

(^._.^)ノ
Retired
Programmer MotM Platinum Record
Messages
9,961
Reaction score
2,963
Points
2,180
Sin$
0
So you're looking to downgrade your dashboard?
Short answer: not possible.

EDIT: Or apparently it is? f***, don't ask me lmao.
 
Last edited:
TEIR1plus2

TEIR1plus2

VIP
VIP
Hidden Devils
Frame In Gold Programmer A Milli
Messages
510
Reaction score
224
Points
305
Sin$
0
The reset signal doesnt slow down the processor, the processor gets slowed so its easier to target a specific operation (the memcmp) and then the reset signal basically corrupts the processor state. We use it to try and corrupt a specific part of the processor.

You would have more luck doing this with RGH2 because it glitches earlier in the bootchain. With RGH2 you would use split cb, both the same version, it would glitch when cba verifies cbb then everything after cbb you would use what ever dash files you want, you dont want to change the file its glitching the verification for because changing the data its checking changes glitch timing, instead use the files and patches that come with xebuild because they have been tested for good glitch timings. But once you have control, you can use whatever.

Thats also why its easier on rgh2, on rgh1 a lot will already be setup before you have control and idk what would be possible and what wouldnt. Recreating shadowboot could be another possibility to basically reboot into lower version bootloaders that have been patched.
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
So you're looking to downgrade your dashboard?
Short answer: not possible.
Ah, would the long answer be it technically IS possible but via a CPU swap (which IMO is just ridiculously overkill for the sake of backdating the dash, not at all worth it in my opinion)?

Also, if you wouldn't mind, what is it that actually stops me? Is it the eFUSE system implemented within the CPU?

If you wouldn't mind and it won't take up too much of your time, could you give me the long answer? I'm interested to know how the stuff works :tongue:
 
Last edited:
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
The reset signal doesnt slow down the processor, the processor gets slowed so its easier to target a specific operation (the memcmp) and then the reset signal basically corrupts the processor state. We use it to try and corrupt a specific part of the processor.

You would have more luck doing this with RGH2 because it glitches earlier in the bootchain. With RGH2 you would use split cb, both the same version, it would glitch when cba verifies cbb then everything after cbb you would use what ever dash files you want, you dont want to change the file its glitching the verification for because changing the data its checking changes glitch timing, instead use the files and patches that come with xebuild because they have been tested for good glitch timings. But once you have control, you can use whatever.

Thats also why its easier on rgh2, on rgh1 a lot will already be setup before you have control and idk what would be possible and what wouldnt. Recreating shadowboot could be another possibility to basically reboot into lower version bootloaders that have been patched.

Ah, I see! So the CPU itself is slowed down BEFORE we even send the pulse to begin the glitch?

So with RGH2, am I correct in saying that it ignores the eFUSE system because it glitches earlier in the boot process like you said, hence is that why I couldn't do this on an RGH1? Also, would I be correct in assuming this would also be applicable to an RGH1.2 as it uses glitch2 images?

So in context, let's say for the sake of the argument I had a Falcon RGH2 system. I would first have to create a glitch2.ini for XeBuild for 9199. As you said, I would use the split CB - would I also have to use the corresponding CD bootloader as well (as obviously, 9199 would have used an older one). But by that point, could I simply change CF and CG to 9199, update the flashfs section to the extracted filesystem then build the image? Now if that's the case, could you point me in the direction of some documentation/explain how to create such an ini? It'll probably be really easy to find, I'm just not sure exactly what to search for to find what I need.

If I'm overthinking or just going in the completely wrong direction then please let me know :tongue: And yeah, sorry for the tons of questions, I just feel it'd be better to get a good understanding of what's physically going on hardware wise as once I understand that, it makes it easier to translate to the software side. Plus, the whole RGH process in of itself is pretty cool and awesome to learn about :biggrin:
 
ImOx

ImOx

(^._.^)ノ
Retired
Programmer MotM Platinum Record
Messages
9,961
Reaction score
2,963
Points
2,180
Sin$
0
Ah, would the long answer be it technically IS possible but via a CPU swap (which IMO is just ridiculously overkill for the sake of backdating the dash, not at all worth it in my opinion)?

Also, if you wouldn't mind, what is it that actually stops me? Is it the eFUSE system implemented within the CPU?

If you wouldn't mind and it won't take up too much of your time, could you give me the long answer? I'm interested to know how the stuff works :tongue:
Thing is, I'm not able to give you the long answer :'-D
TEIR1plus2 TEIR1plus2 sure can tho (unless he already did? I'm in a hurry, didn't read all the posts here yet)
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
Last edited:
TEIR1plus2

TEIR1plus2

VIP
VIP
Hidden Devils
Frame In Gold Programmer A Milli
Messages
510
Reaction score
224
Points
305
Sin$
0
Ah, I see! So the CPU itself is slowed down BEFORE we even send the pulse to begin the glitch?

So with RGH2, am I correct in saying that it ignores the eFUSE system because it glitches earlier in the boot process like you said, hence is that why I couldn't do this on an RGH1? Also, would I be correct in assuming this would also be applicable to an RGH1.2 as it uses glitch2 images?

So in context, let's say for the sake of the argument I had a Falcon RGH2 system. I would first have to create a glitch2.ini for XeBuild for 9199. As you said, I would use the split CB - would I also have to use the corresponding CD bootloader as well (as obviously, 9199 would have used an older one). But by that point, could I simply change CF and CG to 9199, update the flashfs section to the extracted filesystem then build the image? Now if that's the case, could you point me in the direction of some documentation/explain how to create such an ini? It'll probably be really easy to find, I'm just not sure exactly what to search for to find what I need.

If I'm overthinking or just going in the completely wrong direction then please let me know :tongue: And yeah, sorry for the tons of questions, I just feel it'd be better to get a good understanding of what's physically going on hardware wise as once I understand that, it makes it easier to translate to the software side. Plus, the whole RGH process in of itself is pretty cool and awesome to learn about :biggrin:
With RGH2 we have the ability to patch out the fuse check in cbb, but I'm not completely sure if the XeBuild patches take care of it. Like I said, changing the data being verified effects glitch timing, to the point where while developing the RGH method, they would add random bytes to empty space of the file being verified to try and get it to boot. Because of that, they added the minimal patches needed to run unsigned code (patching out the hash check for the next BL) and then did whatever needed to get it to boot. I'm not sure if those minimal patches included the fuse check because I personally haven't checked.
TLDR of the above: don't screw with cba and cbb.
When using RGH2, you can use whatever CD/CF/HV/Kernel your system once supported (eg slims can't run 9199 but all phats can). You will have to frankenstein the patch files xebuild uses because RGH wasn't around back when 9199 was out so there are no patches for an RGH 9199 image. The way I would accomplish this is taking a 17511 ini, leaving the cba and cbb info alone but replacing the CD/CF info with stuff from a 9199 jtag image. Then open the patch files for the 17511 RGH2 image and the 9199 JTAG image, leave the cbb patches alone in the RGH2 file but replacing the rest with the corresponding JTAG patches. They aren't labeled, so you'll have to know what you're doing.

While this is completely possible, it will likely require specific custom patches, because the JTAG is really different than RGH in how they work. For one JTAG images have 2 kernels in them while RGH has one. When a JTAG boots, it completely boots retail until around when the HV or Kernel is loaded, then it exploits, and reboots into the hacked image. When RGH boots, it glitches a check and the rest is already patched/hacked. Because of this, JTAG has a lot of patches that are not needed on RGH and relies on a custom SMC as well.

I'm not sure this method would work on RGH 1.2 because I personally don't know where it glitches.

If you plan on doing this, you should have a way to flash the nand by hardware, a UART, and a POST sniffer.
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
With RGH2 we have the ability to patch out the fuse check in cbb, but I'm not completely sure if the XeBuild patches take care of it. Like I said, changing the data being verified effects glitch timing, to the point where while developing the RGH method, they would add random bytes to empty space of the file being verified to try and get it to boot. Because of that, they added the minimal patches needed to run unsigned code (patching out the hash check for the next BL) and then did whatever needed to get it to boot. I'm not sure if those minimal patches included the fuse check because I personally haven't checked.
TLDR of the above: don't screw with cba and cbb.
When using RGH2, you can use whatever CD/CF/HV/Kernel your system once supported (eg slims can't run 9199 but all phats can). You will have to frankenstein the patch files xebuild uses because RGH wasn't around back when 9199 was out so there are no patches for an RGH 9199 image. The way I would accomplish this is taking a 17511 ini, leaving the cba and cbb info alone but replacing the CD/CF info with stuff from a 9199 jtag image. Then open the patch files for the 17511 RGH2 image and the 9199 JTAG image, leave the cbb patches alone in the RGH2 file but replacing the rest with the corresponding JTAG patches. They aren't labeled, so you'll have to know what you're doing.

While this is completely possible, it will likely require specific custom patches, because the JTAG is really different than RGH in how they work. For one JTAG images have 2 kernels in them while RGH has one. When a JTAG boots, it completely boots retail until around when the HV or Kernel is loaded, then it exploits, and reboots into the hacked image. When RGH boots, it glitches a check and the rest is already patched/hacked. Because of this, JTAG has a lot of patches that are not needed on RGH and relies on a custom SMC as well.

I'm not sure this method would work on RGH 1.2 because I personally don't know where it glitches.

If you plan on doing this, you should have a way to flash the nand by hardware, a UART, and a POST sniffer.

Thanks for that wealth of information TEIR1plus2 TEIR1plus2 ! I'm going to take a look into replacing the patches and see if I can figure it out, but like you said, the JTAG operates differently to the RGH in terms of how they boot so you're correct about having to make a custom patch - again, I'll take a look.

With an RGH1.2, that could be a weird one as it is very similar to RGH1 hardware wise, but is similar to RGH2 software wise (in terms of the generated NAND image). Perhaps the fact it uses FT6U1 as its POST point rather than FT6U7 may give us a clue as to where in the boot process the glitch begins - again, that thesis could be entirely wrong, you seem to know a lot more about the glitch than I do.

I've got my NAND-X and NAND wires (with such a "hacky" process as this, I definitely wouldn't attempt it if I was unable to rewrite via hardware). I'm going to have to look into a POST sniffer but if I can use that to get the POST data from the points and translate them into where we are in the boot process (I'd assume this free60 thread would be of great use: http://free60.org/wiki/POST), that'll be very useful indeed!

Thanks so much for your help! I'll take a look into this at some point soon and let you know if I can come up with anything. Not going to lie, I'm not holding out too much hope myself, but I'll give it a go - it's a bit of a fun mini-project to have a go at :biggrin:
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
With RGH2 we have the ability to patch out the fuse check in cbb, but I'm not completely sure if the XeBuild patches take care of it. Like I said, changing the data being verified effects glitch timing, to the point where while developing the RGH method, they would add random bytes to empty space of the file being verified to try and get it to boot. Because of that, they added the minimal patches needed to run unsigned code (patching out the hash check for the next BL) and then did whatever needed to get it to boot. I'm not sure if those minimal patches included the fuse check because I personally haven't checked.
TLDR of the above: don't screw with cba and cbb.
When using RGH2, you can use whatever CD/CF/HV/Kernel your system once supported (eg slims can't run 9199 but all phats can). You will have to frankenstein the patch files xebuild uses because RGH wasn't around back when 9199 was out so there are no patches for an RGH 9199 image. The way I would accomplish this is taking a 17511 ini, leaving the cba and cbb info alone but replacing the CD/CF info with stuff from a 9199 jtag image. Then open the patch files for the 17511 RGH2 image and the 9199 JTAG image, leave the cbb patches alone in the RGH2 file but replacing the rest with the corresponding JTAG patches. They aren't labeled, so you'll have to know what you're doing.

While this is completely possible, it will likely require specific custom patches, because the JTAG is really different than RGH in how they work. For one JTAG images have 2 kernels in them while RGH has one. When a JTAG boots, it completely boots retail until around when the HV or Kernel is loaded, then it exploits, and reboots into the hacked image. When RGH boots, it glitches a check and the rest is already patched/hacked. Because of this, JTAG has a lot of patches that are not needed on RGH and relies on a custom SMC as well.

I'm not sure this method would work on RGH 1.2 because I personally don't know where it glitches.

If you plan on doing this, you should have a way to flash the nand by hardware, a UART, and a POST sniffer.

Hey again TEIR1plus2 TEIR1plus2 . Just gave this a shot - I've managed to get the glitch2.ini setup fine for 9199 and xeBuild itself builds the image without issue.

However, my console just glitches infinitely when attempting to boot. From what you said and from what I'm attempted, I'm nearly 100% sure my patches_g2falcon.bin file that I created is wrong. Not going to lie, I HIGHLY expected that to be the case as nothing was labelled like you said?

Do you know of any documentation or information yourself which could assist me further in understanding how the patches files and the xeBuild INIs work (I couldn't find anything)? Again, not trying to be "give me the answers plz" person, I want to learn but if you could point me in the right direction, I'd appreciate it. True, this is probably more work than it's worth but I don't like giving up on projects :tongue:

I'm also going to further research UART and POST sniffing so I can see where in the boot process the 360 is failing so I can debug myself, but yeah.

Also, if anyone else has their own input to make, please feel free :biggrin:
 
Last edited:
BlueSn00w

BlueSn00w

RGH/JTAG Seller
Messages
256
Reaction score
41
Points
95
Sin$
7
Hey again TEIR1plus2 TEIR1plus2 . Just gave this a shot - I've managed to get the glitch2.ini setup fine for 9199 and xeBuild itself builds the image without issue.

However, my console just glitches infinitely when attempting to boot. From what you said and from what I'm attempted, I'm nearly 100% sure my patches_g2falcon.bin file that I created is wrong. Not going to lie, I HIGHLY expected that to be the case as nothing was labelled like you said?

Do you know of any documentation or information yourself which could assist me further in understanding how the patches files and the xeBuild INIs work (I couldn't find anything)? Again, not trying to be "give me the answers plz" person, I want to learn but if you could point me in the right direction, I'd appreciate it. True, this is probably more work than it's worth but I don't like giving up on projects :tongue:

I'm also going to further research UART and POST sniffing so I can see where in the boot process the 360 is failing so I can debug myself, but yeah.

Also, if anyone else has their own input to make, please feel free :biggrin:
you have a hardware nand flasher right
 
ddxcb

ddxcb

Contributor
Messages
1,647
Reaction score
275
Points
285
Sin$
0
WTF did i just read?

you can boot to any dashboard as long the system it self can run it, with the rgh/smc(jtag) hack.
ie xenon can run anything 1888+ where jasper can't run that far down.

If you want the old dash to be hacked you must port the patches or run it with out any.

Edit: also about needing to be rgh2 for to hack the cb_2 is pointless, since its rgh1 all he needs to do is either run an older CD or run a hacked one to run the older kernels.
 
Last edited:
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
WTF did i just read?

you can boot to any dashboard as long the system it self can run it, with the rgh/smc(jtag) hack.
ie xenon can run anything 1888+ where jasper can't run that far down.

If you want the old dash to be hacked you must port the patches or run it with out any.

Edit: also about needing to be rgh2 for to hack the cb_2 is pointless, since its rgh1 all he needs to do is either run an older CD or run a hacked one to run the older kernels.
That's awesome but if that's the case, and Jasper's can't run that far down then that begs the question - how far can each motherboard revision go down?

With porting the patches, how easy/difficult would it be to port the patches over (I'm assuming this is in reference to the patches_boardrevision.bin correct?)? That again begs the question of whether or not I should just run without any patches?
 
Last edited:
XeX RageQuit

XeX RageQuit

Add Me on SnapChat XeXRageQuit
Messages
237
Reaction score
23
Points
100
Sin$
7
That's awesome but if that's the case, and Jasper's can't run that far down then that begs the question - how far can each motherboard revision go down?

With porting the patches, how easy/difficult would it be to port the patches over (I'm assuming this is in reference to the patches_boardrevision.bin correct?)? That again begs the question of whether or not I should just run without any patches?
xenons as said above can go to 1888 but not all xenons can if their mfr date is 2006 and zephrys are 45xx and falcons are 6683 i think and for jaspers the lowest ive seen is 6717 and 73xx as for trinitys im pretty sure they are 12xx and above
this is a bit out dated but might help you out https://www.se7ensins.com/forums/threads/downgrading-your-xboxs-firmware.259264/
http://download.happytvgame.com/xbo...l_Eng/Xbox360/Timing_Attack_Infectus/pag1.htm
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
Hey everyone, so here's where we're at.

I've created a glitch.ini file for 9199 for my Falcon RGH1, which looks like the following:

Falcon Section
z6jNwVU.png


flashfs Section
yXO2f7b.png


And I used JRunner to create my XeBuild Falcon glitch 9199 image - there were no errors in the log, everything appeared to proceed and build as normal.

However, when I power on my console, my glitch chip pulses as if it's attempting to glitch as normal (it pulses for 1 or 2 cycles - normal for my boot times). The pulses stop as if the glitch succeeded but then nothing happens. I get no output on the screen, nothing abnormal seems to be happening with my glitch chip and I don't get any sort of RROD.

I CAN, however, boot Xell with the image I wrote to the console so that appears to be working fine. As the image itself seems to have been created without issue, I can only surmise that something is wrong with my ini or my patches file (I should also add that my HDD is disconnected so this can't be a plugin issue).

I did have to go through and manually change the hex after each .xex in the ini file as XeBuild was expecting a different size than was there by default - once I changed the values to what XeBuild expected, the image as able to be created without issue - perhaps this may offer a clue?

If any of you have further input or have an idea of what's going on, that'd be awesome. If you need more information from me, just let me know and I'll be happy to let you know as much as I can :biggrin:
 
xenons as said above can go to 1888 but not all xenons can if their mfr date is 2006 and zephrys are 45xx and falcons are 6683 i think and for jaspers the lowest ive seen is 6717 and 73xx as for trinitys im pretty sure they are 12xx and above
this is a bit out dated but might help you out https://www.se7ensins.com/forums/threads/downgrading-your-xboxs-firmware.259264/
http://download.happytvgame.com/xbo...l_Eng/Xbox360/Timing_Attack_Infectus/pag1.htm
Thanks for that XeX RageQuit XeX RageQuit , but from the post you sent, the Infectus chip only appears to work with 45xx kernals? I will have another look into the links you sent but I think using an Infectus and setting it all up may be a bit overkill. However, if it becomes evident that'd be the easiest solution, I'll consider it. Thanks!
 
Last edited:
TEIR1plus2

TEIR1plus2

VIP
VIP
Hidden Devils
Frame In Gold Programmer A Milli
Messages
510
Reaction score
224
Points
305
Sin$
0
xenons as said above can go to 1888 but not all xenons can if their mfr date is 2006 and zephrys are 45xx and falcons are 6683 i think and for jaspers the lowest ive seen is 6717 and 73xx as for trinitys im pretty sure they are 12xx and above
this is a bit out dated but might help you out https://www.se7ensins.com/forums/threads/downgrading-your-xboxs-firmware.259264/
http://download.happytvgame.com/xbo...l_Eng/Xbox360/Timing_Attack_Infectus/pag1.htm
all xenons can run 1888. The limiting factor is hardware revisions and all xenons have the same hardware.

You can do it with RGH1 and RGH2, but they require patches being ported. You either need to have someone else build the patches for you or learn how the hacks work and what each patch is doing yourself and port them over.
 
XeX RageQuit

XeX RageQuit

Add Me on SnapChat XeXRageQuit
Messages
237
Reaction score
23
Points
100
Sin$
7
all xenons can run 1888. The limiting factor is hardware revisions and all xenons have the same hardware.

You can do it with RGH1 and RGH2, but they require patches being ported. You either need to have someone else build the patches for you or learn how the hacks work and what each patch is doing yourself and port them over.
weird cuz i have a xenon on 4548 ldv 0 and tried downgrading to 1888 and just get rrod when i try
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
all xenons can run 1888. The limiting factor is hardware revisions and all xenons have the same hardware.

You can do it with RGH1 and RGH2, but they require patches being ported. You either need to have someone else build the patches for you or learn how the hacks work and what each patch is doing yourself and port them over.

TEIR1plus2 TEIR1plus2 , do you know of any documentation/tutorials of how to port the patches over so I can learn? Or am I on my own here?

Also, would you or anyone else be willing to help with porting said patches over?
 
TEIR1plus2

TEIR1plus2

VIP
VIP
Hidden Devils
Frame In Gold Programmer A Milli
Messages
510
Reaction score
224
Points
305
Sin$
0
TEIR1plus2 TEIR1plus2 , do you know of any documentation/tutorials of how to port the patches over so I can learn? Or am I on my own here?

Also, would you or anyone else be willing to help with porting said patches over?
The patch files follow a specific pattern/struct layout
Code:
struct
{
    u32 PatchOffset;
    u32 InstructionCount;
    u32 Instruction[InstructionCount];
} PATCHES;

struct
{
    PATCHES PatchesCBB[num_of_CBB_patches]; // cbb patches
    u32 EndCBB = 0xFFFFFFFF;
    PATCHES PatchesCD[num_of_CD_patches]; // cd patches
    u32 EndCD = 0xFFFFFFFF;
    PATCHES PatchesHV[num_of_HV_patches]; // HV/Kernel patches
    u32 EndHV = 0xFFFFFFFF;
};
Thats for g2 patch files, other exploits have more patches
I have the patches for my old trinity labeled as an example, I would recommend you brush up on PPC for this so you know whats being patched and can port them

trinity patches for IDA 6.8:
[Click here to view this link]
Virus Scan: https://www.virustotal.com/#/file/b...58add91d639c623d39d50ca0534b0ac2bd773/details

after looking at the rgh2 patches, it does look a lot easier to do it with rgh2, you'd just use the CF and CG for 9199 and copy the HV/Kernel patches over the HV/Kernel patches in the targetted patches file.
 
Last edited:
Top Bottom
Login
Register