OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Mar 27, 2017 8:30 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: Idea for copy protect
PostPosted: Tue Jan 10, 2017 11:36 am 
Offline
Member
Member
User avatar

Joined: Tue Aug 02, 2016 1:52 pm
Posts: 218
Location: East Riding of Yorkshire, UK
Schol-R-LEA wrote:
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.

Schol-R-LEA wrote:
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.

_________________
com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
Compiler Development Wiki
Compiler Development Forum


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Tue Jan 10, 2017 2:37 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 669
Location: Athens, GA
zenzizenzicube wrote:
Schol-R-LEA wrote:
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.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Tue Jan 10, 2017 3:54 pm 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 215
Location: San Jose San Francisco Bay Area
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)

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Tue Jan 10, 2017 5:18 pm 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 215
Location: San Jose San Francisco Bay Area
zenzizenzicube wrote:
Schol-R-LEA wrote:
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.

Schol-R-LEA wrote:
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.

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Tue Jan 10, 2017 6:19 pm 
Offline
Member
Member
User avatar

Joined: Wed Jul 13, 2011 7:38 pm
Posts: 486
Location: Victoria, Canada
Don't roll your own crypto.

Don't roll your own crypto.

_________________
The good thing about Unix is when it screws up, it does so very quickly.


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Tue Jan 10, 2017 6:39 pm 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 215
Location: San Jose San Francisco Bay Area
Kazinsal wrote:
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.

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Wed Jan 11, 2017 8:00 am 
Offline
Member
Member
User avatar

Joined: Thu Jul 12, 2012 7:29 am
Posts: 566
Location: Tallinn, Estonia
ggodw000 wrote:
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.

_________________
Learn to read.


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Wed Jan 11, 2017 8:02 am 
Offline
Member
Member
User avatar

Joined: Thu Jul 12, 2012 7:29 am
Posts: 566
Location: Tallinn, Estonia
ggodw000 wrote:
ok, please note that it is not software, it is the media content in question.


ok, so

ggodw000 wrote:
Message aka plain text=(

Storage medium serial No


Can be faked

ggodw000 wrote:
+ No. of blocks on the storage medium


Can be faked

ggodw000 wrote:
+ some password


Can be faked

ggodw000 wrote:
+ media file binary


The hell, we can even fake this one!

ggodw000 wrote:
+ some other optional artifacts etc.,)


Can be faked

_________________
Learn to read.


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Wed Jan 11, 2017 2:58 pm 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 215
Location: San Jose San Francisco Bay Area
dozniak wrote:
ggodw000 wrote:
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.

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Wed Jan 11, 2017 6:31 pm 
Offline
Member
Member
User avatar

Joined: Thu Jul 12, 2012 7:29 am
Posts: 566
Location: Tallinn, Estonia
ggodw000 wrote:
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

_________________
Learn to read.


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Wed Jan 11, 2017 7:52 pm 
Offline
Member
Member
User avatar

Joined: Sun Dec 25, 2016 1:54 am
Posts: 181
dozniak wrote:
ggodw000 wrote:
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...

_________________
Plagiarize. Plagiarize. Let not one line escape thine eyes...


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Thu Jan 12, 2017 2:29 am 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 215
Location: San Jose San Francisco Bay Area
dozniak wrote:
ggodw000 wrote:
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!

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Thu Jan 12, 2017 2:30 am 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 215
Location: San Jose San Francisco Bay Area
dchapiesky wrote:
dozniak wrote:
ggodw000 wrote:
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

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Thu Jan 12, 2017 10:30 am 
Offline
Member
Member
User avatar

Joined: Wed Jul 13, 2011 7:38 pm
Posts: 486
Location: Victoria, Canada
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!

_________________
The good thing about Unix is when it screws up, it does so very quickly.


Top
 Profile  
 
 Post subject: Re: Idea for copy protect
PostPosted: Thu Jan 12, 2017 10:58 am 
Offline
Member
Member
User avatar

Joined: Tue Aug 02, 2016 1:52 pm
Posts: 218
Location: East Riding of Yorkshire, UK
Kazinsal wrote:
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.

_________________
com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
Compiler Development Wiki
Compiler Development Forum


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group