Reverse Engineering UDP Packet CRC check maybe?

What level are you capturing the packets ?
How do you modifying the packets  ?

As you might know TCP/IP packet finalization is done by the stack and -apparently- in the kernel mode.
If you want to modify a packet on the fly, it is very important that you should co-oprate with the TCP/Ip stack.
People usually write filter drivers to do this.

The packets I used for an example would have been captured at the application layer.  As far as writing a filter driver that’s far above my skill level as I only know Visual Basic although there are some Active-X controls out there that allow I haven’t tried any of them.

Actually the packets above are not packets at all, it’s the data contained within the packets.  No packet headers or anything of that type. (Sorry for the confusion)

And the process I was using to capture the data may be a bit sloppy but it works.  The way I capture data is I have a 'Man in the middle' program.  It works similar to a proxy.  I set the client to connect to it, while it connects out to the server, it then relay's data between the two and logs it. (Well no actual connection because UDP but you know what I mean), with the program I can edit the packets, drop or send my own as well.  At the cost of performance but the performance drop is acceptable.

Okay... I think now I get a clear-er picture. :)

If you have a proxy-like setup, you can very well modify the data without caring the CRC or any network packet related parameters.

I guess your setup is like this.

CLIENT                PROXY                 SERVER
=============================
connect  -------------------------------->
recvfrom <------(modify data)<----- data

You must be reading the data in your proxy and sending it to the actual client.
If this is correct, there must be a bug in your code causing the faliure.
You have to fig out the following why the packet could not get to the client.

You should verify
1) if the proxy receives the packets correctly.
2) if the port numbers are correct
3) if the length of incoming data is correct
4) if the modify operation is done correctly
5) if the out going (from proxy to the real client) length/port number/ipaddress etc are correct (this could be the the issue)
6) if the packet reaches the client correctly (network filewall or network proxy issues)


You could
1) Add debug prints to the critical areas to verify the above
2) Use the packet sniffer from MS or http://ethereal.com and capture some packets to verify address/port number etc

~j
   

I tested using a packet sniffer (Iris) and everything looks correct.

What I think is happening is the actual client / server send there own CRC or integrity check (im guessing its a crc check) to verify the data is what it should be.

And I think from looking at the data I posted above you can see what I mean, each line representing the data contained within one packet.

You'll notice the 2nd n 3rd byte stays the same if all following data is identical, however if even one byte changes, those 2nd and 3rd bytes will change also, this also holds true with larger packets.

>> there own CRC or integrity check....
     Oh.. yeah.. that could be possible. and that has nothing to do with UDP or IP.
I was under the impression that you are talking about the CRC of the UDP itself.
If that is the case, the client application *will* receve the data and it will drop it because you have modified it.
That happens in the application level, has nothing to do with UDP.

Looks like what you should do inside the proxy is - modify the data and re-calculate the CRC using the same
algorithm as ths server and update the CRC field as well.

Your data would be some thing like this

struct _data_format
{
    int length_data;
    char data_buffer[]
    int CRC;
}

So if you modify the data_buffer inside  your proxy, calculate the new CRC and update CRC fild and then send it to teh real client.

Yes that's exactly what I ment :).  Now my problem is, I dont have that alogorithm they use for the integrity check, and I'm not skilled enough to dissasemble the client/server to determin it, is there any way to derive it from captured packets easily that you know of?

Ok, thanks for your help with everything.  I'll try some alogorithms and see if I get lucky.

Thanks Again

-Mark

good luck buddy
:)