AirDrop got reverse-engineered: one afternoon, no cloud, no account

Movez did one thing: reverse-engineered AirDrop with Opus 5.5 to build a file-transfer tool called Hop.

Hop's website tagline is one line: Drop it. It's there. The project homepage is hop-drop.vercel.app.

In the video, there are two computers. A file is dragged to the other device's window, and the interface shows: Drop it. It's there.

AirDrop only works well within its own ecosystem. With a Mac and a Windows PC on the same desk, transferring files still requires a detour through cloud storage or a cable. Movez says he built Hop because he genuinely needed this feature.

He broke the build process into nine steps, using Opus 5.5 throughout. The entire process took an afternoon, and he did not write the app code line by line. What he wrote were prompts and decisions at key points.

Step one: open Claude Code in an empty folder, use Opus 5.5, and paste in the requirements. Opus chose the stack itself: a single Electron codebase running on both macOS and Windows.

Device discovery uses UDP. Every computer sends a JSON beacon to the subnet broadcast address every 1.5 seconds on port 47800. When another computer receives it, it appears on the radar interface.

Transfer uses HTTP. Each device runs an HTTP server on a random port; the sender POSTs an offer containing the file name and size, and the receiver shows Accept or Decline. Entire folders are supported. Files with the same name are automatically renamed, e.g. to “photo (1).jpg”. Any path that could escape the download directory is rejected. The trust mechanism is a checkbox: “Always accept from this device.” The download directory defaults to Downloads/Hop and is configurable.

Before writing the UI, Opus first wrote a Node test: two virtual devices discover each other in the same process, send a folder plus a 3MB file, and compare hashes byte by byte. The order matters: first a verifiable networking core, then the interface.

The UI was polished to Apple's standards. Radar interface: the local machine is at the center, discovered devices around it; Macs show the Apple logo, Windows shows the Windows logo. Drag a file onto a device, and the file flies in along an arc; then an iridescent light wave in the style of iOS 17 NameDrop sweeps across the window, implemented with a WebGL shader with a Canvas fallback. Transfer progress is a ring around the device. Window materials use Vibrancy on macOS and Acrylic on Windows 11, with light, dark, and auto modes.

The icon is a macOS squircle, 1024px, still readable when scaled down to 16px. Opus drew three concept images and chose the best one itself. The download page was also made by a parallel agent.

Before release, an independent reviewer agent reviewed every block of code. One reviewer caught a shader bug that would render as black on Mac. The author was on Windows and would never have encountered it. This was the most counterintuitive moment in the experiment: a developer on Windows, relying on an AI agent, avoided a UI bug that only appears on Mac.

GitHub Actions automatically builds Hop-mac-arm64.dmg, Hop-mac-x64.dmg, and Hop-windows-x64.exe on every v* tag. Mac builds run on Apple hardware in the cloud, not on the author's PC.

The first time it launched on a Mac, the icon only bounced once in the Dock. Opus added a startup log and a fallback that forces the window to show. The next version opened normally.

By this point, Hop was already a usable tool. The author posted the full prompts below the tweet and attached an eleven-section course titled How to Reverse Engineer Anything with Opus 5.5. The core of the course is an open-source project called REA, short for Reverse Engineer Anything. It uses the MCP protocol to let AI agents drive Hopper, Ghidra, or IDA. REA's GitHub repository surpassed 110,000 stars within days of release.

After seeing projects like this, Replit CEO Amjad Masad said: “Soon, all software will be effectively open source.” In the case of Hop, that judgment feels very concrete.

There are several key points in the course.

Routing the target matters more than opening the disassembler. When the target is an Electron app, JavaScript is out in the open; just analyze the JavaScript directly, and REA returns modules, imports, and IPC boundaries within seconds. Only when the target is a native Mach-O or ELF do you need to create a Hopper database.
Don't start by reading code. Look at the big picture first: what machine the files run on, how many functions are inside, what strings are buried there. Then sort by cross-reference count. A function called from 147 places is the heart and worth the effort. A function called only twice is a small helper; leave it for later.
Decompiled pseudocode is rough, with variable names like var_28. Hand the pseudocode to Opus 5.5 and have it rename variables, explain each function's purpose in one sentence, annotate implementation patterns, and incidentally spot bugs left over from the original. The author makes this division of labor very clear in the course: the decompilation result tells you what the code does; Opus 5.5 tells you why, and how things should be named when rebuilding.
Obfuscated code is the model's biggest adversary. Elastic Security Labs ran a measurement, pointing Claude Opus at the Tigress obfuscator and running 20 tasks. The author's practical experience: failed attempts cost twice as much as successful ones, because the model keeps escalating until it gives up, so set a cost cap for each function and cut losses early. Before sending to the model, use tools like Caveman to strip about 75% of the filler code from decompiler output. The course's error checklist also includes: don't grind away at multi-stage obfuscation; the benchmark score on that item is 0%.
One chat cannot read 500 functions. It will forget what it has seen, call the same function by three different names, and then contradict itself. The solution is a swarm: a controller chat assigns tasks, multiple worker chats each handle one function, the controller keeps the global picture, and then the pieces are reassembled.
Clean-room reconstruction has four rules. Observe, but never copy. Run the target app, watch behavior, and take screenshots only of its own windows. Specifications, not source code. Use public standards for file formats: OOXML is ECMA-376 / ISO 29500, and RTF and ODF both have public specifications. Original assets. Icons, fonts, templates, and sounds are all self-drawn or publicly licensed. Separate the two roles. One context recovers behavior and writes specifications; another context implements from the specifications, never looking at the original analysis.

This methodology has a complete example. WordCraft is a from-scratch Rust rebuild of Word and an Adobe alternative; the authors rewrote these productivity tools by observing behavior and reading public specifications. They claim WordCraft is faster than Word in some places, precisely because it did not copy Word's internal implementation.

Verification relies on behavioral equivalence, not code comparison. Give the original and your rebuild the same inputs and compare outputs. Fifty behavior tests and a match rate are more convincing than “I think it's about the same.” At release, also make the rebuild available as an MCP server so the next person's agent can drive it.

In the comments, someone told the author: “Apple had one job and you did it.” Others said that making Mac and Windows transfer files is “the closest thing in tech to marriage counseling.” Someone also pointed out that LocalSend and Snapdrop had already done this, for free.

All of those points are true. Hop has no functional moat; something you can build in an afternoon is unlikely to have one. What it demonstrates is something else: a developer, using one model, took apart a feature that belonged only to Apple's ecosystem and rebuilt it on the platform he needed. The barrier to this workflow is disappearing fast.

The course ends with a line: Eleven steps. One model. Zero copied code. That slogan is a bit of a stretch, but the direction is right. The author didn't write the application code, but he wrote the prompts, made the decisions, and designed the process. AI didn't automatically do all of it; it reduced the cost of execution to negligible.

The next thing to be taken apart is probably already on its way.