5 points by bad_boomerang 20 hours ago | 8 comments
The org sells to a very niche luxury market and distributes a native application at a high price. The execs at this company are extremely perturbed by the appearance of cracks of the software that appear sometime after every release. The issue is that our present architecture as a native application means the attacker already has root and we cannot protect any key, there are also domain specific reasons why some users will always need to be remote at some point. While I want to encourage the org to eventually move to a client-server architecture we could protect, the need to provide the remote copies means all we can do is create puzzle boxes via security by obscurity, that are cheaper to unlock for an attacker (in terms of their likely hourly rate) than for us to create.
I believe they are over-reacting to the emergence of these cracks by pushing the dev team to introduce more checks into the software and thereby harming productivity and potentially even stability of the software while also failing to solve the issue. To give you an example of my fear; I was talking to one of our devs recently about a dependency issue where some extra license checks had been baked into the UI and I was encouraging better composition to extract these sorts of checks to a specific layer instead. They replied "but if we put all the license checks in the same place, won't that make it easier to crack?".
I appreciate this is probably a red flag and I should run but I believe myself to be a convincing person and I would like to try. They are a little old-school, so I feel like a gentle approach is necessary. For the most part I am wanting to attempt to reframe the issue from a "tech problem" to a "social problem" and focus less on adding more security by obscurity and more on tracking down where the leaks are coming from where consequences can be enforced via license agreements.
So I appeal to you all to help me with this endeavour. I imagine some of you have been in this sort of situation before, and have experience I could draw from, or might have knowledge of various sources I can use. The one that springs to mind for me is the issues that big online gaming companies have with aim-bots or other cheats in markets where the value of the hack is close to the zero and the resources of the engineering department trying to defend are high; to demonstrate the futility of the approach. However I worry a little, that given the old-schoolness at play that gaming might not be an example they will be receptive to.
Conversely, if anyone has any counterpoints or suggestions about low hanging fruit, outside of simple obfuscation and/or hardware dongles, this would also be appreciated, as it might help if I can also suggest something from their angle that beats the typical curve of severely diminishing returns.
al_borland 13 hours ago
More to your question, if you need to sell this to execs, you need to talk in terms of dollars. How much is this change going to cost? How much will it make or save them? What are the risks to the business if it isn't done? The more abstract or hypothetical the risk or financials, the less likely they are to buy what you're selling.
Sorry I can't give any specific suggestions, as I'm having trouble conceptualizing what the product is. What is this key you need to protect? A product license key that they want to validate without an internet connection? Is that the goal?
bad_boomerang 12 hours ago
I mention keys because of suggestions that encryping things in a stand alone, fully offline product achieves anything, given those values will have to be unencrypted on the device that the attacker controls, in order for the values to be useable, thereby rendering it somewhat/entirely pointless.
> More to your question, if you need to sell this to execs, you need to talk in terms of dollars. How much is this change going to cost? How much will it make or save them? What are the risks to the business if it isn't done? The more abstract or hypothetical the risk or financials, the less likely they are to buy what you're selling.
This is a good argument and is something I want to touch upon. The issue is that the fear is much like how the RIAA and MPAA reacted to the advent of the internet. As we saw then, the person with the fear can invent their own numbers, given its all off-book so its not measurable. I can certainly focus on aspects of the dev cost but I fear it might be challenging to wrap it all up in a convincing fashion when put up against an unmeasurable fear.
al_borland 11 hours ago
Is the fear they have that solid practices would make things easier to crack well founded? If you make the changes you want to make, will it put an end to the cracks, or will you spend a lot of time/money on development costs and end up in the exact same place or worse?
What are the risks if you do the client/server thing? Are you going to phone home? What are the risks there? Now if someone is offline they can’t use the software. You now have to maintain a license server until the end of time. If the company goes under, the clients will lose access to the software they paid for. Is that something the clients are OK with? Do your competitors have similar network requirements, or would that be a reason for clients to look elsewhere?
You bring up the RIAA and MPAA. These industries had to change their entire business models to adapt to the piracy threats to their businesses. And they didn’t even solve the problem themselves, it took other companies to solve it for them and drag them along, because they were desperate. If that’s the kind of change you’re talking about, the execs have every right to be scared. They have something that works today, even if it’s not perfect, and a new model might not work. If the changes aren’t that extreme, I don’t know that I’d use that analogy. If the execs are desperate, the company is in trouble, and something needs to be done to save it, than maybe it is a good analogy, but the execs seem more scared of change than worried about cracks. Is that the right read?
There is also the question of if these cracks actually have an impact on business. Most people I know who download a lot of movies would never pay money for them, even when they are free they don’t watch most of them they download. A download isn’t always a lost sale. Product keys tend to be a lot like door keys, they keep honest people honest. As long as you have enough honest customers, how much money should you spend fighting people who were never going to be customers, no matter the cost? Can some of these cracked versions also lead to future sales? Kids in school may be cracked copies of Adobe software, they learn on it, and then once they have jobs they are customers, because they already know and like the software from the experience on the cracked version. Probably less of an issue now with subscriptions vs how it was 20 years ago, but cracked software can act as trials and a means to lower the risk for future buyers, because they can try before they buy.
I’m bouncing all over here, but another thing you might want to explore is fear setting [0]. Outline what the fear is, what’s the worst thing that can happen, and what you can do if those worse case scenarios happen. That could help reduce the unknown and bring logic back into a room that has been run by a fear of the unknown.
bad_boomerang 55 minutes ago
As the package is delivered in completeness and runs entirely offline I believe there is no possibility in guaranteeing its protection. Ultimately you can load the app into memory, work out (slowly) what parts are performing checks and recompile the app while removing those parts. While I imagine initial users are paying, somehow the software is falling into the hands of those who wish to the crack it. So the process is just a factor of time. Without an architecture that puts the hard to reproduce part somewhere else that we can protect (e.g. a client-server architecture that is vital to the function of the app), there is no guarantee. From my perspective the only value beyond setting some bar of difficulty (which we already have) is perhaps finding ways to fingerprint the software so we can narrow down the origin of the cracked edition (as its much harder for the attacker and beyond their interest to scrub non-functional breadcrumbs from the binary).
You're right to bring up the trade-offs but given the money at play and the level of support we offer for the product it transitions quite well into a service as opposed to a product. There are obviously issues around such a switch but I believe it does fit into the business model. In terms of competition I am told that for the most part we are streets ahead and have little to worry about at the moment.
> If the execs are desperate, the company is in trouble, and something needs to be done to save it, than maybe it is a good analogy, but the execs seem more scared of change than worried about cracks. Is that the right read?
I don't think the execs are necessarily desperate, but I'd have to look at the financials to be certain of that. I believe that its just that they fear, and are looking to add value and have simply happened upon this as an obsession. The company is reasonably old with a consistent executive team for most of its life, so I just think they have that 80s/90s attitude to technology that hasn't been updated. I'm still trying to get a feel for the organization, but there appears to be a lack of structure which allows execs to effectively directly control the development department. I'm sure if I get a stronger handle on scheduling (which I expect to happen over time) then this issue is going to come up and we might clash over it, as I believe shipping the product (still with some level of copy-protection) is more important that over-fitting the copy-protection and slipping on the schedule. Their development practices themselves need some serious updating and it would be absurd to focus on adding more copy-protection when they don't even have proper continuous integration. There's lots to do.
Their fear isn't entirely unwarranted, they do good work enforcing compliance with current customers and I agree that there's considerable value in chasing the clients with the money to rectify their non-compliance, and I imagine often such issues are accidental as opposed to intentional. There's a lot of money in this market and those benefitting from the software definitely have the ability to pay. However looking at those who are not paying and may never pay as lost revenue is a mistake imho that they're making, but its about how to frame that. I imagine someone has already made such an argument and was hoping to stumble across their resources.
Thank you for the link and the idea of fear setting. Hopefully I will get the time to sit down and better understand their concerns, prior to framing a response.
v5v3 17 hours ago
Who hired you? Have you spoken to that person?
>I was talking to one of our devs recently
He or she isn't your dev, they are your clients. You are a temp.
bad_boomerang 16 hours ago
Its a little awkward, the chain of command is a little ad-hoc. So lets say the person who hired me is one of these execs. They were quite excited to hear about my knowledge of security which was dampened when they realised I was more talking about auth and securing endpoints as opposed to smth like DRM.
> He or she isn't your dev, they are your clients. You are a temp.
that particular detail is intentional noise. So sadly that advice doesn't apply.
Like I said, the attitude is so pervasive that I worry that it will interfere with the successful delivery of the product. That part, regardless of the noise remains pertinent.
tacostakohashi 13 hours ago
Let the owners, board of directors, management, and employees figure it out.
bad_boomerang 12 hours ago