Pete Finnigan's Oracle Security Forum


    
      
        Pete Finnigan's Oracle Security Forum
        (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
      

        Oracle Security >> Oracle Security tools >> Toolcrypt's orabf
        
(Message started by: Pete Finnigan on Aug 29^th, 2005, 12:17pm)

Title: Toolcrypt's orabf
Post by Pete Finnigan on Aug 29^th, 2005, 12:17pm

Did you notice that the new version of Toolcrypt's orabf (http://www.toolcrypt.org/) now breaks passwords up to 15 characters, in stead of just 5 as was in the previous public release of orabf, version 0.32?

I'm trying to break a password of 8 letters right now and it happily goes beyond the 5 character mark. It is working on 7 letter combinations as we speak. My guess is that in about 3 and a half hours it will have checked all 1 to 7 letter combinations (on a PC with one 1.7 Ghz Pentium 4).

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Aug 30^th, 2005, 10:26am

A nice new feature of orabf is the possibility to resume cracking of a password.

orabf <passwordhash>:<username> <complexity> <max. characters>
For example:
orabf AG1232B114F4A25A:USERNAME 2 8

You can resume cracking this password with this command:

orabf AG1232B114F4A25A:USERNAME 2 8 resume

orabf has just cracked my 8 letter password here in 6 hours and 42 minutes. One sidenote here, my password started with an "A". orabf works through the list of passwords from A to Z, so a password "ZZZZZZZZ" would have taken considerably longer to crack.

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Aug 31^st, 2005, 1:27am

I did a crack of a 6 character password in about half an hour (while I was using the PC for other stuff).
I was checking alphanumeric as well, and I noticed it included passwords starting with a number.
Not sure about 10G/10Gr2, but 9iR2 doesn't allow passwords starting with a numeric unless quoted.

Playing around with the resume file would probably allow you to start with A..... , and I guess if you had a couple of dozen PCs you could start one on each letter of the alphabet. [The resume file has 6 fields - the first I think is the number of combinations tried, the second is the username, the third is the last password checked, not sure on the fourth, the fifth is the complexity and the last is the max password length multiplied by two.]

I think it is safe to say that 8 character passwords can be practically cracked using brute force. 9 character would need some heavy resources.

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 1^st, 2005, 3:12am

Just a note regarding timings on RDS:

The million passwords per sec for orabf is based on the Brute Force mode. Reading from a dictionary file slows it down to around 100,00 per second. [Specifically on my machine orabf went done from 990,000 on brute force to 115,000 per second on dictionary].

checkpwd reads the dictionary file first (took 15 secs for about 1.5 million passwords on my machine). Once in memory it only took 5 seconds to go through the list (about 300,000 per sec).
This method took slightly longer overall for an individual crack, but it would be a lot quicker if it was cracking a set of users over a database connection as it only reads the file once.

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 1^st, 2005, 8:33pm

Hi everyone,

0rm has emailed me today to let me know that orabf has been updated to version 0.7.2 - this is available from [url http://www.toolcrypt.org/tools/orabf/index.html]http://www.toolcrypt.org/tools/orabf/index.html[/url]. He has fixed a small bug that prevented passwords that were a multiple of 4 from being cracked in brute force mode. In dictionary mode the problem did not exist. Download the updated version if you are using the cracker for real.

cheers

Pete

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 16^th, 2005, 2:13am

Just a note about the RESUME mode of this.
If orabf is stopped part way through, it creates a file with the suffix .res for resuming later.
The first part of this file name is the hashed password and the file contains the cleartext username. As such, the file itself is a potential security hole, so if you have been playing around with the tool its best to delete or secure any .res files that has been left.

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 17^th, 2005, 7:55pm

Good point Gary, but remember it is only a risk on Windows boxes as its a Windows binary, or rather Win32 binary. Good catch though.

cheers

Pete

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 19^th, 2005, 8:35am

Hi everybody,

Recently I did some tests with orabf on a Pentium 4 1,7 Ghz with 512Mb (memory is hardly a factor, orabf regularely uses about 700 Kb). I hacked alphabetical passwords with different lengths. Now orabf works through possible alphabetical passwords from A-Z, so to get the maximum time involved in cracking say a 5 character password, I chose 'ZZZZZ'. And here are the results:

Username	Password	Password hash	Time to crack	Number passw. tried
Z	Z	319B5E833E3291F7	00d 00:00:00	default
Y	Z	646A52B5505852EA	00d 00:00:00	27
Z	ZZ	5A99821B918805AA	00d 00:00:00	703
Z	ZZZ	748B146ADFA8EB5E	00d 00:00:00	18279
Z	ZZZZ	05C69D5374090AF5	00d 00:00:01	475255
Z	ZZZZZ	F29224D28E7B57EF	00d 00:00:16	12356631
Z	ZZZZZZ	124F2EA043CD2ED1	00d 00:08:52	321272407
Z	ZZZZZZZ	C717F96D746B3294	00d 03:16:55	8353082583
Z	ZZZZZZZZ	7AAED8BB9D1B19F3	04d 09:12:38	217180147159

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 20^th, 2005, 1:25pm

Marcel-jan,

I don't understand the last column: "Number passw. tried"
From A to Z is 26 and from A to ZZ is 676 (s6^2) , etc.
How do you explain 27, 703, etc?

kind regards,

Ivan

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 21^st, 2005, 10:46am

Ivan,

That has also boggled my mind. I've deduced that the formula to calculate orabf's letter combinations is:

combinations = combinations_n-1 * 26 + 1
where combinations₀=27.

I wonder why that is. Perhaps it's a programming error.

Another thing for improvement is the way it approaches passwords with the full characterset. This set (which follows the ASCII table) is as follows:

NULL ! " # $ % & ' ( ) * + , - . / 0-9 : ; < = > ? @ A-Z [ \ ] ^ _ ` { | } ~

orabf checks for passwords that start with the full characterset, while an Oracle password can only begin with a letter. So there is another possible speed improvement.

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 21^st, 2005, 10:57am

Marcel-jan,

Thank you for the explanation. It's a pity the makers of orabf didn't release the source of orabf. As you mention orabf waste time calculating hashes for passwords that are not allowed in Oracle.

groetjes,

Ivan

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 21^st, 2005, 11:39am

I see it as a possibility to make orabf perform even better. I've send a mail to toolcrypt.org with the suggestions.

In the meantime I'm doing some performance tests on passwords with the full characterset (as far as possible in Oracle of course). Already it shows that using extra characters increases the time to crack a password dramatically. Cracking a 5 letter password takes 16 seconds, but with the full characterset it is probably going to take anything between 3/4 hour to a full hour. I'll keep you informed.

Another thing I should point out to anyone reading my performance test is that when 'ZZZZZ' as a password takes 16 seconds to crack and 'ZZZZZZ' takes about 9 minutes, cracking a 6-letter passwords takes of course anything BETWEEN 16 seconds and 9 minutes. I thought I should add that.

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 21^st, 2005, 12:36pm

Marcel-jan,

If you use A-Z and 0-9 for your 8 characters long passwords you will have 2.901.713.047.668 password! (In reality of this number Oracle would accept 2.818.071.110.712 passwords as correct ones. Any password starting with a number would be refused)
If orabf computes 1.000.000 passwords/sec it will take
it 34 days to compute all 2.901.713.047.668 hashes.

It would be very nice if orabf would take into account any password policy defined in Oracle. A password policy could dramatically (?) reduce the universum from which passwords are chosen. Many use the standard password policy as defined by Oracle in utlpwdmg.sql:
password should contain at least one character, one digit and one punctuation.

regards,

Ivan

p.s. I calculated 2.901.713.047.668 as:
Omega (n 1 to 8) = 36^n
2.818.071.110.712 is the above without those passwords starting with a digit

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 21^st, 2005, 8:58pm

Hello Marcel-Jan and Isaez

The algorithm of orabf is correct.

Oracle passwords can start with every character from the entire characterset. If your password start with a special character you must use a doublequote ".

SQL> alter user scott identified by 1alex;
alter user scott identified by 1alex
*
ERROR at line 1:
ORA-00988: missing or invalid password(s)

SQL> alter user scott identified by "1alex";

User altered.

SQL> alter user scott identified by "!alex";

User altered.

SQL> alter user scott identified by "[alex";

User altered.

SQL> alter user scott identified by " alex";

User altered.

Regards

Alexander

---

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 22^nd, 2005, 9:45am

Kornbrust,

There are some characters that can't be used even inside quotes. Like &, @ . Those two characters are interpreted by sqlplus (at least & is). @ is interpreted as a remote connection.
Also, not every dba/developer uses quotes in alter user to allow their users use punctuation characters.

By the way: people think that strong passwords are password that comply with rules like: at least 6 characters, at least one digit and at least one punctuation. Those rules are in reality in favor of brute force attacks! There is a paper from Lohkee that you can find through Google. Look for : Lohkee strong passwords zucchini
The web page doesn't exists anymore but you can read it from the cache.

regards,

Ivan

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 22^nd, 2005, 10:36am

Ivan

where is the problem with & and @ in passwords?

+++++++++++++++++++++++++++++++
SQL> alter user scott identified by "&alex";
Enter value for alex: &alex
old 1: alter user scott identified by "&alex"
new 1: alter user scott identified by "&alex"

User altered.

or you could use the "set define off" command
SQL> set define off
SQL> alter user scott identified by "&alex";

User altered.

SQL> alter user scott identified by "@alex";

User altered.
+++++++++++++++++++++++++++++++

You mentioned in your post that orabf is checking impossible passwords like "!alex". That's not true. A DBA can (not must) use such a password and orabf is able to find it.

Regards

Alexander

---

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 22^nd, 2005, 12:51pm

Alexander,

With regard to & : you say it your self. You have to set define off
With regard with @:

ISAEZ on 22-SEP-05 at IVAN2 > alter user isaez identified by "@bla";

User altered.

ISAEZ on 22-SEP-05 at IVAN2 > connect isaez
Enter password:
SP2-0306: Invalid option.
Usage: CONN[ECT] [logon] [AS {SYSDBA|SYSOPER}]
where <logon> ::= <username>[/<password>][@<connect_identifier>] | /

You could always do: connect isaez/"@bla"
But try to tell this to your users:-)
The point I'm trying to make is that there is room for improvement for orabf. If a dba, like me, has a password policy defined for his users like ( for example in my case start with a alpha (A-Z), at least one digit, at least one punctuation ($_#) and at least 6 characters long) then orabf could take such a policy into account. It would be so much faster to check those passwords.

regards,

Ivan

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 22^nd, 2005, 6:50pm

Ivan,

OK now I understand. Users can be diffcult . You suggest an additional mode for orabf.

In my opinion it makes more sense to change your password verify function. At least 9 characters + special characters for normal users and 12 characters for system accounts(sys,system,outln,dbsnmp, ...).

Instead of using BF I would recommend you the following approach:

1. BF hashkeys for short passwords (up to 6 characters), if these passwords are possible.

2. Check the rest of the passwords with a dictionary attack. The probability to guess/find a weak password is much higher than BF. And that's the goal, isn't it?

You can use John The Ripper to create permutations (even with your own rules) of your dictionary file.

checkpwd
[...]
Q: Is there a bigger dictionary file with permutations e.g. Oracle, 0racle, Oracle1, Oracle2, ...?
A: You could use John the Ripper to create such a dictionary file (e.g. john.exe -wordfile:password_list.txt -stdout -rules > password_list_big.txt). The result is a 840 MB file.
[...]

Regards

Alexander

------

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 22^nd, 2005, 7:18pm

Alexander,

Thanks for your input.
Yes, I suggest an additional mode for orabf.
The problem is that we have a password policy that resembles very much another password policy for the OS. Users want to have the same password for Oracle as for the OS. Maybe a bad idea but we have to follow.
By the way: OPS$ accounts are out of the question.
Users have passwords that for an outsider seems strong enough but for insiders are sometimes easy to guess. For example JDHG2.33 is composed of the users initial John Doe, the building HG and room 2.33.
Another popular form is JD#12256 (John Doe and internal phone number). So a dictionary attack is probably not very useful. So my idea was to have a orabf-like tool and let it check a subset of the posible password universum (namely those defined by the password policy).
I'll take a look at John The Ripper (not Jack?); maybe I can generate permutations for popular passwords.

In the long run a PKI/SSO solutions seems ideal but legacy applications makes it difficult.

Thanks.

regards,

Ivan

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 24^th, 2005, 9:30pm

Hi Ivan and Alex,

Can I make a few comments on this excellent discussion. The first to Ivan, the fact that you use a policy that is based on users names, locations and phone numbers sounds like a bad idea. If any hacker learns this all he has to do is steal phone lists, room numbers etc and he can crack any users password. It also sounds like users passwords are not changed often if at all if they are based on simple rules such as this.

You said that brute force is easier. In fact in this case a dictionary attack is better although the dictionary is a custome one based on your users names, phone numbers and buildings. Also if an outsider happens to brute force a few passwords he might be able to guess the naming sequences used.

Alex, we have I think discussed this before in email or IM. I think a good order to crack passwords is:

1 - username=password
2 - username has a default password (or is a default user)
3 - username has a dictionary word for its password
4 - brute force up to 6 characters ASCII
5 - depending on time brute force ASCII+DIGITS for 6 characters

Of course as each password is cracked at each stage it would be then tried for all users at the same time and the list of users to crack would be reduced. I would also throw in the hashes from SYS.USER_HISTORY$ and also clear text passwords from various internal tables such as SYS.LINK$

cheers

Pete

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 25^th, 2005, 7:50am

Pete,

I don't use a policy that is based on user names, locations and phone numbers. The users do. Our policy, as I said, is based on another password policy: at least 6 chars, start with one alpha, at least one digit and at least one punctuation. I just noticed that users where using passwords with their initials, phone- and room numbers in it.
Passwords are changed every 3 months, old passwords can't be reused.
So there is a password policy in place but the constructud passwords are predictable (not all of them of course). I think this is a common problem: if you don't have a password policy people tend to use common (short) words as passwords. Words like : sex, secret, topsecret, etc. Or password=username. And if you have a password policy they tend to device some sort of mechanisme to remember them (write it on a post-it and put it on the monitor). Apperantly users, maybe following some ones advice came up with these combinations of initials, phone/room number. I've told them not to use those passwords because they are predictable. And now I was hoping to check with orabf if they came up with more secure passwords. But for the longer passwords orabf's method take to long to crack.
A dictionary attack is indeed in those cases better (faster). But I was hoping that orabf could be learned about a password policy.
For the time being I've a custom password verification policy that checks those predictable passwords and refuses the password when a user tries to change his password. But it's not 100% safe (false positives) and users find it very irritating.
There is a great deal of psychology involved in passwords.

regards,

Ivan

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 25^th, 2005, 7:24pm

Hi Ivan,

Thanks for your upate, I undertand your situation now. I think for you a custom version of orabf would be a great help. I think also for others as well it would be useful if the author of orabf could make a brute force version (policy might be a better description) that took into account (dynamically) password policies that are in use.

cheers

Pete

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 26^th, 2005, 8:38am

I think this raises the issue of why "strong" passwords can be worse that "weak" ones, albeit very differently from the paper mentioned :
"There is a paper from Lohkee that you can find through Google. Look for : Lohkee strong passwords zucchini "

The strong password is supposed to
1) Make it harder for a brute force attack to succeed because the larger character set makes the task take longer.
2) Make it harder for a dictionary attack to succeed because passwords using these characters are less likely to be in the dictionary.

However, working against the "strong" password is that a person still has to choose and remember it. And quite simply, people are unable to choose 'random' passwords.
In many cases, they'll go for a a word and add a number and symbol to the end, or other simple 'munge', or use personal information such as a phone number, car's registration number etc.

If they are given a random password, it will probably be forgotten or written down. Perhaps there is scope for an application that generates random passwords plus a mnemonic for remembering them ?

The crackers posted here make it clear that dictionary words and short (six/seven and even eight character) passwords are easily cracked. 'Munged' and nine/ten character passwords won't stand up much longer. CPUs are catching up with them.

But this is based on knowledge of the HASH password. I wonder if the next step is up to Oracle and making this less accessible.

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 26^th, 2005, 6:08pm

Hi Gary,

I liked the comments that you have made. You are right a password policy to make a supposed stronger password could make it weaker but only if the hash is known and only if the policy is known. Remember we are discussing auditing and not hacking. A hacker should not have the password hashes in an ideal world so use of orabf would then not be possible. He would need to resort to other methods such as connect scripts which would nevre be practical for brute forcing. Also in an ideal world the hacker would not have access to the complete password policy. It would be contained in the profile and also in code in a verification function. The profiles should only be read if a user has already been compromised that has access to profiles and the same if a user has been compromised that has access to the password function code. If the function were wrapped then that would be much harder.

So as you point out the need is to be able to protect the hashes. block access to SYS.USER$, DBA-USERS, SYS.USER_HISTORY$ ... also orapwd file, full exports, list files from sqlplus etc...

Also the issue of reading the password policy from the database is controlled by ensuring access to all base tables and views are locked down to DBA's ior SYS and that these users have passwords of 12 characters.

I agree with what you are saying but its as complex landscape that depends on knowedge of the hash and policy to make it easier to crack with brute force.

Nice comments gary.

cheers

Pete

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 28^th, 2005, 10:41am

Hi everybody,

I did some new time measurements, this time with passwords with alphanumerical character plus special characters (the entire keyspace). Again I've used my Pentium 4 1,7 Ghz with 512Mb. Also I tried to crack passwords that contain ~ characters, which are at the end of the list of ASCII characters orabf scans for. Therefor it will take the most time per character.

USERNAME	PASSWORD	PASSWORDHASH	Time to crack	Number passw. tried
--------	---------	----------------	----------------	-------------------
Z	~	E45D4F87F1720058	00d 00:00:00	70
Z	~~	7CA60AB459936F74	00d 00:00:00	4831
Z	~~~	74579775C249B06A	00d 00:00:00	333340
Z	~~~~	B8A8583F562B1AE2	00d 00:00:36	23000461
Z	~~~~~	373D8989A86FBDE7	00d 00:42:40	1587031810
Z	~~~~~~	6F08342ABF265F91	01d 16:47:23	109505194891

Notice how much longer it takes to crack passwords of 6 characters. I could try to crack a 7 character password, but it is obviously going to take more than a month. So I calculated it:

USERNAME	PASSWORD	PASSWORDHASH	Time to crack	Number passw. tried
--------	---------	----------------	----------------	-------------------
Z	~~~~~~~	AE7E50824EB70A9A	117d 06:30:00	7555858447480
Z	~~~~~~~~	C0249B54717714E7	8091d 16:00:00	521354232876121

So if you use passwords of eight characters and special characters, cracking that hash will take anything between 117 and 8091 days. Sounds like that that is still pretty safe.

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Sep 29^th, 2005, 1:01pm

Hi Marcel-Jan,

Thanks for your updated timings, they are very useful and interesting. I have two comments/observations.

The first is that your use of a one character username will skew the results a bit as the total number of characters in the username/password has a bearing on the crack time. Study the algorithm and you will see. It will not have the same effect as the difference between 6 and 7 character passwords or 7 and 8 character passwords for instance but would have some effect.This can be measured by testing the number of hashes per second on orabf for a 8 character username/password combination and also a 9 character one, the same test can be done on a 17 character combination. This result could be plugged into your results.

Also passwords of 7 and 8 characters are probably out of the reach of most people but if the password being cracked were important enough to crack then "someone" (a government for instance) would certainly have the computing power to crack them in a reasonable time. Even utilizing the power of the net would be a possibility for hackers. For instance to crack an 8 character password would take 8091 days or one day for 8091 computers. Hackers routinely take over groups of PC's to send out spam so it is not inconcievable for hackers to do the same for cracking Oracle passwords.

A third point (OK, sorry I promised 2 points) is that whilst your measurements are valid the time to crack a 1 character to 8 character password the time could be reduced as we should take into account probability. e.g. it is probable that some passwords would be found at the beginning of the keyspace search and also probably that some would be found at the end of the keyspace. Therefore we could use an average time (or whatever the probability mean (whas the name? - standard deviation?) is).

Nice testing though Marcel-Jan,

cheers

Pete

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Oct 5^th, 2005, 9:25am

Hi Pete,

Thanks for the feedback. I've tried cracking the same password with different usernames:

USERNAME	PASSWORD	PASSWORDHASH	Time to crack	Number passw. tried
--------	---------	----------------	----------------	-------------------
Z	~~~~~	373D8989A86FBDE7	00d 00:42:40	1587031810
ZZ	~~~~~	6A5210699D12B455	00d 00:37:14	1587031810
ZZZ	~~~~~	A321E37C438FDC8A	00d 00:37:37	1587031810
ZZZZ	~~~~~	66712F4DD8D15493	00d 00:51:47	1587031810
ZZZZZ	~~~~~	9495C316A1CDBD4E	00d 00:45:09	1587031810
ZZZZZZ	~~~~~	5F0FBC104CEC7DAE	00d 00:44:25	1587031810
ZZZZZZZ	~~~~~	B995ED989374B5F3	00d 00:41:14	1587031810
ZZZZZZZZ	~~~~~	CFB3E087D3C4AB39	00d 00:58:52	1587031810

So this proves your first point.

About your second point. Yes, I suppose that when you would have a distributed computing version of orabf, you could do that. And there are enough zombie-pc's to go around. On the other hand you need to have someones username/hash. On the other other hand (hang on, that's three hands) these are often too easily available (dbsnmp/dbsnmp anyone?).

And to conclude this post: the standard deviation of measured time to crack above is 438.0 seconds (according to Excel's stdev function), the average time is 2692 seconds (44 minutes and 52 seconds).

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Nov 4^th, 2005, 1:20pm

i wrote mine tool less then a year ago for my final thesis ;)

my proggie cracks around 13k/sec in a dictionary mode which is not that bad i suppose :P
also when it comes to BF to compare you have to use the same characters(alphabet) in every programm
i dont know what alphabet is used by orabf for example

i wanted to ask is there orabf source code available?

if not is it possible to get some details about methods/algoriths used inside (not the hashing one)
language used/compiler and so on
generally what makes this tool so fast ;)

im asking because i had some problems with finding good ones already written by someone
and i have done it from scratch
for example i had asm code that leaded to 100%memory consumption in a fewseconds

greetings
Lucas

ps. hello to everybody since this is my first post ;)

Title: Output to file?
Post by Pete Finnigan on Dec 30^th, 2005, 5:32am

All,

I feel kind of silly asking this, but I've been struggling with what I thought would be an easy thing to do: I would like to audit some of my Oracle passwords by feeding orabf a list of password hashes with user ID's,use a large password file list, then let it run for a while. I was able to use the cmd script included in the orabf download to grind through the list and display the results to the screen with no problem (except it output so much info that I lost some of the data in my command window.) So, I decided to re-run it and output the results to a file. This seemed pretty easy, but so far no luck. I have tried a couple of variations of "orabf hash:userID passwordfile 4 8 > outputfile.txt" (with a userID = password combination to make testing run quickly) and have had no luck. If I don't attempt to redirect the output to a file, orabf reports it has found the password and displays it. If I try the simple redirection above, the screen does not display the password and a 0 length file is created. I am hoping I am just missing something really simple and one of you can point me in the right direction.

Thank you for your time,
John

Title: Re: Toolcrypt's orabf
Post by Pete Finnigan on Dec 30^th, 2005, 9:55am

Hi,

I am not a DOS (is it still DOS?) expert. Ihave had the same problem withn redirecting output to a file in DOS. I took an alternate route. Go to the system menu of the DOS window, top left c:\ icon and choose properties. In the layout tab change the screen buffer height to 9999 and it should then be possible to run it to the screen and mark and copy the results to a file.

hth

cheers

Pete