• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 281
  • Last Modified:

Reverse Engineering UDP Packet CRC check maybe?

Hello, I'm trying to make an ad-on program for a small chat server that I'm running.  From looking at packets, and trying to rebuild them I run into one major problem, if I use an identical packet that would be sent by the 'real' client it get's through ok.  However if I modify that packet even by one byte it's dropped and the server request's a new packet.  

I believe there is a CRC check of some type and I believe the CRC check values are stored in the 2nd and 3rd byte of the packet. Examples of three valid packets sent by the client are shown below.

4D 90 2F 00 00 00 30 10 00 00 00 00       M./...0.....
4D 90 2F 00 00 00 30 10 00 00 00 00       M./...0.....
4D 43 8A 00 00 00 31 10 00 00 00 00       MC....1.....

Now let’s say i wanted to send my own custom packet and change only the 7th byte to 35 (hex).  Can anybody help me determine what the 2nd and 3rd byte should be, and the process of finding it?

And what if i wanted to change multiple bytes will that process still work for finding it?

Thanks in advanced

  • 5
  • 4
1 Solution

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.
MMKDAuthor Commented:
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


Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

MMKDAuthor Commented:
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.

MMKDAuthor Commented:
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?

It is virtually impossible to figure out what algo rithm being used by looking at the data and CRC value.
There are several CRC algorithms available and without knowing which one being used, it is hard to guess.
However, since you know the data in side the buffer and the CRC and if you got time, try out some common CRC algorithms
on the data and see if it gives the same CRC value every time. This way you can "at some point" figure out what algo they are using.

If you are lucky, they may be using some common algos.
like this

Take a look at

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

Thanks Again


good luck buddy

Featured Post

Efficient way to get backups off site to Azure

This user guide provides instructions on how to deploy and configure both a StoneFly Scale Out NAS Enterprise Cloud Drive virtual machine and Veeam Cloud Connect in the Microsoft Azure Cloud.

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now