aluigi, posted Wed Apr 01, 2015 7:12 am (4273)

---

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

aluigi, posted Mon Apr 20, 2015 6:09 pm (4682)

---

The -d option is very useful but I guess that most of the users don't know it.
Unfortunately doesn't exist a way to automatically understanding when activating it so I have to leave it disabled by default.

I was thinking to automatically enabling it when, in GUI mode, the user select multiple files.
But I don't know what the script does and if the archive already include the full paths so if you handle archives that use the archive name as path, then it's good, but in all the other cases it's bad (for example a simple file decompressor).

Mah, just making some brainstorming but I think I will leave everything as is and it's job of the script to create the folder path based on the archive name when necessary (I guess it's not a very diffused technique).

aluigi, posted Fri May 01, 2015 10:31 am (4944)

---

I have just released QuickBMS 0.6.3:
http://quickbms.aluigi.org

Note that the support for string operations is not available yet because I really have no idea of how to implement it due to various things (automatic append mode, handling of unicode and non-unicode strings and so on).

I was thinking to something like the log command:
slog NAME OFFSET SIZE FILE_NUM UNICODE

But what to do if the data at that offset is unicode?
How to handle the append mode and the consequent warning to the user who should press 'a' to continue?

One idea may be to dump just unicode data by performing a conversion of the ansi/utf8 strings.
So, extraction: bytes -> unicode and unicode -> unicode
reimporting: unicode -> bytes and unicode -> unicode

I wanted to allow a way for dumping a string as-is like the getdstring command, but it's not compatible with the slog command.
It would have been used in situations like:
get STRING_SIZE long
getdstring STRING STRING_SIZE

that otherwise should be handled as:
get STRING_SIZE long
savepos OFFSET
slog FILENAME OFFSET STRING_SIZE
math OFFSET STRING_SIZE # or goto STRING_SIZE 0 SEEK_CUR
goto OFFSET

Mah, let me know what you think

aluigi, posted Wed May 06, 2015 9:22 am (5062)

---

QuickBMS 0.6.3a
A small bugfix that is very important for the scripts that use the Strlen command.
Upgrade asap.

puggsoy, posted Sat May 09, 2015 4:56 am (5139)

---

Is there any way to get a string of specified length (like getdstring) without stopping at a null byte? For example if I have something like:

Code:

68 00 65 00 6C 00 6C 00 6F 00          h.e.l.l.o.

And I want to get the string "hello".

If there is no way to do this can it be added in? Workarounds are possible but probably pretty tedious.

aluigi, posted Sat May 09, 2015 10:33 am (5143)

---

getdstring doesn't stop at NULL bytes.
Probably what you want is:

getdstring NAME 10
set NAME unicode NAME

puggsoy, posted Sat May 09, 2015 10:52 am (5144)

---

"get NAME unicode NAME" gives an error but "set NAME unicode NAME" is probably what you meant, since that works.

Still a bit of an issue though. If I have:

Code:

4A 00 61 00 6E 00 00 00 00 00 46 00 65 00 62 00          J.a.n.....F.e.b.

Then it just gets "Jan". This solution doesn't seem to handle more than one byte in a row.

aluigi, posted Sat May 09, 2015 10:55 am (5146)

---

Yeah I meant set and not get
In your example is correct that it gets only Jan because it's considered a string.
In that case I would just use:
get NAME1 unicode
get NAME2 unicode

puggsoy, posted Sun May 10, 2015 2:43 am (5167)

---

Hmm, ok. I guess I can work with that, it's not a huge issue. Thanks

aluigi, posted Sun May 10, 2015 4:06 pm (5188)

---

Maybe give me some feedback about the decoding of utf16 unicode in utf8.
In the latest version of quickbms there is a codepage command that allows to choose the preferred charset (and it works) but I would like to have some opinion and feedback.

barti, posted Tue May 19, 2015 6:51 pm (5311)

---

Here's something I thought might be useful in some cases: could it be possible to change the default FILENUM all operations are performed on? Something like this:

Code:

get NUM1 long # reads long from input file
deffilenum MEMORY_FILE
get NUM2 long # reads long from memory file

I think it would be easier for functions etc. to set the FILENUM like this rather than writing MEMORY_FILE after each command.

aluigi, posted Tue May 19, 2015 7:02 pm (5312)

---

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, posted Wed May 20, 2015 10:48 am (5318)

---

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:

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, posted Fri May 22, 2015 7:26 am (5353)

---

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, posted Sun Jul 05, 2015 11:03 pm (6146)

---

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, posted Wed Jul 08, 2015 10:28 am (6216)

---

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:

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, posted Tue Jul 14, 2015 3:56 am (6369)

---

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, posted Fri Jul 31, 2015 10:27 pm (6741)

---

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, posted Sun Aug 02, 2015 6:05 pm (6757)

---

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, posted Mon Aug 03, 2015 4:14 pm (6773)

---

Bug with CRC names fixed?

aluigi, posted Mon Aug 03, 2015 8:09 pm (6775)

---

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

puggsoy, posted Tue Aug 11, 2015 6:08 am (6822)

---

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:

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:

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, posted Thu Aug 13, 2015 2:28 pm (6845)

---

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, posted Thu Aug 13, 2015 3:18 pm (6847)

---

aluigi wrote:

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:

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, posted Sat Aug 29, 2015 5:52 am (6960)

---

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()).