Possible next features of QuickBMS
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Possible next features of QuickBMS
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.
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.
-
- Posts: 320
- Joined: Sun Aug 10, 2014 12:49 pm
Re: Possible next features of QuickBMS
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
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Possible next features of QuickBMS
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
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
-
- Posts: 320
- Joined: Sun Aug 10, 2014 12:49 pm
Re: Possible next features of QuickBMS
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...
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Possible next features of QuickBMS
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.
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.
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Possible next features of QuickBMS
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.
Currently quickbms contains 517 algorithms
I have also finished the tasks I had for my TODO.
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Possible next features of QuickBMS
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.
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.
-
- Posts: 320
- Joined: Sun Aug 10, 2014 12:49 pm
Re: Possible next features of QuickBMS
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
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Possible next features of QuickBMS
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.
The RSA encryption, export/reimport of strings, charset encoding and that sort of offzip-like scanner idea will be implemented in another version.
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Possible next features of QuickBMS
QuickBMS 0.6.2 is now available:
http://quickbms.aluigi.org
http://quickbms.aluigi.org
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Possible next features of QuickBMS
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).
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).
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Possible next features of QuickBMS
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
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
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Possible next features of QuickBMS
QuickBMS 0.6.3a
A small bugfix that is very important for the scripts that use the Strlen command.
Upgrade asap.
A small bugfix that is very important for the scripts that use the Strlen command.
Upgrade asap.
-
- Posts: 161
- Joined: Sat Dec 13, 2014 1:01 am
Re: Possible next features of QuickBMS
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:
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.
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.
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Possible next features of QuickBMS
getdstring doesn't stop at NULL bytes.
Probably what you want is:
getdstring NAME 10
set NAME unicode NAME
Probably what you want is:
getdstring NAME 10
set NAME unicode NAME
-
- Posts: 161
- Joined: Sat Dec 13, 2014 1:01 am
Re: Possible next features of QuickBMS
"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:
Then it just gets "Jan". This solution doesn't seem to handle more than one byte in a row.
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.
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Possible next features of QuickBMS
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
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
-
- Posts: 161
- Joined: Sat Dec 13, 2014 1:01 am
Re: Possible next features of QuickBMS
Hmm, ok. I guess I can work with that, it's not a huge issue. Thanks
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: Possible next features of QuickBMS
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.
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.
-
- Posts: 34
- Joined: Sun Nov 09, 2014 2:40 pm
Re: Possible next features of QuickBMS
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:
I think it would be easier for functions etc. to set the FILENUM like this rather than writing MEMORY_FILE after each command.
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.