How to protect your app's IP from REA-type reverse-engineering tools

Reverse-engineering just went mainstream. Tools like REA (the #1 trending repo on GitHub) let anyone point an AI agent at your shipped app and rebuild any feature — no source code, one command. Your product is now "code on someone else's disk," and competitors can study it in an afternoon.

So here's the practical playbook for protecting your IP — what actually works, ordered by how much it buys you.

First, the ground rule

You cannot make client-side code unbreakable. If a machine runs it, the machine has it, so it can always be extracted with enough effort. Anyone selling "unbreakable" is lying. The realistic, achievable goal is to defeat automated reverse engineering (the REA-class attack that just became trivial) and raise a human's cost from minutes to days.

With that honest framing, here's how.

1. Move your real secrets server-side (the biggest lever)

The only code that truly can't be reverse-engineered is code you don't ship. Put your crown jewels — licensing, pricing math, proprietary algorithms — behind an API. The client calls it; the logic stays on your server. REA can only reconstruct what's in the artifact, so this takes your IP off the board entirely.Everything below is for what you must ship.

2. Strip your source maps

If you ship .map files or a sourceMappingURL, you didn't get reverse- engineered — you published your source. Remove them from production builds.This is free and it's the single most common leak.

3. Turn static facts into runtime facts

This is the key insight: REA-type tools are static. They don't run your app, and they leave anything computed at runtime marked unresolved — they refuse to guess. Weaponize that:

• Replace direct calls with a runtime-computed dispatch table.
• Replace static import/require with computed dynamic imports.
• Assemble route and IPC channel names at runtime instead of as string literals.

You're not hiding the code — you're making the facts the agent needs not exist statically.

4. Ship bytecode or WASM for hot logic

• V8 bytecode (bytenode) puts compiled bytecode in your app.asar instead of readable JS.
• WebAssembly moves numeric/algorithmic hot-paths off the JS graph entirely.

Neither is unbreakable (both can be disassembled), but both move the work into a different, much harder league than reading your bundle.

5. Obfuscate — but know it's the weakest layer

javascript-obfuscator (JS) and PyArmor (Python) mangle names and encrypt strings. Do it — but understand it's the first layer to fall. I ran webcrack (an open-source deobfuscator) on a fully obfuscated build and it stripped everything in 1103 automatic changes. Obfuscation is paint, not armor. It only matters as a cost-adder on top of 1–4.

6. Electron: lock the runtime down

• Ship bytecode in the asar (step 4), not readable JS.
• Set defensive fuses (@electron/fuses): disable RunAsNode, Node CLI inspect args and NODE_OPTIONS; enable embedded ASAR integrity validation and OnlyLoadAppFromAsar.
• Rewrite literal IPC channel names into runtime-computed ones (REA leaves computed channels unresolved).

7. Measure it — don't guess

The mistake everyone makes is assuming their hardening worked. Point the actual attacker at your before/after build and see what it still recovers. If a protected name or secret still shows up, your hardening didn't land.

Doing all of this in one command

I packaged steps 1–7 into an open-source tool, REAShield, so you don't wire each one by
hand — and crucially, it ships a harness that runs the real REA against your build and scores what it recovers.

npm i -D reashield
npx reashield build        # relocation + sealing + WASM + computed dispatch + decoys
npx reashield test --rea   # runs REA on before/after; reports what it recovered

On the example, REA recovered 6 protected tokens → 0 after hardening, and webcrack recovered 0 even after fully deobfuscating the client. (Python front-end: pip install reashield.) Disclosure: I'm the author — linking it because it automates this exact checklist, but every step above stands on its own whether or not you use it.

The one-line summary

You can't make shipped code unbreakable — so move what matters off-device, make the rest runtime-computed, and measure it against the real tool. That turns a 10-minute automated job into days of specialist work, which for almost every product is the difference that matters.