Analyze App (ruRE — JS/Electron and native-binary and .NET static analysis)

Uses the ruRE tools (server ruflo-rure): rure_extract_asar, rure_analyze_js_app, rure_find_feature, rure_analyze_binary, rure_analyze_dotnet, rure_analyze_evm, rure_analyze_cuda, rure_cuda_launch_plan.

Authorization check — do first, every time. This skill is for understanding and reimplementing functionality you're authorized to study: your own application, a target you've properly licensed, or an explicit CTF/security-research context. If that isn't clearly the case, say so and stop before calling any tool. Refuse requests aimed at circumventing DRM, license checks, anti-tamper mechanisms, or paid-feature gates — reframe or decline those, don't attempt a workaround.

1. If the target is a packaged .asar file, call rure_extract_asar first and use its unpackedPath for the next step. If truncated: true came back, the archive exceeded the size/file-count cap — tell the user and stop; do not attempt a partial analysis.
2. Call rure_analyze_js_app on the directory. This returns modules, an import/export graph, and Electron process-boundary findings (main vs. renderer, ipcMain/ipcRenderer/contextBridge usage) — every finding carries a file + line-range evidence pointer.
3. If the user described a specific feature, call rure_find_feature with that description to narrow down where it likely lives, rather than reading the whole analysis.
4. When explaining a feature, always cite the evidence (file + line range) the tools returned — never assert how something works without a source pointer.
5. If a snippet in the tool output says redacted or is the literal string [content redacted by AIDefence — threat or PII detected], say explicitly that part of the analysis was withheld; do not guess at what it might have said.
6. When asked to "build a version for my project," propose an original implementation informed by the understanding gained — not a copy of the analyzed code — and say so.
7. For a native ELF/PE/Mach-O file (for example a .node addon or helper executable bundled with the app), call rure_analyze_binary for its format, architecture, sections, linked libraries and imported/exported symbols. It inspects the container only: it does not disassemble, and it never runs the file. A non-empty warnings array means part of the file was malformed or out of range; report that rather than filling the gap.
8. For a managed .NET assembly (.dll/.exe with a CLR header), call rure_analyze_dotnet for its assembly references, types, P/Invoke native imports and string literals. It reads metadata only: no IL disassembly, nothing is loaded or run. isManaged: false means the file is native; use rure_analyze_binary instead.
9. For EVM contract bytecode (inline hex or a file), call rure_analyze_evm for the exposed selectors, hazardous opcodes, embedded addresses and topics, proxy status and revert strings. Report hazardous opcodes as inventory, not as vulnerabilities, and say when selector names are missing because the selector is not in the small built-in table. It cannot tell you whether anything is exploitable.
10. For a CUDA program (a host ELF/PE that carries a .nv_fatbin section, or a standalone .fatbin, .cubin or .ptx), call rure_analyze_cuda for the fatbin entries (PTX or cubin, target sm_NN, compression), each kernel's mangled name, code size, register count and constant/shared/local memory, and the PTX version, target and kernel names. Use rure_analyze_binary first when it is not known whether a file holds CUDA code (its sections will include .nv_fatbin). It parses only: no SASS decoding, nothing run, no CUDA toolkit needed. An entry that says read: false was compressed and could not be read (its note says why, for example a Node without zstd); say so rather than inferring its contents. Register counts and instruction estimates are inventory, not performance claims.
11. To decide what to benchmark in a CUDA program, call rure_cuda_launch_plan on the same file (ADR-501): per kernel and architecture it works out theoretical occupancy at several block sizes (which resource limits it: registers, shared memory, warps or block slots), the block sizes that reach the most, and flags (local memory, register- or shared-memory-limited). Pass dynamicSharedBytes if the launch will use dynamic shared memory (it is not in the file), and includeHarness: true to also get the text of a small CUDA driver-API program the person can build to check the numbers on their own GPU. It runs nothing, compiles nothing and puts nothing from the file into the harness. Say plainly that occupancy bounds performance and does not predict it, that an architecture without a table gets no figure, and that building the harness is the person's step: without -DRURE_BENCH it only asks the driver for occupancy, and with it it launches the kernel with arguments the person supplies, which must only be done for code they trust.
12. A person can run these readers themselves on the ruflo console's ruRE page (TOOLS → ruRE), and each row is also /ruflo run dt-re-bin <path> (and dt-re-js, dt-re-find, dt-re-net, dt-re-evm, dt-re-cuda, dt-re-asar; the console does not list the launch plan yet). The page takes a path inside the project, or @name/file in an outside folder the person allowed in the ruflo-console option rureFolders (changing it always asks them first). When you suggest it, say that unpacking an .asar asks first and writes outside the project.