文章詳情頁
深入Java字節碼加密
瀏覽:4日期:2024-07-01 11:20:39
內容: 問:如果我把我的class文件加密,在運行時用指定的類加載器(class loader)裝入并解密它,這樣子能防止被反編譯嗎?答:防止JAVA字節碼反編譯這個問題在java語言雛形期就有了,盡管市面上存在一些反編譯的工具可以利用,但是JAVA程序員還是不斷的努力尋找新的更有效的方法來保護他們的智慧結晶。在此,我將詳細給大家解釋這一直來在論壇上有爭議的話題。Class文件能被很輕松的重構生成JAVA源文件與最初JAVA字節碼的設計目的和商業交易有緊密地聯系。另外,JAVA字節碼被設計成簡潔、平臺獨立性、網絡靈活性,并且易于被字節碼解釋器和JIT (just-in-time)/HotSpot 編譯器所分析??梢郧宄亓私獬绦騿T的目的, Class文件要比JAVA源文件更易于分析。如果不能阻止被反編譯的話,至少可以通過一些方法來增加它的困難性。例如: 在一個分步編譯里,你可以打亂Class文件的數據以使其難讀或者難以被反編譯成正確的JAVA源文件,前者可以采用極端函數重載,后者用操作控制流建立控制結構使其難以恢復正常次序。有更多成功的商業困惑者采用這些或其他的技術來保護自己的代碼。不幸的是,哪種方法都必須改變JVM運行的代碼,并且許多用戶害怕這種轉化會給他們的程序帶來新的Bug。而且,方法和字段重命名會調用反射從而使程序停止工作,改變類和包的名字會破壞其他的JAVA APIS(JNDI, URL providers, etc),除了改變名字,如果字節碼偏移量和源代碼行數之間的關系改變了,在恢復這有異常的堆棧將很困難。于是就有了一些打亂JAVA源代碼的選項,但是這將從本質上導致一系列問題的產生。加密而不打亂 或許上述可能會使你問,假如我把字節碼加密而不是處理字節碼,并且JVM運行時自動將它解密并裝入類加載器,然后JVM運行解密后的字節碼文件,這樣就不會被反編譯了對嗎? 考慮到你是第一個提出這種想法的并且它又能正常運行,我表示遺憾和不幸,這種想法是錯誤的。下面是一個簡單的類編碼器: 為了闡明這種思想,我采用了一個實例和一個很通用的類加載器來運行它,該程序包括兩個類: public class Main{ public static void main (final String [] args) { System.out.println ('secret result = ' + MySecretClass.mySecretAlgorithm ()); }} // End of classpackage my.secret.code;import java.util.Random;public class MySecretClass{ /** * Guess what, the secret algorithm just uses a random number generator... */ public static int mySecretAlgorithm () { return (int) s_random.nextInt (); } private static final Random s_random = new Random (System.currentTimeMillis ());} // End of class我想通過加密相關的class文件并在運行期解密來隱藏my.secret.code.MySecretClass的執行。用下面這個工具可以達到效果(你可以到這里下載Resources):public class EncryptedClassLoader extends URLClassLoader{ public static void main (final String [] args) throws Exception { if ('-run'.equals (args [0]) && (args.length>= 3)) { // Create a custom loader that will use the current loader as // delegation parent: final ClassLoader appLoader = new EncryptedClassLoader (EncryptedClassLoader.class.getClassLoader (), new File (args [1])); // Thread context loader must be adjusted as well: Thread.currentThread ().setContextClassLoader (appLoader); final Class app = appLoader.loadClass (args [2]); final Method appmain = app.getMethod ('main', new Class [] {String [].class}); final String [] appargs = new String [args.length - 3]; System.arraycopy (args, 3, appargs, 0, appargs.length); appmain.invoke (null, new Object [] {appargs}); } else if ('-encrypt'.equals (args [0]) && (args.length>= 3)) { ... encrypt specified classes ... } else throw new IllegalArgumentException (USAGE); } /** * Overrides java.lang.ClassLoader.loadClass() to change the usual parent-child * delegation rules just enough to be able to 'snatch' application classes * from under system classloader's nose. */ public Class loadClass (final String name, final boolean resolve) throws ClassNotFoundException { if (TRACE) System.out.println ('loadClass (' + name + ', ' + resolve + ')'); Class c = null; // First, check if this class has already been defined by this classloader // instance: c = findLoadedClass (name); if (c == null) { Class parentsVersion = null; try { // This is slightly unorthodox: do a trial load via the // parent loader and note whether the parent delegated or not; // what this accomplishes is proper delegation for all core // and extension classes without my having to filter on class name: parentsVersion = getParent ().loadClass (name);if (parentsVersion.getClassLoader () != getParent ()) c = parentsVersion; } catch (ClassNotFoundException ignore) {} catch (ClassFormatError ignore) {} if (c == null) { try { // OK, either 'c' was loaded by the system (not the bootstrap // or extension) loader (in which case I want to ignore that // definition) or the parent failed altogether; either way I // attempt to define my own version: c = findClass (name); } catch (ClassNotFoundException ignore) { // If that failed, fall back on the parent's version // [which could be null at this point]: c = parentsVersion; } } } if (c == null) throw new ClassNotFoundException (name); if (resolve) resolveClass (c); return c; } /** * Overrides java.new.URLClassLoader.defineClass() to be able to call * crypt() before defining a class. */ protected Class findClass (final String name) throws ClassNotFoundException { if (TRACE) System.out.println ('findClass (' + name + ')'); // .class files are not guaranteed to be loadable as resources; // but if Sun's code does it, so perhaps can mine... final String classResource = name.replace ('.', '/') + '.class'; final URL classURL = getResource (classResource); if (classURL == null) throw new ClassNotFoundException (name); else { InputStream in = null; try { in = classURL.openStream (); final byte [] classBytes = readFully (in);// 'decrypt': crypt (classBytes); if (TRACE) System.out.println ('decrypted [' + name + ']');return defineClass (name, classBytes, 0, classBytes.length); } catch (IOException ioe) { throw new ClassNotFoundException (name); } finally { if (in != null) try { in.close (); } catch (Exception ignore) {} } } } /** * This classloader is only capable of custom loading from a single directory. */ private EncryptedClassLoader (final ClassLoader parent, final File classpath) throws MalformedURLException { super (new URL [] {classpath.toURL ()}, parent); if (parent == null) throw new IllegalArgumentException ('EncryptedClassLoader' + ' requires a non-null delegation parent'); } /** * De/encrypts binary data in a given byte array. Calling the method again * reverses the encryption. */ private static void crypt (final byte [] data) { for (int i = 8; i < data.length; ++ i) data [i] ^= 0x5A; } ... more helper methods ... } // End of class這個累加載器(EncryptedClassLoader)有兩個基本的操作,在給定的類路徑下加密一系列Class文件并且運行一個先前加密的程序。加密后的文件很簡單,有一些極討厭的各個字節的位組成。(當然,XOR運算符不可能被加密,這只是一個范例,請多多包涵。)通過EncryptedClassLoader來加載類需要注意一些問題,我實現的是繼承自java.net.URLClassLoader并且重載了loadClass()和defineClass()兩個方法來實現自己的兩個功能。一個是專心于JAVA 2 類加載器的委托規則并且在系統類加載器做之前先加載一個經加密過的類;二是在執行defineClass()之前立即調用crypt()方法,否則會執行URLClassLoader.findClass()。執行下面的語句:>javac -d bin src/*.java src/my/secret/code/*.java我把Main.class和MySecretClass.class進行了.加密:>java -cp bin EncryptedClassLoader -encrypt bin Main my.secret.code.MySecretClassencrypted [Main.class]encrypted [mysecretcodeMySecretClass.class]現在原先編譯的class文件已經被加密后的文件所替代了,如果我想運行原始類文件,需要使用EncryptedClassLoader來操作:>java -cp bin MainException in thread 'main' java.lang.ClassFormatError: Main (Illegal constant pool type) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:502) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java:250) at java.net.URLClassLoader.access$100(URLClassLoader.java:54) at java.net.URLClassLoader$1.run(URLClassLoader.java:193) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:186) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)>java -cp bin EncryptedClassLoader -run bin Maindecrypted Main decrypted [my.secret.code.MySecretClass]secret result = 1362768201現在可以確信,采用任何反編譯工具對加密后的Class文件都不會起作用的。現在添加一個可靠的密碼保護機制,把它打包成本地可執行文件,并且使其對外收費。這樣子可以嗎?當然不能這樣了。ClassLoader.defineClass():必然經過的接口 所有的類加載器必須經過明確地API把類定義傳遞到JVM里,這就需要java.lang.ClassLoader.defineClass()方法了。類加載器的API有多個這個方法的重載,但是所有的方法都會調用defineClass(String, byte[], int, int, ProtectionDomain),這是一個在經過一些簡單驗證后放入到JVM里的最終的方法。如果你想建立一個新的Class文件的話,這對于理解每個類加載器都會不可避免的調用該方法是很重要的。你只能在方法defineClass()里把一些單調的字節數組生成Class對象,并且我們猜測這些字節數組文件會包含一些文檔格式化(查看class文件格式規范well-document.d format)的未加密的class定義,通過攔截對該方法的所有調用可以很簡單的破壞這種加密模式,并且很方便的反編譯你感興趣的Class文件。做這種攔截并不困難,實際上破壞自己建立的保護模式比用工具更加迅速的。首先,我取得基于J2SDK的java.lang.ClassLoader源文件,并修改defineClass(String, byte[], int, int, ProtectionDomain)方法,在里面加入其他的類。正如下面:... c = defineClass0(name, b, off, len, protectionDomain); // Intercept classes defined by the system loader and its children: if (isAncestor (getSystemClassLoader ().getParent ())) { // Choose your own dump location here [use an absolute pathname]: final File parentDir = new File ('c:/TEMP/classes/'); File dump = new File (parentDir, name.replace ('.', File.separatorChar) + '[' + getClass ().getName () + '@' + Long.toHexString (System.identityHashCode (this)) + '].class'); dump.getParentFile ().mkdirs (); FileOutputStream out = null; try { out = new FileOutputStream (dump);out.write (b, off, len); } catch (IOException ioe) { ioe.printStackTrace (System.out); } finally { if (out != null) try { out.close (); } catch (Exception ignore) {} } } ...注意if里的語句可以過濾系統類加載器及其子類加載器,同樣在defineClass()方法可以正常工作的情況下才能載入類。很難以相信不只有一個類加載器實例加載一個類,可通過在文件名堆里面加入類加載器標志我還是最終把這一問題給解決了。:-)最后一步是用包含java.lang.ClassLoader類的可執行文件臨時替換由JRE使用的文件rt.jar,你也可以使用-Xbootclasspath/p選項。我再一次運行加密的程序,并恢復了所有的未加密的文件,這么說可以很容易的把.class文件正確的反編譯。我先聲明我并沒有用EncryptedClassLoader類的內部機制來完成此壯舉的。 在這里注意一點,假如我沒去使用一個系統類,我可以使用別的方法,比如自定義一個JVMPI代理來處理JVMPI_EVENT_CLASS_LOAD_HOOK事件。學習小結: 我希望你能對本文有所興趣,你必須認識到得很重要的一點是在購買市面上任何反編譯工具前要三思而行,除非JVM體系結構進行改革以支持class字節碼在本地能進行譯碼轉換,你才會更好的從傳統的困惑中走出來,上演一場字節碼的改革浪潮! 當然也有其他的更有效的方法:對類加載進行調試。盡可能地得到類加載的軌跡是很有價值的,特別是在類加載時你去捕獲異常情況下使用。因此,JAVA的誕生可能純粹是為了開源項目,當然,其他一些體系結構(如:。NET)也正在傾向于反編譯。目前我就說說這種思想了.matrix開源技術經Javaworld授權翻譯并發布.如果你對此文章有任何看法或建議,請到Matrix論壇發表您的意見.注明: 如果對matrix的翻譯文章系列感興趣,請點擊oreilly和javaworld文章翻譯計劃查看詳細情況您也可以點擊-javamen查看翻譯作者的詳細信息. Java, java, J2SE, j2se, J2EE, j2ee, J2ME, j2me, ejb, ejb3, JBOSS, jboss, spring, hibernate, jdo, struts, webwork, ajax, AJAX, mysql, MySQL, Oracle, Weblogic, Websphere, scjp, scjd
標簽:
Java
上一條:Java 中利用管道實現線程間的通訊下一條:創建Java中的線程池
相關文章:
排行榜
