Hacking Queen's Blade: Spiral Chaos Translation Project ( Hackers needed )

Final_Agent · Oct 24, 2015

Wow am I out of my league. Okay, okay... I'll just try and take it slow, I've never done any hex work whatsoever but I'm not averse to learning.

So, the dump Zero helped us get a hold of give us a variety of .log files (and other types of files) to make use of. Using MadEdit, and placing the encoding to SHIFT-JIS, and using your example of the first line of spoken dialogue, I was able to search through the dump .logs themselves rather than our little conversion .txts we used to poke through with google translate and find said line exactly where you said it'd be, 0017e1b0.log. I'll be needing someone to type out lines for me in japanese that means, fortunately, we got our translator to help with that.

Next, you said that the hex location I found for the lines within file 0017e1b0.log is however, a location based on its dumped form and needs to be found within its original shared.bin's form. Essentially, I need the location of our sub file (0017e1b0.log) within the original archive (shared.bin) if I want to do any kind of real editing sometime.

Now here's where I get a little lost, how did you know that the sub file's location within the archive was 0x17d800? I mean, I looked at it, used MadEdit's position search function to look at it, and it makes sense at a glance, resembling the dumped files a little as far as I could tell, but how you came up with that specific hex location is the part I can't figure out. Similarly, how did you know the file entries table for the archive started at 0x17da00 and that the table entry for the sub file starts at 0x17da08, I mean, what's that between 00 and 08? I'm just trying to get my logic down first, was there a step you omitted because its something people with experience in hex would see at a glance? Or am I just blind and I missed one of the dump files plainly listing the hex locations?

flame1234 · Oct 24, 2015

How did you know that the sub file's location within the archive was 0x17d800?

That one is quite easy.
1) Open shared.bin
2) Go to 0x17e1b0 (sub-file start location)
3) Reverse find for text "LICE"
4) Done (answer = 0x17d800)

Similarly, how did you know the file entries table for the archive started at 0x17da00

You have to ask zero this question. I'm just going of the info he posted. See the info he posted earlier in this thread. Seems to be right.

[How did you know]the table entry for the sub file starts at 0x17da08?

1) Open shared.bin.
2) Go to 0x17e1b0 (sub-file start location)
3) See how this location looks? Look on the ASCII view in your hex editor and it looks quite different before and after this location.
4) Go to 0x17da00, start of file index table based on zero's information (Wpbb identifier)
5) See that the first entry in the file index table points to 0x17e1b0
6) Therefore, this location, 0x17e1b0, is the start of the first archived sub-file and the end of the file index table. It looks qualitatively different in your hex editor because it's a switch from plain-text data to compressed data. Compressed data looks different.

You missed nothing. All the data is compressed. You won't be able to find any text without something like offzip.

flame1234 · Oct 24, 2015

Test method:
1) Modify decompressed file. In the 0x17e1b0 file I put xxxxxxxxxxxxxxxxxxxxxx in place of もっと急いでったら～！. Length is same, so I only need to adjust compressed length.
2) Compress. It should be trivial, so I wont post a program. See the compression test program earlier for how to use Python zlib for this.
3) Insert. Pad with zeros. Here's a program:
...
Okay, it turns out it's a lot more complicated than that. Here's a program anyway:
http://pastebin.com/ehGfAspm

1) Compress file
2) Replace compressed and decompressed sizes
3) Replace file, pad with zeros
Only works if the new compressed size is less than the old.

Okay, halfwidth a.k.a. normal characters will not display. It's all fullwidth characters.
Here's my test:

I put 'ab' (halfwidth) in place of D fullwidth. It does not display. Also does not crash the game.
You need help from someone who can help you write a proper font routine. Narrowing the font spacing and editing the font a bit might work too, but I don't even know how to do that.

I also tried more aggressive zlib compression than HobbyJapan used and it worked just fine, which will give a little more space. I don't think space is an issue, just a solvable problem that needs to be solved.

zero_g_monkey · Oct 24, 2015

I'll come back and answer some questions and provide a nice little guide that might prove helpful. Good to see Flame helping out. He works wonders with our projects.

Final_Agent · Oct 26, 2015

You're both heroes. I'm learning a lot here, though my knowledge still needs a little time to settle down.

But I looked up all the LICE headers and the WPBB filedata entry points that ensue within the shared.bin as Zero pointed out to us in his example. I found a total of 7, but apparently all our dialogue can be found within LICE #4's range, at least before #5 comes into play, judging from the hex locations on all the .logs we received from the dump anyways.

I understand the TOC table B0 07 00 00 (which I think is a 32 bit pointer when you have 4 sets of hexes, is that correct?) demonstrates where Sub-file 1 (0x17E1B0) begins and is supposed to serve as an indicator (pointer) towards it, dunno what's all that stuff in between but you're right flame, the difference between that random stuff and where sub file one's compressed date begins is pretty blatant in MadEdit.

The math part flame used however is still a bit of a mystery to me. Particularly how he reached the conclusion of the next files location here -
"Looks like the next file is at 0x180e60. 0x180e60 - 0x17da00 = 0x3460. Things are starting to make more sense."
The 0x17da00 comes from the WPBB location, but the 0x3460 desired kinda throws me for a loop.

Otherwise, I'll need to get started on trying out python next and see if I can't at least repeat that test flame did there for ourselves. Phew.

flame1234 · Oct 26, 2015

For that part, I was searching for 78 9C zlib headers.
The 78 9C "zlib header" at 0x180327 is a false one. Those bytes just appear in the compressed data stream.
The 78 9C zlib header at 0x180e60 is a real one.
Then ask yourself, "okay, if there was an offset that pointed to this, what would its value be?" The answer is 0x180e60 - 0x17da00 = 0x3460. Because the 0x3460 pointer is relative, and we do that math problem to go from absolute to relative. The more generic formula is target point minus reference point.
I hope that makes a little more sense.

As stated earlier, the TOC table goes offset, decompressed size, compressed size starting at 0x17da08.
These entries are three 32-bit values each, so each entry in the header is 0xC long.
To get the location of the compressed size for any file: 0x17da08 + [file number] * 0xC + 0x8. Plugging in 0 gives 0x17da14, that's the first file. Plugging in 1 gives 0x17da20; you see the 0x3460 value there.

You need to modify the font somehow. If you did a whole game like that, it'd look terrible. I don't mind fixed-width fonts, but the spacing they used isn't suitable for English text, IMO.

zero_g_monkey · Oct 26, 2015

The two tools for romhacking I can't live without: WxMEdit (still updated version of madedit) and Windows Calculator (in programmer mode, it's really nice in Windows 10).

I just woke up so bare with me if something doesn't make sense. Feel free to ask me to clarify anything.

OK. Here comes a breakdown of the 0017e1b0.log file, Flame mentioned earlier. (Pardon the caps. Easier for me to type in hex and read.)

BREAKDOWN OF THE 0017E1B0.LOG FILE TABLE OF CONTENTS (TOC LOCATED AT/BETWEEN \x0000 - \x00BF)
*NOTE - THE TOC IS SETUP WITH 32-BIT POINTERS + 32-BIT UNKNOWN DATA (SEE BELOW. I DON'T KNOW WHAT THE SECOND PART IS YET.)
*C0 00 00 00 + 0B 00 00 00 (32-BIT + 32 BIT)

C0 00 00 00 0B 00 00 00 (POINTS TO OTHER STUFF. UNKNOWN PURPOSE.)
10 01 00 00 0C 00 00 00 (POINTS TO OTHER STUFF. UNKNOWN PURPOSE.)
80 04 00 00 3C 02 00 00 (POINTS TO OTHER STUFF. UNKNOWN PURPOSE.)
40 08 00 00 17 00 00 00 (POINTS TO OTHER STUFF. UNKNOWN PURPOSE.)
00 BB 00 00 0A 01 00 00 (POINTS TO OTHER STUFF. UNKNOWN PURPOSE.)
70 BC 00 00 09 00 00 00 (POINTS TO OTHER STUFF. UNKNOWN PURPOSE.)
A0 C0 00 00 09 00 00 00 (TEXT TOC POINTER TABLE)
E0 C4 00 00 02 01 00 00 (TEXT STARTS HERE)
C4 C0 00 00 01 01 00 00 (KIND OF A HALFWAY POINT. NOT IMPORTANT. YET THAT WE KNOW OF!) <- GOES WITH \xC0A0 ADDRESS
DE C6 00 00 FF FF FF FF (KIND OF A HALFWAY POINT. NOT IMPORTANT. YET THAT WE KNOW OF!) <- GOES WITH \xC0E0 ADDRESS
FF FF FF FF FF FF FF FF (JUST A BUNCH OF FFs. UNKNOWN REASON FOR BEING HERE)
20 FE 00 FF FF FF FF FF (END OF TEXT. END OF FILE. DE AD DE AD DE AD <-BAD JOKE BUT FILE RELEVANT.)

I dumped all the files individually according to the TOC. I am including those dumps to look at.
I also did a dump of the TEXT TOC POINTER TABLE (TEXT_TOC.BIN) and TEXT STARTS HERE (FILE_TEXT.BIN).
If you load the TEXT_TOC.BIN and cross reference with the FILE_TEXT.BIN, hopefully you can see
how I am able to understand the whole TOC thing.

Filenames and the association
These are just the files dumped according to the table above. It kind of gives you an idea of the larger file.

C0.BIN
110.BIN
480.BIN
840.BIN
BB00.BIN
BC70.BIN
C0A0.BIN
C0C4.BIN
C4E0.BIN
C6DE.BIN

These two are based partially off the TOC above but adjusted so that they are not split in two. You can see
the split it two versions if you want. The files will be list in paranthesis beside the corresponding files.

TEXT_TOC.BIN (C0A0.BIN, C0C4.BIN)
FILE_TEXT.BIN (C4E0.BIN, C0DE.BIN)

Download File Rip

Final_Agent · Oct 27, 2015

Okay, I understand the math a bit better and I've upped my game to wxMEdit along with my calculator, which does hex math way better than I ever could! Looking at the sub files, their zlib headers (which I think I can sort of recognize when they're actual headers and not when using the search function) and doing some math based on the wpbb location or its position relative to other sub file beginnings, I can determine its size in hex and its location relative to 0x17da00, the wpbb location.

0x17da00 -> 0x17e1b0 -> 0x180e60
Size: ---0x7b0-------0x2cb0-------
Offset from wbpp -
1st File - 7b0
2nd File - x3460

I can't say I really understand if Size implies file size or just, amount of hexes within the given space, like a water balloon that has an optimal capacity that it always has to be at, but I'm getting someplace with the hexes at least. Also, trying to actually find the values in the TOC is proving to be a bit weird... Is the info supposed to be so random in the TOC?

I found said files via their zlib headers, which netted me -
0x17e1b0
0x180e60
0x1828b0
0x183ab0
At least, so far -

Honestly, this is part of the stuff I can't quite wrap my head around. How does the Table of Contents work in a file or sub-file?

Opening the dump file that Zero just posted doesn't clear up much, I mean, I can see the information I'm pointed to but I don't really get the logic behind finding it. Was it the ascii display in wxMEdit that told you that none of the earlier hexes in 0x17e1b0 were part of the TOC? The fact that those 32 bit pointers actually displayed some kind of random letter?

Also, I got python to work on my computer, but I'm a little lost with that little decompress test Flame did before. While I was able to replicate it, you make it sound like using an actual decompression script to create a file is a trivial thing with python and the zlib, is it a common script that's used a lot or something, some kind of command? I wouldn't know the first thing about decompressing or compressing with Python, so that part really stumped me when I tried to replicate it. The dump script for the hex range worked though, so yay for little victories on my part.

I assume the test you did where you changed the text on the first line of the game worked off the compression and decompression scripts you mentioned too, right?

flame1234 · Oct 27, 2015

Honestly, this is part of the stuff I can't quite wrap my head around. How does the Table of Contents work in a file or sub-file?

Not solved yet for the sub-files. For the LICE file, it goes offset, decompressed size, compressed size. For the sub-files, we'll get to it when we get to it. We need to beg for someone to give us a hint on how to fix the font issue. Feel free to download that screenshot if you need to demonstrate the problem. I don't know how to solve graphics problems.

0: Offset 0x7B0
Decompressed: 0xFE20
Compressed: 0x2CB0

1: Offset 0x3460
Decompressed: 0xAA40
Compressed: 0x1A4E

2: Offset 0x4EB0
Decompressed: 0x64C0
Compressed: 0x11FD

Check the work:
1) Offset numbers are increasing and never decrease
2) Decompressed size is always bigger than compressed size

While I was able to replicate it, you make it sound like using an actual decompression script to create a file is a trivial thing with python and the zlib, is it a common script that's used a lot or something, some kind of command?

If it looks like it's trivial, then it is

Sorry if that reply isn't helpful, but there you go. Stupid question, stupid answer. I never used Python zlib before, so I wanted to write a test program to make sure I understand how it works.

I wouldn't know the first thing about decompressing or compressing with Python, so that part really stumped me when I tried to replicate it. The dump script for the hex range worked though, so yay for little victories on my part.

The code is commented. Do you have a question about a specific line? Do you have an error you're getting? Is it hard to follow?

1) Modify the compressed file. To do this, use your hex editor and replace some characters so that the length remains the same. We can't change lengths yet, but I don't think it will be too terribly difficult. Save the file and call it 0017e1b0.mod. Put it in a folder with shared.bin and the Python program. From here, run the program and it will take over. The program does all of the following steps.
2) Compress 0017e1b0.mod. Save the result as 0x17e1b0.compressed.new.
3) Read header info (offset, decompressed size, compressed size)
4) Length check to make sure the new compressed version will fit. If it won't fit, quit. We can't change lengths yet, but I think I can solve it.
5) I'm just being stupid here. So I decompressed the file compressed in step (2) to find out how big it is, when really I should just use os.path.getsize. We need this because it goes in the header.
6) Now the meat of the program. Write to output:
6A) All bytes up to the header location, copying from shared.orig
6B) The new header, using info gained in previous steps
6C) All bytes up to the file position
6D) The new compressed file
6E) Pad with zeros
6F) The rest of the bytes

Now you have a new shared.bin you can insert.

zero_g_monkey · Oct 27, 2015

The files I posted are not compressed. They were extracted using offzip. Not sure if that is understood or not. OK.

TOC and Pointer Tables. (see attached image)

I'm not sure what file is being worked with in the post above Flame's. But working with a TOC/Pointer Table like the ones present in this game are really simple. I color coated the one above to show you how they work. On the left side of the screen is the file I previously created called TEXT_TOC. Normally this starts at position xC0A0 in the file 0017e1b0.log. The address xC0A0 you can find at the beginning of the file between \x0000 - \x00BF. Sometimes the TOC for files in an archive may or may not be smaller/bigger. But we are not working with another file right now. The right side of the image is the game text from the file FILE_TEXT. Also color coated so hopefully you can understand how these things work. It is a much better idea to get your feet wet with something simple before trying to map out a file that contains a mix of compressed and uncompressed stuff. Trust me. It will make you crazy and you start seeing shit that is not really there. "Oh look, that might be something". Yet in reality, it's just garbage data.

A small note about my previous post talking about the TOC.

DE C6 00 00 FF FF FF FF (KIND OF A HALFWAY POINT. NOT IMPORTANT. YET THAT WE KNOW OF!) <- GOES WITH \xC0E0 ADDRESS - After some thought. This address will more than likely need to be updated after script insertion begins since it points to the middle of the original dialog.

leecherboy · Nov 1, 2015

First of all, thanks everybody for all you're helping us, we really wouldn't know where to begin otherwise.

I'm more or less following the explanations so far, but I admit I got some more studying to do. In the meantime, I was trying to replicate flame's test from earlier. I think I edited the original dumped 0x17e1b0 ok, the python code seems to have worked just fine (just to make sure, dumping the resulting "shared.bin" did produce a file with my changes), but it's the "putting the shared.bin back in the game" I'm stumped with.

I tried Umdgen4 and Winiso to edit the iso, but even if I don't modify the 0x17e1b0 at all, and just compress it with the python code and add the resulting shared.bin, the game crashes on start. Could you tell me if there's any step to the reinsertion part I'm missing, or if I should use any other program for it?

flame1234 · Nov 2, 2015

Quick tutorial on UMDgen4:
http://gbatemp.net/threads/brandish-the-dark-revenant-translation.364870/page-3#post-4985715

leecherboy · Nov 5, 2015

Oh cool, that did it.

So, if we're going one thing at a time, and if I understood it correctly, to translate the first stage we need either someone to help set up a proper half-width font, or at least to know how to make the files bigger without errors. Do you guys know about someone we could ask for help about that font modifying business?

flame1234 · Nov 5, 2015

You gotta beg and/or try as best you can.
I'm maybe not the best on advice for this sort of thing.

Almost every time someone helped me in the past on romhacking, they didn't do the work for me. Instead they were like "go try this and let me know how it went."

Anyway, follow this guide as best you can:
http://www.catb.org/esr/faqs/smart-questions.html

You're gonna have to break a few eggs before you make this omelet. Actually try the steps in the link I posted to see where you get or what you can learn, where you get stuck, etc.... Depending on where you get stuck I might be able to write some tutorials to help you through it. What tools to use, how to make use of them, etc.... But I've never solved a problem like this before. I don't think I have much chance of solving it, if I were to try.
Definitely figure out the x direction spacing in pixels (and post it) because it might give you some clue when stepping through the code.

Places to ask: (note: Each one has low chances of someone interested in your problem)
GBAtemp users probably already know about your problem and are unable or unwilling to help. I think you've exhausted GBAtemp.
romhacking.net (forums and help wanted ads)
romxhack.esforos.com (I actually got help here before, so it can't hurt to try)
...And that's about it.
You could try wololo (not sure of URL) - they don't have roms there I don't think. I don't think you're likely to find much help there either.
And you could try back where you guys came from before, fuwanovel.net. You're farther along now and have a different problem, so it's worth another shot.

Note that linking to sites that also provide roms will get you banned, so never post any links to such sites on here. It's okay to ask for help there and share links in PMs, though.

The length problems I think are solvable, but I'll hold off on actually solving them until we get this font problem solved. Eventually, you'll probably be able to use as much space as you reasonably need. You have to do that text replacement test first to just see what happens when you put roman characters in. The Falcom games I worked on before just plain work; they included a reasonable-looking fixed-width font that XSEED/Falcom used for commercial games (even in Japanese versions) and the text routine can read ASCII, so that was really easy.

The characters are spaced too far apart. It'd be fine if they were closer together, I think. That's pretty much the only problem you need to solve. VWF is a lot harder I think than just solving the fixed-width spacing problem. If you can solve the fixed-width spacing problem, I think you'll be able to solve the VWF problem too if you're so inclined.

So go look at that guide for requesting help, pull together all the information you can and post it here (follow the guide). Then try all the stuff you can, and write another report about that; definitely say wherever you got stuck. Once you've done all that, you're ready to request help from someone else. That will "catch up" your helper to where you currently are in solving your problem, so as to be respectful of their time. I don't think you're ready quite yet to post help requests all over the place.
--------------------------------
I need to write the tutorial on how to use UMDgen. I mean, the tutorial I linked you to is super-basic and doesn't cover all functions that you might need. Is there such a tutorial already somewhere? I didn't see it in the tutorials section.

--------------------- MERGED ---------------------------

There's the problem of decompiling and re-compiling the script. The text you see in those decompressed files have control flow codes in it, I think, like variable names for people, open dialog box command, names that go in the dialog boxes, line breaks... You name it, really. It's not just plain text. I think I can help you with trying to decompile the script so you can translate and re-insert. We need to wind up with a human-readable dump like Nayuta Dumps. Check the first post in my Nayuta thread to see what it looks like.

I think it pays to go slow and get a good proof of concept before you start translating the whole thing.

If length needs to be expanded (it might need to be) once you're done with the first file, I'll have to see what I can do about expanding it.

JamRules · Nov 6, 2015

Don't have the time to do this properly but this is a simple version of what you could aim to do for a VWF, this is all based in RAM. It's 1:30 am so don't expect this to be amazing

Default

Hack

***

ex 08863B30 - lwc1 f12,0x14(sp) - f12 is the spacing value and it's loaded here

-replace original asm with jump like below

*****

ex 08990000 - injection code

//load char just rendered
lhu a0, 0x0(s2)

//store original f12
lui s0,0x0899
ori s0,s0,0x0200
swc1 f12,0x0(s0)

move v1, s0
addi v1, v1, 0x10

lhu v0, 0x0(v1)//load char from table <-------- A

beq v0,zero, 0x08990060 //stop at null

//loop if chars don't match
bnel v0,a0, 0x08990018 ---------> A
addiu v1, v1, 0x8

//load spacing if match
addiu v1, v1, 0x4
lwc1 f12,0x0(v1)

//apply spacing
add.s f24,f12,f24

//load original f12
lui s0,0x0899
ori s0,s0,0x0200
lwc1 f12,0x0(s0)

//reset registers
li v0, 0x0
li v1, 0x0

//increase s2 by 2 and return
addiu s2,s2,0x2
j 0x08863B3C

nop ex 08990030 to disable

You don't need the huge space but I was making this up as I went along

***
0x08990210 - Character width data

Sets of 8 bytes per character

2 bytes - Shift-jis char
2 bytes - null
4 bytes - float width

for example the first entry is "A", 0x41100000 (9.0f)

***

You need to either extend the eboot or find another file (e.g. the font) to add the code into and then adjust the jumps to match

flame1234 · Nov 7, 2015

Lost already.
The instruction I have at 8863b2c is sw s1, 0x8(sp)

The CRC32 of my ISO is C658C199. Do I have the wrong one?

JamRules · Nov 7, 2015

Yeah...I thought this might happen, some people might have already noticed.
I might have accidentally looked at Queen's Gate Spiral Chaos instead,
and I even knew both existed.

This is why starting something at 11pm on a weekday is a bad idea,
I probably should have noticed when it prompted me to import my save data which I thought was weird at the time

I'll get back to you once I've looked at the right game...

Edit:

Take two, now with the correct game...

*************
ex 08833A80

-replace with jump
j 0x08990000
nop

****

ex 08990000 - injection code

//load char just rendered
lhu a3, 0x0(s4)

//store original f21
lui s6,0x0899
ori s6,s6,0x0200
swc1 f21,0x0(s6)

move v1, s6
addi v1, v1, 0x10

lhu v0, 0x0(v1)//load char from table <-------- A

beq v0,zero, 0x08990044 //stop at null
nop

//loop if chars don't match
bnel v0,a3, 0x08990018 ---------> A
addiu v1, v1, 0x8

//load spacing if match
addiu v1, v1, 0x4
lwc1 f21,0x0(v1)

//load original f21
lui s6,0x0899
ori s6,s6,0x0200
lwc1 f21,0x0(s6)

//apply spacing
add.s f25,f25,f21

//move to next char
addiu s4,s4,0x2

//reset registers

li v0, 0x0
li v1, 0x0
li a3, 0x0
li s6, 0x0

j 0x08833A88

****

The hack also affects the name text

flame1234 · Nov 8, 2015

Is there a tool that will help you compile MIPS assembly?
I tried armips and it did not work.

Pastebin for .asm script: http://pastebin.com/9Ei8Yrk9

Do I have to write my own assembler or something? I'm not sure the mistake I made on line 27. The instruction I put for line 27 was lbu v0, v1(0x3). Those are all definitely real opcodes. That the PSX (that armips was designed for) does not support, probably.

Nevermind, the correct format is lbu v0, 0x3(v1). Still need help with getting those other opcodes to compile.

JamRules · Nov 8, 2015

For this example I just used PPSSPP's disassembly window, right click and choose assemble opcode

The script should probably be set as .psp not .psx

Edit:

Assuming your aiming for
2 bytes - character
1 byte - null
1 byte - integer width

lbu v0, 0x3(v1)
lwc1 f21, v0
cvt.s.w f21, f21

would be

lbu v0, 0x3(v1)
mtc1 v0,f21
cvt.s.w f21,f21

flame1234 · Nov 9, 2015

Wow Jams, you read my mind. Or the code. Or something. That's exactly what I had in mind. I want to do it this way because I don't like floating point number. This way, the computer will handle the floating point numbers for me.

I got this working. But I feel like I wouldn't be able to do it again.
Jams, can you tell me how you found the instruction where the x character offset is loaded? I feel like I understand the rest of it.

MIPS code: http://pastebin.com/X1fupyVK

Well it's not perfect, but it's much better than it was.

Look at the first image, the name entry screen.
Some of the letters are in the middle of the block. That means for those, the spacing won't quite work. Most of the capital letters are aligned to the left of the block, so spacing for those should be perfect. No idea how to modify the font either. But if we could, we'd left align the letters currently in the middle of the block so that their spacing would work perfectly too.

Now, look at the image on the far right. See how the l's in ellipsis look like their spacing is off? If I change l spacing to be smaller, the l in the following screenshot would be covered up by the m:

Here's an xdelta patch for everything I have so far:
http://www.mediafire.com/download/h1504yhd63z3a7m/QB_v1.xdelta

Hacking Queen's Blade: Spiral Chaos Translation Project ( Hackers needed )

Member

Well-Known Member

Well-Known Member

Well-Known Member

Member

Well-Known Member

Well-Known Member

Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

.....

Well-Known Member

.....

Well-Known Member

.....

Well-Known Member

Similar threads

Popular threads in this forum