1 2 3 Previous Next 39 Replies Latest reply: Feb 11, 2010 1:16 PM by jschellSomeoneStoleMyAlias Go to original post RSS
      • 30. Re: Change accessiblity of an already instantiated classes member variable
        jschellSomeoneStoleMyAlias
        bgnahm wrote:
        jschell wrote:
        What do you mean "in the past"?

        I believe that has been possible since something like 1.3 or 1.4.
        I don't mean to set the system classloader via commandline switch -D. i mean setting it at runtime. till today there is no official way to set the system class loader ( which is instanciated at bootstrap time ). that what i meant it. it was not possible for me in the past. now i now how to set it, even if it is undocumented and not very stable.
        I doubt you can provide a link for the Sun VM that does anything like you claim. But feel free to provide such a link.
        • 31. Re: Change accessiblity of an already instantiated classes member variable
          843798
          bgnahm wrote:
          tschodt wrote:
          Reflective changes to accessibility do not have any impact on the actual class or any instances of the class.
          Maybe i get you wrong but i thought i already did it. The problem in the past was that there is no possibility to set an own system classloader. i took a look at the source of Classloader.java in the lang package. There was a private field Classloader sc;
          I change the accessibility of the that field and overwrote the systemclassloader with my own. And i think that there is no discussion about it that the SystemClassLoader was already instanciated, right ?
          But maybe i don't get the point. Sorry, but my english is not that good...
          Ah, you are talking about altering the
          private ClassLoader scl;
          field using reflection.
          The javadoc for [ClassLoader.getSystemClassLoader()|http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getSystemClassLoader%28%29] explains why you can just use
          -Djava.system.class.loader=...
          Yes, I can imagine your approach can cause problems.
          And what is to stop another method from doing exactly the same and replacing your nominated "system ClassLoader"?
          I think you should have a look at SecurityManager instead.
          • 32. Re: Change accessiblity of an already instantiated classes member variable
            843798
            tschodt wrote:
            Ah, you are talking about altering the
            private ClassLoader scl;
            field using reflection.
            The javadoc for [ClassLoader.getSystemClassLoader()|http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getSystemClassLoader%28%29] explains why you can just use
            -Djava.system.class.loader=...
            Yes, I can imagine your approach can cause problems.
            Yes, thats what I do. Due to the reason that it was not very stable we don't use that approach anymore. Moreover luckily it is not longer necessary with the method level approach.
            And what is to stop another method from doing exactly the same and replacing your nominated "system ClassLoader"?
            Nothing. But that is always that problem in the security business. If i hook a function someone else can hook my hooker and so on and so on...
            I have to weight between effort and level of security and performance. Not an easy decision!
            I think you should have a look at SecurityManager instead.
            I played around with the SecurityManager and from my Point of View it is also not difficult to circumvent it. Usually we try to find non-standard ways to reach our goal in order to confuse attackers when they start anlysing a protected application. Using the offical possibilities is not so smart because this is the first place to check for an attacker. That approach paid out so far...

            Regards,
            bgnahm
            • 33. Re: Change accessiblity of an already instantiated classes member variable
              843798
              jschell wrote:

              That is pretty non-sensical. Especially since the same is true for the solution you are discussing now.

              You can't encrypt everything. So you put non-encrypted proxies in place and you only support access via those. Any attempts around that fail and are not your problem. The proxies handle the decryption.
              It seems that you don't understand the difference between dump a class from the vm to disc and dump a single method to disc. Both is for sure possible and in the first scenario dumping will result in a full functional class with all of its methods. But dumping a randomly generated containing a single method will result in a "randomly generated class containing a single method" WITHOUT any link to the original program because there is no statical link inside the original class to the randomly generated class. You will have to rebuild a few things. Therefore you will have to code rebuilder tools and so on and so on. I hope now you get the difference between both approachess. Dumping a class is not cracking an application. Hopefully this is clear now, seems that some of the discussion participants cannot differentiate between that...
              our new method level encryption does not have theses disadvantages at all no special class loader needed.
              That makes it easy - what you are suggesting is impossible. The last part of your assertion makes it impossible.

              Any VM that meets the specs must verify the class. It can't verify your encrypted mess. It can't load it. So there is no way for the VM to see it unless a class loader is involved.
              I don't know if my english is that bad, but you got it completly wrong. When I say that method level encryption has not these disadvantages then i want to say that i don't need a own classloader to implement the protection. We simply replace the original method body by a dispatcher gate jump stub. wenn the original method is call the dispatcher gate is called. the dispatcher gate is constructing a complete new class which only contain a default constructor and one single method which holds the original byte code. the bytecode of the method remains as long encrypted on disc as the randomly generated class is not loaded. the next advantage is that we don't need to intercept the classloader chain because the method is calling our dispatcher.
              Not if you want to handle reflection inside it isn't.
              Don't get you here...
              • 34. Re: Change accessiblity of an already instantiated classes member variable
                843798
                jschell wrote:
                bgnahm wrote:
                jschell wrote:
                What do you mean "in the past"?

                I believe that has been possible since something like 1.3 or 1.4.
                I don't mean to set the system classloader via commandline switch -D. i mean setting it at runtime. till today there is no official way to set the system class loader ( which is instanciated at bootstrap time ). that what i meant it. it was not possible for me in the past. now i now how to set it, even if it is undocumented and not very stable.
                I doubt you can provide a link for the Sun VM that does anything like you claim. But feel free to provide such a link.
                Obviously i cannot provide a link, because it is not an official way to overwrite the system class loader. Maybe I'm the first person tried that, I really don't know. Anyway for what do you need a link try it by your own.
                As i said the fields name is "scl". It private ot type ClassLoader and located in the ClassLoader.class. If you know what you are talking about try it by yourself. You will see that it work. Nothing more to say here...
                • 35. Re: Change accessiblity of an already instantiated classes member variable
                  843798
                  bgnahm wrote:
                  tschodt wrote:
                  Ah, you are talking about altering the
                  private ClassLoader scl;
                  field using reflection.
                  The javadoc for [ClassLoader.getSystemClassLoader()|http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getSystemClassLoader%28%29] explains why you can just use
                  -Djava.system.class.loader=...
                  Yes, I can imagine your approach can cause problems.
                  Yes, that's what I -do- initially did. Due to the reason that it was not very stable we don't use that approach anymore. Moreover luckily it is not longer necessary with the method level approach.
                  Not sure what you are doing now, I don't really care much and you probably want to keep it a well guarded secret.

                  I think the root issue is that you do not quite understand what Java security is supposed to do.
                  Java security is there to protect the user from inadvertently executing code from rogue classes,
                  it is not there to protect a class from being reverse engineered.

                  The best way of guarding your code from being reverse engineered is to put your business logic classes on a server.
                  Give the users a thin client with a user interface
                  and have that thin client connect to your server, feed it some input and get back some output that can be displayed to the user.
                  Notice how at no point did your business logic classes become directly exposed to the user.
                  • 36. Re: Change accessiblity of an already instantiated classes member variable
                    jschellSomeoneStoleMyAlias
                    bgnahm wrote:
                    jschell wrote:
                    bgnahm wrote:
                    jschell wrote:
                    What do you mean "in the past"?

                    I believe that has been possible since something like 1.3 or 1.4.
                    I don't mean to set the system classloader via commandline switch -D. i mean setting it at runtime. till today there is no official way to set the system class loader ( which is instanciated at bootstrap time ). that what i meant it. it was not possible for me in the past. now i now how to set it, even if it is undocumented and not very stable.
                    I doubt you can provide a link for the Sun VM that does anything like you claim. But feel free to provide such a link.
                    Obviously i cannot provide a link, because it is not an official way to overwrite the system class loader. Maybe I'm the first person tried that, I really don't know. Anyway for what do you need a link try it by your own.
                    As i said the fields name is "scl". It private ot type ClassLoader and located in the ClassLoader.class. If you know what you are talking about try it by yourself. You will see that it work. Nothing more to say here...
                    Your position is that you have your class X which changes that. How does your class X get loaded?
                    • 37. Re: Change accessiblity of an already instantiated classes member variable
                      843798
                      jschell wrote:
                      bgnahm wrote:
                      jschell wrote:
                      bgnahm wrote:
                      jschell wrote:
                      What do you mean "in the past"?

                      I believe that has been possible since something like 1.3 or 1.4.
                      I don't mean to set the system classloader via commandline switch -D. i mean setting it at runtime. till today there is no official way to set the system class loader ( which is instanciated at bootstrap time ). that what i meant it. it was not possible for me in the past. now i now how to set it, even if it is undocumented and not very stable.
                      I doubt you can provide a link for the Sun VM that does anything like you claim. But feel free to provide such a link.
                      Obviously i cannot provide a link, because it is not an official way to overwrite the system class loader. Maybe I'm the first person tried that, I really don't know. Anyway for what do you need a link try it by your own.
                      As i said the fields name is "scl". It private ot type ClassLoader and located in the ClassLoader.class. If you know what you are talking about try it by yourself. You will see that it work. Nothing more to say here...
                      Your position is that you have your class X which changes that. How does your class X get loaded?
                      If you mean MyCustomSystemClassLoader as class x then it is loaded with the original version of the systemclassloader. After overwriting the original scl instance my custom classloader is used for each new instance instanciated but any classloader or even by reflection.
                      • 38. Re: Change accessiblity of an already instantiated classes member variable
                        jschellSomeoneStoleMyAlias
                        bgnahm wrote:
                        I don't know if my english is that bad, but you got it completly wrong. When I say that method level encryption has not these disadvantages then i want to say that i don't need a own classloader to implement the protection. We simply replace the original method body by a dispatcher gate jump stub. wenn the original method is call the dispatcher gate is called. the dispatcher gate is constructing a complete new class which only contain a default constructor and one single method which holds the original byte code. the bytecode of the method remains as long encrypted on disc as the randomly generated class is not loaded. the next advantage is that we don't need to intercept the classloader chain because the method is calling our dispatcher.
                        Solution 1 - So in one case you have
                        1. Classloader X, note that this is in fact a class
                        2. Class M encrypted somewhere
                        3. X loads M, decrypts it, hands it off to the VM.
                        4. Since X is a class loader then the VM accepts M.

                        Solution 2 - In your case you have
                        1. Class Y, not a class loader, but still a class
                        2. Class M encrypted somewhere (and you just said above that it is a class.)
                        3. Class Y reads M, decrypts it into a class structure. Call the decrypted representation S.
                        4. Now what?

                        Now S must be loaded into the VM by a class loader. So please explain how you think that you are going to inject S into the VM without a custom class loader?

                        Also explain how you think Solution 1 is substantially different than Solution 2. Both have a class that decrypts an external class (again that is what you said above.)
                        • 39. Re: Change accessiblity of an already instantiated classes member variable
                          jschellSomeoneStoleMyAlias
                          bgnahm wrote:
                          After overwriting the original scl instance my custom classloader is used for each new instance instanciated but any classloader or even by reflection.
                          And you have actually tested this? You replaced it and then verified in such a way that the only possible loading mechanism could have been via your replacement?

                          If yes then explain the verification mechanism you used to insure that it was your class that actually did the loading (checking the variable itself is not sufficient.)
                          1 2 3 Previous Next