AutoHotkey Community

Hello AHK programmers,
I wonder why hackers/crackers are always capable of decrypting the serial numbers, authorization codes and key gene and blab....Companies like MS, Adobe, Autodesk (with hi-end cg tools such as Maya, 3ds), and almost all SW apps available are downloadable from peer 2 peer sites via program like emule since they are almost cracked and patched.

Why can't these hotshot companies take measure to protect their SW apps ? Do the crackers also be able to read the source codes from the SW programms they de-cipher ?( If I drop any AHK-compiled exe into word editor or Res_hacker.exe I can see the textual info of the exe, which shows this app is created with AHK), I don't know if they have better tools to decrypt their target apps.

I am not comfortable to release my SW programs if this situation can't be dealt with effectively, how do I do to sell my apps without releasing any confidential info of mine intercepted by the crackers ?

I know this could be kind of old stuffs to talk about, but it is me who is going to go for it to proceed to making programs for a life-time career. This issue now concerns me. So your experienced info and / or pro opinions are valuable to me

TUIA.
-poserpro

Nuance: hackers are computer programmers, which an implied meaning of high level of expertise. Crackers are hackers using their skill to do piracy of software. Not all hackers are pirate, far from it.

Whatever measure you take to protect software, if it is desirable enough (ie. made by big names in software), a cracker can bypass the protections. Why? Because in the end, the software must run on a CPU in a regular system, so must follow some patterns to be run on every computer.
A good cracker can go down to disassembly of code, to see what is going on, and find out what to bypass or deactivate. It can be slow, tedious, long, but it can be done. At a time, there was a kind of competition: companies made convoluted code, trying to mask the path, to outsmart pirates. But the latter saw this as a funny challenge, and always succeeded in cracking the software, taking pride in doing this the fastest possible. That's why companies like Microsoft progressively abandoned these software locks (they recently abandoned Office Genuine Advantage) as they are costly to design, and overall not efficient.

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

I am no cracker, or hacker.

but tbh, just for fun I sometimes like to enter random stuff into the product key field of a trial program or a "watered down" free version of a product.
I have been successful 2 times (on small cheap programs). and a 3rd time I was successful was on a game where you could get benefits if you had a "coupon code".

Note: I also do this for fun. If my randomness gets me lucky, yay. But I prefer free and/or opensource. I do not illegal download stuff.

_________________
rawr. be very afraid
*poke*
Note: My name is all lowercase for a reason.
"I think Bigfoot is blurry, that's the problem. It's not the photographer's fault, Bigfoot is blurry. So there's a large, out-of-focus monster roaming the countryside."

At the end of the day, the code of the program must be 'read' by a computer (either in compiled or source), so therefore it will always be possible to 'read' the code with human eyes. That being said there are some measures which can be taken to make it harder, but it will never be impossible.

Try reading up on obfuscation and encryption. These things will make the software harder to crack and may stop a few inexperienced programmers from cracking your software, but a seasoned programmer will always be able to find ways around any security you build in.

You just have to accept that if you want to sell software, and it's good enough to sell, there will be people who want to use it that won't want to pay, either by finding other free software that accomplishes the same thing, downloading a cracked copy from peer-2-peer (or warez site), or by cracking it themselves.

David

_________________
With mixed feelings I am stepping down from all moderation responsibilities: http://www.autohotkey.com/forum/viewtopic.php?t=82906

_________________

The quick onyx goblin jumps over the lazy dwarf

Philho's description is good. Especially the part about the thrill that crackers get in defeating protection. If code is too easy to crack, they hold the programmer in disdain. If cracking the protection is a challenge, then they enjoy it and will eagerly await the next revision of the program hoping that it presents new challenges. In the end, it's always cracked.

There was an excellent thread here a couple of years ago describing cracking methods and ways to protect code, complete with examples:

http://www.autohotkey.com/forum/viewtop ... ght=piracy

My own experience has been that simple software protection is the best. Something as simple as entering a ten digit key for instance. Crackers will always crack. Others in the piracy chain will always find a crack. But the majority of users do not know how to do this or where to find it. Including elaborate anti-piracy measures will just frustrate the legitimate user.

A few things to consider. 1) If you write a good program that people find useful, someone will want to steal it if it's not free. 2) The only true protection for your code is not to release it at all. 3) The rules of good computer programming demand a) Good, b) Fast, c) Cheap, Pick any two. If you write something that people want to steal it's either very good or expensive or serves a serious need in the community. The way to help protect your work without a ton of software security is to make a free reduced feature version of your software and open it up for everyone. Make any special features that enhance the free product either a subscription based upgrade or a one-time fee. That way you only have to maintain the upgrades once the free base product is solid. If you are worried about people stealing your stuff, find a different daytime job.

_________________

For one program I developed, an essential component never resides on the user's computer. Users must be internet-connected, and the program makes a request to a remote server, which processes the user's stuff and sends it back. The program passes credentials to the remote server which checks that they are valid and also verifies that a single set of credentials are not being used by many people at once.

It's not bulletproof, but potential pirates are faced with a very different problem.

Depending what the program does, this sort of remote processing may or may not be viable. And even if it is a possibility, it is not without its own downsides. It introduces a potential single point of failure, privacy must be protected appropriately, and users simply might not like it, among other issues.

i'm curious as to the best way to implement something like this.

i've thought of two ways:

1. have the web server send back some hex text which actually serves as MCode for SomeFunc() that the program uses.

2. have SomeFunc() be coded in php on the webserver, and the ahk simply sends a request to the server and the php only returns the return value of the function.

overall this seems like a really good idea

^^That will just make the software totally unusable in situations where it is being used on a computer without a constant Internet connection or where a firewall is up and can't be opened...

Besides, that could probably be patched by someone watching the connection in Wireshark and figuring out what the server is doing. So all you're really doing there is pissing off people who might never have wanted to crack it

its a given that internet is required for this solution.



yes this is a problem i've been considering, hence why i made my post. what would you recommend as a way to solve it? simply sending the MCode of a function back can be intercepted. so using option 2 is a better idea, if we assume that SomeFunc() is a mission critical component and the return value will be constantly changing. the downside is that the app will have to make the web connect each time it needs to call the func to let the PHP do the work of the func

If I had the answer on how to transparently & completely protect software, I'd not post it here. I'd sell it to Sony and retire on my own private island.

Software protection and DRM and all that will eventually need to be handled at a hardware level I think. Good luck with it until then

well the best solution so far is the one Jamie listed, just don't give the crackers the code, and they can't crack it. keep (some of) the code on the server. i'm just brainstorming and starting discussion as to the best ways to approach that

There are SW Protection Systems which actually can't be cracked in usable time span - till now they didn't get cracked. Like mentioned bevore, to get to this heavy protection, not all Code of the Software is allowed to execute on the CPU. Instead, it must be outsourced:

There are Dongle-Systems which execute critical parts of the Software, containing all licencing codes and so on. As the Dongle itself contains fixed hardware algorithms, physically protected against reverse engineering, its very hard to bypass. Until now, there are uncracked dongle Systems.

The drawback of them is that every customer needs such a highend dongle and they arn't cheap. Furthermore, if big software products like AutoCAD which use such Donglesystems, provide Companyversions without those dongle protection, it's clear that the crackers attack those version and in the final result they don't have to deal with the dongles.

Just to make it clear: Most dongles avaiable arn't of that "uncrackable" very secure kind

jm2c

_________________
http://securityvision.ch
AHK 2D GAME ENGINE

This could be solved by using a different response from the server each week. For instance, as well as having program critical code on the server, the server also provides a key to the program to verify it's really connected. Change this key each week and even distibute it to down to the programs and asking for a response so they know what's going on. You could make them date based (run through an algorythm of course), then they could expire if the program isn't updated with the new key. Then if someone did figure out what the server was sending/recieving, the program would only operate until the key was changed and the cracker would be back to square 1.

David

_________________
With mixed feelings I am stepping down from all moderation responsibilities: http://www.autohotkey.com/forum/viewtopic.php?t=82906