Luigi Auriemma

in the last weeks I have worked hard on a new project which I started almost casually as an experiment and is now a very good project that I use everyday.

QuickBMS belongs to the "archives extraction" field, so the same field of tools like Dragon Unpacker, Game Extractor, MultiEx and so on but with the difference that it's not intended to have an internal database but for being quickly reprogrammed on the fly through small basic scripts which can be written by me or anyone else.

indeed it reads just these textual "scripts" written in an enhanced BMS language and with which is possible to handle the majority of game and non-game file formats.

so, for example, is possible to write on the fly scripts for reading the archives of games like Still Life 2, or for extracting the ZIP archives or even for decrypting files encrypted with Blowfish.

practically for all the recent files extractors I'm writing (check on Xentax where I'm active lately) I'm just using these scripts without writing a line of C and saving tons of time to me and to anyone who doesn't need to download a new tool all the times.

homepage of the project:

http://aluigi.org/papers.htm#quickbms

oh, it works from both command-line and minimalistic GUI so it's also easy to use.
hope it helps

thank you very much that helped me very much , only thing it whould be much beter if it also compress the files back :)

I have done!

rot13 (also known as Caesar cipher) is the simple adding or substraction of a number to another.
for example if your byte is 0x41 and ROT13 is set to 2 the byte will become 0x43.
instead if it's -8 the byte will become 0x39

I have Done

Thanks a lot

I have commented each line:

One thing - Can I run that script on Mr.Mouse' MEC?

I have tried, what i'm missing?

MEX doesn't have the new commands that I implemented in quickbms like filerot13 and it requires the full syntax mode where you specify the file number in each file-operation and the need of the ';' char at the end of each line

Ok, but what I have to change into above script to make MEX read it?

filerot13 is not implemented in mex so it can NOT read it.
but why you want to use mex?

coz I manually importing edited files into archive, which is hard work, and as I know MEX can do it automatically as bms extracts it.

I made out file so it doesn't use filerot13 to decode the file, so now script is



Now can I use it? I've tried in MEX 4.3.0 and in GE, but no senses

naaa the import method used by mex is not really what you mean, as far as I know and I have seen it's only a work-around which overwrites some parts of the original archive (so if the file you want to add is bigger than the original you can do nothing).

anyway add a 0 at the end of each "get" and "log" operation, example:
get FILES long 0;
log NAME OFFSET SIZE 0;

and use "for i = 1 To FILES;"

but for enabling the import work-around you must add two other variable in Log: http://wiki.xentax.com/index.php/BMS#Log
so contact mr.mouse for major info about how to adapt that bms code and moreover about what the import mode can really do for you in this case, he is the only one who can help you about this mex-related function.

Okey, thanks to you for the much more help

Hello pal

How to do like so:

in file containing files so... 1 jpg 2jpg 3 jpg, all after one finished comes other, not sizes nothing is given, so how to tell bms script to get all files?

you need to use a generic ripper in that case because quickbms, although able to do it, has been created for specific formats

here is a file whi contains jpg file, in the begining is somthing but i couldn't make it out, may be u can detect where is adrss and size in this file.
I cut only from the begining and where begins first jpg file

the jpg starts at offset 0x106, have you tried to use a ripper for it? (example: http://wiki.xentax.com/index.php/Jaeder_Naub)

so i found size and start

1. 256 byte before file starts
2. 1byte after it is file size
3. 3bytes after it doesn't need
4. begins file

so how would be script?

uhmmm in my opinion there is something missing because a filesize of 1 byte (8bit) is never used in archives.
then looks like that Images1.p you posted is incomplete because the jpg file is long only 0x4a bytes.
and then seems that there are some fields missing, maybe try to make an image of the hex editor and underline the fields to which you refer with different colors

i was wrong, sorry
1. 256 byte before file starts
2. 4 byte after it is file size

so i did what i wanted, manually - edited 1-2 files, thanks