A few observations with regards to nishnet's original post.
1) Nishnet, are you sure that the cons string is an encrypted version of the following?
&curservid=.....&prevservid=....&version=....&sessionid=...&srcip=....&username=...&password=..
By sure I mean - did you see all those variables being accessed in code, concatenated in a smilar form and then encrypted? Or this is just an educated guess becuase it was what was being sent for login with the previous protocol and the string still does exist in the new client?
2) Are you sure it's encryption as opposed to a one way hash? I tend to agree with Bhaskar (who said it was a hash [maybe casually]).
3) AFAIK, Crypt.dll is not installed with the new dialer and is a remnant of the older client. It's a right pain installing the new client in a folder of your location (can you?) and when you're not connected to Sify all the time (I have to switch cables and hope Sify is up - which it isn't 50% of the times I try). So I haven't been able to confirm this, but if crypt.dll is not shipped with the new client, then perhaps it should be discounted from our investigation.
My observations:
1) The cons string is the same for each session of BBClient, no matter how many times you attempt to login using that session. If you close BBClient and reopen it - you get a new cons string.
2) I think it is a one way hash formed from your username and password and perhaps the other details specified in the string above. The macid is transmitted in clear text and is used to look up your record in the database, the same hashing function is performed on your records and the results are compared.
Different string each BBClient session? As Nishnet stated, it is quite likely that the session id sent to the client from the server is used to salt the input string. If it's only the session id - then the salt does not need to be transmitted along with the hash, since the server knows it already. If it's something else - like the system clock or a combination, the salt does need to be transmitted to the server in clear text at some time.
The cons string itself could contain the salt, but I'm hardly sure.
Note: This entire theory is backed by intuition, not fact.
3) I think both BBClient.exe and BBAppDll.dll are involved in constructing the cons string.
4) It would be cool if we could somehow spoof the sify server and feed controlled input to BBClient as Nishnet suggested (or intercept and change the packets), the output could then be observed for different cases and give us a better idea of what's goin on.
5) When the app is started and after each login attempt - the SEED value in this key HKEY_LOCAL_MACHINE\SOFTWARE\
Microsoft\Cryptography\RNG is modified. I noticed that this happened in the earlier client as well, and it does not seem to tie in with the fact of a constant cons string per session, as the SEED value changes each time you click Login - probably just a red herring.
6) Apparently the old login pages (validatelogin.php and logout.php) still work, inspite of the server returning validatelogin2.php and logout1.php)
I guess these will work for a little while more until all their servers are uptodate with the new protocol (or maybe until they write the Java client
)
No further ideas at this point. I'd vote for making this the thread of choice for protocol discussion. I'm hardly a professional cracker so if anyone can break this and let us all know, awesome. Do share your insights on the issue here.
Best,
Brian.
