Every so often, source code for an application gets lost, mislaid or not given to a customer. In that case, the application’s user may need to do a lot of work to decompile the application and see if the source code can be recovered from the application itself.
I recently had a colleague ask about a similar situation with an Automator application, where they had the Automator application itself but didn’t have access to the Automator workflow that created it.
After some testing, here’s how we were able to access the workflow using only the compiled application.
1. Save a copy of the Automator application to a convenient location.
2. Right-click on the application and select Show Package Contents.
3. Save a copy of Contents/document.wflow to a convenient location.
4. Rename document.wflow to preferred_file_name_here.workflow.
5. When prompted, confirm that you want to change the extension from .wkflow to .workflow.
At this point, you should be able to open the newly-renamed .workflow document in Automator and examine the workflow.
Update 8-1-2015: Steve Hayman pointed out that there’s an even easier way. For details, see below the jump.
On OS X 10.10.x and later, disabling Gatekeeper does not mean it is permanently off. After a set amount of time (currently 30 days), Gatekeeper will automatically re-enable itself with the Allow apps downloaded from: Mac App Store and identified developers setting.
I was able to track down which part of the OS this was coming from and it looks like it’s defined as part of syspolicyd:
After doing some research, it looks like Gatekeeper’s automatic re-enablement function can be disabled by running the following command with root privileges:
defaults write /Library/Preferences/com.apple.security GKAutoRearm -bool false
This would allow Gatekeeper to be set to Allow apps downloaded from: Anywhere and have it stay that way.
For those who want to set this with a management profile, I’ve created a .mobileconfig file and posted it here on Github:
Update – 7-31-2015: My colleague Tom Burgin points out that this may not be manageable via a profile after all, due to the way Apple has set the value that it’s reading:
If a management profile isn’t being respected, the defaults command listed above is the way to apply this to machines.
I’ve filed a bug report about this. For those interested in duping this bug, the bug report ID is 22094327. I’ve also cross-posted it to OpenRadar:
JAMF announced today that, due to changes that are coming in OS X 10.11, Casper’s jamf binary will be moving its location in a future release of Casper. For those not familiar with Casper, the jamf binary is the agent software which Casper installs on Macs in order to manage them.
Update – 7-30-2015: JAMF clarified that the new location is going to be /usr/local/bin/jamf, instead of /usr/local/jamf as I originally understood it to be. I’m updating this post and CasperCheck with the new path information.
From today’s announcement, it also appears that the jamf binary will not be moving on all versions of OS X:
Mac OS X 10.5.x – 10.6: The jamf binary will be staying in /usr/sbin/
Mac OS X 10.7.x and later: The jamf binary will be moving to /usr/local/bin
Now that this information is public, I’m releasing an update to CasperCheck that should be able to handle checking for the Casper agent in both its current and its future locations. For more information, see below the jump.
When building a presentation in Keynote, I often use Apple’s icons and other images included in OS X to illustrate my slides. This is because Apple’s already done a lot of work creating high-res images for OS X and it’s often helpful to use Apple’s own artwork when illustrating how something works. However, this artwork can also be hard to find as it can be buried deep within applications and other resource files. To help me get this artwork all together in one place, I’ve developed a script to search OS X for icons and other relevant images in various file formats, copy them when found, then organize the copied artwork. For more information, see below the jump.
I’m happy to announce that I’ll be speaking at the inaugural Mac Admin & Developer Conference UK, which is taking place in London from February 9th – 10th, 2016.
As part of my work with packaging, I’ve built a few Automator-based applications to assist me and other Mac admins.
Along with building the applications themselves, I wanted to provide custom icons for these apps. This would help them be instantly distinguishable from other Automator applications and also help make them look more polished.
I recently decided to change out the application icon for Payload-Free Package Creator, as its icon had been created on Mavericks and now appeared a little dated when used on Yosemite. With input from my colleague Elliot Jordan, the new icon for Payload-Free Package Creator now looks like this.
For more information on how I went from this PNG file to an icon set for the application, please see below the jump.
For those who want the playlists, please see the links below:
Penn State MacAdmins 2013 playlist: http://sptfy.com/macadmins2013
Penn State MacAdmins 2014 playlist: http://sptfy.com/macadmins2014
Penn State MacAdmins 2015 playlist: http://sptfy.com/macadmins2015