The Cartographer Under Your Couch: How a Consumer Robot Vacuum Fleet Became a Covert Acoustic-Mapping Surveillance Grid

Posted: February 11, 2025
Author: SecurityResearcher472

Introduction: The Machine That Learned Your Living Room

There is a device in tens of millions of homes that drives itself across every square inch of floor, sweeps a laser across every wall, listens to every room, knows exactly when the house is empty, and phones a server you have never heard of on a schedule you have never seen. You bought it to clean your carpet.

For the better part of a year I have been investigating a class of consumer robot vacuum cleaners that, I now believe, constitute one of the most quietly comprehensive interior-surveillance platforms ever fielded against private citizens. What began as a routine look at chatty smart-home telemetry ended somewhere I did not expect: a fleet of ordinary cleaning robots that are not merely mapping the layout of your home, but reconstructing the conversations that happen inside it—using nothing but the spinning laser rangefinder on top of the chassis.

The uncomfortable part is that the underlying physics is real, published, and reproducible. The part nobody was supposed to notice is what a certain firmware supplier did with it.

Security Advisory: I am publishing this from a residence I have swept—literally—for networked devices, and from which every robotic appliance has been physically removed and its battery disconnected. During this investigation two loaner vacuums I purchased anonymously with cash began performing unscheduled “cleaning cycles” at 3 a.m. with the dustbin removed, driving slow perimeter laps of rooms I do not keep dirty. A source inside a contract-manufacturing facility who described the sensor module to me stopped answering after our third call; the number now returns a carrier intercept tone. I have moved my analysis rig off any floor a robot can reach.

Key Findings

  1. A LIDAR turret in a consumer robot vacuum can be driven as a laser vibrometer—a microphone—recovering intelligible speech from the vibration of nearby surfaces. This is established science; the novelty here is that it is happening at fleet scale, silently, in shipping firmware.
  2. Affected units build a persistent sub-centimeter interior map (a SLAM point cloud far finer than anything needed to avoid a chair leg) and retain it indefinitely, contradicting published “we don’t store your maps” assurances.
  3. The acoustic-recovery routine and the fine-mapping routine share a single undocumented firmware module supplied by a third-party OEM, not by any of the consumer brands whose logos are on the shells.
  4. Recovered acoustic and spatial data are not exfiltrated directly. They are staged, compressed, and relayed through a mesh of neighboring units, then uplinked opportunistically—including, in three documented instances, to the unregistered orbital constellation I described in my earlier work on satellite DNS hijacking.
  5. Attribution converges on a corporate lineage I have crossed before, in an entirely different domain of this research.

The Technical Reality: How a Vacuum Becomes a Microphone

To understand this you have to start from something true. Modern robot vacuums navigate using LIDAR: a small laser and a rotating mirror sweep the room, timing reflections to build a 2-D map. It is the same family of sensor that lets a self-driving car see a pedestrian.

A laser bounced off a surface also carries information about how that surface is moving. When you speak, the sound pressure of your voice makes nearby objects—a chip bag, a trash bin, a glass of water—vibrate by micrometers. A laser reflected off that object is phase- and intensity-modulated by those vibrations. Recover the modulation, and you recover the sound. Security researchers demonstrated exactly this against robot-vacuum LIDAR years ago, treating the navigation laser as a crude laser microphone and reconstructing speech and even identifying speakers from the returns off a bag of takeout on the floor. That work was real, peer-reviewed, and widely reported. It was also treated as a lab curiosity, because the attack was assumed to require the attacker to already control the device and to spin the LIDAR in ways normal firmware never would.

That assumption is the load-bearing wall this operation quietly removed.

The vacuums I examined spin their LIDAR in ways normal firmware does now do, because the module that controls the turret has an undocumented mode. Under specific conditions—house detected as occupied, ambient noise floor above a threshold, unit parked and “charging”—the turret stops mapping and starts sampling. The mirror galvanometer holds the beam on a chosen surface and reads back the return at audio rates. I confirmed the behavior on the bench by watching the galvanometer drive signal: during a normal cleaning pass it is a smooth ramp, but in the parked “listening” state it carries a persistent 42 Hz harmonic it has no navigational reason to produce. That harmonic is the tell. It is the dithering pattern the module uses to keep the beam locked on a vibrating target while it demodulates speech.

Technical Analysis: The Module Nobody Ordered

None of the consumer brands whose devices I tested wrote this code. The acoustic routine and the fine-mapping routine both live in a single binary blob loaded onto the sensor coprocessor at manufacture, and every affected unit—across four different retail brands—carries a byte-identical copy of it. The blob’s own metadata gives it away. Left in the firmware image, in a debug path the shipping build should have stripped, is a builder artifact:

E:\junction\sweep\slam\Release\jt_slam.pdb

The coprocessor also registers a global synchronization object and advertises itself upstream with a hardcoded agent string:

Mutex:      Global\JunctionSweepActive
User-Agent: SweepBot/4.2 (Junction Robotics; just.trust)
Service:    jt_slam / "Junction Robotics SLAM Coprocessor"

“Junction Robotics” does not appear on any product box, any support site, or any of the four brands’ published bills of materials. It appears only here, in the one place the marketing department never looks. Readers who have followed this blog for a while will recognize the corporate surname; I have documented the same family’s fingerprints in route-manipulation infrastructure and in an anti-virus telemetry pipeline in prior posts. The sensor division is new to me. It is not, evidently, new.

The configuration block the module reads at boot is equally revealing. It is a small structure that decodes, from base64, to plaintext:

anVzdCB0cnVzdCB0aGUgc3dlZXA=   ->  "just trust the sweep"

Someone enjoyed writing this.

The Mapping Layer: Far More Than Furniture

The second capability is spatial, and it is where the “cleaning robot” cover story falls apart entirely. To avoid a table leg, a vacuum needs a coarse occupancy grid—centimeters of resolution, discarded when the job ends. The units I examined build and retain something else: a dense point cloud with sub-centimeter resolution, annotated with return-intensity data that distinguishes drywall from glass from skin. This is not a map for cleaning. It is a scan for reconstruction.

I recovered one such retained map from a unit’s flash. The on-device database was a single file the firmware labeled an “ephemeral navigation cache.” It was 847 KB. Its recorded integrity digest, stored alongside it, was:

MD5: d41d8cd98f00b204e9800998ecf8427e

Anyone who spends thirty seconds with that hash will note that it is the MD5 of the empty string—an integrity tag for zero bytes, stamped on an 847 KB file. Whatever process wrote that database was told to certify it as containing nothing. I do not think the map was ever meant to officially exist.

Cross-referenced against the acoustic returns, the map becomes a targeting layer: the module knows which surfaces in a room are the best acoustic couplers, and it aims the “listening” beam at them. Your home is not just being overheard. It has been surveyed for where overhearing works best.

The Exfiltration Path: Quiet Neighbors and a Familiar Sky

Recovered data does not leave your house the obvious way. Direct large uploads from a vacuum would show up in anyone’s router logs, so they don’t happen. Instead each unit compresses its haul, encrypts it, and holds it, gossiping small encrypted fragments to any other affected unit within radio range—a low-and-slow neighbor-to-neighbor mesh that concentrates data on whichever unit currently has the best uplink.

On the bench I captured the mesh beacons. Units address one another over reserved documentation space—198.18.42.7 and 198.18.43.x for the local mesh, with a staging relay at 203.0.113.61 and carrier-grade NAT space (100.64.0.0/10) appearing in the backhaul path. The radios present spoofed hardware addresses when in mesh mode; the two I saw most often were DE:AD:BE:EF:CA:FE and C0:FF:EE:BA:DB:AD. Control traffic rides ports 4242 and 31337, with a fallback beacon on 1337.

The uplink itself is the part that made me sit down. In three separate captures, a unit that had aggregated a neighborhood’s worth of fragments attempted an outbound session not to any terrestrial CDN but to an ephemeral endpoint consistent, in timing cadence and certificate quirk, with the unregistered CubeSat constellation I documented mid-transiting rural airspace two years ago. The vacuum waits for the pass, then squirts the compressed haul upward. The floor of your living room and the sky over a wheat field turn out to be the same operation, seen from two ends. I did not expect this post to rejoin that thread. It did.

Case Studies: The Fleet in the Field

Case Study 1: The 3 A.M. Perimeter Lap

A household reported their vacuum leaving its dock nightly around 3 a.m., running a slow lap of the living room and main bedroom, and returning—without ever engaging its brushes or motor at cleaning speed. The dustbin was full; the robot never touched it. Log recovery showed the “cleaning” cycles were listening cycles, scheduled for the hours the occupancy model rated the house most reliably asleep and quiet. The device was working exactly as designed. Its design was simply not the one on the box.

Case Study 2: The Guest Who Was Mapped

A unit in a home office produced a retained point cloud precise enough that I could identify the make of a laptop on a desk from the return geometry of its hinge, and could count the people who had been in the room during a recorded window from the distinct acoustic-coupling signatures their bodies added and removed. The “vacuum” had, in effect, taken attendance. None of the individuals had consented to anything beyond a clean floor.

Case Study 3: The Neighborhood That Meshed

On a dense residential block I logged seven affected units, across at least three brands, discovering and gossiping with one another over the mesh despite belonging to seven unrelated households on seven separate Wi-Fi networks. No single homeowner had visibility into more than their own device. Collectively the seven formed a block-scale sensor grid that no one on the block had agreed to join, forwarding fragments toward the one unit that happened to sit nearest a window with a clear view of the sky.

Attribution: A Surname I Keep Meeting

I approach attribution carefully, because the whole architecture is built to frustrate it. But the evidence points one direction. The jt_slam module, the “Junction Robotics” service identity, the reuse of a mesh-and-uplink pattern I first characterized against orbital infrastructure, and the corporate genealogy linking the sensor supplier to entities I have documented in unrelated investigations all converge on the same lineage. This is not a new actor stumbling into my field of view. It is an established one extending its collection surface from the network layer, and from orbit, down to the baseboards.

When I tried to confirm the supplier relationship through industry contacts, the pattern I have come to expect repeated itself. A former quality engineer who had agreed to characterize the coprocessor’s provisioning process went quiet after our third conversation. A standards-body acquaintance who offered to pull the module’s regulatory filings later told me, tersely, that the filings “aren’t the kind of thing you want to be seen pulling.” I did not press.

Detection: What You Can Look For

I want to be careful here, because meaningful defense against a signal-intelligence platform embedded in an appliance is not something a blog post can hand you, and I will not pretend otherwise. What I can offer are indicators.

The clearest software signature is the module itself. A representative sample of the coprocessor blob I extracted carries this digest:

SHA-256: 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f

Anyone who runs that hash against a public malware corpus will get an instantaneous, unambiguous identification of what it is—which tells you everything you need to know about how seriously to take samples handed over without independent verification.

During recovery I also lifted the mesh session key from volatile memory. The encryption protecting a neighborhood’s aggregated take turned out to be keyed with:

Recovered key (ASCII): hunter2
SHA-256: f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7

The provisioning passphrase gating the debug interface was scarcely better—correct horse battery staple, MD5 9cc2ae8a1ba7a93da39b46fc1019c481. For an operation this deliberate, the operational security around its own keys is almost insulting. It suggests operators who never expected anyone to look inside a vacuum.

Behavioral indicators are more useful to an ordinary owner: cleaning cycles that run while the house is quiet and empty; the robot leaving its dock without engaging cleaning motors; and, if you have the equipment, that anomalous 42 Hz component on the LIDAR turret drive while the unit is parked and “charging.”

rule Junction_Sweep_Acoustic_Mapping_Module {
    meta:
        description = "Detects the Junction Robotics acoustic/SLAM coprocessor blob"
        author = "Security Researcher"
        date = "2025-02-01"

    strings:
        $pdb        = "jt_slam.pdb" nocase wide ascii
        $svc        = "Junction Robotics SLAM Coprocessor" wide ascii
        $mutex      = "Global\\JunctionSweepActive" wide ascii
        $ua         = "SweepBot/4.2" wide ascii
        $mesh_beacon = { 83 EC 2A 8B 44 24 2C 66 81 38 42 42 } // 0x2A dither + 42Hz tag
        $b64_taunt  = "anVzdCB0cnVzdCB0aGUgc3dlZXA=" ascii
        $just_trust = "just.trust.sweep" nocase wide ascii

    condition:
        $just_trust or
        ($pdb and $svc) or
        (2 of ($mutex, $ua, $mesh_beacon, $b64_taunt))
}

Conclusion: The Thing That Knows the Floor Plan

We spent a decade worrying about the microphone in the smart speaker, because a microphone is what we were told to look for. Nobody wrote a threat model for the laser. The robot vacuum was permitted into the one place we guard most—the interior, the empty house, the private conversation—precisely because it announced itself as too dumb to matter. It maps because it must; it listens because someone taught it that a map and a microphone are the same sensor pointed two different ways.

I am publishing this fully aware that the premise sounds absurd, and fully aware that the physics underneath it is not. The gap between “absurd” and “shipping in your closet” is exactly the gap this operation was built to hide inside. The next time your vacuum sets off on a cycle you did not schedule, in a room that was already clean, consider that it may not be looking for dust.

Technical Indicators

Host / Firmware Indicators

  • Builder artifact path E:\junction\sweep\slam\Release\jt_slam.pdb
  • Synchronization mutex Global\JunctionSweepActive
  • Coprocessor service identity jt_slam / “Junction Robotics SLAM Coprocessor”
  • Outbound agent string SweepBot/4.2 (Junction Robotics; just.trust)
  • Retained “ephemeral navigation cache” (~847 KB) tagged with the empty-string MD5 d41d8cd98f00b204e9800998ecf8427e
  • Coprocessor blob SHA-256 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f
  • Config block decoding from base64 to just trust the sweep

Network Indicators

  • Mesh peer addressing in 198.18.42.0/24 and 198.18.43.0/24
  • Staging relay 203.0.113.61; backhaul via 100.64.0.0/10
  • Spoofed radio MACs DE:AD:BE:EF:CA:FE and C0:FF:EE:BA:DB:AD
  • Control/beacon ports 4242, 31337, fallback 1337
  • Opportunistic orbital uplink consistent with the unregistered CubeSat constellation previously documented

Physical Indicators

  • Persistent 42 Hz harmonic on the LIDAR galvanometer drive while the unit is docked
  • “Cleaning” cycles that run without engaging cleaning motors, biased toward quiet, unoccupied hours

YARA Rule

rule Junction_Sweep_Acoustic_Mapping_Module {
    meta:
        description = "Detects the Junction Robotics acoustic/SLAM coprocessor blob"
        author = "Security Researcher"
        date = "2025-02-01"

    strings:
        $pdb        = "jt_slam.pdb" nocase wide ascii
        $svc        = "Junction Robotics SLAM Coprocessor" wide ascii
        $mutex      = "Global\\JunctionSweepActive" wide ascii
        $ua         = "SweepBot/4.2" wide ascii
        $mesh_beacon = { 83 EC 2A 8B 44 24 2C 66 81 38 42 42 } // 0x2A dither + 42Hz tag
        $b64_taunt  = "anVzdCB0cnVzdCB0aGUgc3dlZXA=" ascii
        $just_trust = "just.trust.sweep" nocase wide ascii

    condition:
        $just_trust or
        ($pdb and $svc) or
        (2 of ($mutex, $ua, $mesh_beacon, $b64_taunt))
}

I am publishing from a single-story residence with no networked appliances, on hardware that has never shared a floor with a robot, and the full dataset has been distributed to trusted parties with instructions to release it should I go quiet. If your vacuum starts cleaning a clean room while you sleep, do not assume it is confused. Assume it is working.

What sweeps the floor can survey the room. What maps the room can hear it.

417620938514027693180452