FAQ

FAQ (Frequently Asked Questions)

General:

Why should I use JBrute?
Well, that is a hard question to ask. First of all, you should think in JBrute as an Open Source alternative tool to existing related software. JBrute has special characteristics that could make it interesting for some people, like multi-platform support, multi-treading support, flexible options to work with chained algorithms, small size (around 100KB), no need to compile it, easy to use and intuitive, and there are several algorithms supported out of the box.
On the other hand, JBrute was written in Java, so, it has some limitations, like worst performance compared with c (or any low-level) developed tool.
If you have your own security app developed in java, and you want to add to it cracking support, then you could use JBrute instead of writing source code from scratch (of course, you will have to read JBrute´s license first).
Personally, I like to think in JBrute like an introductory tool to JTR, speaking of cracking art, or just a support tool for IT guys, like me.

But, JTR just do the job, in fact, really well, so...
Yes, and my work is based on JTR, of course. As I said, JBrute is just one more alternative, I learned a lot developing it, and I though that it could be useful in some scenarios when JTR, for some reason, could not be available. For this reason, I published it as an open source tool.

Support:

Does JBrute has any kind of hardware requirements?
Just the Java Runtime ones. But, I really suggest you 1GB of RAM to use java with initial heap space of 128Mb and 512MB for max space (this options are specified in the shell scripts that I provided together with JBrute jar). Why? Because you could have problems using big dictionaries. Actually, JBrute load all words for the specified dictionary on memory at the beginning of the process, and, if you have a really big dictionary, you could receive a "java.lang.OutOfMemoryError: Java heap space" exception. If you receive it, please play a little with these parameter in the bash scripts until you find the correct values for your dictionary.

Does JBrute has support for GPU processing?
Not at the moment, but I hope to implement it in future releases.

Does JBrute has support for distributed processing?
Not at the moment, but I am working on a server-client implementation for distributed processing.

Does JBrute has support for Rainbow Tables?
No, and I have no plans for Rainbow Tables support.

What are the supported platforms?
In theory, any platform that can run Java Runtime. I test JBrute on Windows, Linux and MacOS and it works :)

Algorithms/Performance:

Why does Oracle10g and LM algorithms has poor performance?
Both algorithms are base on DES, and Java implementation of DES has a really bad performance. If you find a Java DES implementation that is fastest than the native one, please let me now.

Why does MD5-crypt algorithm has a really poor performance?
It is because the implementation that I found for MD5-crypt. I duplicated the performance, but it still being poor. So, if you find other implementation, or if you just want to make a better one, please let me now about it.

I want support for an algorithm that JBrute actually did not support. Could you implement it?
Well, mail me and we will see. If it is an algorithm that is well know, or people generally use it, then it could be possible to add that algorithm to future JBrute versions.

What happends with versions of some product not mentioned?
The name of an algorithm represents the actual version supported plus older versions or newer versions of the same product, depending on each algorithm. So, the complete detail:
Oracle10g: works for all versions of Oracle Database from 7 until 10gR2
Oracle11g: works for all versions of Oracle Database from 11gR1 (inclusive)
MYSQL-322: works for all versions of mysql until v4.1.0
MYSQL-411: works for all versions of mysql from v4.1.1 (inclusive)
MSSQL-2000: works for sql server MSSQL2000
MSSQL-2005: works for all versions of sql server from MSSQL 2005 (inclusive) until MSSQL 2008
MSSQL-2012: works for all versions of mysql from MSSQL 2012 (inclusive)
SYBASE-ASE1502: works for all versions of sybase ASE from 15.0.2 (inclusive)
INFORMIX-1170: works for all versions of Informix from 11.70 (inclusive)

If you detect that there are some error respected to the hash algorithm used in some version of the supported apps, please let me nknow it and I will be happy to correct it.

Why does the test results with multiple threads are so different?
Maybe your OS is doing other things in the middle. If you repeat the test several times with 1 thread, you should see similar results, almost no difference. But, if you use multiple threads, and specially when you use number_threads = cpu_count, your results will change, and that change must be related to the system load.

Usability:

Why do I get an error when trying to audit an Oracle10g/PostgreSQL/Informix hash?
These algorithms has a particulary: it uses a salt, and this salt is not a part of the hash. So, in some way, you must specify to JBrute this salt. For this algorithms, the solution that I developed consists in passing the salt (the username for Oracle10g and PostgreSQL, and an in of 64 bits in Informix) in the same hash, with the '/' character as separator, before the hash. If you do not specify the hash in that way, you will get an error like "Not a valid <ALGORITHM> hash: <HASH> (i will ignore it)"

So, the hashes should has the next format:
Oracle10g : SCOTT/F894844C34402B67
PostgreSQL : gonza/md5f7a2af4f1f1f97b12b47d60579745fc3
Informix : 514052374115716813/lXIdcjtw8lGICcUwGv2wiKIKofisjeAvuBJKa4Zo3bw=

In Oracle10g, you can generate a list of hashes with the next query:
SELECT username || '/' || password FROM SYS.USER$;

In postgresql, you can generate a list of hashes with the next query:
select usename || '/' || passwd from pg_shadow;

In informix, you can generate a list of hashes with the next query:
select salt || '/' || substring(hashed_password from 1 for 43) || '='
from sysintauthusers;

For instance, if you want to audit an Oracle10g hash, you should use something like:
$ jbrute --decrypt --hash=SCOTT/F894844C34402B67 --algorithm=A

From version 0.93, you have a main parameter called "--expected". So, if you want to verify the format of an expected hash, then execute:
$ ./jbrute.sh --expected