I am creating my own Java program that can do all the WIII hashing, and having no knowledge of all those encrpytion algorithms and methods, I am forced to use Iago's classes created for his JavaOp.

But, I'm having trouble with the SRP Class.  Generally, I can login fine the first time(sometimes this doesn't even work), but when I create a new SRP class, and try to login with it, I get Invalid Password errors from BNET.

I tested this by creating two SRP classes, and passing the same thing to both and returning the results.

[code]
byte[] s = in.removeBytes(SRP.BIGINT_SIZE);
byte[] B = in.removeBytes(SRP.BIGINT_SIZE);
mySRP=new SRP(aName,aPass);
mySRP.getAccountLogon();
System.out.println("[Acc Logon Proof] Username: "+ aName + " Pass: "+aPass);
Buffer t1=mySRP.getAccountLogonProof(s,B);
System.out.println("First Time: "+t1.toString());
mySRP=new SRP(aName, aPass);
mySRP.getAccountLogon();
Buffer t2=mySRP.getAccountLogonProof(s,B);
System.out.println("Second Time: "+t2.toString());
[/code]

Gets:

[code]
[Acc Logon Proof] Username: fool-1 Pass: fool
First Time: 24 1d d8 79 d8 98 47 67 d7 b9 9b 32 ab 43 6a 93 $..y..Gg...2.Cj.
bd 27 40 e9                                      .'@.
Length: 20

Pass:FOOL
Second Time: 70 99 5e f4 66 4d 51 5a 3d ec 17 11 4e 9c 88 0c p.^.fMQZ=...N...
54 8a 93 e7                                      T...
Length: 20
[/code]

To me, this seems like something inside the class is not getting reset.  Most likely this is java.security.MessageDigest, but the API claims that it is reset on every .digest() call.  So....any ideas what might be causing this?
[color=Black][/color][color=Black][/color][color=Black][/color]

I have no idea what's different.  Why don't you put print statements throughout the function that you're calling and see where it diverges?

Well, I looked into where it changed(many print statements), and I saw what I didn't realize at first - that privKey has a random element within it.  When I set this to a unchanging value, the results from both calls came out the same.  Is it possible to leave this value constant?

Something else I noticed:
[code]
username = username.toUpperCase();
password = password.toUpperCase();
[/code]

I thought War3 passwords were case sensitive?

However, somehow I have succeeded in breaking it(even with # only passwords), and even after replacing with a fresh SRP class, I am getting Invalid Passwords all the time.  I'm at a loss, and am still trying to blame the JVM's SHA-1.  Perhaps I'll find another implementation of it somewhere.

[quote author=The-FooL link=topic=9031.msg83648#msg83648 date=1097198758]
I thought War3 passwords were case sensitive?
[/quote]
Well, technically, yes, as the hash will differ if the case of the things being hashed are different.  However, the official Blizzard game client will automagically send your password in uppercase (I thinK?),  so he probably added that to make it less confusing for people.

Edit:  Actually, I thought Blizzard clients send password in lowercase... weird.

[quote author=Soul Taker link=topic=9031.msg83668#msg83668 date=1097212802]Well, technically, yes, as the hash will differ if the case of the things being hashed are different.  However, the official Blizzard game client will automagically send your password in uppercase (I thinK?),  so he probably added that to make it less confusing for people.

Edit:  Actually, I thought Blizzard clients send password in lowercase... weird.[/quote]

Under Old Logon System, passwords are lowercased before processing.  Under New Logon System, they are uppercased before processing.  In both cases, it's likely an attempt to keep people from locking themselves out by screwing up the case of their password (since the real clients don't show you the password as you type it, even for creating the account).  As far as I know, neither system sends the server enough material to reliably divine what input you used, so the only reason to include the force-to-case in your client is to guard against users who put in a mixed case password, then wonder why it doesn't work (answer: because the password was only one case in the real client, but your client is leaving it mixed case, thus causing a mismatch).

[quote author=Kp link=topic=9031.msg83669#msg83669 date=1097213893]
Under Old Logon System, passwords are lowercased before processing.  Under New Logon System, they are uppercased before processing.
[/quote]
That's what I figured, never looked into it in the NLS, good to know.