1 2 3 Previous Next 39 Replies Latest reply: Feb 11, 2010 1:16 PM by jschellSomeoneStoleMyAlias RSS

    Change accessiblity of an already instantiated classes member variable

    843798
      Hi,

      currently I'm working on a protection system which will be able to protect ( encrypt ) on method level. This means you can select a method from a class which you want to protect and only this method will be protected from reverse engineering. I will try to describe how i do it....
      The bytecode from the selected method is cut out and saved somewhere. Instean of the original bytecode i patch a dispatcher gate stub in the method which is calling a static method with following parameters -> object array of original method parameters and the this instance of the class ( only if the method is non-static ). so far so good. where the protected method is called it jumps via dispatcher gate stub to a method which is doing following things:
      1. the original bytecode is loaded by identifying the caller via Reflection.getCallingClass(2); This returns a class object of the calling class. In my case it is the class where the original method was cut out. In case of a non static function i will have to do a few adjustments to the original code. For example i have to overwrite the this instance of newly created class by the instance passed to the dispatcher gate. That way i can access fields and members from the calling class without having to modify the original bytecode heavily. But, I know there still exists the accessibility problem, because i try to access maybe private fields or methods from a different class.
      My Idea now was to change the accessiblity off all private fields and members, then execute the method and afterwards reset it back to private again. So far thats my theory. But the problem is changing the visibility seems to have no effect to the already instanciated class with the protected method. After I changed the visibility to public each access to a private field triggers an IllegalAccessException, what implies that changing the visibility of an already instanciated class is not possible.

      Any hints what i do wrong or how i can solve the problem.

      Thank you in advance,
      bgnahm

      PS: Please no suggestions to use one of the known binary instrumentation frameworks instead. I know that they are able to do and what NOT. Its not an alternative for me. Thank you.
        • 1. Re: Change accessiblity of an already instantiated classes member variable
          843798
          bgnahm wrote:
          Hi,

          currently I'm working on a protection system which will be able to protect ( encrypt ) on method level. This means you can select a method from a class which you want to protect and only this method will be protected from reverse engineering.
          What stops me from running your code on a self-compile JVM which changed ClassLoader.defineClass() to simply dump the byte[] that's passed in? That way I've easily broken your entire "protection".

          Remember: if the user can run your code, he can also read your code. There's no way around this, unless you buy heavily into the TPM/SecureComputing platform (even then there's the possibility of leaks).
          • 2. Re: Change accessiblity of an already instantiated classes member variable
            843798
            You will not gain anything from it, than having a randomly generate class which only contains one single method from a class which can have 1000s of methods. You will be far, far away from rebuild a complete application that way, because you will have to manually fix the bytecode and all of it attributes for each single protected method.
            Good luck with that ;)

            Edited by: bgnahm on Feb 9, 2010 7:19 AM
            • 3. Re: Change accessiblity of an already instantiated classes member variable
              843798
              bgnahm wrote:
              You will not gain anything from it, than having a randomly generate class which only contains one single method from a class which can have 1000s of methods.
              Then I can go on and dump a stacktrace together with the bytecode and I'll have a pretty good idea which method you're trying to re-build.

              The point I was trying to make was that there is no way to hide the bytecode that is being executed, as long as it's executed on the users computer.

              You can make it somewhat harder to crack, but if your application is useful, it will be cracked anyway.

              And if your application is not useful, then no one will bother copying it no matter if you use obfuscation of any kind or not.
              • 4. Re: Change accessiblity of an already instantiated classes member variable
                843798
                Hehe. You obviously do not work in the DRM business or even in a security related area. I do for a well known company. Nobody said that this will be uncrackable and I totally agree with you that as long as code is executed in a certain environment you can crack it. But there is also one thing for sure: The more more work a cracker will have to invest in order to crack an application the less crackers have the motivation to do so. BTW, i do not develop that protection system for "my" application. Its a system for our customers and we have similar systems for different architectures like .Net, intel processor, arm and so on. This method will definitivly work ( coupled together with our hard or software key system ). We have experience in .NET and the success legitimates the effort we invest.
                Maybe one day you will face a application protected by our system. If it will happen tell me how long it took you ;)

                Nevertheless, this talk was far away from answer the above question...

                Regards,
                bgnahm
                • 5. Re: Change accessiblity of an already instantiated classes member variable
                  843798
                  bgnahm wrote:
                  ... the problem is changing the visibility seems to have no effect
                  After I changed the visibility to public each access to a private field triggers an IllegalAccessException, what implies that changing the visibility of an already instanciated class is not possible.

                  Any hints what i do wrong or how i can solve the problem.
                  You change visibility on a Method object or a Field object.
                  This change in visibility is only in effect when you use the visibility enhanced Method or Field object to reflectively access the underlying method or field.

                  The bytecode from the selected method is cut out and saved somewhere.
                  ...
                  1. the original bytecode is loaded by identifying the caller via Reflection.getCallingClass(2); This returns a class object of the calling class. In my case it is the class where the original method was cut out.
                  To get around this
                  what is to stop someone from reverse engineering that last part?
                  • 6. Re: Change accessiblity of an already instantiated classes member variable
                    843798
                    bgnahm wrote:
                    Hehe. You obviously do not work in the DRM business
                    Right.
                    or even in a security related area.
                    Wrong.

                    I know that if I wan't to make absolutely sure that my customers can't read my code, then I must not give them access to my code (not even in compiled form).
                    I do for a well known company. Nobody said that this will be uncrackable and I totally agree with you that as long as code is executed in a certain environment you can crack it. But there is also one thing for sure: The more more work a cracker will have to invest in order to crack an application the less crackers have the motivation to do so. BTW, i do not develop that protection system for "my" application. Its a system for our customers and we have similar systems for different architectures like .Net, intel processor, arm and so on. This method will definitivly work ( coupled together with our hard or software key system ). We have experience in .NET and the success legitimates the effort we invest.
                    All very well. While personally I don't think it's a good idea to go that path, it's perfectly valid to do it as long as you are aware of its limits. I was just trying to make sure that you knew those limits before you went there (remember: all I knew about you was that post).
                    Maybe one day you will face a application protected by our system. If it will happen tell me how long it took you ;)
                    I have no interest to break such a protection scheme. Usually it isn't legal and more often than not the results wouldn't be worth the invested time.
                    • 7. Re: Change accessiblity of an already instantiated classes member variable
                      843798
                      bgnahm wrote:
                      Nobody said that this will be uncrackable and I totally agree with you that as long as code is executed in a certain environment you can crack it. But there is also one thing for sure: The more more work a cracker will have to invest in order to crack an application the less crackers have the motivation to do so.
                      Regards,
                      bgnahm
                      And how do you define "more work". Unless missing something doesn't seem to be secure. Unless you have a different definition of security.
                      • 8. Re: Change accessiblity of an already instantiated classes member variable
                        843798
                        @tschodt: thank you for your answer. so what you mean is that i only change the class model in the vm and not the created instance itself, right ? If that is the case do you know any way to change the visibility of a method from an already created instance. Because thats more or less what i need. I hope there is a way. If not this will result in big design troubles for me...
                        To come to your question. Sorry but I'm sick of the discussions about "How will that prevent somebody from reverse engineering an application". I'm comming from the cracking szene in the early 90th, so i know the problem. But there are protections out which really kick ass and every measure is better than doing nothing. Nothing more to say...
                        • 9. Re: Change accessiblity of an already instantiated classes member variable
                          843798
                          >
                          I know that if I wan't to make absolutely sure that my customers can't read my code, then I must not give them access to my code (not even in compiled form).
                          BINGO!!!!!!
                          • 10. Re: Change accessiblity of an already instantiated classes member variable
                            843798
                            JoachimSauer wrote:
                            Maybe one day you will face a application protected by our system. If it will happen tell me how long it took you ;)
                            I have no interest to break such a protection scheme. Usually it isn't legal and more often than not the results wouldn't be worth the invested time.
                            A little correction for completeness sake: I would be interested in attempting to break such a protection out of curiosity, but the legal issues and my limited time makes it unlikely that I'll do so in the near future.
                            • 11. Re: Change accessiblity of an already instantiated classes member variable
                              843798
                              @JoachimSauer: There is no need to absolutely secure the code of a certain application. Because if you do so there is no need for a business at all. No application no business. Simple rule ;D Es geht nicht darum die perfekte Sicherheit zu schaffen, die gibt es nicht in einer Realität in der eine Applikation auch benutzt werden soll. Und jemandem zu verbieten einen Programmiersprache wegen ihrer Reverseability zu verwenden steht wohl auch nicht zur Debatte ;)
                              • 12. Re: Change accessiblity of an already instantiated classes member variable
                                843798
                                bgnahm wrote:
                                @JoachimSauer: There is no need to absolutely secure the code of a certain application.
                                Agreed.
                                Because if you do so there is no need for a business at all.
                                I can't follow that line of thought, sorry.
                                Es geht nicht darum die perfekte Sicherheit zu schaffen, die gibt es nicht in einer Realität in der eine Applikation auch benutzt werden soll.
                                Einfach: Web-Anwendungen können ohne weiteres genutzt werden ohne dass jemand den Code zu sehen bekommt.
                                • 13. Re: Change accessiblity of an already instantiated classes member variable
                                  843798
                                  @JoachimSauer: Ich habe mich da schlecht ausgedrückt...."in einer Realität in der nicht jede Applikation eine Web-Application ist und unser Kunden ihre Standalone-Applications schützen wollen." Ich hoffe damit wird das Problem klarer, wobei es hier wohl schon fast um eine "religiöse" Frage geht.
                                  • 14. Re: Change accessiblity of an already instantiated classes member variable
                                    843798
                                    bgnahm wrote:
                                    @JoachimSauer: Ich habe mich da schlecht ausgedrückt...."in einer Realität in der nicht jede Applikation eine Web-Application ist und unser Kunden ihre Standalone-Applications schützen wollen."
                                    I'll keep my answer english for the benefit of other readers ;-)

                                    I know. I'm aware of the problem and I know of the solutions (we even use obfuscation at my job).

                                    "Raising the clue barrier" can be useful, even when perfect security is not possible.

                                    My initial response was meant to ensure that you are aware of the limits of this approach (which you obviously are).
                                    Ich hoffe damit wird das Problem klarer, wobei es hier wohl schon fast um eine "religiöse" Frage geht.
                                    No problem, I'll let it rest from here on. As I said: personally I don't think this is the correct approach, but I won't stop anyone from trying it unless that someone thinks that he's able to achieve perfect security this way. Then I'll try to teach them the limits of this approach.
                                    1 2 3 Previous Next