第壹種加密方案是修改RGSS102J.dll中的解密算法，然後自己把素材打包成RGSSAD格式。
此方案要求使用者對程序設計以及二進制文件的修改有壹定的基礎。
由於我現在還沒有試過外掛dll這種技術，所以這裏介紹壹個相對簡單的方法——修改MagicKey的初始值。RMXP是使用0xDEADCAFE作為MagicKey的初始值，那麽我們把RGSS102J.dll中的DEADCAFE修改掉，然後自己打包就可以防範那些壹般的解包工具。
當然，如果妳覺得有必要的話，還可以給這個修改過的dll文件加壹個強殼，然後隨遊戲發布。
雖然安全系數不高，但足以應對全自動的提取工具。我寫了壹個程序來自動修改MagicKey，並打包資源文件，我給它起名叫"紙老虎"。下載網頁 /user/lingchen/file/1333250。
難度指數：★★
安全指數：★☆
·方案二：混淆文件名
第二種加密思路是混淆文件名。在Windows操作系統下，有 \/:*?"<>| 這9個字符是不能用作文件名的。除去\/表示文件目錄，我們還有7個特殊字符可用。如果在原有文件名中加入這幾個本來不能用的字符，那麽解包程序就會因為不能正常創建文件而提取失敗。
註：此方法需要自己打包資源文件，以及修改rxdata文件，工作量比較大。
混淆不能絕對保證自己的遊戲不被盜用，它的主要目的是打擊盜用者的信心，讓他在還沒有導出全部素材的時候就已經垂頭喪氣，精疲力盡了。
難度指數：★★★★
安全指數：★★☆
·方案三 將整個遊戲打包成壹個可執行程序
這個方法很多人都在用，而且可用的工具比較多，與MoleBox類似的工具都可以做到。
難度指數：★★
安全指數：★★★
·方案四 給遊戲加壹個特殊的"殼"
此方法與方案三類似，並且與傳統概念上給程序加殼有所不同。這裏所說的"殼"更類似用壹個定做的程序給遊戲當作中介，它通過HookApi或者別的什麽方法接管遊戲讀寫文件的操作。因為是完全接管，所以資源使用什麽格式完全是由使用者決定的。此方法需要比較深的編程功底。
難度指數：★★★★
安全指數：★★★☆
·方案五 自制RGSS解釋器
這是所有方案中最有效的方案，但是如果真的要自制壹個RGSS解釋器有兩個主要的障礙，
1、RMXP使用的文件格式
2、編寫RGSS腳本的解釋器
很顯然，障礙壹要比障礙二簡單的多，但同樣是壹個龐大的工程。（如果有RMXP的源代碼的話另當別論）
難度指數：★★★★★
安全指數：★★★★★
對於遊戲而言，無論什麽樣的加密方案都只是增加破解者的工作強度，而不能真正保護自己的素材不被提取，因為素材終歸是要在遊戲中使用的。