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

I understand why you'd want the cake without having to bake it. I get that, I really do. But the point is, IDGAF either way. I'm not the one wanting the pre-baked cake, and if I did, much like yourself, I'd go to the store and buy one. If someone wants me to bake that cake for them, well, cough up some cash and make the adventure worth my time.

If they do, then there's a bigger problem to worry about, and it's not DRM.

The whole point of the recipe is for the developer to make the cake. That's what software development is. As for the padlock metaphor NOTHING is crackproof, and I never claimed that it was anyway.

That goes without saying.

Also, they would need to know the following 1) Another client's hardware ID 2) location of every module/software they plan on downloading while directory views on the server are disabled. The cracking part is a lot easier said than done.

They call said company, give them the old hardware ID code, then the new hardware ID code. From there, the administrative side takes less than 5 minutes to do, which the old profile is copied to the new server-side hardware identifier, and the appropriate adjustments are made to the encrypted profile. They restart the application, and the software automagically works. As I said earlier, a 5 year old could do it.

There doesn't need to be, but in order for that to actually work, you have to know the exact make of another user's computer, along with the resulting hardware ID code. It can be done, but it's not as easy as you think.

Less than 2 years ago*

Ah. The target vector would be emulating not only the server, but the actual files that are distributed FROM the server itself. When the user would access their profile (autoloading from 24-digit HWID, based off of hardware identification), the data that dictates expiration dates, hardware codes, modules, modulenames, etc, is where secondary encryption comes into play. Even emulating server side authentication using VMs is a lot more difficult than it would seem, since the actual content HAS to be copied in order for the crack to actually work. This is well above the skill level of most seasoned devs, so again, the weakest point would be the security of said authentication server. It's not crackproof, but it's extremely difficult to actually work around, even using external patching and disassembly. During my tenure at said company, I did months worth of testing, debugging, cracking, etc, to make sure that altering the compiled code would NOT be a simple cakewalk like other applications that are easily vulnerable to an external patching crack. Internal disassembly, once compiled, obfuscated, and compressed isn't exactly anyone's idea of a fun ride at a waterpark.

The reason I left wasn't because I peddled some kind of snake oil, the code works. I gave several live demonstrations in-house, and for their costumer base. The reason I left was because I suffered a secondary fracture to a knee that had been fractured at a different location less than 10 years ago, which was due to negligence on the part of the company and the property management. Not exactly something one can just bounce back from. However, that's really beside the point.

Unfortunately, no, due to the NDA I signed with a previous company I worked for. The entire software archive they had totaled around 2.5GB, which with this, along with rewriting major parts of their main application, reduced the total disk space requirements down to 398MB. And instead of having 20+ keys (in some cases 150+ keys) for each user and application, each user ended up only having 1 key to deal with.

The only reason they didn't implement the new system was because they were "afraid they would somehow screw things up making new user accounts", despite the fact that a 5 year old can handle the server-side/administrative end, along with documentation. I wouldn't put it up if I knew it wasn't fully functional. So as far as I'm concerned, their source code is something I'm not giving out. The code I developed, however, is a different matter. If they don't use it, then it's mine. Plain and simple.

Yep, that would be for checking individual expiration dates for different modules, if the developer is going to use it to manage software content. That's what it's for.

As is every other piece of DRM. Nothing is crackproof, which is why I used the term "(nearly)". With this type of DRM, the more important part is to make sure the authentication server isn't easily compromised.

Meh. I figured the fact its melting point is 327c would have been enough. Guess not.