More copy protection...

[Urs]

A big issue with software is perception of value.

By the customer or the dev?

As we say in German: "Häh?"

[AnX]

Its not a trick question

[Urs]

in that case let me quote myself with context:

A big issue with software is perception of value. Everyone wants expensive software for a lower price. If it isn't expensive, it's commonly regarded as less valuable and thus less "pro". Hence some companies give themselves a "pro" image by pricing their software high [...]

Other than that, as a developer it's relatively easy to put a price on software by looking at developer salaries, marketing spendings, budget for sound designers, wages for support staff, months spent on UI design, and then factor expected number of sales in and hopefully some profit for boss to buy wife a nice dinner.

[AnX]

I know users often moan about prices, but i haven come across companies who boost prices to look pro... maybe im not looking hard enough.

[Urs]

I know users often moan about prices, but i haven come across companies who boost prices to look pro... maybe im not looking hard enough.

There's a lot of talk about that with certain companies. They place a high price tag on their software, but practically have a sale all year long. So the actual value is half of what it says on the price tag, yet the value seems higher.

[AnX]

Ah yes ok (should have read more posts )

There are certain preset makers that do that too

[kvaca]

I know users often moan about prices, but i haven come across companies who boost prices to look pro... maybe im not looking hard enough.

There's a lot of talk about that with certain companies. They place a high price tag on their software, but practically have a sale all year long. So the actual value is half of what it says on the price tag, yet the value seems higher.

...and there are other "pro" companies with high price tag which usually offer zero sales all year long, their software is innovative, typically with crappy looking GUI...

[Chaotikmind]

Depending how it's made it can be very simple to automate the annotation of assembler code with script in IDA.

I can't see how.

Well, taking the example of your dispatcher, it's quite simple to link the dispatcher call (with its arguments) with a table (that table could be programmatically made depending on how the dispatcher works)
Then it become extremely simple to annotate the code once you have that table i guess there is no need to explain that part.
Is there any of your effects i could download as demo, which use this system ? ( a "tiny" one preferrably)

Edit: Btw did you ever use IDA ?

Most probably, the guy cracking your plugs just didn't see the check , cause they tend to work extremely fast. (and then missing stuff)

I refuse to think of this as "work", just like I can't see why people thank uploaders for "their hard work". Their contribution is irrelevant compared to the effort in the design and development process of the software in question.

Most probably, they diff previous cracks and continue their random little twiddles from where others left it.

Thanking uploaders for "their hard work" sounds like a joke , i'm really sure there is no hard work involved in that (uploaders are usually not the people who do the cracks anyway)

I do contracts as reverser from time to time, obviously on more legal stuff, but it was also a hobby for me 10-15 years ago....
And whatever you think about it , people doing that invest themselves a lot, considering it work or not is a matter of point of view, even if that is work against your interests.

[Urs]

Depending how it's made it can be very simple to automate the annotation of assembler code with script in IDA.

I can't see how.

Well, taking the example of your dispatcher, it's quite simple to link the dispatcher call (with its arguments) with a table (that table could be programmatically made depending on how the dispatcher works)
Then it become extremely simple to annotate the code once you have that table i guess there is no need to explain that part.
Is there any of your effects i could download as demo, which use this system ? ( a "tiny" one preferrably)

Edit: Btw did you ever use IDA ?

I have checked IDA out, but don't use it. I understand its concepts though.

However, the "dispatcher" is distributed. In our code, every object contains a dispatcher which can choose to react on messages, or not. The message itself is a variable that can be set at runtime. Here's a simple example that should be utterly difficult to understand via an automated process: What if there's a message that takes adds a number X to a message identifier. Call it "MessageAdd". Then you have a message identifier "DoThisOrThat". Now this:

messageID X = (k_MessageID_ DoThisOrThat - 37); // evaluated at compile time
dispatch( k_MessageID_MessageAdd, 37, &X ); // adds 37 to X
dispatch( X, 0, &someData );

Of course you're not limited to this kind of mindfuck. Complete messages can be composed from *data* as opposed to *program flow*. These constructs make it utterly tedious to figure out which message is sent from where. You can't identify for sure where in the binary a certain dispatch call originates.

Likewise, one can obscure as to what kind of data a dispatcher call is working on. As I said, to defeat IDA one needs to move protection from code logic to data processing. This totally runs against binary code analysis, and makes runtime analysis preferrable. Runtime analysis however only works well when there are no delayed checks.

Most probably, the guy cracking your plugs just didn't see the check , cause they tend to work extremely fast. (and then missing stuff)

I refuse to think of this as "work", just like I can't see why people thank uploaders for "their hard work". Their contribution is irrelevant compared to the effort in the design and development process of the software in question.

Most probably, they diff previous cracks and continue their random little twiddles from where others left it.

Thanking uploaders for "their hard work" sounds like a joke , i'm really sure there is no hard work involved in that (uploaders are usually not the people who do the cracks anyway)

I do contracts as reverser from time to time, obviously on more legal stuff, but it was also a hobby for me 10-15 years ago....
And whatever you think about it , people doing that invest themselves a lot, considering it work or not is a matter of point of view, even if that is work against your interests.

Sorry, hehe, I was talking about the poor guys who think reversing audio plug-ins is rocket science, maybe even an admirable cause. My stance is based on what I read on file sharing websites, where the warez ecosystem is glorified beyond belief. Thus I refuse to speak of "work" or even "cause" in this particular context.

[Urs]

Also, all our plug-ins are available for download on our website. I won't do a CrackMe with a simplified plug-in

[Chaotikmind]

I have checked IDA out, but don't use it. I understand its concepts though.

However, the "dispatcher" is distributed. In our code, every object contains a dispatcher which can choose to react on messages, or not. The message itself is a variable that can be set at runtime. Here's a simple example that should be utterly difficult to understand via an automated process: What if there's a message that takes adds a number X to a message identifier. Call it "MessageAdd". Then you have a message identifier "DoThisOrThat". Now this:

messageID X = (k_MessageID_ DoThisOrThat - 37); // evaluated at compile time
dispatch( k_MessageID_MessageAdd, 37, &X ); // adds 37 to X
dispatch( X, 0, &someData );

Of course you're not limited to this kind of mindfuck. Complete messages can be composed from *data* as opposed to *program flow*. These constructs make it utterly tedious to figure out which message is sent from where. You can't identify for sure where in the binary a certain dispatch call originates.

Likewise, one can obscure as to what kind of data a dispatcher call is working on. As I said, to defeat IDA one needs to move protection from code logic to data processing. This totally runs against binary code analysis, and makes runtime analysis preferrable. Runtime analysis however only works well when there are no delayed checks.

Obviously there are a lot of way to f**k with reverser minds
The specific case your talking about seems to relate well to the way Themida VM used to work
which was defeated by automatic(mostly) analysis and recompilation.
Basically Themida was taking part of the original code, replacing it with a call to the VM and emulating it's execution , obviously a bitch to reverse, but it was finally reversed like anything else.
It will really depends if you're lucky or not, if a really good reverser does it, then you're mostly f**ked, no matter what.

Sorry, hehe, I was talking about the poor guys who think reversing audio plug-ins is rocket science, maybe even an admirable cause. My stance is based on what I read on file sharing websites, where the warez ecosystem is glorified beyond belief. Thus I refuse to speak of "work" or even "cause" in this particular context.

It's glorified (i think) because the knowledge gap between crack users, and cracks makers is insane, they logically end up being perceived as "gods".

[Urs]

It will really depends if you're lucky or not, if a really good reverser does it, then you're mostly f**ked, no matter what.

I guess I'm lucky because I don't do operating systems, banking stuff or anything else that is an interesting target for anyone but a beginner.

We actually know a lot about the way they work, and they're totally at "let's try to make this jz a jnz". There is no indication in the cracks which show any knowledge of larger context.

because the knowledge gap between crack users, and cracks makers is insane, they logically end up being perceived as "gods".

Yes, but what gets me is the total disregard for the people who wrote the software in the first place. That culture is completely out of whack with their perception of value.

[aciddose]

Yes, but what gets me is the total disregard for the people who wrote the software in the first place. That culture is completely out of whack with their perception of value.

It's like expecting the pope to march in a pride parade. They see you as one of the shirtless sinners. "Hate the sin, not the sinner" = expecting to be remunerated for software development effort.

https://en.wikipedia.org/wiki/Tragedy_of_the_commons

It's a common selfish behavior that applies across almost all aspects of life. It exists because it is beneficial to those who apply it. This is all a simple war for who can pillage the most and so they see you in asking for payment for services rendered as a thief attempting to pick their pockets. They have absolutely zero concern for the development of the product as it already exists. Therefore they demonstrate that they can "slip past" without being robbed and feel quite smug about it.

Software and other works obviously have some "value"; as you say the cost of their development. Nonetheless the point of view of the user is that the value is zero. If you were to charge for bandwidth for example they could simply demonstrate that sharing their own bandwidth could achieve the same ends without requirement of such a cost to them alone.

You might argue of course that this is self-defeating for them; but really it is not. It defeats you by stripping you of your income required to motivate you to continue your efforts. Your argument would be that you would then cease to produce such products and they would no longer provide benefit to the users. They do not see it that way.

They feel that if you disappear it will be no loss to them; they already possess your products and another sucker will appear in time.

(Note: only speaking of users. The crackers themselves are another story which is slightly more complex and involves a lot of cognitive dissonance.)

[aciddose]

Could've summed it up in one link:

https://www.youtube.com/watch?v=-23kmhc3P8U

[JCJR]

in that case let me quote myself with context:

A big issue with software is perception of value. Everyone wants expensive software for a lower price. If it isn't expensive, it's commonly regarded as less valuable and thus less "pro". Hence some companies give themselves a "pro" image by pricing their software high [...]

Other than that, as a developer it's relatively easy to put a price on software by looking at developer salaries, marketing spendings, budget for sound designers, wages for support staff, months spent on UI design, and then factor expected number of sales in and hopefully some profit for boss to buy wife a nice dinner.

Though perhaps irrelevant to modern software biz in general or music software in specific-- You made me recall some articles from decades ago.

A brief summation of the "basic concept" of the articles-- Early and mid-20th century tech/engineering firms, perhaps especially small- to mid-sized operations ran the business on a "cost plus profit" strategy. Dream up a product, try to make a realistic guess how many units will be sold, calculate the cost of manufacturing that number of units, plus shipping, marketing costs, dealer markups necessary to attract dealers, etc other assorted fixed and variable expenses.

Then set the unit price so that if the target sales numbers are met, then there will be some profit left over at the end of the ordeal. If sales don't meet expectations it means break-even or loss on the project. If sales sufficiently exceed expectations then per-unit costs PROBABLY will fall and then profit will also exceed expectations.

I've always been sympathetic to that way of thinking about it, perhaps because of early education, natural inclinations and also these methods were taught as "the way to do it" in some industrial engineering, business and accounting courses I took long ago. Maybe something else is taught nowadays.

Back then the problem with this approach from a "cash strapped customer's perspective"-- Tech products which might sell thousands or even tens of thousands did not really get above the "advantage of scale" price hump which would allow reduction of price. Things like high-quality speakers or nice oscilloscopes or early personal computers tended to be painfully expensive while the manufacturer was still "barely meeting salaries and paying the rent".

In the articles I recall, companies such as early HP, Nonlinear Systems and the early Commodore company were cited as examples of mid-weight tech companies initially following a "cost plus" business model.

The articles praised a "new way of doing it" where price is estimated based on unrealistically huge sales figures, and you do a big push selling way below cost trying to build up an avalanche of sales by "priming the pump" with early evangelistic adopters buying the first units sold at painful loss. Lose money on every sale but make it up in volume.

So Commodore started selling crazy cheap and moving lots of units. NLS quit making lab gear, morphed into KayPro and sold zillions of "unrealistically low-priced" computers (considering the era). HP seems to have followed a similar route, selling lots of computers and printers at prices which probably caused accountant panic attacks, rather than selling modest numbers of insanely expensive oscilloscopes, voltmeters, spectrum analyzers, etc.

Some writers considered that speculative business model "the next big thing". I suppose some companies and individuals became fabulously wealthy with a "bubble economics" model, but such as Commodore or NLS/Kaypro didn't last regardless how many "really low price" products pushed out. OTOH "cost plus" businesses also routinely fail.

I'm still sympathetic to a conservative business model. Perhaps low risk of becoming fabulously wealthy but also a lower risk of going bust. Though biz is always risky. Maybe the majority of fabulously wealthy tech success stories were bubble-riders initially skirting as close possible to the brink of insolvency?

But with a mature market full of competition, nowadays bubble riding might offer few chances of success. Maybe cost-plus strategy, trying to be as competitive possible on tech while also cutting overhead as lean possible? Low overhead allowing low prices, provided that enough units can be sold to pay the rent and keep the lights on, etc.