section 3 of quickbms.txt:
http://aluigi.org/papers/quickbms.txt

uncompressed graphic file, this is not the correct section.
try here:
viewforum.php?f=18

done, anyway the provided archive doesn't have compressed files in it so I don't know if the ZSIZE/SIZE decompression is correct but don't worry because if there is a problem then quickbms will tell you that it's not possible to decompress the data and so you can send me the part of the BAD (and the...

the ARC script for quickbms seems valid for reinjection so take a look at section 3 of quickbms.txt: http://aluigi.org/papers/quickbms.txt then, just for your information, the author of the script is me and not that "sillysomething" who claimed the credits for the work done by other people...

yes, reading the rules.

if you did it, now you knew that there is a 31 pages thread here on xentax:
viewtopic.php?f=10&t=7208&start=450

the format is trivial but I don't know what compression it uses (yeah it looks easy but none of the default ones I scanned gave me the right result), so for the moment this is an useless script (aka DON'T USE IT): comtype lzo1x for get ZSIZE long get OFFSET long get XSIZE long get SIZE long getdstri...

script for QuickBMS: # Yainsidae # script for QuickBMS http://quickbms.aluigi.org idstring "JoyMax File Manager!\n" set OFFSET 0x100 set NAME string "" set PATH string "" callfunction EXTRACT startfunction EXTRACT goto OFFSET string PATH += NAME string PATH += / for sav...

script for QuickBMS:
http://aluigi.org/papers/bms/sherlock_lupin.bms

(I will upload it within some minutes so wait if you don't see it yet)

script for QuickBMS:
http://aluigi.org/papers/bms/sherlock_lupin.bms

this is a CRID archive that, as far as I remember, is something like a CRI CPK archives for videos.

maybe you can find more info here:
viewtopic.php?f=17&t=4956

password:

h5BFrLsjn7T9VsMBcru6

yeah sorry, my fault.
lately I'm loosing my mind so don't worry if I release wrong posts like the previous one :)

the important thing is that everything works perfectly.

*edit (my fault, the key is correct)*

in my opinion there is some sort of obfuscation that uses a xor with a 64bit incremental key.
that's the max I can see