QuickBMS 0.7.0

News about new versions of QuickBMS
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

QuickBMS 0.7.0

Post by aluigi »

support for wildcards in the selection of input files, fixes in check_condition: constant strings, basename, filepath and filename, String reverselong/short/longlong weren't recognized, new 'y' String operator for alignment, Set to_unicode for converting to utf16, new FULLBASENAME type, better Print hexdump, String with constant strings, important fixes for the String operators: shl, mul, equal, split and cstring, some new compression algorithms, TEMPORARY_FILE now doesn't prompt for overwriting, better handling of same input and output file, Encryption Math with #INPUT#, some default values to the few compressions that required a ditionary value, LZ4 supporting dictionary and returning no errors in case of short output, fix for filexor/filerot with negative values, fix for utf16 conversion, information and fixes in the manual, reimplemented lzrw, balz and quad compressions, added mcomp/libmcomp, irolz, uclpack and ace compressions


Many bugs have been fixed.
There are almost 30 new compression algorithms useful for the comtype scanner.
About 15 of them are from libmcomp (aka mcomp.exe and mcomp_x32.exe, quite famous in the compression benchmarks), I implemented them by embedding the original executable that is called with the input and output files (named pipes). Just in case you notice an exe in %TEMP% launched by quickbms during the comtype scanning, it's all fine and documented :)

I opted for a major release stepping from 0.6 to 0.7 due to the various features (and fixes) implemented this year.
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: QuickBMS 0.7.0

Post by aluigi »

I have just noticed that some memory is wasted when quickbms is launched, something like 160 megabytes instead of less than 20.
That's caused by one of the new compression algorithms just implemented in this version (I bet quad or balz), so I will fix it or disable the algorithm in the next days.
It's not urgent but it's annoying when scanning the compressions where the speed is a priority.
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: QuickBMS 0.7.0

Post by aluigi »

Good news: there is no slowness during the comtype scanning, the timings are just like before :D

Anyway in the next version I will check if it's possible to lower the amount of memory used by quickbms when it gets launched (150 Mb) and to improve the speed during the comtype scanning.

Both are not very easy to accomplish because they are caused by third parties C++ compression algorithms that get initialized at runtime (tables and so on), but I will check it anyway.