use:
encryption xor str1

and if str1 contains some zeroes specify also its size
encryption xor str1 "" 0x10

filexor wants a hex string to work so it's not good in this case.

I have just released a tool that in my opinion can be useful in reversing game file formats. For example it can be handy when there is a field containing unknown data (encrypted, compressed) or just a 32bit that we don't know what represent (zsize, size, crc?). The tool is called Offbreak and you ca...

QuickBMS already uses the best solution for the deflate compression so there is nothing else I can do.

that's normal, in short the original file was bigger but had less "entropy" than your current one.
in short the sequence of bytes in your new files is more complex and so it's not possible to compress it till a final size equal or minor than the compressed one of the original file.

no, I work only on archives

I have just done a script for the game War Inc. Battle Zone:
http://aluigi.altervista.org/papers/bms/warinc.bms

yeah it's normal because the chunks get unpacked in memory and so 0 is the offset of the resulted memory file

filenames are not stored in the archive as far as I have seen so it's not possible to guess/retrieve them

ok done thanx. I have attached the current script to this thread so you can perform additional tests and when/if it's enough stable I will update the one online. as written in the title of the script I have just left all the compatibility work-arounds I inserted in the various versions of the script...

for the first problem I thought to have fixed some versions ago, are you using quickbms 0.5.15a? if yes, I will in the next version. anyway don't worry, just type the name manually removing weird chars like * and it's ok while for the second problem I guess you can ignore it because you are just at ...

I guess the following script does the job, let me know the result: # MediEvil PSP # script for QuickBMS http://quickbms.aluigi.org idstring "TOCS" get ARCHIVES long for i = 0 < ARCHIVES get HEAD_SIZE long get OFFSET long getdstring NAME 0x20 savepos TMP_OFF math OFFSET *= 0x800 goto OFFSET...

ok understood, so I guess there is one of those DUMMY fields in blur.bms that is used to track chunked files.
how much big is root.pak?
I don't have the game.

I don't see chunks in blur.bms

note that the key may change in other implementations of the format. set KEY string "36mA20gnJ" comtype copy idstring "PACK_FILE001" get FILES long get SIZE long savepos OFFSET encryption blowfish KEY log MEMORY_FILE OFFSET SIZE math OFFSET += SIZE for i = 0 < FILES math OFFSET +...