Downloading older versions of Mac OS

This post will hopefully also serve as a periodically updated listing with links to older Mac OS versions for download for offline installation from image/ISO or reinstallation whether to install anew or as a way to downgrade.

It used to be that with the Mac App Store, if you downloaded the current (or new beta?) version of Mac OS, even if you delete the downloaded installer and chose not to upgrade, in the future if you ever needed it, it would be searcheable in the App Store and show up in your purchase/downloads section for re-download. You could then use various tools/scripts to generate an ISO image of the installer, etc. to deploy on DVD or a USB drive for install from boot/reboot. So the trick is to do this process for every new Mac OS release so you have it in your purchase/download history for access in future. But it seems this feature was removed in recent newer version of the App Store app. In any case, still might be useful to continue this process should this type of feature come back in the future. For your reference, this feature from what I know at least, last worked (i.e. is available) on App Store v2.4 (658.1) on Mac OS X 10.13.6 (High Sierra), and was not available on App Store v3.0 (1003.3) on Mac OS X 10.14.6 (Mojave).

As such, without that feature, it seems Apple did at least offer up some online repositories/links for getting some older versions of Mac OS X, and I list them below. If you know of additional ones that I don’t please share. I’ll update as I find more in future.

https://itunes.apple.com/us/app/macos-mojave/id1398502828?ls=1&mt=12

https://itunes.apple.com/us/app/macos-high-sierra/id1246284741?ls=1&mt=12

Mac OS X 10.12 (Sierra)
http://updates-http.cdn-apple.com/2019/cert/061-39476-20191023-48f365f4-0015-4c41-9f44-39d3d2aca067/InstallOS.dmg

Mac OS X 10.11 (El Capitan)
http://updates-http.cdn-apple.com/2019/cert/061-41424-20191024-218af9ec-cf50-4516-9011-228c78eda3d2/InstallMacOSX.dmg

Network (HTTP, etc.) packet capture setup across different client devices

General methods across all devices

These methods should work for all devices, for most use cases, and can be used when you can’t directly capture traffic from the device itself (unlike laptops, desktop computers).

Proxy client traffic to a host that can do packet capture

1. Have a host machine like your Mac/Windows/etc. laptop to do the capture, using wireshark/tshark/ tcpdump.
2. Use/install a proxy server on the host machine (e.g. Charles proxy on Mac, Fiddler on Windows).
3. Follow the proxy instructions to install the proxy’s SSL certificate to your client devices under test (in case you need to capture/decrypt SSL/HTTPS/WSS traffic).
4. Route/enable the client device’s (wifi) network connection to use an (HTTP) proxy, entering the values for your given proxy (the defaults or your own customized values you set on the proxy server).
5. Start proxy server on host machine.
6. Start capture on host machine.
7. Generate the desired traffic activity on client device.
8. Stop capture on host machine.
9. Stop proxy server on host machine.
10. Disable/unroute client device network traffic over the proxy.

NOTE: this probably only works provided the client traffic is based on HTTP/HTTPS/WS/WSS, where the capture will also capture the TCP/UDP packets. Not sure if it goes through other protocols whether this will work. Although most mobile devices use HTTP/HTTPS anyhow.

Shared/open network sniffing/capture

With this setup, you have a host machine like your Mac/Windows/etc. laptop or some server or Raspberri Pi to do the capture, using wireshark/tshark/ tcpdump. This host resides on a network where traffic is broadcast on all the ports (e.g. use of hub instead of switch and router, etc. at the lowest leaf level of the network where the testbed is set up) and thus said desired traffic is available to the host machine to sniff & capture.

For this simply ensure the target client to capture is in some way connected to this open sniffing/capture network, and then you can do the capture at any time as desired.

If the clients are wireless, that means the access point has to be connected to this open sniffing/capture LAN to capture the traffic.

Device specific traffic capture

iOS traffic capture

To save hassle of dealing iOS device UUID (finding it with XCode/iTunes, and then making use of it), use the script from here to wrap the process for you: https://thrysoee.dk/iospcap/.

Once that is done and the tool is started to allow capture for (USB) attached iOS device, simply use the interface(s) rviN, where N is a number starting from 0 (typically rvi0 for single device), with the capture tool (Wireshark, tshark, tcpdump). Follow the tool commands to stop the interface service after done capturing.

NOTE: this method is only for use with a Mac. For Windows, Linux, you might first need to install some software to be able to do this: https://github.com/gh2o/rvi_capture ‑ Connect your account to preview links.

Android traffic capture

There can be multiple options for traffic capture here, more especially if the client device is rooted. However, we’ll go with the simplest approach at the moment:

Use tPacketCapture app from Google Play Store.

To use the app for capture:

1. Open the app.
2. Click Capture button. Button name should change to Running, and a key-like icon will then show up in the upper/top left corner of the status bar of the device, for access to stop/disconnect the capturing.
3. Note the filename for this capture listed under “Current File” section, for reference.
4. Generate the desired traffic activity on client device.
5. Stop the capture by accessing the key-like icon at upper/top left corner of device.
   1. in the popup that appears choose disconnect (or equivalent) option.
   2. optionally kill the app to save resources, and kill whatever other apps were used for generating traffic to capture.
6. Transfer the capture file from the device to a computer for further analysis and permanent storage if desired.
   • can transfer over USB cable connection, using like Android File Transfer tool on Mac, or equivalent on Windows (which should have native file storage access over Windows Explorer).
   • can transfer over NFC
   • The capture files can be found under a path like (internal storage of Android device)/Android/data/jp.co.taosoftware.android.packetcapture/files/YYYY_MM_DD_HHMMSS.pcap.
   • you can optionally delete the files from the device afterwards to save space & for less cluster/confusion.

Make a good suggestion (to open source) and things will come

Post a bit delayed compared to a recent mobile automation feature release, as I’ve been busy. But wanted to mention about this. And also relevant to those who ask how they can help/contribute to open source. Sometimes, all it takes is a good idea/suggestion.

Long time back, I made a suggestion to Appium project about being able to have additional “find element by” logic using images, similar to what Sikuli does, and suggested how the implemented command may be used by a user. It was put under consideration, and recently implemented.

The original request: https://github.com/appium/appium/issues/943

And article about the recent implementation: https://appiumpro.com/editions/32

Uninstall old SafariDriver on recent versions of Safari

Aside from not needing SafariDriver starting in Safari 10 (or was it 9? I forget) and requiring recent versions of Selenium with older versions of Selenium paired with older Safari using SafariDriver, if you’re like me and haven’t used Selenium/SafariDriver in a while, you might have left the browser with SafariDriver extension.

If you update Mac OS X and Safari, you may still have the extension installed unless you specifically uninstall it.

One interesting quirk about having it installed is that it can now cause problems on certain websites (likely from same core issue from something in the extension’s codebase):

TypeError: Value is not a sequence

This came up for the websites from my company as well as Apple’s iCloud.com.

Once I uninstalled the extension, everything was fine.

Awesome Stuff – Selenium, RobotFramework, test automation, etc.

A while back I came across the “awesome” series of listings of (good?) resources for a given category (awesome go/java/ruby/python/etc.).

Well, it’s nice that it has expanded to other areas beyond programming languages, and per se to my original blog content, some areas I and my readers are interested in that I thought to share (if you haven’t already come across them):

• https://github.com/christian-bromann/awesome-selenium
• https://github.com/fkromer/awesome-robotframework
• https://github.com/atinfo/awesome-test-automation

I’m contributing to these as I can. And we all should, but at the same time, in keeping with the motto “awesome”, entries in the list should have good reason to be there, not just “yet another related thing to put on the list”, should be something special, otherwise, it will end up a bloated list of (spam-y) stuff.

Cheers to Microfocus and SilkTest for supporting Selenium-based features!

In particular, I’m most intrigued by them offering support/integration with WebDriver API access to SilkTest. That means automating with SilkTest using WebDriver APIs (via a tool called SilkAppDriver) in your language of choice, not running Selenium tests through SilkTest IDE/code, although I’m sure the latter is supported in some way.

WebDriver API is a W3C specification, and it’s great if we can get more applicable tools to use that protocol to drive (G)UI automation than to have different proprietary languages, frameworks to for each tooling vendor. Say for example, you can switch out your home access point or router and your network still works the same as they speak same protocol. Shouldn’t have to be a pain to switch out test automation tools either, the dreaded vendor lock-in.

And Microfocus also has a nice improvement over Selenium IDE as well: Silk WebDriver.

Now if only other (commercial) test automation tool vendors could follow suit.

NOTE: on a related note, I hope to see (more) variants of SilkAppDriver for the free and open source non-browser/mobile automation tools (since we have Selenium WebDriver and Appium/Selenoid for those already). We currently have these in the free/open source space: AutoItDriverServer, AutoPyDriverServer.

Update 01/26/2018: I just came across Ranorex Selocity, a Firebug/FirePath/Firefinder replacment, but for Chrome instead of Firefox. Cheers to Ranorex for offering such a tool. Now I hope they follow on with their equivalent to SilkAppDriver, and perhaps especially Silk WebDriver since Selocity is closer to the latter than the former, but I personally prefer more options of the former.

On filing bugs to Apple

Unlike other public bug tracking systems, Apple’s one is closed to public viewing other than Apple and the reporter of the bug.

So bugs you report, others can’t see the status of. And as such, there can be likelihood of duplicate bugs being filed, etc. I assume Apple has good reasons to overlook potential duplicate bugs in favor of this closed access bug tracking system.

Amusingly, a public repository of Apple bugs is available at OpenRadar. It’s useful for the public community to look for existing bugs filed to Apple before filing their own, and check status of said bugs. There is one caveat though, OpenRadar does not pull data from Apple’s system. Therefore to get data into OpenRadar, one must file a “duplicate” bug to it for whatever one files to Apple.

As such, I would recommend those of us who deal with Apple bugs to:

1. Check OpenRadar first before filing bug to Apple. If one exists on OpenRadar, just subscribe to and monitor that. Although one is free to file a duplicate to Apple just in case.
2. If one doesn’t exist on OpenRadar, then file bug to Apple. And if the bug is not specific to your internal case (confidential/security/proprietary info, intellectual property, etc.), post a duplicate filing on OpenRadar. This allows the public to see the bug you filed. Also makes it easier for team members to view the bug for those teams that don’t use a shared/team Apple developer account or whose said accounts aren’t all under the same organization access. NOTE: that if you file a duplicate post on OpenRadar, do try to keep it updated or in sync with changes/updates on the official bug you have with Apple, so the public knows the status of it.