I’ve been getting a few visitors through hiderefer.com lately. As a software developer I know what that means. Peel has most likely been cracked and is distributed through a website that routes every link through hiderefer.com or a similar site.
It’s no big news, Peel has been cracked before and I usually don’t waste my time looking into that. This time however I decided to disassemble the cracked version and see what had been changed. After collecting the data from otool I ran diff on both versions.
diff cracked original
1c1
< /Users/hjaltij/Misc/Cracked/Peel.app/Contents/MacOS/Peel (architecture ppc):
---
> /Users/hjaltij/Misc/Original/Peel.app/Contents/MacOS/Peel (architecture ppc):
27066c27066
< 0001c754 bne 0x1c850
---
> 0001c754 beq 0x1c850
37227c37227
< /Users/hjaltij/Misc/Cracked/Peel.app/Contents/MacOS/Peel (architecture i386):
---
> /Users/hjaltij/Misc/Original/Peel.app/Contents/MacOS/Peel (architecture i386):
64993c64993
< 0001c2ec jnel 0x0001c3e7
---
> 0001c2ec jel 0x0001c3e7
That’s not much, only two changes and since Peel is a universal binary it’s just one line for each architecture. I’m no assembly expert but it doesn’t take much to see that a condition has been changed so it evaluates to the opposite of the original. I took a look at the method in Xcode and saw that it wasn’t actually doing anything critical. Instead the method checks if there is any license information in the user’s preferences file and reads it if so. So by inverting these conditions the cracker did not bypass the copy protection but instead made it so that if the user decides to buy a license he will have to enter it every time the application starts.
I’ve always thought that you shouldn’t spend too much time on copy protection because it will eventually be broken but it might be worth the while to see what the cracker did even if it’s only for a good laugh.