[music-dsp] interfering signal as "copy protection" of demoversion

Danijel Domazet Danijel.Domazet at littleendian.com
Mon Nov 8 16:06:58 EST 2010


Hi Bastian,
Think twice. Think twice about Pace and similar. Huge number of people 
will not even try your software in that case. People just don't want to 
install drivers, 3rd party softare, etc... They give up before they even 
try. This might be a suicide if your software is new and unknown. Some 
even say Pace is object of hatred in audio community :-).


If you want to fool crackers - give it up, it's impossible. Instead, 
make a decent protection where they must crack you every time you 
release update or fix (for example, encrypt the lic file with a 
public-private key, so they can't make a keygen without factoring the 
key, which is pretty much impossible), that's fair enough. And spend the 
rest of the time making your software better!

My 2 lipas...


Danijel Domazet
LittleEndian.com




On 8.11.2010 18:21, bastian.schnuerle wrote:
> so, err ... in the end this thread was very helpful for me and i would 
> never release any plugins that are not wrapped by pace and co .. ok , 
> they may crack pace, but people there at pace are doing the best job 
> that this wont happen and i just develop plugins ..
>
> bzt
>
>
>
> Am 08.11.2010 um 17:54 schrieb Alan Wolfe:
>
>> Er and the point is just that there isn't such thing as perfect
>> security, you just want your security to be harder to break than is
>> worth while.
>>
>> Or, if you have an HD video of a youtube video demoing your stuff,
>> they never get their hands on your program so that's a good way to
>> protect it.
>>
>> Once people buy it though, they are going to have your software, at
>> which point they would be able to share it (even if they have to crack
>> it to break your anti sharing protection if you have any).
>>
>> Basically, you are just going to have to figure out how good is good
>> enough for your needs and live with the fact that there will always be
>> a way to circumvent your security (:
>>
>> On Mon, Nov 8, 2010 at 8:40 AM, Alan Wolfe <alan.wolfe at gmail.com> wrote:
>>> they can do that too unfortunately bastian
>>>
>>> programs compile to machine code which is basically a binary version
>>> of assembly.
>>>
>>> people can use a disassembler to make the machine code into assembly
>>> and edit it, or they can edit the machine code itself.
>>>
>>> in memory, or on disk and then just relaunch it
>>>
>>> On Mon, Nov 8, 2010 at 12:44 AM, bastian.schnuerle
>>> <bastian.schnuerle at silberstein.de> wrote:
>>>> ah, ok .. that is what i hoped !
>>>>
>>>> i was already stunned if someone can go so deep into a build binary 
>>>> and
>>>> change running code to someone needs ..
>>>>
>>>> Am 08.11.2010 um 09:00 schrieb Alan Wolfe:
>>>>
>>>>> if it was a simple sine wave, and it was a constant wave (or the
>>>>> pattern was easily figured out), they could just add the same wave
>>>>> multiplied by -1 and it would go away.
>>>>>
>>>>> I think that's what he meant by being able to easily remove it :P
>>>>>
>>>>> On Sun, Nov 7, 2010 at 11:47 PM, bastian.schnuerle
>>>>> <bastian.schnuerle at silberstein.de> wrote:
>>>>>>
>>>>>>> One way is to make your plugin not remember its state, and have 
>>>>>>> nothing
>>>>>>> automatable, which is painful enough if there's a big number of
>>>>>>> parameters
>>>>>>> to recall.
>>>>>>> The other common way is periodic white noise of course (a simple 
>>>>>>> sine
>>>>>>> would be pretty easy to remove).
>>>>>>>
>>>>>>
>>>>>> it would be pretty easy to remove ??? how ?
>>>>>>
>>>>>>> Dongles are great if you don't want anyone to try your plugin in 
>>>>>>> its
>>>>>>> demo
>>>>>>> version, but an even better way is to not to release it at all :)
>>>>>>
>>>>>> hehehe ;)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> hey ross,
>>>>>>>>
>>>>>>>> right, i am also considering these issues. but if after 90 days 
>>>>>>>> or 4
>>>>>>>> weeks something comes up, people just pop back their date and time
>>>>>>>> and have a free plugin right ? if the plugin is wrapped by pace or
>>>>>>>> etc. people are not checking it out all, because pace and 
>>>>>>>> friends may
>>>>>>>> be evil (which i do not believe), right ?
>>>>>>>>
>>>>>>>> so a constant signal that is not like an annoying noise, as you
>>>>>>>> suggested, carried  to a amp mod might give you a check out 
>>>>>>>> time of a
>>>>>>>> minute or a bit more, right ? would that not be ok, if the signal
>>>>>>>> that comes back is not to annoying, maybe a sinus at 200Hz with 
>>>>>>>> max
>>>>>>>> -60dBfs or maybe -40dBfs ?
>>>>>>>>
>>>>>>>> another concern i have, what if i publish a plugin in any of the
>>>>>>>> formats available, can it be somehow reverse engineered if it 
>>>>>>>> is not
>>>>>>>> wrapped by pace and co ? sorry, if this question might sound 
>>>>>>>> weird,
>>>>>>>> but i am lacking of technical experience and never published 
>>>>>>>> plugins
>>>>>>>> unwrapped ..
>>>>>>>>
>>>>>>>> thanks for any suggestions,
>>>>>>>> bastian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 07.11.2010 um 20:54 schrieb Ross Bencina:
>>>>>>>>
>>>>>>>>> Hi Bastian
>>>>>>>>>
>>>>>>>>> I think it's pretty hard to evaluate something properly if 
>>>>>>>>> there is
>>>>>>>>> a constant low level noise in there. You might want to reconsider
>>>>>>>>> having it cut in and out, or fade up after a certain time.
>>>>>>>>>
>>>>>>>>> You can also consider what the purpose of the noise is -- is it
>>>>>>>>> just to stop people using it without paying? or is it somehow
>>>>>>>>> intended to encourage people to pay? What I do is have a 
>>>>>>>>> voice-over
>>>>>>>>> that randomly mixes in and asks people to pay -- it doesn't start
>>>>>>>>> happening until after 90 days of use though, so they're ready 
>>>>>>>>> to be
>>>>>>>>> pursuaded by then.
>>>>>>>>>
>>>>>>>>> Perhaps see what your competitors are doing -- if your method is
>>>>>>>>> more annoying than theirs you might end up loosing customers.
>>>>>>>>>
>>>>>>>>> Just my 2 cents.
>>>>>>>>>
>>>>>>>>> Ross.
>>>>>>>>>
>>>>>>>>> ----- Original Message ----- From: "bastian.schnuerle"
>>>>>>>>> <bastian.schnuerle at silberstein.de>
>>>>>>>>> To: "A music-related DSP discussion list for" <music-
>>>>>>>>> dsp at music.columbia.edu>
>>>>>>>>> Sent: Monday, November 08, 2010 6:40 AM
>>>>>>>>> Subject: [music-dsp] interfering signal as "copy protection" of
>>>>>>>>> demo version
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> hi all,
>>>>>>>>>>
>>>>>>>>>> i want to publish a secondary demo version of my plugins beside
>>>>>>>>>> my  usual wrapped and copy protected plugins.
>>>>>>>>>>
>>>>>>>>>> for this i am thinking of just implementing an interfering 
>>>>>>>>>> signal
>>>>>>>>>> in  the signal chain, that is not connected to any pragmas, 
>>>>>>>>>> timing
>>>>>>>>>> or  whatever. it just runs the whole time.
>>>>>>>>>>
>>>>>>>>>> now i am thinking of what kind this signal shall be ... the
>>>>>>>>>> signal  should not be to annoying, just ok to check out the
>>>>>>>>>> plugin, but it  should make it unusable even for not so
>>>>>>>>>> sophisticated users.
>>>>>>>>>>
>>>>>>>>>> does anybody has any suggestions how such a signal could look
>>>>>>>>>> like  and being generated ? (the more easy to generate the 
>>>>>>>>>> better)
>>>>>>>>>>
>>>>>>>>>> thanks a lot,
>>>>>>>>>> bastian
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>
>>>>>>> -- 
>>>>>>> dupswapdrop -- the music-dsp mailing list and website:
>>>>>>> subscription info, FAQ, source code archive, list archive, book 
>>>>>>> reviews,
>>>>>>> dsp links
>>>>>>> http://music.columbia.edu/cmc/music-dsp
>>>>>>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>>>>>
>>>>>> -- 
>>>>>> dupswapdrop -- the music-dsp mailing list and website:
>>>>>> subscription info, FAQ, source code archive, list archive, book 
>>>>>> reviews,
>>>>>> dsp
>>>>>> links
>>>>>> http://music.columbia.edu/cmc/music-dsp
>>>>>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>>>>>
>>>>> -- 
>>>>> dupswapdrop -- the music-dsp mailing list and website:
>>>>> subscription info, FAQ, source code archive, list archive, book 
>>>>> reviews,
>>>>> dsp links
>>>>> http://music.columbia.edu/cmc/music-dsp
>>>>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>>>
>>>> -- 
>>>> dupswapdrop -- the music-dsp mailing list and website:
>>>> subscription info, FAQ, source code archive, list archive, book 
>>>> reviews, dsp
>>>> links
>>>> http://music.columbia.edu/cmc/music-dsp
>>>> http://music.columbia.edu/mailman/listinfo/music-dsp
>>>>
>>>
>> -- 
>> dupswapdrop -- the music-dsp mailing list and website:
>> subscription info, FAQ, source code archive, list archive, book 
>> reviews, dsp links
>> http://music.columbia.edu/cmc/music-dsp
>> http://music.columbia.edu/mailman/listinfo/music-dsp
>
> -- 
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book 
> reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp


More information about the music-dsp mailing list