Fathom Synth Development Thread

VST, AU, AAX, CLAP, etc. Plugin Virtual Instruments Discussion
Post Reply New Topic
RELATED
PRODUCTS
Fathom Synth

Post

I like that Reaper displays your name after buying and I always thought it would be cool it after buying a plugin if you're name was displayed on the GUI near the plugins name in the same type of font. People like buying things to feel like they own it and that's a very small thing that would make a huge impression mentally on the feeling of ownership.
Especially if you could customize it to display your producer name or what have you, people making YouTube videos on that plugin would feel like they had a customized exclusive version.

Post

courtjestr, I sent you a new PM with the download.

It seems a lot of you like the uhe solution, could someone explain how it works?

For the licensing, I don't think it is really possible to lock a license to a user. Of course you can make it look like the license is locked to a user, but the user name is just a piece of information which can be shared, which makes it functionally no different than the unzip code we already have.

The only way to "lock" it really, is to the machine, because the plugin can access machine information at run time which no one is aware of such as the machine name and number of cores in the CPU and you can't fake that. You can pass that around but it would not do you any good since a locked plugin is looking up the info from the machine when it runs.

Locking a license to a user is just marketing, it is no different than a password which can be shared.

You can also lock it to the machine's user name, but that is really just the same as locking it to the machine, not the user really.

This is all just hypothetical since I decided not to use a license for the Fathom Pro product line.

Post

viewtopic.php?f=33&t=472847&hilit=copy+protection

Third comment (and onwards) tells you something, but i'd suggest contacting U-He for more pointers.
Last edited by RPH on Wed May 22, 2019 1:40 pm, edited 1 time in total.

Post

FathomSynth wrote: Wed May 22, 2019 12:50 pm It seems a lot of you like the uhe solution
Possible.. Because it's the best :hihi:

Post

First of all I have good news for everyone.

There will NOT be a new licensing scheme for the Fathom Pro product line.

We will be sticking with the existing unzip code.

I finally had a chance to read back through the thread and the general consensus was this, by votes in the comments above.

Opinion: “Do what you have to” 5
Opinion: “Machine lock would alienate users” 20

This is a pretty clear message that changing the licensing system of a product already in place, especially with a machine lock, would be extremely bad business and could even lose far more customers than additional protected purchases.

I may use a machine lock in the future for a different product line, but it will be done up front so users know what they are buying before hand, it will never be done on Fathom Pro.

Here is more details of what we have learned, for those interested:

1) My sincere appologies that the discussion go so heated, but this in itself is a very important piece of data, because it indicates that changing the system this late in the game would be a huge mistake.

2) Overwhelming opinion that UHE the best system, and that when Seaweed Audio employs one we will be first studying the UHE system.

3) People got confused that this discussion means the existing purchase plan in confusing.

Please don’t think this!

The web site is currently very simple. You buy the product, you get your unzip code for updates. Paying for updates is always optional, and free updates are always provided.

Also, I do need to address one point of confusion.

The comment was made that my policy of going to this thread before making important business decisions means that we do not have a clear business plan or clear vision for Fathom.

This is absolutely not the case. I have an extremely clear road map for Fathom extending far into the future for at least 5 or 10 years, all laid out with features and our ultimate dominance in small areas of the plugin market.

I always make these decision myself ultimately even if users disagree, and it is done based on my plan, ultimately not on forum votes, so there is no waffling here based on user input.

The reason I go to this thread before making a big decision is to avoid making a big mistakes, one which might technically seem like a good idea, but would be bad idea from the perspective of the overall community.

This current discussion is a perfect example, since without feedback I would have changed the licensing system of Fathom Pro on an existing user base, and as this thread has shown, it would have been a catastrophic mistake, and reaching out to the community in this case was critical for me making the right decision (my own decision).

So the decision is this, a few pirated copies of Fathom Pro out there is far better than losing our integrity with our existing customers, so Fathom Pro will stay the same.

A “low tech” unzip code based on Honesty, Simplicity, Integrity and Trust in our users.

Post

RPH wrote: Wed May 22, 2019 1:18 pm viewtopic.php?f=33&t=472847&hilit=copy+protection

Third comment (and onwards) tells you something, but i'd suggest contacting U-He for more pointers.
Urs is a freaking genius.

Post

There are a lot of licenses out there locked to users, but mostly require also some kind of server/shop (The Appstore of Apple for example, but they steal unjustified 30%).
Locking it to the machine poses two problems. First of all machines can break, machines can be stolen, can be sold etc... But the machine does not own the license, its a user... And you have to deal with the fact, that a user usually also needs it authorized on several machines (my Mac Pro in the studio and a second one on a laptop).
There are two accounts which can be combined to protect the authorization better. An account on a vendor server (no access/download without account) which could also check against a blacklist, and the user account on the computer. Usually if I move from one machine to another, I keep my user name and password. Actually I migrate everything from the old machine. That process has to move the authorization with it. You could require to check it with a server for the blacklist. (but it should not lock anybody out if that server is not available...)
I know of those who run little snitch to protect their pirated Adobe apps, but those would still not buy it if it didn’t work, and they are punished enough with their constantly interrupted workflow, just ignore those idiots...
This would make it significantly more difficult to share it. It is definitely not the same as a sharable password. They would need to know someone who is willing to share his personal computer password... You have to find a way to allow the user to change his password as well, but that could be verified with a server again and would deauthorize and register old installations...

Post

Wag put on the best resource...
Urs wrote: Mon Feb 13, 2017 9:57 am
joshb wrote:Do you any thoughts on using some form of a machineID in the serial?
I have not done any form of challenge/response, so I don't know much about it... you need system calls though, which is an easy trace (because you won't need it for anything else)
Urs never even considered locking to the machine... And his scheme is much appreciated here, I guess you find enough hints in that thread to get you going in a good direction. Just limit your time or buy the technology from Urs...

Post

FathomSynth wrote: Wed May 22, 2019 12:50 pm courtjestr, I sent you a new PM with the download.
Thanks Everett. I just wanted to say that you got me as a paying customer because of your responses in this forum. Besides the fact that Fathom is a fabulous synth, it is obvious that you care for your customers and I really want to fully support those who deserve it.

Post

8) Besides the critical aspect of it, the whole issue of licensing fascinates me, so it's hard to resist talking about the technical side of it.

But I just want to be clear that from this point on for me it's only hypothetical since the Fathom Pro product line will stay as is forever, and will never use a machine lock.

:phones: TJ, Theoretically, you are right, licenses belong to users. And I deeply respect what you are saying. However, your own statement makes my point better than I could explain.

"Actually I migrate everything from the old machine. That process has to move the authorization with it. You could require to check it with a server for the blacklist. (but it should not lock anybody out if that server is not available...)"

You just stated very succinctly the whole secret and profound problem inherent in the very issue of licensing. Now go back and replace the words "I" and "you" in your exact same sentence with "anyone".

If someone buys the product and decides to transfer their license to another machine (another user's machine, or a hundred user's other machine) all they do is follow the procedure you just outlined! Batta-bing-batta-boom, license public, not even any real hacking needed.

Also consider this "but it should not lock anybody out if that server is not available..", wait a second, again, that is exactly what the hacker wants. A "safeguard" when the server is not available is the very door he needs.

The point I'm trying to impress on people is that literally everything is a code, the password, the user's name, the user's date of birth, the user's favorite color, and if it is stored in a file on your computer, even in the registry, then all the hacker has to do is give that file to someone else.

Even a ping to the server will not work because the server has no way of knowing if the license data is coming from the original machine or not, unless it tied it to an IP Address which of course would be worse than insanity.

8) The point I'm trying to make is that the ONLY way to create a license which prevents the easy transfer of a product from one person to another is if the application compares a key to hardware data on the computer, which ideally would be a combination of the machine name, number of CPU cores, drive GUID, etc.

Again, I'm not saying this is a good idea, because I know people HATE it, I'm just saying technically speaking it is the ONLY way that is not trivial to hack and distribute.

:tu: The objection has been raised correctly, that this is inconvenient to users who have multiple machines. This is important and worth considering, however, it is easily mitigated. For example my own license application I already wrote has a every easy method on the server interface of granting N number of licenses to a single user for as many machines as they want. Problem solved. If user X requests 9 licenses for his studio, I really don't care, if user Y asks for 250 licenses because he keeps "braking' his computer, then a red flag goes off. Easy solution, all users are happy, because all they have to do is send me an email asking for 5 licenses instead of one, and I'm ok with it because they are asking permission, and that means I'm 99.99% percent sure it is legit.

:borg: Now for the hi-tech aspect, for such a license to work the following must be true.

The key MUST contain and hide three pieces of information which were present all at the same time when the product was installed.

1) The purchase authentication from the server: Server Key
(Does the license request come from a user who just bought the product?).

2) The user data: User Key
(Is the local user requesting the key the same user who bought the product?)

3) The machine hardware data: Machine Key
(Which machine should I run on and which machines should I refuse).

Then all these three pieces of information, all 3 Keys are encoded into a Run-time Local Key, RLK, which is stored as a data file (it does not need to be hidden).

When the application runs it checks the RLK in the file and compares it to the local Machine data. If the key matches the data, the application runs. If a hacker transferred the RLK to another machine the application will not pass the match and the application will vomit.

Because everything is encrypted in the RLK the application never needs to ping the server at run time because the Server Key encrypted in the RLK proves that the key was originally formulated legally.

The entire relationship can not be transferred to another machine because the RLK will not match the Machine name and GUID, etc, on the other machine.

:evil: The ONLY !!! way to hack such a system is for the hacker to change the application binary source code at run time and actually write into the application image on disk or in memory. Now this is not impossible, but the UHE thread goes into this very issue in detail and explains why, even though a hacker can do it, they can be constantly thwarted by successive software releases which change the location of the key validation code, and the effort becomes not worth it, unless of course the hacker is guided by pure hatred, and makes your one application his life's hobby.

Now you could say the hacker can simulate the machine data on another machine, which is not impossible, but since the machine key is encrypted, again, the hacker has to get access to the application code to know which machine data is being used. Again, the effort starts to outweigh the reward.

Keep in mind, as UHE explains clearly in his thread, the idea is not to make hacking impossible, it is just to make it hard enough that only hackers want to do it. If the normal user decides that hacking your app is more trouble than the time it took him to earn the cost of your app, then your license system is successful by any reasonable standard.

:tu: Again, this is all hypothetical, because Fathom Pro will stay as is, and will never have an LCM.

Post

FathomSynth wrote: Wed May 22, 2019 4:21 pm :borg: Now for the hi-tech aspect, for such a license to work the following must be true.

The key MUST contain and hide three pieces of information which were present all at the same time when the product was installed.

1) The purchase authentication from the server: Server Key
(Does the license request come from a user who just bought the product?).

2) The user data: User Key
(Is the local user requesting the key the same user who bought the product?)

3) The machine hardware data: Machine Key
(Which machine should I run on and which machines should I refuse).

Then all these three pieces of information, all 3 Keys are encoded into a Run-time Local Key, RLK, which is stored as a data file (it does not need to be hidden).
This is the part where it seems you could save something. For example: Why is step three necessary? You already checked that the user requesting an authorization purchased a key, and also that he is inded the same user (step 2). IMO, these two should be enough. KV331 Audio (Synthmaster) apparently is satisfies with these two.

Is this hack safe? Maybe not, but which method is? I have seen machine locked protections cracked all the time.
Fernando (FMR)

Post

What I also liked about Urs approach in the past when I worked with him was, that he doesn't care for the hamsters, people who just download tons of stuff because they can and never use it Those wouldn't buy anything anyway and can and should be ignored. But when the product is used for longer periods, then the "black hole" comes up with a direct link to the sales page...
I enjoyed his (at least partial) joy in "hacking back" and staying ahead of the hackers by looking at what they actually do and how... It's still a pain in the neck but doesn't consume you that way.

I don't think many people would be upset when a scheme like the u-he one would be implemented in Fathom. It's just the server based ones and the i-lok etc. that many take an issue with. I personally would prefer an u-he like one over the current zip unlock actually.

Cheers,

Tom
"Out beyond the ideas of wrongdoing and rightdoing, there is a field. I’ll meet you there." - Rumi
Sculptures ScreenDream Mastodon

Post

I like iLok. Speak for yourself.
Anyone who can make you believe absurdities can make you commit atrocities.

Post

:phones: FMR, excellent question.

Step 3) is necessary for the simple reason that step 1) and 2) produce an output (key and file) which can easily be placed on any machine. Step 3 is important to that the application decides that, not only have 1 and 2 been performed (there was somewhere a legal purchase), but ! ALSO ! (3) that the purchase OCCURED ON THIS MACHINE!!!

This is critical... When I decided code my own LCM, I spent about two months digging into this issue very deeply and I quickly came to realize that no matter what you do, ALWAYS, replace the word "USER" with "HACKER" and see if it works. If the "USER" can do ANYTHING to transfer his legal license to his "other" machine, than that is EXACTLY what 500 people will be doing once the hacker posts the hack on the web.

Step (3) is the ONLY way to garauntee that the process is not being performed repeatedly anywhere anyone wants using the first user's perfectly legal information and perfectly legal purchase.

Can the hacker hack the machine image, yes of course, but it is approximately 1000 times more difficult than locating the code file and just posting it on the web for anyone to become "you" the original legal user.

:borg: I have to use iLok also for a bunch of my plugins, but it sometimes requires new users to wait for the physical thumb drive to be delivered so I will never use it for any Seaweed Audio product.

:phones: I read, the uhe thread, the method that everyone loves, and to be honest I'm not sure I understand why a uhe license could not just be easily transferred to another machine. The leader of uhe does an excellent job of explaining how hackers can find the locations in the application code which are probing data from the machine, so I'm guessing is that it is actually essentially a machine lock that is not advertised as such, and that under the hood they are in fact doing exactly the same thing as my solution.

I think part of the original problem for me in this thread is was that I'm honest and say publicly that I would be using the "machine lock", and then there was revolt. On the other hand 99% of all professional level licensing systems actually check the machine data to validate the license. The only difference is THEY DON'T TELL YOU they are doing it !!!

So they avoid the reaction I got, by simply not mentioning it.

Actually, it's a term I made up for myself anyway, maybe it was the worst marketing blunder of all time, hehe. Maybe I should have called it a "Machine Suggestion System". Yes, Seaweed Audio will now use the User Friendly MSS method. Much applause.

But it is so easy to do. All applications probe the local machine for all sorts of stuff like the current time, and amount of ram available, and where to store their preset files on your hard drive. Literally hundreds of pieces of information are read form your machine by literally every app you run. So when application license code probes the name of your machine and the number of cores it is NO DIFFERENT.

The only difference is I said the words "machine lock" and all hell broke loose. LOL.

That is exactly what iLok does, they just replace your machine hardware with a piece of hardware which will not change, problem solved. It would actually be a pretty good idea if users did not have to wait for FedEx to deliver their first iLok thumb drive. And so you lose the quick sale.

Anyway, to be honest I just really prefer the method of basically trusting people, so partly that was the decision for my company.
Last edited by FathomSynth on Wed May 22, 2019 5:26 pm, edited 2 times in total.

Post

FathomSynth wrote: Wed May 22, 2019 5:10 pm FMR, excellent question.

Step 3) is necessary for the simple reason that step 1) and 2) produce an output (key and file) which can easily be placed on any machine. Step 3 is important to that the application decides that, not only have 1 and 2 been performed (there was somewhere a legal purchase), but ! ALSO ! (3) that the purchase OCCURED ON THIS MACHINE!!!

This is critical... When I decided code my own LCM, I spent about two months digging into this issue very deeply and I quickly came to realize that no matter what you do, ALWAYS, replace the word "USER" with "HACKER" and see if it works. If the "USER" can do ANYTHING to transfer his legal license to his "other" machine, than that is EXACTLY what 500 people will be doing once the hacker posts the hack on the web.

Step (3) is the ONLY way to garauntee that the process is not being performed repeatedly anywhere anyone wants using the first user's perfectly legal information and perfectly legal purchase.
It seems you didn't get my point. My point is:

1. You have a user reserved area, where the user accesses his download link, by providing the critical information (User ID and password).

2. Before download, the user is requested to introduce his serial number (or he has a link to a personalized copy of his software (pre-authorized with watermark, for example).

This would be enough, IMO. Sure, theoretically a hacker could purchase one copy of your software, and provide it to anyone thorugh his own servers, but the software would be watermarked, and you could blacklist it once you detect that particular license is shown in several places around the world.

This would be enough protection for your business case, IMO. I sincerely doubt a hacker would distribute a watermarked software, since that could even lead to trace his activities. Usually, they reverse engineer the software to remove the part that is related with copy protection, AFAIK. If they would consider your software deserving the effort, no matter what copy protection method you use, it would be hacked.
Fernando (FMR)

Post Reply

Return to “Instruments”