Mac App Store Receipt Validation Code?

Question

Wondering if anyone has a tutorial or working code for the new Mac App Store's receipt validation? About the only references I've been able to find so far are Apple's stellar documentation on the topic and one open source project which compiles but doesn't have a lot of inline comments so it's hard to understand unless you are a crypto whiz.

Apple docs for registered devs only:

https://developer.apple.com/devcenter/mac/documents/validating.html

Roddi's ValidateStoreReceipt (looks promising, but sparsely documented):

https://github.com/roddi/ValidateStoreReceipt

Also wondering why Apple does not just provide working code for validation?

Any other good references out there?

Answer 1

It is hard to provide a generic solution for Mac App Store receipt validation, mainly because this is a very sensitive piece of code that must be hard to bypass (cf. Apple documentation).

These GitHub projects are very good starting points to learn about what steps must be performed in receipt validation:

• NPReceiptVerification
• ValidateStoreReceipt
• AppReceiptParser

Once you have understood what must be done, here is some advice:

• Don't use Objective-C classes or methods. Objective-C carries a lot of metadata, and its dynamic nature exposes it to runtime injection.
• Only use C function calls. Even if you need more lines of code with the CoreFoundation framework, you can perfectly do what the Foundation framework can do (NSString, NSArray, NSDictionary, ...).
• Don't link dynamically with the OpenSSL library as it has been deprecated in Mac OS X Lion. If you want to go with OpenSSL, link it statically to be sure to have the latest release.
• Use system functions for cryptography. Mac OS X ships with equivalent functions since 10.5. For example, to compute a SHA-1 hash, you can use the CC_SHA1 function.
• Don't put strings in plaintext in your code. Encode them or encrypt them. If you fail to do so, you give a hint about the location of your code.
• Don't use numeric constants in your code. Compute them at runtime, with some simple operations (+, -, / or *). Again, if you fail to do so, you give a hint about the location of your code.
• Avoid simple tests for validation by embedding your tests and the call to NSApplicationMain into a complex loop.
• Avoid calling NSApplicationMain directly. Use a function pointer to hide the invocation. If you fail to do so, you give a hint about the location of your code.
• For each release of your application, slightly modify the validation code so it is never the same.

Remember that receipt validation is necessary and is not simple as it seems. It can consume a lot of time that you may better spend on your application.

So I suggest you to take a look at this application: Receigen (Disclaimer: I am the developer of this application).

Answer 2

In order to validate against the real receipt after testing, change this line of code in your main.m file:

if (!validateReceiptAtPath(@"~/Desktop/receipt"))

to

#ifdef USE_SAMPLE_RECEIPT   // defined for debug version
    NSString *pathToReceipt = @"~/Desktop/receipt";
#else
    NSString *pathToReceipt = [[[NSBundle mainBundle] bundlePath]
        stringByAppendingPathComponent:@"Contents/_MASReceipt/receipt"];
#endif  
    if (!validateReceiptAtPath(pathToReceipt))
        exit(173); //receipt did not validate

and in your compiler settings, "Other C Flags" for your Debug Configuration should include -DUSE_SAMPLE_RECEIPT

courtesy http://jesusagora.org/groups/futurebasic/0::53562:get:1read.html

Answer 3

Be sure to check that you are validating a receipt for your app. Easy to do all the crypto and verification of signatures for the wrong receipt.

See http://pastebin.com/1eWf9LCg where it looks like Angry Birds missed this bit and left them open to people substituting in a receipt from a free app.

Alan Quatermain also has code to do this up on github. https://github.com/AlanQuatermain/mac-app-store-validation-sample

It should not be used as-is to avoid automated removal.

Answer 4

You could try NPReceiptVerification. It's the easiest way to add receipt verification to your app. You just add the class files to your project, set the version and bundle identifier, and everything else is handled automatically.

Answer 5

You can Refer the RVNReceiptValidation it is easy to implement. Just you have to set the Bundle id in RVNReceiptValidation.m file and version of your App. Remember to get the receipt from the apple you have to launch the app from the Finder. This Class also helps in the implementation of InApp Purchase.

Answer 6

I reviewed Alan Quartermain's code and it looks good. Something to think about:

the last parameter here could/should be a compiled requirement stating that the code must be signed by YOUR certificate and no-one else's.

When the developer submits an app to the store for approval, the signing certificates are as follows:

3rd Party Mac Developer Application: me
Apple Worldwide Developer Relations Certification Authority
Apple Root CA

After the app is delivered from the App Store to the end user, the signing certificates are as follows:

Apple Mac OS Application Signing
Apple Worldwide Developer Relations Certification Authority
Apple Root CA

Also, I suggest only exit(173) when the receipt is missing, but everything else is in order.

Answer 7

RVNReceiptValidation is great and it uses CommonCrypto rather than the now deprecated by Apple, openssl. you will have to attach a valid receipt to your project to debug it. Do this by getting a valid receipt from another app bundle and create a build phase in your test environment to add it to your bundle. I suggest the following techniques for obfuscation:

Encrypt the kRVNBundleID and kRVNBundleVersion and decrypt them when you compare them to the CFBundleIdentifier and CFBundleShortVersionString.

I create an array of function pointers with random values and change them to valid pointers to the functions in RVNReceiptValuation at run time before executing them using code like this:

static void testFunction(void);

typedef void (*functionPtr)(void);

functionPtr obfuscationArray[8] = {
    (functionPtr)0xA243F6A8,
    (functionPtr)0x885308D3,
    (functionPtr)0x13198A2E,
    (functionPtr)0x03707344,
    (functionPtr)0xA4093822,
    (functionPtr)0x299F31D0,
    (functionPtr)0x082EFA98,
    (functionPtr)0xEC4E6C89};

int main(int argc, const char * argv[]) {
    functionPtr myFuncPtr;

    obfuscationArray[3] = &testFunction;
    myFuncPtr = obfuscationArray[3];
    (myFuncPtr)();

    return 0;
}

static void testFunction(void){
    printf("function executed\n");
}

Answer 8

I'd propose to implement the code verification routines as C functions, not ObjC methods.

This technique makes it (a bit) harder to locate receipt checking code, since fewer method-names get compiled into the binary.

Answer 9

I'll elaborate on priller's answer. If Apple provided a code sample for the validation process then it would be very easy for a Bad Guy to take your compiled app and scan through it for the code corresponding to the validation process. The Bad Guy would know exactly what the compiled code looks like if you use a standard code sample from Apple. Once the Bad Guy has found that section of the code it is pretty trivial to modify the app's compiled code to just skip the receipt verification stage, rendering the entire thing useless.

All that said, a determined cracker is probably going to get around any copy protection you put in place regardless of what you do. The games industry (for example) spends a lot of time trying to protect their software, and cracked versions seem to always be available.

Answer 10

When creating the sample receipt from Apple Docs, be sure not to include any extra characters after 'end' else the uudecode will fail.

Answer 11

roddi's ValidateStoreReceipt worked for me before, but it does not work any more. I wrote a blog post about the solution: http://vinceyuan.blogspot.com/2012/07/validate-mac-app-store-receipt-2012.html

Copied here: roddi's code is still working. You need not change it. (Just need to get the latest version) Follow these steps (internet required):

1. Log out from Mac App Store app.
2. Remove USE_SAMPLE_RECEIPT flag from your project settings -> Preprocessor Macros.
3. Compile your project
4. Find this app in Finder
5. Double click it in Finder to run. Do not run it in Xcode.
6. The OS will ask you to log in with your Apple ID. Do not log in with your real iTunes account. You need to log in with the test account. Find it or create it in the iTunesconnect website.
7. The OS will say something like "Your app is broken. Download it in App Store". Ignore this message. If you "Show Package Contents" of this app in Finder, you will see there is a file _MASReceipt/receipt. The OS installed a development receipt. We will not need the old sample receipt any more. That's why we remove USE_SAMPLE_RECEIPT debugging flag.

Done. You can debug your app now.

Answer 12

Yes, in their docs it says, "It is important that you employ a solution that is unique to your application."

Answer 13

Even with NPReceiptValidation you still should validate the security of your application bundle including the signing certificates. This is documented in the WWDR recommendations for developers.

A solution: http://itunes.apple.com/us/app/apptight-pro-app-store-code/id427083596?mt=12

One potential problem with NPReceiptValidation is that method selectors on Cocoa objects are very easy to hijack. It's the most popular way of extending apps.

Here's another tool for assisting with In-App purchase parsing:

http://itunes.apple.com/us/app/pkcs-7viewer/id547539804?mt=12