I have developed an application and want to publish to the microsoft store. I have tried using advanced installer but unless I pay $500 I cannot publish it i think using the trial version? I have also tried using MSIX Package (Windows) but then I need to digitally sign it, and then I can't add logos and etc. I also do not know how to get a certificate and convert it to .pfx format for this to work.
Honestly, this process has just made me want to stop, which is unfortunate. So I am trying to find a service or someone that I can pay to package my .exe app to an MSIX, signed and everything so that I can just upload it to the store on my account..but I cannot find anything on google.
Does anyone know of a service, or even a better application that has better guides for MSIX packaging and signing? Advanced Installer is pretty extensive, but their guides are based on MSI, not MSIX. Not worth paying $500 for when they are not even current with Microsoft Stores required format.
FYI - to get a useful answer around here it helps if you place specific questions (i.e. split your question into multiple ones, like: Do I need to digitally sign an application for the MS Store?; how do I add logos...?)
Back to your problem. I work on the Advanced Installer and I will try to give you some advice to help clear a part of your problems.
First of all, to publish an application in the Microsoft Store you don't need a certificate. As explained in our guide, in your Store developer account you will find a package identity assigned to your application, here is an example:
The value that starts with CN=... must be copied and pasted into your Advanced Installer project, on the Package Information page, under the ID field. Make sure Digital Signing is disabled in your project. (You need to digitally sign the MSIX only when you deploy it outside the MS Store)
This identity will allow the MS team to certify you as the owner of the application. Once Microsoft approves your application submission, the MSIX package you upload will be signed with a Microsoft digital certificate. All MSIX packages uploaded in the store are signed by Microsoft.
I don't know how complex your application is, but most apps can be packaged with the free Advanced Installer Express edition. Have you tried that? The commercial editions include additional features, but you might not need them.
MSIX Hero is pretty great and is open source. Assuming your application is just a directory of files containing one or more EXEs just click "pack directory to MSIX"
Then select the folder containing your application files and the EXEs you want to create shortcuts for in the start menu. It will pull a lot of the package metadata from the metadata in the EXEs.
If you are publishing to the Windows store you don't need to sign the package.
If you do want to sign it for distribution outside the store the options for that are pretty easy to use as well. The only issue is you will need a code signing certificate, which is ~$300 a year.
I'm trying to create a custom CSP(cryptographic service provider) and I'm kinda stuck at signing the csp dll. In the cspdk(cspdk) it is said, that I should use cspsign.exe to produce the signature file that can be included into the dll as a resource. But there's no such a file in cspdk or anywhere in windows.
So I began to google and found some posts that before 2013 people were sending their dll's to microsoft and got it signed in return. And after 2013 you are supposed to use microsoft authenticode and purchase code signing cert for it.
I'm in a development stage so there will be many many builds, so may be there is some simple way to get thing working.
So the question is how this process looks like in 2019?
UPDATE:
I found out that cspsign was a test utility for Windows 2000, so the cspdk is a little bit out of date. The question remains actual ..
Those sdks are so old, with newer versions nowhere to be found, and documentation so sparse. The only reference I found on a somewhat recent process is hidden in here, halfway through the page: Authenticode signing of CSPs
Note Starting with Windows 8, it is no longer a requirement that CSPs must be signed.
So, CSPs no longer need to be signed.
So my situation:
I built an Sideloaded UWP app with Visual Studio. Visual Studio can create an .pfx certificate that is temporary for 1 year. After that you have to recreate another certificate. The year for my certificate is almost over. Now I was thinking of buying such a certificate with more than 1 year of a lifetime.
Now my problem is that I absolutly don´t understand what I actually have to look for. When searching for certificates I find all kinds of SSL Certificates. Do I need SSL certificates for my case? Because it seems this is some web related certificate. Then there are EV OV DV, S/MIME Email Certificates and everything just does not seem right.
Code Signing OV is the closest I could find.
There also are alot of other different Code Signing certificates. Some list details like: "Authenticode, Office VBA, Java, Adobe Air, Mac / OSX, Android"
Some other just list the detail "Multiplatform" on like 5 different offers that all look the same and when you look into the description those informations are probably important: "32- und 64-Bit-Files like .exe, .cab, .dll, .ocx, .msi, .xpi, .xap and Kernel-Software" + "SHA-1".
Then there are CodeSignings like this "Microsoft Authenticode (Multi-Purpose)" with "SHA-2"
And this are just a few examples. There are alot offers and I understand neither of them. Just give me a working .pfx file.
Anyway
I was hoping that someone could help me understand on what I should be looking for if I want to have a certificate for my Sideloaded UWP app similar to the certificate that Visual Studio can create.
You need a code signing certificate which can be bought from digicert for example. Please refer to the their support page for more information about how it works.
If you need a public certificate, you'll find a special offer on this link.
I am trying to figure out if I am in a potential bind here. I am having someone else develop my app and I have given them complete access to my developer account to create the certificates to build the binary. I have uploaded the binary using the Application Loader and it it now waiting for review by Apple. My question is when it comes time to update the app, will I be able to do so without using the programmer who signed the certificate? When I become competent I'd like to do this myself but I'm clearly not there yet. I don't want to be in a situation where I have to keep going back to the same programmer to do the smallest thing.
Yes, provided you:
Have them send you the signing assets as described in "Exporting Your Code Signing Assets to Your File System" in the Xcode documentation. Note that they will still be able to sign using your key.
Have them send you the original project, obviously.
Once you part ways with them you should change the passwords of any accounts they've been given access to, like Apple ID and iTunes Connect.
At a later date, or as a last resort, you can create new signing assets as described in "Reset You Signing and Provisioning Assets..." in the Tools Workflow Guide.
So, most important going forward, they must not have access to any Apple accounts belonging to you.
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?
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).
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
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.
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.
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.
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.
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.
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");
}
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.
When creating the sample receipt from Apple Docs, be sure not to include any extra characters after 'end' else the uudecode will fail.
Yes, in their docs it says, "It is important that you employ a solution that is unique to your application."
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):
Log out from Mac App Store app.
Remove USE_SAMPLE_RECEIPT flag from your project settings -> Preprocessor Macros.
Compile your project
Find this app in Finder
Double click it in Finder to run. Do not run it in Xcode.
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.
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.
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