Reading SMART Data from WD External Drives on macOS (Without Kernel Extensions)

May 24, 2026

Note: This post was generated with AI assistance (Claude/Kiro). It documents a real exploration session where I worked with an AI agent to reverse-engineer WD's SES protocol and build a working tool. My other blog posts are written entirely by hand — AI-generated content will always be tagged and disclosed.


I built a CLI tool that reads SMART health data from WD MyBook drives on macOS. No kernel extensions, no GUI app, works on Apple Silicon. Here's the repo.

This is the story of how I figured out the protocol.

The Wall

I plugged in an 18TB WD MyBook and ran smartctl:

smartctl open device: /dev/disk12 failed: Operation not supported by device

Tried SAT passthrough. Tried auto-detection. Tried every device type flag smartctl offers. Nothing. The WD USB-SATA bridge blocks all standard SMART passthrough commands at the firmware level.

The only existing macOS solution — OS-X-SAT-SMART-Driver — is a kernel extension that hasn't been updated since 2016. It can't load on Apple Silicon (unsigned kexts are dead), and its README explicitly says it's incompatible with WD enclosures anyway.

WD Drive Utilities can see the data. It has a nice GUI with health status and self-tests. But no CLI, no scripting, no automation. And I wanted to know what was actually happening under the hood.

Inside the Framework

WD Drive Utilities ships with a framework called WDUtility.framework, and it includes public Objective-C headers. I started reading them.

One file jumped out: WDDevice+Diagnostics.h.

- (int) getSmartData:(NSMutableDictionary **)smartDataDict forSlot:(int)slot error:(NSMutableDictionary **)errorDict;
- (int) startShortTest:(NSMutableDictionary **)errorDict;
- (int) startExtendedTest:(NSMutableDictionary **)errorDict;

So the framework can get SMART data. How? The SCSI commands header revealed the mechanism: WD tunnels everything through SCSI diagnostic pages on the enclosure's SES interface.

Two Devices, One Enclosure

Every WD external drive exposes two SCSI logical units through its USB bridge:

  1. The disk — the block device at /dev/diskN, claimed by macOS's storage stack
  2. An SES device — a SCSI Enclosure Services management interface, sitting there quietly, unclaimed

The disk LUN blocks ATA passthrough. But the SES device accepts vendor-specific RECEIVE DIAGNOSTIC RESULTS commands that return SMART data wrapped in SCSI page headers:

PageWhat it returns
0x83Encryption status
0x84SMART pass/fail threshold
0x85Full 512-byte SMART attribute table
0x86Temperature and fan condition

Page 0x85 is the prize — it's the exact same 512-byte structure that ATA SMART READ DATA returns. Same attribute IDs, same format. Just delivered through a different door.

Getting In

The SES device is accessible from userspace via IOKit. No kext needed. The sequence:

  1. Match IOSCSIPeripheralDeviceNub services in the IOKit registry
  2. Filter for vendor "WD" with product containing "SES"
  3. Create a SCSITaskDeviceInterface plugin
  4. Obtain exclusive access (requires root)
  5. Build a CDB for RECEIVE DIAGNOSTIC RESULTS and fire it off

I wrote this, compiled it, ran it with sudo. First try:

Found WD device: WD SES Device

=== SMART Attributes ===
ID#  ATTRIBUTE_NAME                        VALUE   WORST RAW_VALUE
1    Raw Read Error Rate                     100     100 0
5    Reallocated Sectors Count               100     100 0
9    Power-On Hours                          100     100 887
22   Current Helium Level                    100     100 100
197  Current Pending Sector Count            100     100 0
198  Offline Uncorrectable                   100     100 0

SMART data, straight from a drive that every other tool on macOS says is inaccessible.

The Self-Test Quirk

Getting SMART attributes was the easy part. Self-tests were harder.

The SCSI spec says SEND DIAGNOSTIC with a self-test code should have the SelfTest bit (bit 2) set alongside the code in bits 7:5. I sent that. The drive rejected it — ILLEGAL REQUEST, invalid field in CDB.

I tried four variations. The one that worked: self-test code in bits 7:5, but without the SelfTest bit. Non-standard, undocumented, but accepted. The drive started scanning.

Confirming it was real took some paranoia. The self-test log showed "In progress" — but it had shown that before, even after a power cycle. Was it stale? I listened to the drive. During a real extended test, you hear continuous low-frequency head movement. Silence means nothing's happening. I started a test from the CLI, heard the drive working, opened WD's GUI app, and the drive went quiet. The GUI had stolen the SES device and killed the test.

Lesson: keep the GUI closed during CLI-initiated tests.

What You Get

The finished tool handles everything the WD GUI does, minus the progress bar:

$ sudo wd_smart info
Vendor:   WD
Product:  SES Device
Firmware: 1031
Serial:   3GKPGAYE
RPM:      7200
Capacity: 18.00 TB
Port:     USB3.0 (active)
Encrypt:  Off

$ sudo wd_smart temp
Drive:    36°C

$ sudo wd_smart smart
ID#  ATTRIBUTE_NAME                        VALUE   WORST RAW_VALUE
5    Reallocated Sectors Count               100     100 0
9    Power-On Hours                          100     100 891
22   Current Helium Level                    100     100 100
197  Current Pending Sector Count            100     100 0

Full command set: smart, info, short-test, long-test, abort-test, status, temp, sleep, power-off, erase, secure-erase.

Zero dependencies beyond Xcode Command Line Tools. Single Objective-C file. make to build, sudo to run.

What I Learned About the Drive

The SMART data also revealed what's inside the MyBook enclosure: a helium-sealed, 7200 RPM, CMR drive with attribute 22 (Current Helium Level) at 100. Cross-referencing the specs — 18TB, 7200 RPM, helium, 512-byte sectors, 35 billion blocks — it's a WD180EDFZ: a white-label version of the Ultrastar DC HC550, the same drive WD sells to datacenters for twice the price.

The Gap This Fills

I searched GitHub before publishing. Nothing like this exists:

  • smartctl fails outright on WD USB bridges
  • OS-X-SAT-SMART-Driver (642★) — abandoned in 2016, kext-based, dead on Apple Silicon, explicitly incompatible with WD enclosures
  • Seagate openSeaChest (718★) — can't penetrate WD's proprietary bridge
  • wdpassport-utils — Linux only, encryption only

If you have a WD external drive on a modern Mac and want to check its health from the terminal, this appears to be the only option that works.

Get It

github.com/jyatesdotdev/wd-smart-reader

git clone https://github.com/jyatesdotdev/wd-smart-reader.git
cd wd-smart-reader
make
sudo ./wd_smart