Here is the command to create a bootable installation USB for the latest OSX 10.12 Sierra, it’s the same as previous releases, at least as far back as Mavericks 10.9 with the only change being the name of the installation.app (“Install macOS Sierra.app” in this case) and the name of the USB volume I’m writing to (“SierraInstaller” in this case).
sudo /Applications/Install\ macOS\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/SierraInstaller --applicationpath /Applications/Install\ macOS\ Sierra.app --nointeraction &&say Done
I received a report from an OSX Yosemite user who found documents saved on their iMac had stopped synchronizing to iCloud as they weren’t visible there or on the user’s MacAir.
Inspection showed the files in question had a grey dotted cloud next to their name in finder.
Documents created on the MacAir were synchronized back to the iMac so iCloud was working to some degree.
Creating a new document on the iMac resulted in the grey dotted cloud next to the document but nothing in the iCloud web interface.
Using the following command to inspect the “bird” daemon log indicated a fault with an alias file, locating that file I discovered it pointed to a non-existent file.
brctl log -w
I moved the broken alias out of the iCloud drive and the errors disappeared from the log but nothing appeared to be synchronizing.
I took a backup of the data (in addition to the Time Machine backup that is in permanent operation).
I then :
- Stopped the “bird” daemon with “killall bird” on the terminall
- Moved the “~/Library/Mobile\ Documents” folder to the desktop (“~/Desktop/Mobile\ Documents”)
- Renamed the database store folder for the iCloud service “~/Library/Application\ Support/CloudDocs/”
- Moved the folder from step 2 (“~/Desktop/Mobile\ Documents”) back into place at “~/Library/Mobile\ Documents”
- Rebooted the iMac and waited 12 hours (overnight).
The next day I inspected the machine and found around 40% of documents appeared to have re-synchronized, 10% had the dotted grey cloud and the remaining 50% had lost their file icon and instead had a dotted grey square for an icon!
I looked at Activity Monitor and inspected the “bird” process, it had read and written over 30GB of data to the disk, considering the user’s iCloud drive was around 3GB in use this seemed odd.
I restarted the iMac and waited a further 6 hours, upon returning all files had synchronized successfully and everything was well!
Steve Kersley provided me with a quick tute in using the native Mac OSX tools to monitor the local wifi clients and access points.
First prep the symlink on the machines
sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/sbin/airport
Next run the dissassociate command on the wireless adpater:
sudo airport -z
finally run the tcpdump command to begin monitoring the wireless activity in realtime
sudo tcpdump -i en1 -I -n type mgt and not subtype beacon
The previous command is broken down into:
- -i en1 : specify the interface to listen on
- -I : Print the interface on each dump line.
- -n : do not convert address (don’t use DNS resolution)
- type mgt and not subtype beacon : filter the packets by type mgt (exclude ctl and data) and also just examine the beacon data for dis/associate events
The above is fairly self-explanatory except for the last options for filtering by type.
An excellent resource I used for reference to understand this can be found at http://www.wildpackets.com/resources/compendium/wireless_lan/wlan_packet_types
and is included below for reference:
802.11 WLAN Packet Types
The table below lists the various packet types and subtypes specified in the 802.11 WLAN standard, and describes their usage briefly.
Table E.1 WLAN packet types
||This packet is sent to an access point (in a BSS or ESS) or to any other peer (in an IBSS or ad hoc network). The sender must already be authenticated in order to gain a successful association.
||This packet is sent from an access point (in a BSS or ESS) or from any other peer (in an IBSS or ad hoc network) in response to an association request packet. If the request is successful, the response will include the Association ID of the requester.
||Like an association request, but it includes information about the current association at the same time as it requests a new association (either with the original Station after some lapse of time, or with a new station upon moving from one BSS to another). This packet is sent to an access point (in a BSS or ESS) or to any other peer (in an IBSS or ad hoc network). The sender must already be authenticated in order to gain a successful association.
||Like an association response, but in response to a reassociation request. This packet is sent from an access point (in a BSS or ESS) or from any other peer (in an IBSS or ad hoc network) in response to a reassociation request packet. If the request is successful, the response will include the Association ID of the requester.
||Probe request is used to actively seek any, or a particular, access point or BSS.
||Probe response replies with station parameters and supported data rates.
||Beacon packets are sent by the access point in a BSS (or its equivalent in an IBSS) to announce the beginning of a Contention Free period (CF), during which the right to transmit is conferred by the access point by polling. Beacon management packets carry BSS timestamps to help synchronize member stations with the BSS, and other information to help them locate and choose the BSS with the best signal and availability.
||Announcement Traffic Indication Message. This packet serves much the same function in an IBSS that the Beacon packet does in an infrastructure (BSS or ESS) topology. The packet sets the synchronization of the group and announces that messages are waiting to be delivered. Stations in Power Save mode wake up periodically to listen for ATIM packets in ad hoc (IBSS) networks, just as they do for Beacon packets in infrastructure (BSS or ESS) networks.
||This packet is an announcement breaking an existing association. It is a one-way communication (meaning it does not require or accept a reply), and must be accepted. It can be sent by any associated station or BSS and it takes effect immediately.
||Authentication packets are sent back and forth between the station requesting authentication and the station to which it is attempting to assert its authentic identity. The number of packets exchanged depends on the authentication method employed. Information relating to the particular scheme is carried in the body of the Authentication packet.
||This packet is an announcement stating that the receiver is no longer authenticated. It is a one-way communication from the authenticating station (a BSS or functional equivalent), and must be accepted. It takes effect immediately.
||Power Save polling packet. Stations in power save mode awaken periodically to listen to selected Beacons. If they hear that data is waiting for them, they will awake more fully and send a PS-Poll packet to the access point (BSS) to request the transmission of this waiting data. In Control packets of the Power Save-Poll type, the Duration/ID field contains the association ID (AID) for the station sending the packet.
||Request To Send. Coordinates access to airwaves.
||Clear To Send. Response to a RTS, coordinates access to airwaves.
||Acknowledges receipt of transmitted data.
||Signals the end of Contention Free period.
||CF End + CF ACK
||Signals the end of the Contention Free period and Acknowledges the receipt of some packet in a single message.
||Multiple subtypes exist for Data type packets, but all have the same basic format, as described above. (see Appendix C, “802.11 WLAN Packets and Protocols”.) The different Data subtypes essentially just piggyback CF-Poll, CF-ACK, and CF-End messages onto the data message in a single transmission. This allows the BSS to gain higher throughputs possible using PCF (point coordinating function).
dd bs=512 if=/dev/rXX# of=/some_dir/foo.dmg conv=noerror,sync
Using “dd” inside of OSX I was able to copy the affected disk bit by bit to an image file and then convert that file to a readable format for OSX to mount:
1. Get device ID of disk via
then created the image via:
dd bs=512 if=/dev/XXX of=/some_dir/foo.dmg conv=noerror,sync
2. Next I converted the .dmg to an img for mounting via
hdiutil convert input.dmg -format UDTO -o output.img
Had a curious case of a Macbook Pro which had a browser hijack from what appeared to be some nasty Malware.
It was overlaying a small window in the bottom left of every new browser window in both Google Chrome and Safari (both latest versions as of 11/03/2015).
The window usually suggested a Russian Bride or pyramid “investment” advert. The malware was also subverting any links clicked from legitimate pages and returning the request (mostly) but also opening an additional tab to more advertising websites (bettering, bridges, “investments” etc).
Booting the system into a live USB 10.10 environment allowed me to Sophos 9.2.2 scan the drive which highlighted an infected “Install paint.dmg” file but nothing else.
Having removed that I began some web searching and came across an informative HowToGeek article: http://www.howtogeek.com/210589/mac-os-x-isn%E2%80%99t-safe-anymore-the-crapware-malware-epidemic-has-begun/
Also some informative results on an Apple discussions thread : https://discussions.apple.com/thread/6673353
This led me to :
- Searching /Library/Launch Agents/ where I found a “com.bubble.plist”, looking at the file it was indeed making references to /Library/Application Support/Launch Agents/bubble
- I then removed /Library/Launch Agents/com.bubble.plist and also /Library/Application Support/Launch Agents/bubble
- Rebooted the Macbook Pro and the problem seemed to be resolved! I’m never 100% confident in these areas but Sophos is happy (it failed to install during the infection but installed happily afterwards).
1. Get the identity of the physical disk using
from the command line. Usually it’s named “System” if booting from an OSX Live USB drive
2. Unmount the physical disk from the system
3. From terminal create a holding VMDK file for Virtualbox to communicate with the physical disk through by:
“sudo VBoxManage internalcommands createrawvmdk -filename <<DIR/FILE.vmdk>> -rawdisk /dev/disk<<#>>”
4. Correct permissions on both the physical disk and the file you created, something like:
“sudo chmod 777 /dev/disk<<#>>”
“sudo chown <<group>>:<<user>> <<DIR/FILE.vmdk>>”
“sudo chmod 770 <<DIR/FILE.vmdk>>”
5. Launch Virtualbox, create a new DOS VM and attach a SATA Controller and then the new VMDKfile as a SATA disk
6. From Virtualbox “File>Virtual Media Manager”, modify the <<DIR/FILE.vmdk>> so that it’s set as a “writethrough” disk
7. Then attach the desired boot cd to the VM and ensure the boot order is correct
8. Start the VM!
To add an additional IP to a network interface on OSX using the GUI simply “replicate service” on any interface via the cog in [Network Settings] and then assign the IP to the replicated interface manually.
From the terminal:
sudo ifconfig en1 inet xxx.xxx.xxx.xxx netmask 255.255.255.0 alias
Where sudo = execute as root, en1 = the interface you want to add an alias to, xxx.xxx.xxx.xxx = ip you wan to add, 255.255.255.0 = desired netmask.
/Users/<USERNAME>/Library/Application Support/Microsoft/Office/Office 2011 AutoRecovery