Problem Reading Network Packet Data
-
I hope nobody gets upset about me starting a new thread - I've posted a couple about this project already but the problems I'm encountering are different each time. The server application I've written in Visual Basic is receiving a packet of data from a client. I have had nothing to do with how the client communicates, and I can't change it - I'm sort of trying to 'reverse engineer' an existing application. A packet sniffer tells me what the data of the packet from the client contains. In hex it is:
414D464D1A000000BD020012FB21CC1F0600000053746F636B73The same packet sniffer software tells me that this converts to:AMFM....½...û!Ì.....StocksThe word 'Stocks' at the end is the client name, so obviously that's what I'm trying to obtain. I have no idea what the other bits mean. But when the little application I've written receives this packet and displays the data received it only displays "AMFM". Nothing else. If I change my code to display the hex received and not the ASCII conversion it shows the whole hex code, just as the packet sniffer does. Why does it only show me these first four characters (plus the mysterious box)? How can I get the rest? Oddly enough, when copying the output from the packet sniffer to the clipboard as I wrote this, even though I selected the whole string when I pasted it into my browser window it only pasted "AMFM". What's going on?! -
I hope nobody gets upset about me starting a new thread - I've posted a couple about this project already but the problems I'm encountering are different each time. The server application I've written in Visual Basic is receiving a packet of data from a client. I have had nothing to do with how the client communicates, and I can't change it - I'm sort of trying to 'reverse engineer' an existing application. A packet sniffer tells me what the data of the packet from the client contains. In hex it is:
414D464D1A000000BD020012FB21CC1F0600000053746F636B73The same packet sniffer software tells me that this converts to:AMFM....½...û!Ì.....StocksThe word 'Stocks' at the end is the client name, so obviously that's what I'm trying to obtain. I have no idea what the other bits mean. But when the little application I've written receives this packet and displays the data received it only displays "AMFM". Nothing else. If I change my code to display the hex received and not the ASCII conversion it shows the whole hex code, just as the packet sniffer does. Why does it only show me these first four characters (plus the mysterious box)? How can I get the rest? Oddly enough, when copying the output from the packet sniffer to the clipboard as I wrote this, even though I selected the whole string when I pasted it into my browser window it only pasted "AMFM". What's going on?!Not all data is text, some is just binary data; and some is mixed (as in an EXE file). Text processing often stops at the first NULL character, which is a zero byte. The non-user content of TCP/IP packets is documented in the TCP/IP documentation. :)
Luc Pattyn
Local announcement (Antwerp region): Lange Wapper? Neen!
-
Not all data is text, some is just binary data; and some is mixed (as in an EXE file). Text processing often stops at the first NULL character, which is a zero byte. The non-user content of TCP/IP packets is documented in the TCP/IP documentation. :)
Luc Pattyn
Local announcement (Antwerp region): Lange Wapper? Neen!
By "non-user content" are you referring to the header information and so forth? I'm already ignoring all of that, this is just the part identified as "data" by the packet sniffer. Is there a way to have my code continue to look for text in the string after it encounters a null byte? Or just to read the last characters of the string, which seem to constitute the client name?
-
By "non-user content" are you referring to the header information and so forth? I'm already ignoring all of that, this is just the part identified as "data" by the packet sniffer. Is there a way to have my code continue to look for text in the string after it encounters a null byte? Or just to read the last characters of the string, which seem to constitute the client name?
You'll have to go over the byte data yourself and look for alphanumeric ASCII values. Relying on the Encodings classes to do it for you will all result in stopping at the first 0 byte they encounter. You're going to have a very difficult time with this. It's like you're trying to speak Japanese by duplicating the sounds of the words you hear instead of understanding the language.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009... -
By "non-user content" are you referring to the header information and so forth? I'm already ignoring all of that, this is just the part identified as "data" by the packet sniffer. Is there a way to have my code continue to look for text in the string after it encounters a null byte? Or just to read the last characters of the string, which seem to constitute the client name?
Hi, if all the sniffer knows is Ethernet packets, then it would strip Ethernet heads and tails, and call the remainder "data". However other protocols are built on top of that, each adding either entire packets, or pre- and postfixing their own header and tail to the actual user data. research TCP/IP, it is all standardized and documented and slightly complex if you're new to it. :)
Luc Pattyn
Local announcement (Antwerp region): Lange Wapper? Neen!
-
You'll have to go over the byte data yourself and look for alphanumeric ASCII values. Relying on the Encodings classes to do it for you will all result in stopping at the first 0 byte they encounter. You're going to have a very difficult time with this. It's like you're trying to speak Japanese by duplicating the sounds of the words you hear instead of understanding the language.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...And here was me thinking I'd had a difficult time up until now! I like your analogy - but if this packet contains data in a 'foreign language', what does speak this language? So in theory if I create a loop which works through every byte in the string looking for characters with ASCII values between 32 and 126 and adds them to a string if they match those criteria that should work? /sigh
-
Hi, if all the sniffer knows is Ethernet packets, then it would strip Ethernet heads and tails, and call the remainder "data". However other protocols are built on top of that, each adding either entire packets, or pre- and postfixing their own header and tail to the actual user data. research TCP/IP, it is all standardized and documented and slightly complex if you're new to it. :)
Luc Pattyn
Local announcement (Antwerp region): Lange Wapper? Neen!
-
Luc Pattyn wrote:
slightly complex
Slightly?! :p Thanks for the help, I'll crack on and read the documentation!
Not immediately recognizing some hex output doesn't necessarily make it complex. if you want something complex, have a look at PEF, the file format used by Windows executables. :)
Luc Pattyn
Local announcement (Antwerp region): Lange Wapper? Neen!
-
And here was me thinking I'd had a difficult time up until now! I like your analogy - but if this packet contains data in a 'foreign language', what does speak this language? So in theory if I create a loop which works through every byte in the string looking for characters with ASCII values between 32 and 126 and adds them to a string if they match those criteria that should work? /sigh
phil2415 wrote:
So in theory if I create a loop which works through every byte in the string looking for characters with ASCII values between 32 and 126 and adds them to a string if they match those criteria that should work?
You'll get some form of data. Whether or not it means anything is a whole other issue. How about this? 1, 16, 32464, 2342, 6547. What does that string of numbers mean? Without knowing precisely what the applications send back and forth and how it's formatted by the applications, you have no hope of ever understanding what the numbers mean, nor how to respond in a manner that's going to be understood. Also, if the data object thats being transferred is bigger than one packet, how will you know??
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009... -
Not immediately recognizing some hex output doesn't necessarily make it complex. if you want something complex, have a look at PEF, the file format used by Windows executables. :)
Luc Pattyn
Local announcement (Antwerp region): Lange Wapper? Neen!
Oddly enough, I'm doing that right now! I can almost read a PE file by hand and know exactly what I'm looking at. I writing a utility that has a requirement of checking the exports of a specified .DLL's to see if function names entered by the suer are valid. How little did I know the hell I'd have to go through just to get those names!
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...