Recent changes to FAQ

FAQ modified by chalo

chalo — Tue, 29 Oct 2013 20:34:49 -0000

--- v14
+++ v15
@@ -27,9 +27,6 @@
 **Does JBrute has support for Rainbow Tables?**
 No, and I have no plans for Rainbow Tables support.

-**Does the dictionary method has multi-threading support?**
-Not at the moment, I am still thinking on the best strategy to do that.
-
 **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 :)

@@ -51,10 +48,11 @@
 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 all versions of sql server until MSSQL2000
+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.

@@ -63,12 +61,13 @@

 Usability:
 ----------
-**Why do I get an error when trying to audit an Oracle10g/PostgreSQL hash?**
-These algorithms has a particulary: it uses the username as 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 (username) 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  hash:  (i will ignore it)" 
+**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  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$;
@@ -76,6 +75,10 @@
 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

FAQ modified by chalo

chalo — Fri, 27 Sep 2013 03:53:11 -0000

--- v13
+++ v14
@@ -4,17 +4,19 @@
 General:
 --------
 **Why should I use JBrute?**
-Well, that is a hard question to ask. First of all, you should see 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 (less than 200KB), easy to use and it implements several algorithms support out of the box. 
+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 told you, JBrute is just one more alternative, I learned a lot developing it, and it could be useful in some scenarios when JTR, for some reason, could not be available.
+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 situation.
+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.

FAQ modified by chalo

chalo — Tue, 17 Sep 2013 16:25:10 -0000

--- v12
+++ v13
@@ -43,14 +43,14 @@
 **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?
+**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 until 11gR1
+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.1
+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 all versions of mysql until MSSQL 2005 
-MSSQL-2005: works for all versions of mysql from MSSQL 2005 (inclusive) until MSSQL 2012
+MSSQL-2000: works for all versions of sql server until 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)

@@ -61,7 +61,7 @@

 Usability:
 ----------
-**Why do I get an error when trying to audit an Oracle10g/PostreSQL hash?**
+**Why do I get an error when trying to audit an Oracle10g/PostgreSQL hash?**
 These algorithms has a particulary: it uses the username as 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 (username) 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  hash:  (i will ignore it)" 

 So, the hashes should has the next format:

FAQ modified by chalo

chalo — Wed, 11 Sep 2013 20:11:26 -0000

--- v11
+++ v12
@@ -40,17 +40,6 @@
 **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.

-**Why does MYSQL-411 algorithm has poor performance?**
-My fault, it is an implementation problem, and it will be corrected in new versions. I tried to make the addition of an algorithm to JBrute a really fast process, and sometimes it requires performance loss. Mean while, you could use the chained algorithm technique: essentially, MYSQL-411 is a chained SHA1 algorithm with raw intermediate hash. So, suppose that you have the next hash: "3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1" or "*3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1" (if the rdbms has compatibility for older hashes enabled). You should use for MYSQL-411:
-$ jbrute --decrypt --hash=3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1 --algorithm=I
-or 
-$ jbrute --decrypt --hash=*3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1 --algorithm=I
-
-Instead, you could use the next command to audit this hash:
-$ jbrute --decrypt --hash=3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1 --algorithm=99 --chained_case=R
-
-Be carefull about the '*' character: if you decided to use the chained technique, then you must to remove it from the hash. Otherwise, you will get an error like "Not a valid SHA1 hash:  (i will ignore it)". You will discover that with the chained algorithm technique, it should be 4 times faster than MYSQL-411.
-
 **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.

@@ -63,6 +52,7 @@
 MSSQL-2000: works for all versions of mysql until MSSQL 2005 
 MSSQL-2005: works for all versions of mysql from MSSQL 2005 (inclusive) until MSSQL 2012
 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)

 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.

@@ -86,3 +76,6 @@

 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

FAQ modified by chalo

chalo — Mon, 09 Sep 2013 22:06:45 -0000

--- v10
+++ v11
@@ -67,7 +67,7 @@
 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 miltiple threads, and specially when you use number_threads = cpu_count, your results will change, and that change must be related to the system load.
+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:
 ----------

FAQ modified by chalo

chalo — Mon, 09 Sep 2013 22:06:09 -0000

--- v9
+++ v10
@@ -66,6 +66,8 @@

 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 miltiple 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:
 ----------

FAQ modified by chalo

chalo — Mon, 09 Sep 2013 21:09:06 -0000

--- v8
+++ v9
@@ -43,11 +43,13 @@
 **Why does MYSQL-411 algorithm has poor performance?**
 My fault, it is an implementation problem, and it will be corrected in new versions. I tried to make the addition of an algorithm to JBrute a really fast process, and sometimes it requires performance loss. Mean while, you could use the chained algorithm technique: essentially, MYSQL-411 is a chained SHA1 algorithm with raw intermediate hash. So, suppose that you have the next hash: "3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1" or "*3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1" (if the rdbms has compatibility for older hashes enabled). You should use for MYSQL-411:
 $ jbrute --decrypt --hash=3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1 --algorithm=I
+or 
+$ jbrute --decrypt --hash=*3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1 --algorithm=I

 Instead, you could use the next command to audit this hash:
 $ jbrute --decrypt --hash=3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1 --algorithm=99 --chained_case=R

-Be carefull about the '*' character: if you decided to use the chained technique, then you must to remove it from the hash. You will discover that with the chained algorithm technique, it should be 4 times faster than MYSQL-411.
+Be carefull about the '*' character: if you decided to use the chained technique, then you must to remove it from the hash. Otherwise, you will get an error like "Not a valid SHA1 hash:  (i will ignore it)". You will discover that with the chained algorithm technique, it should be 4 times faster than MYSQL-411.

 **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.

FAQ modified by chalo

chalo — Mon, 09 Sep 2013 21:04:41 -0000

--- v7
+++ v8
@@ -40,6 +40,15 @@
 **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.

+**Why does MYSQL-411 algorithm has poor performance?**
+My fault, it is an implementation problem, and it will be corrected in new versions. I tried to make the addition of an algorithm to JBrute a really fast process, and sometimes it requires performance loss. Mean while, you could use the chained algorithm technique: essentially, MYSQL-411 is a chained SHA1 algorithm with raw intermediate hash. So, suppose that you have the next hash: "3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1" or "*3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1" (if the rdbms has compatibility for older hashes enabled). You should use for MYSQL-411:
+$ jbrute --decrypt --hash=3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1 --algorithm=I
+
+Instead, you could use the next command to audit this hash:
+$ jbrute --decrypt --hash=3F50515DDEE62F18A2B1CE3BE819CFB2F3C869F1 --algorithm=99 --chained_case=R
+
+Be carefull about the '*' character: if you decided to use the chained technique, then you must to remove it from the hash. You will discover that with the chained algorithm technique, it should be 4 times faster than MYSQL-411.
+
 **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.

FAQ modified by chalo

chalo — Mon, 09 Sep 2013 20:11:39 -0000

--- v6
+++ v7
@@ -43,6 +43,18 @@
 **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 until 11gR1
+Oracle11g: works for all versions of Oracle Database from 11gR1 (inclusive)
+MYSQL-322: works for all versions of mysql until v4.1.1
+MYSQL-411: works for all versions of mysql from v4.1.1 (inclusive)
+MSSQL-2000: works for all versions of mysql until MSSQL 2005 
+MSSQL-2005: works for all versions of mysql from MSSQL 2005 (inclusive) until MSSQL 2012
+MSSQL-2012: works for all versions of mysql from MSSQL 2012 (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.
+

 Usability:
 ----------

FAQ modified by chalo

chalo — Mon, 09 Sep 2013 18:25:44 -0000