Live data from Hacker News

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

kswizz.com

21–30 of 93 posts

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

#21
post #11
post #9

Earlier quoted context omitted.

vim, gdb, hex editor...

All of which run inside a shell.

I would've been more impressed if you did this ONLY using GUIs. Clickies, checkboxes, buttons - shiny stuff. Command line tools are best and most efficient for reverse engineering IMHO. So if you were looking for an "I built the statue of liberty with matchsticks" type of effect, its kind of a fail, at least on me.

still there is never a reminder too much on security, so thanks for bringing that up.

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

#22

#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…

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.

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

#23
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?

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

#25

#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…

This is useless: task_for_pid() still works, and there's many public kernel extensions out there that just remove this feature entirely.

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

#26

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…

I was under the impression that hashes were there to protect against download/disk errors, or generic viruses/trojans etc.

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

#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.

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

#29

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…

Fravia materials are great, but they are outdated. Techniques are still valid, but the users have changed. Perhaps Mac users are still naive and ignorant when it comes to running random stuff on their machines, but on the Windows side anti-virus companies were fairly successful in educating people on this matter. Scaremongering works :)

So signed executable + few simple validity checks + a couple of well-hidden timebombs that activate when the .exe is messed with - then add witholding the support and automatic updates and this combo works as an effective piracy deterrent. Specifically, it provides enough incentives for those actually using the app to use the official version.

Fravia's great, but there are social anti-reverse engineering hacks to consider.

Post reply on HN