常見保護的攻擊:序列號方式
序列號保護機制
數(shù)學算法一項都是密碼加密的核心，但在一般的軟件加密中，他似乎并不太為人們關心，因為大多數(shù)時候軟件加密本身實現(xiàn)的都是一種編程的技巧。但近幾年來隨著序列號加密程式的普及，數(shù)學算法在軟件加密中的比重似乎是越來越大了。
我們先來看看在網絡上大行其道的序列號加密的工作原理。當用戶從網絡上下載某個shareware——共享軟件后，一般都有使用時間上的限制，當過了共享軟件的試用期后，你必須到這個軟件的公司去注冊后方能繼續(xù)使用。
注冊過程一般是用戶把自己的私人信息（一般主要指名字）連同信用卡號碼告訴給軟件公司，軟件公司會根據用戶的信息計算出一個序列碼，在用戶得到這個序列碼后，按照注冊需要的步驟在軟件中輸入注冊信息和注冊碼，其注冊信息的合法性由軟件驗證通過后，軟件就會取消掉本身的各種限制，這種加密實現(xiàn)起來比較簡單，不必額外的成本，用戶購買也非常方便，在互連網上的軟件80%都是以這種方式來保護的。
我們注意到軟件驗證序列號的合法性過程，其實就是驗證用戶名和序列號之間的換算關系是否正確的過程。其驗證最基本的有兩種，一種是按用戶輸入的姓名來生成注冊碼，再同用戶輸入的注冊碼比較，公式表示如下：
序列號 = F（用戶名）
但這種方法等于在用戶軟件中再現(xiàn)了軟件公司生成注冊碼的過程，實際上是非常不安全的，不論其換算過程多么復雜，解密者只需把你的換算過程從程式中提取出來就能編制一個通用的注冊程式。
另外一種是通過注冊碼來驗證用戶名的正確性，公式表示如下：
用戶名稱 = F逆（序列號） （如ACDSEE,小樓注）
這其實是軟件公司注冊碼計算過程的反算法，如果正向算法和反向算法不是對稱算法的話，對于解密者來說，的確有些困難，但這種算法相當不好設計。
于是有人考慮到一下的算法：
F1（用戶名稱） = F2（序列號）
F1、F2是兩種完全不同的的算法，但用戶名通過F1算法的計算出的特征字等于序列號通過F2算法計算出的特征字，這種算法在設計上比較簡單，保密性相對以上兩種算法也要好的多。如果能夠把F1、F2算法設計成不可逆算法的話，保密性相當?shù)暮?；可一旦解密者找到其中之一的反算法的話，這種算法就不安全了。一元算法的設計看來再怎么努力也非常難有太大的突破，那么二元呢？
特定值 = F（用戶名，序列號）
這個算法看上去相當不錯，用戶名稱和序列號之間的關系不再那么清晰了，但同時也失去了用戶名于序列號的一一對應關系，軟件研發(fā)者必須自己維護用戶名稱和序列號之間的唯一性，但這似乎不是難以辦到的事，建個數(shù)據庫就好了。當然你也能根據這一思路把用戶名稱和序列號分為幾個部分來構造多元的算法。
特定值 = F（用戶名1，用戶名2，...序列號1，序列號2...）
現(xiàn)有的序列號加密算法大多是軟件研發(fā)者自行設計的，大部分相當簡單。而且有些算法作者雖然下了非常大的功夫，效果卻往往得不到他所希望的結果。其實目前有非常多現(xiàn)成的加密算法能用，如RSADES,MD4,MD5,只不過這些算法是為了加密密文或密碼用的，于序列號加密多少有些不同。我在這里試舉一例，希望有拋磚引玉的作用： 中國網管聯(lián)盟
1、在軟件程式中有一段加密過的密文S
2、密鑰 = F（用戶名、序列號） 用上面的二元算法得到密鑰
3、明文D = F-DES（密文S、密鑰） 用得到的密鑰來解密密文得到明文D
4、CRC = F-CRC（明文D） 對得到的明文應用各種CRC統(tǒng)計
5、檢查CRC是否正確。最佳多設計幾種CRC算法，檢查多個CRC結果是否都正確
用這種方法，在沒有一個已知正確的序列號情況下是永遠推算不出正確的序列號的。
序列號方式的保護方式就為大家介紹完了，希望大家已經掌握。如果想了解更多的相關內容，請大家閱讀：常見保護的攻擊:序列號方式 續(xù)
【編輯推薦】
