I would like to detect whether my macOS app executable file has been altered by someone.
I wouldn't rely on the Codesign because, as I have seen on the web, many apps have been cracked, even if notarised by Apple. I know this will not guarantee the top security, but I would add this custom protection anyway.
A) If I add a checksum file within the Resources folder in the bundle after the app has been Archived (so within the xcarchive package), it's too late. The app won't launch because of the manipulation. I get a crash with "Termination Reason: Namespace CODESIGNING, Code 0x2".
B) If I add or modify the checksum file after the app has been notarised, the same, it won't launch.
C) If I modify the checksum resource file with a shell script during the build phase, before the "Run Copy Bundle Resources" phase, the checksum is wrong since the executable at that moment has a different file size and file modification date.
So, what's the best way to add my own checksum file to my app bundle?
I run macOS 10.15.6 and XCode 11.5 and compile my 64 bits app for macOS 10.3/10.5.
If I understand correctly, you're trying to verify that your application is as you shipped it? And you're worried that codesigning isn't enough, as it might be "cracked"?
I do not believe this can be solved by using any kind of checksum. Anything that can compromise codesigning, can also compromise your checksum.
I would instead look at the new Apple Attestation API. This is designed to allow an application to verify that it is running on Apple hardware, and is the codesigned version. (A modified and signed application would fail this -- it's codesigned by a different key)
https://developer.apple.com/documentation/devicecheck
Related
Our application has bitcode enabled, so we can't use dSYM files generated on our machines/CI but rather we should use dSYM generated during bitcode compilation. The problem here is that we don't have those files available to download on App Store Connect (no link is presented).
That's really weird. We suspected that maybe our 3rd party tool which we upgraded recently and that is used to obfuscate our binaries started to work incorrectly but all builds get "Validated" status and we can publish them in App Store without any issue.
I suppose that bitcode process runs correctly as we get smaller binaries available in App Store, but dSYM is somehow not produced.
I found a thread on Apple Developer Forums but nothing really uncovers the root of this issue: DSYMs No Longer Offered for Download?
Im able to submit my app through Xcode 6.3.2 perfectly fine. Validation and analyzing pass perfectly. Once it successfully submits to the app store though I get an email from Apple:
"Dear developer,
We have discovered one or more issues with your recent delivery for "App". To process your delivery, the following issues must be corrected:
Invalid Signature - Code object is not signed at all. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose "Clean All" in Xcode, delete the "build" directory in the Finder, and rebuild your release target. For more information, please consult https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html
Once these issues have been corrected, you can then redeliver the corrected binary."
I have tried redownloading the distribution cert, regenerating the distribution provisioning profile, added "--deep" to the code signing "Other Code Signing Flags." I even checked the bundle name etc, everthing is alpha numeric. I was able to submit fine on May 22nd, now on June 3rd everything breaks.
Doesnt make any sense, any help would be appreciated!
UPDATE & SOLUTION:
While I don't have a good explanation of why this suddenly has happened within the last week, I finally found a solution this morning.
I started with a new project and submitted to the app store with nothing but the identifier and correct version and build numbers, which processed fine. After that I started piecing in any assets that wasnt my own code until I got the "Invalid Binary" email. I narrowed it down to the Hockey App SDK (embedded framework) which was causing the issue and not even being used anymore so I removed it from the project (problem solved). The disturbing part is that nothing fails on my end during validation or submission and according to github this directory and content hasn't changed in a year, which leads me to believe something changed server side at Apple.
I did see a lot of posts via google saying that frameworks needed signed etc and when using Xcode 6 and iOS 8 it seems to be the standard which is why I assumed it might be something along these lines.
Im not sure how helpful this is as I was building for iOS and this article is in reference to Mac, but HockeyApp explains in order to distribute to the app store you need to sign the framework with your own identity here:
http://support.hockeyapp.net/kb/client-integration-ios-mac-os-x/hockeyapp-for-mac-os-x
If anyone has anymore technical notes on this or why this suddenly changed Id love to understand this better.
I've checked a variety of places and there seem to be several things that are now being rejected by iTunes Connect. The solution is typically to remove the offending resource from the Target -> Build Phases -> Copy Bundle Resources (as #azizus mentions). Unfortunately Apple doesn't tell you what file causes this issue with your builds so you have to go hunt for yourself. Here are some items that I've found that will do it:
Shell scripts (Look for .sh files, though they could have a different
extension)
Also, look out for files that are listed as executable, when they
shouldn't be. Those might be a good place to look for shell scripts
that you might have missed.
Frameworks (Framework bundles, even .a or .o files - you
don't need them as they will get compiled into the executable binary)
DocSets (I don't know why, but I found that the HockeyApp SDK
includes a DocSet bundle which was the cause in my experience)
Sometimes this might also happen due to some weird entitlements
issue. The entitlements you have may not match up with the App in the
provisioning portal.
Look out for invalid characters in your app name or file names (like
wildcard characters)
This is a pretty broad list, something I did to help in the search is build an archive and then show the contents of the .app in the archive using finder, sorting by file type. The strange thing is that these files actually exist in the _CodeSignature/CodeResources file.
My own theory on why this is happening is that Apple made some changes (or is making some changes) because of Extensions and WatchKit apps. Essentially, you are including a couple of binaries in the packaged IPA (phone app, extension, watch app). They probably want to make sure you're not including something else that could potentially be executed. Unfortunately, the error message is too vague (really it's incorrect) for most.
This took me 3 days to debug.
In the end it was due to an external framework I created (lets call it X) that I was importing via carthage. X had its own dependencies that it was importing via carthage as well. In order to link these frameworks it had a path in the build settings called Framework Search Paths set to the location of the frameworks. For some reason it was this flag in this framework that was causing the problem specified in the questions. I eventually imported X's dependencies with Git submodules so that I didn't have to set the Framework Search Paths flag. I the exported the framework and manually added it to my project I was submitting to the AppStore. Then it worked.
I can reproduce this when I 'create folder references' for my resources folder as opposed to 'create groups' when adding in.
I contacted HockeyApp and they suggested not to add the SDK to app bundle. So I navigated to Target -> Build Phases -> Copy Bundle Resources and removed HockeySDKResources.bundle from there. iTunes Connect accepted my binary.
In my case it was a info.plist duplicated that was not used. (it wasn't easy find out the problem). I removed almost all the files of my project until remove this one and.. it worked
Clearing the value for Code Sign Resource Rules Path in each target resolved the issue.
I am building an app called 'ToyBox.
When I build for iOS, I get a ToyBox.app directory which contains a ToyBox executable and the other typical iOS-related files (Info.plist, pkg.info, etc.), in addition to my app icons, assets and source code directories.
However the directory also contains another ToyBox.app sub-directory, which itself contains a ToyBox executable and iOS-related files and my assets directory.
It looks like Corona is recursively compiling my app. This happens whether I build for device or the Xcode iOS simulator. There is no problem running the resulting executable on my device (iPad4) or simulating it in Xcode but when I tried to submit my app to the App Store it was rejected with the following error:
"Invalid Bundle Structure - The binary file
'ToyBox.app/ToyBox.app/ToyBox' is not permitted. Your app may contain
only one executable file."
The error is valid - there are two executables!
(At the risk of confusing the issue, I have another, seemingly related, issue: if I build my app (either for device or Xcode simulator) then later build the app with a different name, in the same directory, the second build will include the first build and the build process will take a very long time to complete. If I was to build the app again with a third name, both previous app builds wold be included and the build would take a very (very) long time).
I can probably work around the issue by deleting the extra files, but this seems like a hack and I'd like to know what's going on.
I am using Corona Version 2013.1087 (2013.4.17).
Make sure you are not saving your Built app to the folder with your source code. You cannot put the output from building an app into the same folder with your source or you will get this error.
I'm in version 2.3 of an app I've had in the App Store for about a year and a half. Suddenly, I submit an update to the app store with a few small changes, and now when loaded from the app store, some images won't load on all devices. It is a consistent set of images on a scrollview- it all appears black instead, but there are other pages with fewer images that consistently still work and are implemented exactly the same. No memory warnings. No SDK/XCode/OS X upgrades since last updating the app.
There are a few messages logged to the console, and those print correctly and don't indicate any problems. No errors are logged.
I'm completely at a loss for how to debug this. I'm already getting angry emails about it. I don't have time to keep resubmitting and waiting a week for it to be approved. Any suggestions?
Check the case of your image names.
Do a full rebuild of your app (ie Build->Clean).
Do a fuller rebuild - delete the "build" and simulator folders
Test on several real devices, of different generations and OS versions.
Build an Ad Hoc distribution and test that.
Generally, image problems are caused by the OS not finding the image in the app's bundle.
This can be because the device is case-sensitive whereas the simulator is not, so something that works for the simulator might not work on devices.
Also the IDE can be a bit flaky (hence the full rebuild). For some reason, I've seen resources compiled into the app never get removed, even if I clean the build. The only way to fix this is to delete the build folders, and/or the simulator folders. Simulator folders are at ~/Library/Application Support/iPhone Simulator/4.3.2/Applications/ (or whatever your build version was). You can trash the build folders without worry, but don't delete too much in Application Support or else you might need to re-install XCode; just find the GUID (ABCDEF01-2345-6789-ABCD-EF0123456789) that matches your app.
An Ad Hoc build, especially if you base it off of your Release configuration, will probably be the closest thing to a real build that you can get. There are tricks to using the command-line codesign utility to take a release build and change its signature so that you can run it as an ad-hoc but that's definitely not low-hanging fruit.
Make sure that all your image files are in your test app bundle and submitted app bundle, and not in subdirectories in your test app bundle, and that the upper/lower case and spelling of all file names is identical within all usages inside and outside the app.
We're iOS (and other mobile platform) developers and our sales folks routinely need to provide demos of our apps for clients. What we're trying to do is automate a process so sales people can go to a self-serve website and feed the app into their simulator.
Using xcodebuild we can kick off the build process and then present it as a secure download link (via our intranet) but all that lets them do is install it to their iOS device. This is OK except not everyone on the road has an iOS device (or some have old iPod touches, and that's super slow). So, I was thinking that there's gotta be a way to get it installed in their simulator.
I see that others have hacked it in there by zipping up a simulator directory and placing it on another:
http://discussions.apple.com/thread.jspa?messageID=7680994
Set target to simulator, release.
deploy. stop iphone simulator. zip
your app from ~/Library/Application
Support/iPhone
Simulator/User/Applications/ send it
to someone else, and let that person
know to unzip it in that folder, than
start iphone simulator - and you're
done.
I guess we can do this, but it doesn't seem deterministic (or at least, a lot harder to script). I'd prefer to work with the .app but if the only way to do it is with this hacky copy and paste operation, that'll be what we have to do.
Any thoughts?
This could work: https://github.com/landonf/simlaunch/
I have not tried it yet by myself, but from video looks like the application converts .app compiled for simulator to a launcher, which can be used to run the app in simulator without installing it through xcode.
It probably uses the same kind of approach for simulating the app without installing it first that is described here: How to install iPhone application in iPhone Simulator
I know this isn't a direct answer to your question, but have you thought about having a server (eg a Mac mini) that has all the installed software on it? Then they could just use some form of screen sharing to run the app remotely.
I've used the simulator build mechanism above with a number of clients and once they figure out the right folder to drop the actual folder into, it's gone very well.
It's a little bit of a hack as you say but in some cases it also beats having to deal with ad hoc provisioning etc when it's less important to have it on an actual device itself.
I haven't tried it yet but I've heard pretty good things about Test Flight (http://testflightapp.com/) also as a way to distribute demos/betas so that might be worth a look as well.
I just developed a pair of scripts to (a) extract an app from a iOS simulator, and (b) install it on another iOS simulator. https://github.com/christopher-prince/SimAppScripts
Locate the .app bundle in your built products directory, typically under Debug-iphonesimulator or Release-iphonesimulator. Drag and drop that bundle onto the Simulator window and it will be installed (you may need to swipe on the home screen to show the icon).
You can also script this from the command line using xcrun simctl install. The xcrun simctl launch command can also start the application.
Most build systems can be automated (or you can use a post-build script from within Xcode, ordered as the last step) to create a ZIP of the app bundle and put it somewhere for download.
(If having the Archive workflow support creating Simulator IPAs would be useful for you please file an enhancement request at https://bugreport.apple.com)
check out waxsim:
https://github.com/square/WaxSim
http://cocoamanifest.net/articles/2011/12/running-your-ios-app-in-the-simulator-from-the-command-line.html
If you build it for i386 and distribute the .app, I believe this will work.