Reverse Engineering UDP Packet CRC check maybe?

Posted on 2004-09-12
Last Modified: 2013-12-03
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

Question by:MMKD
  • 5
  • 4

Expert Comment

ID: 12056916

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.

Author Comment

ID: 12058255
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.

Expert Comment

ID: 12059129

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 and capture some packets to verify address/port number etc


Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.


Author Comment

ID: 12060265
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.

Expert Comment

ID: 12060311

>> 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.


Author Comment

ID: 12060325
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?

Accepted Solution

mxjijo earned 500 total points
ID: 12060376

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


Author Comment

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

Thanks Again


Expert Comment

ID: 12060410

good luck buddy

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article describes how to programmatically preset the "Pages per Sheet" option that's available with most printer drivers.   This setting lets you do "n-Up" printing, where two, four, or more pages are printed on each sheet of paper. If your …
After several hours of googling I could not gather any information on this topic. There are several ways of controlling the USB port connected to any storage device. The best example of that is by changing the registry value of "HKEY_LOCAL_MACHINE\S…
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA.…
Two types of users will appreciate AOMEI Backupper Pro: 1 - Those with PCIe drives (and haven't found cloning software that works on them). 2 - Those who want a fast clone of their boot drive (no re-boots needed) and it can clone your drive wh…

856 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question