Verify License API

Hey John,

Everything can be cracked (every licensing solution, every "anti-crack" solution, every "in-memory" protection", etc.). Nothing can stop cracking. But that's not the point of licensing: https://wyday.com/limelm/features/why/

If you want to re-verify with the activation servers, use the IsGenuineEx() function.

If you want to embed TurboActivate in your app, use the static libraries.

If you want to ensure the TurboActivate library hasn't been modified, then verify it in your app. (Of course your app can then be cracked, but that goes without saying) This does, however, prevent the "replace with a DLL" laziness. So a cracker will actually have to spend a half-minute cracking your app.

To sum up:

1. Nothing can stop cracking: https://wyday.com/limelm/features/why/2. You can remove cracked versions of your app from the search engines using DMCA request, thereby making them invisible to "real people".

The whole point of this will be to prevent cracking. Users should not have to result to DMCA requests when it's very possible to prevent 99% of cracking.

Simply calling the methods from the DLL are not good enough. They can be patched. I have written a patcher for limelm myself in very little time.

What limelm needs is a global variable feature, or API support to verify a license w/ its fingerprint.

Otherwise, it will continue to be cracked with little to no effort.

Exposing the internals of the algorithm will not prevent cracking. It will create extra work for you with zero benefit.

Either use the static TA / TF libraries, or verify the dynamic library at runtime before you call any function.

Sigh..

You're clueless. I give up.

>> "You're clueless."

I disagree. What you're asking for can be cracked easily. So... what's the point in doing it? It literally provides zero benefit, and effectively re-creates the TA_IsGenuineEx() function (while simultaneously making it more difficult and prone to errors). Why would we waste developer time on re-implementing a worse version of something we already have?

Trust me (or don't -- I guess that's your prerogative). I know a thing or 2 about reverse engineering. What you're suggesting won't be useful to any of our customers. I gave you alternative suggestions that "solve" the same problem you're presenting. Are those suggestions I put forth uncrackable? Nope. Why? Because absolutely nothing is uncrackable.

If you're looking for a company to sell you uncrackable protection, there are plenty of hucksters out there who will take your money. We're not going to lie to customers.

Also, see this article: https://wyday.com/limelm/features/why/

Unless I completely misunderstood your original post. You are talking about "anti-crack" methods right? If not, then I don't understand what you're asking.

This is where you are wrong. I know what I'm talking about. I have been reverse engineering arguable the 2-3 largest applications that use your service. The one I'm trying to protect, uses the second genuine call. But guess what? It's worthless. It can be patched, just like the original call. What CANNOT be patched, is a server sided licence verification.

It would be incredibly difficult to spoof RSA/AES license verification. That is why it is necessary to have a server sided license check. Passing through license details (product key, fingerprint) through the RSA/AES server exchange would allow server-sided verification (should you implement the web api function) of a license.

Why is this necessary? Doing so would allow data to be sent encrypted from the server to the client. Information that would otherwise render the application useless without it.

This way, they can patch limelm all day long, but they wont have the server sided information that the client application requires to properly function.

Hopefully we are on the same page now.

JohnSmith is right.It took me less than 3 hours to make a universal patcher for TurboActivate on .NET Windows.

It is very possible to prevent patchers.

It just takes a bit of time to actually fix your crummy licensing solution.

Anyone with native knowledge would be able to outright patch the turboactivate dll thus making my crappy .net patcher look like crap.I know people already have done that.

[Snip]

DeltaLockat wrote:> JohnSmith is right.> It took me less than 3 hours to make a universal patcher for TurboActivate> on .NET Windows.> > It is very possible to prevent patchers.> > It just takes a bit of time to actually fix your crummy licensing solution.> > Anyone with native knowledge would be able to outright patch the> turboactivate dll thus making my crappy .net patcher look like crap.> I know people already have done that.> > [Snip]

Is this why both of my programs were cracked within the first week? 🤔 If there is a better way to secure it, why not implement it? Am I spending thousands of dollars on licensing in the wrong place?

oPryzeLP wrote:> DeltaLockat wrote:> > JohnSmith is right.> > It took me less than 3 hours to make a universal patcher for TurboActivate> > on .NET Windows.> > > > It is very possible to prevent patchers.> > > > It just takes a bit of time to actually fix your crummy licensing solution.> > > > Anyone with native knowledge would be able to outright patch the> > turboactivate dll thus making my crappy .net patcher look like crap.> > I know people already have done that.> > > > [Snip]> > Is this why both of my programs were cracked within the first week? 🤔 If there is a> better way to secure it, why not implement it? Am I spending thousands of dollars on> licensing in the wrong place?

Indeed. Hate to break it to you, but LimeLM is pretty shit for actual security.

You can salvage it by using getfeaturevalue. Make your program depend on feature values.

johsmith96 wrote:> oPryzeLP wrote:> > DeltaLockat wrote:> > > JohnSmith is right.> > > It took me less than 3 hours to make a universal patcher for TurboActivate> > > on .NET Windows.> > > > > > It is very possible to prevent patchers.> > > > > > It just takes a bit of time to actually fix your crummy licensing solution.> > > > > > Anyone with native knowledge would be able to outright patch the> > > turboactivate dll thus making my crappy .net patcher look like crap.> > > I know people already have done that.> > > > > > [Snip]> > > > Is this why both of my programs were cracked within the first week? 🤔 If there> is a> > better way to secure it, why not implement it? Am I spending thousands of> dollars on> > licensing in the wrong place?> > Indeed. Hate to break it to you, but LimeLM is pretty shit for actual security.> > You can salvage it by using getfeaturevalue. Make your program depend on feature> values.

Well I have a new program coming out in a couple months. The target demographic is modders (EZ cracking) but my programsha e become a joke. They've been pirated to hell and DMCA only goes so far. Mega doesnt respond, and to bypass the google blocks people just make flum threads linking to the blocked page.

my email is oPryzeLP@gmail.com just in case this gets removed. Might we talk via email? I don't wish to bring limelm down with any negative talk in this support forum.

A couple things:

1. Nothing can stop cracking.

2. You can avoid the whole cracking problem altogether by making a web app, which is basically what you're describing john. What you can't do is have trivial communication to/from the server. Your app essentially has to be run from the servers.

Of course, then you're running a web app and you don't need licensing at all.

I explain this further in depth if I'm confusing you.

Wyatt wrote:> A couple things:> > 1. Nothing can stop cracking.> > 2. You can avoid the whole cracking problem altogether by making a web app,> which is basically what you're describing john. What you can't do is have> trivial communication to/from the server. Your app essentially has to be> run from the servers.> > Of course, then you're running a web app and you don't need licensing at> all.> > I explain this further in depth if I'm confusing you.

This is where our convo got to Wyatt. Basically I would have to do it all server side. Well I'm still not convinced entirely though because all it took to bypass my software within the first week was 2 bytes changed in hxd. Now my software has become a joke and Im still paying $150 per month. Why at this point? Any recommended solutions Wyatt? Obfuscation?

Thank you for nothing wyatt. Even with your poor lack of documentation and web api resources, I was able to create my own solution with limelm.

It's super hacky, but it works.

> 1. Nothing can stop cracking.

100% prevention, no, you're right. But upwards of 90% is very possible, as is with the hackey implementation my partner and I created for our client.

> 2. You can avoid the whole cracking problem altogether by making a web app, which is basically what you're describing john. What you can't do is have trivial communication to/from the server. Your app essentially has to be run from the servers.

But once again, you're wrong. Just because something requires web authentication does not mean it should be a web based platform.

Encouraging your users to not obfuscate their code is blasphemy. Your licensing system is a joke, and without obfuscation it's childsplay to any reverse engineer worth 2 grains of salt.

Obfuscation can be reversed easily. Just because you don't understand that doesn't change that fact.

If you're determined to use obfuscation there are a handful of free offerings out there. Don't waste your money on one, though. Why? Because they can all be reversed very simply. And they don't stop cracking.

Why? Because nothing stops cracking.

The point of licensing is not to stop cracking. The point of licensing is to increase your revenue by preventing casual piracy (using serials over and over again). There is real money to be made by stopping casual piracy.

See: https://wyday.com/limelm/features/why/

Obfuscation and anti-crack methods aren't licensing. They're snake oil. They provide no value (because they can be reversed simply by a cracker with moderate experience).

>> "Just because something requires web authentication does not mean it should be a web based platform. "

Again, I think this really is just a case where you don't really understand how cracking is done. You seem to have a basic grasp of rudimentary cracking, but not much beyond that (and thus you're spreading a lot of misinformation).

"Web authentication" doesn't stop cracking. TurboActivate does "web authentication" (i.e. online activation): http://wyday.com/limelm/features/why/#hardware-locked-descr

The *only* way you can make an uncrackable app is to have it hosted completely on servers under your control. But then you've just made a web app.

Just "pinging" a server, or sending junk data to a server and waiting for the ultimately pointless result doesn't stop cracking. It just forces customers to always be connected to the internet. And if you're doing that then you might as well make a web app and truly be uncrackable, rather than just pretending to be.

Read these 2 sentences again from my previous post: "What you can't do is have trivial communication to/from the server. Your app essentially has to be run from the servers."

There's a lot of information packed into those 2 sentences, but the key word is "trivial". In other words, if the the data being communicated to/from the servers is non-emulateable, mission-critical, app logic, then what you're describing will actually stop cracking. But guess what? You've just make yourself a web app, and you might as well host the rest of the logic on servers as well.

I honestly can't tell if you're a troll, John, or if you're well meaning but just don't understand these topics as well as you're pretending. But either way I'll be glad to dig into these topics further in depth. At least until I feel like we're going in a loop.