# What Cybersecurity Scenarios Are Addressed by Routing Rules R0–R8 in reverse-skill

> Explore cybersecurity scenarios R10-R18 in reverse-skill. Discover how these rules enhance reverse engineering, mobile analysis, and more.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: deep-dive
- Published: 2026-09-02

---

**Routing rules R0–R8 in the reverse-skill repository cover nine distinct cybersecurity scenarios spanning generic reverse engineering, mobile application analysis (Android and iOS), JavaScript frontend reversal, specialized virtual machine bytecode inspection, .NET assembly decompilation, static binary analysis with IDA and radare2, and embedded firmware penetration testing.**

The routing table at [`skills/config/routing.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/config/routing.json) serves as the central decision engine for the zhaoxuya520/reverse-skill framework, mapping natural language task hints to specialized skill modules. These nine rules define the primary attack vectors and analysis workflows supported by the system, ensuring requests route to the correct tooling pipeline based on regex keyword matching.

## Overview of the Routing Table Structure

The master routing configuration resides in [`skills/config/routing.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/config/routing.json), where rules **R0** through **R8** occupy lines 13–71. Each rule consists of a human-readable label, a target skill file path, and keyword regex patterns that trigger the match.

The master router (`skills/scripts/master-route.ps1` or [`master-route.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/master-route.sh)) evaluates incoming hints against these rules, assigns scores based on regex matches, and selects the highest-priority route. The `priority` array (lines 24–28) ensures **R0** acts as a catch-all fallback, positioned last so that specific rules (R1–R8) take precedence when applicable.

| Rule | Scenario | Skill Module | Key Detection Keywords |
|------|----------|--------------|------------------------|
| **R0** | Generic reverse engineering | [`reverse-engineering/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/reverse-engineering/SKILL.md) | `ollvm`, `anti-debug`, `gdb`, `frida` (non-APK) |
| **R1** | Android APK reverse engineering | [`apk-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/apk-reverse/SKILL.md) | `apk`, `jadx`, `apktool`, `certificate pinning` |
| **R2** | Mobile reverse (iOS + Android) | [`mobile-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/mobile-reverse/SKILL.md) | `ipa`, `ios reverse`, `jailbreak`, `objection` |
| **R3** | JavaScript / frontend reverse | [`js-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/js-reverse/SKILL.md) | `js reverse`, `webpack`, `encrypted param` |
| **R4** | DSL VM reverse | [`reverse-engineering/dsl-vm-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/reverse-engineering/dsl-vm-reverse/SKILL.md) | `dsl vm`, `custom vm`, `fireye` |
| **R5** | .NET reverse | [`dotnet-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/dotnet-reverse/SKILL.md) | `.net`, `dnspy`, `de4dot` |
| **R6** | IDA static analysis | [`ida-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/ida-reverse/SKILL.md) | `ida`, `disassembl`, `so file`, `jni` |
| **R7** | radare2 analysis | [`radare2/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/radare2/SKILL.md) | `radare`, `r2`, `rabin2` |
| **R8** | Firmware pentest | [`firmware-pentest/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/firmware-pentest/SKILL.md) | `firmware`, `binwalk`, `iot`, `嵌入式` |

## Detailed Breakdown of Each Rule

### R0: Generic Reverse Engineering Fallback

**R0** functions as the safety net for the routing system. When an incoming hint contains generic reverse engineering terminology—such as `ollvm`, `anti-debug`, `gdb`, or `frida` outside the context of Android APKs—but fails to match more specific rules, the system routes to [`reverse-engineering/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/reverse-engineering/SKILL.md). This ensures no valid reverse engineering task falls through unhandled while allowing specialized rules to take precedence for contextual scenarios.

### R1: APK Reverse Engineering

**R1** handles Android application security assessments. The rule triggers on keywords like `apk`, `smali`, `jadx`, `apktool`, `android`, and Chinese terms for repackaging (`重打包`), root detection (`root detect`), and certificate pinning bypass (`pinning 绕过`). This routes de-obfuscation tasks, certificate pinning analysis, and APK unpacking workflows to [`apk-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/apk-reverse/SKILL.md).

### R2: Mobile Reverse Engineering (Cross-Platform)

**R2** extends mobile analysis to iOS and cross-platform scenarios. It matches `ipa`, `ios reverse`, `jailbreak`, and `objection`, directing tasks involving iOS binary analysis, jailbreak detection bypasses, and broader mobile reverse engineering to [`mobile-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/mobile-reverse/SKILL.md). This separation prevents Android-specific tools from polluting iOS workflows.

### R3: JavaScript and Frontend Reverse Engineering

**R3** isolates web-centric analysis workflows. It captures hints containing `js reverse`, `webpack`, or `encrypted param`, routing JavaScript de-obfuscation, Webpack bundle analysis, and encrypted HTTP parameter inspection to [`js-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/js-reverse/SKILL.md). This rule ensures frontend security testing utilizes the appropriate HTTP capture and replay tooling.

### R4: DSL VM Reverse Engineering

**R4** addresses specialized virtual machine bytecode analysis. When hints reference `dsl vm`, `custom vm`, or `fireye`, the system selects [`reverse-engineering/dsl-vm-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/reverse-engineering/dsl-vm-reverse/SKILL.md) to handle custom virtual machine instruction sets and bytecode reversal scenarios common in advanced obfuscation schemes.

### R5: .NET Reverse Engineering

**R5** targets managed code analysis. Keywords like `.net`, `dnspy`, and `de4dot` trigger this rule, routing C# assembly de-obfuscation and .NET binary analysis to [`dotnet-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/dotnet-reverse/SKILL.md). This ensures proper handling of managed runtime environments distinct from native binary analysis.

### R6: IDA Pro Static Analysis

**R6** covers classic static analysis using IDA Pro. It matches `ida`, `disassembl`, `so file`, and `jni`, directing ELF, SO, and other native binary analysis tasks to [`ida-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/ida-reverse/SKILL.md). This rule specifically handles scenarios requiring disassembly and decompilation via the IDA toolchain.

### R7: radare2 Toolchain Analysis

**R7** provides an open-source alternative to R6, triggering on `radare`, `r2`, and `rabin2`. It routes tasks to [`radare2/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/radare2/SKILL.md) for users preferring the radare2 framework for static and dynamic binary analysis, ensuring support for the complete r2 toolchain.

### R8: Firmware Penetration Testing

**R8** handles embedded and IoT security. Keywords like `firmware`, `binwalk`, `iot`, and `嵌入式` (embedded) trigger this rule, routing firmware extraction, filesystem analysis, and embedded device exploitation to [`firmware-pentest/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/firmware-pentest/SKILL.md). This supports hardware security assessments using tools like binwalk and EMBA.

## How the Routing Engine Evaluates Rules

The routing mechanism implemented in [`skills/scripts/master-route.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/master-route.sh) (and its PowerShell equivalent) operates through regex evaluation against the JSON configuration:

1. **Hint Ingestion**: The master router receives a textual hint describing the cybersecurity task.
2. **Regex Scoring**: Each rule's `must` regex patterns are evaluated against the hint. Matching rules accumulate scores.
3. **Priority Resolution**: When multiple rules match, the router consults the `priority` array. Earlier entries win ties.
4. **Skill Dispatch**: The highest-scoring rule's `skill` path is loaded (e.g., [`apk-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/apk-reverse/SKILL.md)), and the corresponding workflow executes.

The JSON structure for **R1** (lines 14–18) exemplifies this pattern:

```json
"R1": {
  "label": "APK reverse",
  "skill": "apk-reverse/SKILL.md",
  "keywords": [
    { "must": "\\bapk\\b|smali|jadx|apktool|\\bandroid\\b|android.?reverse|安卓|反编译.?apk|apk.?加固|重打包|root.?detect|root.?检测|证书.?校验|certificate.?pinning|pinning.?绕过|签名.?校验", "note": "android 裸词/root 检测/证书校验/pinning 绕过 均为 APK 分析常见诉求" }
  ]
}

```

## Practical Routing Examples

### Example 1: Android APK Certificate Pinning Bypass

When processing the hint *"unpack an Android APK that uses certificate pinning and heavy obfuscation"*:

1. **R1** regex matches (`apk`, `certificate pinning`)
2. Primary skill resolved: [`apk-reverse/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/apk-reverse/SKILL.md)
3. Execution via master router:

```bash
bash skills/scripts/master-route.sh --hint "unpack Android APK with cert pinning"

# → loads apk-reverse/SKILL.md

# → runs preparation scripts (bootstrap-reverse.sh for jadx, apktool, etc.)

```

### Example 2: Firmware Extraction

For the task *"Extract the file system from a router firmware image using binwalk"*:

1. **R8** regex (`firmware|binwalk|iot|嵌入式`) matches
2. Primary skill resolved: [`firmware-pentest/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/firmware-pentest/SKILL.md)
3. Execution triggers binwalk bootstrap and extraction scripts

```bash
bash skills/scripts/master-route.sh --hint "binwalk router firmware"

# → loads firmware-pentest/SKILL.md

# → triggers bootstrap for binwalk if missing, then runs the extraction script

```

### Example 3: Generic Binary Analysis

For *"Analyse a suspicious ELF binary for hidden strings"* with no specific tool mentioned:

1. No specific rule (R1–R8) matches
2. **R0** catches the generic `reverse` keyword
3. Primary skill resolved: [`reverse-engineering/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/reverse-engineering/SKILL.md)
4. Generic pipeline selects available tools (IDA, radare2, or Ghidra) from [`tool-index.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/tool-index.md)

## Summary

Routing rules **R0–R8** in the reverse-skill repository provide deterministic mapping for core cybersecurity scenarios:

- **R0** serves as the generic reverse engineering fallback for unstructured tasks
- **R1–R2** segregate Android and iOS mobile analysis to prevent tool contamination
- **R3** isolates JavaScript and frontend security workflows
- **R4–R5** handle specialized bytecode environments (DSL VMs and .NET assemblies)
- **R6–R7** route to appropriate static analysis toolchains (IDA Pro vs. radare2)
- **R8** manages embedded firmware and IoT penetration testing

These rules ensure that natural language task descriptions route to the correct [`SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/SKILL.md) workflow files, automating tool selection for reverse engineering and pentesting operations.

## Frequently Asked Questions

### What is the purpose of routing rule R0 in the reverse-skill framework?

**R0** acts as the default fallback mechanism when no specific rule matches an incoming task hint. It captures generic reverse engineering requests containing terms like `ollvm`, `anti-debug`, or `gdb` that don't fit into the specialized categories of R1–R8, ensuring all reverse engineering tasks route to [`reverse-engineering/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/reverse-engineering/SKILL.md) rather than failing to match.

### How does the routing engine decide between similar rules like R1 and R2?

The engine uses the `priority` array defined in [`routing.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/routing.json) (lines 24–28) to break ties. Specific rules like **R1** (APK) and **R2** (Mobile) appear before the generic **R0**. When scores tie between **R1** and **R2**, the earlier entry in the priority list wins, ensuring Android-specific hints route to APK analysis rather than generic mobile workflows.

### Can new routing rules be added beyond R8?

Yes, the architecture supports extensibility. New rules can be appended to [`skills/config/routing.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/config/routing.json) before the fallback **R0** entry, with their identifiers inserted into the `priority` array at the appropriate specificity level. The master router ([`master-route.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/master-route.sh)/`master-route.ps1`) dynamically reads the JSON configuration, requiring no code changes to support additional scenarios.

### Why are Chinese keywords included in rules like R1 and R8?

The regex patterns include Chinese terms (e.g., `安卓`, `反编译`, `嵌入式`) to support native Chinese cybersecurity terminology commonly used in reverse engineering contexts. This localization ensures the routing engine correctly identifies tasks described in Chinese, such as `重打包` (repackaging) for APKs or `嵌入式` (embedded) for firmware analysis.