Sign in to follow this  
Followers 0
Valiant8086

encrypting a tcp client and server

3 posts in this topic

Hi.

First, on my phone I get a much nicer version of the autoit forums. Can I get that same alternative on the computer? I'm having trouble with the main autoit forum. Too much content. The pages are too big and when I have a page open to the forum it lags my entire computer down.

Ok, that said, I do have an autoit related question after all.

Basically, I'm trying to send an encrypted string from my client to my server. The client encrypts the command, sends it to the server, the server decrypts it, and follows the command if valid.

But it's not that simple it seems. I've got the client and server doing msgboxes for the time being so I can debug. The client shows the encrypted string that it's going to send, usually starts with 0x something. After I click ok it sends it. Now the server does a message box that shows the same string. I press ok and up comes another message box that's supposed to show the string that the client started with before the client encrypted it, but it's completely different.

I've made sure I use the same password. I've checked to make sure I'm not encrypting @CRLFs. I've tried aes256bit and Rc4 with more or less the same result. In those message boxes I put something like

msgbox(0, "", "heh"&$data&"heh") .

This has allowed me to ensure during my debugging there are no whitespaces before or after the string on both ends of the communication, and also the hehs are on the same line as the $data, so that would indicate the lack of @CRLFs, which is desirable.

I've made sure that when I go decrypt that an @CRLF hasn't been added in using the same method I just mentioned. Those msgboxes with the hehs around the string look exactly alike. All the encrypted characters are the same on both ends. So I think the problem is just on the server side. It is not decrypting properly. I have explicitly instructed it to create a new key with the password of "zomg" on both the client and server, don't worry this isn't the password I will always use for this, and I have supplied that key the same way to both the client and the server.

Any suggestions Would it have something to do with it being a different data type when it arrives to the server? I've tried different things with stringToBinary and binaryToString but while I do get different results none are anywhere near to being correct.

Thanks. I would include a copy of the script but I have bits and pieces of information that I wouldn't want public such as the real password I use. I hope in view of that I have done a good job explaining the situation. If not I can create a copy of the client and server that have been stripped to post here for examination. Keep in mind that I do believe I have tracked the bug down to being somewhere in the server side, as the server seems to see the same encrypted string the client sent before the server goes to work to decrypt the string.

Share this post


Link to post
Share on other sites



Did u check this, i use it alot its very good :)

Share this post


Link to post
Share on other sites

Hi.

I just downloaded the TCP with OOP thing. I'll take a look at it, but man, if I switch to this one, it'll be like the 5th time I've switched to a different tcp server/client UDF. Darn, the one I have ought to work.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0