确定Windows CE可执行文件使用的16位CRC /校验和算法的方法？ [英] Methods to nail down 16 bit CRC/Checksum algorithm used by Windows CE executable?

问题描述

我需要对Windows CE可执行文件实现的CRC /校验和算法进行逆向工程。作为专有协议，它没有对CRC /校验和算法进行任何说明。但是，有一个控制台界面报告正确/计算的校验和，如果消息协议正确，我可以使用随机位构造自己的消息：

I need to reverse engineer CRC/Checksum algorithm implemented by windows CE executable. Being propritory protocol, it does not say anything about CRC/checksum algorithm. However, There is console interface that reports correct/calculated checksum and I can construct my own messages with random bits if message protocol is correct:

我已经观察到了，

• 更改消息中的单个位会完全更改校验和字节。

• Changing single bit in message changes checksum bytes completely.

算法似乎与位置有关，因为我在各种消息数据位置中馈入了一些单个1位消息，其余位为零，并且所有时间控制台都报告为不同校验和。如果是简单的加法校验和，则校验和将是相同的。

Algorithm seems to be position dependent as I fed some single 1 bit messages in various message data positions with rest of the bits zero and all the time console reported different checksum. If it was simple additive checksum, checksum would have been identical.

我应用了通用的XOR，LRC，加法校验和算法，常见的CRC多项式（Standerd，CCITT，X-modem），并经历了[CRC逆向工程论文] [2]，但是不幸的是，我无法推导出多项式，因为消息类型是固定的，因此无法创建单个1位消息。

I applied common XOR, LRC, Additive checksum algorithms, common CRC polynomials(Standerd, CCITT, X-modem) and gone through [CRC Reverse engineering essay][2] but unfortunately I cannot go past deducing the polynomial because message type is fixed so cannot create single 1 bit message.

我的问题：

1. 是否有任何CRC /校验和算法我可以针对消息进行测试以确定算法是校验和还是基于多项式的CRC的属性？

1. Are there any CRC/checksum algorithm properties that I can test against messages to determine if algorithm is checksum or polynomial based CRC?

有什么方法可以将程序反汇编中出现的错误消息与对应关系相关联组装说明？

Is there any way to relate error message seen in program disassembly with corrosponding assembly instructions?

在控制台上报告正确的校验和后，有哪些方法可以调试/定位反汇编代码？内存转储还是什么？

What are the ways to debug/pinpoint disassembly code the moment it reports correct checksum on console? Memory dump or something?

推荐答案

尝试 CRC RevEng 。快速尝试使用您的数据是徒劳的，但是我并没有很努力。考虑不仅尝试所有十个消息字节，而且尝试最后八个和最后六个消息。

Try CRC RevEng. Some quick attempts with your data were fruitless, but I didn't try very hard. Consider trying not just all ten message bytes, but also the last eight and the last six.

此外，您可以在同一站点找到我知道的最全面的已知CRC列表。

In addition you can find at that same site the most comprehensive list of known CRCs that I'm aware of.

更新：

很有可能这是某种形式的CRC，或者至少是对GF（2）的线性运算。它具有CRC所具有的此属性：如果两个序列具有相同的异或，则它们的CRC也具有相同的异或。例如，从您的数据中（删除公共前缀，但请注意，包括前缀或前缀的一部分不会更改结果）：

It is highly likely that this is a CRC of some sort, or at least a linear operation over GF(2). It has this property that CRC's have: if two sequences have the same exclusive-or, then their CRC's also have the same exclusive-ors. For example, from your data (dropping the common prefix, though note that including the prefix or a portion of it does not change the result):

00000000000122b5 ^ 0000000000022421 = 0000000000030694
0447080a300130A1 ^ 0447080a30023635 = 0000000000030694

并且

0447080a300130A1 ^ 0447080a30043A36 = 0000000000050a97
00000000000122b5 ^ 0000000000042822 = 0000000000050a97

鉴于此事实，您可以通过一种方法构造一个例程来计算校验值，而无需确定它是CRC还是CRC参数。

Given this fact, there is a way for you to construct a routine to calculate the check value without determining if it's a CRC or what the CRC parameters are.

为所有单个位消息生成16位校验值，即在六个字节的消息数据中设置一个单个位，其余消息数据位为零。这些消息是此线性字段的完整基础向量集。其中有48个。还生成全零消息的检查值。您已经有了一个开始，全零给出 2020 ，最后一位给出 22b5 ，依此类推。或所有其他零的检查值（ 2020 ）。现在，您有49个值，其中48个是基向量，一个是零向量的校正（由于CRC和前缀字节的前后条件，该向量可能不为零）。例如，设置最后一位的基向量的值是 0295 。

Generate the 16-bit check value for all of the single bit messages, i.e. a single bit set in the six bytes of message data, with the rest of the message data bits zero. These messages are a complete set of basis vectors for this linear field. There are 48 of them. Also generate the check values for an all zero message. You already have a start at that with all zeros giving 2020, the last bit set giving 22b5, etc. Exclusive-or the check value for all zeros (2020) with each of the others. You now have 49 values of which 48 are for the basis vectors and one is the correction for the zero vector (which is non-zero likely due to pre and post conditioning of a CRC and the prefix bytes). For example, the value for the basis vector with the last bit set is 0295.

现在您可以使用那些49个值，用于计算任何六字节消息的校验值。将在该消息中设置为1的所有相应位的值异或在一起。异或-校验值为零。结果将是该邮件的检查值。

Now you can use those 49 values to calculate the check value for any six-byte message. Exclusive-or together the values for all of the corresponding bits that are set to one in that message. Exclusive-or that with the check value for zero. The result will be the check value for that message.

这篇关于确定Windows CE可执行文件使用的16位CRC /校验和算法的方法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！