Idea for copy protect

[matt11235]

at worst the potential customer would use something else if they couldn't do what they wanted with your software, at best casual copying would spread the use of the program and actually lead to an increase in sales - and the ones which are losses can't be prevented by any means other than not writing the program in the first place.

This is definitely true, Notch/the Minecraft developer has a few good points on this too.

and have the software only download the parts actually in use at a given time, keeping the code sections in a LRU cache and never providing the whole program at any given time; and second, encrypt the object files or bytecode when not in use. It will slow the software down (though not as much as you might think), but it will at least fulfill your brief.

I have tried this before because it seemed like a good idea, but it's always possible for people to dump the code while it's running.

[Schol-R-LEA]

and have the software only download the parts actually in use at a given time, keeping the code sections in a LRU cache and never providing the whole program at any given time; and second, encrypt the object files or bytecode when not in use. It will slow the software down (though not as much as you might think), but it will at least fulfill your brief.

I have tried this before because it seemed like a good idea, but it's always possible for people to dump the code while it's running.

That is true, and a genuine concern. TBH, I mainly added that because a) it has other advantages (at least with the sort of design I have in mind for Kether, where 'applications' are actually swarms of individual tools joined by the system - whether the advantages in question would apply here isn't wholly clear), and b) it sounded as if this was something @ggodw000 doing primarily to fulfill a contractual obligation, in which case the only other realistic alternative is to leave the job (or drop the client, as the case may be). This would at least be somewhat more technically challenging to overcome than most other approaches, though it is not foolproof, of course.

[ggodw000]

Ok here is the plan I came up with, will it work?

Message aka plain text=(Storage medium serial No + No. of blocks on the storage medium + some password + media file binary + some other optional artifacts etc.,)

1.
When creating media content:
Hash(plain text) = message digest.
Enc(Hash(plain text) = signature (encrypt with private key).

2.
Store private key on cold storage, do not ever lose it.
For every legitimate copies, re-generate private keys from seed.

3.
When playing media content:
Dec(signature) => generates Hash1 (decrypt with public key) - always generates same hash value.
Rehash(plain text) => generates Hash2 - if copied to different medium, file is corrupted or damaged, will generate different hash value. If file residing on original legitimate storage, will generate same hash.

If hash1==hash2 (OK, play the media, it is on original storage medium)
If hash1!=hash2 (do not play, it is copied to another medium)

[ggodw000]

at worst the potential customer would use something else if they couldn't do what they wanted with your software, at best casual copying would spread the use of the program and actually lead to an increase in sales - and the ones which are losses can't be prevented by any means other than not writing the program in the first place.

This is definitely true, Notch/the Minecraft developer has a few good points on this too.

and have the software only download the parts actually in use at a given time, keeping the code sections in a LRU cache and never providing the whole program at any given time; and second, encrypt the object files or bytecode when not in use. It will slow the software down (though not as much as you might think), but it will at least fulfill your brief.

I have tried this before because it seemed like a good idea, but it's always possible for people to dump the code while it's running.

ok, please note that it is not software, it is the media content in question.

[Kazinsal]

Don't roll your own crypto.

Don't roll your own crypto.

[ggodw000]

Don't roll your own crypto.

Don't roll your own crypto.

Thanks, googled it lot of info.
However many of 'em appears to referring to rolling your own algorithm which obviously not going to happen. Will use popular, hardened algorithm i.e. sha for hashing and RSA-256 or similar for encrypting.

What is concerned here is protocol and whether it can be breached.

[dozniak]

What is concerned here is protocol and whether it can be breached.

Yes, of course it can.

You're speaking about ONE check if hash1==hash2, at exactly that point replace the conditional jump with unconditional and you're done. Patch size will be either 1 or 5 bytes depending on the check.

Here you go, your "protection" gone poof.

[dozniak]

ok, please note that it is not software, it is the media content in question.

ok, so

Message aka plain text=(

Storage medium serial No

Can be faked

+ No. of blocks on the storage medium

Can be faked

+ some password

Can be faked

+ media file binary

The hell, we can even fake this one!

+ some other optional artifacts etc.,)

Can be faked

[ggodw000]

What is concerned here is protocol and whether it can be breached.

Yes, of course it can.

You're speaking about ONE check if hash1==hash2, at exactly that point replace the conditional jump with unconditional and you're done. Patch size will be either 1 or 5 bytes depending on the check.

Here you go, your "protection" gone poof.

yes it is good point, the OP is basic framework. For hash1==hash2, it can be made to be complicated to make disassmbly harder. Also note that i am not planning like like nuclear switch security grade things, something that make it harder to breach.

I am contemplating something like following:

option 1: convoluted code with multiple check points:

if hash1[0:N] == hash2[0:N]
do bunch of other stuff, decompress part of file etc., sheer enough code to discourage disassembly
if hash1[N+1:N+2N] == hash2[N+1:N+2N]
do bunch of other stuff, sheer enough code to discourage further disassembly,
further repeated checks.

option2:
hide validation code by performing simple encryption so that it can not be a disassembled.
during runtime: do a simple decryption so validation code only exist in memory in its unencrypted forum. Of course it is not safe but more work for diassembler.

[dozniak]

option 1: convoluted code with multiple check points:

if hash1[0:N] == hash2[0:N]
do bunch of other stuff, decompress part of file etc., sheer enough code to discourage disassembly
if hash1[N+1:N+2N] == hash2[N+1:N+2N]
do bunch of other stuff, sheer enough code to discourage further disassembly,
further repeated checks.

option2:
hide validation code by performing simple encryption so that it can not be a disassembled.
during runtime: do a simple decryption so validation code only exist in memory in its unencrypted forum. Of course it is not safe but more work for diassembler.

Do you understand that Skype used option 2 and is now completely fully disassembled once people figured out this logic in the code? It only takes one OCD guy with enough time on his hands.

Do you realize that tools like reverse-analysers can take your convoluted machine code, convert it back to annotated AST representation of assembly code (using symbolic execution) and then reconstruct the entire "obfuscation" logic almost entirely automatically?

I.e. see work from https://www.blackhat.com/docs/eu-16/mat ... oaches.pdf

[dchapiesky]

option 1: convoluted code with multiple check points:

if hash1[0:N] == hash2[0:N]
do bunch of other stuff, decompress part of file etc., sheer enough code to discourage disassembly
if hash1[N+1:N+2N] == hash2[N+1:N+2N]
do bunch of other stuff, sheer enough code to discourage further disassembly,
further repeated checks.

option2:
hide validation code by performing simple encryption so that it can not be a disassembled.
during runtime: do a simple decryption so validation code only exist in memory in its unencrypted forum. Of course it is not safe but more work for diassembler.

Do you understand that Skype used option 2 and is now completely fully disassembled once people figured out this logic in the code? It only takes one OCD guy with enough time on his hands.

Do you realize that tools like reverse-analysers can take your convoluted machine code, convert it back to annotated AST representation of assembly code (using symbolic execution) and then reconstruct the entire "obfuscation" logic almost entirely automatically?

I.e. see work from https://www.blackhat.com/docs/eu-16/mat ... oaches.pdf

+1 on what dozniak said.

Intel addresses the issue of option2 by attempting to encrypt the memory transport outside the cpu chip - Intel SGX - however there is still the problem of actually setting up a secure "enclave" as they call it and delivering your secret encrypted code into it so it can be decrypted & executed all while having memory accesses encrypted by SGX.... it is a crap shoot.

Now, if you have enough juice with Intel... you could have them encrypt your code using their LZH dictionary and run your code directly in the Intel Management Unit in every Intel chip since 2010...

[ggodw000]

option 1: convoluted code with multiple check points:

if hash1[0:N] == hash2[0:N]
do bunch of other stuff, decompress part of file etc., sheer enough code to discourage disassembly
if hash1[N+1:N+2N] == hash2[N+1:N+2N]
do bunch of other stuff, sheer enough code to discourage further disassembly,
further repeated checks.

option2:
hide validation code by performing simple encryption so that it can not be a disassembled.
during runtime: do a simple decryption so validation code only exist in memory in its unencrypted forum. Of course it is not safe but more work for diassembler.

Do you understand that Skype used option 2 and is now completely fully disassembled once people figured out this logic in the code? It only takes one OCD guy with enough time on his hands.

Do you realize that tools like reverse-analysers can take your convoluted machine code, convert it back to annotated AST representation of assembly code (using symbolic execution) and then reconstruct the entire "obfuscation" logic almost entirely automatically?

I.e. see work from https://www.blackhat.com/docs/eu-16/mat ... oaches.pdf

1. if it involves PhD level student to involvement to do the reverse engineering, the mission accomplished
2. any youtube video, I am going to study this pdf file. Thanks!

[ggodw000]

option 1: convoluted code with multiple check points:

if hash1[0:N] == hash2[0:N]
do bunch of other stuff, decompress part of file etc., sheer enough code to discourage disassembly
if hash1[N+1:N+2N] == hash2[N+1:N+2N]
do bunch of other stuff, sheer enough code to discourage further disassembly,
further repeated checks.

option2:
hide validation code by performing simple encryption so that it can not be a disassembled.
during runtime: do a simple decryption so validation code only exist in memory in its unencrypted forum. Of course it is not safe but more work for diassembler.

Do you understand that Skype used option 2 and is now completely fully disassembled once people figured out this logic in the code? It only takes one OCD guy with enough time on his hands.

Do you realize that tools like reverse-analysers can take your convoluted machine code, convert it back to annotated AST representation of assembly code (using symbolic execution) and then reconstruct the entire "obfuscation" logic almost entirely automatically?

I.e. see work from https://www.blackhat.com/docs/eu-16/mat ... oaches.pdf

+1 on what dozniak said.

Intel addresses the issue of option2 by attempting to encrypt the memory transport outside the cpu chip - Intel SGX - however there is still the problem of actually setting up a secure "enclave" as they call it and delivering your secret encrypted code into it so it can be decrypted & executed all while having memory accesses encrypted by SGX.... it is a crap shoot.

Now, if you have enough juice with Intel... you could have them encrypt your code using their LZH dictionary and run your code directly in the Intel Management Unit in every Intel chip since 2010...

Few days ago, I got this AMD developer white paper regarding in memory protection. And it turned out it has been since 2009 ARM cortex a5 time!

http://developer.amd.com/wordpress/medi ... Public.pdf

[Kazinsal]

If you want to really get some good copy protection going, go hire the guys who did the copy protection on Earthbound. There's still bits of it that we don't know what they do!

[matt11235]

If you want to really get some good copy protection going, go hire the guys who did the copy protection on Earthbound. There's still bits of it that we don't know what they do!

That's a really interesting read. A more modern example might be Denuvo (used in the new DOOM game, Just Cause and a few others). It took pirates quite a while to get around it.