Capturing and Analyzing WiFi Handshakes with Node.js

Capturing and Analyzing WiFi Handshakes with Node.js

pr0h0
node-jswifi-securitynetwork-analysiswireless-protocols
AI Usage (88%)

Why WiFi Handshakes Matter in Security Testing

A WPA/WPA2 handshake is not the password itself. It is a short exchange that shows both sides know the key material and can derive the same session keys.

That makes it useful in testing because the handshake tells you whether a network is using the authentication flow you expect, whether clients roam cleanly, and whether your capture path is actually seeing management and EAPOL traffic. If you are auditing wireless security, this is often the first artifact you can review without touching the access point configuration.

What a WPA/WPA2 Handshake Actually Contains

In practice, a captured handshake gives you:

  • MAC addresses for the client and access point
  • ANonce and SNonce values
  • replay counter values
  • MIC-protected EAPOL key frames
  • enough metadata to confirm which association attempt you saw
💡

The handshake is useful for analysis, but it is not a license to attack networks. Keep the work inside your own lab or an environment you are explicitly authorized to test.

The detail that matters most is the EAPOL exchange. For a normal WPA2 four-way handshake, you are looking for frames that carry key information elements, not ordinary data traffic. If your capture only shows beacon frames and encrypted payloads, you probably missed the right window or the adapter was not truly in monitor mode.

Where Node.js Fits in the Workflow

Node.js is not the radio layer, and it is not the packet sniffer. I use it after capture, when I want to automate parsing, flag interesting frames, or build a repeatable review step for lab traffic.

Capturing Frames Without Rebuilding the Tooling Stack

Do the radio work with established tools and hardware. Capture to a PCAP first, then let Node.js handle the boring parts: opening the file, iterating packets, and extracting handshake metadata.

That keeps the pipeline simple:

  1. Put the adapter in monitor mode.
  2. Capture a controlled test exchange.
  3. Export the PCAP.
  4. Parse only the frames you care about.

Parsing Handshake Data from a Safe Test Capture

A safe workflow is to use a lab AP and a test client you control. Trigger one association, collect the capture, and verify that the expected EAPOL frames are present. From there, Node.js can summarize what happened without storing more than the minimum you need.

Setting Up a Controlled Lab Environment

Required Hardware and Driver Constraints

Monitor mode support is the main constraint. Not every USB adapter and driver combination will expose raw 802.11 frames cleanly. In my experience, the failure mode is usually one of these:

  • the adapter claims monitor mode but drops management frames
  • the driver strips radiotap metadata
  • the capture tool works on one OS but not another
  • the antenna and channel selection are wrong for the target AP

Use hardware you know can actually see 802.11 frames on the band you plan to test.

Legal and Safety Boundaries

Do not test on networks you do not own or have explicit permission to assess. Capturing wireless traffic can cross legal lines fast, even if you are only “looking at metadata.”

Keep the lab isolated:

  • use your own AP and client
  • test on a non-production SSID
  • avoid real credentials
  • wipe captures when you no longer need them

Practical Capture and Analysis Workflow

Verifying the Adapter Is in Monitor Mode

Before parsing anything, confirm the adapter state. If your tool shows 802.11 headers and channel information, you are closer to the right path. If it only behaves like a normal network interface, stop there.

A quick sanity check is to look for radiotap headers and packet types other than ordinary IP traffic. If those are missing, the capture is probably not usable for handshake analysis.

Exporting a PCAP and Inspecting It in Node.js

Once you have a capture, Node.js can read it as a binary file and scan for the EAPOL EtherType. The point is not to decode every WiFi nuance in JavaScript. The point is to identify the handshake frames and pull out the fields that matter for review.

Detecting EAPOL Messages and Nonce Fields

The fields I usually extract are:

FieldWhy it matters
Source and destination MACConfirms AP/client roles
EAPOL key frame typeIdentifies handshake traffic
Replay counterHelps spot repeated or out-of-order frames
ANonce / SNonceConfirms the key exchange progressed
MIC presenceHelps validate frame integrity

A lot of bad analysis comes from mixing up frame types. Beacon frames, probe responses, and EAPOL key frames are different layers of the conversation. If you do not separate them, the output looks busy but says very little.

Example Node.js Parser for Handshake Metadata

parse-eapol-metadata.js
import fs from "node:fs";

const pcap = fs.readFileSync("lab-capture.pcap");

function hex(u8, start, len) {
return Buffer.from(u8.slice(start, start + len)).toString("hex");
}

function findEapolFrames(buf) {
const frames = [];
for (let i = 0; i < buf.length - 20; i++) {
  // Very small, safe heuristic for demo purposes only.
  // In a real parser, decode the PCAP and radiotap/802.11 headers properly.
  if (buf[i] === 0x88 && buf[i + 1] === 0x8e) {
    frames.push({
      offset: i,
      etherType: "EAPOL",
      replayCounter: hex(buf, i + 9, 8),
      keyInfo: hex(buf, i + 5, 2),
    });
  }
}
return frames;
}

const frames = findEapolFrames(pcap);

console.log(`found ${frames.length} candidate EAPOL frames`);
for (const frame of frames.slice(0, 5)) {
console.log(frame);
}

This is intentionally minimal. A real parser should decode the PCAP container, then walk the link-layer headers before it inspects EAPOL fields. The important part is the workflow: identify candidate frames first, then validate them against the capture format instead of guessing from byte offsets.

Common Mistakes When Reviewing Captures

The same errors show up over and over:

  • treating encrypted traffic as proof of a handshake
  • forgetting that channel hopping can miss one of the four messages
  • assuming a capture is good because it is large
  • parsing raw bytes without checking the link-layer type
  • using production traffic instead of a controlled lab test
⚠️

A capture with missing frames can still look convincing. If you cannot explain where the client was, which channel was active, and which EAPOL messages are present, the analysis is not reliable.

Defensive Uses of This Analysis

This work is useful on defense too. You can use handshake analysis to confirm:

  • whether clients successfully reauthenticate after roaming
  • whether an AP is emitting the expected security mode
  • whether your monitoring sees deauth or reconnect patterns
  • whether a wireless test bed is configured the way you think it is

It also helps incident responders spot odd association churn. A sudden burst of failed handshakes, repeated replay counters, or inconsistent client behavior can point to interference, misconfiguration, or active abuse.

Conclusion

Node.js is a good fit for post-capture analysis because it is easy to script, easy to test, and good at turning binary junk into a small report you can read. The key is to keep the workflow honest: capture in a controlled lab, verify the adapter is really seeing 802.11 frames, and parse only the handshake metadata you need.

If you are serious about wireless testing, the packet format matters more than the language. Node.js just makes it faster to see what is already there.

Share this post

More posts

Comments