re-analyze

Reverse Engineering Analysis Entry Point

Step Zero: Input Type Determination and Environment Probing

Input Type → probe determination：

Input Type	probe
File/sample (executable, firmware, archive, document, APK, etc.)	Required
Binary/firmware analysis request (target is on disk)	Required
Phenomenon description / no sample ("some program doesn't touch disk", "abnormal behavior", target is running)	Required (on-site collection requires tools and environment probing)
Code snippet (C/assembly/pseudocode pasted directly by the user)	Skip
Decompilation screenshot/disassembly text (no file to analyze)	Skip
Protocol description/logic Q&A (no binary target)	Skip

• When probe is required: run references/probe.sh(or manually execute the equivalent command on this machine), record:
  • RE_OS / RE_ARCH / RE_CORES / RE_MEM_GB(probing failed → ask the user)
  • RE_TOOLS: HAVE list (installed, use preferentially) and MISS list (not installed,do not interrupt the workflow, the skills used will guide installation)
  • Refer to the experience of this platform's branch in [[platform-tips]]
• When probe is skipped: no OS/ARCH/MEM requirements——RE_OS/RE_ARCH/RE_CORES/RE_MEM_GB/RE_TOOLS set unknown, ask on demand when subsequent steps/skills use them, does not block the entry point

Step One: Preference Inquiry (Tiered)

Handle according to references/preferences.md tiering rules (do not ask item by item by default）：

• Level 0 Quick Entry (default): goal is preliminary analysis or unclear → directly use default values (goal=preliminary analysis, Ghidra, standard, report wanted, platform auto), proceed to Step Two
• Level 1 Deep Task: goal clearly belongs to a deep task (unpacking / vulnerability / protocol reverse engineering / deep malware analysis / cracking / forensics, etc.) or the user actively requests it → fully inquire about 5 items:
  1. Analysis goal(must answer, first item) —— if unclear, follow up
  2. Decompiler: Ghidra (default) / IDA / radare2
  3. Depth: quick conclusion / standard analysis / deep report
  4. Report: wanted / not wanted
  5. Platform confirmation: automatic / manual

Store the results in session variables (RE_GOAL、RE_DECOMPILER、RE_DEPTH、RE_REPORT、RE_TARGET_PLATFORM), valid throughout this analysis, read by the invoked skills.

Security Bottom Line: if the goal involves running a sample → remind about the default sandbox principle (see the highest principle in [[platform-tips]]).

Step Two: Task Identification

Identify the target first: when unsure whichsystemthe target belongs to, first go through [[system-fingerprints]]——Step 0 is evidence attribution(which objects are in the container, their respective scopes, which one is the subject;A cross-scope hit only records existence; then go through carrier and format → superfamily convergence → intra-family identification → confusable pairs → negative criteria. In many cases, the ELF's EI_OSABI and the note section can settle it in one step; if there is no container image, look for magic numbers and signature strings; if there is a config file,the config format itself is strong evidence。

If you cannot determine it, do not force a determination: having the family settled and the system unsettled is better than guessing a system and then having the entire analysis chain go off track; in this case, proceed along the family-level branch first.

According to the references/triage.md decision table, map RE_GOAL + input file to an orchestration path. Composite targets are chained across multiple major categories in dependency order.

First determine the authorization context: determine RE_AUTH(owned / ctf / research / unknown) according to step 0 of triage — sensitive paths such as patching/bypassing/dynamic execution are constrained by it (consistent with the authorization boundary of [[re-cracking]]).

Step 3: Routing engine (state machine)

A skill is not a call chain; it is astate transition: each skill produces new evidence after execution, and the evidence drives the next hop.

triage → route → skill execution → evidence → route（循环）

Call the corresponding major-category gateway skill ([[re-binary-core]] [[re-malware]] [[re-firmware]] [[re-protocol]] [[re-mobile]] [[re-anti-analysis]] [[re-cracking]] [[re-vuln]] [[re-ctf]] [[re-managed]] [[re-forensics]]); the gateway internally selects the atomic skills.

Route State (loop protection)：

• visited: already entered skill list (session variable RE_VISITED）
• max revisit：1
• Rule: entering the same skill a second time must carrynew evidence(the evidence increment relative to the previous entry — new strings/new behavior/new structural features); re-entry is prohibited without new evidence; return to the current skill's alternative branch or converge according to the [[rerouting]] B table (to prevent binary-core ↔ crypto ↔ anti-analysis loops)

Dual-track rerouting (mandatory, see [[rerouting]])：

• Track 1 (mandatory check after gateway completion): after each gateway is completed, check the new evidence against the A/B tables of [[rerouting]]; on a hit → call the corresponding skill, and after completion return to Track 1 to continue
• Track 2 (check as soon as evidence appears): each time a new type of evidence is produced during analysis (string content such as keys/C2/packer names, section table, behavior, cryptographic features), immediately check it against the A table; on a hit → call the skill
• If no table entry is hit → act according to the constraints of the B table (change approach/backtrack/deliver partial conclusions); do not force your own pondering

Cross-system misjudgment table (mandatory prerequisite before determination): at any moment when you are about to write "this is a hook / dead code / loader bug / malicious", first check [[cross-system-models]] — the ten-category high-frequency misjudgment table + cross-system common patterns (local handle ≠ global identifier, ready ≠ eligible to run, no kernel entry ≠ no I/O, no CFG edge ≠ did not happen, disk ≠ running) + exception handling tree, and rule them out item by itemthe normal mechanisms allowed by that runtime model; write the exclusion process and basis into the report,do not write a conclusion before exclusion is complete。

The entire analysis process complies with [[analysis-contract]]: collect a context checklist before analysis (including investigation budget, ≤8 tool calls per target), pass fields between stages according to the data contract (do not rescan), and perform independent review before delivering conclusions (check evidence ↔ conclusions item by item; output a structured format that includes confidence).

Step 4 (optional): Experience retrospective

After delivering the analysis conclusions, ask the user whether to feed back this pitfall/new method to the skill library—if needed, call [[re-feedback]] (three tiers: publish an issue / add to local library / do not add; distillation must be desensitized, see that gateway's red lines).

When to use / when not to use

• Use: any reverse engineering/malware/firmware/protocol/mobile/cracking/CTF analysis request
• Do not use: precise requests already triggered by a specific skill (e.g. "use Ghidra to analyze this code" can go directly to [[re-ghidra]])

Common pitfalls and traps

• Probing is not just for show: if memory is <4GB but Ghidra was chosen → prompt to switch to radare2

• The goal is to "see the logic" but a sandbox is used directly → static first, dynamic on demand

• It is normal for the user to have no tools installed—do not get stuck because of a MISS; guide installation via "Tool Preparation"

• Search community reverse engineering results before digging yourself: Symptom—writing your own parser/algorithm recovery for similar targets (protocols/packers/signatures) takes 10 times as long as porting; Cause—open-source reverse engineering projects (protocol implementations, unpackers, emulator callback sets) are the accumulated results of predecessors and can be ported directly; Countermeasure—first search GitHub/Gitee/codeload for similar projects (even if versions differ, the structure/patterns can be reused), and dig yourself only after confirming there is no ready-made result

• Finish the entry point and stop calling skills: Symptom—after entry-point orchestration, you rack your brains on your own, and when new characteristics (packer/encryption/anti-debugging) are discovered midway, you do not call the corresponding skill; Cause—re-routing was not executed; Countermeasure—follow the dual track of step three: compare each completed gateway/each new piece of evidence against the [[rerouting]] trigger table, and call as soon as there is a hit

• Treat a large goal as one move and demand a one-shot full analysis: Symptom—upon receiving "analyze this program," directly demand a full analysis plus complete report, with tools/skills returning all results at once, causing context bloat and repeated scanning; Cause—failure to split a long task into a chain of small steps; large all-in-one output sacrifices explorability and traceability; Countermeasure—split into atomic small steps (list strings→check xref→decompile a single function), with each step's output carrying structured fields such as addresses/symbols to feed directly into the next step, and pull large outputs as needed by line range/pagination instead of pulling everything at once (Source: ReVa (cyberkaida), Apache-2.0)

• When tool parameters do not match, switch paths instead of normalizing input first: Symptom—a parameter error (address/symbol name form mismatch, type mismatch) immediately leads to judging the tool unusable or switching approaches; Cause—the tool input layer inherently tolerates common deviations, and typical LLM errors can be absorbed at the input end; Countermeasure—normalize before retrying: try addresses↔symbol names both ways, add type conversions for numeric/boolean parameters, and eliminate whitespace differences in signature text (e.g. char *func( and char* func( are equivalent); when mutually exclusive parameters conflict, remove one according to the error message and retry (Source: ReVa (cyberkaida), Apache-2.0)

• Treat an error as a dead end and do not read the next-step guidance in the error message: Symptom—stop or switch paths as soon as a tool errors, ignoring the fix suggestions in the error text; Cause—treating errors as endpoints rather than decision points; Countermeasure—error messages usually carry enough corrective context (similar-name suggestions, available lists, prerequisite hints such as "decompile before renaming"/"define the function before modifying it"); retry after correcting according to the guidance, and the cost of retrying is lower than switching paths (Source: ReVa (cyberkaida), Apache-2.0)

• Context bloat in long tasks: synchronous wait for full volume vs cursor-based incremental polling: Symptom — minute-scale analysis (full automated analysis, batch comparison) synchronously waits indefinitely or repeatedly re-queries old results, duplicate content crowds out the context, and later judgments get diluted; Cause — failure to use a "small fragments + incremental" mechanism to manage long-task context; Countermeasure — hand long tasks to background jobs, first take back the job identifier + log cursor and immediately continue, poll only for new lines after the cursor, and fetch the complete result only at the terminal state, while running other steps in parallel during this period; the output side is the same: for lists, count first then list, default to compact mode (name + address + size), and enable verbose only when details are needed — never pull an entire large collection all at once (Source: ReVa (cyberkaida), Apache-2.0)

• If preset tools cannot cover it, it deadlocks, and the script escape hatch is not enabled: Symptom — when the standard toolchain lacks the corresponding capability (batch processing, custom logic), it stalls or gives up; Cause — failure to treat direct script access as a fallback channel, or conversely abusing scripts to bypass dedicated tools; Countermeasure — tools first: confirm there is no dedicated skill/tool before detouring to a script; script execution carries guardrails (output truncation, timeout, exception capture, write only to the registered script directory), and inline code goes through a temporary file; script artifacts are backfilled into structured fields to continue subsequent steps (Source: ReVa (cyberkaida), Apache-2.0)