The BLEShark Nano is now a scriptable RF platform

irm https://cdn.infishark.com/install.ps1 | iex

curl -fsSL https://cdn.infishark.com/install.sh | sh

Wireless pentesting tools always had their issues. When we launched the BLEShark Nano, our goal was simple: make it easier to get into wireless cybersecurity without a shelf of adapters and a weekend of driver hell. We stand by that goal. But we can not pretend the device was flawless.

It is closed-source. You are locked to the handful of tools we ship, and some of you have called some of those tools what they are -- "party tricks". And some of you said, plainly, "learning airmon-ng with an ALFA adapter is the better way to learn!"

And we do not disagree. Most of the tools on the device are nice PoCs. Run them a few times and the ceiling shows up fast: you are stuck with whatever features, fixes, and updates we decide to post. For something you want to use as a real pentesting tool, that is not how it should work. The worst part is the one you can not engineer around. It is closed-source, so you can not run what you want to run.

That is problem #1. There are two more.

The second is that the "just use a laptop and an ALFA card" answer is not as clean as it sounds. Sit down to run a single PoC and you are already making decisions:

1. Which adapter (Wi-Fi or Bluetooth) to get? An ALFA AWUS036ACS? A TP-Link AC1300? A UGREEN Bluetooth adapter? Does it do monitor and injection mode? Will it work without proprietary drivers? Can I script against it without fighting it?
2. Which tool do I need to learn for this one PoC?
3. Which libraries do I have to install before it even runs?
4. And how was I supposed to know which PoC to run in the first place?

Every tool in this space has its own workflow, flags, and its own quirks. Even when you understand a PoC inside and out, there is a barrier between you and actually running it. This reduces the number of PoCs run relative to the number of PoCs learned. This barrier is the thing we wanted to kill.

The third problem is ours: compute. The Nano runs on 400KB of SRAM, a 160MHz clock, and 128KB of persistent storage partitioned out of 4MB of flash. That is enough to be a great edge radio. It is nowhere near enough to run a full automated pentest on-device. You want to capture a handshake and throw rockyou.txt at it? A microcontroller is never going to do that. Real-time Wireshark off the airspace around you? BLE MITM? All of it wants compute the device simply does not have.

And there are the smaller papercuts too - the tiny screen, the three-button interface, and more.

So here is what we did about it.

Introducing the InfiShark SDK

We did not try to cram a desktop's worth of compute into a microcontroller. We did the opposite. The Nano stays the edge radio. Your computer does the processing. Plug the Nano in over USB-C and it starts talking to your host. This is fully open-source, Rust-based, fast, and scriptable end to end.

That one architectural decision is what unlocks everything below. Every "impossible" from the compute section is not solved by making the chip bigger. It is solved by moving the heavy lifting to where it belonged all along. The Nano does not aim to replace a computer; it aims to work alongside it.

Capture a WPA handshake - PMKID and full 4-way EAPOL - straight to pcap and hashcat 22000 format, then hand it off to hashcat on your machine with a single --crack flag. Stream a promiscuous 802.11 monitor feed live into Wireshark. Inject raw frames. Run the Nano as a real Wi-Fi adapter on Linux over a SLIP tunnel, so it joins a network and your host gets an actual interface. Deauth with a CLI workflow that does not feel like a toy. Scan with OUI vendor enrichment done host-side.

This is not a walled garden of preset buttons. Primitives compose. The output of one thing pipes into the next, and JSON comes out everywhere so you can automate around it.

And this is the CLI. We have programming libraries for Rust, so you can create your own applications easily. More language compatibility -- like Python, C, and Go -- are in the works, so you don't have to learn a proprietary language just to create something.

Captive portals that are not trapped in 30KB of SPIFFS

Stand up a SoftAP with the SSID, channel, open-or-WPA2 setup, hidden flag, client cap, and MAC you choose - including random locally-administered MACs. Then stream a full multi-file HTML directory from your computer over USB as phones request pages. No more squeezing a portal into a few kilobytes of on-device flash. And you see the traffic with User-Agent, headers, client IP, station MAC and RSSI, SoftAP identity. The device is the radio. Your portal content lives on the host, where it belongs.

Bluetooth LE you can actually script

Scan, enumerate GATT, read and write characteristics, subscribe to notifications. Advertise custom payloads and serve your own GATT table. Emulate HID keyboards, mice, and gamepads - or bridge real inputs from your host over BLE and control a second machine through the Nano. You can even clone a raw HID device. This is the surface that was flatly impossible on-device before.

And the unglamorous glue that makes research possible

IR receive and transmit with raw timings, TV-B-Gone, and .ir files you push into on-device remote slots. File push and pull for captures, portals, scripts, and remotes. JSON on every command so none of this is a dead end when you want to script it. Not exciting to write about, but essential.

This is the start of the platform, not the end of it

Shipping the SDK is step one. Here is where it goes.

A community app ecosystem. A coming apps command lets you browse a catalog, install, and run tools other people built - automations, analyzers, defensive PoCs, packaged demos - right from the CLI, with authors, versions, and stars. It will be a curated catalog, not an anything-goes dump. Tools are categorized & reviewed, with the emphasis on research and offensive / defensive work.

BLE and Wi-Fi MITM. And no, not just to "snoop traffic". BLE MITM lets you sit between an app and its device and reverse-engineer proprietary protocols on the fly - see what a vendor's app actually says to its hardware. There is a lot here, and a lot more coming.

Multi-device human detection over CSI. Using Shiver, place nodes across an area, let them talk to each other, and detect human presence and movement between them.

Campaign-style orchestration across one Nano or a whole Shiver fleet, driven from the CLI.

Multi-radio / HCI setups - a host Bluetooth adapter where full HCI is required, the Nano handling Wi-Fi and IR, and the CLI conducting all of it.

A research toolkit for known protocol weaknesses. Pixie Dust, WPA2-downgrade handshake capture, KRACK, the BLESA CVE, the Airoha RACE toolkit, and more.

A tool that oversells itself is worthless - so we must be straight on the limitations here. The Nano is BLE-only, so anything that speaks L2CAP instead of GATT will not show up. There is no promiscuous mode with raw LL / PDU manipulation - on the BLE side you are doing app-layer and vendor-implementation work, not link-layer protocol exploits. And the radio is 2.4GHz-only; 5GHz is out of reach on this hardware. We have upgrades in the works for some of that.

But the thing doing all of this still costs $49.99. That was the whole point.

v1.1.0 also brings BLE-device and Wi-Fi-AP proximity detection via RSSI, an "airhorn" app that pings every AirTag near you (there is a reference app in the SDK showing exactly how it works - go read it), and a pile of quality-of-life fixes.