Question or issue on macOS:
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
I emailed the author of the Receigen app, they updated the troubleshooting tips right away. I then went on to launch my app. 1.0 had a BIG bug. I then released 1.0.1 quickly with an expedited review. Today I got a support email. They sent me a screen shot of the damaged app dialog. As a new indie dev my heart sank and my stress and insecurity rose. A bash script to generate 'all-in-one' OpenSSL static libraries for OS X and iOS. The script produces fat static libraries (i386, x8664 for OS X) and (i386, x8664, armv7, armv7s, arm64 for iOS) suitable for integration in both OS X and iOS project. Receigen provides an inspector window where you can visualize the signature, the receipt and the entitlements of any OS X application. The inspector shows whether the application is signed or not and whether the application contains a receipt. It also displays the chain of certification for both the application and the receipt. Receigen 2017-12-10. Free To Pc Win MASS Gmail Account Creator Download Dropbox. MASS Gmail Account Creator 2017-12-10. Crystalmaker Download On OS X High Sierra 10.
Also wondering why Apple does not just provide working code for validation?
Recigen Side Effects
Any other good references out there?
How to solve this problem?
Solution no. 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:
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.
Recigen Injection
So I suggest you to take a look at this application: Receigen (Disclaimer: I am the developer of this application).
Solution no. 2:
In order to validate against the real receipt after testing, change this line of code in your main.m file:
to
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
Solution no. 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.
Solution no. 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.
Solution no. 5:
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:
After the app is delivered from the App Store to the end user, the signing certificates are as follows:
Also, I suggest only exit(173) when the receipt is missing, but everything else is in order.
Solution no. 6:
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.
Solution no. 7:
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.
Solution no. 8:
Recigen 44
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.
Solution no. 9:
When creating the sample receipt from Apple Docs, be sure not to include any extra characters after ‘end’ else the uudecode will fail.
Recigen Covid
Solution no. 10:
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:
Recigen Dosage
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:
Rece Gene
Hope this helps!