How to protect decryption key from decompilation?

I am a beginner Java programmer. I am working on an application that decrypts some data. The decryption key is hardcoded into the software and, therefore, can be seen by analyzing the byte code.

I know that reverse engineering cannot be completely prevented, so I am trying to make this process as difficult as possible.

My idea is not to directly insert the key into my code, but through some kind of conversion. For example, I could write -

private static final byte[] HC256A = Hex .decode("8589075b0df3f6d82fc0c5425179b6a6" + "3465f053f2891f808b24744e18480b72" + "ec2792cdbf4dcfeb7769bf8dfa14aee4" + "7b4c50e8eaf3a9c8f506016c81697e32"); 

Thus, someone looking at a bytecode cannot read it right away. But you have to follow the logic and apply transformations to it, which will not be much easier at the byte level.

So what do you guys think? This is useful? What could be the best conversion other than hexagonal decoding? Are there any other ways to protect hard-coded decryption keys?

Thanks for all your suggestions.

+6
source share
3 answers

The correct way to attack such obfuscation (especially in bytecode languages) is to attach the debugger to the place where the key is transmitted (if debugging is not possible, start analyzing the code from this place). Thus, the attacker does not need to look for the key at all, and he does not care like a confused key. Therefore, you need to rethink your design.

If you want to protect against amateur lurkers, then dividing the key and XORing its parts (possibly using different keys) will be enough. Another trick is to get the key to the text constants already present in the code (for example, the name of the application). This makes the key less obvious than splitting or XORing.

+8
source

Do not enter the code in the source code at all. Keep it separate, send it separately, for example. in the Java keystore, and only for clients / sites / clients that you trust, and place a license in the license that imposes liability on them if they leak into the keystore.

+3
source

Faced with a similar problem (c), I went with XOR disposable pads. This is good because it looks like trash ... if you are really smart, you can snoop for this (wrong) key to use. I would avoid everything that introduced human-readable lines, since they invariably pay attention to this bit of code.

0
source

Source: https://habr.com/ru/post/888626/


All Articles