The struct again:
struct HostInfo
{
____enum_{ONLINE=0x0001,_OFFLINE=0x0002};
____char_m_Host[HOSTMAX];
____unsigned_int_m_iState;
};

Just out of curiosity: what steps would need to be taken to be able to alter
exactly the m_istate member in the above struct on a stream socket while in
transmission over the net?

[ Post a follow-up to this message ]

In article <HUAEg.4731$gf2.3062@reader1.news.jippii.net>,
ibaloubi <bobofibodibo@aaakyars.com> wrote:

> The struct again:
> struct HostInfo
> {
> ____enum_{ONLINE=0x0001,_OFFLINE=0x0002};
> ____char_m_Host[HOSTMAX];
> ____unsigned_int_m_iState;
> };
>
> Just out of curiosity: what steps would need to be taken to be able to alt
er
> exactly the m_istate member in the above struct on a stream socket while i
n
> transmission over the net?

It's not clear what you're asking.  Are you wondering how a hacker might
mess with your data before it gets received?  Or what you can put in a
router to make it modify the data?  What are you trying to do?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[ Post a follow-up to this message ]

Barry Margolin wrote:

> In article <HUAEg.4731$gf2.3062@reader1.news.jippii.net>,
>  ibaloubi <bobofibodibo@aaakyars.com> wrote:
> 
>
> It's not clear what you're asking.  Are you wondering how a hacker might
> mess with your data before it gets received?  Or what you can put in a
> router to make it modify the data?  What are you trying to do?
>
not trying to do anything but understand why my network behaves like it
does.using the client-server app over my lan worked fine, until the read
part in the client started throwing "connection reset by peer"
errorrs( which the server on lan never does until the whole struct has been
transmitted(it is a simple server)).

Using the application from my linux workstation to my dedicated server
( server on the dedicated part) then the information is tampered with. I
get a zero in m_iState, despite the digit should ( which I am absolutely
sure of) be a 1 or 2 depending on the state. The code used on the lan is
the same as from over the internet from my workstation to the dedicated
server.

so:the data is changed in transmission, and I want to know how this is
possible, and most importantly what can be done about it. I know of
encryption, but haven't used any encryption lib in programming.

I also know of byte ordering( little and big endian) but both machines in
this case, or actually all three, are little endian. So, regardless of what
ntohx, htonx functions are used or not, the result should be the same.

I have tried using the ntoxx htoxx functions as well as not using them, the
result is the same, always a zero.

any advice, information, much appreciated.

G

[ Post a follow-up to this message ]

ibaloubi wrote:
> The struct again:
> struct HostInfo
> {
>     enum {ONLINE=0x0001, OFFLINE=0x0002};
>     char m_Host[HOSTMAX];
>     unsigned int m_iState;
> };
>
> Just out of curiosity: what steps would need to be taken to be able to alt
er
> exactly the m_istate member in the above struct on a stream socket while i
n
> transmission over the net?

Please just fix your code. You *must* define the protocol at the byte
level because TCP is a stream of bytes. We can continue to find and
detail all the ways that your failure to do this is breaking your code,
but that would be a waste of your time and ours.

Here's a few more issues for you to think about :

1) How many bytes long is an 'enum'?

2) Is HOSTMAX exactly the same on all machines?

3) What are the alignment requirements for an unsigned integer -- did
all machines assume the same number of padding bytes between the m_Host
and the m_iState variable?

My best advice to you from many years of experience is this -- you just
learned a cheap lesson. TCP is a byte-stream protocol. It sends bytes.
When you use it, you must specify what bytes are to be exchanged, then
you can make sure the sender sends the right bytes and the receiver
expects the right bytes.

You can 'cheat' if you want -- define the protocol in terms of the
bytes that the sender just happens to be sending now. Just make *sure*
you get it bang on. If the sender is sending 4 bytes for the enum,
write that down. If it is using a HOSTMAX of 12, write that down. If
it's using 2 bytes of padding, what that down. If the integer is
little-endian and 4 bytes long, write that down. You now have a
*specification*.

You can now check all your code against that specification, and if it
doesn't work, you know who to blame. If all the code follows the
specification and it still doesn't work, the bug is in the
specification. ;)

DS

[ Post a follow-up to this message ]