A bootable installer is one of the fastest ways to install Yosemite. Rather than copy the installer to a local drive you can run it right off a USB disk (or Thunderbolt if you dare). Such a little USB drive would be similar to the sticks that came with the older MacBook Air, when we were all still sitting around wondering how you would ever install the OS on a computer with no optical media or Ethernet otherwise. Luckily, Apple loves us.

To make a bootable USB/flash drive of Yosemite like the one that used to come with the MacBook Air, first name the USB drive. I’ll use yosinstall for the purposes of this article. The format should be Mac OS Extended Journaled. The installer is called Install OS X Yosemite.app and is by default located in the /Applications directory. Inside the app bundle, there’s a new binary called createinstallmedia (nested in Contents/Resources).

Using this binary you can create an installation drive (similar to what we used to do with InstallESD). To do so, specify the –volume to create the drive on (note that the target volume will be erased), the path of the Install OS X Yosemite app bundle and then we’re going to select –nointeraction so it just runs through the whole thing

/Applications/Install\ OS\ X\ Yosemite.app/Contents/Resources/createinstallmedia --volume /Volumes/yosinstall --applicationpath /Applications/Install\ OS\ X\ Yosemite.app --nointeraction

Note: You’ll need to elevate your privileges for this to run.

Once run you’ll see that it erases the disk, copies the Installation materials (InstallESX, etc) and then makes the drive bootable, as follows:

Erasing Disk: 0%... 10%... 20%... 100%...
Copying installer files to disk...
Copy complete.
Making disk bootable...
Copying boot files...
Copy complete.

Then you can either select the new volume in the Startup Disk System Preference pane or boot the computer holding down the option key to select the new volume.

Note: If you can do this on a system with a solid state drive it will be  faster. Although this took 17 minutes last I ran it so be patient for the files to copy.

A few people have hit me up about issues getting Windows machines to play nice with the SMB built into Yosemite Server and Windows. Basically, the authentication dialog keeps coming up even when a Mac can connect. So there are two potential issues that you might run into here. The first is that the authentication method is not supported. Here, you want to enable only the one(s) required. NTLMv2 should be enabled by default, so try ntlm:

sudo serveradmin settings smb:ntlm auth = "yes"

If that doesn’t work (older and by older I mean old as hell versions of Windows), try Lanman:

sudo serveradmin settings smb:lanman auth = “yes"

The second is that the authentication string (can be seen in wireshark) doesn’t include the workgroup/domain. To resolve this, simply include the Server name or workgroup in the beginning of the username followed by a backslash(\). So you might do this as a username if your NetBios name were kryptedserver:

kryptedserver\charles

To get that exact name, use serveradmin again, to look at the smb:NetBIOSName attribute:

smb:NetBIOSName = "kryptedserver"

Setting up OS X Server has never been easier. Neither has upgrading OS X Server. In this article, we’ll look at upgrading a Mac from OS X 10.8 or 10.9 running Server 2 or Server 3 to OS X 10.10 (Mavericks) running Server 4.

The first thing you should do is clone your system. The second thing you should do is make sure you have a good backup. The third thing you should do is make sure you can swap back to the clone should you need to do so and that your data will remain functional on the backup. The fourth thing you should do is repeat all that and triple check that your data is there!

Once you’re sure that you have a fallback plan, let’s get started by downloading OS X Yosemite from the App Store. I would also purchase the Server app first while Yosemite is downloading.  Once downloaded, you’ll see Install OS X Yosemite sitting in LaunchPad. Once downloaded, you’ll see Install OS X Yosemite sitting in LaunchPad, as well as in the /Applications folder.

Open the app and click Continue (provided of course that you are ready to restart the computer and install OS X Yosemite).

At the licensing agreement, click Agree (or don’t and there will be no Mavericks for you).

At the pop-up click Agree again, unless you’ve changed your mind about the license agreement in the past couple of seconds.

At the Install screen, click Install and the computer will reboot and do some installation fun stuff.

Once done and you’re looking at the desktop, download the latest version of the Server app you should have purchased previously, if you haven’t already. Then open it.

If prompted that the Server app was replaced, click OK. Then open the app.

At the Update screen, click Continue (assuming this is the server you’re upgrading).

At the Licensing screen, click Agree.

When prompted for an administrator account, provide the username and password of an administrator and click OK.

When the app opens, verify DNS (absolutely the most important element of this upgrade), etc and then check that configured services still operate as intended. If you end up deciding that you no longer need OS X Server, just delete the app and the contents of /Library/Server and you’re good. Handle with Care.

A blog is a great way to communicate information. But pedagogy, yo… Blogs are not great ways to teach in a guided manner. But they can be. So with a little Table of Contents, or a Guide of sorts, you can easily communicate in a fashion similar to a book. And this makes the third annual OS X Server Guide that I’m publishing in this manner; the guides for Mavericks and Mountain Lion are  still available. I doubt I’ll ever actually bother to take them down.

I’ve been working on getting the annual guide up for a few weeks and while there are still some posts remaining, but it’s basically done (some articles just haven’t gone up yet, but they’re basically written). So, if you’re fighting the good fight (and I do think it’s a good fight) and rolling Yosemite Server, click over on http://krypted.com/guides/yosemite-server for the latest guide, covering OS X Server 4 running on OS X Yosemite (which I still like to call Yosemite Server).

Oh, and if you’re keeping track (doubtful): yah, I know I never finished the Windows Server Guide, but I did write and finish the Xsan one and there might have been a divorce, 2 books, a product release, job change and a few benders mixed in there – one of which might still be ongoing… So I’ll eventually get back to it. Or not….

Installing OS X has never been easier than in Yosemite. In this article, we’ll look at upgrading a Mac from OS X 10.9 (Mavericks) to OS X 10.10 (Yosemite). The first thing you should do is clone your system. The second thing you should do is make sure you have a good backup. The third thing you should do is make sure you can swap back to the clone should you need to do so and that your data will remain functional on the backup. Once you’re sure that you have a fallback plan, let’s get started by downloading OS X Yosemite from the App Store. Once downloaded, you’ll see Install OS X Yosemite sitting in LaunchPad, as well as in the /Applications folder.

Open the app and click Continue (provided of course that you are ready to restart the computer and install OS X Yosemite).

At the licensing agreement, click Agree (or don’t and there will be no Mavericks for you).

At the pop-up click Agree again, unless you’ve changed your mind about the license agreement in the past couple of seconds.

At the Install screen, click Install and the computer will reboot.

And you’re done. Now for the fun stuff!

The Directory Utility application has moved to /System/Library/CoreServices/Applications. Once open, you can use it to bind to directory services, change search policies and even dink around with NIS if you still rock the flannel with your ripped up jeans. But, the thing that I tend to do in Directory Utility the most is look at user and group attributes. To do so, open Directory Utility and click on the Directory Editor tab. In the bar directly below, you’ll see Viewing and In Node. The Viewing option is what type of object you’re going to look at. The In Node option shows the directory domain you’re viewing. Below, we show the local users in /Local/Default. 

Click on a user and you will see all of the attributes that exist for that user. Not all users are created equal when it comes to attributes, so if you’re looking for a specific attribute then you can go through different users to see what they have.

Change the In Node option to /LDAPV3/127.0.0.1 (or the name of your directory service such as your Active Directory) to see all the attributes available there. You can then note the names and use them in scripts, etc.

You can also access this information via dscl, but I’ve covered that enough times in the past to be bored with myself for even making the reference. Enjoy.

The statshares option has an -m option to look at a mount path for showing the path to the mount (e.g. if the mount is called krypted this should be something like /Volumes/krypted):

smbutil statshares -m /Volumes/krypted

When run, you see a list of all the attributes OS X tracks for that mount path, including the name of the server, the user ID (octal), how SMB negotiated an authentication, what version of SMB is running (e.g. SMB_1), the type of share and whether signing, extended security, Unix and large files are supported.

Additionally, if you’d like to see the attributes for all shares, use the -a option after statshares:

smbutil statshares -a

Overall, this is a nice health check type of verb for the smbutil command that can be added to any monitoring or troubleshooting workflow. Other verbs for smbutil include lookup, status, view, and identity. All are very helpful in troubleshooting connections to smb targets.

QuickLook scans file contents before you open those files. Usually this just lets you view a file quickly. But you can also use this same technology from the command line to bring about a change to the Finder without actually opening a file. To access QuickLook from the command line, use qlmanage.

qlmanage -p ~/Desktop/MyTowel42.pdf

While open, click the space bar to go back to your Terminal session. The most notable use case here is that when you use qlmanage you don’t run the risk of changing the date/time stamp of the files.

You get requests for features. Lots of requests. What do you pick? Why? Sure, vote up, vote down, statistics, choosing people you respect, looking at potential new customers, and tons of other attributes go into this, but at the end of the day, there’s a judgement call. And some people hate what you pick. But sometimes, everyone is into it. Yup.

I’ve spent way too much time traveling in my life (and way too little time writing about non-technical things). It’s had ups and it’s had downs. But these days, a bunch of fun little technical breakthroughs that make traveling incrementally better. And one of those things is Uber (and other similar services) who have disrupted the short-range ground transportation game. And I like them so much, I decided to write a little list of the reasons why! While writing, I also realized that you can use this code and we both get Uber credit I never used a promo code. But you can: https://www.uber.com/invite/uberkrypted. Has nothing to do with why I wrote this, but it’s a nice thing for me to find while writing…

So here’s my top 10 reason Uber rocks:

1. I believe in the model. People work when they want and seem generally happy. I’ve had a lot of students and people who drive a little after their day job just here and there whenever they feel like it. And they love it. It’s transparent. Everyone is wide open when it comes to talking about what they do and how the process works. Even in the apps, it’s all very transparent. The app requires the credit card, but you never have to give the card to the driver. You can text the driver (e.g. if you accidentally drag the pin a little when you’re a bit buzzed to let them know where to get you).
2. The reason the model and the transparency are possible is that the tech is great. I can see a map of all the cars, the route they’re going to take, the exact(ish) number of minutes before they show up and the payment is all kinds of working for me. In fact, the tech is so great that I reference their interface here and there in UX meetings. For example, how that whole awesome credit card entry screen works (if you haven’t seen it, it should be the design everyone uses forever cause it’s that rad). But my credit card never goes in their hands. The maps are great and up-to-date and the app is bad daddy, sleek and probably should earn their UX team some awards (not awards like getting knighted but awards like getting a trophy or something). They email receipts, so I don’t have to cart around printed receipts to do an expense report. They have a web lost and found.
3. It’s been faster than getting a cab every single freakin’ time! For some areas it’s like half an hour faster. Boom. And I don’t have to setup an appointment the night before with some craptastic Danny DeVito-style operator who still needs me to read out an address and then have that cab show up 15 minutes late when I’m in a hurry or 15 minutes early when I’m still in the shower and start calling over and over. I can see where the car is on a map. Love that. And if you tell a driver a better route, they actually listen…
4. It’s not possible to tip in the app. Or not that I’ve found. I do still throw a few bucks their way here and there when I actually have cash because they’re awesome. But when I’ve not had cash it’s a no harm no foul kind of situation. They don’t expect it and they’re great people so usually deserve something more than $15 or whatever for the amount of time I spend with them…
5. You rate the drivers. I have given all of mine 5 stars. And they can rate me. And they’ve all given me 5 stars. It’s not possible my experiences will absolutely always be this awesome (YMMV I’m guessing) but it’s definitely been a great run.
6. Cab drivers are rushing around and rude drivers. Nothing harshes my calm more than feeling like I get some negative karma points for someone else hurling their car around like a vehicular version of the Jerky Boys.
7. Credit cards. In the past year or two, at least half the time I’ve taken a cab, the driver gets annoyed if I can’t tip in cash, or sometimes pay in cash. I shared a cab with my friend Zack (@acidprime) once and since we were paying with credit cards the driver wouldn’t even charge us at all. Totally annoying… This does seem to be getting better with the cabs that have the video screens in the back. But I’d almost rather them get annoyed than having some of the early versions of those things screaming at me while I’m trying to talk during a conference call…
8. The drivers are quirky and interesting. I have had a great run with this. I did have a funny little moment with this recently where a lady driver was telling me about her grandkids, which I thought was natural, but then she started telling me all about the “arrangement” she has with her husband and referencing knocking off early and hitting my hotel bar. Alright, it was fun to get hit on by my first Uber driver, even if she was 20 years older than me! The one on the way back to my hotel later that night was telling me all about his Tinder whoreness. Hilarious conversationing! Also, they all know how it works. I tried to get in the wrong Uber the other day and even though the guy got stood up he was like “no thanks.” I’ve had cab drivers from the same company pick me up and not radio it in and then I get nasty calls from dispatch when I thought I was getting in the right cab ’cause they lied about it! Teh lamer…
9. Oh, and did I mention that Uber is cheaper than a cab. I once got a little too tipsy to drive and took a cab from the Los Angeles Airport (LAX) up to Hollywood. It cost over $100. I took an Uber to Sunset and started further away than LAX and it was $41. .
10. Because it’s so much cheaper than a cab, there’s even less of a reason to get a DUI too. It seems like I see less drunk drivers later at night since it became a thing, too. So for the final one: Uber saves babies and makes the world a safer place.

Having said all these generalizations, I’ve had some absolutely wonderful cab drivers in my life. I was once riding around with a customer of mine and the driver was so awesome that my customer sent him a pallet of the product my customer makes. So YMMV, but this has been my experience thus far! And before anyone says it: I know Lyft is supposed to be cheaper and whatever, but I’ve had more experience with Uber, and I’m sure they’d be similar if it had been with another service…

Also, Uber continues to experiment with additional services and features. Black, Taxi and other options are the most obvious, but they also experimented with delivering Halloween costumes and makeup artists to your house for Halloween this year and I’m guessing they’re going to continue thinking of cool, quirky add-ons to the service. I love bringing an MVP to market in the app and then adding little tweaks here and there when the MVP actually works and people love it love it love it (yes, that’s an Eloise reference).

Finally, Uber isn’t for everyone just yet. Check to see it it’s in your city yet: https://www.uber.com/cities.

PS – Double  Amex points if you use that to pay for Uber.

The profiles command in Yosemite (and Mavericks for that matter), can configure profiles to install at the next boot, rather than immediately. Use the -s to define a startup profile and take note that if it fails, the profile will attempt to install at each subsequent reboot until installed. To use the command, simply add a -s then the -F for the profile and the -f to automatically confirm, as follows (and I like to throw in a -v usually for good measure):

profiles -s -F /Profiles/SuperAwesome.mobileconfig -f -v

And that’s it. Nice and easy and you now have profiles that only activate when a computer is started up.

Xcode and other tools can be used to view logs on iOS devices. One of those other tools is libimobiledevice. I usually install libimobiledevice using homebrew, as there are a few dependencies that can be a little annoying. To install homebrew if you haven’t already, run the following command:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Once run, follow the prompts to complete the installation. Once homebrew is installed, run the following brew command to download the required components and then libimobiledevice:

brew install -v --devel --fresh automake autoconf libtool wget libimobiledevice

Then run ideviceinstaller:

brew install -v --HEAD --fresh --build-from-source ideviceinstaller

Once these are installed, you can plug in a paired device, unlock it and use the following command to view the logs on the screen:

idevicesyslog

This is akin to running a tail against the device. Again, the device must be paired. You can use the command line (e.g. if you’re running this on Linux) to view the logs, but if you’re not paired you’ll need to use idevicepair to pair your device, followed by the pair verb (which is very different from the pear verb):

idevicepair pair

You can also unpair using the unpair verb:

idevicepair unpair

When pairing and unpairing, you should see the appropriate entries in /var/db/lockdown. The final option I’m going to cover in this article is the date (very useful when scripting unit tests using this suite. To obtain this, use the idevicedate command, no operators or verbs required:

idevicedate

Rake is basically make for Ruby. I recently needed to update rake for something I was working on. After doing so, I tried to update some stuff in Profile Manager and it seemed to work on the outside, but a lot of stuff in Yosemite and Yosemite Server rely on rake so be careful when doing this kind of thing. So, to update to the latest version of rake, use the gem command along with the install verb and then rake as the gem being updated:

sudo gem update rake

This is an interactive command line environment so you’ll be asked a few questions in order to update the gem. Once complete, you’re running (at the time of this writing) 10.3.2. Run the list verb to see what version of each local gem you are running:

sudo gem list

Because running a newer version of rake can conflict with some built-in OS X stuff, you might find a desire to go back. At the time I’m writing this article, 0.9.6 is the latest and greatest version of rake that OS X uses. We can remove the existing rake using uninstall:

sudo gem uninstall rake

Then we can install a specific version using the install verb, followed by the gem and then the version:

sudo gem install rake 9.6

For a full guide of the gem verbs (or commands) see http://guides.rubygems.org/command-reference/.

Special thanks to Tim Robertson and macsales.com for including me along with some of the great ones like Tidbits’ Engst family!

http://videos.macsales.com/podcasts/OWC-Radio-2-21.mp3

The other day, we installed libimobiledevice and used it to view the logs of an iOS device. But you can do much more with the commands that were installed. In fact, if you have a paired device, you can actually use these commands to do some remedial regression testing and other pretty cool things. So this is going to be part two of that article, basically.

First up, make sure the device is paired (note: not all commands require a device to be unlocked). But, all interaction with a device requires the device to be paired. You can use the command line (e.g. if you’re running this on Linux) to view the logs and manage devices, but if you’re not paired using iTunes or another tool, you’ll need to use idevicepair to pair your device, followed by the pair verb (which is very different from the pear verb):

idevicepair pair

You can also unpair using the unpair verb:

idevicepair unpair

The first command we’ll use is idevicedate, which simply returns with the date and time stamp currently on the device:

/usr/local/bin/idevicedate

The response would look similar to the following:

Thu Nov 13 08:58:30 CST 2014

Next, let’s check the apps installed on a device. We can do this with the ideviceinstaller command (also part of the ilibmobiledevice suite of tools). Here, we’ll use the -l option to just list what’s installed:

/usr/local/bin/ideviceinstaller -l

The output would show the app, along with the version of the app at rest on the device:

com.apple.Pages - Pages 1716

To uninstall one of the listed apps, use the –uninstall option:

ideviceinstaller --uninstall com.protogeo.Moves

You can also install apps provided you’ve cached the ipa file (e.g. via iTunes).

ideviceinstaller --install /Users/charlesedge/Music/iTunes/iTunes\ Media/Mobile\ Applications/Box\ 3.3.0.ipa

Which returns the following:

Copying '/Users/charlesedge/Music/iTunes/iTunes Media/Mobile Applications/Box 3.3.0.ipa' to device... DONE.
Installing 'net.box.BoxNet'
Install - CreatingStagingDirectory (5%)
Install - ExtractingPackage (15%)
Install - InspectingPackage (20%)
Install - TakingInstallLock (20%)
Install - PreflightingApplication (30%)
Install - VerifyingApplication (40%)
Install - CreatingContainer (50%)
Install - InstallingApplication (60%)
Install - PostflightingApplication (70%)
Install - SandboxingApplication (80%)
Install - GeneratingApplicationMap (90%)
Install - Complete

When run against a device, the app can then open apps provided the AppleID owns the app.

There’s also a command for ideviceprovision, which can be used to view provisioning profiles, when run with the list verb:

/usr/local/bin/ideviceprovision list

The ideviceprovision command can also form the basis of a tool like wirelurker by allowing you to install a provisioning profile

/usr/local/bin/ideviceprovision install angrybirds.mobileprovision

The file would look something like the following:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>AppIDName</key>
<string>Angry Birds</string>
<key>ApplicationIdentifierPrefix</key>
<array>
<string>ASDFJKL</string>
</array>
<key>CreationDate</key>
<date>2014-11-16T02:14:09Z</date>
<key>DeveloperCertificates</key>
<array>
<data>
MYCERT
</data>
</array>
<key>Entitlements</key>
<dict>
<key>application-identifier</key>
<string>ASDFJKL.com.rovio.angrybirds</string>
<key>com.apple.developer.ubiquity-container-identifiers</key>
<array>
<string>ASDFJKL</string>
</array>
<key>com.apple.developer.rovio</key>
<string>ASDFJKL*</string>
<key>get-task-allow</key>
<true/>
</dict>
<key>Name</key>
<string>Angry Birds</string>
<key>ProvisionedDevices</key>
<array>
<string>MYUDID</string>
</array>
<key>TeamIdentifier</key>
<array>
<string>ASDFJKL</string>
</array>
<key>Version</key>
<integer>1</integer>
</dict>
</plist>

You can also remove this, by feeding in the UUID of the provisioning profile (obtained using the list verb but replacing MYUUID from below codeblock):

/usr/local/bin/ideviceprovision remove MYUUID

Note: I’m going to leave my rant about how wirelurker is about as much a security vulnerability as `rm` is due to the fact that it’s how you test the impact of upgrading apps on devices during the development process to another post – where I’ll also beg Apple not to let a little bad press cause them to rip away some of the few deployment and testing tools we actually have for the platform.

Or you could so something more annoying like put a device into recovery mode, so it would need to be plugged into a computer running iTunes and get a new ipsw installed, which is as simple as feeding the udid into ideviceenterrecovery:

/usr/local/bin/ideviceenterrecovery af36e5d7065d4ad666bf047b6e4de26dd144578c

Which brings up an interesting question, how would you get the udid? You can use ideviceinfo:

ActivationState: Activated
ActivationStateAcknowledged: true
BasebandActivationTicketVersion: V2
BasebandCertId: 3554301762
BasebandChipID: 7282913
BasebandKeyHashInformation:
AKeyStatus: 2
SKeyHash: 7MQEUyvzG4gjjZc7KsNNAVTS8g4=
SKeyStatus: 0
BasebandMasterKeyHash: AEA5CCE143668D0EFB4CE1F2C94C966A6496CZZZ
BasebandRegionSKU: BAAAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZZZ==
BasebandSerialNumber: JErUEw==
BasebandStatus: BBInfoAvailable
BasebandVersion: 3.11.00
BluetoothAddress: 90:fd:61:a6:f6:ZZ
BoardId: 0
BrickState: false
BuildVersion: 12B411
CPUArchitecture: arm64
CarrierBundleInfoArray[1]:
0:
CFBundleIdentifier: com.apple.Verizon_LTE_US
CFBundleVersion: 18.0
IntegratedCircuitCardIdentity: 89148000001085935ZZZ
InternationalMobileSubscriberIdentity: 311480110469ZZZ
MCC: 311
MNC: 480
SIMGID1: uuAAAAAAAAA=
SIMGID2: //////////8=
CertID: 3554301762
ChipID: 35168
ChipSerialNo: JErUEw==
CompassCalibration: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
DeviceClass: iPhone
DeviceColor: #3b3b3c
DeviceName: OK Computer
DevicePublicKey: LS0tLS1CRUdJTiBSU0EgUFVCTElDIEtFWS0tLS0tCk1JR0pBb0dCQUxzV1BCWWJtM0FzK3ZRV2hOcnYvTTBSMWxFWi9QMVhPZzUyTG5GaEN5VUFlOVpPOWd2TC9NUzkKSXFMbTRZT3d6LytQeEdDMmlnTlRRbFlsKzdJY1dleFQ3dTBhZTI4UGtQL0N4OFYvV0dicWhqOGNmMHZDeVNVcApPa1FPWlFRYmJhRVVDN0pNaDExVW1ZdmllajYwN3cyRWh0THB4MysvZWR4cjlLNWtudXl6QWdNQkFBRT0KLS0tLS1FTkQgUlNBIFBVQkxJQyBLRVktLS0tLQo=
DieID: 5177734985296
EthernetAddress: 90:fd:61:a6:f6:13
FirmwareVersion: iBoot-2261.3.32
FusingStatus: 3
HardwareModel: N51AP
HardwarePlatform: s5l8960x
HostAttached: true
IntegratedCircuitCardIdentity: 89148000001085935111
InternationalMobileEquipmentIdentity: 352008065544111
InternationalMobileSubscriberIdentity: 311480110469111
MLBSerialNumber: F3Y34040ZEDF7GRA
MobileEquipmentIdentifier: 35200806554111
MobileSubscriberCountryCode: 311
MobileSubscriberNetworkCode: 480
ModelNumber: NE341
NonVolatileRAM:
auto-boot: dHJ1ZQ==
backlight-level: MTQ0MA==
boot-args:
bootdelay: MA==
PartitionType:
PasswordProtected: false
PhoneNumber: (612) 867-5309
PkHash: 09pXQgM5cjY6TJJNOOzO//R5JuGKqjHElfshBbnxZZZ=
ProductType: iPhone7,1
ProductVersion: 8.1
ProductionSOC: true
ProtocolVersion: 2
ProximitySensorCalibration: T00DAA0KQTgQAwAAAABeAQAAbgAEAP7zZgMEAAtS9wLuAjAAWYbZAY+GkhkAAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
RegionInfo: LL/A
SBLockdownEverRegisteredKey: true
SIMGID1: ug==
SIMGID2: /w==
SIMStatus: kCTSIMSupportSIMStatusReady
SIMTrayStatus: kCTSIMSupportSIMTrayInsertedWithSIM
SerialNumber: F97N61XZFZZZ
SoftwareBehavior: EQAAAAAAAAAAAAAAAAAAAA==
SoftwareBundleVersion:
SupportedDeviceFamilies[1]:
0: 1
TelephonyCapability: true
TimeIntervalSince1970: 1416017216.873442
TimeZone: America/Chicago
TimeZoneOffsetFromUTC: -21600.000000
TrustedHostAttached: true
UniqueChipID: 5177734985296
UniqueDeviceID: af36e5d7065d4ad666bf047b6e4de26dd1445ZZZ
UseRaptorCerts: true
Uses24HourClock: false
WiFiAddress: 90:fd:61:a6:f6:ZZ
WirelessBoardSerialNumber: D81C55315781
kCTPostponementInfoPRIVersion: 0.1.90
kCTPostponementInfoPRLName: 1
kCTPostponementStatus: kCTPostponementStatusActivated

The ideviceinfo output above shows more information that I knew you could actually get about a device previously. You can grep for the UniqueDeviceID and

ideviceinfo | grep UniqueDeviceID | awk '{ print $2}'

This would just return with the UDID. Since that’s blank when there’s no device connected, you can run a loop that waits a few seconds when empty and then uses that UDID as a $1 in some script. Of course, it’s much easier to use a command they built for this called idevice_id:

idevice_id -l

Next, you can use idevicediagnostics to obtain some information about the current state of the device:

idevicediagnostics diagnostics All -u af36e5d7065d4ad666bf047b6e4de26dd1445789

Which has an output similar to the following:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>GasGauge</key>
<dict>
<key>CycleCount</key>
<integer>78</integer>
<key>DesignCapacity</key>
<integer>1550</integer>
<key>FullChargeCapacity</key>
<integer>1600</integer>
<key>Status</key>
<string>Success</string>
</dict>
<key>HDMI</key>
<dict>
<key>Connection</key>
<string>Unplugged</string>
<key>Status</key>
<string>Success</string>
</dict>
<key>NAND</key>
<dict>
<key>Status</key>
<string>NANDInfoFailed</string>
</dict>
<key>WiFi</key>
<dict>
<key>Active</key>
<string>YES</string>
<key>Status</key>
<string>Success</string>
</dict>
</dict>
</plist>

Or query the IOreg of the device:

idevicediagnostics ioreg IODeviceTree -u af36e5d7065d4ad666bf047b6e4de26dd1445789

The output is way too long to paste in here, but interesting (kinda’). The idevicediagnostics command can also do some basic tasks such as restart, sleep and shutdown (each sent as a verb without a required UDID):

idevicediagnostics restart

The crash reports on a device (which include reports for uninstalled apps, forensically providing a glimpse into what apps were removed from a device and when) can all be extracted from a paired device as well, using idevicecrashreport:

idevicecrashreport -e /test

You can then view the logs or grep through them for specific pieces of information:

cat /Test/Baseband/log-bb-2014-08-06-stats.plist

The last command we’re going to cover in this article is idevicebackup2, used to backup devices. Here, we’re going to feed it the udid (which I’m lazily using the idevice_id command from earlier in backticks to grab the udid and backing up into that /test directory.

idevicebackup2 -u `idevice_id -l` backup /test

Here, we’ve backed up whatever device is plugged in, to the /test directory. Subsequent backups will be incrementals.

Slowly but surely information about what I left 318 to do has been leaking out. And I wouldn’t say leaking. More like being broadcast to the world. I’ve worked on a few little things here and there at JAMF Software since my arrival. But my core duty is to shepherd the development and strategy behind a new Mobile Device Management tool called Bushel. A little more about Bushel is available here, and I’ll likely post more about it here when the time is right:

http://tech.mn/news/2014/11/04/jamf-software-bushel-apple-device-management/

And to access the Bushel site:

http://www.bushel.com

And some of the writing that are now finding their way onto the Bushel blog:

http://blog.bushel.com

OS X has a command called rvictl, which can be used to proxy network communications from iOS devices through a computer over what’s known as a Remote Virtual Interface, or RVI. To setup an rvi, you’ll need the udid of a device and the device will need to be plugged into a Mac and have the device paired to the Mac. This may seem like a lot but if you’ve followed along with a couple of the other articles I’ve done recently this should be pretty simple. First we’ll pair:

idevicepair pair

Then tap Trust on the device itself. Then we’ll grab that udid with idevice_id:

idevice_id -l

Next, we’ll setup a rvi with rvictl and the -s option (here I’m just going to grab the udid since I only have one device plugged into my computer):

rvictl -s `idevice_id -l`

Then we can list the connections using rvictl with the -l option:

rvictl -l

Next, we’ll run a tcpdump using this newly constructed rvi0:

tcpdump -n -i rvi0

Next, we’ll get a lot of logs. Let’s fire up the Nike FuelBand app and refresh our status. Watching the resultant traffic, we’ll see a line like this:

22:42:29.485691 IP 192.168.0.12.57850 > 54.241.32.20.443: Flags [S], seq 3936380112, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 706439445 ecr 0,sackOK,eol], length 0

There’s an IP in there, 54.241.32.20. We can look this up and see that the servers are sitting on Amazon Web Services and verify it’s Nike. Watching the traffic with tcpdump we can then obtain GET, POST and other information sent and received. Using wireshark we could get even more detailed data.

Overall though, this article is meant to focus on the iOS side of this and not on debugging and refining the approach to using tcpdump/wireshark. rvictl is a great tool in the iOS development cycle and for security researchers that are looking into how many of the apps on iOS devices exchange data. Enjoy.

MacTech Conference 2015:

November 4-6, 2015 in Los Angeles.

Like 2014, it will be a full three days.

Pre-Conference workshops: November 3rd

Apple’s Device Enrollment Program (DEP for short) allows you to automatically setup devices with the settings you need on devices that your organization purchases. In Bushel, we give you the ability to link an Apple DEP account up with your Bushel account. This allows devices to add themselves automatically to your Bushel when the devices are activated. We tend to think this is the coolest thing since sliced bread and so we want to make sure you know how to use the feature.

Setup Device Enrollment Program in Bushel

To get started, log into your Bushel and click on Devices. Here, click the button for Device Enrollment Program.

Download your certificate and go to deploy.apple.com and log into your Device Enrollment Program account. Click on Manage Servers in the Deployment Programs sidebar.

Next, click on Add MDM Server and provide the certificate we gave you and a name. Once Bushel has been added to your Device Enrollment Program (DEP) account, click on Assign by Serial Number to add your first device. Assuming the device is part of your DEP account, enter the serial number for the device and choose which server (the one you just added) that the device should reach out to on activation to pull settings from.

Once you’ve added the server, you’ll be greeted by a screen that says Assignment Complete. You can now wipe the device and upon reactivation the device will pull new settings from your Bushel.

The Device Enrollment Program in Bushel

Click OK and you can add more devices. Once your devices are added into the Apple DEP portal they will automatically appear in the DEP screen of your Bushel. Click on a device to assign a username and email address, if you will be using email.

Good luck!