Live data from Hacker News

I Can Crack Your App With Just A Shell (And How To Stop Me)

kswizz.com

81–90 of 93 posts

Re: I Can Crack Your App With Just A Shell (And How To Stop Me)

#81
post #20

The most stealth cracking countermeasure I ever witnessed was the application would XOR some of its UI messages with the hash sig of the application binary file, so if you edited the application binary file directly the crack seemed to work just fine ... but then the application would gradually go insane. The cracker who finally posted a working crack was impressed with how simple and devious the countermeasures were…

I am almost certain Ableton Live for the mac does something like this. It is a piece of music production/performance software. It will appear to function normally, but the audio engine will gradually begin to fail in increasingly ugly ways, especially when you use plugins.

It usually starts doing this after a few weeks or months of regular uninterrupted use. Considering this app is used by professional musicians to perform in front of audiences of thousands of fans, having the possibility of the app crashing hard at a random time hanging over you is a pretty powerful disincentive against piracy.

Over the years, many cracking groups have tried and failed to overcome this. The guys at ableton are extraordinary programmers and they've obviously done a number on this one.

There were even rumours that one of the top audio software cracking group members was actually an ableton developer, and that they leaked these devilishly broken builds to the warez scene themselves.

Re: I Can Crack Your App With Just A Shell (And How To Stop Me)

#82
The only "real" copy protection would be trusted-computing right down to the hardware. Signed binaries, with the signature database ultimately in hardware and controlled by a single party.... and even then, we'll have jailbreaks and keys leaked.

But seriously - this was interesting in and of itself, for those who don't know the tools. The whole concept of copy protection and registration is a war that can't be won. Denying unregistered people proper updates seems to me, form experience,to be the most effective deterrent - I don't like to apply updates if I'm not sure if it will cripple my app because I used a weird serial # - and nobody likes to run a "keygen" these days because who knows what it does.

In the end - all software is piratable, and usually by those who won't pay for it anyway.

With the declining price of software and mass-markets like the app-store, more people will pay. (I like a certain piece of SSH terminal software for windows - but I don't use it, because I'll be damned if I'm going to pay over a hundred bucks a seat for it - it's not THAT much better than the free alternatives. If they brought that price down to something reasonable, I'd use it all over)

Re: I Can Crack Your App With Just A Shell (And How To Stop Me)

#83

Earlier quoted context omitted.

If lots of games used similar methodologies then people would slowly learn that "pirated game" == "buggy game". Wouldn't work unless lots of them did the same thing of course.

No, they don't have anything to compare it with. They'd never figure out that it's because stuff is pirated.

Exactly. It's even worse if you add the crippling behavior later on, i.e. in the upgrade from v1.2 to v1.3. All pirates notice is that the new version is really unstable.

Re: I Can Crack Your App With Just A Shell (And How To Stop Me)

#84
post #77
post #20

The most stealth cracking countermeasure I ever witnessed was the application would XOR some of its UI messages with the hash sig of the application binary file, so if you edited the application binary file directly the crack seemed to work just fine ... but then the application would gradually go insane. The cracker who finally posted a working crack was impressed with how simple and devious the countermeasures were…

Why bother with stealth? My favourite approach is the Microsoft approach. It pops up, says "I'm cracked, click here", which takes the user to a web page that shows them all the benefits they'll reap if they get a legit version, just type your credit card number in this box and all is forgiven. It's hilariously easy to make your installation legal, which is the point... it's easier than pirating it, AND you get benefi…

Just wanted to add that this is the exact opposite to what some large game companies do. I bought Settlers 7 (an Ubisoft title) and got kicked out of the single-player campaign every time my internet connection blipped. In contrast, had I pirated the game, I would have had a paradoxically better experience. No incentive to buy, whatsoever.

Re: I Can Crack Your App With Just A Shell (And How To Stop Me)

#85
post #33
post #11

Earlier quoted context omitted.

All of which run inside a shell.

I think you misunderstand what a shell is. All these apps run within a _terminal_, the shell merely invokes them. The article's headline made me a little excited to see some cool bash hackery (there's a lot of functionality packed into bash, see its colossal manpage), but when I saw it was just the usual debugger/patch/etc routine I was disappointed. By the standards of this post's title, I could say that I have writ…

There was a time I did everything in a shell...

Re: I Can Crack Your App With Just A Shell (And How To Stop Me)

#86
post #28

Near the end of the article, the author mentions that storing a digest of the binary is an effective means of protection. I've heard this before, but I've never understood how it works. There's two ways I can think of: One is it just builds the binary, runs it through SHA1 (or whatever), and stores that digest somewhere in the installation directory. But what's stopping attackers from just changing the digest? They h…

If you have access to enough computing power maybe you can store a digest of the binary while including the digest in that same binary. That would make it a LOT harder to just change, but would also slow down things like security patches.

If you have enough computing power to do it, so do the crackers (but usually even moreso)

Re: I Can Crack Your App With Just A Shell (And How To Stop Me)

#88

The great danger in the fight against piracy is that it's so damn interesting . You can spend months playing cat and mouse with the people trying to crack your schemes, ratcheting up the complexity to insane levels, and every time you come up with a new scheme and get it working you'll feel like a million bucks because you Won(tm). But the people on the other side feel the same way, there are more of them, and in rea…

I agree. The arms race of building 'better' copy protections instead of continous improvement of your product won't do you any good. I think the main key is deciding on the investment. The amount of time put into those things can be expressed in money. So this poses two questions: 1. Would I be willing to pay the given amount to someone else to do it. If not and I still want to do it I should at least admit that this is for personal ambition and not for the product. It's OK everybody likes a challenge. 2. Will it improve my sales? Again the money. What stands to gain from this. How much effort is OK. Perhaps the simple checksum in addition to the common cmp jne check is enough to get a few sales. But that's about it for products with a market where uncracked time is not king. Look somewhere above for the gamasutra article about game releases and the value of time. And I think the time constraint doesn't work for many products.

The idea for one of my projects was to say "if you are able to crack it you can keep it". If someone spent the time and has the ability to do it, it's fine with me. Surely this is no viable solution for most products. But I'm curious how it will work out...

Re: I Can Crack Your App With Just A Shell (And How To Stop Me)

#90

Earlier quoted context omitted.

Forgive my numbness, but how does this work? How do you know the right signature to be verifying against? It seems (to my not-much-of-a-programmer mind) that you've got a chicken and egg scenario here. But that's obviously not the case, so you can explain briefly how it works? Or just paste a link. Thanks!

You move the UI messages into a separate resource file, as you would for language translation. The executable signature is unaffected by the changed UI messages.

Alternatively, you could use a broken hash and modify an unneeded string so as to produce a collision with the key you decided ahead of time.
Post reply on HN