because start and end are only the limits of the file that was uploaded.
there is a "middle" part too

xcompress.lib :) anyway in my tests the XMemDecompression function wasn't able to decompress the RE5 x360 arc files correctly, I guess because it uses different window values (those 2 parameters accepted by the function) but really I don't know. the script I created works with all the ARC files exce...

"3E541F0C" would be a string if the sequence of bytes was "33 45 35 34 31 46 30 43", while in this case there are 4 bytes (32bits long): "3E 54 1F 0C".
verify it with the hex editor

well done, I have updated the script of the previous post

can you upload one of them (if there is one small) or the first 2 megabytes of one of them?

*updated script* # Cursed Mountain # script for QuickBMS http://aluigi.org/papers.htm#quickbms get SIGN long # 0xd2f17e00 getdstring DAT_NAME 32 get FILES long get EVER1 long get BASE_OFF long get ENTRY_SIZE long get INFO_OFF long math NAMESZ = ENTRY_SIZE math NAMESZ -= 24 set FOLDER_OFF long 0x40 m...

# script for QuickBMS http://aluigi.org/papers.htm#quickbms endian big get ARCHIVE_NAME filename get ARCHIVE_SIZE asize set OFFSET long 0 for PACK = 0 if OFFSET >= ARCHIVE_SIZE cleanexit endif set CORRECT_SIGN binary "\x10\x04\xFA\x99\x57\xFB\xAA\x33" getdstring SIGN 8 if SIGN != CORRECT_...

uhmmm, try to move the first "append" command after the log operation (invert their positions). I have edited the previous script in case of problems P.S.: the offset 00000000 is correct because it's the offset relative to the memory file where are temporary saved the files before the dump...

that problem you say just doesn't exist, for sure not with the script I wrote: offset filesize filename ------------------------------ 000809a2 27648 00000000.dat 00100f94 26624 00000001.dat 00188926 28160 00000002.dat 00205088 25600 00000003.dat 002693d2 21504 00000004.dat 002c62bc 20480 00000005.d...

findloc works correctly, indeed the files are all differents and the loop terminates without problem automatically (if findloc got the same value it was an endless loop)

I have only followed what you said using the size field you specified, I have done no further research.

in my opinion findloc should be used only in very very rare cases because the first way to follow is the full implementation of the archive's format from the first byte till the last one.

oh I forgot that yesterday I updated the main script because an user reported an error with the file "ondemand_awards-00.fbrb". the link to the updated script is ever the same: http://aluigi.org/papers/bms/fbrb.bms while the following is the technical explanation of the problem (that was n...

uhmmm there are various errors. I try to list almost all of them so that they could be useful to you and others. the first errors are in the format because size and frequency are long (32bits) and not short (16bits). then the part from channels to the data is composed by 6 bytes (for example 2 bytes...

get NAME basename string NAME += ".unpacked" comtype PUYO_LZ01 get TYPE byte get ZSIZE long get SIZE long savepos OFFSET clog NAME OFFSET ZSIZE SIZE for who is interested in the algorithm and in the technical stuff, it's simply lzss with an init char (the one used to fill the sliding wind...

uhmm a bad format because it doesn't have a real format. it's only a chunk based sequence of data composed by a zip file at the beginning and unknown content (probably encrypted with CryptEncrypt) from offset 0x34AC59. so till offset 0x34AC59 you can extract all the files in that chunked zip archive...