Author Topic: Gundam Ghirens Greed V PSP, Hacker Needed!  (Read 989 times)


  • Newbie
  • *
  • Posts: 6
    • View Profile
Gundam Ghirens Greed V PSP, Hacker Needed!
« on: February 01, 2016, 11:39:27 pm »
Hey guys,

I'm new here, but I've been lurking for a long time.

The idea of a menu translation of Gundam Ghiren's Greed PSP has always been a passion of mine.
I admittedly lack the skill, but I've been plugging along anyway.

So here's what I've accomplished:

1. All graphics and ingame text are  static compressed images found inside of the *.MKD files  files on the ISO. (witch the exception of unit names, which are in the boot.bin)

2. I found a program to extract the images (GIRENAXV.EXE) , and have all of the menu's etc.. exported into BMP format.
I am semi fluent in Japanese so I've begun the process of translating the images.

The problem, I've have no way of re-inserting the translated images, due to the fact the program only extracts the files and doesn't inject them.

What I've found from hex editing is that the Majority of the images are probably compressed in a SD0 format. (I know nothing about compression, I found this through trial and error)
I'm attaching the Program and a sample MKD file I cut from from one of the large ingame files.

I would love if anyone else has the same passion and added skill who would like to help out.

(Interesting fact, this program can extract files from all of the Ghiren Series (PSP,PS2,PS) the MKD format was used across all platforms)

Send me any and all messages, I will send a copy of the opensource tool I found to whomever asks

« Last Edit: October 24, 2016, 08:58:10 pm by lsaint »


  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: Gundam Ghirens Greed V PSP, Progress Made!
« Reply #1 on: October 08, 2016, 03:29:44 pm »
I know this is not ideal and probably not what you want, but the latest version of PPSSPP (1.3) can dump/read textures to standard png files.
The feature is likely intended to let people do high resolution texture packs, but you could use that to translate the game until someone figures out how to properly re-insert them.


  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Gundam Ghirens Greed V PSP, Progress Made!
« Reply #2 on: October 08, 2016, 08:47:29 pm »
I found a Japanese tool to do that. It was mad specifically for the game.

so most of the menu textures are done and translated.

October 09, 2016, 11:25:06 pm - (Auto Merged - Double Posts are not allowed before 7 days.)

Thank's for the suggestions, but the textures come out really odd and garbled and I don't think I'll be able to translate it that way.

I'll give an update on what I have done translation wise.

Progress: (Images Files Redone with english language)
100% Main Menu/Combat Menu
100% Pilot Names all factions

To do:
Decision Branches, Adviser Dialog, MISC pop up's, Pilot Banter, Unit Translations
This is literally thousands of images and my plan is to go through faction by faction and do the advisers and decision points.
edit Boot.bin/Eboot.bin insert english text (not much)

The Pilot Banter will be a long term goal.

October 11, 2016, 04:59:34 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
From searching several foreign sites I've found that the game is utilizing an LZ77 based compression scheme,

here is the info (It's translated from korean, so bare with me)

Pre-compression method, a type of the LZ77 compression scheme.
A description of the head information is purposely omitted.
The compressed data will be in the pattern of 1 bite that is gathered by 8 flag bit and 8 chuncks.
Ex)  [Flag][chunk0][chunk 1][chunk2][chunk3][chunk4][chunk5][chunk6][chunk7][flag][chunk0][chunk1]....
Each bit of the flag indicates whether the chunk was compressed or not.1 means compressed chunk, 0 will be the chunk has not been compressed and has a size of 1 bite.
#0bite represents # 0 chunk, while #7bit represents #7 bit.

There are 4 types of compressed chunk.
If the first bite of the chunk’s lower nibble has a value of 0, that means it is a long compression.1 means RLE, 2means Copy, the rest means compressed.
Long compressed chunks are formed with 3 bites.
If the 3bite comes in the order of [H0:L0][H1:L1][H2:L2]  ,( H is upper nibble,4 bit), L is lower nibble. They are enclosed by bite. L0 is 0.
The enclosed 12 bit which is the order of H1 L1 H0, helps you to understand how much backwards you have to refer in advance starting from current cursor.
Add 0x10 to 8bit which is enclosed by H2 L2, that tells you how much bite you have to bring.
If it is 30 12 24 , after seeing L0 which is 0,  you know it is a long compressed chunk . 0x123 tells you how much you have to refer backward from previous.
 and  (0x24 + 0x10)is how much bite you have to bring from there.
RLE chunks are formed by 2 bite.
L0 has to follow 1. Add3 to H0 tells you how many times you have to repeat.[H1:L1]tells repeating bite.
If it 21 78, that means 0x78 words was repeated 2+3 times.
Copy chunks are formed by 2+nbite.
In case L0 is 2, add0x12 to H1 L1 H0, you will know how much bite you have to copy. You just have to copy the data shows after that.
Compressed chunk is formed by 2bite.
The value of L0 same as previously brought data’s bite. H1 L1 H0 tells you  how much you have to go backward from the current cursor.
There are 3 points in total.
1. The point that indicates from previous to present .
2. The point that indicates the present of compressed input file.
3. After decompressing and saving, the point that is used for output.
It reads one bite from the input point. Input point will move automatically.
After seeing the bite, it will make an assumption that it is a copy chunk.
After reading another bite, it will calculate the length of n. input point will move automatically.
for(i = 0; i < n; i++) {
c = fgetc(input point);
fputc(c, output point);
Previous [previous point ] = c; previous point++;
Previous size was 4kb. Since the range of previous point was 0~4095, after 4095, instead of 4096, it will move back to 0.
Previous point= (previous point+ 1) % 4096;

« Last Edit: October 11, 2016, 05:00:27 pm by lsaint »


  • Sr. Member
  • ****
  • Posts: 259
    • View Profile
Re: Gundam Ghirens Greed V PSP, Progress Made!
« Reply #3 on: October 14, 2016, 11:15:17 am »
I wish I had the knowledge to help, but wish you luck on it. I always wondered what Gihren's Greed was all about since it has one of the coolest looking gundam covers.


  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Gundam Ghirens Greed V PSP, Progress Made!
« Reply #4 on: October 17, 2016, 07:34:15 pm »

So the SD0 File type has been decompressed. The MRG files that lay within an contain the actual Textures as "TX"
are next.

Also, when translating the names inside of the Eboot.bin I've been lucky that Japanese names spell allot of English
names phonetically, so I've had allot of luck space wise. Also the are between in 2 - 6 bytes of trailing zeroes.
That I've been able to utilize, for more space.

Right now, I'm looking for someone to handle the MRG format, and re compression so I reinsert the images that
have been translated.

October 21, 2016, 11:03:09 am - (Auto Merged - Double Posts are not allowed before 7 days.)
I found the Textures!

« Last Edit: October 21, 2016, 11:03:09 am by lsaint »


  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Gundam Ghirens Greed V PSP, Progress Made!
« Reply #5 on: October 24, 2016, 08:57:47 pm »

The image format is easy to deal with, and my current plan that iis adapting the tesseract
ocr engine to read all the images into an excel spreadsheet. I don't mind a few missed characters, if it cuts down
the work of me hand jamming all of them into the sheet myself.

Currently, I'm looking for someone to figure out how to reinsert the decompressed MRG files into the main
MKD Archive's.

Below is the quickbms script.

if anyone is interested in lending a hand with re-compression it would be greatly appreciated.

Also here are the headers, of a Compressed and Un-Compressed MRG
« Last Edit: October 25, 2016, 12:45:34 pm by lsaint »


  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Gundam Ghirens Greed V PSP, Hacker Needed!
« Reply #6 on: November 06, 2016, 04:16:43 pm »
Here is a copy of the Decompression Routine, if anyone is interested.
I'm having a bit of trouble wrapping my head around it!

4029b0:   sub esp, 0x18
4029b3:   push ebp
4029b4:   push edi
4029b5:   mov edi, [esp+0x24]
4029b9:   xor eax, eax
4029bb:   xor ecx, ecx
4029bd:   mov edx, 0xc
4029c2:   mov ah, [edi+0xa]
4029c5:   mov cl, [edi+0x8]
4029c8:   mov al, [edi+0x9]
4029cb:   shl eax, 0x8
4029ce:   or eax, ecx
4029d0:   mov [esp+0x1c], eax
4029d4:   mov eax, 0x0
4029d9:   mov [esp+0xb], al
4029dd:   mov [esp+0xa], al
4029e1:   mov ebp, eax
4029e3:   jbe dword 0x402b5b
4029e9:   push ebx
4029ea:   mov ebx, [esp+0x2c]
4029ee:   push esi
4029ef:   mov al, [esp+0x12]
4029f3:   test al, al
4029f5:   jnz 0x402a04
4029f7:   mov al, [edx+edi]
4029fa:   mov byte [esp+0x12], 0x8
4029ff:   mov [esp+0x13], al
402a03:   inc edx
402a04:   test byte [esp+0x13], 0x1
402a09:   jnz 0x402a18
402a0b:   mov cl, [edx+edi]
402a0e:   inc edx
402a0f:   mov [ebx+ebp], cl
402a12:   inc ebp
402a13:   jmp dword 0x402b31
402a18:   mov al, [edx+edi]
402a1b:   mov cl, [edx+edi+0x1]
402a1f:   mov [esp+0x18], al
402a23:   add edx, 0x2
402a26:   and al, 0xf
402a28:   mov [esp+0x14], cl
402a2c:   mov [esp+0x20], al
402a30:   jnz 0x402a6c
402a32:   mov esi, [esp+0x14]
402a36:   mov eax, [esp+0x18]
402a3a:   and esi, 0xff
402a40:   and eax, 0xff
402a45:   shl esi, 0x4
402a48:   shr eax, 0x4
402a4b:   add esi, eax
402a4d:   xor eax, eax
402a4f:   mov al, [edx+edi]
402a52:   add eax, 0x10
402a55:   jz 0x402a66
402a57:   mov ecx, ebp
402a59:   sub ecx, esi
402a5b:   inc ebp
402a5c:   dec eax
402a5d:   mov cl, [ecx+ebx]
402a60:   mov [ebx+ebp-0x1], cl
402a64:   jnz 0x402a57
402a66:   inc edx
402a67:   jmp dword 0x402b31
402a6c:   cmp al, 0x1
402a6e:   jnz 0x402ab8
402a70:   mov eax, [esp+0x14]
402a74:   mov ecx, [esp+0x18]
402a78:   and eax, 0xff
402a7d:   and ecx, 0xff
402a83:   lea edi, [ebx+ebp]
402a86:   mov bl, al
402a88:   shr ecx, 0x4
402a8b:   mov bh, bl
402a8d:   add ecx, 0x3
402a90:   mov eax, ebx
402a92:   mov [esp+0x1c], ecx
402a96:   mov esi, ecx
402a98:   shl eax, 0x10
402a9b:   mov ax, bx
402a9e:   mov ebx, [esp+0x30]
402aa2:   shr ecx, 0x2
402aa5:   rep stosd
402aa7:   mov ecx, esi
402aa9:   and ecx, 0x3
402aac:   rep stosb
402aae:   mov edi, [esp+0x2c]
402ab2:   mov eax, esi
402ab4:   add ebp, eax
402ab6:   jmp 0x402b31
402ab8:   cmp al, 0x2
402aba:   jnz 0x402afb
402abc:   mov eax, [esp+0x14]
402ac0:   mov ecx, [esp+0x18]
402ac4:   and eax, 0xff
402ac9:   and ecx, 0xff
402acf:   shl eax, 0x4
402ad2:   shr ecx, 0x4
402ad5:   lea esi, [edx+edi]
402ad8:   lea edi, [ebx+ebp]
402adb:   lea ecx, [eax+ecx+0x12]
402adf:   mov [esp+0x1c], ecx
402ae3:   mov eax, ecx
402ae5:   shr ecx, 0x2
402ae8:   rep movsd
402aea:   mov ecx, eax
402aec:   add edx, eax
402aee:   and ecx, 0x3
402af1:   add ebp, eax
402af3:   rep movsb
402af5:   mov edi, [esp+0x2c]
402af9:   jmp 0x402b31
402afb:   mov esi, [esp+0x14]
402aff:   mov ecx, [esp+0x18]
402b03:   mov eax, [esp+0x20]
402b07:   and esi, 0xff
402b0d:   and ecx, 0xff
402b13:   shl esi, 0x4
402b16:   shr ecx, 0x4
402b19:   add esi, ecx
402b1b:   and eax, 0xff
402b20:   jbe 0x402b31
402b22:   mov ecx, ebp
402b24:   sub ecx, esi
402b26:   inc ebp
402b27:   dec eax
402b28:   mov cl, [ecx+ebx]
402b2b:   mov [ebx+ebp-0x1], cl
402b2f:   jnz 0x402b22
402b31:   mov al, [esp+0x12]
402b35:   mov cl, [esp+0x13]
402b39:   dec al
402b3b:   mov [esp+0x12], al
402b3f:   mov eax, [esp+0x24]
402b43:   shr cl, 1
402b45:   cmp ebp, eax
402b47:   mov [esp+0x13], cl
402b4b:   jb dword 0x4029ef
402b51:   pop esi
402b52:   pop ebx
402b53:   mov eax, ebp
402b55:   pop edi
402b56:   pop ebp
402b57:   add esp, 0x18
402b5a:   ret
402b5b:   mov eax, ebp
402b5d:   pop edi
402b5e:   pop ebp
402b5f:   add esp, 0x18
402b62:   ret