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.
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.
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.
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.
I'm glad you left the rest of the source code out that generates the inital hardware spec. If someone wants to add additional layers of modified hashing they can. The stuff you're complaining that's lacking is already in there. Each system will generate a unique 24-digit hardware ID code.
That's generally the idea to bypass most types of DRM. External/Internal patching is not a new thing. However, even disassemblers still have problems with truly decompiling P-Code, since most of the internal routines are technically "undocumented" and have been for quite some time. More than that, code obfuscation techniques aren't new either, and by definition, anything can be cracked. It just depends on how much work you want to put into it.
As for an API wrapper, considering that most of the code is a direct result of CLI scripting, the actual workaround would be to modify/fake batch scripts on the fly. The only way to do that is to either rewrite portions from the source code itself, or do an internal jump/patch (internal or external, doesn't really matter), which defeats the purpose anyway.
Look, if you're upset that it's written in VB6, fine, whatever. Unless you've actually got something like a direct proof of concept exploit, you have nothing to bring to the table. As for other things, I'm well aware of my own skillsets and limitations. That's why I don't just limit myself to programming. Unfortunately, I would have to make a moderately (un)educated guess that the extent of your interest in this discussion is simply to bitch because you can.
If total overhead increase of 200KB for compiled application size, and ~3-5MB memory overhead for non-invasive DRM is a joke, then yes. But not as much as MS extending support until 2024 to allow for the "migration to.NET". At that point, I'll have moved onto other things.
Again, MAC spoofing has been around for a while. That's why there is static information brought up beyond just a MAC address, which if you have a motherboard that has the capability to change the MAC address, good for you. Now, if you'll go back and read a little, you'll notice that there is a function for server-side verification. If the idea is that you're going to fake information for an entire system through windows CLI, good luck with that, bruh.
Yeah, nearly. I didn't say it was FULLY crackproof, but you have to know what you're doing in order to bypass it. Which is why server authentication is BUILT IN. So, unless you've got a direct proof-of-concept exploit, such as faking burned in MAC address codes, along with simple bios info (which amazingly, can be brought up via windows commandline), I would make the educated guess that you're upset in regards to me further maintaining already solid code which someone else can build on.
That's why it's free. If someone doesn't want to use it, I don't lose any sleep over it anyways.
Slashdot Mirror
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.
I'm glad you left the rest of the source code out that generates the inital hardware spec. If someone wants to add additional layers of modified hashing they can. The stuff you're complaining that's lacking is already in there. Each system will generate a unique 24-digit hardware ID code.
QED
3/10 - Ctrl + Mouse Scrollwheel = Zoom in/out.
That's generally the idea to bypass most types of DRM. External/Internal patching is not a new thing. However, even disassemblers still have problems with truly decompiling P-Code, since most of the internal routines are technically "undocumented" and have been for quite some time. More than that, code obfuscation techniques aren't new either, and by definition, anything can be cracked. It just depends on how much work you want to put into it.
As for an API wrapper, considering that most of the code is a direct result of CLI scripting, the actual workaround would be to modify/fake batch scripts on the fly. The only way to do that is to either rewrite portions from the source code itself, or do an internal jump/patch (internal or external, doesn't really matter), which defeats the purpose anyway.
Also, you might want to look into this, since it doesn't exist. https://en.wikipedia.org/wiki/...
Look, if you're upset that it's written in VB6, fine, whatever. Unless you've actually got something like a direct proof of concept exploit, you have nothing to bring to the table. As for other things, I'm well aware of my own skillsets and limitations. That's why I don't just limit myself to programming. Unfortunately, I would have to make a moderately (un)educated guess that the extent of your interest in this discussion is simply to bitch because you can.
Well, that's generally the idea when it comes to refining specific skill sets.
CLI = Command Line Interface.
It's called Teflon, unless I'm mistaken.
If total overhead increase of 200KB for compiled application size, and ~3-5MB memory overhead for non-invasive DRM is a joke, then yes. But not as much as MS extending support until 2024 to allow for the "migration to .NET". At that point, I'll have moved onto other things.
Again, MAC spoofing has been around for a while. That's why there is static information brought up beyond just a MAC address, which if you have a motherboard that has the capability to change the MAC address, good for you. Now, if you'll go back and read a little, you'll notice that there is a function for server-side verification. If the idea is that you're going to fake information for an entire system through windows CLI, good luck with that, bruh.
Yeah, nearly. I didn't say it was FULLY crackproof, but you have to know what you're doing in order to bypass it. Which is why server authentication is BUILT IN. So, unless you've got a direct proof-of-concept exploit, such as faking burned in MAC address codes, along with simple bios info (which amazingly, can be brought up via windows commandline), I would make the educated guess that you're upset in regards to me further maintaining already solid code which someone else can build on.
That's why it's free. If someone doesn't want to use it, I don't lose any sleep over it anyways.