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?

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

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, 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. 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.

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

jeff <thexder1@gmail.com> wrote in
news:VLidnawCrJzFS7_NnZ2dnUVZ5jadnZ2d@giganews.com: 

> 
> I know and understand all of that. It does not change that this system
> will help prevent copying, 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. 

Could you let us know what programs/methods/systems these are so we could 
best avoid them?

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

This still has nothing to do with C++.
 

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

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.

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.

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.

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.

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.

On 08/08/2012 02:49 PM, Paavo Helde wrote:
> jeff<thexder1@gmail.com>  wrote in
> news:VLidnawCrJzFS7_NnZ2dnUVZ5jadnZ2d@giganews.com:
>
>>
>> I know and understand all of that. It does not change that this system
>> will help prevent copying, 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.
>
> Could you let us know what programs/methods/systems these are so we could
> best avoid them?
>
>>
>> In any case I need to get this figured out one way or another.
>
> This still has nothing to do with C++.
>
>

Paavo,

I have two different DRM schemes implemented right now which limits the 
environments where the software can be run in. I am not going to go into 
details on it but it is in place and it works.

The reason I posted here is because the software uses mostly C++ and I 
thought that C++ would be the best language to use for something like 
this without getting too complicated. So I am looking for a C++ method 
to accomplish this task.

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

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:
>>>>>> 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.
>
Ok you obviously know nothing of what you are talking about, I have read 
several articles on it from security professionals who have developed 
ways to detect running inside a virtual machine. It is actually pretty 
simple because with the modern virtualization that is built into the 
processors you can access the hardware and through that detect the 
presence of a hypervisor.

Based on what you said above I know that I would not trust you with 
anything that is supposed to be secure because you claim to know about 
this but at the same time you are completely wrong about it. Very 
dangerous combination especially when it comes to security.

If you do not believe me I suggest you look up blue pill detection.
>>
>> 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
>

For this as I have said twice before the system in place detects 
software that will do things like dump RAM and will not allow the 
program to start if that exists. I am done repeating myself on this.

>>
>> 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

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.

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_monster.email-scan.com-12950-1344479372-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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.


--=_monster.email-scan.com-12950-1344479372-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlAjIIwACgkQx9p3GYHlUOLgNQCdGbtvCKQIMpOj13f/K1IvXzBS
SbkAn26WVHkTrs65HyruDNm5ZnzmwYFO
=Ppzp
-----END PGP SIGNATURE-----

--=_monster.email-scan.com-12950-1344479372-0001--

On Wed, 08 Aug 2012 13:10:32 -0700, 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.

Any information which could possibly be of use to you is OS-specific, so
you'd be better off asking on a group dedicated to your target OS.

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.

On 08/08/2012 07:54 PM, Nobody wrote:
> On Wed, 08 Aug 2012 13:10:32 -0700, 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.
>
> Any information which could possibly be of use to you is OS-specific, so
> you'd be better off asking on a group dedicated to your target OS.
>


Thanks, finally someone actually provides an answer instead of just 
saying that the effort is futile. Well last time I ever consider posting 
in this group since it seems no one is interested in providing answers, 
and instead just wants to criticize what I am trying to do.

On 09/08/2012 00: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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.

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.

A DRM system like you suggest will annoy the first group of real, paying 
users.  Requiring a user name and password is perhaps not too bad 
(depending on the type of software), but things like tricks to block 
running in a virtual machine, or otherwise limiting the users' 
environment, are right off.  So your plan works directly against the 
only important people - the customers that pay your wages.

The second group can be pretty much ignored.  They were never going to 
provide you with any income anyway.  Just make sure they don't take any 
resources (such as by making write-access to your support forums 
dependent on registration - but keep read-access open).  Then you treat 
them as extra beta testers and cheap advertising.

The third group are a risk.  But you won't stop them, no matter how hard 
you try.  They are smarter at you, have more experience than you, and 
cooperate better with other crackers.  If your software is popular, 
cracks /will/ appear on the internet, letting anyone use it for free. 
If it is more niche, but expensive, then cracks /will/ appear on the 
more specialised underground sites, where people can get the software 
for a small fee.  This is inevitable, and any believe you might have 
that you can stop it is illusionary.  Accept that this will happen and 
move on.

The forth group are the other important group - these are the people 
that are potential customers that might pay you, or might use the 
software for free.  It is the "money lost to piracy" group that the DRM 
fans keep on about.  Usually it is very small (for most software or 
media, the majority of unlicensed users are in group two, not group 
four, of this list).  Your key here is to make usage a better experience 
for licensed users, such as by having the software connect to your 
servers for extra content, updates, tips, etc.  Convince people that 
they are paying to join a community or service and support system, and 
that licensed usage gives extra benefits.


One trick that can help here, especially if your software is specialised 
with only a few customers, is to register all customers and watermark 
the executables.  It's easy to do, and lets you trace and leakage (of 
course, you have to let customers know this to benefit from the scare 
effect.  Do it subtly, such as by making their company name appear on 
the splash screen).

There is no point in encrypting your programs.  For casual crackers, 
compilation is encryption enough.  For expert crackers, no encryption is 
enough - they will /always/ be able to break it.  It is good enough for 
the program to connect to the server (radius or whatever) at startup and 
check that the license is in order before running.

But if you treat your customers as potential criminals by encrypting the 
program and putting barriers up against reasonable usage, you will 
destroy your customer base.

On 09/08/2012 05:18, jeff wrote:
> 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.

Step one in any cracker's plan of attack is to monitor and limit 
outgoing traffic from their machine, to stop anything "phoning home". 
It is not exactly a new concept.

On 09/08/2012 05:20, jeff wrote:
> On 08/08/2012 07:54 PM, Nobody wrote:
>> On Wed, 08 Aug 2012 13:10:32 -0700, 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.
>>
>> Any information which could possibly be of use to you is OS-specific, so
>> you'd be better off asking on a group dedicated to your target OS.
>>
>
>
> Thanks, finally someone actually provides an answer instead of just
> saying that the effort is futile. Well last time I ever consider posting
> in this group since it seems no one is interested in providing answers,
> and instead just wants to criticize what I am trying to do.

If someone asked me "what's the best way to jump off a cliff", I'd 
suggest they find a safe path down to the bottom.

You are asking the wrong sort of questions here, because what you are 
trying to do is not a good idea.  It would be irresponsible to simply 
give answers to the questions you asked - it is better to help guide you 
into asking the right questions.

Of course you are welcome to try other newsgroups or information 
sources, and eventually you will find someone who will help you down 
your chosen path.  But it won't help you in the long run.

"Andrew Cooper" <amc96@cam.ac.uk> ha scritto nel messaggio
news:5aBUr.474407$ma6.157247@fx09.am4...
> 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.

i think if OS has a protection for make one executable changed
only from who wrote it
i think if OS has one function for make un_debugable this program
and one other function for make         un_radable one file of disk
to other process from the time this program run

it is possible...
for me depend all by OS

>> 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

"io_x" <a@b.c.invalid> ha scritto nel messaggio 
news:50235f22$0$17944$4fafbaef@reader1.news.tin.it...
>
> "Andrew Cooper" <amc96@cam.ac.uk> ha scritto nel messaggio
> news:5aBUr.474407$ma6.157247@fx09.am4...
>> On 08/08/2012 22:09, jeff wrote:
> i think if OS has a protection for make one executable changed
> only from who wrote it

changed and read and write what there is in...

> i think if OS has one function for make un_debugable this program
> and one other function for make         un_radable one file of disk
> to other process from the time this program run
>
> it is possible...
> for me depend all by OS

"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:50235f22$0$17944$4fafbaef@reader1.news.tin.it...
> i think if OS has a protection for make one executable changed
> only from who wrote it
> i think if OS has one function for make un_debugable this program
> and one other function for make         un_radable one file of disk
> to other process from the time this program run
>
> it is possible...
> for me depend all by OS

it would be enought label by the OS the executable as "secret executable"

the executable will be in the OS as encrypt file...

when someone whant run that program

the OS would decript that program with a key-process no other can know
or debug or read the key
decrypt from file directly in memory....

label that process as indebugable

label the memory that process use not readable other process

call the loader for run that memory...

jeff <thexder1@gmail.com> wrote in
news:T8GdnbAo0Mk-eL_NnZ2dnUVZ5omdnZ2d@giganews.com: 

> On 08/08/2012 02:49 PM, Paavo Helde wrote:
>>
>> This still has nothing to do with C++.
>
> The reason I posted here is because the software uses mostly C++ and I
> thought that C++ would be the best language to use for something like 
> this without getting too complicated. So I am looking for a C++ method
> to accomplish this task.

For reminders, the "task" is to launch an executable file in memory after 
decrypting it.

The standard exec function family requires executable filenames. If you 
want to load an executable by yourself into memory, then AFAIK there is 
no standard function for it in C or C++ (nor even in the most common OS 
SDK-s). You have probably to emulate parts of the OS loader: according to 
the executable file formad load the needed parts of the file in memory, 
relocate the relocatable symbols if needed, do any other platform-
specific setup as needed, finally call the executable entry point. This 
all probably requires some lines of assembler code and is all highly 
platform-specific and executable-format specific. Also note that current 
processors can prohibit "running the data" at the hardware level, so 
depending on the OS you might need a root level access for turning the 
loaded code runnable. As you haven't even mentioned which 
OS/platform/executable format you are targeting it is not clear if this 
is easy or not. I suspect on some platforms all it might take is just a 
couple of lines of code. 

But this has nothing to do with the C++, the OS loader does not care a 
bit whether the app has been developed in C++ or not.

hth
Paavo

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_monster.email-scan.com-27213-1344509577-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

jeff writes:

> 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

Really? Such as? For every example you can cite, I'll probably be able to  
come up with three others that have been cracked on launch day.
 
> 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.

Good luck with your scheme. Maybe you'll succeed where huge software houses  
have utterly failed, even though they had $$$ worth of resources at their  
disposal.

--=_monster.email-scan.com-27213-1344509577-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlAjlokACgkQx9p3GYHlUOJGWwCeOafD5D/DtOFcHbxlE1Jnwpzq
+kQAn22VxdKqgylgnG5fh+R4n+vkcHY5
=rCAK
-----END PGP SIGNATURE-----

--=_monster.email-scan.com-27213-1344509577-0001--

jeff <thexder1@gmail.com> wrote in 
news:GKadnTi0IfY1sb7NnZ2dnUVZ5vadnZ2d@giganews.com:

> 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.

Am 08.08.12 22:10, schrieb jeff:
> 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.

Besides that I also don't advise you to do it, it is a rather 
interesting question for itself, but is not supported by C++. Everything 
belonging to executable format is OS dependent and therefore off-topic 
in this group.

However, for certain widely-used platforms, the answer is quickly found 
by google, when you know the magic word "Loader". On Windows, which uses 
the PE format, you would be looking for a "PE loader".

http://www.cultdeadcow.com/tools/pewrap.html

On Linux, it is an "ELF loader" you are looking for, and on the Mac it 
would be a "Mach-O loader".

Note that recently MS introduced side-by-side, which really sucks, which 
they have realized themselves by calling the folders "WinSxS". This is 
much more involved: You need to parse an XML file embeded into the 
executable and locate the DLLs by cryptokeys stored there.

All this means you probably don't want to do it yourself.  There is, 
however, another option for you: Look at UPX, which compresses 
executables and expands them in-memory.

http://upx.sourceforge.net/

Modify the source to do your decryption instead of expanding.

	Christian

On Thu, 09 Aug 2012 17:05:50 +0200
Christian Gollwitzer <auriocus@gmx.de> wrote:
>Note that recently MS introduced side-by-side, which really sucks, which 
>they have realized themselves by calling the folders "WinSxS". This is 
>much more involved: You need to parse an XML file embeded into the 
>executable and locate the DLLs by cryptokeys stored there.

I think they've ditched that now and gone with the version number in the 
filename system that unix has had for decades. Once again MS take 30 years 
to play catch up.

B2003

On 8/8/2012 3:10 PM, 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?

No but I would advise using zlib ( http://zlib.net/ ),
a cross platform compression / decompression open
source utility for your encryption / decryption.

I have built a DRM system for our software package
and it has been cracked many times in the last
couple of decades.  We use a digital signature
(sometimes the hard drive signature:
    http://www.winsim.com/diskid32/diskid32.html )
and password system.

The problem is that locks are to tell honest
people where the limits are.  If everyone was
honest then we software developers could use a
very simplistic serial number or password system.
Unfortunately, we have to design our software
distribution systems to limit the amount of
damage that the dishonest people can do.  Just
cracking your software is bad enough, there are
actually people who will repackage software with
viruses inside it (been there, done that).

Lynn

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

On 08/08/2012 11:43 PM, David Brown wrote:
> On 09/08/2012 00: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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>
> 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.
>
> A DRM system like you suggest will annoy the first group of real, paying
> users. Requiring a user name and password is perhaps not too bad
> (depending on the type of software), but things like tricks to block
> running in a virtual machine, or otherwise limiting the users'
> environment, are right off. So your plan works directly against the only
> important people - the customers that pay your wages.
>
> The second group can be pretty much ignored. They were never going to
> provide you with any income anyway. Just make sure they don't take any
> resources (such as by making write-access to your support forums
> dependent on registration - but keep read-access open). Then you treat
> them as extra beta testers and cheap advertising.
>
> The third group are a risk. But you won't stop them, no matter how hard
> you try. They are smarter at you, have more experience than you, and
> cooperate better with other crackers. If your software is popular,
> cracks /will/ appear on the internet, letting anyone use it for free. If
> it is more niche, but expensive, then cracks /will/ appear on the more
> specialised underground sites, where people can get the software for a
> small fee. This is inevitable, and any believe you might have that you
> can stop it is illusionary. Accept that this will happen and move on.
>
> The forth group are the other important group - these are the people
> that are potential customers that might pay you, or might use the
> software for free. It is the "money lost to piracy" group that the DRM
> fans keep on about. Usually it is very small (for most software or
> media, the majority of unlicensed users are in group two, not group
> four, of this list). Your key here is to make usage a better experience
> for licensed users, such as by having the software connect to your
> servers for extra content, updates, tips, etc. Convince people that they
> are paying to join a community or service and support system, and that
> licensed usage gives extra benefits.
>
>
> One trick that can help here, especially if your software is specialised
> with only a few customers, is to register all customers and watermark
> the executables. It's easy to do, and lets you trace and leakage (of
> course, you have to let customers know this to benefit from the scare
> effect. Do it subtly, such as by making their company name appear on the
> splash screen).
>
> There is no point in encrypting your programs. For casual crackers,
> compilation is encryption enough. For expert crackers, no encryption is
> enough - they will /always/ be able to break it. It is good enough for
> the program to connect to the server (radius or whatever) at startup and
> check that the license is in order before running.
>
> But if you treat your customers as potential criminals by encrypting the
> program and putting barriers up against reasonable usage, you will
> destroy your customer base.
>
>
>
>
If you had read what I have posted before you would know that I have 
already responded to all of this. 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. Also when the companies 
buy the software (which they will buy it because the benefits of using 
it are to good to ignore) then the users will not have a choice on what 
to use. I do not think that a login prompt for accessing software is too 
much especially since every company I have ever worked for has had at 
least 1 login screen for 2 or 3 different pieces of software that they 
use. Even if it was for home user I do not see it as being a problem 
because users are used to logging in to run software. To give a couple 
of examples of this look at the popularity of MMOs, look at Valve's 
Steam, and look at all the software that runs in the cloud, all requires 
login before you can use it this is no different.

On 08/09/2012 12:19 AM, io_x wrote:
> "io_x"<a@b.c.invalid>  ha scritto nel messaggio
> news:50235f22$0$17944$4fafbaef@reader1.news.tin.it...
>> i think if OS has a protection for make one executable changed
>> only from who wrote it
>> i think if OS has one function for make un_debugable this program
>> and one other function for make         un_radable one file of disk
>> to other process from the time this program run
>>
>> it is possible...
>> for me depend all by OS
>
> it would be enought label by the OS the executable as "secret executable"
>
> the executable will be in the OS as encrypt file...
>
> when someone whant run that program
>
> the OS would decript that program with a key-process no other can know
> or debug or read the key
> decrypt from file directly in memory....
>
> label that process as indebugable
>
> label the memory that process use not readable other process
>
> call the loader for run that memory...
>
>
>
What you are writing makes no sense and has little or nothing to do with 
my original question. Please do not reply unless you have at least read 
what I have posted.

On 08/08/2012 11:53 PM, David Brown wrote:
> On 09/08/2012 05:20, jeff wrote:
>> On 08/08/2012 07:54 PM, Nobody wrote:
>>> On Wed, 08 Aug 2012 13:10:32 -0700, 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.
>>>
>>> Any information which could possibly be of use to you is OS-specific, so
>>> you'd be better off asking on a group dedicated to your target OS.
>>>
>>
>>
>> Thanks, finally someone actually provides an answer instead of just
>> saying that the effort is futile. Well last time I ever consider posting
>> in this group since it seems no one is interested in providing answers,
>> and instead just wants to criticize what I am trying to do.
>
> If someone asked me "what's the best way to jump off a cliff", I'd
> suggest they find a safe path down to the bottom.
>
> You are asking the wrong sort of questions here, because what you are
> trying to do is not a good idea. It would be irresponsible to simply
> give answers to the questions you asked - it is better to help guide you
> into asking the right questions.
>
> Of course you are welcome to try other newsgroups or information
> sources, and eventually you will find someone who will help you down
> your chosen path. But it won't help you in the long run.
>
>

How is it not a good idea? What is wrong with simply having an 
executable that is encrypted on the hard drive then decrypting it and 
running it in memory without writing it back to the hard drive? There is 
still only one person who has responded with anything that is helpful. 
No one else has tried to point me in the right direction, or tried to 
explain something better that I can do to protect my software.

On 09/08/2012 07:43, 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.
>
<snip leaving only enough for context>

An excellent post from someone who understands this.

One piece of information for you - you need to protect your distribution 
channels.  Many a copy protection has been "cracked on the day of 
launch" because copies of the protected product were sent to the 
crackers before the product went on sale. This is true of software and 
of DVDs (and was on music before the Sony rootkit fiasco, which you 
should study).  Occasionally the crackers slip and release the crack 
before the product.

Andy

jeff <thexder1@gmail.com> writes:
>On 08/08/2012 11:53 PM, David Brown wrote:
>> On 09/08/2012 05:20, jeff wrote:
>>> On 08/08/2012 07:54 PM, Nobody wrote:
>>>> On Wed, 08 Aug 2012 13:10:32 -0700, 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.
>>>>
>>>> Any information which could possibly be of use to you is OS-specific, so
>>>> you'd be better off asking on a group dedicated to your target OS.
>>>>
>>>
>>>
>>> Thanks, finally someone actually provides an answer instead of just
>>> saying that the effort is futile. Well last time I ever consider posting
>>> in this group since it seems no one is interested in providing answers,
>>> and instead just wants to criticize what I am trying to do.
>>
>> If someone asked me "what's the best way to jump off a cliff", I'd
>> suggest they find a safe path down to the bottom.
>>
>> You are asking the wrong sort of questions here, because what you are
>> trying to do is not a good idea. It would be irresponsible to simply
>> give answers to the questions you asked - it is better to help guide you
>> into asking the right questions.
>>
>> Of course you are welcome to try other newsgroups or information
>> sources, and eventually you will find someone who will help you down
>> your chosen path. But it won't help you in the long run.
>>
>>
>
>How is it not a good idea? What is wrong with simply having an 
>executable that is encrypted on the hard drive then decrypting it and 
>running it in memory without writing it back to the hard drive?

Because any other privileged process on the system can read the
unencrypted executable directly from memory while it is running,
even a non-privileged process running with the same login credentials
can directly access the address space of your executable (see ptrace(2)
on linux, /proc on unix or the debugger interface on Windows).

As someone already pointed out, hibernating a system will flush the
DRAM contents to the swap partition/pagefile/save area on disk where
it can be subsequently accessed.

I can think of a dozen ways to bypass your mechanism without even knowing
exactly how you intend to obfuscate your executable, or even what operating
system you're running on.

One method described in the literature involves liquid nitrogen.

> There is 
>still only one person who has responded with anything that is helpful. 
>No one else has tried to point me in the right direction, or tried to 
>explain something better that I can do to protect my software.

trust, yet verify.

scott

jeff <thexder1@gmail.com> wrote in
news:GKadnTu0IfbJsL7NnZ2dnUVZ5vadnZ2d@giganews.com: 

> On 08/08/2012 07:54 PM, Nobody wrote:
>> On Wed, 08 Aug 2012 13:10:32 -0700, 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.
>>
>> Any information which could possibly be of use to you is OS-specific,
>> so you'd be better off asking on a group dedicated to your target OS.
>>
> 
> 
> Thanks, finally someone actually provides an answer instead of just 
> saying that the effort is futile. Well last time I ever consider
> posting in this group since it seems no one is interested in providing
> answers, and instead just wants to criticize what I am trying to do.
> 

Why should we assist to write shady software?
Why try to fuck your cutomers?(with our assistance?)

On 08/09/2012 01:29 PM, Sjouke Burry wrote:
> jeff<thexder1@gmail.com>  wrote in
> news:GKadnTu0IfbJsL7NnZ2dnUVZ5vadnZ2d@giganews.com:
>
>> On 08/08/2012 07:54 PM, Nobody wrote:
>>> On Wed, 08 Aug 2012 13:10:32 -0700, 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.
>>>
>>> Any information which could possibly be of use to you is OS-specific,
>>> so you'd be better off asking on a group dedicated to your target OS.
>>>
>>
>>
>> Thanks, finally someone actually provides an answer instead of just
>> saying that the effort is futile. Well last time I ever consider
>> posting in this group since it seems no one is interested in providing
>> answers, and instead just wants to criticize what I am trying to do.
>>
>
> Why should we assist to write shady software?
> Why try to fuck your cutomers?(with our assistance?)

How am I trying to fuck my customers? describe exactly how I am doing that.

I am going to already say that you cannot do that for a few reasons. 
First off you have no idea what I am doing for protection other than the 
few things that I have stated here. Also as much as I am trying to 
protect the software I am purposely making sure that it is not going to 
cause problems for legitimate users and I am making sure that any phone 
home things that are put in are not giving me any personal information.

What makes this software shady? Seems like you are saying that I do not 
have a right to protect my software, well I do have that right, but 
unlike most people who protect their software I am specifically making 
sure I do not interrupt the rights of legitimate users to run my software.

I would suggest that you do not continue to post on here talking about 
things you are completely ignorant of. Just because some companies have 
put in oppressive DRM and have caused problems for legitimate users 
(some of which I have ran into and have dealt with the problems caused 
by it) does not mean that everyone who wants to protect the software is 
going to do that.

jeff <thexder1@gmail.com> writes:

>I would suggest that you do not continue to post on here talking about 
>things you are completely ignorant of. Just because some companies have 
>put in oppressive DRM and have caused problems for legitimate users 
>(some of which I have ran into and have dealt with the problems caused 
>by it) does not mean that everyone who wants to protect the software is 
>going to do that.

Why don't you just use FlexLM (FlexNet Publisher) like everyone else that
licenses commercial software?

scott

On 08/09/2012 02:42 PM, Scott Lurndal wrote:
> jeff<thexder1@gmail.com>  writes:
>
>> I would suggest that you do not continue to post on here talking about
>> things you are completely ignorant of. Just because some companies have
>> put in oppressive DRM and have caused problems for legitimate users
>> (some of which I have ran into and have dealt with the problems caused
>> by it) does not mean that everyone who wants to protect the software is
>> going to do that.
>
> Why don't you just use FlexLM (FlexNet Publisher) like everyone else that
> licenses commercial software?
>
> scott
Because everyone (Including me) knows how to crack or get around that.

On 09/08/2012 20:59, jeff wrote:
> On 08/08/2012 11:53 PM, David Brown wrote:
>> On 09/08/2012 05:20, jeff wrote:
>>> On 08/08/2012 07:54 PM, Nobody wrote:
>>>> On Wed, 08 Aug 2012 13:10:32 -0700, 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.
>>>>
>>>> Any information which could possibly be of use to you is
>>>> OS-specific, so
>>>> you'd be better off asking on a group dedicated to your target OS.
>>>>
>>>
>>>
>>> Thanks, finally someone actually provides an answer instead of just
>>> saying that the effort is futile. Well last time I ever consider posting
>>> in this group since it seems no one is interested in providing answers,
>>> and instead just wants to criticize what I am trying to do.
>>
>> If someone asked me "what's the best way to jump off a cliff", I'd
>> suggest they find a safe path down to the bottom.
>>
>> You are asking the wrong sort of questions here, because what you are
>> trying to do is not a good idea. It would be irresponsible to simply
>> give answers to the questions you asked - it is better to help guide you
>> into asking the right questions.
>>
>> Of course you are welcome to try other newsgroups or information
>> sources, and eventually you will find someone who will help you down
>> your chosen path. But it won't help you in the long run.
>>
>>
>
> How is it not a good idea? What is wrong with simply having an
> executable that is encrypted on the hard drive then decrypting it and
> running it in memory without writing it back to the hard drive?

It is not a good idea because it makes life difficult for you and your 
users, yet gives you absolutely no benefits.

You said in another post you were more worried about protecting your 
"IP" than traditional unlicensed usage (popularly known as "piracy", 
though I hate that totally inaccurate name).  As has been pointed out 
earlier, your system will do nothing to protect from unlicensed copying.

How do you think this encryption will help protect your "IP"?  Again, 
anyone with skill, motivation and access to your program, will be able 
to read out the unencrypted binary code.  So encryption is not 
sufficient.  And since "decompiling" to get back to source code, 
especially C++, is highly impractical, no one will be able to make use 
of the code.  Thus your encryption is not necessary either.

Concentrate on making a good system that is as easy as possible for 
paying customers to install and use, add "services" to encourage 
licensed use, and by all means use logins if it is that sort of software 
(but allow users to have their own license server within their own 
network - or provide dongles as alternatives).

 > There is still only one person who has responded with anything that
 > is helpful.
 > No one else has tried to point me in the right direction, or tried to
 > explain something better that I can do to protect my software.

Am I that helpful person?  I certainly have given you a lot of helpful 
advice, and tried to point you in the right direction.  But I have no 
plans to waste your time and mine by helping you go further down the 
wrong path.

The implication from your posts is that your software is large, 
valuable, and will only have a few customers in a specialised market. 
Customer-hostile DRM is not the way to go.  Consider (as I suggested 
earlier) watermarking the software for each customer.  Also look at 
customisation - as part of the package you will customise parts of the 
software individually for the customer, which makes it far less 
attractive for copying.  And include a signed contract - then your 
customers will not copy or spread the software.

This is nothing new - it's what vendors of expensive software have 
always done.  They don't faff about with encryption, anti-virtualisation 
detection, and such nonsense.  In many cases they are even happy to 
provide source code to the customer - the opposite of your plans.

On Thu, 2012-08-09, jeff wrote:
> There is 
> still only one person who has responded with anything that is helpful. 

By your criteria, I count at least two. I think it was Paavo who early
on sketched up the connection (or lack thereof) between what you
wanted to do and the C++ language.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

jeff <thexder1@gmail.com> writes:
>On 08/09/2012 02:42 PM, Scott Lurndal wrote:
>> jeff<thexder1@gmail.com>  writes:
>>
>>> I would suggest that you do not continue to post on here talking about
>>> things you are completely ignorant of. Just because some companies have
>>> put in oppressive DRM and have caused problems for legitimate users
>>> (some of which I have ran into and have dealt with the problems caused
>>> by it) does not mean that everyone who wants to protect the software is
>>> going to do that.
>>
>> Why don't you just use FlexLM (FlexNet Publisher) like everyone else that
>> licenses commercial software?
>>
>> scott
>Because everyone (Including me) knows how to crack or get around that.

You have a pretty low opinion of your customer, it appears.

On 08/10/2012 12:56 AM, David Brown wrote:
> On 09/08/2012 20:59, jeff wrote:
>> On 08/08/2012 11:53 PM, David Brown wrote:
>>> On 09/08/2012 05:20, jeff wrote:
>>>> On 08/08/2012 07:54 PM, Nobody wrote:
>>>>> On Wed, 08 Aug 2012 13:10:32 -0700, 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.
>>>>>
>>>>> Any information which could possibly be of use to you is
>>>>> OS-specific, so
>>>>> you'd be better off asking on a group dedicated to your target OS.
>>>>>
>>>>
>>>>
>>>> Thanks, finally someone actually provides an answer instead of just
>>>> saying that the effort is futile. Well last time I ever consider
>>>> posting
>>>> in this group since it seems no one is interested in providing answers,
>>>> and instead just wants to criticize what I am trying to do.
>>>
>>> If someone asked me "what's the best way to jump off a cliff", I'd
>>> suggest they find a safe path down to the bottom.
>>>
>>> You are asking the wrong sort of questions here, because what you are
>>> trying to do is not a good idea. It would be irresponsible to simply
>>> give answers to the questions you asked - it is better to help guide you
>>> into asking the right questions.
>>>
>>> Of course you are welcome to try other newsgroups or information
>>> sources, and eventually you will find someone who will help you down
>>> your chosen path. But it won't help you in the long run.
>>>
>>>
>>
>> How is it not a good idea? What is wrong with simply having an
>> executable that is encrypted on the hard drive then decrypting it and
>> running it in memory without writing it back to the hard drive?
>
> It is not a good idea because it makes life difficult for you and your
> users, yet gives you absolutely no benefits.
>
> You said in another post you were more worried about protecting your
> "IP" than traditional unlicensed usage (popularly known as "piracy",
> though I hate that totally inaccurate name). As has been pointed out
> earlier, your system will do nothing to protect from unlicensed copying.
>
> How do you think this encryption will help protect your "IP"? Again,
> anyone with skill, motivation and access to your program, will be able
> to read out the unencrypted binary code. So encryption is not
> sufficient. And since "decompiling" to get back to source code,
> especially C++, is highly impractical, no one will be able to make use
> of the code. Thus your encryption is not necessary either.
>
> Concentrate on making a good system that is as easy as possible for
> paying customers to install and use, add "services" to encourage
> licensed use, and by all means use logins if it is that sort of software
> (but allow users to have their own license server within their own
> network - or provide dongles as alternatives).
>
>  > There is still only one person who has responded with anything that
>  > is helpful.
>  > No one else has tried to point me in the right direction, or tried to
>  > explain something better that I can do to protect my software.
>
> Am I that helpful person? I certainly have given you a lot of helpful
> advice, and tried to point you in the right direction. But I have no
> plans to waste your time and mine by helping you go further down the
> wrong path.
>
> The implication from your posts is that your software is large,
> valuable, and will only have a few customers in a specialised market.
> Customer-hostile DRM is not the way to go. Consider (as I suggested
> earlier) watermarking the software for each customer. Also look at
> customisation - as part of the package you will customise parts of the
> software individually for the customer, which makes it far less
> attractive for copying. And include a signed contract - then your
> customers will not copy or spread the software.
>
> This is nothing new - it's what vendors of expensive software have
> always done. They don't faff about with encryption, anti-virtualisation
> detection, and such nonsense. In many cases they are even happy to
> provide source code to the customer - the opposite of your plans.
>
Guess what I am already doing almost everything you have suggested. I 
have been planning on most of it from the beginning and if you look at 
my other posts you would know that for starters I am looking for 
something that will stop at least some users from copying the software, 
or getting the IP. You will also note that I never mentioned anything 
that is customer-hostile. If you believe that I did then please by all 
means point it out and I will probably change it.

In another post that I made I said that I do not think that a simple 
login screen is too much to ask for when the user wants to access the 
software. I am purposely doing everything that I can to make sure that a 
legitimate user will see no more than that login screen. Once again I am 
repeating myself because people apparently are not reading everything 
that I am posting.

Also you are not the one who has provided help.

I would also like to point out that I have dealt with and I really hate 
any Customer-hostile DRM and I believe that all companies take the wrong 
approach to DRM and I am doing everything that I can to avoid that 
because I know that it does not work and in the end it just pushes 
people to cracking the DRM so they do not have to deal with it.

On 08/10/2012 07:08 AM, Scott Lurndal wrote:
> jeff<thexder1@gmail.com>  writes:
>> On 08/09/2012 02:42 PM, Scott Lurndal wrote:
>>> jeff<thexder1@gmail.com>   writes:
>>>
>>>> I would suggest that you do not continue to post on here talking about
>>>> things you are completely ignorant of. Just because some companies have
>>>> put in oppressive DRM and have caused problems for legitimate users
>>>> (some of which I have ran into and have dealt with the problems caused
>>>> by it) does not mean that everyone who wants to protect the software is
>>>> going to do that.
>>>
>>> Why don't you just use FlexLM (FlexNet Publisher) like everyone else that
>>> licenses commercial software?
>>>
>>> scott
>> Because everyone (Including me) knows how to crack or get around that.
>
> You have a pretty low opinion of your customer, it appears.
I happen to be working with companies that are currently using software 
where they have cracked FlexLM. I also have talked to people who do not 
know anything about DRM and they were able to get around restrictions on 
FlexLM licenses. Using FlexLM is pretty much the same as using nothing 
therefore it is a waste of money.

jeff <thexder1@gmail.com> writes:
>On 08/10/2012 07:08 AM, Scott Lurndal wrote:
>> jeff<thexder1@gmail.com>  writes:
>>> On 08/09/2012 02:42 PM, Scott Lurndal wrote:
>>>> jeff<thexder1@gmail.com>   writes:
>>>>
>>>>> I would suggest that you do not continue to post on here talking about
>>>>> things you are completely ignorant of. Just because some companies have
>>>>> put in oppressive DRM and have caused problems for legitimate users
>>>>> (some of which I have ran into and have dealt with the problems caused
>>>>> by it) does not mean that everyone who wants to protect the software is
>>>>> going to do that.
>>>>
>>>> Why don't you just use FlexLM (FlexNet Publisher) like everyone else that
>>>> licenses commercial software?
>>>>
>>>> scott
>>> Because everyone (Including me) knows how to crack or get around that.
>>
>> You have a pretty low opinion of your customer, it appears.
>I happen to be working with companies that are currently using software 
>where they have cracked FlexLM. I also have talked to people who do not 
>know anything about DRM and they were able to get around restrictions on 
>FlexLM licenses. Using FlexLM is pretty much the same as using nothing 
>therefore it is a waste of money.

So ARMH, Cadence, Synopsis,  Intel, AMD, et. al. are wasting money by relying on
FlexLM for their licensed software?

Having run licensed software for 30+ years, I've never seen a company
attempt to bypass or otherwise eliminate flexlm restrictions on the
software they run (even my startup, which had several hundred cadence
licenses, had no incentive to attempt to cheat cadence).

That isn't meant to imply that no company will attempt to bypass licensing
restrictions, but I'd argue that the number of companies which do attempt
to bypass such license restrictions are a significant minority and not really
worth worrying about.

If you suspect, or become aware of such poor behavior, feel free to get the
BSA involved (no, not the Boy Scouts of America) - they'll be happy to do
an audit and take a cut of the results.

On 08/10/2012 12:15 PM, Scott Lurndal wrote:
> jeff<thexder1@gmail.com>  writes:
>> On 08/10/2012 07:08 AM, Scott Lurndal wrote:
>>> jeff<thexder1@gmail.com>   writes:
>>>> On 08/09/2012 02:42 PM, Scott Lurndal wrote:
>>>>> jeff<thexder1@gmail.com>    writes:
>>>>>
>>>>>> I would suggest that you do not continue to post on here talking about
>>>>>> things you are completely ignorant of. Just because some companies have
>>>>>> put in oppressive DRM and have caused problems for legitimate users
>>>>>> (some of which I have ran into and have dealt with the problems caused
>>>>>> by it) does not mean that everyone who wants to protect the software is
>>>>>> going to do that.
>>>>>
>>>>> Why don't you just use FlexLM (FlexNet Publisher) like everyone else that
>>>>> licenses commercial software?
>>>>>
>>>>> scott
>>>> Because everyone (Including me) knows how to crack or get around that.
>>>
>>> You have a pretty low opinion of your customer, it appears.
>> I happen to be working with companies that are currently using software
>> where they have cracked FlexLM. I also have talked to people who do not
>> know anything about DRM and they were able to get around restrictions on
>> FlexLM licenses. Using FlexLM is pretty much the same as using nothing
>> therefore it is a waste of money.
>
> So ARMH, Cadence, Synopsis,  Intel, AMD, et. al. are wasting money by relying on
> FlexLM for their licensed software?
>
> Having run licensed software for 30+ years, I've never seen a company
> attempt to bypass or otherwise eliminate flexlm restrictions on the
> software they run (even my startup, which had several hundred cadence
> licenses, had no incentive to attempt to cheat cadence).
>
> That isn't meant to imply that no company will attempt to bypass licensing
> restrictions, but I'd argue that the number of companies which do attempt
> to bypass such license restrictions are a significant minority and not really
> worth worrying about.
>
> If you suspect, or become aware of such poor behavior, feel free to get the
> BSA involved (no, not the Boy Scouts of America) - they'll be happy to do
> an audit and take a cut of the results.
>
The point is that to get around some restrictions in FlexLM in Linux 
takes no more than a single line change in a config file. Also there is 
apparently no verification on the date so simply changing the date in 
the BIOS on the computer appears to remove time restrictions. Minimal 
knowledge and no programming are required for that. There is obviously 
more to some of it than I mention here but that is the basic idea. Also 
if you think that those companies are not wasting their money then I 
would point out to you that many companies have invested in copy 
protection and DRM methods that never really worked but they continued 
to put millions of dallars into it, the only reason I can come up with 
for that is someone at the company mistakenly thought that it was worth 
the money and did not have enough knowledge of what went on under them 
to realize that it really did nothing.

I also happen to know from talking to people who work at and have worked 
at Cadence for many years that the company knows that there are 
companies that are using their software without paying them and in many 
cases they will either ignore it because they could not get enough money 
from the company to justify legal expenses required to stop it, or they 
sent sales people there to give the company a good deal on getting the 
software legally. This has not prevented thousands of Cadence licenses 
that are being used without being paid for in places like China where 
they mostly ignore US patent and copyright.

I would also say that in about 12 years in IT I have seen about 20+ 
instances of companies either violating or out right cracking licensing. 
In most cases it was either a single employee who brought it in and 
indicated that it was legal, or the company was completely unaware that 
what they did violated the licensing (usually because no one read the 
EULA that came with the software they are using). I have made it a point 
to read the licensing agreements and understand the legal aspects of it 
because I have seen so many cases of ignorance, but I have yet to see 
one case where there was any legal action. I have seen cases where the 
publisher or developer of the software was made aware and they ended up 
just having sales people contact the company and in some cases scare the 
company into paying for licenses where they were previously using 
licenses illegally.

On 09/08/2012 23:03, jeff wrote:
> On 08/09/2012 02:42 PM, Scott Lurndal wrote:
>>
>> Why don't you just use FlexLM (FlexNet Publisher) like everyone else that
>> licenses commercial software?
>>
>> scott
> Because everyone (Including me) knows how to crack or get around that.

You might like to consider why they don't ship any of their stronger 
systems any more - such as Safedisc.  Ones that didn't just have an aim 
of "keeping the honest people honest".

Andy

On 8/10/2012 2:37 PM, jeff wrote:
> On 08/10/2012 12:15 PM, Scott Lurndal wrote:
>> jeff<thexder1@gmail.com>  writes:
>>> On 08/10/2012 07:08 AM, Scott Lurndal wrote:
>>>> jeff<thexder1@gmail.com>   writes:
>>>>> On 08/09/2012 02:42 PM, Scott Lurndal wrote:
>>>>>> jeff<thexder1@gmail.com>    writes:
>>>>>>
>>>>>>> I would suggest that you do not continue to post on here talking about
>>>>>>> things you are completely ignorant of. Just because some companies have
>>>>>>> put in oppressive DRM and have caused problems for legitimate users
>>>>>>> (some of which I have ran into and have dealt with the problems caused
>>>>>>> by it) does not mean that everyone who wants to protect the software is
>>>>>>> going to do that.
>>>>>>
>>>>>> Why don't you just use FlexLM (FlexNet Publisher) like everyone else that
>>>>>> licenses commercial software?
>>>>>>
>>>>>> scott
>>>>> Because everyone (Including me) knows how to crack or get around that.
>>>>
>>>> You have a pretty low opinion of your customer, it appears.
>>> I happen to be working with companies that are currently using software
>>> where they have cracked FlexLM. I also have talked to people who do not
>>> know anything about DRM and they were able to get around restrictions on
>>> FlexLM licenses. Using FlexLM is pretty much the same as using nothing
>>> therefore it is a waste of money.
>>
>> So ARMH, Cadence, Synopsis,  Intel, AMD, et. al. are wasting money by relying on
>> FlexLM for their licensed software?
>>
>> Having run licensed software for 30+ years, I've never seen a company
>> attempt to bypass or otherwise eliminate flexlm restrictions on the
>> software they run (even my startup, which had several hundred cadence
>> licenses, had no incentive to attempt to cheat cadence).
>>
>> That isn't meant to imply that no company will attempt to bypass licensing
>> restrictions, but I'd argue that the number of companies which do attempt
>> to bypass such license restrictions are a significant minority and not really
>> worth worrying about.
>>
>> If you suspect, or become aware of such poor behavior, feel free to get the
>> BSA involved (no, not the Boy Scouts of America) - they'll be happy to do
>> an audit and take a cut of the results.
>>
> The point is that to get around some restrictions in FlexLM in Linux takes no more than a single line change in a config file. Also
> there is apparently no verification on the date so simply changing the date in the BIOS on the computer appears to remove time
> restrictions. Minimal knowledge and no programming are required for that. There is obviously more to some of it than I mention here
> but that is the basic idea. Also if you think that those companies are not wasting their money then I would point out to you that
> many companies have invested in copy protection and DRM methods that never really worked but they continued to put millions of
> dallars into it, the only reason I can come up with for that is someone at the company mistakenly thought that it was worth the money
> and did not have enough knowledge of what went on under them to realize that it really did nothing.
>
> I also happen to know from talking to people who work at and have worked at Cadence for many years that the company knows that there
> are companies that are using their software without paying them and in many cases they will either ignore it because they could not
> get enough money from the company to justify legal expenses required to stop it, or they sent sales people there to give the company
> a good deal on getting the software legally. This has not prevented thousands of Cadence licenses that are being used without being
> paid for in places like China where they mostly ignore US patent and copyright.
>
> I would also say that in about 12 years in IT I have seen about 20+ instances of companies either violating or out right cracking
> licensing. In most cases it was either a single employee who brought it in and indicated that it was legal, or the company was
> completely unaware that what they did violated the licensing (usually because no one read the EULA that came with the software they
> are using). I have made it a point to read the licensing agreements and understand the legal aspects of it because I have seen so
> many cases of ignorance, but I have yet to see one case where there was any legal action. I have seen cases where the publisher or
> developer of the software was made aware and they ended up just having sales people contact the company and in some cases scare the
> company into paying for licenses where they were previously using licenses illegally.

Go google "Drink or Die".  Or just go here:
    http://en.wikipedia.org/wiki/DrinkOrDie
They were selling a cracked version of our software
on their server in San Fransisco when the FBI took
them down.  The FBI told me that they made quite
a bit of money from our software.

I have successfully sued companies here in the USA
for using our software without a license.

However, I have sold two licenses in China and we
appear to have several hundred users there.

Lynn

On 08/10/2012 05:09 PM, Lynn McGuire wrote:
> On 8/10/2012 2:37 PM, jeff wrote:
>> On 08/10/2012 12:15 PM, Scott Lurndal wrote:
>>> jeff<thexder1@gmail.com> writes:
>>>> On 08/10/2012 07:08 AM, Scott Lurndal wrote:
>>>>> jeff<thexder1@gmail.com> writes:
>>>>>> On 08/09/2012 02:42 PM, Scott Lurndal wrote:
>>>>>>> jeff<thexder1@gmail.com> writes:
>>>>>>>
>>>>>>>> I would suggest that you do not continue to post on here talking
>>>>>>>> about
>>>>>>>> things you are completely ignorant of. Just because some
>>>>>>>> companies have
>>>>>>>> put in oppressive DRM and have caused problems for legitimate users
>>>>>>>> (some of which I have ran into and have dealt with the problems
>>>>>>>> caused
>>>>>>>> by it) does not mean that everyone who wants to protect the
>>>>>>>> software is
>>>>>>>> going to do that.
>>>>>>>
>>>>>>> Why don't you just use FlexLM (FlexNet Publisher) like everyone
>>>>>>> else that
>>>>>>> licenses commercial software?
>>>>>>>
>>>>>>> scott
>>>>>> Because everyone (Including me) knows how to crack or get around
>>>>>> that.
>>>>>
>>>>> You have a pretty low opinion of your customer, it appears.
>>>> I happen to be working with companies that are currently using software
>>>> where they have cracked FlexLM. I also have talked to people who do not
>>>> know anything about DRM and they were able to get around
>>>> restrictions on
>>>> FlexLM licenses. Using FlexLM is pretty much the same as using nothing
>>>> therefore it is a waste of money.
>>>
>>> So ARMH, Cadence, Synopsis, Intel, AMD, et. al. are wasting money by
>>> relying on
>>> FlexLM for their licensed software?
>>>
>>> Having run licensed software for 30+ years, I've never seen a company
>>> attempt to bypass or otherwise eliminate flexlm restrictions on the
>>> software they run (even my startup, which had several hundred cadence
>>> licenses, had no incentive to attempt to cheat cadence).
>>>
>>> That isn't meant to imply that no company will attempt to bypass
>>> licensing
>>> restrictions, but I'd argue that the number of companies which do
>>> attempt
>>> to bypass such license restrictions are a significant minority and
>>> not really
>>> worth worrying about.
>>>
>>> If you suspect, or become aware of such poor behavior, feel free to
>>> get the
>>> BSA involved (no, not the Boy Scouts of America) - they'll be happy
>>> to do
>>> an audit and take a cut of the results.
>>>
>> The point is that to get around some restrictions in FlexLM in Linux
>> takes no more than a single line change in a config file. Also
>> there is apparently no verification on the date so simply changing the
>> date in the BIOS on the computer appears to remove time
>> restrictions. Minimal knowledge and no programming are required for
>> that. There is obviously more to some of it than I mention here
>> but that is the basic idea. Also if you think that those companies are
>> not wasting their money then I would point out to you that
>> many companies have invested in copy protection and DRM methods that
>> never really worked but they continued to put millions of
>> dallars into it, the only reason I can come up with for that is
>> someone at the company mistakenly thought that it was worth the money
>> and did not have enough knowledge of what went on under them to
>> realize that it really did nothing.
>>
>> I also happen to know from talking to people who work at and have
>> worked at Cadence for many years that the company knows that there
>> are companies that are using their software without paying them and in
>> many cases they will either ignore it because they could not
>> get enough money from the company to justify legal expenses required
>> to stop it, or they sent sales people there to give the company
>> a good deal on getting the software legally. This has not prevented
>> thousands of Cadence licenses that are being used without being
>> paid for in places like China where they mostly ignore US patent and
>> copyright.
>>
>> I would also say that in about 12 years in IT I have seen about 20+
>> instances of companies either violating or out right cracking
>> licensing. In most cases it was either a single employee who brought
>> it in and indicated that it was legal, or the company was
>> completely unaware that what they did violated the licensing (usually
>> because no one read the EULA that came with the software they
>> are using). I have made it a point to read the licensing agreements
>> and understand the legal aspects of it because I have seen so
>> many cases of ignorance, but I have yet to see one case where there
>> was any legal action. I have seen cases where the publisher or
>> developer of the software was made aware and they ended up just having
>> sales people contact the company and in some cases scare the
>> company into paying for licenses where they were previously using
>> licenses illegally.
>
> Go google "Drink or Die". Or just go here:
> http://en.wikipedia.org/wiki/DrinkOrDie
> They were selling a cracked version of our software
> on their server in San Fransisco when the FBI took
> them down. The FBI told me that they made quite
> a bit of money from our software.
>
> I have successfully sued companies here in the USA
> for using our software without a license.
>
> However, I have sold two licenses in China and we
> appear to have several hundred users there.
>
> Lynn
>

And that has what to do with what I was saying? I never said that 
companies do not go after people who are using unlicensed copies of 
software, although I did indicate and I believe that there is plenty of 
evidence to support it that companies are more interested in going after 
people who are selling illegal copies of their software, or people who 
are actively cracking the software than people who are just using 
illegal copies of the software even though all 3 groups have been 
successfully prosecuted.

I also never said that people do not buy legitimate copies of software 
in China because I know that legitimate copies are sold in China all the 
time. China is not the only country where using software illegally (at 
least as far as US law is concerned) is common but it is one that most 
people know about.

To be clear I am not trying to offend anyone from China I am simply 
stating facts and sharing information from studies that I have read. 
There are plenty of other countries that do the same thing because 
either it is not enforced or because they do not recognize US copyrights 
or patents.

"jeff" <thexder1@gmail.com> wrote...
> On 08/09/2012 01:29 PM, Sjouke Burry wrote:
>>
>> Why should we assist to write shady software?
>> Why try to fuck your cutomers?
>
> How am I trying to fuck my customers?
> What makes this software shady?

Let me count:

- you deliberately attempt to obfuscate your actual executable from
peeping eyes, on the paranoid assumption that any such is malevolent
towards you; just the opposite, your kind of subversive behavior will
raise any responsible anti-virus's and rootkit detector's reddest flags;

- you want to block memory snapshots, which (on the offchance you
succeed) would also deny legitimate crash dumps; not even insinuating
that you may someday write a bug ;-) but if that were to ever happen
and you are not able to duplicate it in house, or if the client has some
other unique misconfig which crashes _your_ software, and you deny
yourself the last line of defense, a full memory dump, you'll lose both
credibility and clients very soon;

- you wish to disallow running inside virtual machines; it's illusory
that you can even come close to foolproofing that wish, but again
on the offchance that you managed to, you'd aggravate many
corporate ITs who migrated their users to VMs in recent years;

- under your scheme, if the client is on a flight without 'net access,
he can't run the program; if your site is down, the client software
stops working; if your site is hijacked, you've just provided a vector
into your client's network; if your company vanishes entirely, the
already "sold" software dies with it.

I did read most of your (highly OT for that matter) thread, and I do
remember you said it's a vertical high value market. I am somewhat
familiar with the context, and my comments still apply.  Hope you
have all of the above crystal-clearly spelled out in your contracts,
otherwise you may find yourself in heaps of real trouble down the road.

That said, I realize you are too far invested down this dead end to turn
back now, and will shrug mine off as just another "unhelpful" reply.

So I'll just echo the sentiment from earlier in the thread:

>>> Could you let us know what programs/methods/systems
>>> these are so we could best avoid them?

Liviu

P.S. << Also when the companies buy the software (which they will
buy it because the benefits of using it are to good to ignore) then the
users will not have a choice on what to use. >>

"Famous last words" collection never ceases to grow and amaze ;-)

On Aug 10, 7:24=A0pm, jeff <thexd...@gmail.com> wrote:
> On 08/10/2012 12:56 AM, David Brown wrote:
> > On 09/08/2012 20:59, jeff wrote:
> >> On 08/08/2012 11:53 PM, David Brown wrote:
> >>> On 09/08/2012 05:20, jeff wrote:
> >>>> On 08/08/2012 07:54 PM, Nobody wrote:
> >>>>> On Wed, 08 Aug 2012 13:10:32 -0700, 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 i=
n
> >>>>>> memory, decrypt it, leaving the decrypted form in memory and run t=
he
> >>>>>> executable from there.

<snip>

> > The implication from your posts is that your software is large,
> > valuable, and will only have a few customers in a specialised market.
> > Customer-hostile DRM is not the way to go. [...]

> Guess what I am already doing almost everything you have suggested. I
> have been planning on most of it from the beginning and if you look at
> my other posts you would know that for starters I am looking for
> something that will stop at least some users from copying the software,
> or getting the IP. You will also note that I never mentioned anything
> that is customer-hostile. If you believe that I did then please by all
> means point it out and I will probably change it.

it's a political thing. Some people believe *any* form of DRM is
customer
hostile. See Stallman.

> In another post that I made I said that I do not think that a simple
> login screen is too much to ask for when the user wants to access the
> software. I am purposely doing everything that I can to make sure that a
> legitimate user will see no more than that login screen. Once again I am
> repeating myself because people apparently are not reading everything
> that I am posting.
>
> Also you are not the one who has provided help.
>
> I would also like to point out that I have dealt with and I really hate
> any Customer-hostile DRM and I believe that all companies take the wrong
> approach to DRM and I am doing everything that I can to avoid that
> because I know that it does not work and in the end it just pushes
> people to cracking the DRM so they do not have to deal with it.

if you have a small number of users, have you considered a dongle
approach?

On 11/08/2012 13:07, Nick Keighley wrote:
> if you have a small number of users, have you considered a dongle
> approach?

That gets around the problems of the software not working when the 
customer has no network connection (etc).

It adds nothing to security.

Andy

"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:5023630a$0$17955$4fafbaef@reader1.news.tin.it...

disclaimer: if you search a serious answer, question all to some german people..
this i can say, can not be serious because i have not a proof on what i say...
it could be seen as a troll post etc etc

> "io_x" <a@b.c.invalid> ha scritto nel messaggio
> news:50235f22$0$17944$4fafbaef@reader1.news.tin.it...
>> i think if OS has a protection for make one executable changed
>> only from who wrote it
>> i think if OS has one function for make un_debugable this program
>> and one other function for make         un_radable one file of disk
>> to other process from the time this program run
>>
>> it is possible...
>> for me depend all by OS
>
> it would be enought label by the OS the executable as "secret executable"
>
> the executable will be in the OS as encrypt file...
>
> when someone whant run that program
>
> the OS would decript that program with a key-process no other can know
> or debug or read the key

> decrypt from file directly in memory....
^^^^^^^^^^^^^^^^^^
no
decrypt in the same filename the crypted file
label that file only for run and in a way noone just OS can read it
[in the Windows OS if one file open itself with special args
i find no process can read it... but only the OS and itself]
and the only one can run it is sys
so nobody can debug it

> label that process as indebugable
>
> label the memory that process use not readable other process
>
> call the loader for run that memory...
         ^^^sys

at end of the process OS recrypt that file...
and mark that file read write run...

if the OS going in crash when that file is run
than the OS has recrypt that file
first
of his full run as server of process

but i have the doubt the file remain
in decripted form in the hard disck
in that case...

in few words the problem i find is
the program loader one could write
can be debugged, so all memory can be seen
and copy in a file...

the same for the data that program read - write
can be copy in a file...
at last i think that

so it could be difficult to mantain secret the ip
or whathever information in the loader program
or in the program run if the loader know password
--------------------------------
if OS not has the above functions etc
the only way i see is a server for the client program

but the ip would be public...

the client program can be craccked, but
each time it has to run it has
send passwrd
and login to the server, if server show there are
2 with the same pasword-login - know ip where
there is the copy not registred

as result for the second login-password connect
the server would not send the info the client
programs has need to continue conputation

i don't know what "info" can be,
or if that could be done...

this would be done for example 1 time every 10 minuts
etc

the problem is the people that has the real
license can have his copy of the program not run...

but if server know the right ip of the client program
this shold be never happen

than someone could not have internet or the internet
goes to crash etc..
it would be a disaster if server ip number
has to change of its sub net is not reachable

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.

Dnia Thu, 09 Aug 2012 11:59:22 -0700, jeff napisal:

> How is it not a good idea? What is wrong with simply having an executable
> that is encrypted on the hard drive then decrypting it and running it in
> memory without writing it back to the hard drive? There is still only one
> person who has responded with anything that is helpful. No one else has
> tried to point me in the right direction, or tried to explain something
> better that I can do to protect my software.

It is not a good idea, because it is lots of trouble for you, support team,
and most importantly customers, while it gives no additional security 
whatsoever.

BTW, there is a patent application of the scheme you are proposing. Or
at least I remember reading one; I don't have a link or number, sorry.
I just hope it will not go through, because from technical point of view
it accomplishes nothing at all, most importantly not what it says
it does. Reviews where along the lines of 'wtf?...'.

Your scheme is an overkill for non-technical users (exclude most people
under 20 from this group). For anyone apt, you would need to sell your
software together with a highly locked operating system which is way
beyond your imagination or skills. On anything off-the-shelf it does 
not make any sense for reasons mentioned already: virtualisation
(dude, you cannot detect a properly emulated environment),
memory dump, debuggers, hibernation, compromised systems, swapping
(which can be forced at any time), and many other features of 
the operating systems which a user like you have never heard of
but which are used for instance by virus protection software.
If you know how to write a virus that can overcome virus protection
when the virus is already known, you can start doing your IP scheme.
It is a prerequisite to know why. I understand why many people would say
"it si working" like you do, but it is marketing hype and here 
you have a technically oriented usenet group.

If you have any technical questions, I am sure someone will
answer.

Edek

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.

In article <k00pkp$liv$1@dont-email.me>, Lynn McGuire  <lmc@winsim.com> wrote:
>On 8/8/2012 3:10 PM, 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?
>
>No but I would advise using zlib ( http://zlib.net/ ),
>a cross platform compression / decompression open
>source utility for your encryption / decryption.
>
>I have built a DRM system for our software package
>and it has been cracked many times in the last
>couple of decades.  We use a digital signature
>(sometimes the hard drive signature:
>    http://www.winsim.com/diskid32/diskid32.html )
>and password system.
>
>The problem is that locks are to tell honest
>people where the limits are.  If everyone was
>honest then we software developers could use a
>very simplistic serial number or password system.
>Unfortunately, we have to design our software
>distribution systems to limit the amount of
>damage that the dishonest people can do.  Just
>cracking your software is bad enough, there are
>actually people who will repackage software with
>viruses inside it (been there, done that).

Disclaimer: I think the question is not really C++ related but... :-)  

There seems to be a witch hunt by DRM haters agaisnt the OP.  From the
perspective of software DRM, I'd tend to agree that this is most
likely a lost battle and managing licensing through value added
service and legal (courts) means may be the better way to go.  

However, there exists a space where DRM is almost essential.  A
company like Netflix can't simply rely value-added customer service,
etc. It has to protect the content and make it as hard as possible to
access content without a subscription.  This is most likely going to
be a constant battle where crackers will find a way in the current
system and the distributor will need to update their protection and
distribute a new client but as things currently stand, they simply
can't stream in a DRM-free format. 

So I think the the OP question has some value even if it is not quite
in the original context.

Yan

On 13/08/2012 18:47, none Yannick Tremblay wrote:

> Disclaimer: I think the question is not really C++ related but... :-)
>
> There seems to be a witch hunt by DRM haters agaisnt the OP.  From the
> perspective of software DRM, I'd tend to agree that this is most
> likely a lost battle and managing licensing through value added
> service and legal (courts) means may be the better way to go.

Let's be clear on this - there is /no/ witch hunt against the OP.  There 
is a general opinion that the encryption system proposed by the OP is a 
bad idea - it will complicate matters and inconvenience people (such as 
legitimate customers and not least, the OP himself), and provide no 
protection.  But people here are trying to help the OP by giving useful 
advice - there is no witch hunt.

>
> However, there exists a space where DRM is almost essential.  A
> company like Netflix can't simply rely value-added customer service,
> etc. It has to protect the content and make it as hard as possible to
> access content without a subscription.  This is most likely going to
> be a constant battle where crackers will find a way in the current
> system and the distributor will need to update their protection and
> distribute a new client but as things currently stand, they simply
> can't stream in a DRM-free format.
>
> So I think the the OP question has some value even if it is not quite
> in the original context.
>

The concept of DRM (taken to mean an encryption system that is decoded 
at the end point) itself is ultimately broken - the user or customer has 
the keys and the decoded result, even if it is a little difficult to 
copy them.  Time and again, DRM "protection" has been shown to be no 
help at all against more serious copyright abuse - and it has 
inconvenienced and limited users from using their legally obtained 
software or media in the way they want.

There are other ways to deal with the distribution of media.  Many music 
services now deliver files that are DRM-free, and seem to manage fine. 
And an obvious way to protect video content is through watermarking.  If 
the film you download from Netflix starts with a warning message telling 
you this copy is licensed to you, with your name and customer number, 
warns that it is watermarked and traceable if it is shared "into the 
wild", then customers will not spread the files.  It is simple, 
unobtrusive, and reliable - everyone should be happy.

On 08/11/2012 05:07 AM, Nick Keighley wrote:
> On Aug 10, 7:24 pm, jeff<thexd...@gmail.com>  wrote:
>> On 08/10/2012 12:56 AM, David Brown wrote:
>>> On 09/08/2012 20:59, jeff wrote:
>>>> On 08/08/2012 11:53 PM, David Brown wrote:
>>>>> On 09/08/2012 05:20, jeff wrote:
>>>>>> On 08/08/2012 07:54 PM, Nobody wrote:
>>>>>>> On Wed, 08 Aug 2012 13:10:32 -0700, 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.
>
> <snip>
>
>>> The implication from your posts is that your software is large,
>>> valuable, and will only have a few customers in a specialised market.
>>> Customer-hostile DRM is not the way to go. [...]
>
>> Guess what I am already doing almost everything you have suggested. I
>> have been planning on most of it from the beginning and if you look at
>> my other posts you would know that for starters I am looking for
>> something that will stop at least some users from copying the software,
>> or getting the IP. You will also note that I never mentioned anything
>> that is customer-hostile. If you believe that I did then please by all
>> means point it out and I will probably change it.
>
> it's a political thing. Some people believe *any* form of DRM is
> customer
> hostile. See Stallman.
>
>> In another post that I made I said that I do not think that a simple
>> login screen is too much to ask for when the user wants to access the
>> software. I am purposely doing everything that I can to make sure that a
>> legitimate user will see no more than that login screen. Once again I am
>> repeating myself because people apparently are not reading everything
>> that I am posting.
>>
>> Also you are not the one who has provided help.
>>
>> I would also like to point out that I have dealt with and I really hate
>> any Customer-hostile DRM and I believe that all companies take the wrong
>> approach to DRM and I am doing everything that I can to avoid that
>> because I know that it does not work and in the end it just pushes
>> people to cracking the DRM so they do not have to deal with it.
>
> if you have a small number of users, have you considered a dongle
> approach?
>
>
I am using a dongle. I am just looking for more, since the dongles are 
lacking in certain areas that I am trying to close without causing 
problems for the users.

On 08/11/2012 11:52 AM, Andy Champ wrote:
> On 11/08/2012 13:07, Nick Keighley wrote:
>> if you have a small number of users, have you considered a dongle
>> approach?
>
> That gets around the problems of the software not working when the
> customer has no network connection (etc).
>
> It adds nothing to security.
>
> Andy

Dongles can help as long as they are implemented correctly. As will all 
security they are not perfect but it is an easy way to add some 
security. I do not believe it is too much to ask to have the 
workstations able to communicate with my server for authentication so I 
am not worried about that. If the company is worried about that part I 
can always setup a VPN connection that they connect through.

I am really confused about you saying that it adds nothing to security 
when I know that is not true. I have read a lot of information about it 
and spoken with engineers at the companies that make the dongles and the 
modern ones that are used have not been emulated yet that anyone knows 
about. That does not mean that the checks for the dongles cannot be 
disabled but that requires someone with a lot of technical expertise to 
make those changes to the software. I am by no means saying that it 
cannot be done, I am just saying that it makes it considerably more 
difficult and therefore it adds to security.

On 08/12/2012 08:11 AM, Edek Pienkowski wrote:
> Dnia Thu, 09 Aug 2012 11:59:22 -0700, jeff napisal:
>
>> How is it not a good idea? What is wrong with simply having an executable
>> that is encrypted on the hard drive then decrypting it and running it in
>> memory without writing it back to the hard drive? There is still only one
>> person who has responded with anything that is helpful. No one else has
>> tried to point me in the right direction, or tried to explain something
>> better that I can do to protect my software.
>
> It is not a good idea, because it is lots of trouble for you, support team,
> and most importantly customers, while it gives no additional security
> whatsoever.
>
> BTW, there is a patent application of the scheme you are proposing. Or
> at least I remember reading one; I don't have a link or number, sorry.
> I just hope it will not go through, because from technical point of view
> it accomplishes nothing at all, most importantly not what it says
> it does. Reviews where along the lines of 'wtf?...'.
>
> Your scheme is an overkill for non-technical users (exclude most people
> under 20 from this group). For anyone apt, you would need to sell your
> software together with a highly locked operating system which is way
> beyond your imagination or skills. On anything off-the-shelf it does
> not make any sense for reasons mentioned already: virtualisation
> (dude, you cannot detect a properly emulated environment),
> memory dump, debuggers, hibernation, compromised systems, swapping
> (which can be forced at any time), and many other features of
> the operating systems which a user like you have never heard of
> but which are used for instance by virus protection software.
> If you know how to write a virus that can overcome virus protection
> when the virus is already known, you can start doing your IP scheme.
> It is a prerequisite to know why. I understand why many people would say
> "it si working" like you do, but it is marketing hype and here
> you have a technically oriented usenet group.
>
> If you have any technical questions, I am sure someone will
> answer.
>
> Edek

So first off I am going to hit on the virtualization again. It can be 
detected and it has been detected. If you actually did your research you 
would already know this. Second it is not a lot of trouble for me or my 
customers. What I am doing right now for licensing and DRM is not really 
affecting the customers at all other than maybe 5 minutes of initial 
setup and it is causing me maybe an additional 60 seconds per software 
build. There is little to nothing that can go wrong with what I 
currently have in place so not much for support either. I know all of 
this because there has been extensive testing done on the current 
systems. Once they are setup no one even knows that there is copy 
protection unless they are not connected to the network. This systems 
that I am currently trying to setup is equavalent to something that is 
done in business all the time which is login to a remote system and run 
software from there. If you do not believe me you need to look no 
farther than the popularity of Citrix, Remote Desktop, and other similar 
applications. This is no different than that other than the user will 
not see the lag associated with running the software remotely.

Businesses have already conditioned users to expect a login when they 
open software, and companies almost always have all computers connected 
to the internet in some way so for this it would be just telling them 
that they need to allow a specific port to connect to my server and no 
one will think twice about it after that. Not really an inconvenience, 
no problems unless the internet connection is not working, but there is 
not much that can be done about that, and with how companies rely on 
their internet connections it is not likely to be down for very long if 
it is down.

On 08/10/2012 08:13 PM, Liviu wrote:
> "jeff"<thexder1@gmail.com>  wrote...
>> On 08/09/2012 01:29 PM, Sjouke Burry wrote:
>>>
>>> Why should we assist to write shady software?
>>> Why try to fuck your cutomers?
>>
>> How am I trying to fuck my customers?
>> What makes this software shady?
>
> Let me count:
>
> - you deliberately attempt to obfuscate your actual executable from
> peeping eyes, on the paranoid assumption that any such is malevolent
> towards you; just the opposite, your kind of subversive behavior will
> raise any responsible anti-virus's and rootkit detector's reddest flags;
>
This is something that is common and does not interrupt normal 
operation, other than that anti-virus issue which I am not worried 
about, but I do not feel like explaining it.

> - you want to block memory snapshots, which (on the offchance you
> succeed) would also deny legitimate crash dumps; not even insinuating
> that you may someday write a bug ;-) but if that were to ever happen
> and you are not able to duplicate it in house, or if the client has some
> other unique misconfig which crashes _your_ software, and you deny
> yourself the last line of defense, a full memory dump, you'll lose both
> credibility and clients very soon;
>
The users will likely not even know what to do with a crash dump and the 
version used by my testers does not have some of the restrictions on it 
so I can see the dumps without any issue. I do not believe I will run 
into the problems that you are saying because I have taken a lot of time 
to avoid it. You are correct though it will probably happen but I am 
sure that I will be able to find a way to duplicate the problem in-house.

> - you wish to disallow running inside virtual machines; it's illusory
> that you can even come close to foolproofing that wish, but again
> on the offchance that you managed to, you'd aggravate many
> corporate ITs who migrated their users to VMs in recent years;
>
This software will not be run in VMs. There is no reason for it other 
than to avoid paying for more licensing and the processing and RAM 
needed for the software makes it much more useful to run on a bare metal 
OS instead of in a VM. If that does come up for some reason I am not 
completely against making an exception for the company if they can prove 
that they need it.

> - under your scheme, if the client is on a flight without 'net access,
> he can't run the program; if your site is down, the client software
> stops working; if your site is hijacked, you've just provided a vector
> into your client's network; if your company vanishes entirely, the
> already "sold" software dies with it.
>
The client would not be running the software in flight or at least it 
should be a policy at the company that is strictly enforced because if 
they are using it in flight then anyone on the flight could see that 
companies proprietary IP which could cause a big problem.

As far as my site, I have full redundancy and offsite replications. If 
there is a problem with my site it will not be down for long. For 
someone to hijack the system that is providing the authentication they 
would have to hack the authentication system itself, not impossible but 
not easy. No other systems will give them direct access to the 
authentication due to separation of the systems and strong network 
filtering.

> I did read most of your (highly OT for that matter) thread, and I do
> remember you said it's a vertical high value market. I am somewhat
> familiar with the context, and my comments still apply.  Hope you
> have all of the above crystal-clearly spelled out in your contracts,
> otherwise you may find yourself in heaps of real trouble down the road.
>
Yes, The contracts are very clear on what is required and what is 
allowed with the software as well as what the software is doing.

> That said, I realize you are too far invested down this dead end to turn
> back now, and will shrug mine off as just another "unhelpful" reply.
>
> So I'll just echo the sentiment from earlier in the thread:
>
>>>> Could you let us know what programs/methods/systems
>>>> these are so we could best avoid them?
>
> Liviu
>
> P.S.<<  Also when the companies buy the software (which they will
> buy it because the benefits of using it are to good to ignore) then the
> users will not have a choice on what to use.>>
>
> "Famous last words" collection never ceases to grow and amaze ;-)
>
>
>
>
>
>
>

On 08/14/2012 01:55 AM, David Brown wrote:
> On 13/08/2012 18:47, none Yannick Tremblay wrote:
>
>> Disclaimer: I think the question is not really C++ related but... :-)
>>
>> There seems to be a witch hunt by DRM haters agaisnt the OP. From the
>> perspective of software DRM, I'd tend to agree that this is most
>> likely a lost battle and managing licensing through value added
>> service and legal (courts) means may be the better way to go.
>
> Let's be clear on this - there is /no/ witch hunt against the OP. There
> is a general opinion that the encryption system proposed by the OP is a
> bad idea - it will complicate matters and inconvenience people (such as
> legitimate customers and not least, the OP himself), and provide no
> protection. But people here are trying to help the OP by giving useful
> advice - there is no witch hunt.
>
There sure seems to be a witch hunt since I have investigated everything 
that has been mentioned before anyone mentioned it here and I have said 
that many times. Also I have said specifically several times that I am 
working hard to make sure that it is not an inconvenience to the 
legitimate users, but no one seems to pay any attention to that part.
>>
>> However, there exists a space where DRM is almost essential. A
>> company like Netflix can't simply rely value-added customer service,
>> etc. It has to protect the content and make it as hard as possible to
>> access content without a subscription. This is most likely going to
>> be a constant battle where crackers will find a way in the current
>> system and the distributor will need to update their protection and
>> distribute a new client but as things currently stand, they simply
>> can't stream in a DRM-free format.
>>
>> So I think the the OP question has some value even if it is not quite
>> in the original context.
>>
>
> The concept of DRM (taken to mean an encryption system that is decoded
> at the end point) itself is ultimately broken - the user or customer has
> the keys and the decoded result, even if it is a little difficult to
> copy them. Time and again, DRM "protection" has been shown to be no help
> at all against more serious copyright abuse - and it has inconvenienced
> and limited users from using their legally obtained software or media in
> the way they want.
>
> There are other ways to deal with the distribution of media. Many music
> services now deliver files that are DRM-free, and seem to manage fine.
> And an obvious way to protect video content is through watermarking. If
> the film you download from Netflix starts with a warning message telling
> you this copy is licensed to you, with your name and customer number,
> warns that it is watermarked and traceable if it is shared "into the
> wild", then customers will not spread the files. It is simple,
> unobtrusive, and reliable - everyone should be happy.
>
>

The key to this system is to give me a chance to monitor usage and to 
give me a change to see at least some unlicensed usage of the software. 
I would also like to point out that music services that sell DRM free 
music are limited because many recording companies will not let them 
sell the music without DRM and Netflix, Hulu and Amazon have the same 
problem they cannot show DRM free content because the companies that 
they license the content from would all leave, it has nothing to do with 
companies like Netflix deciding that they need to protect the content, 
but they would probably still put DRM on the content if they were not 
required to.

In any case this protection that I am trying to implement has almost as 
much to do with getting information as it does with protecting the software.

jeff <thexder1@gmail.com> writes:

>
>So first off I am going to hit on the virtualization again. It can be 
>detected and it has been detected. 

I've been "doing" virtualization since 1998.   It can be done in
such a way as to be invisible to the guest operating system.   Because
things like VMware, KVM, XEN and HyperV are designed to be efficient, they expose
facilities to a guest that can be detected, as you point out.   However,
they don't have to do that.   That leaves timing issues around intercepts
which aren't as easy to detect as you may imagine.

In any case, you should probably research the concept of ICE (of which
the AMD HDT is a prime example).   With an ICE, you have direct access
to the processor, at processor speed, which cannot be detected in any way
by the software running on the machine.    Every X86 processor from
all x86 vendors and most ARM/MIPS/PPC SoC support some form of ICE interface (e.g. HDT, JTAG,
Scan Chains via TWSI, et. al.).

>  This systems 
>that I am currently trying to setup is equavalent to something that is 
>done in business all the time which is login to a remote system and run 
>software from there. 

Actually, most companies will attempt to automate this "remote login"
business, particularly if your application is used for batch processing
(e.g. verilog test benches, synthesis and floorplanning s/w, etc).

>If you do not believe me you need to look no 
>farther than the popularity of Citrix, Remote Desktop, and other similar 
>applications. This is no different than that other than the user will 
>not see the lag associated with running the software remotely.

No, it's not the same.
>
>Businesses have already conditioned users to expect a login when they 
>open software, 

No, they don't.   Users expect to login once, and have those credentials
carry throughout the remainder of the computing arena.   SSO is a big
market.

scott

On Thu, 16 Aug 2012 12:11:11 -0700, jeff wrote:

> I am really confused about you saying that it adds nothing to security
> when I know that is not true.

The check for the dongle or server is still in software, and can be
removed.

If you want DRM which actually works, you need to leave some critical
portion of your program on the dongle or server, so that any would-be
cracker has to re-implement that code in spite of not knowing what it's
supposed to do. For a dongle, this means that it has to include some form
of processor.

On 08/16/2012 01:57 PM, Scott Lurndal wrote:
> jeff<thexder1@gmail.com>  writes:
>
>>
>> So first off I am going to hit on the virtualization again. It can be
>> detected and it has been detected.
>
> I've been "doing" virtualization since 1998.   It can be done in
> such a way as to be invisible to the guest operating system.   Because
> things like VMware, KVM, XEN and HyperV are designed to be efficient, they expose
> facilities to a guest that can be detected, as you point out.   However,
> they don't have to do that.   That leaves timing issues around intercepts
> which aren't as easy to detect as you may imagine.
>
> In any case, you should probably research the concept of ICE (of which
> the AMD HDT is a prime example).   With an ICE, you have direct access
> to the processor, at processor speed, which cannot be detected in any way
> by the software running on the machine.    Every X86 processor from
> all x86 vendors and most ARM/MIPS/PPC SoC support some form of ICE interface (e.g. HDT, JTAG,
> Scan Chains via TWSI, et. al.).
>
You have obviously not read my first response to this so I am done 
talking about it.
>>   This systems
>> that I am currently trying to setup is equavalent to something that is
>> done in business all the time which is login to a remote system and run
>> software from there.
>
> Actually, most companies will attempt to automate this "remote login"
> business, particularly if your application is used for batch processing
> (e.g. verilog test benches, synthesis and floorplanning s/w, etc).
>
Every company that I have worked for has failed at automating it and 
ended up requiring me and everyone in the same department as me to 
remember 5-10 passwords that are forced to change at different 
intervals. All of my friends and coworkers have has the same experience. 
So your generalization of most companies is completely wrong as most 
generalizations are.

>> If you do not believe me you need to look no
>> farther than the popularity of Citrix, Remote Desktop, and other similar
>> applications. This is no different than that other than the user will
>> not see the lag associated with running the software remotely.
>
> No, it's not the same.

How is a login screen not the same as a login screen?
>>
>> Businesses have already conditioned users to expect a login when they
>> open software,
>
> No, they don't.   Users expect to login once, and have those credentials
> carry throughout the remainder of the computing arena.   SSO is a big
> market.
>

Read above.
> scott

"Nobody" <nobody@nowhere.com> ha scritto nel messaggio
news:pan.2012.08.16.20.58.24.739000@nowhere.com...
> On Thu, 16 Aug 2012 12:11:11 -0700, jeff wrote:
>
>> I am really confused about you saying that it adds nothing to security
>> when I know that is not true.
>
> The check for the dongle or server is still in software, and can be
> removed.
>
> If you want DRM which actually works, you need to leave some critical
> portion of your program on the dongle or server, so that any would-be
> cracker has to re-implement that code in spite of not knowing what it's
> supposed to do. For a dongle, this means that it has to include some form
> of processor.

in how i see, you are the only one identify the problem, or pheraps
the only one it seems i understand something...

in few i understand one hacker can get the ip of the connection from
executable...
so it is possible one "denial of server" attack
[100000 ip send connection to that server only for slow down it]
or it is not a problem? or more probably i don't know what i'm saying...
than
i would like to ask this question:
if the server know the list of ips that has to accept connections,
and deny access to all other ips

in that server, could it be successful
one "denial of server" attack  using other ips that are not in that
'safe' list?

could be possible other type attack to that server?

Buone Vacanze

On 16/08/2012 21:11, jeff wrote:
> On 08/11/2012 11:52 AM, Andy Champ wrote:
>> On 11/08/2012 13:07, Nick Keighley wrote:
>>> if you have a small number of users, have you considered a dongle
>>> approach?
>>
>> That gets around the problems of the software not working when the
>> customer has no network connection (etc).
>>
>> It adds nothing to security.
>>
>> Andy
>
> Dongles can help as long as they are implemented correctly. As will all
> security they are not perfect but it is an easy way to add some
> security. I do not believe it is too much to ask to have the
> workstations able to communicate with my server for authentication so I
> am not worried about that. If the company is worried about that part I
> can always setup a VPN connection that they connect through.
>

As a network administrator (amongst my many jobs), I really /hate/ it 
when other people require a VPN to connect to their server "to make it 
secure".  VPN's do not make anything secure - in a situation like this, 
they make things far /less/ secure for the customer.  No sane network 
administrator is going to be happy about having a VPN tunnel from their 
network, or machines on their network, into a third-party system.

On 08/17/2012 01:06 AM, David Brown wrote:
> On 16/08/2012 21:11, jeff wrote:
>> On 08/11/2012 11:52 AM, Andy Champ wrote:
>>> On 11/08/2012 13:07, Nick Keighley wrote:
>>>> if you have a small number of users, have you considered a dongle
>>>> approach?
>>>
>>> That gets around the problems of the software not working when the
>>> customer has no network connection (etc).
>>>
>>> It adds nothing to security.
>>>
>>> Andy
>>
>> Dongles can help as long as they are implemented correctly. As will all
>> security they are not perfect but it is an easy way to add some
>> security. I do not believe it is too much to ask to have the
>> workstations able to communicate with my server for authentication so I
>> am not worried about that. If the company is worried about that part I
>> can always setup a VPN connection that they connect through.
>>
>
> As a network administrator (amongst my many jobs), I really /hate/ it
> when other people require a VPN to connect to their server "to make it
> secure". VPN's do not make anything secure - in a situation like this,
> they make things far /less/ secure for the customer. No sane network
> administrator is going to be happy about having a VPN tunnel from their
> network, or machines on their network, into a third-party system.
>
>

I agree with that, I was just using that as an example of what a company 
may require, and it is not really difficult to setup since I went from 
never setting up a VPN before to having a working one within a couple of 
hours.

On 16/08/2012 21:58, Nobody wrote:
> On Thu, 16 Aug 2012 12:11:11 -0700, jeff wrote:
>
>> I am really confused about you saying that it adds nothing to security
>> when I know that is not true.
>
> The check for the dongle or server is still in software, and can be
> removed.
>
> If you want DRM which actually works, you need to leave some critical
> portion of your program on the dongle or server, so that any would-be
> cracker has to re-implement that code in spite of not knowing what it's
> supposed to do. For a dongle, this means that it has to include some form
> of processor.
>

I was going to write something long, but pointing at this is easier. 
He's correct.

Andy

On 17/08/2012 21:43, jeff wrote:
> On 08/17/2012 01:06 AM, David Brown wrote:
>> On 16/08/2012 21:11, jeff wrote:
>>> On 08/11/2012 11:52 AM, Andy Champ wrote:
>>>> On 11/08/2012 13:07, Nick Keighley wrote:
>>>>> if you have a small number of users, have you considered a dongle
>>>>> approach?
>>>>
>>>> That gets around the problems of the software not working when the
>>>> customer has no network connection (etc).
>>>>
>>>> It adds nothing to security.
>>>>
>>>> Andy
>>>
>>> Dongles can help as long as they are implemented correctly. As will all
>>> security they are not perfect but it is an easy way to add some
>>> security. I do not believe it is too much to ask to have the
>>> workstations able to communicate with my server for authentication so I
>>> am not worried about that. If the company is worried about that part I
>>> can always setup a VPN connection that they connect through.
>>>
>>
>> As a network administrator (amongst my many jobs), I really /hate/ it
>> when other people require a VPN to connect to their server "to make it
>> secure". VPN's do not make anything secure - in a situation like this,
>> they make things far /less/ secure for the customer. No sane network
>> administrator is going to be happy about having a VPN tunnel from their
>> network, or machines on their network, into a third-party system.
>>
>>
>
> I agree with that, I was just using that as an example of what a company
> may require, and it is not really difficult to setup since I went from
> never setting up a VPN before to having a working one within a couple of
> hours.

There are a dozen different ways of making a VPN, and some are harder 
than others in different circumstances.  The really "entertaining" ones 
are when a the third-party insists on an IPSEC VPN, and requires you to 
run something like a SonicWall VPN client on one of your machines.  It 
is usually very quick and easy to get working on /one/ PC in your 
network.  But when you try and connect from two PC's at the same time, 
everything collapses.  Other joys are when the VPN server insists on 
passing dozens of routes and its own DNS settings to the client, 
completely buggering up all local network access for the client.  Then 
there are those VPN servers that have connections from hundreds of 
scattered clients, providing a perfect connection point to let malware 
spread by tunnelling under network firewalls.

VPNs have their uses - they can be very handy when you really do want to 
connect physically separated networks.  But they are only "secure" in 
that you can't eavesdrop on the traffic over the "unsecured" network - 
all other claims and misunderstandings about security are bogus.

(Sorry for the off-topic rant - I've just recently had to deal with the 
messes from VPNs.)

On 8/16/2012 3:37 PM, jeff wrote:
> On 08/14/2012 01:55 AM, David Brown wrote:
>> On 13/08/2012 18:47, none Yannick Tremblay wrote:
>>
>>> Disclaimer: I think the question is not really C++ related but... :-)
>>>
>>> There seems to be a witch hunt by DRM haters agaisnt the OP. From the
>>> perspective of software DRM, I'd tend to agree that this is most
>>> likely a lost battle and managing licensing through value added
>>> service and legal (courts) means may be the better way to go.
>>
>> Let's be clear on this - there is /no/ witch hunt against the OP. There
>> is a general opinion that the encryption system proposed by the OP is a
>> bad idea - it will complicate matters and inconvenience people (such as
>> legitimate customers and not least, the OP himself), and provide no
>> protection. But people here are trying to help the OP by giving useful
>> advice - there is no witch hunt.
>>
> There sure seems to be a witch hunt since I have investigated everything that has been mentioned before anyone mentioned it here and
> I have said that many times. Also I have said specifically several times that I am working hard to make sure that it is not an
> inconvenience to the legitimate users, but no one seems to pay any attention to that part.
>>>
>>> However, there exists a space where DRM is almost essential. A
>>> company like Netflix can't simply rely value-added customer service,
>>> etc. It has to protect the content and make it as hard as possible to
>>> access content without a subscription. This is most likely going to
>>> be a constant battle where crackers will find a way in the current
>>> system and the distributor will need to update their protection and
>>> distribute a new client but as things currently stand, they simply
>>> can't stream in a DRM-free format.
>>>
>>> So I think the the OP question has some value even if it is not quite
>>> in the original context.
>>>
>>
>> The concept of DRM (taken to mean an encryption system that is decoded
>> at the end point) itself is ultimately broken - the user or customer has
>> the keys and the decoded result, even if it is a little difficult to
>> copy them. Time and again, DRM "protection" has been shown to be no help
>> at all against more serious copyright abuse - and it has inconvenienced
>> and limited users from using their legally obtained software or media in
>> the way they want.
>>
>> There are other ways to deal with the distribution of media. Many music
>> services now deliver files that are DRM-free, and seem to manage fine.
>> And an obvious way to protect video content is through watermarking. If
>> the film you download from Netflix starts with a warning message telling
>> you this copy is licensed to you, with your name and customer number,
>> warns that it is watermarked and traceable if it is shared "into the
>> wild", then customers will not spread the files. It is simple,
>> unobtrusive, and reliable - everyone should be happy.
>>
>>
>
> The key to this system is to give me a chance to monitor usage and to give me a change to see at least some unlicensed usage of the
> software. I would also like to point out that music services that sell DRM free music are limited because many recording companies
> will not let them sell the music without DRM and Netflix, Hulu and Amazon have the same problem they cannot show DRM free content
> because the companies that they license the content from would all leave, it has nothing to do with companies like Netflix deciding
> that they need to protect the content, but they would probably still put DRM on the content if they were not required to.
>
> In any case this protection that I am trying to implement has almost as much to do with getting information as it does with
> protecting the software.

Hi Jeff, If you want, I can tell you how to easily
build a phone home system for your software using
a website.  It will not work through a firewall
that captures http though.

Lynn

On 08/21/2012 09:40 AM, Lynn McGuire wrote:
> On 8/16/2012 3:37 PM, jeff wrote:
>> On 08/14/2012 01:55 AM, David Brown wrote:
>>> On 13/08/2012 18:47, none Yannick Tremblay wrote:
>>>
>>>> Disclaimer: I think the question is not really C++ related but... :-)
>>>>
>>>> There seems to be a witch hunt by DRM haters agaisnt the OP. From the
>>>> perspective of software DRM, I'd tend to agree that this is most
>>>> likely a lost battle and managing licensing through value added
>>>> service and legal (courts) means may be the better way to go.
>>>
>>> Let's be clear on this - there is /no/ witch hunt against the OP. There
>>> is a general opinion that the encryption system proposed by the OP is a
>>> bad idea - it will complicate matters and inconvenience people (such as
>>> legitimate customers and not least, the OP himself), and provide no
>>> protection. But people here are trying to help the OP by giving useful
>>> advice - there is no witch hunt.
>>>
>> There sure seems to be a witch hunt since I have investigated
>> everything that has been mentioned before anyone mentioned it here and
>> I have said that many times. Also I have said specifically several
>> times that I am working hard to make sure that it is not an
>> inconvenience to the legitimate users, but no one seems to pay any
>> attention to that part.
>>>>
>>>> However, there exists a space where DRM is almost essential. A
>>>> company like Netflix can't simply rely value-added customer service,
>>>> etc. It has to protect the content and make it as hard as possible to
>>>> access content without a subscription. This is most likely going to
>>>> be a constant battle where crackers will find a way in the current
>>>> system and the distributor will need to update their protection and
>>>> distribute a new client but as things currently stand, they simply
>>>> can't stream in a DRM-free format.
>>>>
>>>> So I think the the OP question has some value even if it is not quite
>>>> in the original context.
>>>>
>>>
>>> The concept of DRM (taken to mean an encryption system that is decoded
>>> at the end point) itself is ultimately broken - the user or customer has
>>> the keys and the decoded result, even if it is a little difficult to
>>> copy them. Time and again, DRM "protection" has been shown to be no help
>>> at all against more serious copyright abuse - and it has inconvenienced
>>> and limited users from using their legally obtained software or media in
>>> the way they want.
>>>
>>> There are other ways to deal with the distribution of media. Many music
>>> services now deliver files that are DRM-free, and seem to manage fine.
>>> And an obvious way to protect video content is through watermarking. If
>>> the film you download from Netflix starts with a warning message telling
>>> you this copy is licensed to you, with your name and customer number,
>>> warns that it is watermarked and traceable if it is shared "into the
>>> wild", then customers will not spread the files. It is simple,
>>> unobtrusive, and reliable - everyone should be happy.
>>>
>>>
>>
>> The key to this system is to give me a chance to monitor usage and to
>> give me a change to see at least some unlicensed usage of the
>> software. I would also like to point out that music services that sell
>> DRM free music are limited because many recording companies
>> will not let them sell the music without DRM and Netflix, Hulu and
>> Amazon have the same problem they cannot show DRM free content
>> because the companies that they license the content from would all
>> leave, it has nothing to do with companies like Netflix deciding
>> that they need to protect the content, but they would probably still
>> put DRM on the content if they were not required to.
>>
>> In any case this protection that I am trying to implement has almost
>> as much to do with getting information as it does with
>> protecting the software.
>
> Hi Jeff, If you want, I can tell you how to easily
> build a phone home system for your software using
> a website. It will not work through a firewall
> that captures http though.
>
> Lynn
>

Lynn,

Thanks for the offer, but I already have a basic phone home system that 
I was working with. Nothing fancy but enough to get the external IP of 
people who are running the software which was all I really wanted at the 
time.

On Wednesday, August 8, 2012 10:10:32 PM UTC+2, jeff wrote:
> I am trying to build a copy protection system where the user authenticate=
s 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 fr=
om 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.

It's not hard getting your executable from memory either. Your hard drive "=
worries" are a red herring - your attacker can do pretty erasioly with the =
memory access only.

On a second look, Andrew Cooper's advice is by far the best you will get. ;=
-)

I see that further on you say " it is going to be combined with other=20
methods that are already in place and prevent people from running=20
programs that will dump memory to disk" - first, I have to ask you, who do =
you think you are to even try to prevent people from running any kind of a =
program. How important you think your program is to even try the same thing=
!? You really should ask your users first "look, I want to have some copy-p=
rotection, and I want to do it so-and-so", and listen to responses. Second,=
 you are sorely mistaken in suggesting that these "other methods" will ulti=
mately work. Ultimately, you can't take away control of the target machine =
from it's administrator, and I believe you don't even realize why you can't=
 do this (otherwise, you would not have believed in what you say you read a=
bout it on the internet).

Leave it and focus of building something of value for your users (note that=
 copy-protection has little to no value to them). For that, I say, listen t=
o David Brown.

Goran.

On Aug 16, 8:11=A0pm, jeff <thexd...@gmail.com> wrote:
> On 08/11/2012 11:52 AM, Andy Champ wrote:
>
> > On 11/08/2012 13:07, Nick Keighley wrote:
> >> if you have a small number of users, have you considered a dongle
> >> approach?
>
> > That gets around the problems of the software not working when the
> > customer has no network connection (etc).
>
> > It adds nothing to security.

it appears to

> Dongles can help as long as they are implemented correctly. As will all
> security they are not perfect but it is an easy way to add some
> security. I do not believe it is too much to ask to have the
> workstations able to communicate with my server for authentication

a network connection is not always available in my case

> so I
> am not worried about that. If the company is worried about that part I
> can always setup a VPN connection that they connect through.
>
> I am really confused about you saying that it adds nothing to security
> when I know that is not true. I have read a lot of information about it
> and spoken with engineers at the companies that make the dongles and the
> modern ones that are used have not been emulated yet that anyone knows
> about. That does not mean that the checks for the dongles cannot be
> disabled but that requires someone with a lot of technical expertise to
> make those changes to the software. I am by no means saying that it
> cannot be done, I am just saying that it makes it considerably more
> difficult and therefore it adds to security.

On Thursday, August 16, 2012 9:03:48 PM UTC+2, jeff wrote:
> I am using a dongle. I am just looking for more, since the dongles are la=
cking in certain areas that I am trying to close without causing problems f=
or the users.

I was working in a place that was using a dongle (world-known provider of s=
uch solutions). Well, it turns out that there was a virtual driver that tha=
t would imitate the dongle on a given port. We knew about it, we knew which=
 customer was doing it, and we did strictly nothing. Why? It was a good cus=
tomer. He was using our software and was bringing a lot of money in for us.=
 We could have gone after him about it, but

1. this would cause us work (e.g. legal)
2. it could ("would" is a better word) have alienated the customer.

This is the position you want to be in - you want your product to bring mon=
ey by virtues other than being hard to crack. From this discusssion, it cer=
tainly looks like that is not the case.

Goran.

On Wednesday, August 8, 2012 11:10:32 PM UTC+3, jeff wrote:
> I am trying to build a copy protection system where the user=20
> authenticates to my server and the server sends a decryption key. Then=20
> without writing the key to the hard drive I want to load an encrypted=20
> executable in memory, decrypt it, leaving the decrypted form in memory=20
> and run the executable from there.

As others have said, you possibly go too far with you being paranoid of you=
r end-users. Such things add complexity, complexity adds bugs, bugs add mis=
behavior and the legitimate users will suffer and be annoyed.

> I cannot have the decrypted executable or the key ever written to the=20
> hard drive because it is too easy for someone to get it from there. I=20
> have the encryption and decryption working, I still need to get the=20
> authentication system working which will probably be RADIUS since I do=20
> not know anything else that would work because the authentication is not=
=20
> custom built so I have either HTTP authentication or RADIUS=20
> authentication. The RADIUS should be easy to setup I found several=20
> libraries that have that I just have not gotten them to authenticate=20
> properly yet. The biggest thing is being able to run the executable from=
=20
> memory.

The reason of any phone-home-system should be to put most weight of it into=
 you being helpful, not being paranoid or spying. Offer automatic patches, =
offer bug-reporting facility, offer transfer of crash dumps to you with ful=
ly guaranteed privacy. That sort of stuff available for legit users makes a=
ny hacks look worse and less trustworthy.

> Does anyone have any idea what to do for this? Any code examples to get=
=20
> me started?

First switch your way of thinking like all around you are thieves (sadly th=
ere are countries in world where it is true) and so you have any to mount a=
nd build all sorts of booby traps against your users and install such into =
their computers.  End users feel that you do not trust them and that you fi=
ght them and that you are are ready to bash down open doors for it so they =
have zero reasons to trust you.

Op 22-Aug-12 11:42, goran.pusic@gmail.com schreef:
> On Thursday, August 16, 2012 9:03:48 PM UTC+2, jeff wrote:
>> I am using a dongle. I am just looking for more, since the dongles are lacking in certain areas that I am trying to close without causing problems for the users.
>
> I was working in a place that was using a dongle (world-known provider of such solutions). Well, it turns out that there was a virtual driver that that would imitate the dongle on a given port. We knew about it, we knew which customer was doing it, and we did strictly nothing. Why? It was a good customer. He was using our software and was bringing a lot of money in for us. We could have gone after him about it, but
>
> 1. this would cause us work (e.g. legal)
> 2. it could ("would" is a better word) have alienated the customer.

3. The customer might have a valid reason to do so.

I understand the (IMO justifyable) desire for DRM. The problem with DRM 
is that it tends to hurt paying customers much more (especially the 
aggressive ones) than the dishonest users. Some DRM mechanisms have such 
severe side effects that the only reasonable course of action is to use 
the hacked version, even if you have paid for the product.

On 08/21/2012 11:47 PM, goran.pusic@gmail.com wrote:
> On Wednesday, August 8, 2012 10:10:32 PM UTC+2, 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.
>
> It's not hard getting your executable from memory either. Your hard drive "worries" are a red herring - your attacker can do pretty erasioly with the memory access only.
>
> On a second look, Andrew Cooper's advice is by far the best you will get. ;-)
>
> I see that further on you say " 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" - first, I have to ask you, who do you think you are to even try to prevent people from running any kind of a program. How important you think your program is to even try the same thing!? You really should ask your users first "look, I want to have some copy-protection, and I want to do it so-and-so", and listen to responses. Second, you are sorely mistaken in suggesting that these "other methods" will ultimately work. Ultimately, you can't take away control of the target machine from it's administrator, and I believe you don't even realize why you can't do this (otherwise, you would not have believed in what you say you read about it on the internet).
>
> Leave it and focus of building something of value for your users (note that copy-protection has little to no value to them). For that, I say, listen to David Brown.
>
> Goran.

You obviously have little idea of what I am doing and are only going 
based on what you have read and heard, not actual experience so I am not 
going to even try to explain everything to you. All I am going to say is 
that I am not doing anything wrong here and I am not doing anything that 
is going to cause problems for the users unless they decide that they 
are going to try to use the software without paying for licenses.

On 08/22/2012 03:01 AM, �� Tiib wrote:
> On Wednesday, August 8, 2012 11:10:32 PM UTC+3, 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.
>
> As others have said, you possibly go too far with you being paranoid of your end-users. Such things add complexity, complexity adds bugs, bugs add misbehavior and the legitimate users will suffer and be annoyed.

It is not overly complicated to do this and it is easy to test and 
verify that it does not cause any problems.
>
>> 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.
>
> The reason of any phone-home-system should be to put most weight of it into you being helpful, not being paranoid or spying. Offer automatic patches, offer bug-reporting facility, offer transfer of crash dumps to you with fully guaranteed privacy. That sort of stuff available for legit users makes any hacks look worse and less trustworthy.

I still have not seen any evidence that shows that I am being overly 
paranoid and since I am not getting any personal data from the user 
there is no way you can claim that I am spying on them. Once again your 
suggestions are already implemented. Yet another person who is getting 
the wrong idea of what I am doing and seems more interested in telling 
me how wrong it is rather than helping.
>
>> Does anyone have any idea what to do for this? Any code examples to get
>> me started?
>
> First switch your way of thinking like all around you are thieves (sadly there are countries in world where it is true) and so you have any to mount and build all sorts of booby traps against your users and install such into their computers.  End users feel that you do not trust them and that you fight them and that you are are ready to bash down open doors for it so they have zero reasons to trust you.

I do not think like that, and I have never thought like that. If you had 
read my previous posts you would know that I am purposely trying to make 
this completely painless to legitimate users. I do not want to do 
anything to cause problems for legitimate users and if it does cause 
problems then I would scrap it.

I really wish people would stop accusing me of being hostile or thinking 
very little of the users when that is simply not the case. Once again if 
people read what I have written they would see that I am actually 
working hard to avoid causing any problems for the legitimate users.

On 08/22/2012 01:56 AM, Nick Keighley wrote:
> On Aug 16, 8:11 pm, jeff<thexd...@gmail.com>  wrote:
>> On 08/11/2012 11:52 AM, Andy Champ wrote:
>>
>>> On 11/08/2012 13:07, Nick Keighley wrote:
>>>> if you have a small number of users, have you considered a dongle
>>>> approach?
>>
>>> That gets around the problems of the software not working when the
>>> customer has no network connection (etc).
>>
>>> It adds nothing to security.
>
> it appears to
>
>> Dongles can help as long as they are implemented correctly. As will all
>> security they are not perfect but it is an easy way to add some
>> security. I do not believe it is too much to ask to have the
>> workstations able to communicate with my server for authentication
>
> a network connection is not always available in my case

I can tell you that is not the norm especially when you consider that it 
is not likely that users would even be allowed to use the software when 
they are travelling.
>
>> so I
>> am not worried about that. If the company is worried about that part I
>> can always setup a VPN connection that they connect through.
>>
>> I am really confused about you saying that it adds nothing to security
>> when I know that is not true. I have read a lot of information about it
>> and spoken with engineers at the companies that make the dongles and the
>> modern ones that are used have not been emulated yet that anyone knows
>> about. That does not mean that the checks for the dongles cannot be
>> disabled but that requires someone with a lot of technical expertise to
>> make those changes to the software. I am by no means saying that it
>> cannot be done, I am just saying that it makes it considerably more
>> difficult and therefore it adds to security.
>

On 08/22/2012 02:42 AM, goran.pusic@gmail.com wrote:
> On Thursday, August 16, 2012 9:03:48 PM UTC+2, jeff wrote:
>> I am using a dongle. I am just looking for more, since the dongles are lacking in certain areas that I am trying to close without causing problems for the users.
>
> I was working in a place that was using a dongle (world-known provider of such solutions). Well, it turns out that there was a virtual driver that that would imitate the dongle on a given port. We knew about it, we knew which customer was doing it, and we did strictly nothing. Why? It was a good customer. He was using our software and was bringing a lot of money in for us. We could have gone after him about it, but
>
> 1. this would cause us work (e.g. legal)
> 2. it could ("would" is a better word) have alienated the customer.
>
> This is the position you want to be in - you want your product to bring money by virtues other than being hard to crack. From this discusssion, it certainly looks like that is not the case.
>
> Goran.

First I have to say that would have to have been an old dongle because I 
have not been able to find any evidence indicating that the new ones 
with the smart card chips in them have been successfully emulated. I 
could be wrong about this but even security researchers have said that 
it would be very difficult to successfully do this and it would probably 
be a lot easier to just disable the dongle checks. Also the companies 
making the dongles claim that it has not been successfully emulated like 
that (not that I would expect them to admit to a flaw in their products).

I agree that just because someone using the software is not paying for 
the license does not necessarily mean that you should pursue legal 
action against them. A great example of where this has caused problems 
is the RIAA going after people sharing music on P2P file sharing, that 
has caused many would be customers to avoid anything associated with the 
record companies and it has even alienated artists who have moved to 
more openly and sometimes even freely distributing music.

At the same time I am not just going to ignore anyone who tries to use 
unlicensed copies of the software, I am going for a middle ground.

On 08/22/2012 11:54 AM, Dombo wrote:
> Op 22-Aug-12 11:42, goran.pusic@gmail.com schreef:
>> On Thursday, August 16, 2012 9:03:48 PM UTC+2, jeff wrote:
>>> I am using a dongle. I am just looking for more, since the dongles
>>> are lacking in certain areas that I am trying to close without
>>> causing problems for the users.
>>
>> I was working in a place that was using a dongle (world-known provider
>> of such solutions). Well, it turns out that there was a virtual driver
>> that that would imitate the dongle on a given port. We knew about it,
>> we knew which customer was doing it, and we did strictly nothing. Why?
>> It was a good customer. He was using our software and was bringing a
>> lot of money in for us. We could have gone after him about it, but
>>
>> 1. this would cause us work (e.g. legal)
>> 2. it could ("would" is a better word) have alienated the customer.
>
> 3. The customer might have a valid reason to do so.
>
> I understand the (IMO justifyable) desire for DRM. The problem with DRM
> is that it tends to hurt paying customers much more (especially the
> aggressive ones) than the dishonest users. Some DRM mechanisms have such
> severe side effects that the only reasonable course of action is to use
> the hacked version, even if you have paid for the product.

I fully agree with that, I have experienced problems before where DRM 
prevented me from running legitimate copies of software. If you would 
read through what I have posted you would know that I am putting a lot 
of effort into making sure that does not happen.

On Thursday, August 23, 2012 1:35:01 AM UTC+3, jeff wrote:
> On 08/22/2012 03:01 AM, =D6=F6 Tiib wrote:
> > The reason of any phone-home-system should be to put most weight of it =
into you being helpful, not being paranoid or spying. Offer automatic patch=
es, offer bug-reporting facility, offer transfer of crash dumps to you with=
 fully guaranteed privacy. That sort of stuff available for legit users mak=
es any hacks look worse and less trustworthy.
>=20
> I still have not seen any evidence that shows that I am being overly=20
> paranoid and since I am not getting any personal data from the user=20
> there is no way you can claim that I am spying on them. Once again your=
=20
> suggestions are already implemented.

How can I provide any evidence about you? I can only tell to you that evide=
nce provided by *you* makes me *feel* that you are being overly paranoid. A=
ll what you have said that you have plus all that you have said that we hav=
e no idea what else security you have on top of it and still looking for mo=
re. Just my feeling. For you that all may actually look like good evidence =
that you have not paid close enough attention to copy protection measures a=
nd so your software is loosely protected.=20

That said your claims seem to contradict. If you already get core dumps of =
crash (already implemented) then those may contain personal data. Else thre=
ad you told that your phone-home system only gets you little information li=
ke IP address of people that use it. Only possibility how this all can fit =
together is that your software never crashes.

On Thursday, August 23, 2012 12:48:08 AM UTC+2, jeff wrote:
> On 08/22/2012 02:42 AM, goran.pusic@gmail.com wrote:
>=20
> > On Thursday, August 16, 2012 9:03:48 PM UTC+2, jeff wrote:
>=20
> >> I am using a dongle. I am just looking for more, since the dongles are=
 lacking in certain areas that I am trying to close without causing problem=
s for the users.
>=20
> >
>=20
> > I was working in a place that was using a dongle (world-known provider =
of such solutions). Well, it turns out that there was a virtual driver that=
 that would imitate the dongle on a given port. We knew about it, we knew w=
hich customer was doing it, and we did strictly nothing. Why? It was a good=
 customer. He was using our software and was bringing a lot of money in for=
 us. We could have gone after him about it, but
>=20
> >
>=20
> > 1. this would cause us work (e.g. legal)
>=20
> > 2. it could ("would" is a better word) have alienated the customer.
>=20
> >
>=20
> > This is the position you want to be in - you want your product to bring=
 money by virtues other than being hard to crack. From this discusssion, it=
 certainly looks like that is not the case.
>=20
> >
>=20
> > Goran.
>=20
>=20
>=20
> First I have to say that would have to have been an old dongle because I=
=20

That was in 2010. I don't work there anymore, so I don't know what the stat=
us is now. I don't know what you consider "old".

Goran.

On Wednesday, August 8, 2012 10:10:32 PM UTC+2, jeff wrote:
> The biggest thing is being able to run the executable from 
> 
> memory.

(To get back to basics...) What did you try so far? 2 minutes of googling gave me a couple of examples, one of them on much-known stackoverflow. No idea how / if they work, but it looks like you didn't even search, let alone tried?

Goran.

Am 23.08.12 13:21, schrieb goran.pusic@gmail.com:
> On Wednesday, August 8, 2012 10:10:32 PM UTC+2, jeff wrote:
>> The biggest thing is being able to run the executable from
>>
>> memory.
>
> (To get back to basics...) What did you try so far? 2 minutes of
> googling gave me a couple of examples, one of them on much-known
> stackoverflow. No idea how / if they work, but it looks like you
> didn't even search, let alone tried?

Yes, and also I've pointed him to UPX, which does, more or less, exactly 
what he wants. Only that compression is used instead of encryption. My 
answer was completely ignored.

	Christian

On 08/22/2012 05:19 PM, �� Tiib wrote:
> On Thursday, August 23, 2012 1:35:01 AM UTC+3, jeff wrote:
>> On 08/22/2012 03:01 AM, �� Tiib wrote:
>>> The reason of any phone-home-system should be to put most weight of it into you being helpful, not being paranoid or spying. Offer automatic patches, offer bug-reporting facility, offer transfer of crash dumps to you with fully guaranteed privacy. That sort of stuff available for legit users makes any hacks look worse and less trustworthy.
>>
>> I still have not seen any evidence that shows that I am being overly
>> paranoid and since I am not getting any personal data from the user
>> there is no way you can claim that I am spying on them. Once again your
>> suggestions are already implemented.
>
> How can I provide any evidence about you? I can only tell to you that evidence provided by *you* makes me *feel* that you are being overly paranoid. All what you have said that you have plus all that you have said that we have no idea what else security you have on top of it and still looking for more. Just my feeling. For you that all may actually look like good evidence that you have not paid close enough attention to copy protection measures and so your software is loosely protected.
>
> That said your claims seem to contradict. If you already get core dumps of crash (already implemented) then those may contain personal data. Else thread you told that your phone-home system only gets you little information like IP address of people that use it. Only possibility how this all can fit together is that your software never crashes.

Since you did not understand what I have said before let me say it 
again. On the versions that are used for testing I get core dumps for 
troubleshooting. The customers will most likely never have that, but I 
have other ways to get information about crashes. I also never said 
anything about core dumps being sent over the internet automatically 
which you seem to have thought that I said. Once again more evidence 
that my posts are not read in their entirety before a comment is posted.

On 08/23/2012 04:21 AM, goran.pusic@gmail.com wrote:
> On Wednesday, August 8, 2012 10:10:32 PM UTC+2, jeff wrote:
>> The biggest thing is being able to run the executable from
>>
>> memory.
>
> (To get back to basics...) What did you try so far? 2 minutes of googling gave me a couple of examples, one of them on much-known stackoverflow. No idea how / if they work, but it looks like you didn't even search, let alone tried?
>
> Goran.

I did search and have tried what I found but so far have not been able 
to get it to work. From the searching it looks like since I am running 
the software in Linux the information I found advises to use contexts to 
run the executable, but so far I have not found a specific example that 
works and in all of the reading that I have done I have not been able to 
come up with a setup that works.

On 08/23/2012 11:51 AM, Christian Gollwitzer wrote:
> Am 23.08.12 13:21, schrieb goran.pusic@gmail.com:
>> On Wednesday, August 8, 2012 10:10:32 PM UTC+2, jeff wrote:
>>> The biggest thing is being able to run the executable from
>>>
>>> memory.
>>
>> (To get back to basics...) What did you try so far? 2 minutes of
>> googling gave me a couple of examples, one of them on much-known
>> stackoverflow. No idea how / if they work, but it looks like you
>> didn't even search, let alone tried?
>
> Yes, and also I've pointed him to UPX, which does, more or less, exactly
> what he wants. Only that compression is used instead of encryption. My
> answer was completely ignored.
>
> Christian
>

Not ignored, being considered.

On 8/24/2012 12:01 PM, jeff wrote:
> On 08/23/2012 04:21 AM, goran.pusic@gmail.com wrote:
>> On Wednesday, August 8, 2012 10:10:32 PM UTC+2, jeff wrote:
>>> The biggest thing is being able to run the executable from
>>>
>>> memory.
>>
>> (To get back to basics...) What did you try so far? 2 minutes of
>> googling gave me a couple of examples, one of them on much-known
>> stackoverflow. No idea how / if they work, but it looks like you
>> didn't even search, let alone tried?
>>
>> Goran.
>
> I did search and have tried what I found but so far have not been able
> to get it to work. From the searching it looks like since I am running
> the software in Linux the information I found advises to use contexts to
> run the executable, but so far I have not found a specific example that
> works and in all of the reading that I have done I have not been able to
> come up with a setup that works.

Way to completely misunderstand your target market!!!!!!!
Most people who run Linux do so *BECAUSE* they don't want "phone home".

I'm not going to debate whether DRM is good or bad.  I'm simply pointing
out that your "market research" is sadly lacking.

On 08/24/2012 01:54 PM, red floyd wrote:
> On 8/24/2012 12:01 PM, jeff wrote:
>> On 08/23/2012 04:21 AM, goran.pusic@gmail.com wrote:
>>> On Wednesday, August 8, 2012 10:10:32 PM UTC+2, jeff wrote:
>>>> The biggest thing is being able to run the executable from
>>>>
>>>> memory.
>>>
>>> (To get back to basics...) What did you try so far? 2 minutes of
>>> googling gave me a couple of examples, one of them on much-known
>>> stackoverflow. No idea how / if they work, but it looks like you
>>> didn't even search, let alone tried?
>>>
>>> Goran.
>>
>> I did search and have tried what I found but so far have not been able
>> to get it to work. From the searching it looks like since I am running
>> the software in Linux the information I found advises to use contexts to
>> run the executable, but so far I have not found a specific example that
>> works and in all of the reading that I have done I have not been able to
>> come up with a setup that works.
>
> Way to completely misunderstand your target market!!!!!!!
> Most people who run Linux do so *BECAUSE* they don't want "phone home".
>
> I'm not going to debate whether DRM is good or bad. I'm simply pointing
> out that your "market research" is sadly lacking.
>

Well You have no idea what you are talking about because the companies 
who would buy the software are already running Linux and the businesses 
do to mind DRM on the software. Individual users might have problems 
with this but I am not selling to individual users since very few would 
be able to afford the software and even fewer would have capability of 
using the software.

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?

On 8/22/2012 5:37 PM, jeff wrote:
> On 08/22/2012 01:56 AM, Nick Keighley wrote:
>> On Aug 16, 8:11 pm, jeff<thexd...@gmail.com>  wrote:
>>> On 08/11/2012 11:52 AM, Andy Champ wrote:
>>>
>>>> On 11/08/2012 13:07, Nick Keighley wrote:
[snip]
>>> Dongles can help as long as they are implemented correctly. As will all
>>> security they are not perfect but it is an easy way to add some
>>> security. I do not believe it is too much to ask to have the
>>> workstations able to communicate with my server for authentication
>>
>> a network connection is not always available in my case
>
> I can tell you that is not the norm especially when you consider that it
> is not likely that users would even be allowed to use the software when
> they are travelling.

So you prefer to require all your customers to have a backup internet
connection from a different ISP, and test the backup frequently, to
cover times when their primary ISP does not provide a working internet
connection?

For this problem, traveling is not an issue.

jeff wrote:
> On 08/21/2012 11:47 PM, goran.pusic@gmail.com wrote:
>> On Wednesday, August 8, 2012 10:10:32 PM UTC+2, 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.
....
Consider explicit periodical audit approach instead of capability-disabling (IBM 
has used it to a great success):

1. You do not risk disabling legitimate users (or the users who ran out of 
licenses without even knowing it). You said it many times that you are trying to 
avoid the annoying legitimate users but your selected approach has an inherent 
risk of doing just so. Audit approach, on the other hand, is not able to disable 
software.

2. You have a great opportunity to talk to your users an extra time and at very 
least learn their needs better (I saw IBM consulting using this chance by all 
its 200%+). Beware: often it will turn out that you either actually save money 
to them (many organizations will just continue paying for the copies of software 
that they do not need; and they can run them without any load). Does not sound 
like much-in-it for you in the short term but nothing helps better in building 
relationships and bringing in new orders.

You might also think of offering deeply discounted price models for 
development/QA/UAT instances. Sometimes big organizations try to entirely avoid 
or squeeze their non-production environments due to steep licensing costs they 
feel "non-productive"; but give them 90% break on these and they will buy tens 
of these licenses and then very well might *buy more production licenses* 
because they will have better experience with better-tested apps. As soon as 
your app becomes their profit-center instead of cost-center, rational 
organizations suddenly stop being stingy.

-Pavel