Quote from: Ringo on March 08, 2006, 04:55 AMNo I did mean decode, because you said I shouldn't put the decoded CDKey in the log. So what you made, decodes and encodes right?Quote from: Jaquio on March 08, 2006, 04:38 AMIf you ment encode, so you can generate d2/w2 cdkeys from product, public and private value.
Hehe, that is pretty cool. But what would be the exact point of it? Lol, why would you need to decode a cdkey?
Edit: Oh nevermind I understand now, someone could take the decoded cdkey then re-encode it then have it, right?
Quote from: Ringo on March 08, 2006, 04:55 AMQuote from: Jaquio on March 08, 2006, 04:38 AMHm?
I tried what you had suggested and now instead of getting 0x80000001(Realm is unavailable) I get 0x80000002(Realm logon failed). I take it, it is from inserting the ClientToken where the cookie was supposed to go? Or is it something else?
Well, if its no longer saying realm unavalible, the realm can now see your chosen realm name, as its now at the right offset.
The only thing left to be causeing it now, is the hash and tokens used.
If your useing your client token as the "cookie" when you request BNLS hash the realm password, then you have to put it as the "cookie" in 0x3E bnet packet, other wise bnet will compute a hash differnt to yours, resullting in the realm failed responce.
See that is the thing, I am not sending a cookie at all when I hash the data. For BNLS_HASHDATA(0x0B) cookie is only used for a cookie hash, therefore I don't need to sned the cookie if I am double hashing the realm password. I have never used my client token as cookie for anything in my code, so wouldn't need to use it as a cookie to respond with. So I am not sure what the heck I am doing wrong, when I had it working once before...
Code Select
21 70.106.238.227:3928 63.240.202.127:6112 4 Send
0000 FF 40 04 00 .@..
22 63.240.202.127:6112 70.106.238.227:3928 51 Recv
0000 FF 40 33 00 00 00 00 00 01 00 00 00 01 00 00 00 .@3.............
0010 55 53 45 61 73 74 00 52 65 61 6C 6D 20 66 6F 72 USEast.Realm for
0020 20 74 68 65 20 55 53 20 45 61 73 74 20 43 6F 61 the US East Coa
0030 73 74 00 st.
23 70.106.238.227:3927 63.161.183.205:9367 27 Send
0000 1B 00 0B 08 00 00 00 02 00 00 00 05 55 4A 43 B9 ............UJC.
0010 E9 A6 09 70 61 73 73 77 6F 72 64 ...password
24 63.161.183.205:9367 70.106.238.227:3927 23 Recv
0000 17 00 0B A4 5D 0C 88 FD B4 71 B4 38 1B 8C F6 38 ....]....q.8...8
0010 26 37 25 D1 51 10 00 &7%.Q..
25 70.106.238.227:3928 63.240.202.127:6112 35 Send
0000 FF 3E 23 00 05 55 4A 43 A4 5D 0C 88 FD B4 71 B4 .>#..UJC.]....q.
0010 38 1B 8C F6 38 26 37 25 D1 51 10 00 55 53 45 61 8...8&7%.Q..USEa
0020 73 74 00 st.
26 63.240.202.127:6112 70.106.238.227:3928 12 Recv
0000 FF 3E 0C 00 05 55 4A 43 02 00 00 80 .>...UJC....
A new packet log using the client token as the cookie for sending to SID_LOGONREALMEX(0x3E)...