javarc4加密演算法

⑴ SSL/TLS協議原理解讀

HTTPS是什麼相信大家都知道，如果你不知道。。。請關閉此文！！！
HTTP的數據是明文傳輸的，沒有安全性可言。HTTPS是秘文傳輸，那麼HTTPS是怎麼實現數據的安全(加密)傳輸的？那是因為HTTPS比HTTP多了個'S'。 即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。

SSL/TLS協議是網路安全通信的重要基石，本文將簡單介紹SSL/TLS協議，主要關注SSL/TLS協議的安全性，特別是SSL規范的正確實現。 本系列的文章大體分為幾個部分：

1、SSL/TLS簡介
2、SSL/TLS協議的基本流程
3、從SSL到TLS
4、SSL/TLS的流行實現庫

SSL全稱是Secure Sockets Layer，安全套接字層，它是由網景公司(Netscape)設計的主要用於Web的安全傳輸協議，目的是為網路通信提供機密性、認證性及數據完整性保障。如今，SSL已經成為互聯網保密通信的工業標准。

SSL最初的幾個版本(SSL 1.0、SSL2.0、SSL 3.0)由網景公司設計和維護，從3.1版本開始，SSL協議由網際網路工程任務小組(IETF)正式接管，並更名為TLS(Transport Layer Security)，發展至今已有TLS 1.0、TLS1.1、TLS1.2這幾個版本。

如TLS名字所說，SSL/TLS協議僅保障傳輸層安全。同時，由於協議自身特性(數字證書機制)，SSL/TLS不能被用於保護多跳(multi-hop)端到端通信，而只能保護點到點通信。

SSL/TLS協議能夠提供的安全目標主要包括如下幾個：

認證性——藉助數字證書認證伺服器端和客戶端身份，防止身份偽造

機密性——藉助加密防止第三方竊聽

完整性——藉助消息認證碼(MAC)保障數據完整性，防止消息篡改

重放保護——通過使用隱式序列號防止重放攻擊

為了實現這些安全目標，SSL/TLS協議被設計為一個兩階段協議，分為握手階段和應用階段：

握手階段也稱協商階段，在這一階段，客戶端和伺服器端會認證對方身份(依賴於PKI體系，利用數字證書進行身份認證)，並協商通信中使用的安全參數、密碼套件以及MasterSecret。後續通信使用的所有密鑰都是通過MasterSecret生成。

在握手階段完成後，進入應用階段。在應用階段通信雙方使用握手階段協商好的密鑰進行安全通信。

Handshake協議：包括協商安全參數和密碼套件、伺服器身份認證(客戶端身份認證可選)、密鑰交換;

ChangeCipherSpec 協議：一條消息表明握手協議已經完成;

Alert 協議：對握手協議中一些異常的錯誤提醒，分為fatal和warning兩個級別，fatal類型的錯誤會直接中斷SSL鏈接，而warning級別的錯誤SSL鏈接仍可繼續，只是會給出錯誤警告;

Record 協議：包括對消息的分段、壓縮、消息認證和完整性保護、加密等。

圖2、圖3都是表示的協議流程，大同小異。可以對比著看加深理解。

每一個SSL/TLS鏈接都是從握手開始的，握手過程包含一個消息序列，用以協商安全參數、密碼套件，進行身份認證以及密鑰交換。握手過程中的消息必須嚴格按照預先定義的順序發生，否則就會帶來潛在的安全威脅。今年頂級安全會議CCS 有文章提出了建立綜合狀態機來檢查SSL鏈接中消息序列……

2.1 握手過程中的消息序列

ClientHello：ClientHello通常是握手過程中的第一條消息，用於告知伺服器客戶端所支持的密碼套件種類、最高SSL/TLS協議版本以及壓縮演算法。

ClientHello中還包含一個隨機數，這個隨機數由4個位元組的當前GMT UNIX時間以及28個隨機選擇的位元組組成，共32位元組。該隨機數會在密鑰生成過程中被使用。

另外，ClientHello中還可能包含客戶端支持的TLS擴展。(TLS擴展可以被用來豐富TLS協議的功能或者增強協議的安全性)

ServerHello：伺服器接受到ClientHello後，會返回ServerHello。伺服器從客戶端在ClientHello中提供的密碼套件、SSL/TLS版本、壓縮演算法列表裡選擇它所支持的項，並把它的選擇包含在ServerHello中告知客戶端。接下來SSL協議的建立就基於伺服器選擇的密碼套件類型、SSL/TLS協議版本以及壓縮演算法。

ServerHello中同樣會包含一個隨機數，同樣4+28 位元組類型，由伺服器生成。

Certificate：客戶端和伺服器都可以發送證書消息來證明自己的身份，但是通常客戶端證書不被使用。 伺服器一般在ServerHello後會接一條Certificate消息，Certificate消息中會包含一條證書鏈，從伺服器證書開始，到Certificate authority(CA)或者最新的自簽名證書結束。下圖形象地描述了證書鏈：

SSL中使用的證書通常是X.509類型證書，X.509證書的內容如下表所示：

在用的X.509證書包含Version 1和Version 3兩種版本，其中v1版本的證書存在安全隱患，同時不支持TLS擴展，被逐漸棄用。現在大多數在用的SSL證書都是V3版本。

同時證書會附帶與協商好的密鑰交換演算法對應的密鑰。密鑰交換演算法以及它們所要求的密鑰類型如下表所示。

ServerKeyExchange：該消息僅當以下密鑰交換演算法被使用時由伺服器發出：

RSA_EXPORT(僅當伺服器的公鑰大於512bit時)、DHE_DSS、DHE_DSS_EXPORT、DHE_RSA、DHE_RSA_EXPORT、DH_anon 使用其它密鑰交換演算法時，伺服器不能發送此消息。

ServerkeyExchange消息會攜帶這些密鑰交換演算法所需要的額外參數，以在後續步驟中協商PreMasterSecret。這些參數需要被簽過名。

CertificateRequest：這個消息通常在要求認證客戶端身份時才會有。消息中包含了證書類型以及可接受的CA列表。

ServerHelloDone：伺服器發送這條消息表明伺服器部分的密鑰交換信息已經發送完了，等待客戶端的消息以繼續接下來的步驟。這條消息只用作提醒，不包含數據域。

ClientKeyExchange：這條消息包含的數據與所選用的密鑰交換演算法有關。

如果選擇的密鑰交換演算法是RSA，那麼消息包含的參數為用伺服器RSA公鑰(包含在之前證書中的或者是ServerKeyExchange中的)加密過的PreMasterSecret，它有48個位元組，前2個位元組表示客戶端支持的最高協議版本，後46個位元組是隨機選擇的。

如果選擇的密鑰交換演算法是DH或者DHE，則可能有兩種情況：

隱式DH公開值：包含在Certificate消息里;

顯示DH公開值：公開值是本消息的一部分。

CertificateVerify：這條消息用來證明客戶端擁有之前提交的客戶端證書的私鑰。

Finished：表明握手階段結束。這是第一條用協商的演算法和密鑰保護的消息。

因為是用協商好的密鑰加密的消息，它可以用來確認已經協商好的密鑰。

同時Finished消息包含一個verify_data域，可以用來校驗之前發送和接收的信息。

Verify_data域是一個PRF函數的輸出(pseudo-random function)。這個偽隨機函數的輸入為：(1)兩個hash值：一個SHA-1，一個MD5，對之前握手過程中交換的所有消息做哈希;(2)the MasterSecret，由預備主密鑰生成;(3)finished_label，如果客戶端發送的則是」client finished」，伺服器發送的則是」server finished」。關於這個PRF的細節在3.3節中會具體描述。 此外，Finished 消息不能夠在ChangeCipherSpec前發送。

2.2 不同密鑰交換演算法對應的握手過程

不同的密鑰交換演算法對應的握手過程中的消息序列是不同的，相應的實現方式也不同，本節介紹幾個常見密鑰交換演算法對應的握手過程。

TLS-RSA：在這個場景下，PreMasterSecret是由客戶端指定的，並用RSA公鑰加密發送給伺服器。伺服器不影響PReMasterSecret的生成。

TLS-DH：基於DH的密鑰交換也被稱為靜態Diffie-Hellman。在這種場景下，可能是雙方各自提交一個證書包含DH公開值，或者伺服器端提交證書包含DH公開值，客戶端在每次會話中選擇一個值。協商好的DH值被用作PreMasterSecret。顯然證書中的參數是固定的，那麼每次鏈接的PreMasterSecret也是相同的。

TLS-DH不能提供前向安全性。

TLS-DHE：基於DHE的TLS握手中會有ServerKeyExchange消息。握手過程中交換參數的認證通過數字簽名來實現，支持的簽名演算法包括RSA和DSS。DH參數會有它的數字簽名一起被包含在ServerKeyExchange中被發送出去。客戶端在ClientKeyExchange中返回它的公開DH參數，但沒有簽名保護。同樣協商出來的DH密鑰被用作PreMasterSecret。

2.3 密鑰生成

Pseudo-random Function(PRF)：偽隨機函數是SSL協議中的一個重要組成部分，它被用來秘密擴展以及生成密鑰。在3.1節講解Finished消息時已經簡單提及PRF，在這里我們詳細討論PRF的工作原理。SSL/TLS協議中的PRF如下圖所示：

這個PRF基於兩個hash函數：MD5和SHA-1，它有3個輸入，一個Secret(比如PreMasterSecret)，一個標志符(比如」client finished」, 「server finished」)，還有一個種子值(比如客戶端隨機數+伺服器端隨機數)。

Secret在使用時被分為長度相同的兩半：S1和S2，分別作為P_MD5和P_SHA-1的輸入。

PRF的輸出按如下方式處理得到：

P_MD5和P_SHA-1都是擴展函數，用來擴展秘密值以用於密鑰生成，它們的計算方式如下：

其中A(0) = seed, A(i) = HMAC hash( secret, A( i −1) )

這個秘密擴展會一直進行直到得到足夠多的擴展數據。 Key Derivation：主密鑰(MasterSecret)是利用上述PRF從預備主密鑰(PreMasterSecret)生成的。每個MasterSecret為48位元組，生成方式如下：

得到MasterSecret後，它會被進一步處理最後生成4個不同的密鑰和2個初始向量(IV)。處理過程如下：

處理過程一直持續到足夠多的輸出被生成，然後把輸出分為4個key和2個IV：

下圖完整闡述了SSL/TLS協議中的密鑰生成過程。

本節介紹SSL/TLS協議的版本變遷，不同版本的區別以及安全特性等。

SSL 1.0由於從來沒有被公開過，並且存在嚴重安全漏洞，我們就不討論了。

SSL 2.0：SSL 2.0於1995年4月被發布。SSL 2.0中主要存在的問題如下：

MAC不能覆蓋填充長度域，攻擊者可能利用這點破壞消息完整性;

缺乏握手認證，攻擊者可以篡改密碼套件列表，誘騙通信雙方使用較弱的密碼套件;

使用較弱的或有問題的密碼演算法(如MD5，RC4等)，或者使用不安全的分組模式(如CBC模式);

對於不同的密碼學基元使用相同的密鑰，違背基本安全常識。

由於以上安全問題，RFC 6176已經明確提出避免使用SSL 2.0，但是現實生活中還有少量客戶端和伺服器支持SSL 2.0.

SSL 3.0：SSL 3.0引入了一些新的特性和機制解決了很多之前版本存在的漏洞。此外，SSL 3.0中引入了ChangeCipherSpec子協議。SSL 3.0向後兼容SSL 2.0，相對於SSL 2.0，它的主要改變包括以下幾點：

支持更多的密碼套件(支持更多的密碼演算法如DSS，SHA-1)

在握手階段支持密鑰協商(DH和FORTEZZA)

支持密碼學參數的重協商

增加了消息壓縮選項

MAC能夠覆蓋填充長度域了，同時MAC可以使用MD5或者SHA-1

不同的密碼學基元使用不同的key

Alert子協議能對任何錯誤給出兩種提示：Warning和Fatal

中止鏈接的時候會用一個close_notify警告通知通信雙方

支持證書鏈，而非單個證書

通過Finished消息認證所有發送和接收的消息

加密了的PreMasterSecret包含當前使用的協議版本，防止協議回滾

TLS 1.0：TLS 1.0和SSL 3.0差別非常小。實際上，TLS 1.0是SSL 3.1，在IETF接手後改名為TLS。TLS 1.0版本是目前使用最廣泛的SSL/TLS協議版本。

TLS 1.0不再支持使用FORTEZZA的密碼套件。

TLS 1.0中MAC被替換成HMAC。

之前提到ChangeCipherSpec消息必須在Finished消息前發送，在TLS 1.0中，如果消息序列不符合這個要求，會產生FATAL警告並終止鏈接。

TLS 1.1：這個版本相比之前改動也很小。最重要的改動是預防了針對CBC分組模式的一些攻擊。現在的填充錯誤變的和非法MAC錯誤不可區分了，防止攻擊者利用可區分錯誤響應建立解密預言機對密文進行攻擊。

在每次加密過程中，使用CBC分組模式時，都需要顯示給出IV，而不用再密鑰生成時使用PRF生成IV。

此外，TLS 1.1禁止為適應之前出口限制而使用弱化的密碼套件。

TLS 1.2：這是最新的版本，部署的還比較少。這個版本禁用了PRF中的MD5和SHA-1，而用一個可配置的hash函數取代了它們，這樣的修改簡化了計算過程。修改後的PRF風格如下：

此外，TLS 1.2的一個重要變化是支持認證加密模式(支持GCM等)。但是由於一些AEAD(Authenticated Encryption with Associated Data)密碼演算法要求IV為隱式的，所以IV又恢復到由MasterSecret生成，即TLS 1.0以前的風格。

TLS 1.2支持使用GCM、CCM的新密碼套件。

同時SSL 2.0被宣布放棄，不再向後兼容SSL 2.0.

本節簡單介紹一下流行的SSL/TLS實現庫，SSL協議非常復雜，由開發者自己實現常常會出錯，開發者在具體實現SSL協議時通常會依賴於這些密碼學庫。

4.1 常見的SSL/TLS 實現

OpenSSL：這是非常流行的開源SSL/TLS實現。

OpenSSLim完全用C語言實現，支持SSL 2.0/3.0，TLS 1.0/1.1/1.2以及DTLS 1.0。

OpenSSL 近年來出現了很多的安全漏洞，比如2014年曝出的著名的Heartbleed漏洞等。

JSSE：這是使用java實現的，支持SSL 3.0，TLS 1.0/1.1/1.2.

Bouncy Castle：它不僅僅支持SSL/TLS，它是一個完整的密碼學庫，支持各種密碼學演算法和協議。不過它僅僅支持TLS 1.0版本。

Android平台主要使用這個密碼學庫。

GnuTLS：這是另一個用C語言實現的庫，支持SSL 3.0，TLS 1.0/1.1/1.2以及DTLS 1.0。主要在Unix世界被使用。同時以各種安全漏洞多而聞名。

NSS：這是最初由網景公司(Netscape)開發的庫，支持SSL 2.0/3.0，TLS 1.0/1.1，現在主要被瀏覽器和客戶端軟體使用，比如Firefox使用的就是NSS庫，Chrome使用的是一個NSS庫的修正版。

下表是一些常見軟體以及它們所使用的SSL/TLS實現庫的情況：

其它還有一些常用的SSL實現庫，如cryptlib、CyaSSL、MatrixSSL、PolarSSL等，由於市場佔有率不高，我們這里就不多做介紹了。

4.2 流行SSL/TLS實現庫的安全研究

最近幾年曝出的高風險SSL安全漏洞大多跟SSL實現庫有關，比如2014年4月曝出的「心臟滴血」漏洞，存在於OpenSSL 1.0.1-1.0.1f版本中，影響全球近17%的Web伺服器;同樣是2014年曝出的蘋果公司iOS 7.0.6版本系統中存在的「gotofail」漏洞，因為程序員的疏忽導致SSL證書校驗中的簽名校驗失效;包括今年曝出的SSL Freak攻擊也是由於SSL實現庫的安全漏洞導致的攻擊，我們研究小組的同學對這個攻擊有詳細的分析，參見《SSL Freak來襲：如何實施一個具體的SSL Freak攻擊》。同時我們還開發了一個基於python的中間人代理攻擊框架「風聲」對某國內知名電商的伺服器進行具體的攻擊，並上報了漏洞。

考慮到大量SSL/TLS實現庫中存在安全問題，同時這些主流的SSL/TLS實現庫對開發者而言使用難度較高，比如有些SSL/TLS實現庫要求開發者自己進行隨機數生成或密鑰管理，讓缺乏系統信息安全知識培訓的開發者去使用這樣高度復雜的密碼學庫容易產生很多安全問題。我們在這里推薦一些高級密碼學庫：Google keycazer、NaCl、Cryptlib、GPGME。這些密碼學庫存在的安全問題較少，同時封裝了一些底層的密碼學操作，降低了開發者的使用難度。

以上就是本次要介紹的SSL /TLS協議基本知識，後續的文章我們會對一些典型SSL/TLS攻擊進行具體介紹。

參考：
1、 http://netsecurity.51cto.com/art/201505/476337.htm
2、 http://www.cnblogs.com/NathanYang/p/9183300.html
3、 https://www.cnblogs.com/bhlsheji/p/4586597.html

⑵ 加密後的字元串最後有兩個「==」是什麼加密演算法

Base64是網路上最常見的用於傳輸8Bit位元組碼的編碼方式之一，Base64就是一種基於64個可列印字元來表示二進制數據的方法。

1，Base64使用US-ASCII子集的64個字元,即大小寫的26個英文字母，0－9，＋，/。

2，編碼總是基於3個字元，每個字元用8位二進製表示，因此一共24位，再分為4四組，每組6位，表示一個Base64的值。

3，Base64值為0就是A，為27的就是b。這樣，每3個字元產生4位的Base64字元。如果被加密的字元串每3個一組，還剩1或2個字元，使用特殊字元"="補齊Base64的4字。

(2)javarc4加密演算法擴展閱讀：

應用

Base64編碼可用於在HTTP環境下傳遞較長的標識信息。例如，在Java Persistence系統Hibernate中，就採用了Base64來將一個較長的一個標識符（一般為128-bit的UUID）編碼為一個字元串，用作HTTP表單和HTTP GET URL中的參數。

在其他應用程序中，也常常需要把二進制數據編碼為適合放在URL（包括隱藏表單域）中的形式。此時，採用Base64編碼不僅比較簡短，同時也具有不可讀性，即所編碼的數據不會被人用肉眼所直接看到。

然而，標準的Base64並不適合直接放在URL里傳輸，因為URL編碼器會把標准Base64中的「/」和「+」字元變為形如「%XX」的形式，而這些「%」號在存入資料庫時還需要再進行轉換。

因為ANSI SQL中已將「%」號用作通配符。

為解決此問題，可採用一種用於URL的改進Base64編碼，它不僅在末尾去掉填充的'='號，並將標准Base64中的「+」和「/」分別改成了「-」和「_」。

這樣就免去了在URL編解碼和資料庫存儲時所要作的轉換，避免了編碼信息長度在此過程中的增加，並統一了資料庫、表單等處對象標識符的格式。

另有一種用於正則表達式的改進Base64變種，它將「+」和「/」改成了「!」和「-」，因為「+」,「/」以及前面在IRCu中用到的「[」和「]」在正則表達式中都可能具有特殊含義。

此外還有一些變種，它們將「+/」改為「_-」或「._」（用作編程語言中的標識符名稱）或「.-」（用於XML中的Nmtoken）甚至「_:」（用於XML中的Name）。

⑶ 文件受版權保護或被加密 無法轉換WMV格式

曾經有個破解的軟體freeme.

1.下載這個東東 http://jya.com/FreeMe.zip
2.解壓後會發現一個FreeMe.exe的執行文件，將它拷貝到你的音樂文件夾下，比如D:MP3
3.把你的加密wma音樂也放在D:MP3下
4.進入MS-DOS命令行模式
5.在命令行里打D:MP3>freeme xxx.wma
然後會生成一個Freed-xxx.wma，這就是破解後的文件
但是請注意，這個freeme.exe只能破解DRM2格式的文件，wma既有DRM1的，也有DRM2的，所有肯定會有些文件不能破。（此外，微軟已經發布了針對freeme.exe 的補丁，他包括更多安全性使得將來針對發布媒體的攻擊變得更加困難）
還有一些WMA文件需要聯網取得許可證，比如9sky。這類WMA如何破解呢？
1.當你從某某某網站下載一個wma文件後，直接用FreeMe破解是不行的。
2.你必須先用windows media player。播放這個wma文件，wmp會自動連接某某某網站取得播放許可證（有時還需要你輸入認證信息）。
3.按步驟取得許可證後，按彈出的對話框上的那個Play就可以聽音樂了。但，別急，先Stop media player（不能用pause，否則會有access violation），然後進入MS-DOS，再用FreeMe就可以順利破解了。
以下是閑話解說，有興趣的看看

最近下載了殺破狼前傳CD1.WMV，殺破狼前傳CD2.WMV，居然不能播放，真是抑悶哪！
用暴風看不了,要用系統自帶的Media player一打開就提示解碼器要升級，升級完成後又提示要證書才能播放，還好這網站估計只是為了宣傳，雖然會彈出幾個網頁，但不點也沒有關系，直接關掉就行了。接著就自動下載了證書，等個1分鍾，再次打開文件，就可以播放了。

下面的內容是的轉載的，希望對大家有幫助：

想破解WMV許可證的進來！

如果你有電信影視網帳號，則可用；
如果沒有，你可以使用 最新的 winamp505_pro 觀看，它可以屏蔽這個通行證

winamp505_pro 播放器下載地址：
點擊下載：http://www.ntol.cn/program/ha_winamp505_Pro.exe

用Winamp 5.07 Pro 簡體中文增強版免費歸觀看網上限制級DVD電影的方法
第一步：下載並安裝Winamp 5.07 Pro 簡體中文增強版
免費的不須注冊
如果你已經有Winamp 5.07 Pro 簡體中文增強版，
第二步：打開Winamp 5.07Pro 簡體中文增強版的「菜單選項」，選擇「選項」--「參數設置」
第三步：在「參數設置」里點擊「常規參數」，並將「網際網路連接設置」選項當中的「選擇你的 網際網路連接類型」選項，設置成「允許連接到

網際網路（LAN,DSL,Cable) 」選中.
第四步：
1、在「常規參數」---「媒體庫」選項當中選擇「網際網路廣播/電視」，將「網際網路廣播/電視選項」中的「在媒體庫顯示「網際網路廣播」和「

網際網路電視」查看」前的空格里打勾。
2、將「指定等級」下面的所有空格打勾，
注意：此步驟非常重要，否則你就不會看到你希望看到的限制級的網路電視。
第五步：打開Winamp 5.07 Pro 簡體中文增強版的「菜單選項」，選擇「文件」---「網際網路電視」選項。
第六步：在出現的「Winamp LIBRARY」(或ML)菜單選項中，點擊「網際網路電視」，此時，Winamp會自動搜索網際網路上的所有電視資源，包括限

制級DVD 電影。並在右面的欄目里顯示出可看資源目錄。
第七步：也是最後一步，在所有可看資源目錄里找你喜歡看的電影目錄，然後雙擊該文件名稱就可以觀看了。
最後說明，該網上電影資源豐富，播放質量很清晰，畫面流暢，當然，如果你是用小貓上網的話急壞了東西，你可別找我.
另外，該網上電影更新比較快，這樣你就可以看到大量免費的限制級DVD電影了。

wmv文件的許可證破解工具

========
使用方法：
首先請先開始正常聆聽有保護的的WMA文件
入工具選項裡面的證書管理
進行證書導出
導出後的證書文件建議放於一特定目錄
將其freeme壓縮包解壓到證書文件所在文件夾 這時再把需要解除保護的文件放於同一文件夾
DOS命令行窗口輸入 freeme 文件.wma
於是得到 freed-文件.wma 此文件即為沒有任何保護的普通WMA文件 可以任意播放

【注意】解除保護需要一可用證書 如果freeme運行無效 請導出你擁有的最新證書文件，像9天的可以獲取到證書再進行破解。

點擊下載：http://netroom.hbu.e.cn/personal/crackmore/crsoft/cr-wma.zip

另一個軟體（看了就會用）
點擊下載：http://netroom.hbu.e.cn/personal/crackmore/crsoft/cr-wma2.zip

如果還不行，請看下面：

**最近看到的方法，安裝media player 7 或更低版本即可觀看，大家可以試試看。
事實上"每個系統"中都有隱藏的6.4版本存在。為什麼？因為微軟自己也知道，MediaPlayer的6.4版本是最最穩定的，其他的諸如7.0、8.0版本

，播放MPEG4的剪輯時都會出現這樣或者那樣的問題。

========

密碼分析家2.7(感謝7樓 shirley510提供破解版地址)

軟體語言： 簡體中文
軟體類型： 黑客工具 / 破解專區
運行環境： WinXP, Win2000, NT, Win9X
軟體大小： 1.29 MB

軟體簡介： 密碼分析家可以分析出帶版權的WMV和WMA文件的用戶名和密碼。軟體的特殊之處是在分析的過程中可以自動生成一個或多個模擬

的許可證藉此來探測WMV和WMA文件的用戶名和密碼，准確率可達80%。
此外軟體還可以分析出帶有密碼保護的WDL和PDF文件的密碼。

下載地址:http://www.yzqn.net/SoftDown.asp?ID=13952
一般提供影片的網站把WMV加密，即使你下載了也沒法看
除非你你花錢獲取許可證，也就是在網站上注冊，打開WMV的時候會一般會連接到這個網站或代理站
讓你輸入個類似賬戶密碼之類的東西，然後網站會自動把許可證分配給你
你就可以看了，
破解DRM，別想了，很麻煩……

DRM，英文全稱Digital Rights Management ，一般翻譯為數字版權保護或數字版權管理。DRM分為兩類一類是多媒體保護，例如加密電影、音

樂、音視頻、流媒體文件。另外一類是加密文檔，例如Word, Excel, PDF等。DRM主要通過技術手段來保護文檔、電影、音樂不被盜版。這項技

術通過對數字內容進行加密和附加使用規則對數字內容進行保護，其中，使用規則可以斷定用戶是否符合播放。

系統原理：
系統會將密鑰標識和許可證頒發機構地址寫入打包加密後的內容的頭部，並且使用另一對密鑰，通過橢圓曲線加密演算法對頭部信息進行簽名，

防止頭部信息被非法修改。內容部分的加密過程可以簡單描述為，首先使用SHA-1散列演算法處理56位密鑰，得到一個160位，即20位元組的密鑰散

列。這個密鑰散列的前12位元組將用作生成加密過程中使用的密鑰。這12個位元組將作為一個密鑰，通過RC4演算法加密一個全零的64位元組串，得到一

個64位元組的加密結果，其中前48位元組，即12個32位字作為產生加密內容使用的密鑰的來源，分別針對前面6個32位字的和後面6個32位字進行操

作。對於被加密的內容來說，首先把被加密的內容切分為8個位元組的數據塊。對於每一個8個位元組的數據塊，它的前32位數據將和上述密鑰的前

面6個32位字的進行運算，後32位數據將和上述密鑰的後面6個位元組進行運算。具體運算過程是，32位數據與6個32位字的的密鑰的第一節位元組相

乘，然後除以4294967296取其餘數，並交換結果的高16位和低16位，然後再與6個32位字的的密鑰的第二節位元組相乘，然後除以4294967296取其

余數，並交換結果的高16位和低16位，然後再與6個32位字的的密鑰的第三節位元組相乘，然後除以4294967296取其餘數，並交換結果的高16位和

低16位，然後再與6個位元組的密鑰的第四節位元組相乘，然後除以4294967296取其餘數，並交換結果的高16位和低16位，然後再與6個32位字的的

密鑰的第一節位元組相乘，然後除以4294967296取其餘數，並交換結果的高16位和低16位，然後再加上6個32位字的密鑰，然後除以4294967296取

其餘數，上述過程定義為函數f(x)，設一個64位狀態值，並設初值為零。
網上找了N久後終於找到FairUse4WM，經測試使用ok，特和兄弟們分享
使用心得：該軟體是屬於必須得有認可證的情況下才能使用，按我們bt下載的基本上認可證都能下載下來，就是麻煩每次必須得用MEDIA

PLAYER打開並且還得等待，中間還有彈出的網頁，麻煩啊，所以用這個軟體把drm也就是認證步驟分解出來，分解出來後就可以像正常的WMV文

件一樣用其他軟體播放，感覺不錯的，軟體運行之前得保證你的認可證，也就是先播放wmv文件，下載認可證彈出窗口播放按鈕可以點擊時不要

播放直接退出，之後運行fairuse4wm，按下一步來就是了，再把你的wmv文件重新輸出成個新文件通常是[NoDRM]-文件名.wmv

軟體名稱：FairUse4WM
軟體版本：V1.3
適用平台：Windows 9x/ME/NT/2000/2003/XP
官方網站：http://forum.doom9.org/
功能簡介：
-----------------------------------------------------
FairUse4WM 是一個 drmdbg 的圖形用戶界面程序，可以移除媒體文件中的 DRM 保護，支持 WM10 和某些 WM11 版本，不支持 WM9。如果

您發現某些文件不能在您的移動設備上播放或無法被轉換，請嘗試使用這個軟體來提取許可證。一旦您提取了許可證，就再也不需要使用WMP來

播放每個文件了。(請勿用於非法用途)

『漢化說明』
-----------------------------------------------------
安裝文件到任一目錄運行即可！
-----------------------------------------------------
下載地址：http://teacher.zjnu.cn/wuguole/HA_FairUse4WM13_WGL.exe
下載地址：http://www.cngr.cn/dir/212/300/2006090812906.html
下載地址：http://wuguole.ote.com/down/HA_FairUse4WM13_WGL.exe第三個下載地址 （用工具例如迅雷下載）

找到更有意思的東東了，解決不了問題的朋友請繼續耐心看下去。

wmv文件的許可證破解

使用方法：
首先請先開始正常聆聽有保護的的WMA文件
入工具選項裡面的證書管理
進行證書導出
導出後的證書文件建議放於一特定目錄
將其freeme壓縮包解壓到證書文件所在文件夾 這時再把需要解除保護的文件放於同一文件夾
DOS命令行窗口輸入 freeme 文件.wma
於是得到 freed-文件.wma 此文件即為沒有任何保護的普通WMA文件 可以任意播放.
【注意】解除保護需要一可用證書 如果freeme運行無效 請導出你擁有的最新證書文件，像9天的可以獲取到證書再進行破解。
點擊下載FreeMe：http://netroom.hbu.e.cn/personal/crackmore/crsoft/cr-wma.zip

另一個軟體（看了就會用）
點擊下載Un***：http://netroom.hbu.e.cn/personal/crackmore/crsoft/cr-wma2.zip

現在網上流行的視頻格式除了RMVB和AVI之外，有慢慢出現了一些WMV格式的視頻，這些視頻文件無法用第三方播放器播放，播放時必須在線，無法離線播放。如果你也遇到這樣的視頻文件，也正因此而苦惱時，我們來幫你解決問題吧！

前段時間我從網上下載了一部電影，打開後發現是WMV格式的，它必須要用Windows Media Player在線播放，非常麻煩！經過研究，這些視頻都是加了DRM數字簽名，需要聯網驗證，獲取許可證後才可以播放的。

\\小知識
揭秘DRM
DRM(Digital Right Management)，內容數字版權加密保護技術，這是專門來用保護音、視頻文件內容版權的技術，它可以限制文件播放的次數，播放的時間等。這種技術目前用在微軟的視頻格式WMV上，現在網路發布的正版電影多是採用這種格式進行加密，比如前段時間網路發布的《夜宴》，就使用了DRM版權保護技術。
DRM的工作原理:首先建立數字視頻授權伺服器，編碼壓縮後的視頻文件，利用密鑰(Key)可以被加密保護(Lock)，加密的數位元組目頭部存放著KeyID和視頻授權伺服器的URL。用戶在播放視頻時，根據視頻文件頭部的KeyID和URL信息，連接至視頻授權伺服器，驗證授權後，服務獲取發送出相關的密鑰解密(Unlock)，也就是許可文件，節目就可播放了。

正是由於許可證的問題，這類視頻文件不能離線播放，不能用第三方播放器播放，不能在其他電腦上播放，更別說轉換成其他格式在MP4上播放了。為了解決這幾個不便，目前唯一的方法就是將DRM從WMV文件中剝離出來。

FairUse4WM小檔案
軟體版本:1.3 漢化版 軟體大小:1202KB
軟體性質:免費軟體 適用平台:Windows 9x/2000/XP
下載地址:http://www.newhua.com/soft/51937.htm

第一步:你要確認已經取得WMV文件的合法授權，即可以用Windows Media Player正常播放，FairUse4WM的功能只是將DRM驗證部分剝離。
第二步:運行FairUse4WM後，會出現下圖所示窗口，提示你FairUse4WM至少需要一個已激活的許可文件，點擊「恢復許可證」按鈕，如未提示「IBX組件似乎不存在」，則可直接跳過第三步。

小提示
由於網上大部分DRM視頻是使用DRM 10組件加密的，所以建議你升級至Windows Media Player 10，以使可以獲取許可證。

第三步:現在我們需要獲取一個已激活的許可文件，登錄http://services.wmdrm.windowsmedia.com/indivSite/en/indivit.asp，點擊「Upgrade」按鈕，稍候會彈出獲取許可證的窗口，點擊「是」就可以了。重新啟動電腦，完成安裝。
第四步:有了正確的許可證，點擊「恢復許可證」按鈕後，就會打開下圖所示窗口，點擊「添加文件」按鈕，選擇帶DRM的WMV文件，再設置好「輸出目錄」，點擊「下一步」。

這時，軟體開始轉換視頻，800MB的文件不到2分鍾就可以完成轉換了。現在用暴風影音或Kmplayer播放一下轉換後文件名前帶有[NoDRM]的視頻文件，看看DRM是不是已經被剝離？
小編有話說:對於網上下載回來的帶DRM的WMV視頻，如果你不能判斷其獲取許可證的網站是否合法，最好不要輕易去聯機下載。

\\單獨排
DRM出了故障怎麼辦？
如果出現了「Windows Media數字許可權管理(DRM)」系統可能無法正常工作」類的提示，可以按如下步驟進行修復。
第一步:確認系統安裝了Windows Media Player 10。
第二步:從http://work.newhua.com/cfan/200707/cleardrm.rar下載DRM清除工具，運行後系統中的DRM文件及注冊表中的DRM信息會全部清除。
第三步:登錄http://drmlicense.one.microsoft.com/Indivsite/zh-cn/indivit.asp?force=1，點擊「Upgrade」按鈕，重新更新DRM信息就可以了。

小提示
DRM是和電腦硬體相關的，如果你更換了硬體，可能會出現「The license to play the packaged media is invalid.C00D277F - Secure storage protection error.Restore your licenses from a previous backup and try again.」的提示，用上面的方法也可以修復。

DRM的備份與恢復
除了上面我們提供的方法外，如果你需要重裝系統又無法下載到新的許可證了，可以將DRM備份出來:進入Windows Media Player，選擇「工具→管理許可證」菜單項，點擊「更改」按鈕，將位置設置在快閃記憶體檔等位置，然後點擊「立即備份」，這樣重裝系統後，只要在同一窗口中選擇好備份的位置，再點擊「立即還原」按鈕就可以了。

如果還不行，請看下面：

**最近看到的方法，安裝media player 7 或更低版本即可觀看，大家可以試試看。
事實上"每個系統"中都有隱藏的6.4版本存在。為什麼？因為微軟自己也知道，MediaPlayer的6.4版本是最最穩定的，其他的諸如7.0、8.0版本，播放MPEG4的剪輯時都會出現這樣或者那樣的問題。
Media Player 6.4的位置一般如下：
C:\Program Files\Windows Media Player\mplayer2.exe

下載實時播放的流節目完全教材（高、中、初級指南）

一、初級篇——下載隱藏的ASF與MWV文件
ASFRecorder V1.1是一個專門用來下載ASF、Wma、Wmv格式流文件的工具。它除了能把ASF下載回來外，也支持ASF文件的索引格式ASX文件，它能把隱藏在ASX裡面的真正流部分找出來，甚至還可以設置代理等等，功能強大之餘使用也非常方便。只要在其菜單下面選再輸入流節目的地址後就可以回到主界面按那個三角形符號開始下載了。
最近還出現了另外一個流節目下載軟體 Stream Download Project v1.4 ，它的功能和 ASFRecorder非常的相似，一樣是只支持ASF和WMV格式，一樣不支持多線程下載和續傳。但它畢竟是比較新的軟體，在一些 Streambox Vcr都不能成功下載的情況下，用這個軟體試試或者會讓你有柳暗花明的感覺。

二、中級篇——下載隱藏的RM文件 Streambox Vcr不但支持點播形式的流節目也同樣支持現場流節目，而且兩者可以同時下載！由於它採用了獨特的分析技術，所以可以把那些隱藏在ASX後的ASF文件和隱藏在SMIL文件後的RM文件找出來並進行下載。這個功能雖然在ASFRecorder裡面已經實現，但真正做到實用階段的是Streambox Vcr！另外，Streambox Vcr支持的流播放協議相當齊全，http、ftp、rtsp、mms、pnm等能數得出的協議它都全部支持並可以在下載的時候自動判別。除此之外它支持斷線續傳、支持定時下載、支持拖放下載等等作為下載軟體必要的功能它一樣沒少，夠吸引的吧！

三、高級篇——下載受保護的流媒體文件
對於一些隱藏得更深、保護得更完善的流文件，StreamBox vcr因找不到真實地址而無法下載。這個時候，我們就需要用另外的軟體來分析、整理出真實的地址了。既然流文件用播放器能播放，那麼真實地址一定是隱藏在發送到本機的網路數據包裡面。所以只要用軟體截獲網上發送過來的數據包，然後加以分析就一定可以找得到真實地址。現在出現了一個專門是用來和StreamBox vcr等軟體配合的地址嗅探軟體Project URL Snooper

下載電影的技巧（極限下載秘技）！！！
從網上下載，聽起來容易，但想真正成為高手，就要做到「下別人之不能下，載別人所不會載」，其中的門道可並不簡單。
提到下載，很多人都認為所謂的download不過是從網上把軟體或mp3復制到硬碟中的一個過程。然而，如果真用這個標准來衡量的話，恐怕把全世界網民至少能數出幾億個下載高手來。可實際上，下載包含的內容遠不止於此。從理論上講，即使是瀏覽普通的網頁也應該算是下載的一種，何況去下載軟體、音樂、圖書等更精彩的資源了。網路的開放性不斷吸引著人們去尋找對自身有價值的東西，而各種商業網站又為了自身的利益，不斷依*「先進」技術使它們提供的資源逐漸封閉化。為了下載一個軟體而打開三層頁面的網站並不少見，而更多的圖庫站點更需要您不斷點擊大大小小的鏈接才肯露出廬山真面目；說是免費閱讀圖書，又不讓您下載，給您一個連抓圖都不支持的java窗口，慢慢看去吧！（估計等您把書看完，您的網費開銷能買十本原版書了。）有人說，網上的免費是糖衣炮彈：想下載軟體，請您看廣告；想聊天，請您看廣告；想要免費信箱，請您看廣告（更有附加在您每封郵件末尾的廣告）。還有，某些精彩的flash動畫、real影片以及各種在線播放的音頻和視頻，更是「只可遠觀而不可褻玩焉」——不支持下載！
軟體名稱：FairUse4WM，一個很好的工具，可以批量去除下載的WMV、WMA視頻文件中的許可證，即DRM 數字版權保護，讓你隨意播放或轉換視頻文件而不受其限制，分享一下！

下載地址（漢化版）：ftp://hhdown:[email protected]/download/HA_FairUse4WM13_WGL.exe

說明：用Windows Media Player，依次瀏覽播放待去除許可證的WMV或WMA視頻文件，即獲得所有視頻文件的許可證後，運行軟體，添加這些文件即可批量去除許可證。操作和功能遠勝於軟體FreeMe.exe。

⑷ java如何讀取一個加密後的.xls文件

近日來，研究了一下Excel Biff8（xls 97-2007）與OpenXML（ECMA-376）的加密文檔的讀取（這還是為了我們世界先進Grid而做的 ^__^）。有些成果，寫在這里，希望能給要做類似功能的XD們一些參考。
如有不詳，請聯系：[email protected] / [email protected]
前提：
1. 加密文檔：指Wookbook級的加密，就是在Save Excel文檔時在General Settings中設置open password之後的文檔；
2. 打開：需要用戶傳入密碼。並非破解。但請勿將本文方法添加暴力模塊使用 :-) ；
3. 本文涉及較多為，密鑰計算，關於解密細節請參考微軟相關文檔；
使用的加密演算法： RC4, SHA1, MD5, AES-128（其中RC4並不包含在所有版本的.NET Framework中，AES演算法可以在.NET Framework 3.5中找到）
本文示例依賴 .NET Framework 3.5

A. Biff8 的加密文檔讀取
1. 通過文檔中FILEPASS的record取得，文檔的加密信息（關於Biff文檔的格式問題，請參閱Biff的微軟文檔）
其中Biff8可以使用兩種方法加密：Biff8標准加密演算法和Biff8擴充加密演算法。本文主要討論最常用的Biff標准加密演算法
2. 通過FILEPASS的結構，獲得如下信息：
salt（加密隨機數，16 bytes）
password verifier （密碼效驗器，16 bytes）
password verifier hash（密碼效驗器Hash，16 bytes）
3. 通過以上信息，生成解密key。並通過密碼效驗器，驗證密碼：
i. 將密碼轉化成unicode數組，並進行MD5 Hash；
ii. 將hash結果與salt串聯，然後將byte數組，反復串聯16次（336 bytes） ，然後再進行MD5 Hash；
iii. 將上步hash結果的前五位，串聯上4 bytes的block值（在密碼驗證階段為0，在以後解密階段為block的index） ，然後進行MD5 Hash；
iv. 將上步hash結果的前16位，作為key
v. 使用RC4對稱加密演算法，將password verifier和password verifier hash分別解密，然後對password verifier的解密結果進行MD5 hash，其值應和password verifier hash的解密結果一致，即為密碼正確。
vi. 之後進行逐個record的解密。excel biff8加密原則基本為，record的標示不加密，長度不加密，個別record不加密（見文檔）；另外，在record解密時，還需要通過block的值重新計算解密key，block的大小為1024.
4. 詳細請參照示例代碼；

B. OpenXML(ECMA-376) 加密文檔的讀取
1. 通常來說，xlsx文件相當於一個zip文件，可以用zip程序，直接打開。而在加密後，為了安全性考慮，微軟使用了 structured storage（一種OLE文檔存儲方式）存儲（可以用7-zip或者OLE document viewer打開，windows也有相應API來操作此類結構）。在上述文檔中，有一個叫做「EncryptedPackage」加密的package，就是一個zip包通過AES演算法進行加密之後的結果。我們將使用和A一樣的方式來檢查密碼，但生成key的方法不同；OpenXML的加密類型也有多種，我們這里就討論常用的用AES-128進行加密的流程；
2. 通過文檔的「EncryptedInfo」部分，需要過的一下信息（關於此部分的結構，請參考[MS-OFFCRYPTO].pdf）
salt（加密隨機數，16 bytes）
password verifier （密碼效驗器，16 bytes）
password verifier hash（密碼效驗器Hash，32 bytes）
3. 通過以上信息，生成解密key。並通過密碼效驗器，驗證密碼：
i. 首先，定義一個H函數，其有兩個輸入，內部使用SHA1演算法將兩個輸入串聯之後的結果hash返回；
ii. 先將salt與password（password的unicode數組）進行H計算，h = H(salt, password) ；
iii.然後設iterator為0x00000000，將其轉為4byte的數組，然後進行H計算，h1 = H(iterator, h);
iv.將上面的iterator遞增一，然後再與h1進行H計算，h2 = H(iterator,h1)，然後將這個遞增和計算過程重復50000次，最後計算過的iterator為49999即可；
v. 現在有計算結果h50000，將h50000再與0x00000000(4 byte數組)進行H計算，Hfinal = H(h50000, 0x00000000)；
vi. 生成一個64byte的數組，將每位都初始化成0x36，然後將這個數組與Hfinal異或；(關於這個地方，微軟文檔中寫的有錯誤，按照原文的方法生成的key不正確，要不是文檔的作者回信告訴我要使用這個法子，就算我想破頭也想不出來啊 T__T)
vii.將異或結果，進行SHA1 hash，結果的前16byte就是解密的key；
viii.初始化AES演算法，key長度為128，模式為ECB模式，Padding為none； 然後將password verifier 和password verifier hash分別解密；
ix. password verifier 解密後的SHA1 hash結果應該與password verifier hash解密後的前20byte相同；
4. 關於"EncryptedPackage" 的解密則更為簡單，只許將「EncryptedPackage」讀入，去除前8byte的size信息後，進行AES解密，即為未加密的標准openxml文檔。

參考：
[MS-OFFCRYPTO].pdf
[MS-XLS].pdf
ECMA-376 standards

Reply by "winnow", 2008-09-10, 1:17
-----------------------------------------------------
總結一下, 關於這兩種基於密碼的加密方法, 基本上都是基於RFC2898 建議, 思想是這樣:
輸入是用戶的密碼:password, 輸出是提供給加密函數的密鑰:key.
考慮安全, 需要使同樣的password生成的key不一樣, 這樣用相同的password加密後的結果就無法比較. 需要一個隨機數salt.
另外, 為了使暴力破解的代價增大, 考慮使用一個循環多次的過程, 需要循環次數:iteration_count.
概念上, 生成方法為: 將password和salt進行某種運算, 配合一個Hash函數, 以某種方式循環iteration_count次, 在最後的結果里取一部分作為key輸出.
具體參照RFC2898中的建議方法PBKDF1和PBKDF2.
這樣, 用戶輸入的密碼與一個隨機數組合, 經過一定代價的運算, 就生成了可以供加密函數使用的密鑰. 使用這個密鑰和一個加密函數, 就可以進行加密了.

在應用中, 為了快速判斷密碼是否錯誤. 生成一個隨機數verifier, 用一個Hash函數計算verifier的hash值:verifier_hash, 分別加密verifier和verifier_hash並保存.
解密的時候, 先分別解密出verifier和verifier_hash, 計算verifier的hash值, 與verifier_hash比較, 如果一致, 即說明密碼正確.

⑸ 求一個實現RC4加密演算法的第三方包，JAVA的

 曾經實驗室的帶動，加上最近在上網路安全與管理的專業選修課，對加密演算法有了濃厚的興趣。老師留了一次作業，用自己的學號為密鑰，加密一句話，使用RC4加密演算法。
   圖書館查找資料，發現RC4演算法還是比較容易理解的。於是動手實現出來。不多說廢話，還是貼代碼吧。我寫的注釋還算清楚。
   先貼一個含main函數的核心演算法類，有測試，可以看看最後輸出了什麼^.^
 
import java.io.UnsupportedEncodingException;
public class Arithmetic {
 
 
 public static void swap(int x,int y){
  int temp;
  temp=x;
  x=y;
  y=temp;
 }
 
 public static void main(String[] args) throws UnsupportedEncodingException {
   
  
  
  //  密鑰（我的學號）
  byte K[]={0,6,1,6,1,0,0,4};
  
  int S[]=new int[256];//狀態矢量S
  int T[]=new int[256];//臨時矢量T
//  初始化狀態矢量S,同時生成臨時矢量T 
  for(int i=0;i<256;i++){
   S[i]= i;
   T[i]=K[i%K.length];
  }
  //用T使S置換
  {
    int j=0;
    for(int i=0;i<256;i++){
       j=(j+(int)S[i]+(int)T[i])%256;
       swap(S[i],S[j]);
     }
  }
  
  
  int i = 0,j=0;
  boolean tt=true;
  int c=0;
  int t;
  byte k;//密鑰流的當前位元組
  byte C[]="套范續".getBytes();
  
  System.out.println(C[3]);
  byte P[]=new byte[C.length];
  while(c<6){
   i=(i+1)%256;
   j=(j+S[i])%256;
   swap(S[i],S[j]);
   t=((S[i]+S[j])%256);
   k=(byte) S[t];
//   C[c]=(byte) (k^P[c]);
//     System.out.print(C[c]+" ");
   P[c]=(byte) (k^C[c]);
     System.out.print(P[c]+" ");
   c++;
  }
   System.out.println(new String(P,"GBK")); 
//  byte rr[]={65};
//    System.out.println(new String(rr)); 
 }
}
  再來貼一下以界面展示的代碼，比較長。用的就是普通的jsp+servlet。
核心類：
public class RC4 {
// 密鑰（我的學號）
 byte K[]={0,6,1,6,1,0,0,4};
 
  void swap(int x,int y){
  int temp;
  temp=x;
  x=y;
  y=temp;
 }
 
 public String encrypt(String plaintext){
  String ciphertext=new String();
  int S[]=new int[256];//狀態矢量S
  int T[]=new int[256];//臨時矢量T
//  初始化狀態矢量S,同時生成臨時矢量T 
  for(int i=0;i<256;i++){
   S[i]= i;
   T[i]=K[i%K.length];
  }
  //用T使S置換
  {
    int j=0;
    for(int i=0;i<256;i++){
       j=(j+(int)S[i]+(int)T[i])%256;
       swap(S[i],S[j]);
     }
  }
  
  
  int i = 0,j=0;
  int c=0;
  int t;
  byte k;//密鑰流的當前位元組
  byte P[]=plaintext.getBytes();
  byte C[]=new byte[P.length];
  while(c<P.length){
   i=(i+1)%256;
   j=(j+S[i])%256;
   swap(S[i],S[j]);
   t=((S[i]+S[j])%256);
   k=(byte) S[t];
   C[c]=(byte) (k^P[c]);
     System.out.print(C[c]+" ");
   c++;
  }
   System.out.println(new String(C)); 
  ciphertext=new String(C);
  return ciphertext;
  
 }
 
 
 
}
 頁面：
home.jsp
<%@ page language="java" import="java.util.*,core.ChangeCharset" pageEncoding="GBK"%>
<%
String path = request.getContextPath();
String basePath = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/";
%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html>
  <head>
    <base href="<%=basePath%>">
   
    <title>My JSP 'home.jsp' starting page</title>
   
 <meta http-equiv="pragma" content="no-cache">
 <meta http-equiv="cache-control" content="no-cache">
 <meta http-equiv="expires" content="0">   
 <meta http-equiv="keywords" content="keyword1,keyword2,keyword3">
 <meta http-equiv="description" content="This is my page">
 
 <link rel="stylesheet" type="text/css" href="styles.css">
 
  <script type="text/javascript">
     function doencrypt(){
        document.form1.domethod.value="encrypt";
        document.form1.submit();
     }
     function dodecipher(){
        document.form1.domethod.value="decipher";
        document.form1.submit();
     }
 
 
 
  </script>
  </head>
 
  <body>
 
 
  <%@ include file="header.jsp" %>
  <div id="show" >
 
  <form name="form1" method="post" action="Manage">
  <input type="hidden" name="domethod" />
    請輸入一句話：<input type="text" name="plainText" />
   <a href="javascript:void(0)" onclick="javascript:doencrypt();return false;">加密</a>
     </br>
     </br>
     <%String cipher=(String)request.getAttribute("cipher");
       if(cipher==null){
           cipher="";
       }
       String plain1=(String)request.getAttribute("plain1"); 
       if(plain1==null){
           plain1="";
       } 
      %>
    所得密文：<input type="text" name="cipherText" value="<%=cipher %>"  />
    <a href="javascript:void(0)" onclick="javascript:dodecipher();return false;">解密</a>
     </br>
     </br>
    所得明文：<input type="text" name="getPlain" value="<%=plain1 %>"  />
    </form>
    </div>
   <%@ include file="footer.jsp" %>
  </body>
</html>
header.jsp（這個沒什麼意思，但還是給出來吧，給初學html的朋友一些借鑒）
<%@ page language="java" import="java.util.*" pageEncoding="gb2312"%>
<div id="header" align="center">
 
 <h1>RC4加密演算法測試系統</h1>
 <hr>

</div>
footer.jsp
<%@ page language="java" import="java.util.*" pageEncoding="gb2312"%>
<div align="center">
    <hr>
    <table>
       <tr><td>Powered by Tasu</td></tr>
       <tr><td>Copyright@Tasusparty Studio 2009-2010 All rights reserved</td></tr>
   
    </table>
</div>
styles.css(給出來省事一些，諸位看起來方便)
body{
margin:0px;
padding:0px;
background: #E6EAE9;
font-family: "Lucida Sans Unicode", "宋體", "新宋體", Arial, Verdana, serif;
color:#4f6b72;
font-size:12px;
line-height:150%;
}
#show{
 margin:0px auto;
 padding:0px;
 width:200px;
 height:400px
 }
#header{
margin:30px auto;
}

 
處理的Servlet：
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import core.ChangeCharset;
import core.RC4;
public class Manage extends HttpServlet {
 
 public Manage() {
  super();
 }
 
 public void destroy() {
  super.destroy(); // Just puts "destroy" string in log
  // Put your code here
 }
 
 public void doGet(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
  doPost(request,response);
 }
 
 public void doPost(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
  request.setCharacterEncoding("GBK"); //設置輸入編碼格式
  response.setContentType("text/html;charset=GBK"); //設置輸出編碼格式
        String domethod=request.getParameter("domethod");
       
        if(domethod.equals("encrypt")){
  String plain=request.getParameter("plainText");
  RC4 rc4=new RC4();
  String cipher=rc4.encrypt(plain);
  System.out.println(cipher);
  request.setAttribute("cipher", cipher);
  request.getRequestDispatcher("home.jsp").forward(request, response);
        }
        if(domethod.equals("decipher")){
      String cipher=request.getParameter("cipherText");
      RC4 rc4=new RC4();
      String plain=rc4.encrypt(cipher);
      
      request.setAttribute("plain1", plain);
      request.getRequestDispatcher("home.jsp").forward(request, response);
            }
 }
 
 public void init() throws ServletException {
  // Put your code here
 }
}（中網互贏 手機客戶端）