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