我有一个199mumble的Brother集成文字处理器，具有非常奇怪的非PC软盘格式。我已经构建了一个软盘控制器，并已成功地从磁盘读取磁通量，对两种GCR都进行了解码，然后将结果重新组装为磁盘映像。但是我需要能够检查部门中的校验和，以了解我是否做对了。 （眼球看起来不错。）
每个扇区为256字节，后跟三个字节，具体取决于扇区的内容-相同的扇区产生相同的值，所以我假设它是校验和。有趣的是，全零扇区产生的全零校验和，因此我怀疑它不是常规的CRC。
我有100个不同的示例，但其中可能会有一些不正确的结果（由于误读扇区）;完整列表位于https://pastebin.com/0HZrUVPR，但这是一些选定的示例，希望采用reveng格式，因此校验和位于最后三个字节中：
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005750314120464c4f505059080000000000000000000000000000000000000000616161616161616120202020000000000000000000000000000002000a5d000064656d6f20202020a4ca1a
414141414141414141410000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008b38af
414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141de6162636465666768696a6b6c6d6e6f707172737475767778797a303132333435363738394141414141414141414141414141414141414141414141414141414141de4141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141de4141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141415a6ea1
41414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141de4141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141de6162636465666768696a6b6c6d6e6f707172737475767778797a303132333435363738394141414141414141414141414141414141414141414141414141414141de41414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141413362ac
请注意，最后两个包含相同的数据，并向右旋转整数个字节。
所以我很困惑。有一些24位CRC，但它们似乎很少见。 reveng没有任何内容，但我不能完全确定我是否正确地驱动它-它的执行速度似乎要比进行强力搜索的速度快。我尝试了一些琐碎的求和方法，但是简单的求和方法却不起作用，并且有太多变化只能猜测。
我将如何解决这个问题？ >
#1 楼
答案很简单，只要您了解CRC是什么。它类似于CRC校验码-将输入除以具有舍去表示形式的多项式
0x000201的余数。/>
我编写了一个快速的Python脚本来验证校验和：
def crc(data, poly):
# width = 24 bit
# data len = 2048 bit
assert poly<(1<<24)
for i in range(2048-1,24-1,-1):
if data>>i&1:
data^=1<<i
data^=poly<<(i-24)
assert i==24
assert data<(1<<24)
return data
import sys
for line in sys.stdin.read().splitlines():
line = int(line,16)
print(crc(line>>24,0x000201) == line&~(-1<<24))
在线试用！
<可能使用
crc函数生成缺少的校验和值。如何？
首先，我假设校验和函数满足以下属性：对于所有
x和y ，我们有checksum(x) xor checksum(y) == checksum(x xor y)。对提供的数据使用高斯消除，我可以推断出
000000...000000bb0301的哈希为bb0301。看起来很合理。然后，我了解了现有的哈希函数，并了解了它们使用的方法。我注意到CRC使用的是多项式余数mod 2，因此我想哈希是作为多项式以阶数为25的多项式的模的输入（因为输出具有24位）。
用简单的蛮力，我得出的结论是多项式是
000201。测试表明它是正确的。为什么要强制搜索。为什么reveng执行得这么快？
这是因为只能有2个宽度的多项式。 reveng只需要很少的时间即可尝试每个多项式。在这种情况下，width = 24，因此只有1048576个多项式，对于计算机而言不是很大。
为什么reveng不返回输出？它和CRC有什么区别？
CRC在计算多项式余数之前将
width（在这种情况下为-24）位附加到输入中，该算法没有。评论
哇---非常感谢！我原本希望一旦回到机器上就可以自己捡起它并生成源数据。是的，这很好用（我有一个C实现，结果匹配）。我有点惊讶Reveng没有发现这一点。这似乎是标准算法的相当标准的变化。
–David Given
18-10-25在4:05
另外，您想在我的代码中获得荣誉吗？如果是，如何？
–David Given
18-10-25在4:05
Reveng是否总是/完全使用蛮力找到CRC多项式？对于CRC32，大约需要10分钟。想象一下，CRC64需要多长时间。是否有没有方法可以以非暴力的方式减少计算量？
–Silicomancer
19年4月26日在22:06
@Silicomancer我想是的。 /我认为cosc.canterbury.ac.nz/greg.ewing/essays / ...可能有一种方法。
–user202729
19-4-27的3:18
@ user202729：似乎作者使用一种非常特殊的方法来计算多项式。我认为在大多数情况下，这是行不通的，因为它需要对有效负载数据进行非常具体的修改（即，以单个步行位重复更改数据）。您是否知道是否存在使用随机有效载荷/校验和对来重构多项式的非蛮力方法？
–Silicomancer
19年4月27日在8:58
评论
请稍等，我不了解背景。软盘上是什么-文字处理器或可由文字处理器编辑的文档？应该读什么软盘？此外，什么是GCR？这个吗？嗯，对，背景。这可以追溯到文字处理程序不是程序的时代，它是具有屏幕和软驱的电动打字机。图片很难找到，但是gizmodo.com/…是比我的模型稍晚的模型。用于保存文件的软盘格式不是PC，而是256字节扇区，是GCR而不是MFM（您的链接是正确的），不同的低级磁盘格式等。 PC软盘驱动器。但是这些东西都搞清楚了。
尝试产生一些汉明距离较低的扇区（不同位数）？这样，就可以确定单个位如何影响校验和，以防万一校验和算法是线性的（或足够接近线性）。
我会尝试一下，但是现在机器距离酒店9000公里，因此必须等到下周。如果我能从我的磁盘映像中找出来，那就太棒了。