krypted.com

Tiny Deathstars of Foulness

Awhile back, I wrote a tool to rewrap ipa files that I called ipasign: https://github.com/krypted/ipasign/blob/master/ipasign.py. But I wanted to do something similar for the Mac, and specifically have it run in Linux. So looking at what you’d need to be able to do, let’s start with viewing the contents of a flattened Apple package. This command will show you the files installed as a part of the Node JS package. Why did I choose that package? It was sitting on my desktop…

pkgutil --files org.nodejs.node.pkg

Now, this logic is available because you’re running pkgutil on a Mac. But that can’t run in Linux. So what would you do if you wanted to complete that same operation? If the package hasn’t been flattened then you can simply traverse the files in the package. If it has been flattened (and it must be in order to properly be signed) then that can’t work. So to see the files installed from a Linux system will require a tad bit more work. First, we’ll create a directly to extract our package into:

mkdir node-v8.11.1.pkg

Then cd into that directory and use xar to extract the package:

xar -xf /Users/charles.edge/Downloads/node-v8.11.1.pkg

In there, you’ll see three files: Bom, PackageInfo, and Payload. The contents, which mimic the –files option to some extent are found by first changing the name of payload to Payload.gz:

mv ./node-v8.11.1.pkg/Payload ./node-v8.11.1.pkg/Payload.gz

Then unzipping it:

gunzip Payload

And viewing the contents:

cpio -iv < Payload

Or throw all that into a one-liner:

cpio -o | gzip -c > Payload

You can also use bomutils to traverse and make BOMs: http://bomutils.dyndns.org/tutorial.html

You can also see some metadata about how the package will lay down by catting the distribution file:

<?xml version=”1.0″ encoding=”utf-8″ standalone=”yes”?>
<installer-gui-script minSpecVersion=”1″>
<title>Node.js</title>
<welcome file=”welcome.html”/>
<conclusion file=”conclusion.html”/>
<background alignment=”topleft” file=”osx_installer_logo.png”/>
<pkg-ref id=”org.nodejs.node.pkg” auth=”root”>
<bundle-version/>
</pkg-ref>
<pkg-ref id=”org.nodejs.npm.pkg” auth=”root”>
<bundle-version/>
</pkg-ref>
<options customize=”allow” require-scripts=”false”/>
<license file=”license.rtf”/>
<choices-outline>
<line choice=”org.nodejs.node.pkg”/>
<line choice=”org.nodejs.npm.pkg”/>
</choices-outline>
<choice id=”org.nodejs.node.pkg” visible=”true” title=”Node.js v8.11.1″>
<pkg-ref id=”org.nodejs.node.pkg”/>
</choice>
<pkg-ref id=”org.nodejs.node.pkg” version=”v8.11.1″ onConclusion=”none” installKBytes=”37377″>#node-v8.11.1.pkg</pkg-ref>
<choice id=”org.nodejs.npm.pkg” visible=”true” title=”npm v5.6.0″>
<pkg-ref id=”org.nodejs.npm.pkg”/>
</choice>
<pkg-ref id=”org.nodejs.npm.pkg” version=”v5.6.0″ onConclusion=”none” installKBytes=”20113″>#npm-v5.6.0.pkg</pkg-ref>

If you want to make a package, check out this gist: https://gist.github.com/SchizoDuckie/2a1a1cc71284e6463b9a.

Next up, you frequently want to check the signature of a package. So to see the signature, I can simply use: pkgutil if on a Mac:

pkgutil --check-signature org.nodejs.node.pkg

Or I can use codesign:

codesign -v node-v8.11.1.pkg

The beauty of codesign is that it’s been open sourced by Apple. The bummer about codesign is that it uses multiple CoreFoundation frameworks:

otool -L /usr/bin/codesign

/usr/bin/codesign:

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1452.23.0)

/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 58286.51.6)

/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

April 24th, 2018

Posted In: Mac OS X, Mac Security, Mass Deployment

Tags: , , , , , ,

The codesign command is used to sign apps and check the signature of apps. Apps need to be signed more and more and more these days. So, you might need to loop through your apps and verify that they’re signed. You might also choose to stop trusting given signing authorities if one is compromised. To check signing authorities, you can use codesign -dv --verbose=4 /Applications/Firefox.app/ 2>&1 | sed -n '/Authority/p' The options in the above command:
  • -d is used to display information about the app (as opposed to a -s which would actually sign the app)
  • -v increases the verbosity level (without the v’s we won’t see the signing “Authority”)
  • –verbose=4 indicates the level of verbosity
  • 2>&1 redirects stderr to stdout
  • /Applications/Firefox.app/ – the path to the app we’re checking (or signing if you’re signing)
Then we pipe the output into a simple sed and get the signing chain. Or don’t. For example, if you’re scripting don’t forget a sanity check for whether an object isn’t signed. For example, if we just run the following for a non-signed app: codesign -dv --verbose=4 /Applications/Utilities/XQuartz.app/ The output would be as follows:
/Applications/Utilities/XQuartz.app/: code object is not signed at all

January 12th, 2017

Posted In: Apps, Mac OS X, Mac OS X Server

Tags: , , , , , , ,

As you may have noticed, we’ve been working on building some links between the App Store and patch management tools such as Casper, FileWave and Munki. We’ve been looking at policy-based management of apps as well. In this semi-new world of signing and stores and the such, there’s actually a good bit you can ascertain about an app both inside the app as well as inside metadata OS X keeps about the app. I’ve discussed signing (apps and packages) in the past, but let’s look at using some commands to help us out with some tasks. The first command is to determine some information about apps that are on the computer. Spotlight keeps a fair amount of information about these apps and can be invoked using the mdls command. Running the command with no additional parameters looks like this (I’m gonna’ use iMovie in these examples, although note that there are spaces in a lot of app names and paths as you start scripting things – so use IFS rather than trying to use traditional array): mdls /Applications/iMovie.app This results in output similar to the following (I’ve stripped out a few fields as they consume a lot of space and aren’t super pertinent to what I’m trying to do here):
kMDItemAlternateNames = ( "iMovie.app" ) kMDItemAppStoreCategory = "Video" kMDItemAppStoreCategoryType = "public.app-category.video" kMDItemCFBundleIdentifier = "com.apple.iMovieApp" kMDItemContentCreationDate = 2011-09-28 08:04:34 +0000 kMDItemContentModificationDate = 2012-09-22 02:13:45 +0000 kMDItemContentType = "com.apple.application-bundle" kMDItemDisplayName = "iMovie" kMDItemExecutableArchitectures = ( i386 ) kMDItemFSContentChangeDate = 2012-09-22 02:13:45 +0000 kMDItemFSCreationDate = 2011-09-28 08:04:34 +0000 kMDItemVersion = "9.0.8"
To just ask for one of these attributes, run the command along with the -name option in addition to the metadata attribute you’d like returned. For example, to see the bundle ID (kMDItemCFBundleIdentifier), use: mdls /Applications/iMovie.app -name kMDItemCFBundleIdentifier /Applications/iMovie.app Now, if you’d like to just quickly ascertain what apps on the system came from the App Store, use the mdfind command, along with whatever of the attributes matches what you want to know. Running mdfind for kMDItemAppStoreHasReceipt of 1 would look like the following and would result in a list of all apps on the system that came from the App Store: mdfind kMDItemAppStoreHasReceipt=1 Blacklisting all apps that are part of a specific category (and with regard to customer requests, that category seems to always be Games) is something we get a lot of banter about with customers. To determine this information for apps, you can run mdfind on kMDItemAppStoreCategory for Games: mdfind kMDItemAppStoreCategory=Games You could then dump the contents of those into something that can blacklist apps (or whitelist based on other categories). Now, version control is another hot topic at various organizations. To see the version type of a given app, use the -name option with mdls kMDItemVersion mdls /Applications/iMovie.app -name kMDItemVersion /Applications/iMovie.app Then you can track the version of the app and take action through other ways to remove old versions and force users to upgrade. The mdfind command can also be leveraged to find apps that have escaped their traditional homes of /Applications and /Applications/Utilities, with the ability to obtain a full list by querying for kMDItemContentType of app bundles, as follows: mdfind kMDItemContentType="com.apple.application-bundle" Loading a list of apps (output from `mdfind kMDItemAppStoreHasReceipt=1` or `mdfind kMDItemAppStoreCategory=Games`) into an array and then querying each one of them for more information is pretty trivial beyond the steps we’ve already taken. This information can then be fed into some kind of Managed Prefs script to deny or allow access to various objects or an admin could even chmod the bundle, mark it as invisible, poison it (keep in mind, if you alter it you’ll break the signing), etc in order to get some desired outcome. You can also use defaults to read a users com.apple.storeagent.plist file for the AppleID field to see what AppleID is currently logged into the AppStore, providing another variable that can be reported on: defaults read /Users/cedge/Library/Preferences/com.apple.storeagent.plist AppleID And yes, it’s worth noting that users from another account or a system image, etc can be used to download apps so this one isn’t exactly certain but the purchaser isn’t stored anywhere within the bundle nor is it permissioned in a way that we can use to find the purchaser that way. There’s still a bit of a gap right now with regards to some of these technologies that Mac SysAdmins are managing. The consumeristic technologies such as App Stores are here to stay. We’re kidding ourselves if we think that we won’t be able to buy certain apps via Volume Licenses and have pkg installers for too much longer. Apple has made no indication that they’re dropping the results that can be obtained with a simple installer command, but with forcing signing on certain objects, gatekeeper and other technologies it’s hard to say what the future will really have in store for us. Getting to a point where we can report on elements of the App Store and hopefully eventually deploy objects through the App Store should continue to help bridge these factors, but I still see the need for additional binaries from Apple to be introduced to get the rest of the way there (or at least expose a method to me so I can go in there and buy an app through the method).

November 19th, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, Uncategorized

Tags: , , , , , , , , , , , , , , , ,

In OS X, installers are known as packages. The trend in OS X is to sign anything going onto a computer so that it can then be installed without concern that the product is not authentic. The productsign command provides the ability to sign packages in much the same way that the codesign command can be used on apps. For example, let’s say that we wanted to sign a package called Alpha.pkg in /tmp with Apple DeveloperID 31415926535897932384626 and have it result in a new package, Omega.pkg in the same directory. The command would be as follows: productsign --sign 'Developer ID Installer: 31415926535897932384626' '/temp/Alpha.pkg' '/temp/Omega.pkg' You can also timestamp the signing by adding a –timestamp option or disable trusted timestamps with the –timestamp=none. You can also indicate a keychain using the –keychain option or –cert to indicate a certificate to embed in the archive. Once signed, you can then test the signing using the spctl command along with the –assess option. The –type option would also indicate a type of install, resulting in the following for Omega.pkg: spctl --assess --type install /temp/Omega.pkg

August 31st, 2012

Posted In: Mac OS X

Tags: , , , , , , ,

I’ve mentioned the codesign tool in previous articles, but today let’s look at a specific use. I recently needed to generate a report of the executable for around 2000 app bundles. Luckily, codesign displays the executable for an app when run with the –display option: codesign --display /Applications/Utilities/Terminal.app The output looks as follows: Executable=/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal Another tool that I haven’t written much about is productsign (also in /usr/sbin of Mac OS X 10.8). I’ll look at that one next, as a means of signing packages.

August 27th, 2012

Posted In: Mac OS X

Tags: , , , , , , ,