01 / Get oriented

An ASAR is a container, not a conclusion.

Electron combines browser-based interfaces with a Node.js-powered main process. Many Electron applications package JavaScript, assets, and metadata in an app.asar archive. Reading that container is a useful first step in an investigation with REA.

REA means Reverse Engineer Anything. For an Electron target, it can help connect files, modules, APIs, and process boundaries. You can begin more simply: open the archive, understand its shape, and decide which behavior you want to explain.

Common installation layouts include a resources/app.asar path on Windows or Linux, and Contents/Resources/app.asar inside a macOS app bundle. Packaging differs by application; some apps use an unpacked directory instead.

Open a file you are authorized to examine in the browser ASAR inspector. If you do not have one handy, choose “Try an example.” The original Fieldnotes fixture contains a small, readable CSV export flow.

02 / Follow the first clue

Read the manifest before reading everything.

The root package.json may declare the application name, version, and main entry point. That entry tells you where the application’s main process is configured to begin. It does not tell you which functions execute during a particular action.

Fieldnotes / package.json
{
  "name": "fieldnotes",
  "version": "1.2.0",
  "main": "src/main.js",
  "dependencies": {
    "electron-store": "^10.0.0",
    "papaparse": "^5.4.1"
  }
}

In this fixture, src/main.js is a good starting point. A CSV-related dependency suggests a possible implementation detail worth checking. The version range is only a declaration: it does not establish which package version was installed or which code is reachable.

When metadata is missing, keep the identity or entry point marked as unknown. REA can investigate the available modules, but a convincing filename alone is not proof of an application’s architecture.

03 / Trace one feature

Renderer → preload → main.

An Electron feature can cross multiple processes. The renderer handles the interface. A preload script may expose selected operations to that interface. The main process handles privileged application tasks. IPC messages connect these pieces.

For the Fieldnotes example, follow the “Export notes” button. The renderer invokes the exposed API, the preload forwards an IPC request, and a main-process handler creates the CSV.

The three links in the chain
// renderer.js — a user action
const path = await window.notes.exportCsv(notes);

// preload.js — a bridge between processes
contextBridge.exposeInMainWorld("notes", {
  exportCsv: (notes) => ipcRenderer.invoke("notes:export", notes)
});

// main.js — the matching handler
ipcMain.handle("notes:export", async (_event, notes) => {
  const destination = join(app.getPath("downloads"), "notes.csv");
  writeFileSync(destination, toCsv(notes), "utf8");
  return destination;
});

This gives REA a narrow question: where does notes:export go, and what reaches the file writer? Ask for the matching paths and code, not just a prose summary. The inspector itself lists and previews files; it does not automatically verify this IPC relationship.

04 / Investigate, then check

A useful explanation comes with evidence.

After connecting your agent to REA, provide the local archive path and the behavior you want to trace. The browser cannot know the absolute location of a selected file, so replace any path placeholder yourself.

A focused REA task
Use REA to trace the CSV export in <ABSOLUTE_PATH_TO_APP.ASAR>.
Start with the declared main entry and the preload bridge.
Find the renderer call, IPC channel, and corresponding handler.
Show file paths and the code that formats and writes the CSV.
Explain how an embedded quote in a note is handled.
List anything that static analysis cannot establish.

Next, choose a small input that tests the explanation. For CSV, a note containing a comma, a quote, or a newline can reveal whether the escaping behavior matches your interpretation. Inspecting the original application’s behavior is a separate step from reading its code.

The Reverse Engineer Anything workflow becomes more useful when each new question follows a finding: identify a handler, inspect its formatter, then test a specific output. Avoid assuming that an AI-generated reconstruction already matches the original.

05 / Keep your bearings

Some clues point beyond the archive.

Source maps

A .map file may connect bundled JavaScript to earlier source. It might include source content, only reference paths, or be unrelated to the feature you are studying. The inspector reports candidates by filename; open a candidate before relying on it.

Native modules

A .node file is a native add-on candidate. Understanding its compiled implementation may require a provider such as Ghidra, Hopper, or IDA through REA. JavaScript inspection alone does not recover that implementation.

Unpacked files and remote services

An ASAR header can reference files stored in an adjacent .asar.unpacked folder. Those bytes are not in the selected archive. A network call similarly does not reveal the server’s implementation. “Reverse engineer anything” does not mean every missing component can be recovered from a client package.

Keep observations and assumptions separate.

Record which file supports a claim, what a runtime check confirmed, and what is still unknown. That habit makes a REA investigation easier to revisit, share, and verify.

Sources: Electron ASAR format, official REA JavaScript guide, and the original Fieldnotes fixture included with this workbench. Reviewed October 12, 2026.

Bring your own curiosity

Try it on a small example.

Our original Fieldnotes archive gives you an entry point, a preload bridge, and a CSV export to investigate.

Explore the example