I built a privacy-first, cross-platform hardware information tool in Rust

econovibe — Tue, 06 Oct 2026 11:40:10 +0000

There are already plenty of applications that can tell you what hardware is inside your computer.

CPU-Z, HWiNFO, Speccy, system utilities built into the operating system — this is definitely not a new category of software.

But I wanted to build my own.

The result is MyHardwareInfo, an open-source desktop application for inspecting your computer's hardware and system information locally.

It runs on Windows, Linux, and macOS, is built with Rust and egui/eframe, and is designed around a simple principle:

Your hardware information should stay on your computer.

GitHub:

https://github.com/econovibe/MyHardwareInfo

What is MyHardwareInfo?

MyHardwareInfo is a native desktop application that collects hardware and operating system information and presents it through a simple graphical interface.

The application currently has nine main areas:

Overview
CPU
GPU
Memory
Motherboard
Storage
Network
Operating System
Full Report

It can collect information such as CPU details and utilization, memory usage, physical storage, mounted volumes, graphics hardware, network configuration, operating system information, motherboard and firmware data, depending on what each operating system and driver exposes.

The goal isn't to replace every specialized diagnostic tool.

Instead, I wanted one straightforward application that could give me a useful overview of a computer without requiring an account, cloud service, installer ecosystem, or telemetry.

Privacy was one of the main design goals

Hardware inspection applications can see surprisingly sensitive information.

A system report may contain things like:

computer and user names
disk serial numbers
motherboard identifiers
MAC addresses
IP addresses
gateways
DNS configuration

Because of that, MyHardwareInfo was designed to operate locally.

The application has:

No accounts.

No telemetry.

No analytics.

No update checks.

No uploads.

Collection, clipboard operations, and report generation happen locally.

The application does not intentionally make Internet requests or DNS lookups while collecting system information.

Network information is read from the computer's existing configuration rather than discovered by sending probe packets.

Reports are redacted by default

This became another important feature.

When generating a report, potentially identifying information such as computer names, user names, serial numbers, MAC addresses, IPv4/IPv6 addresses, gateways, and DNS servers is redacted by default.

The user has to explicitly opt in if they want those identifiers included in the Full Report.

This makes it easier to share a report without accidentally publishing information that probably shouldn't be public.

From Windows-only to cross-platform Rust

The original version of MyHardwareInfo was a Windows application built with WPF.

I eventually rebuilt the application in Rust, using egui/eframe for the interface.

That allowed the project to evolve into a native application for:

Windows x64

Linux x64

macOS Apple Silicon

macOS Intel

The cross-platform part turned out to be one of the most interesting challenges because there isn't a single universal API for getting detailed hardware information.

Each operating system exposes information differently.

How hardware information is collected

The application uses different local sources depending on the operating system.

Windows

On Windows, MyHardwareInfo uses technologies including:

WMI
Windows Registry
Win32 APIs
system performance counters
Direct3D-related system information

It can collect information about physical disks, memory modules, CPU metrics, display configuration, motherboard information, network configuration, and other Windows-specific hardware data.

There is also optional support for locally exposed NVIDIA metrics when available.

Linux

Linux is very different.

The Linux collector combines the Rust sysinfo crate with information exposed through:

/proc
/sys
DRM
DMI/firmware interfaces
routing information
filesystem/device information

lspci is optional and can provide friendlier PCI device names when installed, but basic PCI identifiers remain available without it.

One interesting limitation is DIMM information.

Detailed memory module information often requires elevated privileges on Linux, and MyHardwareInfo deliberately runs as the current user instead of requesting root access.

If the operating system does not expose something safely to the current user, the application prefers to report it as unavailable rather than requiring privilege escalation.

macOS

On macOS, the application combines sysinfo with Apple's local system utilities and APIs, including structured output from tools such as:

system_profiler
diskutil

It also reads local routing, resolver, hardware, disk, GPU, display, memory, and firmware information.

Apple Silicon creates some interesting reporting challenges because CPU and GPU share unified memory.

Instead of pretending that an Apple Silicon GPU has a conventional dedicated VRAM value, MyHardwareInfo identifies it as unified/shared memory.

No administrator or root requirement

Another design decision was to keep the application running as the normal user.

MyHardwareInfo does not request administrator or root privileges.

That means some information may not always be available.

Depending on the operating system, hardware, drivers, and permissions, this can include things like:

DIMM details
serial numbers
GPU temperatures
GPU utilization
GPU clocks
some firmware information

I'd rather show a field as unavailable than require unnecessary privilege escalation just to populate it.

Keeping the interface responsive

Hardware discovery isn't always instant.

WMI queries, filesystem inspection, firmware information and platform utilities can take time.

Because of that, hardware collection does not run directly on the UI thread.

MyHardwareInfo performs collection in background workers and sends the resulting snapshot back to the interface.

The user can manually request a new hardware snapshot using Refresh, F5, or Alt+R.

This was particularly important for keeping the GUI responsive even when one hardware category takes longer than expected.

Exporting hardware information

Besides viewing information in the interface, the application can generate reports.

Currently it supports:

TXT reports

Useful when you just want a readable system specification.

JSON reports

Useful if the hardware information needs to be processed by another program or script.

Values displayed in the application can also be selected and copied.

As mentioned earlier, identifying fields in generated reports are redacted by default.

Testing hardware software is surprisingly difficult

One thing I learned from this project is that cross-platform hardware detection is difficult to test properly.

A program compiling successfully for another operating system doesn't prove that hardware detection actually works there.

So the project uses native CI runners for:

Windows x64
Ubuntu x64
macOS Apple Silicon
macOS Intel

Tests cover areas including:

real CPU and memory collection
operating system collection
report redaction
JSON serialization/deserialization
formatting
hardware parser fixtures
category failure isolation
keyboard navigation
accessibility nodes
release packaging
offline-source policy

There is also a GUI smoke test that launches the application, collects hardware data, renders a report, and closes automatically.

Of course, hardware software can never be completely validated by CI.

Different GPUs, drivers, motherboards, firmware implementations and unusual storage configurations will always introduce edge cases.

Checking the offline policy

Since the application claims to be privacy-first and offline, I wanted that principle to exist in the project itself rather than only in the README.

The test suite includes an offline policy check that scans the application's Rust and build sources for communication and browser APIs that shouldn't be there.

It also validates direct dependencies against that policy.

This isn't meant to replace a professional security audit or packet capture.

But it provides an automated guard against accidentally adding network functionality to an application that is supposed to work locally.

Native rendering

The default GUI renderer uses wgpu, which maps to native graphics APIs depending on the platform.

That can mean Direct3D on Windows, Metal on macOS, and Vulkan or other supported backends on Linux.

There is also an OpenGL-based fallback using:

MyHardwareInfo --renderer=glow

This is useful when a particular graphics driver doesn't cooperate with the default renderer.

Building it yourself

The entire project is open source and can be built with Rust.

At the simplest level:

cargo run --locked

or:

cargo build --release --locked

The repository contains the platform-specific build requirements and packaging instructions for Windows, Linux, and macOS.

The project also pins its Rust toolchain and keeps dependencies locked through Cargo.lock to make builds more reproducible.

Downloads

Prebuilt releases are available directly from GitHub:

https://github.com/econovibe/MyHardwareInfo/releases/latest

There are builds for:

Windows x64
Linux x64
macOS Apple Silicon
macOS Intel

Release downloads also include SHA-256 checksums so binaries and archives can be verified after downloading.

The Windows executable is currently unsigned, and the macOS application is not Developer ID notarized, so those operating systems may show their normal security warnings for software from an unidentified developer.

The README explains these limitations before users download anything.

Open source with a permissive license

MyHardwareInfo is released under the Zero-Clause BSD (0BSD) license.

That means the source can be used, copied, modified, redistributed, relicensed, or incorporated into other projects without an attribution requirement.

The official repository is maintained as a personal project rather than a community-maintained project, so it currently does not accept external pull requests, issues, feature requests, or support requests.

Forking and independent modification are welcome.

What I learned from building it

What looked like a relatively simple idea — "show me information about my computer" — quickly turned into a much deeper systems programming project.

The UI wasn't really the difficult part.

The interesting problems were things like:

discovering the same conceptual hardware across very different operating systems
deciding which information is trustworthy
distinguishing physical disks from logical volumes
dealing with hardware information hidden behind permissions
avoiding misleading GPU metrics
handling Apple unified memory correctly
preventing one broken hardware query from breaking the whole report
designing reports that are useful without leaking identifiers
validating behavior on operating systems I wasn't currently running

It gave me a much better appreciation for established hardware tools.

A polished hardware information utility hides a huge amount of platform-specific complexity behind what looks like a simple list of specifications.

Try MyHardwareInfo

If this kind of project interests you, you can find the source code, documentation, architecture notes, and downloads here:

GitHub:

https://github.com/econovibe/MyHardwareInfo

It's still a personal project, but building it has been a very interesting way to explore Rust, desktop development, operating-system APIs, and the messy reality of cross-platform hardware detection.

I'd be interested to hear how other developers approach cross-platform system information tools — especially where operating systems disagree about what a piece of hardware actually is.

DEV Community: econovibe