标签: error-detection

我再一次进行了设计评审,并且遇到了一个声称特定情景的概率"低于宇宙射线的风险"影响该程序的说法,并且我发现我没有最微弱的想法是什么概率是.

"因为2 ^-128是340282366920938463463374607431768211456中的1个,我认为我们在这里抓住机会是合理的,即使这些计算已经减少了几十亿......我们对宇宙射线的风险更大我相信,把我们搞砸了."

这个程序员是否正确？宇宙射线撞击计算机并影响程序执行的概率是多少？

我有一个旧的,不再制造的带有串口的电子设备.我正在尝试对此设备中使用的数据包CRC /校验和/散列进行逆向工程.

任何有敏锐眼光,有敏锐数学技能的人都可以破解这个东西？

这是我到目前为止所知道的......

• 每个数据包总是21个字节.对于CRC /校验和/散列,19个字节的数据加上2个字节
• 因此,这里没有长度或头部字节.哈希计算中涉及所有19个字节.
• 我有能力使用该设备生成一定数量的数据包
• 我的第一个想法是数据包具有某种CRC-16计算
• 所以我跟着在www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html中反转提示.

• 验证我的数据包样本观察到上述网络链接中概述的"叠加原则".这表明它们具有数学XOR关系.

• 开始感觉很好......但之后又难过了.无法确定CRC-16多项式.这些数据包哈希很可能不与CRC相关,而是一些家庭酿造方案.

• 通过Ross N. Williams阅读"CRC错误检测算法的无痛指南"

• 请参阅http://www.ross.net/crc/download/crc_v3.txt
• 也用于应用:CRC Reveng - 逆向工程应用
• 请参阅reveng.sourceforge.net
• 仍然没有运气......

• 不幸的是,我无法访问任何设备源/二进制代码

• 还运行测试以查看是否使用了其他哈希,例如Fletcher的校验和

以下是我的数据包的各种样本.

0x47366B2EE00000000000751CEB5F3469543B585E2D
0x47366B2ED00000000000751CEB5F3469543B582A2C
0x47366B2EC80000000000751CEB5F3469543B580B2B
0x47366B2EC40000000000751CEB5F3469543B58BB2A
0x47366B2EC20040000000751CEB5F3469543B58DFE7
0x47366B2EC10000000000751CEB5F3469543B58A328
0x47366B2EC08000000000751CEB5F3469543B584127
0x47366B2EC04000000000751CEB5F3469543B588126
0x47366B2EC02000000000751CEB5F3469543B580525
0x47366B2EC01000000000751CEB5F3469543B580124

请注意以下有关这些数据包的信息......

• CRC在数据包的最后2个字节上找到.
• 如果我查看逻辑分析仪上的位,我已将字节表示为MSB优先
• 因此,数据包0x47366B2EE00000000000751CEB5F3469543B585E2D在二进制中看作:
• 01000111 ................................................. ............ 00101101

• (0X47)............................................... ......................(0x2D)

• 我不知道我的系统是大端还是小端,但是确定的字节是LSB优先的

• 注意,对于上述10个数据包样本,每个包通过1位移位到10位位置而不同.除了第5个数据包,我不得不改变2位

• 请参阅数据包的0x47366B2E部分之后的数据字节.

• 只有模式我看到出现的是每个数据包上的最后一个字节递减一(2D,2C,...).(除了第5个数据包,我必须更改2位)

• 最后一个字节不是某种序列号,因为我可以在任何时候以相同的值生成它们.
• 但它可能暗示了所使用的数学哈希.

任何帮助表示赞赏!

大多数可用的桌面(廉价)x86平台现在仍然没有ECC内存支持(错误检查和纠正).但内存位翻转错误的速度仍在增长(不是最好的SO线程,大规模CERN 2007研究"数据完整性":" 内存模块的误码率为10 ^-12 ...观察到的错误率是4个订单低于预期 "; 2009年Google的"DRAM中的错误:大规模的实地研究").对于当前的硬件与数据密集的负荷(读数8 GB/s)的,这意味着单个位翻转,可能会出现每分钟(10家^-12在两天厂商BER从CERN07)或一次(10 ^-16来自CERN07的BER).Google09表示,每Mbit可以有高达25000-75000的一位FIT(每十亿小时的故障时间),相当于8GB RAM每小时1-5位错误(" 2000的平均可纠正错误率 -每GB每年6000 "".

所以,我想知道,是否可以在系统范围内添加某种软件错误检测(检查用户和内核内存).例如,为Linux内核和/或系统编译器创建一个补丁,为每个内存页面添加一些校验和,并尝试通过定期重新计算校验和来检测静默内存损坏(bit-flips)？

例如,我们可以看到对内存的所有写入(来自用户和内核空间),以区分内存位翻转中的预期内存更改吗？或者我们能以某种方式用一些帮助来检测所有代码吗？

我知道任何类型的软件内存ECC可能会花费很多性能并且不会捕获所有错误,但我认为在它们将在以后的计算中重用或存储之前,至少检测一些内存位翻转是有用的.到硬盘.

我也明白,更好的数据保护方式是从内存bitflip切换到ECC硬件,但大多数PC仍然是非ECC.

我正在研究通过Javascript自动进行页面错误检测的可能性.我找到了几个问题,答案允许您通过全局捕获Javascript编译和运行时错误window.onerror,但没有答案提到浏览器错误控制台中经常报告的其他类型的非Javascript错误.我主要对网络错误(无效的URI,SSL错误,HTTP错误,超时)和资源解释错误(不匹配的类型导致中止资源的解释,解析加载的资源上的错误等)感兴趣.

我检查了这个performance.getEntries方法,但是我很困惑地发现它似乎没有包含导致错误的网络请求(我只在Chrome 29中检查过......)

我不需要完全跨浏览器兼容性..只要它适用于某些浏览器,并且不会破坏其他浏览器,那很好.

我想知道有什么好方法可以对同步进行断言或者某些事情以便我可以检测同步违规(在测试时).

例如,我将使用一个不是线程安全且不会是线程安全的类的情况.通过某种方式,如果从多个线程调用某些方法,我会有一些断言可以通知我(日志或其他东西).

我渴望能够为AWT调度线程做类似的事情,具体如下:

public static void checkDispatchThread() {
    if(!SwingUtilities.isEventDispatchThread()) {
        throw new RuntimeException("GUI change made outside AWT dispatch thread");
    }
}

我只想要更通用的东西.问题描述不是很清楚,但我希望有人有一些好方法=)

前几天我遇到了问题GZipStream没有检测到损坏的数据(甚至CRC32通过)？(其中很可能是一个"重复",我对这个主题有不同的感受.我也是那个将CRC32添加到标题中的人,但回想起来,与帖子的其余部分感觉不合适).在我自己探讨了这个问题后,我认为这个问题比最初描述的其他问题要大得多.

我扩展了另一个问题,并使测试代码在LINQPad下可运行,并试图更好地展示CRC32(循环冗余校验)问题,如果确实存在的话.(由于代码只是基于原始版本的轻微修改,因此测试设置/方法可能存在缺陷,或者存在另一个奇怪的怪癖/ PEBCAK.)

The results are odd because the corrupt data is not always causing an (any!) Exception to be raised. Note that only sometimes does the CRC32 check seem to actually be "working". The corrupt bytes that cause the index-out-of-range/bad header/bad footer can be ignored because we can assume these are killing the decompression prior to the CRC32 check (which is perfectly understandable, even if the IndexOutOfRangeException should likely be …

抛开性能和安全性考虑,并假设具有完美雪崩效应的散列函数,我应该将其用于校验和数据块:CRC32或散列截断为N个字节？即错过错误的可能性较小？特别:

1. CRC32与4字节哈希
2. CRC32与8字节哈希
3. CRC64与8字节散列

数据块将通过网络传输并重复存储在磁盘上.块大小可以是1KB到1GB.

据我了解,CRC32可以检测高达32位的翻转,具有100%的可靠性,但在此之后,其可靠性接近1-2^(-32)并且对于某些模式来说更糟糕.总是有一个完美的4字节散列可靠性1-2^(-32),所以请看一下.

8字节散列应该具有更好的整体可靠性(2^(-64)错过错误的机会),所以它应该优先于CRC32吗？CRC64怎么样？

我想答案取决于在这种操作中可能出现的错误类型.我们是否可能会看到稀疏的1位翻转或大量的块损坏？另外,鉴于大多数存储和网络硬件都实现了某种CRC,不应该意外地进行位翻转吗？

我有一个PHP脚本,可以发送需要到达目的地的重要电子邮件.我知道如何检查电子邮件是否成功发送,唯一的问题是知道它是否真的送到了收件人.

有什么建议？如果没有办法知道,你会如何处理这种情况？

从编码的4B/5B编码方案数据0000到11110码字,类似地,0001被编码为01001等.

这里,两个码字之间的XOR运算结果将是另一个有效的码字.

例如,11110和01001的XOR是另一个码字10111,其数据字是1011.这里我没有问题.

同样,为了避免直流分量,使用NRZ-I线路编码方案.结果,输出码字中没有三个连续的零.代码字中没有一个标题和两个尾随零.我们不担心NRZ-I编码方案中的一个数量.

但是,如何编码0000到11110或0001到01001以及我应该为这种编码方案应用哪种算法.

我也搜索谷歌和学习书籍.但到处都是他们只讲同一件事,但我没有得到答案.

提前致谢

一个问题问:找到以下代码的汉明距离:

11111  
10101  
01010  
11100  
00011  
11001

答案是2.这是如何工作的？我觉得汉明距离只在两根琴弦之间？