Possible next features of QuickBMS

[aluigi]

The only problem I see is that when you specify no number, it's just like specifying 0.
Let's say your default filenum is -1 (MEMORY_FILE) and you want to read data from file 0, how can quickbms know that?

deffilenum MEMORY_FILE
get DUMMY long 0 # MEMORY_FILE
get DUMMY long 0 # how to read data from file 0?!

[puggsoy]

You could make it that the file the script is working on is not actually file 0 but rather a special file type like INITIAL_FILE or something. Then whenever you pass 0 into a file command, it uses whatever is chosen as your "default file". This would be INITIAL_FILE by default, but you can change it. So that in this case you could do:

Code: Select all

get DUMMY long 0 # gets from INITIAL_FILE
deffilenum MEMORY_FILE
get DUMMY long 0 # gets from MEMORY_FILE
get DUMMY long INITIAL_FILE # gets from INITIAL_FILE

This would require some refactoring to the Get/Put methods (and their variations) but I agree that it would be very convenient, especially for scripts that rely heavily on MEMORY_FILEs or externally opened files.

[aluigi]

I will think about it but currently I don't know if I will implement it because adding a -1 or MEMORY_FILE is not a big effort in my opinion.
Avoiding to use that -1 means adding a new command and breaking the compatibility and comprehension of the *log commands

[aluigi]

The new SLog command is amazing... really.
I will perform some other few tests and then I will release quickbms 0.6.5 so that you can test this new command.

Currently the only "problem" is that it simply alerts if the new string is longer than the original without stopping the importing.
It's not a big problem, probably it's not a problem at all.

P.S.: it handles even the numbers so you can dump a 32bit number as a textual number and reimporting it back as a 32bit field

[aluigi]

QuickBMS 0.6.5 is ready.
Feel free to play with the SLog command and let me know what you think.

If you need an example script and sample, check the following:

Code: Select all

set STRINGS_FILE string "strings.txt"
slog STRINGS_FILE -1 0xb string
slog STRINGS_FILE -1 -1
slog STRINGS_FILE -1 -1 long
endian big
#slog STRINGS_FILE -1 -1 unicode
slog STRINGS_FILE -1 0x18 unicode
slog STRINGS_FILE 0x2e -1

http://aluigi.org/papers/bms/slog_test.dat (available also in attachment)

[aluigi]

Some things I want to do in the next version:

• avoiding the warning in append mode when you are appending data to a file you have just created: this is useful to return to the classical handling of chunked files without using memory files
• reimporting chunked files: just in reference to the previous point, I want to reimport chunked files. The current problem is that almost all the available scripts use a MEMORY_FILE as way to build the file and dump it on the disk (to avoid the "overwrite" warning) so it's probably necessary to modify all these scripts
• reimporting of chunked memory files: basically this is the idea for solving the problem in the second point, I can check if the append mode is active and then "trying" (because it's not so easy) to reimport the data from the memory file to the disk file. The cool thing here is that if I allow the reimporting of memory file only in append mode then it's possible to use this feature also with files to which you added a header, for example a wav file where you put the RIFF header and then append the original data from the file

Some of these features are easy to implement (the first 2 points) and if I can add all of them it's possible to reimport the chunked files which wasn't possible before.
Work-in-progress...

[aluigi]

The good news is that, apparently after some tests, now it's possible to reimport the chunked files.
The bad news is that you can do that only with the files saved directly to disk and not those dumped on a MEMORY_FILE and then on disk.
99% of my scripts use the MEMORY_FILE solution
I will keep you update if there are positive news.

[aluigi]

QuickBMS 0.6.6 is now available: http://quickbms.aluigi.org

And yes, reimporting of chunked files is now possible although don't expect miracles.
So try it and report any problem but keep in mind the following:

• if the script uses chunked files saved directly to disk (just few of my very old script) then you should have a very high chance of success
• if the script uses chunked files built on a memory file and then saved to disk (almost all my scripts) then it may not work, moreover if the script is quite complex

Hope you will enjoy it.

[Ekey]

Bug with CRC names fixed?

[aluigi]

Sure that it works.
Obviously it's necessary the 0x prefix before the hexadecimal numbers (otherwise they are decimal).

[puggsoy]

It seems like for [FILENUM] arguments in commands, we are unable to use variables, and that it requires raw numbers. For example, if I do this:

Code: Select all

open FDSE myFile.txt 1
set NUM 1
goto 0x20 NUM

I get this error:
Error: the specified file number (1024) has not been opened yet (line 306)

However if I replace the last line with this:

Code: Select all

goto 0x20 1

It works fine. It would be useful to dynamically be able to access different files using variables, is this possible? I understand that a simple workaround can be done with if statements, but if I want to do the same thing, just with different files, this can lead to a lot of repetitive code.

[aluigi]

Yeah, that's because the filenumber field cannot be a variable.
It's parsed when quickbms parses the script.

Currently there are no plans for using that field as variable because it would be a drastic change with, for sure, some bugs.
To be honest, in my scripts I had almost never a need to use it as a dynamic field, just in some rare occasions when using a function.

[michalss]

QuickBMS 0.6.5 is ready.
Feel free to play with the SLog command and let me know what you think.

If you need an example script and sample, check the following:

Code: Select all

set STRINGS_FILE string "strings.txt"
slog STRINGS_FILE -1 0xb string
slog STRINGS_FILE -1 -1
slog STRINGS_FILE -1 -1 long
endian big
#slog STRINGS_FILE -1 -1 unicode
slog STRINGS_FILE -1 0x18 unicode
slog STRINGS_FILE 0x2e -1

http://aluigi.org/papers/bms/slog_test.dat (available also in attachment)

Uhh nice, is there any doc for this pls ? Im gonna spend some time on that and test what i can...

[aluigi]

The only documentation is in quickbms.txt from line 3250.

As far as I remember it explains everything, included the possible errors and faults.
If you are interested in the source code take a look in src/file.c from line 1298 (dumpa_slog()).

[spider91]

Can you add an option to automatically rename files that already exist (like type "r" when quickbms asks what to do with existing files)?

[aluigi]

The slog command works in append mode so the same output name means that the new data will be concatenated to that file.
You have to generate a new sequential output filename if you want to avoid this behaviour.

But why do you want to save each string in a separate file?
In that case it's better to use the Log command.

Or are you referring to something different?

[spider91]

I don't need separate files for each string. I need only one file, but there is no string sizes and endline characters. Take a look at example.

http://www32.zippyshare.com/v/1ufkrFh8/file.html

[aluigi]

Code: Select all

get NAME basename
string NAME += ".txt"

get STRINGS long
for i = 0 < STRINGS
   get OFFSET long
   slog NAME OFFSET -1
next i

[spider91]

Thanks, didn't knew it add's endline characters by default.

And is there a way to use ID in hex like tag in output txt? For example add ID field to each offset (get OFFSET long and after that get ID long) than output it like .ini files

Code: Select all

00000001=string1
00000002=some another string
00000003=final string
...
00FFFFFF=end string

[aluigi]

No, every line is the whole string read from the file (multilines are escaped with \).
So the ID is the line number itself.