※ 引述《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