保護MIDP應用里的數據文件--遠離版權侵犯

2019-11-18 16:13:39

字體：大中小

來源：轉載

供稿：網友

摘要
開發者開發MIDP應用時經常面臨如何保護分布在JAR中的數據的困境，通過保護數據, 其他人便不能偷竊或使用它去創造另一個與之競爭的應用。JCP正在引入新的JSR來解決這個問題。可是，傳統的方法依靠密碼計算，它很消耗CPU資源并且不向后兼容的，因此對那些不支持新的API 的電話是很不方便的。這也讓那些希望通過簡單機制來防止版權侵犯的開發者感到不便。本文描述了一個在壓縮和保護MIDP應用里的數據的方法。

版權聲明：任何獲得Matrix授權的網站，轉載時請務必保留以下作者信息和鏈接
作者:Amydeng(作者的blog:http://blog.matrix.org.cn/page/Amydeng)
原文:http://www.matrix.org.cn/resource/article/44/44334_MIDP+DATA.Html
關鍵字:MIDP;DATA

隨著OTA技術的持續成熟，一個新的市場對軟件開發者開放了。目前，機智的蜂窩電話用戶會購買一個來自Handango.com 的J2ME MIDP應用并在數秒內下載到他們的手機上。在剛剛過去的幾年里，無線軟件產業從鈴聲跳躍到了成熟（羽毛豐滿）的游戲應用。

許多消費者更加認識到他們可以為他們的手機承受多少錢；他們經常聯想帶有無意義游戲的J2ME應用。然而，隨著用戶升級到新一代的手機，一種帶有實際使用價值的基于MIDP應用的新知識受到關注。在Handango的最佳J2ME軟件出售名單上都是基于應用的知識，如多語詞典，詞匯訓練，圣經，記事本，甚至有雞尾酒配方。名單上的一個字典程序在不到一年的時間里已經有將近26,000次下載！考慮到數千的無線訂戶愿意花費3美圓在一個鈴聲上，實際J2ME應用的市場潛力是巨大的。

不像游戲程序，基于知識的應用程序的價值在于數據。由于MIDP應用硬件利用的簡單性，如果數據文件被折衷的話，可以很容易就提出一個與之競爭的應用。盡管將數據放在后臺服務器的客戶端-服務器模式可以闡釋這種關系，這樣的模式對大多數無線應用來講被證明是不切實際的。除非等到無線數據傳播費用降低，同時無線連接變得更加可靠和普遍，目前來說將數據文件嵌入MIDP JAR 是唯一的選擇。因此，保護數據文件不受版權侵犯變得勢在必行。

該問題的一個普遍解決辦法是加密數據文件。實際上，幾個JSRs正在籌備提供一套加密解密的標準API。但是，密碼系統即使對于桌面J2SE應用來說也是CPU密集的。而且,如果要等到新的手機都會支持這樣的API,至少還有很多年時間。此外，基于新API的代碼不向后兼容目前的手機。這導致了一個灰色時代，某個應用可以在一些手機上運行但在另外一些上不可以。一個可選擇的方法是使用第三方的支持J2ME的密碼庫。一個流行的開源工具是Bouncy Castle的輕量級密碼支持API。但是，注意：這個庫超過400KB。考慮到市場上大多數的Nokia java手機有64KB JAR的大小限制，這個方法又是不可行的。

我提出一個簡單的解決該問題的方法。增加一行額外的代碼，忽略JAR的大小限制。它有兩個狀態。首先，整理并壓縮數據文件。然后，混淆壓縮文件讓它不能輕易被解壓縮。

整理數據文件：許多Windows編輯器用/n/r避開了新行。特別是在你從Excel導出數據的情況下。"/r"是多余的，既然"/n"是足夠來顯示新一行的。在換行前消除"/r"和不用的空白可以節省很多字節。
注意不是所有的文本編輯器都可以探測到"/r"；UltraEdit是有效的編輯器之一。如果數據文件很大，把它拆成幾個小的文件以便快速的搜尋。但謹記小的文本文件不像大的壓縮得那么高效。
•        壓縮數據文件：壓縮算法的選擇受到J2ME壓縮執行的可用性限制。盡管壓縮API已經與J2ME CDC（其目標是至少有2MB內存的設備）綁定，大部分目前的蜂窩電話設備僅僅支持CLDC和建立在其之上的MIDP標準。CLDC的最小內存要求是128KB。因此，開發者必須尋找第三方的庫或者寫自己的代碼。我發現了三個：　　　　　
o        利用zlib壓縮算法的JCraft壓縮庫。它是開源的，文檔良好，并且有大量跟隨者；但是，庫有點大。
o        Java4Ever有一個gzip (GNU zip)執行(3.27 KB)。它在ＬＧＰＬ的許可下，也是開源的。
o        我喜歡TinyLine的GZIPInputStream，因為它擴展了java.io.InputStream并且追隨了同樣的裝飾模式，作為另一個Java流類。它支持skip(), mark(),和其他基本I/O函數。工具的作者對問題的響應很迅速，并且庫的使用方法很直接：

InputStream in = getClass().getResourceAsStream(db);
in = new GZIPInputStream (in, 256);

有一個使用壓縮的弱點：解壓縮不可避免的增加了應用程序的內存覆蓋區。TinyLine沒有發布該庫需要的額外堆的大小，但是按我的測試，我必須增加我的堆大小35到40KB。一個MIDP應用最初運行在Palm Zire(2 MB)上，現在需要4MB的RAM（隨機存儲寄存器）來運行。這在輕微地增加所需地內存覆蓋區，對于大部分的應用程序和設備來說，不會讓人擔憂，但是還是推薦你們進行回朔測試。

壓縮只是防御的第一線；軟件盜賊仍可以輕易取得MIDP的JAR并利用正確的算法解壓縮數據文件。我門可以混淆一下已壓縮的數據文件。首先，我重命名數據文件為.res(或其他偽文件擴展名，如.xls或.mdb)，如此一來壓縮算法便不能輕易被發覺。然后，用UltraEdit在HEX模式下打開壓縮數據文件（或任何HEX編輯器），在壓縮文件開頭插入（不是覆蓋）N字節數（如#!wx）。
最后，我改變了I/O代碼，在讀GZIPInputStream之前跳過N個字節：

      InputStream in = getClass().getResourceAsStream(db);
         in.skip(N);
         in = new GZIPInputStream (in, 256);

我們跳過的N個字節變成了應用程序和數據文件之間的秘密代碼，修正過的壓縮數據文件是除了你的代碼之外的任何解壓縮軟件都無法識別的。當然了，一個意志堅定的電腦黑客可以反編譯類文件并通過混淆代碼費力的去尋找跳過的字節樹。但這種安全措施應該足夠阻止大部分的竊賊了。

移動設備能夠支持所有的J2SE API棧的日子也不遠了。但是那天到來之前，開發者們開發獨立的MIDP應用仍必須堅持不懈的與JAR的大小限制和數據文件安全性進行戰斗。本文的解決方法試圖改進這個問題。我承認它有點笨拙并費事；將來，我希望有一個工具可以利用來自動進行數據壓縮和混淆處理。

關于作者
Simon Ru 是Ebay的一個高級軟件工程師。他有六年多的開發java和J2EE應用的經驗。在2001年，他開始研究J2ME技術，是基于J2ME的六商業教育軟件項目的創造者。該軟件在Handango上有數千的下載次數。他是伯克利加州大學的研究生，是通過Sun認證的J2EE開發者。

資源
Tools to comPRess data using the gzip algorithm:
http://www.gzip.org/
Tools to compress and read data using the zlib algorithm:
http://www.jcraft.com/jzlib/
Library to read a gzip file using GZIPInputStream:
http://tinyline.com/download.html
Java4Ever:
http://www.java4ever.com/index.php?section=j2me&project=apime&menu=download&lang=
Over The Air User Initiated Provisioning 1.0:
http://java.sun.com/prodUCts/midp/OTAProvisioning-1.0.pdf
Lightweight crypto APIs for J2ME CDC:
http://www.bouncycastle.org/latest_releases.html
Optimizing MIDP size:
http://www.javaperformancetuning.com/tips/j2me.shtml
Security and Trust Services API for J2ME (JSR 177):
http://java.sun.com/products/satsa/
Handango:
http://www.handango.com/home.jsp?siteId=1

（出處：http://m.survivalescaperooms.com）

上一篇：一個JDBC連接池例子

下一篇：如何給Log4j配上數據庫連接池