Earlier quoted context omitted.
vim, gdb, hex editor...
All of which run inside a shell.
still there is never a reminder too much on security, so thanks for bringing that up.
21–30 of 93 posts
Earlier quoted context omitted.
vim, gdb, hex editor...
All of which run inside a shell.
still there is never a reminder too much on security, so thanks for bringing that up.
#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…
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?
#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…
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…
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…
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…
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.