Re: Trying to build a copy protection system

Discussion in 'C++' started by Andrew Cooper, Aug 8, 2012.

  1. On 08/08/2012 21:10, jeff wrote:
    > I am trying to build a copy protection system where the user
    > authenticates to my server and the server sends a decryption key. Then
    > without writing the key to the hard drive I want to load an encrypted
    > executable in memory, decrypt it, leaving the decrypted form in memory
    > and run the executable from there.
    >
    > I cannot have the decrypted executable or the key ever written to the
    > hard drive because it is too easy for someone to get it from there. I
    > have the encryption and decryption working, I still need to get the
    > authentication system working which will probably be RADIUS since I do
    > not know anything else that would work because the authentication is not
    > custom built so I have either HTTP authentication or RADIUS
    > authentication. The RADIUS should be easy to setup I found several
    > libraries that have that I just have not gotten them to authenticate
    > properly yet. The biggest thing is being able to run the executable from
    > memory.
    >
    > Does anyone have any idea what to do for this? Any code examples to get
    > me started?


    Yes. Ditch it and forget you ever thought about implementing it.

    DRM is fundamentally flawed. It necessarily has to contain the
    decryption keys in memory, and necessarily has to decrypt the incoming
    content stream to be able to use it (whatever 'it' is). As a result, it
    is not hard for people to get at the unencrypted contents.

    Furthermore, in these modern days (of crisis and universal broo-ha-ha),
    all desktop operating systems employ paging as the primary form of
    memory management meaning that in general, there is nothing you can do
    to prevent any part of your memory space being written to disk.

    DRM does nothing useful in terms of protection from computer-literate
    people, and serves only to harm paying customers when inevitably there
    is a bug or your authentication server goes down.

    ~Andrew
     
    Andrew Cooper, Aug 8, 2012
    #1
    1. Advertising

  2. On 08/08/2012 22:09, jeff wrote:
    >
    >
    > On 08/08/2012 01:49 PM, Andrew Cooper wrote:
    >> On 08/08/2012 21:10, jeff wrote:
    >>> I am trying to build a copy protection system where the user
    >>> authenticates to my server and the server sends a decryption key. Then
    >>> without writing the key to the hard drive I want to load an encrypted
    >>> executable in memory, decrypt it, leaving the decrypted form in memory
    >>> and run the executable from there.
    >>>
    >>> I cannot have the decrypted executable or the key ever written to the
    >>> hard drive because it is too easy for someone to get it from there. I
    >>> have the encryption and decryption working, I still need to get the
    >>> authentication system working which will probably be RADIUS since I do
    >>> not know anything else that would work because the authentication is not
    >>> custom built so I have either HTTP authentication or RADIUS
    >>> authentication. The RADIUS should be easy to setup I found several
    >>> libraries that have that I just have not gotten them to authenticate
    >>> properly yet. The biggest thing is being able to run the executable from
    >>> memory.
    >>>
    >>> Does anyone have any idea what to do for this? Any code examples to get
    >>> me started?

    >>
    >> Yes. Ditch it and forget you ever thought about implementing it.
    >>
    >> DRM is fundamentally flawed. It necessarily has to contain the
    >> decryption keys in memory, and necessarily has to decrypt the incoming
    >> content stream to be able to use it (whatever 'it' is). As a result, it
    >> is not hard for people to get at the unencrypted contents.
    >>
    >> Furthermore, in these modern days (of crisis and universal broo-ha-ha),
    >> all desktop operating systems employ paging as the primary form of
    >> memory management meaning that in general, there is nothing you can do
    >> to prevent any part of your memory space being written to disk.
    >>
    >> DRM does nothing useful in terms of protection from computer-literate
    >> people, and serves only to harm paying customers when inevitably there
    >> is a bug or your authentication server goes down.
    >>
    >> ~Andrew

    >
    > Andrew,
    >
    > I know and understand all of that. It does not change that this system
    > will help prevent copying


    Then you clearly don't "know and understand all of that"

    > and it is going to be combined with other
    > methods that are already in place and prevent people from running
    > programs that will dump memory to disk.


    Who said anything about *needing* to dump the memory to disk to get at
    the keys/data? The simple fact that data is memory at all is enough to
    mean that it can be got at. With virtualisation, it is not hard to
    single-step an entire operating system with it being any-the-wiser.

    > Also as far as the paging is
    > concerned if the program is in the foreground it is not likely to be
    > written to a page file.


    Take this trivial example of getting your entire program written to
    disk. User comes along and tells the operating system to hibernate.

    Suddenly, the contents of memory is written to the swap file, and is
    trivial to analyse offline.

    >
    > In any case I need to get this figured out one way or another.


    You are clearly not listening to anything I have said. It is not possible.

    ~Andrew
     
    Andrew Cooper, Aug 8, 2012
    #2
    1. Advertising

  3. On 08/08/2012 23:11, jeff wrote:
    > On 08/08/2012 02:49 PM, Andrew Cooper wrote:
    >> On 08/08/2012 22:09, jeff wrote:
    >>>
    >>>
    >>> On 08/08/2012 01:49 PM, Andrew Cooper wrote:
    >>>> On 08/08/2012 21:10, jeff wrote:
    >>>>> I am trying to build a copy protection system where the user
    >>>>> authenticates to my server and the server sends a decryption key. Then
    >>>>> without writing the key to the hard drive I want to load an encrypted
    >>>>> executable in memory, decrypt it, leaving the decrypted form in memory
    >>>>> and run the executable from there.
    >>>>>
    >>>>> I cannot have the decrypted executable or the key ever written to the
    >>>>> hard drive because it is too easy for someone to get it from there. I
    >>>>> have the encryption and decryption working, I still need to get the
    >>>>> authentication system working which will probably be RADIUS since I do
    >>>>> not know anything else that would work because the authentication
    >>>>> is not
    >>>>> custom built so I have either HTTP authentication or RADIUS
    >>>>> authentication. The RADIUS should be easy to setup I found several
    >>>>> libraries that have that I just have not gotten them to authenticate
    >>>>> properly yet. The biggest thing is being able to run the executable
    >>>>> from
    >>>>> memory.
    >>>>>
    >>>>> Does anyone have any idea what to do for this? Any code examples to
    >>>>> get
    >>>>> me started?
    >>>>
    >>>> Yes. Ditch it and forget you ever thought about implementing it.
    >>>>
    >>>> DRM is fundamentally flawed. It necessarily has to contain the
    >>>> decryption keys in memory, and necessarily has to decrypt the incoming
    >>>> content stream to be able to use it (whatever 'it' is). As a result, it
    >>>> is not hard for people to get at the unencrypted contents.
    >>>>
    >>>> Furthermore, in these modern days (of crisis and universal broo-ha-ha),
    >>>> all desktop operating systems employ paging as the primary form of
    >>>> memory management meaning that in general, there is nothing you can do
    >>>> to prevent any part of your memory space being written to disk.
    >>>>
    >>>> DRM does nothing useful in terms of protection from computer-literate
    >>>> people, and serves only to harm paying customers when inevitably there
    >>>> is a bug or your authentication server goes down.
    >>>>
    >>>> ~Andrew
    >>>
    >>> Andrew,
    >>>
    >>> I know and understand all of that. It does not change that this system
    >>> will help prevent copying

    >>
    >> Then you clearly don't "know and understand all of that"
    >>
    >>> and it is going to be combined with other
    >>> methods that are already in place and prevent people from running
    >>> programs that will dump memory to disk.

    >>
    >> Who said anything about *needing* to dump the memory to disk to get at
    >> the keys/data? The simple fact that data is memory at all is enough to
    >> mean that it can be got at. With virtualisation, it is not hard to
    >> single-step an entire operating system with it being any-the-wiser.
    >>
    >>> Also as far as the paging is
    >>> concerned if the program is in the foreground it is not likely to be
    >>> written to a page file.

    >>
    >> Take this trivial example of getting your entire program written to
    >> disk. User comes along and tells the operating system to hibernate.
    >>
    >> Suddenly, the contents of memory is written to the swap file, and is
    >> trivial to analyse offline.
    >>
    >>>
    >>> In any case I need to get this figured out one way or another.

    >>
    >> You are clearly not listening to anything I have said. It is not
    >> possible.
    >>
    >> ~Andrew

    > Andrew,
    >
    > First off you never said anything about it not being possible. Second I
    > know it is possible because it is done all the time with DRM.


    I assumed that my first statement of "DRM is fundamentally flawed" was a
    good implication that it is impossible.

    Allow me to repeat myself. DRM is broken concept as far as copy
    protection goes. All it does is raise the barrier for entry. It is as
    good as "security through obscurity" when it comes to actually
    protecting things.

    >
    > As for what I said in my reply. Lets say there is a user who knows
    > basics of computers but does not really do any programming. They notice
    > an executable that is encrypted associated with the software and decide
    > that they do not want to keep entering a username and password each time
    > the program starts. Now if the executable gets written to the hard drive
    > after being decrypted they will be able to find it in a temp directory
    > somewhere and just copy it out of there. Then the have a chance at being
    > able to bypass the authentication and encryption. Now what if the
    > decrypted executable is never written to the hard drive, then they will
    > not be able to find it.


    The majority of users don't know what a temporary directory is, let
    alone where to find it. So you are going to extreme lengths to protect
    against a small minority of people? Seems like a waste of effort...

    >
    > About the virtualization example the other protection that I already
    > have in place detects that and will prevent the software from running
    > inside a virtual machine so that is not a problem.


    Hahaha. Here you are going to trust me; as a hypervisor and kernel
    developer by profession, believe me when I say that there is nothing at
    all your software can do to to detect a hypervisor which is trying to
    hide itself.

    The hypervisor has absolute control over when the guest OS gets to
    execute instructions, what times are reported, when interrupts occur
    etc. The reason virtualized environments are usually easy to spot is
    because there are many performance gains to be had that way, not because
    they are overly difficult to hide.

    >
    > For the hibernate I do not know if any protection that I currently have
    > is in place to prevent it but there are ways to prevent that with the
    > authentication by doing things like keeping the connection open and only
    > decrypting and running the executable when it is needed then clearing
    > the memory immediately after it finishes. so the key and the decrypted
    > executable are not sitting in memory.


    And here we have something known as a race condition. Which can lead to
    all sorts of fun and unexpected behaviour. Like for example still being
    able to get a complete dump of your programs RAM including keys and
    decrypted executables. All I would need to do is tell the operating system

    Unless you plan to rootkit the computer to prevent things like
    hibernation. You wouldn't be the first person to try this.

    http://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootkit_scandal

    >
    > Do not get me wrong. I know someone will find a way around this, but I
    > am trying to prevent is as much as possible and I want to have a way of
    > being notified if it does get broken which this authentication would
    > probably have something to do with that part even if it does not notify
    > me directly.


    So you have identified that you cant actually protect against someone
    determined to break the protection? In which case, what is the point?

    Furthermore, from your example a few posts ago, what are you going to do
    to prevent people sharing usernames/passwords, yet not be invalidated by
    someone upgrading their computer?

    I am half curious as to what it is you actually wish to protect with
    this scheme.

    ~Andrew
     
    Andrew Cooper, Aug 9, 2012
    #3
  4. Andrew Cooper

    Sjouke Burry Guest

    jeff <> wrote in
    news::

    > On 08/08/2012 07:29 PM, Sam wrote:
    >> jeff writes:
    >>
    >>> Do not get me wrong. I know someone will find a way around this, but

    I
    >>> am trying to prevent is as much as possible

    >>
    >> And it only takes one "someone", one person to do it, then it's game
    >> over. It's now on bit-torrent, accessible to the rest of the world.
    >>
    >>> and I want to have a way of being notified if it does get broken

    which
    >>> this authentication would probably have

    >>
    >> And I want to have a pony.
    >>
    >> Why do you believe that someone who will disable your crippleware,

    will
    >> leave untouched some other part of your crippleware, that phones home?
    >>
    >>> something to do with that part even if it does not notify me

    directly.
    >>
    >> You do not understand: trying to make bits uncopyable is like trying

    to
    >> make water not wet.
    >>

    >
    > Sam,
    >
    > Please do not respond if you do not know what you are talking about.
    > What I am doing has been done successfully many times, implementing
    > several different copy protection methods and phone home mechanisms in
    > different parts of the software has been proven many times to delay the
    > inevitable cracking and it has also proved to cause may problems for
    > people who try to crack it. Also if someone is cracking it they will
    > likely be looking in the place where the DRM is, not at another section
    > of code in a different file that is sending a simple ping to my server.
    >
    > I understand making it impossible to copy is not going to happen, but

    if
    > you will actually read what I have posted you will see that I am trying
    > to delay that as much as possible.
    >


    Writers of "PHONE HOME" software should be send to Alcatraz.
    I would rather trust a thief.
     
    Sjouke Burry, Aug 9, 2012
    #4
  5. Andrew Cooper

    Bo Persson Guest

    jeff wrote 2012-08-09 05:18:
    >What I am doing has been done successfully many times, implementing
    > several different copy protection methods and phone home mechanisms in
    > different parts of the software has been proven many times to delay the
    > inevitable cracking and it has also proved to cause may problems for
    > people who try to crack it. Also if someone is cracking it they will
    > likely be looking in the place where the DRM is, not at another section
    > of code in a different file that is sending a simple ping to my server.
    >


    Having several layers of copy protection will also introduce several
    possible points of failure, where a single false positive will piss off
    you REAL customers.

    You have two kinds of "customers" - those who don't buy it when it can
    be freely copied, and those who don't buy it when it cannot.

    Which category do you focus on?

    As an example, I work for a bank that ALWAYS pays for every license. We
    also have a high security network. I would be REALLY pissed if some
    software refused to run when our firewalls stopped it from calling home.


    Bo Persson
     
    Bo Persson, Aug 9, 2012
    #5
  6. Andrew Cooper

    Nobody Guest

    On Thu, 09 Aug 2012 08:43:05 +0200, David Brown wrote:

    > You can pretty much divide your users into four groups. First, there are
    > those who will pay honestly to use the software - these are the important
    > people. Then there are the people who would like to use your software,
    > but are unwilling to pay for it. The third group is those that are
    > experts (or at least reasonably knowledgeable) at cracking. The final
    > group is those that want to use it, and would be willing to pay for it if
    > they had to, but will happily use a cracked version if they can.


    You missed the fifth group: those will be willing to pay for it if it is
    of use to them, but not if it's unusable because the minimum level of
    security which they can accept for their systems exceeds the maximum level
    of security under which your program can run.

    E.g. if the program requires a "phone home" but their security policy
    prohibits connections outside the local network, or the program uses
    on-the-fly decryption of code but their systems have security features
    which prevent execution of dynamically-generated code.
     
    Nobody, Aug 12, 2012
    #6
  7. Andrew Cooper

    Dombo Guest

    Op 09-Aug-12 20:53, jeff schreef:

    > If you had read what I have posted before you would know that I have
    > The key thing to pick up here is not
    > that I am so concerned about piracy, I know it will happen and I know I
    > cannot stop it. I am more concerned about IP than anything else. If what
    > I do slows down the piracy then that is a bonus.


    I understand your desire to protect your software and your IP (which is
    entirely legitimate in my book). What I fail to understand is how
    encryption is going to help here. For someone motivated and skilled
    enough to reverse engineer the compiled C++ code (which is rather labor
    intensive, and at best yields some understanding how certain parts
    works, but nothing like the original source code), bypassing the
    encryption will be no problem at all.
     
    Dombo, Aug 12, 2012
    #7
  8. Andrew Cooper

    Robert Miles Guest

    On 8/8/2012 8:50 PM, jeff wrote:
    > On 08/08/2012 04:41 PM, Andrew Cooper wrote:
    >> On 08/08/2012 23:11, jeff wrote:
    >>> On 08/08/2012 02:49 PM, Andrew Cooper wrote:
    >>>> On 08/08/2012 22:09, jeff wrote:
    >>>>>
    >>>>>
    >>>>> On 08/08/2012 01:49 PM, Andrew Cooper wrote:
    >>>>>> On 08/08/2012 21:10, jeff wrote:

    [snip]
    >> So you have identified that you cant actually protect against someone
    >> determined to break the protection? In which case, what is the point?
    >>
    >> Furthermore, from your example a few posts ago, what are you going to do
    >> to prevent people sharing usernames/passwords, yet not be invalidated by
    >> someone upgrading their computer?
    >>
    >> I am half curious as to what it is you actually wish to protect with
    >> this scheme.
    >>
    >> ~Andrew

    >
    > The point as I have said twice before is to delay the inevitable as long
    > as possible. This delay will allow me to have a timeframe to make a
    > profit without competing with a free download. The way to prevent
    > sharing usernames/passwords involves a couple of different methods
    > including serial numbers from hardware and checking the source of the
    > login request. There are other things involved but I am not going into
    > specific details on all of the protections schemes on here.
    >
    > The software that is being protected is not for home users, it is
    > something that only large companies in a specific industry will have,
    > but in the industry as well as many others IP theft is a very big
    > problem hence me doing everything that I can to prevent it as long as
    > possible.


    So you aren't interested in the users being able to upgrade their
    computers to newer computers that happen to have different serial
    numbers, without losing their ability to use that software?
     
    Robert Miles, Sep 15, 2012
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nobody
    Replies:
    11
    Views:
    638
    Robert Miles
    Sep 15, 2012
  2. Replies:
    0
    Views:
    389
  3. Lynn McGuire
    Replies:
    2
    Views:
    433
    Lynn McGuire
    Aug 21, 2012
  4. Replies:
    1
    Views:
    343
    Pavel
    Sep 18, 2012
  5. Öö Tiib
    Replies:
    1
    Views:
    334
    Öö Tiib
    Aug 23, 2012
Loading...

Share This Page