科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道基础软件深入讨论JAVA字节码加密技术(1)

深入讨论JAVA字节码加密技术(1)

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

如果把的class文件加密,在运行时用指定的类加载器(class loader)装入并解密它,能防止被反编译吗?

作者:中国IT实验室 来源:中国IT实验室 2007年8月31日

关键字: 字节码 java

  • 评论
  • 分享微博
  • 分享邮件
   如果把的class文件加密,在运行时用指定的类加载器(class loader)装入并解密它,能防止被反编译吗?结论是防止JAVA字节码反编译这个问题在java语言雏形期就有了,尽管市面上存在一些反编译的工具可以利用,但是JAVA程序员还是不断的努力寻找新的更有效的方法来保护他们的智慧结晶。在此,我将详细给大家解释这一直来在论坛上有争议的话题。
  
    Class文件能被很轻松的重构生成JAVA源文件与最初JAVA字节码的设计目的和商业交易有紧密地联系。另外,JAVA字节码被设计成简洁、平台独立性、网络灵活性,并且易于被字节码解释器和JIT (just-in-time)/HotSpot 编译器所分析。可以清楚地了解程序员的目的, 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 class
  
  
  package 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 classesfrom 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;
   }
  
 
查看本文来源
    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章