2

In order to address some level of protection against reverse engineering or decompilation, I decided to move the important parts of my C# application including several xml resources into a native C++ DLL file based on the method described here for using resources in C++ programs and practice1 and practice2 for utilizing C++ DLL files in C# applications. Now i have two questions:

  1. Is this a proper approach for addressing the application protection against reverse engineering?
  2. W̶h̶a̶t̶ ̶i̶s̶ ̶t̶h̶e̶ ̶c̶o̶r̶r̶e̶c̶t̶ ̶w̶a̶y̶ ̶o̶f̶ ̶r̶e̶t̶u̶r̶n̶i̶n̶g̶ ̶t̶e̶x̶t̶ ̶c̶o̶n̶t̶e̶n̶t̶s̶ ̶i̶n̶ ̶C̶+̶+̶ ̶D̶L̶L̶ ̶f̶i̶l̶e̶s̶ ̶b̶a̶s̶e̶d̶ ̶o̶n̶ ̶p̶r̶a̶c̶t̶i̶c̶e̶1̶ ̶a̶n̶d̶ ̶p̶r̶a̶c̶t̶i̶c̶e̶2̶.̶ ̶I̶ ̶h̶a̶v̶e̶ ̶r̶e̶a̶d̶ ̶m̶a̶n̶a̶y̶ ̶s̶a̶m̶p̶l̶e̶s̶,̶ ̶b̶u̶t̶ ̶a̶l̶l̶ ̶o̶f̶ ̶t̶h̶o̶s̶e̶ ̶t̶h̶a̶t̶ ̶I̶ ̶r̶e̶a̶d̶ ̶h̶a̶d̶ ̶d̶e̶s̶c̶r̶i̶b̶e̶d̶ ̶b̶y̶ ̶u̶s̶i̶n̶g̶ ̶A̶d̶d̶/̶S̶u̶b̶t̶r̶a̶c̶t̶/̶M̶u̶l̶t̶i̶p̶l̶y̶/̶D̶e̶v̶i̶d̶e̶ ̶f̶u̶n̶c̶t̶i̶o̶n̶s̶.̶

Update: I skip the second question as might be coding question while the first one is a question about practice.

Community
  • 1
  • 1
utvecklare
  • 671
  • 1
  • 11
  • 25

1 Answers1

4

Placing text resources in a DLL is a technique of hiding resources, not protecting them. If the goal is to protect your resources against reverse engineering, this technique would qualify only as the lowest and the least effective measure of "security by obscurity," which provides no security against anyone with minimal amount of determination to hack your resources.

For any degree of real protection you need to use encryption, because encrypting your resources with a custom key would require much higher degree of sophistication from anyone trying to reverse-engineer your system. This wouldn't made it completely impossible to reverse-engineer your system, but it would do enough to discourage hackers with limited knowledge from messing around with your code.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • I don't get your point about encryption. The code, at run time, must be able to decrypt, right? – manuell Feb 20 '16 at 10:37
  • 1
    @manuell I agree with dasblinkenlight => your point is valid but it implies that the reversing engineer needs to have access not just to the dll but also a functioning system if you use runtime-provided decrypting password/certificate. Further, you can decrypt with a well-known runtime-provided native password in c++ which would be very hard, if not impossible, to revert. Of course, there is a significant performance overhead for such design so i would seriously weigh up the probability of someone reverse engineering the code - usually 'legal action' path is a lot cheaper. – zaitsman Feb 20 '16 at 10:43
  • @manuell Absolutely, the code would need to decrypt the resources before using them, so anyone with enough determination would be able to do the same. The goal of the exercise is not to make it impossible to hack (because it's always possible). The goal is to make it impractical to hack, because the effort required to do so greatly outweighs the benefit of obtaining access to the resource. – Sergey Kalinichenko Feb 20 '16 at 10:50
  • @dasblinkenlight I agree that this is the lowest and the least effective approach. But, by considering the importance of the application and users of this application, not sure if we and our customers have the experience of making this application complex and decompiled. I think about hiding important sections in a native C++ dll to prevent easy decompilation programs. Also, using checksums could be another way of making sure that this application has not modified. Unfortunately I don't have any experience on application encryption. Is there any simple example/tutorial on how to do this? – utvecklare Feb 20 '16 at 11:08
  • 1
    @utvecklare There is a difference between hiding the resource from viewing and making it hard to modify. Check sum will give you a decent protection against tampering with your resources. Using a strong hash is better, and it is only slightly more complex (look up SHA-256). Encryption is harder, but there are many resources available to make it manageable, even if you did not know much about it at first. For example, here is a [Q&A explaining how to encrypt and decrypt a string](http://stackoverflow.com/a/2791259/335858). – Sergey Kalinichenko Feb 20 '16 at 11:54
  • @dasblinkenlight Thanks for the further clarification. So one reliable way is to encrypt the hash of a resource. But still I don't have the whole picture. Imagine "challenge-response authentication" must be supported by a desktop client application with C#. How the method/class for creating the response should be implemented in the client application in way that be hard to be reverse-engineered? Is it true to say this method/class is a resource? – utvecklare Feb 22 '16 at 11:09
  • @utvecklare A method that implements response is not even a resource, it's generally code (unless you use a "canned response", i.e. a password, in which case it becomes a resource). Anyone with a debugger can reverse-engineer code, given sufficient time and a worthy incentive to do it. All you can do in software is to make it harder on them, to the point when they stop trying. – Sergey Kalinichenko Feb 22 '16 at 20:08