Possible next features of QuickBMS

Doubts, help and support about QuickBMS and other game research tools
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Possible next features of QuickBMS

Post by aluigi »

Yes it's in my TODO list as last thing to implement before the release.
That feature would be interesting but I have some doubts about its implementation.
For example let's say that all the strings are dumped in a text file one-per-line and one of them is a multi-line string... in that case the reimporting would be not possible.
An alternative is placing a certain sequence of chars to divide each string like "###" or similar to limit the problem.

Then there are the size limitations because it would be just a reinjecter (the only choice for being a generic tool).

Basically the main benefit in this feature is just the possibility to translate games without using a hex editor.
That's the only benefit because the rest is just like a hex editor work.
michalss
Posts: 320
Joined: Sun Aug 10, 2014 12:49 pm

Re: Possible next features of QuickBMS

Post by michalss »

true but \r or \rn can be easy to detect and simple implement replace it with something like [\r] or similar. I guess this is easy. Well to be honest everything is better then use HEX :D
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Possible next features of QuickBMS

Post by aluigi »

That's a good idea too that allows to have everything in one line.
By using [\r][\n] I can even avoid to "parse" the string because it will be enough to make a replacement.

I have just noticed that after having added over 30 new algorithms the size of the final exe is almost 13 megabytes :O
michalss
Posts: 320
Joined: Sun Aug 10, 2014 12:49 pm

Re: Possible next features of QuickBMS

Post by michalss »

aluigi wrote:That's a good idea too that allows to have everything in one line.
By using [\r][\n] I can even avoid to "parse" the string because it will be enough to make a replacement.

I have just noticed that after having added over 30 new algorithms the size of the final exe is almost 13 megabytes :O


Also 1 more thing, need to be able to specify the encoding as well mate.. Commons are Unicode, UTF8, ASCII, etc...
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Possible next features of QuickBMS

Post by aluigi »

I have had some problems while trying to implement the unicode charset handling in the past.
Basically doesn't matter what charset I chosed because the result was ever the same or not matching the expected one.

I guess that this week I will release the new quickbms and then I will work on the string-related stuff for the next-next version.
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Possible next features of QuickBMS

Post by aluigi »

I would like to add some compressions that may be available in RPGViewer and not in quickbms but I don't know the games and samples of these compressions, if you know them or remember something feel free to let me know.

Currently quickbms contains 517 algorithms :)

I have also finished the tasks I had for my TODO.
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Possible next features of QuickBMS

Post by aluigi »

I'm evaluating the possibility of moving the source code of quickbms in another ZIP, maybe a quickbms_src.zip so that only who needs it will download it.
The reason is that currently the compressed "src" folder is over 4 megabytes and is totally useless (if not even confusing) to the final user.
michalss
Posts: 320
Joined: Sun Aug 10, 2014 12:49 pm

Re: Possible next features of QuickBMS

Post by michalss »

aluigi wrote:I'm evaluating the possibility of moving the source code of quickbms in another ZIP, maybe a quickbms_src.zip so that only who needs it will download it.
The reason is that currently the compressed "src" folder is over 4 megabytes and is totally useless (if not even confusing) to the final user.



agrees :)
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Possible next features of QuickBMS

Post by aluigi »

QuickBMS 0.6.2 will be released in the next hours.
The RSA encryption, export/reimport of strings, charset encoding and that sort of offzip-like scanner idea will be implemented in another version.
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Possible next features of QuickBMS

Post by aluigi »

QuickBMS 0.6.2 is now available:
http://quickbms.aluigi.org
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Possible next features of QuickBMS

Post by aluigi »

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
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Possible next features of QuickBMS

Post by aluigi »

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
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Possible next features of QuickBMS

Post by aluigi »

QuickBMS 0.6.3a
A small bugfix that is very important for the scripts that use the Strlen command.
Upgrade asap.
puggsoy
Posts: 161
Joined: Sat Dec 13, 2014 1:01 am

Re: Possible next features of QuickBMS

Post by puggsoy »

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: Select all

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
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Possible next features of QuickBMS

Post by aluigi »

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

getdstring NAME 10
set NAME unicode NAME
puggsoy
Posts: 161
Joined: Sat Dec 13, 2014 1:01 am

Re: Possible next features of QuickBMS

Post by puggsoy »

"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: Select all

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
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Possible next features of QuickBMS

Post by aluigi »

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
Posts: 161
Joined: Sat Dec 13, 2014 1:01 am

Re: Possible next features of QuickBMS

Post by puggsoy »

Hmm, ok. I guess I can work with that, it's not a huge issue. Thanks :)
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Possible next features of QuickBMS

Post by aluigi »

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
Posts: 34
Joined: Sun Nov 09, 2014 2:40 pm

Re: Possible next features of QuickBMS

Post by barti »

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: Select all

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.