Log in

View Full Version : Need help with network debugging


crUsAdEr
March 17th, 2005, 14:59
Ok i must start off i am a networking idiot so do go easy on me...

I have a client software that logs into a remote server and query & submit data to the server. I would like to find out how this client is interacting with the server, which API call, data format being sent so i can write my own software to interact with the server & submit data.

Well, here go.. i havent got a clue on how to start... it uses MFC7... so some start up tips would be appreciated.

cheers,
crUs

midnitrcr
March 17th, 2005, 15:07
Can you sniff a legit session between that application and another client? if so that is probably your only way of doing this as randomly sending data to the server is going to get you nowhere.

This is how a lot of the open-source chat clients figured out things like the yahoo and aim protocols.

crUsAdEr
March 17th, 2005, 15:11
Can you be more specific ? I have the software, i can run, control when it should connect when it doesnt... i suppose i can "sniff" but how should i go about doing it ? Oh yeah i have legit access to the server, it is nothing illegal, i can log in anytime, just trying to find a more efficient way of submitting data...

I was thinking more of like debugging the software to see how/when it connect to the remote server, send the data to server etc.

midnitrcr
March 17th, 2005, 15:23
First thing is first. Is this a binary or text-based protocol? My guess is binary which will be much more difficult to analyze. (although still possible) I will use a text-based protocol for the sake of brevity though.

Take SMTP for instance. Every connection to the server is initiated with a 'HELO' string followed by keywords telling who the message is from, the subject, etc... Assuming the conversation is not encrypted you could fire up something like ethereal on that network segment and collect the information transmitted back and forth. This is basic sniffing.

Then all you have to do is program your new client to use the same commands, formatting, etc... as what you viewed and you have your own SMTP mailer. Binary protocols will work the same way but it won't be as intuitive because its not in human-readable format. This means you will have to look at your packets you have collected and say "ok, the session initiates with the byte sequence 0x01 0x02 0x00" and implement your client to do the same. Not a fast process, but possible...

If you don't understand how sniffers work or how to read an ethereal/tcpdump packet log you are probably in over your head. Not meaning to be offensive, just statement of fact...

naides
March 17th, 2005, 15:31
Do you have or can you get a copy of the Server Software?

You could set up the server in a VMware virtual machine and the client in your host sytem or another Virtual machine. Then using VMtools like VnetSniffer and debuggers in both server and client VM you may have much better control in your analysis.

Just an idea.

midnitrcr
March 17th, 2005, 15:33
naides - what is vmsniff? I've not heard of that one before...

naides
March 17th, 2005, 16:08
my bad, I had just a vague recollection of the name.
The tool is called vnetsniffer

babar0ga
March 17th, 2005, 17:00
Hello!

For sniffing network communications i use Ethereal.
It's a realy fine piece of software...

You can download it from http://www.ethereal.com (it's open source)
And here is good screen shoot of what you can except: http://www.ethereal.com/mm/image/tcpstream-20010427.gif
Notice different colour for client and server data so you can't get lost easily...

blabberer
March 18th, 2005, 00:55
tamos softwares comm view is also a good sniffer and you can sniff in promiscous mode too with it it has a 30 day trial (half of the packets will not be visible some thing like that crap handicaps exist in trial)

there is a review article by Steve gibson of grc.com on various sniffers and
thier

look for shieldsup documentation part

i paste a url wander through the site there are valuble info in there
though the claims tend to be bombastic and self serving me me kind
http://www.grc.com/su-rebindingnt.htm

bilbo
March 18th, 2005, 03:23
Quote:
[Originally Posted by crUsAdEr]I have a client software that logs into a remote server and query & submit data to the server.

In many cases a full sniffer like ethereal or commview is not necessary: an HTTP protocol tracer could be enough. It MUST be enough if client and server can work also through an HTTP proxy.
I use HttpTracer, for example.
Best regards, bilbo

crUsAdEr
March 18th, 2005, 16:39
erm... thanks for the response guys...
Actually i was planning to approach it the reseving way, that is break on network API, then trace to find the code that interact with server, not tweaking with packet being transmitted over the network... hence was hoping for some tips on common API used by MFC7 or common MFC7 library function for remote networking...

Nope i do not have the server program. But i belive once i find the code that does the interaction with the server, reversing those code to work out data format, transmission protocol isnt hard... hence i am trying to take that approach.

Silver
March 19th, 2005, 08:21
MFC (well, VS) comes with the MFC call trace tool which may help you. A small hiccup will be MFC/win32 integration. MFC provides class libs for network operations, but some are limited and buggy. So a lot of MFC coders use the base classes for simple work, but revert to direct winsock code for anything more complex.

blabberer
March 19th, 2005, 08:31
networking apis ??
you mean wsastartup,socket,gethostbyname,gethostbyaddr,connect,recv,send,close socket if you break on recv then you should be able to sniff on the data tht is sent by some server now if there is an algo that decrypts it that has to follow close thats how it works generally

here is a small piece of c code that recvs and sends modified data back to
server

Code:

#include <windows.h>
#pragma argsused
WINAPI WinMain (HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
WSADATA wsaData;
SOCKET conn;
struct hostent *hp;
char *servername ="whatever your server name is";
long addr;
struct sockaddr_in server;
unsigned int buff[100] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
unsigned int temp[8] = {0,0,0,0,0,0,0,0};
char reabuff[500];
int i;
int wsaret = WSAStartup(0x101,&wsaData);
if(wsaret)
return;
conn = socket(AF_INET,SOCK_STREAM,IPPROTO_TCP);
if(conn == INVALID_SOCKET)
return;
if(inet_addr(servername)==INADDR_NONE)
{
hp = gethostbyname(servername);
}
else
{
addr = inet_addr(servername);
hp=gethostbyaddr((char*)&addr,sizeof(addr),AF_INET);
}
if(hp==NULL)
{
closesocket(conn);
return;
}
server.sin_addr.s_addr=*((unsigned long*)hp->h_addr);
server.sin_family=AF_INET;
server.sin_port=htons(5842);

if(connect(conn,(struct sockaddr*)&server,sizeof(server)))
{
closesocket(conn);
return;
}
recv(conn,buff,100,0);

\\ what ever happens to the crap that was recieved will be here
\\do whatever you want to do with it and send back your response
\\ it will most probably be a infinite loop recvinng all the time and
\\sendvinng till you shut it down
for(i=0;i<4;i++)
{
temp[1]+= buff[I];
}
send(conn,&temp[1],4,0);
recv(conn,reabuff,200,0);
return;
}

nikolatesla20
March 19th, 2005, 09:48
while it might seem like a good idea to break on the network API's, a sniffer really would help a lot, so you can see what the data looks like ahead of time. That way at least when you do start BPXing on API's you'll know you did it right cause of the data you will see...

CommView is an excellent sniffer, as well as that Ethereal.

To do network stuff you really need to use a sniffer, etc, it helps a lot. And get a good book on networking (A very good book about TCP/IP) Anything by SAMS will be excellent.

-nt20

tiocsti
March 19th, 2005, 12:39
Quote:
[Originally Posted by nikolatesla20]
To do network stuff you really need to use a sniffer, etc, it helps a lot. And get a good book on networking (A very good book about TCP/IP) Anything by SAMS will be excellent.


I'd recommend tcp/ip illustrated, volume 1. It will allow you to understand the protocols (particularly tcp) better.