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.

It's pretty easy to lock down these things via hardware. In fact, I have a working model that's (theoretically) infinitely scale-able on any given server, ignoring file number restraints from the hosting provider. http://www.tot-ltd.org/WMSDK.h...

I thought the whole point of a search engine was to use its own results first.