
I Can Crack Your App With Just A Shell (And How To Stop Me) - SeoxyS
http://kswizz.com/post/2785664228/hacking-mac-apps
======
snorkel
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.

~~~
phillco
Brilliant, but be careful about this. There was an article here years ago
about an indie game developer who put tons of different piracy checks all
throughout his game. He was pretty clever, and made it so that several didn't
activate until partway through the levels — that way the crackers might miss
them. Also, he didn't show any "pirated copy detected!" messages, which would
have made the checks trivial to find. Instead, the application would simply
crash with a cryptic error message.

It worked perfectly — the crackers missed the later checks. Anyone who
torrented the game found that it crashed reliably as soon as you completed the
first level. Game over.

Unfortunately, this did not generate the kind of PR he was hoping for. In
fact, all this did was give the impression to everyone who pirated the game
that it was a buggy piece of shit. Since there was no obvious reason for the
odd behavior, they assumed it was the fault of the application. They stormed
the gaming review forums and discussion boards, complaining about how the game
was "shitty" and "unplayable". Nobody was keen to mention that they had
pirated it, so there wasn't an obvious trend. At the time, the ratio of
pirated video games to legal ones was about 10:1, so the bad feedback
overpowered the good feedback by about 10:1. He was ruined.

Be careful about anti-piracy. You just might succeed.

~~~
coderdude
I mentioned this game in another comment on this page, but Spyro: Year of the
Dragon used this technique and it worked very well for them. It could be that
this is because it was on a console and not on the PC, but who knows. The goal
for them was to simply keep the crackers at bay for as long as possible to
keep the sales high during the initial release of the game. The developers
stated that once the game is cracked the sales drop dramatically, so the
longer they can keep the game uncracked the more money they made.

Great article from the developers about this:
[http://www.gamasutra.com/view/feature/3030/keeping_the_pirat...](http://www.gamasutra.com/view/feature/3030/keeping_the_pirates_at_bay.php)

~~~
asnyder
I remember playing Spyro, good memories. I think there's a new one out, maybe
I'll check it out for old time sake. Thanks for the positive nostalgia

------
moopark
The fact that most simple copy protection can be broken by someone that knows
a bit of assembly shouldn't surprise anyone writing applications, and this
post is just self-congratulatory silliness that doesn't actually help someone
that wants to protect their software.

It wouldn't be any more responsible/ethical/useful of me to post a "I Can
Crack Your Non-Mac App With Just A Copy Of IDA Pro and HexRays" tutorial. I
could show you how I can press 'F5' and decompile your code back to
surprisingly readable pseudo-C, but that's not going to help you secure your
application, it's just patting myself on the back and showing you how cool I
am.

On top of that, the author is _still_ flogging the PT_DENY_ATTACH horse,
despite the fact that it's been documented over, and over, and over again as
trivial to bypass. PT_DENY_ATTACH was added to meet the minimal contractual
requirements Apple had to movie studios and record companies by preventing
users from attaching a debugger to DVD Player and iTunes. It's not a real
security solution. There's a simple open source kext (that was first
implemented for Mac OS X 10.3!) that simply disables it across the board:

<https://github.com/dwalters/pt_deny_attach>

~~~
Confusion

      The fact that most simple copy protection can be broken by
      someone that knows a bit of assembly shouldn't surprise
      anyone writing applications, 
    

But it does, which is the point of the author.

    
    
      this post is just self-congratulatory silliness
    

You know, some people just like to write up something they did that they think
is pretty interesting. People will keep inventing the wheel over and over
again and still be proud of their wheel. This kind of derogatory remarks are
uncalled for. You have no idea about the thoughts or feelings of the author
and have no reason to think ugly things.

If I were to respond to your comment in the same way, I would say that you
were just displaying your superiority complex over someone learning the ropes.
Or perhaps bitterness and jealousy over the attention this article gets, while
your more advanced knowledge does not get the attention it deserves. Or ...
whatever. I can come up with a number of epithets to attribute to you based on
that little bit of text, all equally uncalled for.

------
kennet
Hey SeoxyS,

Another fan of your writings. I like the occasional quote you throw in there.
However:

I don't agree with the way you phrased your headings. Verging on linkbait,
even.

RCE is a hobby of mine and I crack all sorts of shit; it's fun and
challenging. I know quite a few people who do.

This is the first time I have read such a blunt "I can crack your..."/"How to
stop me" approach. It sounded very arrogant at first. No one else that I know
bothers with this direct attitude. I am sure Mac devs are more than aware
(Anticipating an article on this as a followup to your post).

"[...] but implementing a bare minimum of security will weed out 99% of
amateurs. [...]"

I am not sure where you pulled that number from but it's false. RCE is not as
difficult as you make it out to be, and amateurs can overcome the usual
barriers quickly. Communities thrive on teaching amateurs the art, and they
pick up these skills very quickly. I taught a few.

------
bermanoid
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 reality, they're not actually hurting your business as badly as your
delusions tell you they are - none of them were ever going to buy your shit
anyway.

Add features, improve your design, fix bugs, or tweak your shitty description
and screen shots in the app store (which, in my experience, will affect sales
for most apps more than the first three factors put together). Literally any
time that you devote to copy protection is wasted, unless you're Angry Birds
(and even then I'm not sure) you're not reaching anywhere _near_ a high enough
percentage of the people that would happily pay for your product to worry
about the ones that would rather just take it.

~~~
nait
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...

------
dangero
The App Store doesn't need high levels of security on your apps. No matter how
much you obfuscate, it only takes one smart person to crack it and then your
app is on all the bit torrent sites.

People will buy from the App Store because they want the protection it
provides and the convenience. They know when they download your app from the
app store that it's not a virus, the install will be one click simple, and
Apple has hand reviewed and approved the app.

I think the Mac App Store protection is designed to be just enough to stop
Average Joe from copying it onto a usb stick and giving it to his friend. In
the end that's really what you want.

------
morganpyne
Another fairly easy way to do this kind of thing is to use the
DYLD_INSERT_LIBRARIES variable. You can reverse engineer the classnames with
class-dump, subclass a class and override a suitable function e.g.
IsLicenseValid() to just return true; You can then start your program and
insert your new subclassed class into it like this:

$ DYLD_INSERT_LIBRARIES=/path/to/your/Subclassedlibrary.dylib arch -i386
/Applications/OriginalApp.app/Contents/MacOS/OriginalApp &

And on a sidenote, I thought it was funny to see him refer to something as
'badly spelt' - I thought that 'rye' remark was a bit 'corny' (rimshot :-)

~~~
SeoxyS
I didn't know about that, that's really neat! Will need to do some research
into that!

PS: I'm poking fun at myself—since I wrote the original app, including
misspelling. Also, I use American english, but I do prefer to use the british
form of 'spelt' or 'burnt.'

------
Locke1689
Meh, decoding compiled C code is about just as easy for me. I wouldn't worry
about it until it becomes a serious problem. The people who crack many apps in
the scene are pretty decent at it and this will not slow them down.

Edit: Actually, they're not very good at it, but this still won't slow them
down much.

------
ay
Some people also view the windows as an invitation to throw the stones in,
claiming they are too fragile to be of any protection anyway.

Next time you buy a DRM-ed book from Amazon.com, or watch a film you can not
make a copy of, you can contemplate that the protection there is much better
than in some Mac app.

Would that make you happier as a user ?

The way to solve this problem is to spend more time on adding more features
into the frequently released newer versions of software. Cracking all the same
basic reg code would get boring for a few-dollar app.

~~~
jbri
The challenge then is to write a script that automates the cracking.

~~~
ugh
But does that actually matter? As far as I can see, it’s already easy to
pirate any app you want. All you need is Google.

I’m suspicious that super secure DRM really stops people from pirating,
especially when considering something non-essential with many (maybe worse but
often free or more easily piratable) substitutes. Super secure DRM might be
more effective with something really unique you really cannot get any other
way like games (but those will be cracked anyway, won’t they?) but some app? I
doubt it.

~~~
jbri
I would actually lean the other way. If your system is far more secure than
another identical system, people are less likely to bother targeting your
application when they break open the other one much more easily.

It's only when you bring something unique or "better" to the table that you
make it worth spending significant amounts of effort on breaking.

------
middus
Well, that's more than just a shell.

~~~
SeoxyS
How so?

~~~
yuvadam
vim, gdb, hex editor...

~~~
SeoxyS
All of which run inside a shell.

~~~
enneff
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 written huge
pieces of software with "just a shell". In fact, the foundations of modern
computing could be said to have been built with "just a shell". (ie, before
they had GUIs) See how silly it sounds?

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

------
oniTony
A much more interesting dive into exploring a binary's internals, at DEFCON
CTF difficulty -- <http://hackerschool.org/DefconCTF/17/B300.html>

------
m0shen
_$ sudo brew_

Not really necessary -
<https://github.com/mxcl/homebrew/wiki/installation#sudo>

------
dedward
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)

------
jmillikin
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 have access to the
application, so they can know exactly how to generate the digest; all they
have to do is run the bundled digest function in gdb, copy the output, and
then search for it in the installation. Even if the author tried some sort of
obfustication (xor, deflate, reverse, etc), such attempts would show up in the
binary and could be trivially duplicated.

A second is that the digest is somehow pre-computed for a binary before it's
built, then included in the binary itself. But I don't see how this is
possible with secure digests. And if the method is simple enough that it's
worth using for typical iOS applications, what prevents an attacker from pre-
computing a digest for the cracked version?

~~~
TheAmazingIdiot
No. Effective means of protection are when you "roach motel" the data.

The first rule of software engineering is you never let the shareware stuff do
it all. Test version should not save? Rip it out. Shouldn't print? Remove
printing. Chop it out wholesale.

If you do an unlocking scheme, then make it subtle. Take a hint from Unix
development: dont tell the user that the code worked or not. Just take the
code or whatever. Tomorrow, then tell the user if it's a bad code.

And if it's in the blacklist, don't tell the user at all, and instead start
introducing subtle errors everywhere. "What, you saved it yesterday and now it
doesn't open? Whoops (snicker)." Or, misalign printing so anything looks good
for a draft but not 'professional' use. Or you could go the obvious route of
slapping a banner on it, but that is usually easily removable.

The idea here is to be subtly annoying up to the point of just doing nasty
shit to the data worked with in your program. And of course, give error codes
in a form of a md5sum that tells the company if you're a pirate or not.

But as I said earlier, put the time you would protect the program instead as
improvement to make your program do its task better and easier. Crackers find
these to be challenges. They just crack to keep their chops up.

~~~
burgerbrain
_"And if it's in the blacklist, don't tell the user at all, and instead start
introducing subtle errors everywhere. "What, you saved it yesterday and now it
doesn't open? Whoops (snicker)." Or, misalign printing so anything looks good
for a draft but not 'professional' use. Or you could go the obvious route of
slapping a banner on it, but that is usually easily removable"_

"Gee, I'm sure glad I decided to pirate [program], it's buggy as hell. Better
warn my friends..."

~~~
coderdude
Spyro: Year of the Dragon used a similar technique to great avail. Don't be so
quick to dismiss this method of deterring crackers. It just needs to be done
right. There are arguments going both ways on this issue so it's simply not
black and white. Perhaps it works better for games than applications, but
again, you'll find arguments going both ways for games and apps alike.

------
EGreg
I personally like the idea of an application "unlocking" itself every time
based on a hash of its binary. You would have to find all the places these
hashes are computed -- if you missed even one place, you wouldn't be able to
unlock the app.

Of course, such an app could still be cracked -- as could any app... because
all you have to do is

1) purchase a legitimate copy and enter a fake name 2) take a snapshot of a
working, unlocked app 3) remove all the code that cripples that state

The only way to really prevent cracking of apps that run locally is either
challenge-response dongles or requiring people to provide a strongly verified
identity in order to unlock the app (that way the cracker can't distribute the
app without compromising the identity of the original buyer). And that is just
too inconvenient for the actual buyers. Once again, security at the price of
convenience.

~~~
daeken
> The only way to really prevent cracking of apps that run locally is either
> challenge-response dongles ...

This doesn't really work. If you have all of the functionality running on your
machine but the dongle is there to authenticate, it can be cracked by ripping
out the code that does the challenges. The proper way to secure an app using a
dongle is to move some key piece of functionality out to hardware instead.

~~~
EGreg
good point! You need some functionality though where the response can't just
be memoized by the crack. What could it be?

~~~
daeken
Depends on the application, really. I can give you an example of where I've
personally considered using this (ended up going with an alternative,
however): my startup's product is a hotel front desk system and we have to
encrypt room keys to work in the locks; pushing the crypto off onto an
external device would make it considerably more difficult to pirate the
software, as you'd have to reverse the algorithm and reimplement it in
software. In the end, it didn't make sense for us, but it would've been pretty
solid, as the odds of you having two identical cards is monumentally slim (and
would only even be _possible_ every couple of years).

------
andrewljohnson
People crack and hack our apps. We don't think it's worth fighting.

And moreover, we have a link on our home page that says if you email us, we
will give you our apps for free. Some people take advantage of this offer, but
the vast majority of users do not.

------
lelele
I think we are exploring the wrong issue here. We shouldn't be looking for a
non-crackable scheme, we should be striving to find a scheme to recognize
customers who are willing to pay and reward them.

------
dlsspy
I wrote labrea for similarly playing with apps:
<http://dustin.github.com/2010/12/03/labrea.html>

Specifically, the PT_DENY_ATTACH thing should be possible to be, itself,
denied with labrea (though in practice, I've run into runtime linker problems
with that exact call that I haven't quite figured out, but I haven't put much
work into it).

------
Kilimanjaro
Price your app exactly at a point where people with money will gladly pay for
it instead of suffer the hassle of downloading crapware-infested copies. And
let people without money copy it freely without barriers, and see it as a
marketing tool so everybody use your app, not your competitor's.

That price usually is between $0.99 and $9.99 and thank Apple for showing us
that lesson.

------
mml
I recall Intellij Idea IDE had some pretty decent protection. They used an
"encrypting" class loader (of the xor variety), and also encrypted all their
resource files. I have a lot of respect for the lengths they went to, though
i'm not sure how much it benefitted them really.

------
16s
Linking statically helps too (not sure that's doable with Apple) then
stripping and packing.

------
pwim
If your a developer for Apple, presumably you are selling your apps through
the app store. Apple get's a cut of the revenue for apps. So if it was
worthwhile to have a more complicated DRM scheme, wouldn't Apple provide it?

------
jckarter
Crackers aren't your customers. Don't waste time/money on them.

------
mcantor
For the definition of "Shell" used by the author, isn't the title basically
the same as saying "I Can Crack Your App With Just A Computer"?

------
vinhboy
Thanks for writing a detailed step by step tutorial on this interesting topic.
I have always wanted to learn more about this stuff.

------
xster
Excellent article, especially with code

------
TheAmazingIdiot
Gah, this is your standard 2 byte change_je_to_jne.

Perhaps, to people who program in higher languages this is not evident, but
old assembly programmers know this stuff well. Even for the newer ASM
programmers, we had Fravia+ (may he rest in peace) to teach us the ropes on
reverse engineering and unprotecting 'nasty' code.

And those students of Fravia+ know something well: if it is viewable,
executable, listenable on a device you own, you can do anything to it. He
recommends taking what you would have put in for protections and make your
program better by that much. Or prepare to protect the hell out of it (and
release every day, munging the exe).

~~~
morganpyne
Oh no, I did not know that Fravia was dead. Spent a lot of time reading his
stuff years ago. RIP Francesco.

~~~
TheAmazingIdiot
Sadfully, he passed May 3, 2009.

Here was HN's article and responses:
<http://news.ycombinator.com/item?id=600523>

------
albertogh
#ifdef DEBUG

    
    
        //do nothing
    

#else

    
    
        ptrace(PT_DENY_ATTACH, 0, 0, 0);
    

#endif

I really have a hard time taking advice on copy protection from someone who
doesn't known about ifndef.

Furthermore, PT_DENY_ATTACH won't help because any cracker worth is salt will
just open the binary with an hex editor and remove the call to ptrace(). The
other two tips to prevent cracking are, at best, as useless as this one.

And just in case you're wondering, those three methods are equally useless on
iOS.

~~~
daeken
To avoid having to modify the binary (and thus deal with checksums and the
like), you can alternatively break on ptrace where the first arg ==
PT_DENY_ATTACH, then have it immediately return. Easy to do in GDB.

------
mobileed
Amature crack for an amature protection.

------
shashashasha
Read this title as a Mario Kart reference. Oops.

