0

If I have a private key with which I sign byte code, and a public key with which I can decipher the signed code to verify its authenticity, can I protect that byte code from being reverse engineered and modified as follows:

  1. Built an abstract machine to interpret the byte code in plain text.
  2. Apply code generation techniques to this to be able to generate a unique machine for each end user, paired with a public key for that user, in such a way that the byte code machine verifies the byte code as each instruction is executed. That is, the verifier is woven into the machine.
  3. The bytecode interpreter itself is ofuscated in a non-reversible manner, using the petri-nets technique.
  4. Sign the bytecode for each user by encrypting it with the a secret key, unique to the user but not accessible to them.

Now the bytecode can easily be decrypted by each user with their key, but they do not posses a copy of the plain text machine to run it.

If users modify the code, they cannot sign it to run on the machine that they do have, since they do not possess the secret key needed to do this.

Perhaps this technique is already widely known and in use?

Please note, this question is not about whether this makes reverse engineering absolutely impossible, as I understand that no technique is ever going to be perfect and there are good reasons for that. I want to know whether this would be a practical deterrent and viable technique, have such techniques already been explored/discredited or is this considered a reasonably good one, relative to other protection techniques.

Improve this question
13
  • 6
    Any specific technique you use would still have to give your real users the ability to use the software. Once you've done that, you've given the cracker the ability to crack it.
    – Robert Harvey
    Commented Feb 13, 2015 at 15:53
  • 4
    @user2800708 And the answer to the general subject is "no". A sufficiently determined user can tamper with your abstract machine and remove the the verifier.
    – Doval
    Commented Feb 13, 2015 at 15:54
  • 1
    This is going to be dog slow, regardless. Your scheme still has a fundamental flaw of almost all other DRM attempts - you have to trust the end user to do the decryption, on a standardized machine. Taking your proposal at face value, I could just give my buddy the entire thing, key and all. Pirates also aren't generally interested in getting the source code, anyways (which is effectively impossible for compiled code), but something that runs - which your system has to provide, to be able to run on real, physical hardware.
    – Clockwork-Muse
    Commented Feb 13, 2015 at 15:55
  • 1
    "Prevent", no. Game consoles, which are quite locked down, do use various techniques that can delay reverse engineering for months or years. But this requires complete control of the hardware and of all applications that run on the hardware. And even then, one screwup and it's all over.
    – user53141
    Commented Feb 13, 2015 at 16:11
  • 2
    @user2800708 Just answering every question here is not what the site's about. Nor is it a full-time job for the people here. A consensus has been reached long ago whether it's theoretically possible to do this, arguing more is just like submitting a new model for a perpetual motion machine. They don't exist. We don't care about the details of your idea. Regarding your current question - if you can "obfuscate the byte-code interpreter in a non-reversible manner" then you can do just the same with the program you are trying to protect.
    – Ordous
    Commented Feb 13, 2015 at 16:43

1 Answer 1

Reset to default
1

No. There is nothing in your scheme that prevents a user from reverse engineering the bytecode interpreter and either (1) removing the verification steps or (2) changing the public key which must be encoded within it somehow to one they know the equivalent private key of.

Improve this answer
3
  • Ok, I'm adding some additional conditions on how the byte code interpreter itself is protected from RE.
    – user2800708
    Commented Feb 13, 2015 at 16:36
  • This achieves nothing as one can simply examine the behaviour of the interpreter with a correctly signed program and a modified one and identify the point of divergence, which can then be hard wired to follow the path it would take in a correctly signed program. Your scheme would also likely make the interpreter extremely slow, which would be a problem for most complex tasks. If your task isn't complex, it seems there would be little point protecting it, as reimplementation from scratch would be easier than reverse engineering such a system in any case.
    – Jules
    Commented Feb 15, 2015 at 11:24
  • I see; they descrypt the bytecode to plaintext (easy), then, run through the obfuscated machine, correct next point of divergence, repeat until done. What if there are hundreds or even thousands of points of divergence? Is there an easy way to automate correcting the points of divergence, or is this a huge amount of work for someone to do?
    – user2800708
    Commented Feb 16, 2015 at 9:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.