※ 引述《voiceh (cold)》之铭言： : 这是5年前的一个家教学生 ( 男 / 16岁 ) : 发明的一个压缩程式 : 1日到7日 我们可以现场确认压缩各式档案 ( 文字. 图档. 影片 ) : 合作最後的CHECK及开发.以及跟他本人共同讨论. 小弟不才，比不上板上许多先进 不过由於从朋友那也拿到了一份这传说中的压缩档 来补充一些资讯 首先，拿到压缩档时，只有档案并没有解压缩程式 这可真是傻眼了，不能解要怎麽验证？ 不过仔细一看，档名 imagefileformacpartition[1].img.bz2 哇，真是太棒了，世界上刚好有个同名的格式也叫 bzip2, 可能是叫我用 bzip2 解开来，然後到到 Mac 上把它 mount 起来 (这里假设 img 是 dmg 打错字), 就可以找到真正的 压缩档跟解压缩程式，或是 img 其实是 iso image, 或某软体产生的那个叫 .img 的 iso image... 总之，第一步用 bzip2 先解下去再说 这一解，马上就停住了... 咦，解开来的是一个 6G 大的档案，而且前面都是 0.... 那麽来 hexdump 一下吧 000000000 0000 0000 0000 0000 0000 0000 0000 0000 * 17fff9ff0 0000 0000 0000 0000 0000 0000 0000 8000 完美的 6G 啊，而且还不是全部 0 喔，有一个 80! (hexdump 感谢有耐心的 rafan 长辈，我解到 3G 硬碟就满了 所以也不想解了) 可是这麽一来留下很多疑点，我们也不要一下就说人家骗人， 来帮他做些假设吧： 假设A. bzip2 只是巧合，其实那个压缩档用的演算法与一般的 bzip2 完全不同，解出来只是巧合中的巧合，实际真实资料完全不同 成立可能性: 机率非常的低... 随便把一个档丢给 bzip2 看看就知 假设B. 他写了修改版的 bzip2。那麽为什麽结果一模一样呢？ 可能是他写的 code 其实没发挥作用但没发现，或是 PATH 不对 那麽，在确认解压缩的正确性时为何没注意到？ 可能是他读入 disk raw data (以档名推测) 时的方法用错了， 写入 disk 的也错了，所以他读入全是 0, 在同一 partition 上读入又写出，因为读写全错所以自然以为 partition 是一样的 成立可能性: 算合理 (吧) 这样说来，大概他改写的 bzip 有些地方弄错了，所以什麽档案进来都是 0, 自然压缩率很高； 输出可能也写坏了根本不会输出。 当然，我很希望这件事纯粹是弄错了， 不然刻意冒充 bzip2 作者的行为是不太好的哟 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.112.30.72