I was more interested in figuring out how to poke in cheat codes. I had made a little TSR thing I had hooked into memory location zero (You just hit reset and instead of resetting it’d call your tsr) which I could then use to try and find where the live decrement counter was. Usually not hard to work out, but completely bamboozling when the code was a bit more defensive against that sort of thing.

So they just XOR’d it huh?

Man, playing around with ARM assembly lately (inlining some time critical operations in a G729 codec) really brought back memories of the days when I had most of the key Z80 opcodes memorised. Good times.

I think I heard knuth saying that back in the day he got a xor matrix wiped off a board in one convention, because it was a state secret

It was a simple loop that would iterate through the *whole* 64K of memory, XORing it against some particular number. The code following the loop seemed total garbage, but once the XOR was applied, it was revealed to be another loop XORing all of memory again with another number. This was repeated many times (maybe 100 times?). So clearly, if you had any other code residing in memory, it would be wiped completely. It was almost like playing CoreWars on a real computer!

And every so often, if you looked at the ASCII representation of some parts of memory that you thought would contain something useful, you found messages from the developers egging you on, or telling you how you’d never break it. Pretty fun really. A lot more fun than the game itself, that’s for sure!

But we arrive at the same conclusion again, the minute the cracker has a way to read the OSs memory, the game is lost

btw, would be great to hear more about your footnote :0) – especially the taunting part

What you suggest is only true for items that are already included in the code (fertilizer, extra garden). But the ones that need to be downloaded from the server would require a bit more work: download it, add it to the binary, and turn off the whole purchase path. I guess the consolation is that someone needs to do it by hand instead of just running a script like they did before to “crack” it.

@Kevin && @John: All a cracker need do is find out where in the code Noel get his server answer and turn a false into true. No need to falsify receipts or anything.

That’s assuming that it’s impossible to craft a receipt that causes the Apple server to return an error code. That’s rarely a correct assumption.

They’d only get things for free temporarily (because the app can periodically check and see if the receipt is valid) and only if the Apple servers happen to be down when they’re trying. It’s a pretty small, and temporary, window.

Good point. You’re absolutely right. If the Apple server fails to respond, then it would be better not to automatically flag it as an invalid purchase. I probably haven’t considered that case because the Apple server has been up 100% of the time, but I think I’ll change it.
Thanks.

One comment, your php function seems to return false if the call to the Apple servers fails. Wouldn’t it be better to give the user the benefit of the doubt in that case and approve the purchase? I see you’re storing the receipts so you can check the next time the client reports to the server.

This would remove any user frustration when either your server or the Apple server fails to make/return from the verification step.