Hello,

I am the owner of a very small (just me!) software development company. One of my apps has been cracked by someone using the name DEVOTiON and I'd like to know how, if at all, I can reach the cracker to find out more about the weaknesses of the protection. (One version was cracked the very day I put in on the server).

As it happens, the crack is incomplete, too, and I'd like to share this information with the cracker so that he/she doesn't get labelled as lame when the crack proves to be ineffective!

Thanks.

If I where the author of an app and it was cracked incompletely I would keep it to myself. Just my thoughts... There are many things you can do to make cracking harder. Just read a bit through the forum.

Read the NFO that comes with the crack. It might have the contact information for their group.

Usually the authors don't tell them their crack is incomplete though. The crackers usually figure that out themselves sooner or later and update their crack.

Indeed, sympathy for the reputation of a cracker who cracked your own app? Sure, you might get him/her to point out the weaknesses of your code, but this only means she knows your code better than you do (from a crackers perspective).

You would do better to analyze the code yourself, again from a crackers perspective, and learn to protect better in the process. You could start by comparing the disassemblies of the cracked and original versions to find out exactly where things were patched (assuming it was a crack produced and not a keygen). This should immediately point out the weakest spots. There are "bindiff" utilities you could use for this but you should be able to do it manually just as effectively.

To begin with, you should start with the assumption that your app *will* be cracked no matter what you do. It's usually a matter of when not if. Don't be upset by this, but just take it as a given. There is the theory that the longer you can have your app uncracked, as in weeks or months - not years, then you have a chance of reaping some profit from it by attracting registered users.

Developing a moderately effective protection might take months or years itself, depending on how many of the "tricks" you are already aware of. You could use a commercial protection but you would be better off not relying on that alone, and of course you have to factor in the cost of it as well.

There are lots and lots of protection strategies, all dependant on your coding abilities, time and desire. There is of course much information on this and other sites on the very subject, though not always laid out in black and white, you will have to dig.

Good luck,
Kayaker

http://fravia.com/protec/protec.htm

But, as Woodmann said above, it will be cracked anyway.

Dude, just give up on software products and turn your app into a web service. Then there's nothing to crack

JohnnyMcRonny, can I suggest a different approach? Your app has been cracked, and you've made it clear to the cracker that further work is needed for the crack to be complete. In other words your current protection now offers zero value.

In light of that why not write a detailed post here explaining how you coded the protection and how it works. Then we can pick holes in it and show you where the weak point are.

What LLXX suggests is valid, but if you're like most coders you won't want to spend 6 months getting a reasonable foundation in RCE - and that's the only way you're going to be able to *reliably* assess how your protection looks from a cracker's point of view.

Be very aware that what I'm suggesting is also effectively a roadmap for others to use to crack your software, so you need to weigh up the choice: disclose all the information now, rendering the current version worthless but giving a fighting chance for the next version, or keep the information private and hope further cracks don't occur (very unlikely).

disa: web service? pa-fooey!

kayaker: bet you I can code an app that can't be cracked

yep it wont run you cant crack the best protection ever invented

Well in my opinion if I was he cracker I would not tell you where i the right patch.
As you said the application is not cracked but that is nothing.(until when?)
Basically i prefer Silver's idea to write how you coded and to try and find the holes.Interesting project.Will it success?Time will show

Well, no one has done what he wanted, ask "what's the name of your app" this is either a thinly veiled crack request, or a fishing expedition for info on Team DEVOTiON, there a several threads already here that discuss what the the opinions of this forum's members are on various protection schemes, Just my cynical opinion!

SiGiNT

I second Silver and Wasted_bytes, detailing the protection you implented and finding holes would be interesting for you and for us.

Death and taxes are inevitable.

I would add "cracks" to that short list.

Live your life just the same as before.

dunno, i'd be quite suspicious about you wanting to 'find' the cracker, as you may have other motives.. the fact that the crack isn't complete means that you arent really going to lose a customer base, as those using the warezed copy will have an incomplete crack..and how can you respect a cracker who made an incomplete crack...

why not analyse his crack, in doing so you will most likely see the weaknesses, and if you really want to have a weakness analysis, then might i suggest you give information / url to your product so some people (along possibly with some real serial codes etc or stuff that might be required to get it operational) here could play with it and might report weaknesses for you (if that is indeed your aim)...

My second 2 cents - people pay for software that proves it's worth - there are many examples, take WinZip - for a long time this was one of the easiest apps around to crack, it was often recommended as a target for newbie crackers, the company did not really suffer financially because of this, people always would prefer to have a "legal" copy of an app they use frequently, but if you offer a product with limited usefullness then chances are that cracked versions will put a significant "ding" in your revenue, I find it hard to believe that operating as a one man operation your servers were monitored closely enough to have it cracked on the day the latest version was released - in short a few more details might be usefull, no one here likes to see a hard working developer lose his due.

SiGiNT

One possible explanation - he uploaded it to a distro-service like Download.com, and by coincidence the cracker was scanning the "latest submissions" list at the same time. That's how I've picked targets to play with in the past. And, no offence to the OP, but if he homebrew'd the protection then it's probably like many apps on there - 2 or 3 byte patch to crack. It's that knowledge gap he won't be able to fill without serious work.

Anyway, let's see what he says.

Actually, I'd estimate a few hundred crackers (or "suppliers" are scanning software listing sites at any moment in time. The groups usually are in competition with each other to up their release counts, which explains how quickly new apps get cracked.

One of the best approaches I heard of is the following..

Quoting:



don't know who's the guy who is behind this, but definitely is a smart approach.

interesting... that's a clever way to proactively dupe future cracks

When I encounter such bad cracks I make my own for personal use It's however smart to be ahead of the 0-day crack release scene. I like the idea.

Maybe I have found a couple of times some of these "cracks", because they didn't unprotect all the limitations, and when this happens one is thinking: "how a cracker could be happy releasing this crap?"

For instance, for an old PE Explorer release I found some cracks, but never found one defeating all the limitations...

And here is the answer. Never thought about this posibility, it seems imagination is powerful...

Thanks for the info Shub

Cheers

Nacho_dj

Wow - thanks for all the replies....

I'll try to answer some of the points raised.

Firstly, I am the author of the application in question - I'm not phishing for anything here.

The application is a video-related tool that sells for all of $15 (!)

The existing crack restores an expired trial period but doesn't remove a spoiler that gets put on the video processed by the app.

I'm using, for better or for worse, Armadillo/Software Passport. I understand that providing a trial version that doesn't require a key is a weakness (the so-called 'DEFAULT' certificate). My app is like this. However, the 'spoiler' logic sits within an Armadillo Secured Section - may be that's why it is still intact?

Looking back on the code, the defenses are flimsy and minimal (based upon reading much of the information on this website).

As it happens, sales of the licensed version are small compared to some customization work that I was asked to do for another software house. And, in a way, this particular app was a stepping stone on a path to a more advanced application that is in very late beta. I hope to release that app within the next month or two.

So, I want to learn from my mistakes with the current app before making the new one available. Some thoughts I have had on this:

1. Obviously create some pretty obscure transformation algorithms for key variables etc that control the licensing logic
2. Combine Armadillo with a second option - e.g., EXECryptor. I have dabbled with this idea and successfully created an Armadillo-protected trial version of a program that uses EXECryptor to mangle the Armadillo function calls.
3. My new app is heavily multithreaded - a few checks that cross thread boundaries may help
4. Don't use the DEFAULT certificate but, instead, require that the trial version has a key. I use RegNow for the eCommerce - I should be able to provide both trial and permanent keys via the RegNow portal.
5. Don't use mirrors/repositories like Download.com but limit the availability of the downloadable package to RegNow.
6. Make the app freely available for non-commercial use. Rely on honesty of those using the app for profit-making reasons to purchase the license.

One question came up about how could the cracker get the new version so quickly. Two possibilities (beyond those already suggested):

1. I maintain a list of email addresses of people who download the trial and - voluntarily - choose to be notified of new versions. I send an email to the list when I upload the new version
2. A popular forum for my kind of app maintains a list of apps and, I've noticed, news of my updates occurs very rapidly (either someone on the group advises the rest of the group or the forum has a robot to sniff out new versions)

My rationale for seeking out the cracker? Some advice I read (on this site, I think) suggested it. Basically, ask nicely and point out that I'm a one-man band and not a Microsoft-style behemoth....

Anyway, I hope this answers some of the questions raised?

Thanks!

my 4 cents:

The use of commercial protection packages (Arma) is a double edge sword: It saves you from the learning curve and extra effort of diving into low level coding, encryption and re-inventing the wheel. But have the problem that once some cracker(s) solve "the tricks" of the protection, it gets published in the wild, and pretty much all the apps protected with the commercial package bite the dust rather quickly.
Some protections are more challenging than others, offering polymorphic code, customizable options, generators of diversity, but in the end, a human being or a human team of protectors can only have a finite number of ideas. Eventually an experienced cracker develops intuitive problem solving skills that allow us to find alternative (lateral) solutions to un-protecting the code.

2. The cost, in money and effort, of the app protection should be commensurate with the app cost and expected earnings. In fact cracked apps tend to become popular and widespread, provided the contents is innovative, attracting equally warez hunters as well as legit shareware users. So in the long run, what you lose in sales income for the near term may translate into sales volume in future releases, if you are in for the long run.

Which version of 'dillo are you using? I've unpacked several 'dillos, and they all seemed equally easy. BTW, the secured sections thing is for code that you intend to only be present in the full version, e.g. additional features. Otherwise you're basically "protecting" something that could just be removed entirely.

I'm using the latest available (so, for the crack app, whichever was the most recent about 4 weeks ago - 4.62, I believe.

The secured section bit uses a kind of reverse logic - if it gets stripped out, the 'spoiler' will be displayed.