Join Hands for Open Source Sify Dialer

  • Thread starter Thread starter nishnet2002
  • Start date Start date
  • Replies Replies 36
  • Views Views 15,602
N

nishnet2002

Newbie
Messages
15
Location
NA
Hello guys, i have kindof worked on BBClient.exe to find its encryption/decryption technique... well the exams are on head so didn't give much time.. the following data might be useful to reverse engg the code..

Sify has comeup with new broadband dialer. The technical details what i found out are as follows:

1) The BBClient sends data using some encryption technique.


2) The data sent is in following format:
cons= ....240 characters.....&macaddress=0C-0C-0C-0C-0C-0C
The characters found to be
* nos 1 -- 9
* alpha a --- f
This concludes that it is represented in HEXADECIMAL FORMAT.


3) CONS contains encrypted data as follows:
&curservid=.....&prevservid=....&version=....&sessionid=...&srcip=....&username=...&password=..

(I am still guessing what are these for : curservid and prevservid )


4) There are two keys embedded into BBClient.exe
key1=29355d121c211de0717c127166713ebb
(key2 I will give it later)


5) One key is found in Crypt.dll which is as follows:
F9E5CCCE853B11D4A5470050DA8C23EA

--- I will work on this after my exams by that time i hope some one would carry forward the work
 
Hmm eentresting, so they are encrypting and not hashing :SAnyways, even I've got my exams coming so cant contribute much...... 🙁. Nevertheless great work on the disassembly.My guess for servid would be the Service Plan ID like QMU7/QMU1 etc. No idea what previous and current are for though...Are you confident that its encrypted and not hashed, and that there are 7 values sent and not 6. Coz if you do a sha1 hash of the 6 values , thats 40 * 6 = 240 string in hex format. Maybe the keys are just a salt.......I will check later if I get the time, whether a sha1 of the following values yields the same result as what is sent to the server.One thing to keep in mind is that they are using PHP backend so the encryption method should be available in PHP. A base_64 most probably if its an encrypted value.
 
240 chars? No wonder I cudn't figure it out... I was stuck on 239.. I got it frm your dump. Anyway, that does look suspiciously like SHA1 except for the fact that there are seven values rather than the necessary 6.
BTW, how did u figure out the contents of the string?
The keys could be something else in entirety, but they are 128 bit... so possibly that is some form of symmetric encryption/authentication.

If instead of seven items, there are 6, then we have 160 bits per item, ie a 160 bit block. And that could be the following:
http://en.wikipedia.org/wiki/SHACAL

SHACAL-1 uses keys of 128bit (which are padded up to 512 bits)

"My guess for servid would be the Service Plan ID like QMU7/QMU1 etc"
I don't think so. All those fields there must either entered by the user (username/pass), available from the system (IP) or retrieved from the server (sessionid). But how could it possibly know which service plan ID to use for the login? That information (mapping of service plan to login) is available after logging in, not before.
 
bah nevermind my post, its too late in the night for my brains to work : P.

Like I said in the ither thread the vars can be from the foll:
ip
macaddress
os
version
php_session_id
username
password

I had stated that the key I gave in the dump was edited........

BTW, how did u figure out the contents of the string? [/b]
On disassembling, any good disassembler will list the String Outputs, this is one of them.
 
Good good 🙂. Let us all work towards it. Like all engineering students, I too have my exams. BTW can someone figure out the API that crypt.dll uses? Can we use it without actually breaking their encryption? Please correct me if we can't use their DLL. I am not knowledgeable about Windows programming.Tushar / other Sify users, I have one request for you guys. Put in dummy user names and passowrds like test and test and find out the encryption string. Do this with atleast 5 to 10 username / password combos. We can take the help of some people who know about encryption. May be they can figure out what the heck the encryption is!And please remember, I dont personally own a Sify connection. So I can't do any testing on my side. But if I am given the protocol specs then I can whip up a client for Linux and possibly for Windows too! 😀
 
It is not a question of breaking their encryption - that is impossible (well with Sify you never know... but normally you can't). The question is, can we figure out which technique they are using? Possibly.
 
kingkrool, yes, by "breaking" or "cracking" their encryption I meant that we need to reverse engineer their encryption algorithm. Using their own DLL wouldn't be appropriate because that will attract legal action against us. So we need to know the encryption algorithm which isn't very difficult if they are using a two way algo.
 
hello guys exams are over and I am back..Inorder to try out various inputs to the Sify BBClient we must depict the Sify's actual server.The various inputs to BBClient would be SessionID.Also the custom Server will enable us to:1) Run the client no of times without actually getting Sify ppl doubt abt our login attempts...2) We will able to send dummy values like SessionID=000000000.....3) One can perform the test even when he doesn't have a sify connectionIf some one can depict the sify server it would be a grt help...we dont want exact working but just working server
 
play safe


never use sify BBclient

Usage of sify BBclient might be injurious to ur comp 😛

use an alternative client
 
agent, if you were on an IRC channel then you would be kicked and banned before the impulse from your finger tip could reach your brain. Please read the entire thread before you post. We are discussing about making an _alternative_ client _because_ the other alternative clients _dont_ work _because_ of the new protocol. But I guess you havent noticed it? 😕
 
I tried the linux client too under ubuntu, it says "Please Update your Client" even though i downloaded the latest version. its clear that their linux client is also not maintained anymore. Even that client gets a "NOUPDATE" response from the server.
 
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.
 

Top