I built a Wi-Fi tool whose most visible result was making someone listen to Rick Astley.
The project was called WiFi Cayote. The point was to show how easily a familiar-looking network and a login page can create a feeling of trust.
WiFi Cayote could broadcast a network name I chose, including one that matched a network I had seen before. When a device joined, it showed a captive portal, the kind of page you get at a hotel. Those pages ask you to accept terms, enter a room number, or sign in before you can go on.
In my demo, that page led to "Never Gonna Give You Up." It was a memorable way to show that joining a network can put someone else's content in front of you before you've thought about who runs it.
The setup didn't need a working internet connection to serve its local content. The Wi-Fi connection and the local page were enough. That's what made the project interesting to me: a device can join a network and see a convincing page without that network giving it access to the wider internet.
The hardware used an ESP8266, and a Linux machine hosted the larger local content. That split let the small board handle the network side while the computer served media that wouldn't fit on the board.
There's a more serious side to this. Whoever controls the page could show different content, copy a login screen, or try to get a visitor to hand over information. Public spaces are the obvious place for this, because people trust a network when its name looks right. The Rickroll was the payload I picked for the demo, but the same setup could be misused.
I also looked at connecting the setup to the Browser Exploitation Framework, or BeEF. BeEF uses a JavaScript hook that runs in a browser page to support security testing and command modules. That's a different level of experiment from showing a video. BeEF project documentation
That capability needs a precise description. Running a script in a page doesn't mean unrestricted access to someone's phone or laptop. Browser camera and location access require permission and a secure context. Capturing the rendered page is also different from capturing everything on a person's screen. Any claim about what an integration did has to be tied to the actual browser, the permissions, and the test result. Camera permissions, location permissions
WiFi Cayote combined hardware, Linux, local hosting, and browser behavior in one project. The lesson I wanted people to take away is simple: a familiar network name and a polished portal page don't tell you who's on the other end.
What the demonstration actually showed
The interesting line was between recognizing an interface and knowing who controls it. A familiar network name tells you what a device shows you. It doesn't prove the network belongs to the place or organization you think it does. A portal makes that impression stronger, because people already expect an agreement page on guest Wi-Fi.
My version made that line obvious with the Rickroll. The page and video were the content I chose to serve. That shows I controlled what got delivered locally. It doesn't mean every connected device was compromised. Joining a network, opening a portal, running page scripts, and granting device permissions are four separate events.
There was also an ordinary engineering limit behind the joke. The ESP8266 has very little storage. Splitting the work between a small Wi-Fi board and a Linux computer gave each one a job it could handle. The board ran its side of the network experience, and the computer hosted the larger media. I want to remember that alongside the security lesson.
I'd describe WiFi Cayote as a hardware-and-web experiment with one very specific visible result. The BeEF connection belongs to the wider set of things I could test. The Rickroll is what I actually demonstrated. Keeping those claims separate makes the project easier to understand. It stuck because a small set of parts could create an experience people might connect with a much larger public network.