Has anyone taken a look at this?
PM me for sample.
Important information: this site is currently scheduled to go offline indefinitely by end of the year.
Saints row IV ps3_vpp.
-
- Moderator
- Posts: 719
- Joined: Mon Jul 05, 2010 8:55 pm
- Has thanked: 20 times
- Been thanked: 496 times
-
- Moderator
- Posts: 719
- Joined: Mon Jul 05, 2010 8:55 pm
- Has thanked: 20 times
- Been thanked: 496 times
Re: Saints row IV ps3_vpp.
Here you go then, it seems to work fine although some of the extracted files may be compressed. I'm not sure what compression is used in this game!
Code: Select all
# [PS3] Saints Row IV Unpacker [.VPP]
# Script v1.1
# By Gh0stblade!
# Thanks Chrrox for you know what (:
endian big
IDSTRING "\x51\x89\x0A\xCE"
get VERSION long #0xA
get HASH long #Possible checksum? i hope not!
get VPP_SIZE long #Size of the full archive
get NULL00 long #Always 00 00 00 00
get FILES long #The file count!
get PTR_NAMES long #0x28 + this is the offset to the names table
get PTR_DATA long #0x28 + PTR_NAMES + this is the offset to the data start
get DSIZE long #Size of the data section
get PADDING long #Padding always 0xFFFFFFFF
#Each file table entry is 0x18 in length!
for i = 0 < FILES
get NAME_OFF long #This is the relative name offset relative to base offset PTR_NAMES + 0x28
get NULL01 long #Always 00 00 00 00
get OFFSET long #This is the relative data offset relative to base offset 0x28 + PTR_NAMES + PTR_DATA
get SIZE long #The size of the file!
get PADDING long #Padding always 0xFFFFFFFF
get UNK00 long #Always 00 00 00 01
#Get the correct offset and read the name string!
math NAME_OFF += 0x28
math NAME_OFF += PTR_NAMES
savepos TEMP
goto NAME_OFF
get NAME string
goto TEMP
#Get the correct offset for the data!
math OFFSET += 0x28
math OFFSET += PTR_NAMES
math OFFSET += PTR_DATA
log NAME OFFSET SIZE
next i
Last edited by Gh0stBlade on Sun Aug 18, 2013 5:13 pm, edited 1 time in total.
Click the thanks button if I helped!
-
- ultra-n00b
- Posts: 5
- Joined: Thu Nov 10, 2011 1:13 am
Re: Saints row IV ps3_vpp.
Fixed your script with more accurate names. Also the compression is zlib.Gh0stBlade wrote:Here you go then, it seems to work fine although some of the extracted files may be compressed. I'm not sure what compression is used in this game!
Code: Select all
# [PS3] Saints Row IV Unpacker [.VPP] # Script v1.1 # By Gh0stblade! # Thanks Chrrox for you know what (: # Fixed by CRACKbomber endian big get IDENT long #File ident - 0x00 get VERSION long #10 for SRIV - 0x04 get HASH long #Checksum - 0x08 calculated here http://pastebin.com/Parpjz8W get VPP_SIZE long #File size - 0x0C get FLAGS long #Flags - 0x10 get FILES long #Number of files 0x014 get DIR_SIZE long #Directory size 0x18 get FILENAME_SIZE long #Filename size 0x1C get DSIZE long #Size of the data section 0x20 get COMPSIZE long #Size of the compressed data section 0x24 #Each file table entry is 0x18 in length! for i = 0 < FILES get NAME_OFF long #This is the relative name offset relative to base offset PTR_NAMES + 0x28 get PADDING long #PADDING get OFFSET long #This is the relative data offset relative to base offset 0x28 + PTR_NAMES + PTR_DATA get SIZE long #The size of the file! get COMPSIZE long #Compressed data size get FLAGS short #Flags of the file get ALIGNMENT short #Alignment of the file either 1 or 16 #Get the correct offset and read the name string! math NAME_OFF += 0x28 math NAME_OFF += DIR_SIZE savepos TEMP goto NAME_OFF get NAME string goto TEMP #Get the correct offset for the data! math OFFSET += 0x28 math OFFSET += DIR_SIZE math OFFSET += FILENAME_SIZE log NAME OFFSET SIZE next i
-
- Moderator
- Posts: 2602
- Joined: Sun May 18, 2008 3:01 pm
- Has thanked: 57 times
- Been thanked: 1422 times
-
- Moderator
- Posts: 954
- Joined: Sun Mar 27, 2011 8:42 pm
- Has thanked: 10 times
- Been thanked: 161 times
Re: Saints row IV ps3_vpp.
does it work for X360 as well ?
Quick BMS Editor GUI - simple easy to use
Goto : viewtopic.php?uid=34229&f=29&t=6797&start=0
Downloads from DropBox : https://dl.dropboxusercontent.com/u/
Goto : viewtopic.php?uid=34229&f=29&t=6797&start=0
Downloads from DropBox : https://dl.dropboxusercontent.com/u/
-
- ultra-n00b
- Posts: 5
- Joined: Thu Nov 10, 2011 1:13 am
-
- Moderator
- Posts: 719
- Joined: Mon Jul 05, 2010 8:55 pm
- Has thanked: 20 times
- Been thanked: 496 times
Re: Saints row IV ps3_vpp.
Well a few days ago i worked along side with chrrox to try get the decompression working. We did update the script however, I don't know why it's not decompressing some files so I'll just post up what we got so far.
It's extremely messy though but I'll leave it just in case someone else can fix it!
Edit: Maybe it's due to the byte alignment which was stated in the script edit by the other guy? Someone could investigate maybe, just a thought!
It's extremely messy though but I'll leave it just in case someone else can fix it!
Edit: Maybe it's due to the byte alignment which was stated in the script edit by the other guy? Someone could investigate maybe, just a thought!
Code: Select all
# [PS3] Saints Row IV Unpacker [.VPP]
# Script v1.2
# By Gh0stblade!
# Thanks Chrrox for you know what (:
endian big
comtype unzip_dynamic
IDSTRING "\x51\x89\x0A\xCE"
get VERSION long #0xA
get HASH long #Possible checksum? i hope not!
get VPP_SIZE long #Size of the full archive
get ATYPE long #Archive type 00 00 00 00 = Uncompressed; 00 00 50 03 = Compressed
get FILES long #The file count!
get PTR_NAMES long #0x28 + this is the offset to the names table
get PTR_DATA long #0x28 + PTR_NAMES + this is the offset to the data start
get DSIZE long #Size of the data section
get DZSIZE long #Size of the compressed data section if compressed or -1 if uncompressed!
#Each file table entry is 0x18 in length!
set OFFSET2 0
for i = 0 < FILES
get NAME_OFF long #This is the relative name offset relative to base offset PTR_NAMES + 0x28
get NULL01 long #Always 00 00 00 00
get OFFSET long #This is the relative data offset relative to base offset 0x28 + PTR_NAMES + PTR_DATA
get SIZE long #The size of the file!
get ZSIZE long #The compressed size of the file if compressed or -1 if uncompressed!
get UNK00 long #Always 00 00 00 01
#Get the correct offset and read the name string!
savepos TEMP
math NAME_OFF += 0x28
math NAME_OFF += PTR_NAMES
goto NAME_OFF
get NAME string
goto TEMP
#if it's not the uncompressed archive
if ATYPE != 0x00000000
set OFFSET OFFSET2
math OFFSET += 0x28
math OFFSET += PTR_NAMES
math OFFSET += PTR_DATA
math OFFSET += 0x8
math OFFSET2 += ZSIZE
math ZSIZE -= 0x8
clog NAME OFFSET ZSIZE SIZE
else
#Get the correct offset for the data!
math OFFSET += 0x28
math OFFSET += PTR_NAMES
math OFFSET += PTR_DATA
log NAME OFFSET SIZE
endif
next i
Click the thanks button if I helped!
-
- ultra-n00b
- Posts: 5
- Joined: Thu Nov 10, 2011 1:13 am
Re: Saints row IV ps3_vpp.
Once again, read my post. It's zlib. and "ATYPE" is just flags. You have to use bit operators the see if a flag is set. (1 == compressed, 2 == condensed)Gh0stBlade wrote:Well a few days ago i worked along side with chrrox to try get the decompression working. We did update the script however, I don't know why it's not decompressing some files so I'll just post up what we got so far.
It's extremely messy though but I'll leave it just in case someone else can fix it!
Edit: Maybe it's due to the byte alignment which was stated in the script edit by the other guy? Someone could investigate maybe, just a thought!
Code: Select all
# [PS3] Saints Row IV Unpacker [.VPP] # Script v1.2 # By Gh0stblade! # Thanks Chrrox for you know what (: endian big comtype unzip_dynamic IDSTRING "\x51\x89\x0A\xCE" get VERSION long #0xA get HASH long #Possible checksum? i hope not! get VPP_SIZE long #Size of the full archive get ATYPE long #Archive type 00 00 00 00 = Uncompressed; 00 00 50 03 = Compressed get FILES long #The file count! get PTR_NAMES long #0x28 + this is the offset to the names table get PTR_DATA long #0x28 + PTR_NAMES + this is the offset to the data start get DSIZE long #Size of the data section get DZSIZE long #Size of the compressed data section if compressed or -1 if uncompressed! #Each file table entry is 0x18 in length! set OFFSET2 0 for i = 0 < FILES get NAME_OFF long #This is the relative name offset relative to base offset PTR_NAMES + 0x28 get NULL01 long #Always 00 00 00 00 get OFFSET long #This is the relative data offset relative to base offset 0x28 + PTR_NAMES + PTR_DATA get SIZE long #The size of the file! get ZSIZE long #The compressed size of the file if compressed or -1 if uncompressed! get UNK00 long #Always 00 00 00 01 #Get the correct offset and read the name string! savepos TEMP math NAME_OFF += 0x28 math NAME_OFF += PTR_NAMES goto NAME_OFF get NAME string goto TEMP #if it's not the uncompressed archive if ATYPE != 0x00000000 set OFFSET OFFSET2 math OFFSET += 0x28 math OFFSET += PTR_NAMES math OFFSET += PTR_DATA math OFFSET += 0x8 math OFFSET2 += ZSIZE math ZSIZE -= 0x8 clog NAME OFFSET ZSIZE SIZE else #Get the correct offset for the data! math OFFSET += 0x28 math OFFSET += PTR_NAMES math OFFSET += PTR_DATA log NAME OFFSET SIZE endif next i
-
- Moderator
- Posts: 719
- Joined: Mon Jul 05, 2010 8:55 pm
- Has thanked: 20 times
- Been thanked: 496 times
Re: Saints row IV ps3_vpp.
I know the compression used is Zlib however there's a reason why there are decompression issues. If it's as simple as it just being Zlib then it would decompress fine. I have no need to read your post, i skimmed it because I don't have the time to compare the scripts to see what you changed.CRACKbomber wrote:Once again, read my post. It's zlib. and "ATYPE" is just flags. You have to use bit operators the see if a flag is set. (1 == compressed, 2 == condensed)Gh0stBlade wrote:Well a few days ago i worked along side with chrrox to try get the decompression working. We did update the script however, I don't know why it's not decompressing some files so I'll just post up what we got so far.
It's extremely messy though but I'll leave it just in case someone else can fix it!
Edit: Maybe it's due to the byte alignment which was stated in the script edit by the other guy? Someone could investigate maybe, just a thought!
Code: Select all
# [PS3] Saints Row IV Unpacker [.VPP] # Script v1.2 # By Gh0stblade! # Thanks Chrrox for you know what (: endian big comtype unzip_dynamic IDSTRING "\x51\x89\x0A\xCE" get VERSION long #0xA get HASH long #Possible checksum? i hope not! get VPP_SIZE long #Size of the full archive get ATYPE long #Archive type 00 00 00 00 = Uncompressed; 00 00 50 03 = Compressed get FILES long #The file count! get PTR_NAMES long #0x28 + this is the offset to the names table get PTR_DATA long #0x28 + PTR_NAMES + this is the offset to the data start get DSIZE long #Size of the data section get DZSIZE long #Size of the compressed data section if compressed or -1 if uncompressed! #Each file table entry is 0x18 in length! set OFFSET2 0 for i = 0 < FILES get NAME_OFF long #This is the relative name offset relative to base offset PTR_NAMES + 0x28 get NULL01 long #Always 00 00 00 00 get OFFSET long #This is the relative data offset relative to base offset 0x28 + PTR_NAMES + PTR_DATA get SIZE long #The size of the file! get ZSIZE long #The compressed size of the file if compressed or -1 if uncompressed! get UNK00 long #Always 00 00 00 01 #Get the correct offset and read the name string! savepos TEMP math NAME_OFF += 0x28 math NAME_OFF += PTR_NAMES goto NAME_OFF get NAME string goto TEMP #if it's not the uncompressed archive if ATYPE != 0x00000000 set OFFSET OFFSET2 math OFFSET += 0x28 math OFFSET += PTR_NAMES math OFFSET += PTR_DATA math OFFSET += 0x8 math OFFSET2 += ZSIZE math ZSIZE -= 0x8 clog NAME OFFSET ZSIZE SIZE else #Get the correct offset for the data! math OFFSET += 0x28 math OFFSET += PTR_NAMES math OFFSET += PTR_DATA log NAME OFFSET SIZE endif next i
You have updated the script and mine is obviously outdated and lacks the things you may have found. I understand what you mean with the flags, I just think you need to be a little less forceful (if that's the word) with the "it's this, it's this, this this, read". I have simply done what I can with the script and I clearly stated I'm discontinuing it so IF you are interested in fixing the issues then go ahead I don't need to be told what's what because I'm not interested in continuing anymore since I've done what I can with this.
I will clarify that this script has not been touched for a few days and it's just rough stuff I did randomly and clarify further i do not need to be told to read things. I just feel that you're being slightly rude to me so I should let you off this time, just don't ever try to dictate to me or there will be problems.
Regards.
Click the thanks button if I helped!
-
- Moderator
- Posts: 954
- Joined: Sun Mar 27, 2011 8:42 pm
- Has thanked: 10 times
- Been thanked: 161 times
Re: Saints row IV ps3_vpp.
im almost sure that for x360 it will be xmem_decompress and it will compatible with qbms
Quick BMS Editor GUI - simple easy to use
Goto : viewtopic.php?uid=34229&f=29&t=6797&start=0
Downloads from DropBox : https://dl.dropboxusercontent.com/u/
Goto : viewtopic.php?uid=34229&f=29&t=6797&start=0
Downloads from DropBox : https://dl.dropboxusercontent.com/u/
-
- veteran
- Posts: 88
- Joined: Sat Feb 27, 2010 6:57 pm
- Has thanked: 40 times
- Been thanked: 77 times
Re: Saints row IV ps3_vpp.
Note: I have only tested this on the xbox360 files.
Is everyone sure this is zlib? I know it does provide the decompressed and compressed sizes in the header sections for each file, but no dll/quickbms is actually decompressing the data.
The current script does not decompress, only removes the first 8 bytes of the compressed chunks. Correct me if I'm wrong.
This may be some kind of header-less zlib. I've tried ICSharpZipLib's SetInput() and Inflate() methods with the Inflater parameter "noZlibHeaderOrFooter" set to true.
Another possibility is a different dictionary.
--I'm not sure, but (aNeedDictionary:.string "need dictionary") in the disassembly doesn't have a xref. Maybe this means a different dictionary is not used?
Does anyone know of another compression off hand that the decompressed size and compressed size are needed for decompression?
Is everyone sure this is zlib? I know it does provide the decompressed and compressed sizes in the header sections for each file, but no dll/quickbms is actually decompressing the data.
The current script does not decompress, only removes the first 8 bytes of the compressed chunks. Correct me if I'm wrong.
This may be some kind of header-less zlib. I've tried ICSharpZipLib's SetInput() and Inflate() methods with the Inflater parameter "noZlibHeaderOrFooter" set to true.
Another possibility is a different dictionary.
--I'm not sure, but (aNeedDictionary:.string "need dictionary") in the disassembly doesn't have a xref. Maybe this means a different dictionary is not used?
Does anyone know of another compression off hand that the decompressed size and compressed size are needed for decompression?