READ THE RULES: Click here

Follow us on Facebook: https://www.facebook.com/xentax/ :)

Saints row IV ps3_vpp.

The Original Forum. Game archives, full of resources. How to open them? Get help here.
OrangeC
double-veteran
double-veteran
Posts: 860
Joined: Sun Apr 20, 2008 2:58 am
Has thanked: 5 times
Been thanked: 33 times

Saints row IV ps3_vpp.

Post by OrangeC » Sun Aug 18, 2013 2:51 am

Has anyone taken a look at this?

PM me for sample.

Gh0stBlade
Moderator
Posts: 683
Joined: Mon Jul 05, 2010 8:55 pm
Has thanked: 20 times
Been thanked: 325 times

Re: Saints row IV ps3_vpp.

Post by Gh0stBlade » Sun Aug 18, 2013 2:04 pm

Can i have a see?
Click the thanks button if I helped!

OrangeC
double-veteran
double-veteran
Posts: 860
Joined: Sun Apr 20, 2008 2:58 am
Has thanked: 5 times
Been thanked: 33 times

Re: Saints row IV ps3_vpp.

Post by OrangeC » Sun Aug 18, 2013 2:17 pm

PM sent.

Gh0stBlade
Moderator
Posts: 683
Joined: Mon Jul 05, 2010 8:55 pm
Has thanked: 20 times
Been thanked: 325 times

Re: Saints row IV ps3_vpp.

Post by Gh0stBlade » Sun Aug 18, 2013 3:59 pm

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!

Thief1987
advanced
Posts: 72
Joined: Wed Jan 18, 2012 5:11 am
Has thanked: 1 time
Been thanked: 29 times

Re: Saints row IV ps3_vpp.

Post by Thief1987 » Sun Aug 18, 2013 4:10 pm

Seems it's used deflate compression, i'm not sure. Aluigi's offzip can decompress some data but not all

CRACKbomber
ultra-n00b
Posts: 5
Joined: Thu Nov 10, 2011 1:13 am

Re: Saints row IV ps3_vpp.

Post by CRACKbomber » Wed Aug 21, 2013 8:17 pm

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
Fixed your script with more accurate names. Also the compression is zlib.

User avatar
chrrox
Moderator
Posts: 2541
Joined: Sun May 18, 2008 3:01 pm
Has thanked: 57 times
Been thanked: 1269 times

Re: Saints row IV ps3_vpp.

Post by chrrox » Wed Aug 21, 2013 8:22 pm

its the same as a psarc file. they just modified it slightly.

michalss
Moderator
Posts: 941
Joined: Sun Mar 27, 2011 8:42 pm
Has thanked: 10 times
Been thanked: 134 times

Re: Saints row IV ps3_vpp.

Post by michalss » Wed Aug 21, 2013 8:24 pm

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/

OrangeC
double-veteran
double-veteran
Posts: 860
Joined: Sun Apr 20, 2008 2:58 am
Has thanked: 5 times
Been thanked: 33 times

Re: Saints row IV ps3_vpp.

Post by OrangeC » Wed Aug 21, 2013 9:07 pm

Yes i would like to know if 360 would be supported as well.

CRACKbomber
ultra-n00b
Posts: 5
Joined: Thu Nov 10, 2011 1:13 am

Re: Saints row IV ps3_vpp.

Post by CRACKbomber » Thu Aug 22, 2013 5:35 am

Yes, the PS3 and XBOX files are identical, just different endings.

Gh0stBlade
Moderator
Posts: 683
Joined: Mon Jul 05, 2010 8:55 pm
Has thanked: 20 times
Been thanked: 325 times

Re: Saints row IV ps3_vpp.

Post by Gh0stBlade » Thu Aug 22, 2013 9:53 pm

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
Click the thanks button if I helped!

CRACKbomber
ultra-n00b
Posts: 5
Joined: Thu Nov 10, 2011 1:13 am

Re: Saints row IV ps3_vpp.

Post by CRACKbomber » Thu Aug 22, 2013 10:28 pm

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
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
Moderator
Posts: 683
Joined: Mon Jul 05, 2010 8:55 pm
Has thanked: 20 times
Been thanked: 325 times

Re: Saints row IV ps3_vpp.

Post by Gh0stBlade » Thu Aug 22, 2013 10:59 pm

CRACKbomber wrote:
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
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)
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.

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!

michalss
Moderator
Posts: 941
Joined: Sun Mar 27, 2011 8:42 pm
Has thanked: 10 times
Been thanked: 134 times

Re: Saints row IV ps3_vpp.

Post by michalss » Sat Aug 24, 2013 8:11 pm

im almost sure that for x360 it will be xmem_decompress and it will compatible with qbms :D
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/

EcheloCross
veteran
Posts: 88
Joined: Sat Feb 27, 2010 6:57 pm
Has thanked: 38 times
Been thanked: 77 times

Re: Saints row IV ps3_vpp.

Post by EcheloCross » Thu Aug 29, 2013 2:36 am

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?

Post Reply