DEV Community: shan han

REA Claims It Can "Reverse-Engineer Anything" — and Pulled 120K Stars in a Week. So I Handed It My Own App

shan han — Wed, 14 Oct 2026 23:14:03 +0000

An open-source project that had been silent for six months suddenly exploded on GitHub last week: +116,561 stars in seven days, peaking at +40,307 in a single day. Total stars crossed 187K tonight. It claims an "Agent that reverse-engineers everything." I didn't buy it — so I handed over the installer of my own app: no source code, no documentation, not a single comment. It dug out the rendering pipeline I'd hidden deepest of all.

Author: an indie developer ｜ Target: my own app (FluxMark for macOS v1.3.5) ｜ Reading time: ~9 minutes

The verdict up front: REA takes your code — but code was never the moat.
Still, it forces every developer to answer a question: if your app were perfectly cloned tomorrow, what would you have left?

01 | 120K Stars in a Week — How Big Is That, Really?

These past two days, a project called REA (Reverse Engineer Anything) has been tearing up GitHub. The repo description is one line: "Use agents to reverse-engineer everything, from app behavior all the way down to native binaries."

It didn't come out of nowhere — the repo was created in April and then went quiet for six months. The explosion happened in early October: on October 4 it hit Trending for the first time with +1,373 stars that day; then it compounded — +19,375 on October 9, and on October 11 a single-day peak of +40,307. Day-by-day measurements from GitHub star history show that from October 5–11 it accumulated 116,561 new stars in seven days (+4388% week over week). As of tonight, total stars stand at 187,499 (measured via the GitHub API; 35K–45K forks), still climbing at a visible pace.

For perspective: the phenomenon-level project that kicked off the year's AI-coding craze took three days to accumulate 60K stars at its own explosive debut — REA gained 40K in a single day. The daily numbers look like this:

REA daily new stars (measured from GitHub star history via GitNova, UTC; Oct 12 is a partial count as of 10:57 that day)

Why would a reverse-engineering tool go more viral than a "shrimp-farming" repo? Because it hits an itch every developer has:

"That app's feature is brilliant, shame there's no source code…" — that excuse just stopped being valid.

02 | What Is REA, Actually?

Let's be clear about one thing first: REA is not a magic black box where you drop in an APK and source code falls out. It's an open-source TypeScript tool (MIT license, npm package rea-agents), and what it does is remarkably restrained — it builds a scheduling bridge between your AI coding assistant and a fleet of battle-tested reverse-engineering tools.

Ghidra (NSA open source), Hopper, IDA — these disassembly powerhouses have been evolving for decades, but their learning curve scares off 99% of app developers: you have to chew through APIs, read assembly, and manually chase call chains through piles of strings and symbols. REA hands all of that grunt work to an agent — Claude Code, Cursor, Codex, Gemini CLI all work. After setup, all you say is:

Understand how search works in the Notes app,
show me the evidence, and build a similar feature for my project.

What happens next is the pipeline below — the agent does the thinking and verification; REA reaches into the binary:

Your agent → REA (MCP) → reverse-engineering engines → evidence flows back → shipped implementation. Runs entirely locally.

The range of things it can dissect is bigger than you'd think:

Target	What REA returns
Native binaries (Mach-O / ELF / PE)	Pseudocode, assembly, strings, symbols, call chains
IPA / APK / macOS .app	Bundle manifest, plist, resource dissection, decompiled methods
Electron / JS apps	Modules, entry points, IPC channels, source maps (no execution needed)
.NET assemblies	Metadata, CIL instructions (fully static)
Websites	Page structure, scripts, network observation (passively, in your own browser)
SQLite / firmware / Flutter	Table schemas / partition extraction / Dart snapshot fingerprints
Version diffs	Change reports between two builds

🧠 First, a quick reality check: why binaries can never be "reversed" back to source. At compile time, your variable names, comments, type annotations, and code structure are all thrown away — Swift/C++ gets translated into machine instructions the CPU executes directly. It's like baking a cake: nobody can un-bake a cake back into eggs. So for native binaries (Mach-O/ELF/PE), REA doesn't pretend to "recover source." What it hands over is pseudocode, assembly, symbol tables, and call chains: class names, method names, and function boundaries survive (unless deliberately obfuscated), which is more than enough for an agent to understand what a program does and how — exactly the raw material used to dissect FluxMark below. For true source-level recovery, you'd target Electron/.NET apps, which carry their own metadata.

💰 The math others have already run (from public experiments): a senior security researcher used Cursor + Claude to reverse a batch of apps: most tasks finished in about 30 minutes for under $5; the most token-hungry job — a Unity game — burned 40M tokens, roughly $27. Averaged out: around $30 a job. His own takeaway: "I am the AI's bottleneck."

03 | Hands-On: I Handed Over My Own App's "Corpse"

Talk is cheap — let's dissect something. For compliance reasons (and for maximum drama), the target was my own app: FluxMark for macOS — a Markdown multi-platform publishing tool. I wrote every line of it. I know every line of it.

I threw its DMG image straight at REA — mount, dissect, reconstruct, zero source code provided at any point. Now walk through it from the agent's perspective, and watch how it "sees" a product from a pile of zeros and ones:

From archive to product profile: not a single step needs source code, and nothing gets uploaded anywhere.

🥩 Cut 1: Bundle Anatomy — the Architecture Gives Itself Away

Before touching the binary at all, the agent produced its first report from the bundle manifest alone:

FluxMark.app — 62 files · arm64 · macOS 14.6+ · v1.3.5

Executable     FluxMark            4.3 MB Mach-O
JS engines ×13 codemirror.js · markdown.js · marked.min.js
               mermaid.min.js · tex-svg-full.min.js (KaTeX)
               highlight.min.js · js-yaml+esm.js · front-matter …
Styles ×33     gzh_default.css · zhihu_default.css · juejin_default.css
               csdn_default.css · toutiao_default.css · medium_default.css
               github_default.css + 20+ style themes …
Platform icons platform-medium.png · platform-devto.png
               platform-hashnode.png · platform-ghost.png

See the problem? Before decompiling a single function, the product's core secret was already written in the filenames. gzh_default.css — "gzh" as in GongZhong-hao, WeChat Official Accounts default style; a pile of platform-*.png — Medium, Dev.to, Hashnode, Ghost. The agent inferred: this is a tool that converts Markdown into platform-ready articles with one click.

My first reaction was a smirk: cute. Filenames. You haven't seen anything yet.

🍖 Cut 2: The Symbol Table — 20 Classes Line Up to Introduce Themselves

Then it cut into that 4.3 MB Mach-O. Swift doesn't obfuscate class names by default, so the symbol table is a signed confession:

— Views —
DocumentEditorView      PreviewPaneView        WorkspaceDetailView
MarkdownEditorView      FolderTreeNodeView     DocumentRowView

— WebView bridge —
FluxMarkAssetSchemeHandler   ← WKURLSchemeHandler, custom resource loading
PlatformHTMLWebView          GuideHTMLWebView
LegalDocumentWebView         WKScriptMessageHandler

— Rendering & export pipeline —
CopyRenderSession   PreviewPDFRenderSession   PreviewImageRenderSession
PDFExporter · SplitGroupExporter · PreviewExporter · DocumentExportService

— Content capture —
WebCaptureSession   CameraCaptureView    ImageUploadService
ImageHostingGuideView   AnnotationStore   PasteEnabledMarkdownTextView

— Desktop-only (nails down its macOS identity) —
PenOverlayNSView    ← AppKit view, annotation ink layer
MarkdownEditorController    LegalWebViewCoordinator

This is where I started feeling uneasy. FluxMarkAssetSchemeHandler is the custom protocol handler I wrote to work around WKWebView's local-resource security restrictions — a solution that took me two full days of research to get right. It recognized instantly that it was a WKURLSchemeHandler, and correctly inferred the hybrid architecture: Swift native shell, WebView rendering layer, two-way communication over a script bridge. Worse: PenOverlayNSView — a single AppKit view class name — pinned down the app's identity as a macOS desktop app.

🔥 Cut 3: Behavior Reconstruction — Even the "Render Session" Surfaced

The cruelest cut was the third. Following strings inside the symbols, the agent dug out my most deeply guarded mechanism — the copy-render pipeline — in its entirety:

// Export capability matrix (from strings in the binary)
export.as_markdown        export.as_textbundle
export.copy.html          export.copy.markdown
export.copy.richtext      export.section.copy_platform
export.section.export_to

// Content capture entry points
capture.source.blank      new blank document
capture.source.clipboard  from clipboard
capture.source.ocr        OCR recognition ← even this was found
capture.source.web        import from web

// Error fallbacks (revealed that rendering runs in a separate session)
copy.process.crashed      copy render process exited abnormally
previewRenderTimeout      previewRenderFailed

That copy.process.crashed error string exposed an architectural decision: copy rendering runs in an isolated session, so a crash there can never take down the main process. It was a trade-off I made after chasing countless WebView render timeouts. It was documented nowhere. The agent inferred process-isolation design from a single error message.

Then it handed over this reconstruction:

Swift native shell ⇅ two-way script bridge ⇅ WKWebView rendering layer — every conclusion from static analysis only.

It never saw one second of my source code, yet it drew a clearer picture of my architecture than the one in my own memory.

😱 How it actually felt as the author: not anger — a chill down my spine. The three technical decisions I was proudest of — the SchemeHandler resource loading, the isolated render session, the multi-platform theme system — all exposed without a single line of disassembly. If the target had been a competitor's app instead of mine, I'd have had a "here's how to do it better" list in about 3 minutes. The barrier to entry for reverse engineering just dropped from "years of hard graft" to "one prompt."

04 | So Is My App "Naked" Now?

Having seen the architecture diagram, you might be thinking: it's over, the app is done, the closed-source moat is bankrupt. That's certainly the take sweeping the internet: "subscription software deserves to die," "if this really works, nothing is proprietary anymore."

But calm down, because two facts are worth laying out:

First, open-source software has been "naked" for decades — and the business model still stands. Anyone can download Red Hat's code, and customers still pay for subscriptions — for production-grade support, lifecycle management, compatibility, and expertise. If "source available = business dead," open source would have ceased to exist long ago.

Second, REA can reconstruct the code. It cannot reconstruct the "why." It knows I use an isolated render session, but not how many WebView-timeout bugs drove me there. It knows I ship 33 CSS themes, but not that each one's spacing and font weights were tuned pixel-by-pixel against the real WeChat publishing backend. Between having the code and building a good product lies the entire history of pitfalls — every bug hit, every fix earned. There's a sharp saying in the industry: clones take the code, not the knowledge.

🧱 The moat didn't disappear — it moved. From "you can't see my code" to three new locations:

① Iteration speed: the clone is today's version; you're already building next month's.
② Business understanding: why this button sits here, why that error message reads that way — AI only sees the "what."
③ Trust and service: users follow your changelog, your community, you.

05 | Three Things I'd Tell Every Indie Developer

① Point REA at yourself — it's the cheapest security audit you'll ever run. This exercise was a free "leak-surface check": symbols fully exposed, error strings leaking architecture, resources readable in plain text. Next steps for me: symbol obfuscation on core modules, splitting and encoding sensitive strings. Not to stop everyone — to raise "seen through in 3 minutes" to "not fully mapped in 3 days."

② Rather than fighting clones, outrun them. Small teams used to fear big companies copying them; now big companies fear one person + AI. For indie developers, REA is actually a weapon: you can openly study how great products are designed (not to steal code — to understand design intent) and turn it into insight for your own product.

③ Don't forget the red line. Reverse-engineering software you own or are licensed to use is learning. Reverse-engineering someone else's commercial software to clone and distribute it is infringement. The technology has flattened the technical barrier — the legal and ethical ones are still standing. Where that line sits is something each of us has to hold ourselves.

When code is no longer a secret, the only secret left worth keeping is how well you understand your users.


3 min	from installer to architecture diagram
$0	extra cost of this dissection (ran locally)
0 lines	of source code provided

About this post: REA repo: github.com/morluto/rea (MIT)

⚠️ Disclaimer: This article demonstrates reverse engineering solely on software I own, for educational purposes. Do not apply these methods to software you're not authorized to analyze. Respect intellectual property and applicable law.

I haven't opened VS Code in 6 months — here’s what happened when AI took over my workflow

shan han — Thu, 01 Oct 2026 04:57:23 +0000

Author: Shan (HanShan) | Reflections after 20+ years of software engineering on transitioning from "typing code in an editor" to "driving development through AI dialogs."

The Icon I Rarely Click Anymore

Looking at my desktop dock, I can barely remember the last time I clicked on the VS Code icon. It stays there mostly out of habit and nostalgia.

Now, whenever I need to change something, my first instinct isn't opening a file—it's opening a chat prompt.

This is what my workspace looks like every day. Over the past six months, I shipped three complete projects, fixed hundreds of bugs, and completely refactored a backend service suite. Not a single line of that code was typed out by hand in VS Code.

If someone had told me six months ago: "As a career programmer with over two decades of coding experience, you won't even bother opening your editor for half a year," I would have thought they were out of their mind.

Yet here we are: VS Code has virtually vanished from my daily workflow.

Even though VS Code has plenty of great AI plugins, I eventually said goodbye to it because native AI IDEs and agents handle context, agentic workflows, and tool execution significantly better.

Today, I want to unpack this half-year journey honestly: What actually happens to our development workflow when AI takes over writing code? And where does our core value as developers actually go?

Phase 1: The First 2 Weeks — Fingers on Autopilot, Mind Lagging Behind

The hardest part at the beginning was the cognitive dissonance.

When I first stopped using my traditional editor, my muscle memory kept betraying me.

I’d want to rename a variable, and my fingers would automatically press Cmd + P before I remembered there were no files to search. I’d want to inspect a utility function, switch over to an empty workspace, and freeze. Once, while adjusting CSS padding, I stared blankly at the screen for 10 minutes because "tweaking a pixel" had meant Open file → Search class → Edit value for twenty years—now I had to describe it in plain language.

I genuinely wondered if I was losing my edge.

Then it hit me: The discomfort wasn't from a lack of tools; it was from having my mental model ripped away.

For decades, developers operated under a File-Centric View.

You carried a file tree in your head: which component lived in components, which API endpoint was in api, how state trickled down, where an enum was defined vs. consumed. When a bug popped up, you set breakpoints, sprinkled console.log statements, and climbed up the call stack.

Switching completely to Agentic workflows, MCP (Model Context Protocol), and terminal-native AI tools inverted this entire model into a Task & System View.

I no longer care which exact line a function lives on. I only provide three things: System Boundaries, Data Structure Definitions, and Expected Inputs/Outputs. The rest is the Agent's job—indexing the codebase, creating branches, editing files, running tests, and telling me: "Done. Ready to merge?"

It felt strange at first. Handing over the keyboard meant handing over the map—the mental map of my codebase.

	File-Centric View	Task & System View
Starting Point	Create a new project file	Write a detailed Specification
Mental Load	Directory trees, file paths, naming conventions	Module boundaries, data flow, failure modes
Debugging	Breakpoints, logging, stepping through stack traces	Describe the symptom → AI investigates logs & repos
Deliverable	A snippet of code	A verified change + Git diff
Developer Role	Producer (Typist + Craftsman)	Approver (Architect + Reviewer)
Amplified Skill	Typing speed, path memory, debugging patience	System definition, judgment, critical inquiry

After a month, I accepted a humbling truth:

70% of our time in the past wasn't spent "thinking about systems"—it was spent acting as human code converters.

Translating comments into syntax, design mocks into functions, or refactoring three legacy files into a new API—this boilerplate consumption dominated our daily lives. It gave us a sense of "productivity," but it wasn't where real engineering lived.

Phase 2: Six Months In — My New Development Stack

Once the adjustment period passed, three main pillars replaced my old editor-centric workflow:

Pillar 1: Writing Specifications Instead of Writing Code

Development no longer starts with touch index.ts; it starts with an extremely explicit specification document.

The clearer my definitions for module boundaries and data flow are, the sturdier the generated architecture becomes. Ambiguity in specs directly translates to exponential rework.

My pre-implementation spec template looks like this:

Goal

In one sentence: What problem does this module solve, and what is explicitly OUT of scope?

Boundaries

Input: Fields / Types / Caller
Output: Fields / Types / Return behavior on failure
Out of scope: Explicitly list 3 things this module does NOT handle.

Data Structures

Strictly defined via TypeScript interfaces/types. Types are contracts.

Failure Paths

List at least 3: Null inputs / Upstream timeouts / Invalid data formats, and expected behaviors for each.

Acceptance Criteria

Include runnable edge-case test suites.

When the specification is complete, generating the code becomes a deterministic execution rather than a creative gamble.

Pillar 2: Context Attachment via MCP (Model Context Protocol)

Specifications define what I say; MCP defines what the AI can access.

Debugging used to mean sifting through logs, SSHing into servers, querying DBs, and comparing environment variables manually.

Using MCP, I connect the AI directly to my local database, API inspection tools, and Git repositories. The AI evolves from a "conversational chatbot reading pasted code" into an agent equipped with real tools.

A typical investigation now looks like this:

Me: Describe the issue.

AI: Checks logs, inspects codebase, traces logic, checks commit history, edits code, compiles, and runs tests.

Me: Inspect the diff, verify test results, merge.

Going from "spend hours investigating" to "spend 30 seconds reviewing" comes down to whether you embrace this paradigm shift.

Pillar 3: Automated Verification — Tests Are the Main Character

Without unit tests as a safety net, AI-generated code is a ticking time bomb.

Over the past six months, I've seen AI "working" code fail in production: an API that passed basic checks corrupted user records under concurrent requests, and a "cleaner" refactored module accidentally stripped out fallback logic for empty arrays.

AI excels at generating quickly, not anticipating comprehensively.

My job shifted to designing edge-case test suites, then handing them to the AI to iterate on until every test turns green:

Nulls & Zeroes: null, undefined, 0, empty arrays/objects.
Boundaries: First page, last page, max length limits, long strings.
Concurrency: Simultaneous mutations on identical records, duplicate submissions.
Failure Branches: Upstream 500 errors, timeouts, malformed payloads.
Formatting: Date boundaries (month-end, leap years, time zones), floating-point precision.
State Integrity: Duplicate calls, external state mutations mid-execution.

Phase 3: The Reality Check — What Didn't Go Smoothly

Moving completely away from editors isn't a silver bullet. If you plan to adopt this workflow, watch out for these traps:

Pitfall 1: Hidden Architectural Rot

AI favors local optima. Architecture requires global constraints. Left unchecked, AI will reinvent wheels across files—three different HTTP wrappers, duplicate helper logic, or conflicting constants.

My fix: Put architectural rules in a project convention file (CLAUDE.md / RULES.md).

All HTTP calls MUST go through src/lib/api. No custom wrappers.

Logging MUST use MLog. System console.log is strictly prohibited.

New modules MUST declare dependencies before implementation.

Pitfall 2: Hallucinated Dependencies & Security Risks

AI will happily introduce deprecated or insecure packages that sound plausible, or call outdated APIs that pass compilation but fail at runtime.

My fix: Never let AI decide dependencies autonomously.

AI must provide registry links and version numbers for any new package.

Enforce CI dependency audits (vulnerabilities & deprecation checks).

Personally review security-sensitive code (Auth, Crypto, File I/O) line by line.

Pitfall 3: Context Drift in Long Sessions

In short sessions, AI is obedient. In 2-hour multi-turn conversations, it starts drifting—forgetting constraints set in turn 3 or refactoring code to match its own preferences.

My fix: Keep sessions short and modular. One task per session. Re-state key constraints at the start of a prompt, and reset the context as soon as the agent strays.

Pitfall 4: Code Review Costs Skyrocket

When an AI modifies 1,000 lines in seconds, how much can you actually review?

If you can't review it, you are blindly accepting it. Review test coverage first, inspect deleted logic second, and review new lines last.

Final Thoughts

AI hasn't eliminated programmers, but it has made purely mechanical coding obsolete.

Your value as an architect, your understanding of underlying protocols, and your ability to anticipate system failures matter more than ever before.

How long has it been since you last opened your code editor? Feel free to share your current workflow in the comments!