New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Firmware Static Analysis

by OrbitCurve in OrbitCurve/firmware-reverse-engineering

Systematic static analysis of ELF firmware binaries using command-line tools (file, strings, readelf, objdump, xxd).

Apache-2.0Auto-check passedSecurity

Install Firmware Static Analysis

skills CLI
$ npx skills add OrbitCurve/firmware-reverse-engineering --skill firmware-static-analysis -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install OrbitCurve/firmware-reverse-engineering firmware-static-analysis --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/OrbitCurve/firmware-reverse-engineering.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/firmware-reverse-engineering/skills/firmware-static-analysis .claude/skills/firmware-static-analysis && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
firmware-static-analysis
GitHub stars
214
Token cost
~3.2k tokens
SKILL.md length
875 words
Files
3 (incl. references)
Skills in repo
3
Repo updated
First seen
Licence
Apache-2.0

At a glance

Systematic static analysis of ELF firmware binaries using command-line tools (file, strings, readelf, objdump, xxd).

  • Works in 8 steps: Binary Identification → String Extraction → Symbol Analysis → …
  • The agent needs to perform initial reconnaissance on firmware/embedded binaries before reverse engineering
  • SKILL.md covers Analysis Workflow, Step 1: Binary Identification, Step 2: String Extraction and Step 3: Symbol Analysis, plus 8 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Firmware Static Analysis is an agent skill from OrbitCurve/firmware-reverse-engineering. Systematic static analysis of ELF firmware binaries using command-line tools (file, strings, readelf, objdump, xxd). Use when the agent needs to perform initial reconnaissance on firmware/embedded binaries before reverse engineering, specifically for (1) Identifying architecture and binary characteristics, (2) Extracting metadata, strings, and imports, (3) Analyzing symbols, sections, and entry points, (4) Understanding binary structure and dependencies, (5) Generating structured analysis reports. Covers ARM…

Its SKILL.md is about 3.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 3 other files, including reference files (for example `references/architectures.md` and `references/toolchain.md`).

It sits in Security, covering Static analysis and SAST and Reverse engineering and malware. The repository describes itself as: A full claude and codex skillsets for firmware reverse engineering. The licence is Apache-2.0.

When your agent uses it

  • The agent needs to perform initial reconnaissance on firmware/embedded binaries before reverse engineering
  • Specifically for
  • Identifying architecture and binary characteristics
  • Extracting metadata

Example prompts

  • “/firmware-static-analysis”

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. Binary Identification
  2. String Extraction
  3. Symbol Analysis
  4. Structure Analysis
  5. Security Analysis
  6. Metadata Extraction
  7. Disassembly (with symbols)
  8. Handling Stripped Binaries

What it can do on your machine

Read from SKILL.md and the folder at commit a047a60. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are bash and markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Firmware Static Analysis loads about 3.2k tokens when it runs, and up to ~5.4k if it reads all its reference files. Until then it costs about 165 tokens; SKILL.md has 875 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~165
When it runs · the whole SKILL.md, loaded when a task matches
~3.2k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~5.4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from OrbitCurve/firmware-reverse-engineering at commit a047a60, republished under its Apache-2.0 licence (© OrbitCurve). 875 words, ~3,155 tokens.

Download SKILL.mdSave it as .claude/skills/firmware-static-analysis/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.
name
firmware-static-analysis
description
Systematic static analysis of ELF firmware binaries using command-line tools (file, strings, readelf, objdump, xxd). Use when the agent needs to perform initial reconnaissance on firmware/embedded binaries before reverse engineering, specifically for (1) Identifying architecture and binary characteristics, (2) Extracting metadata, strings, and imports, (3) Analyzing symbols, sections, and entry points, (4) Understanding binary structure and dependencies, (5) Generating structured analysis reports. Covers ARM, MIPS, x86, RISC-V, PowerPC architectures. Does NOT handle firmware extraction/unpacking (use separate skill for that).

Firmware Static Analysis

Perform comprehensive static analysis of ELF firmware binaries using command-line reconnaissance tools. This skill guides systematic metadata extraction and binary characterization before deeper reverse engineering.

Analysis Workflow

Follow this workflow when analyzing firmware binaries. Always start from Step 1 and proceed sequentially:

  1. Binary identification - Determine architecture, bitness, endianness
  2. String extraction - Find human-readable strings and clues
  3. Symbol analysis - Examine imports, exports, and functions
  4. Structure analysis - Analyze segments, sections, and entry points
  5. Security analysis - Check PIE, RELRO, stack canaries
  6. Metadata extraction - Find compiler info and build metadata
  7. Report generation - Create structured markdown report

Step 1: Binary Identification

Identify the target architecture and basic characteristics.

bash
file <binary>

Extract these details:

  • CPU architecture (ARM, MIPS, x86, RISC-V, PowerPC, etc.)
  • Bitness (32-bit or 64-bit)
  • Endianness (LSB/little-endian or MSB/big-endian)
  • Link type (dynamically linked, statically linked, or not linked)
  • Binary type (executable, shared object, relocatable)

Architecture reference: If unfamiliar with the detected architecture, read references/architectures.md for architecture-specific details including calling conventions and common use cases.

Step 2: String Extraction

Extract all printable strings to understand program behavior and inputs.

bash
strings -a <binary> > strings.txt

Analyze for:

  • Usage/help text patterns (usage|help|--)
  • Format strings (%s|%d|%x)
  • Error messages (error|fail|invalid)
  • File paths and directories (/etc/|/tmp/|/var/)
  • URLs and network addresses
  • Hardcoded credentials (common in firmware!)
  • Library names and debug paths
  • Version strings and build info

Targeted searches:

bash
strings -a <binary> | grep -i -E 'usage|error|%d|%s'
strings -a <binary> | grep -i -E 'password|admin|root|key'
strings -a <binary> | grep -E '^/|^\.'  # File paths

Step 3: Symbol Analysis

Examine what functions the binary imports and exports.

Dynamic Symbols (when .dynsym is present, including many stripped binaries)
bash
readelf --dyn-syms --wide <binary>

Look for:

  • Imported functions (from libc, libssl, custom libraries)
  • Exported functions (what this binary provides)
  • Function names that hint at behavior (authenticate, encrypt, parse, etc.)
  • Standard library usage patterns

Alternative command:

bash
objdump -T <binary>
Function Discovery

Identify key functions for later disassembly:

bash
readelf -Ws <binary> | grep ' main$'
readelf -Ws <binary> | grep -E 'FUNC.*GLOBAL'

Common firmware functions to look for: main, init, setup, parse_config, handle_request, authenticate, encrypt, decrypt

Step 4: Structure Analysis

Analyze the binary's internal structure.

ELF Header
bash
readelf -h <binary>

Key information:

  • Entry point address - Where execution begins
  • Type - ET_EXEC (non-PIE) or ET_DYN (PIE/shared object)
  • Machine - Confirm architecture
  • Section headers - Number and locations
Program Headers (Segments)
bash
readelf -lW <binary>

Check for:

  • INTERP segment - Dynamic linker path (if dynamically linked)
  • LOAD segments - Memory layout (addresses, permissions)
  • DYNAMIC segment - Dynamic linking information
  • GNU_STACK - Stack permissions (NX bit)
Section Headers
bash
readelf -S <binary>

Important sections:

  • .text - Code section (note size and address)
  • .rodata - Read-only data (strings, constants)
  • .data - Initialized data
  • .bss - Uninitialized data
  • .dynsym / .dynstr - Dynamic symbols and strings
  • .plt / .got - Procedure linkage table and global offset table
  • .comment - Compiler information

Verify symbol tables directly:

bash
# Get .dynsym and .dynstr offsets from readelf -S
xxd -s 0x<DYNSYM_OFFSET> -l 256 <binary>
xxd -s 0x<DYNSTR_OFFSET> -l 256 <binary>
Dynamic Section
bash
readelf -d <binary>

Extract:

  • NEEDED - Shared library dependencies
  • SONAME - Shared object name (if present)
  • RPATH/RUNPATH - Library search paths
  • FLAGS - Dynamic linking flags

Step 5: Security Analysis

Assess available evidence, retaining an unknown/not observed result where needed. PT_GNU_RELRO is a program header. For conventional dynamically linked ELF, that segment plus immediate binding (BIND_NOW or FLAGS/FLAGS_1 containing NOW) indicates full RELRO; the segment alone indicates partial RELRO. Absent dynamic tags in a static binary require a different assessment.

GNU_STACK without E requests a non-executable stack. A missing header is unknown and depends on the ABI/kernel. Canary or _chk symbols show some instrumentation, not complete coverage; absence does not prove absence in stripped, static or inlined code. Inspect relevant functions when reporting.

Show full SKILL.md (357 more words)Show less
PIE/ASLR Check
bash
readelf -h <binary> | grep Type
  • Type: EXEC (Executable file) = Non-PIE (fixed addresses)
  • Type: DYN (Shared object file) = PIE candidate OR shared library. Check FLAGS_1: PIE, loader metadata and intended use.
  • ASLR is runtime policy, not established by ELF type. Verify on the target kernel and compare mappings across runs.
Security Features Check
bash
readelf -dW <binary> | grep -E 'BIND_NOW|FLAGS.*NOW'
readelf -lW <binary> | grep -E 'GNU_RELRO|GNU_STACK'
readelf -Ws <binary> | grep -E '__stack_chk_fail|__(memcpy|memmove|strcpy|strncpy|sprintf|snprintf|printf)_chk'

Look for:

  • RELRO (RELocation Read-Only) - GOT protections
  • Stack canaries (__stack_chk_fail)
  • NX stack (non-executable stack via GNU_STACK)
  • Fortify evidence: checked wrappers such as __memcpy_chk or __snprintf_chk

Step 6: Metadata Extraction

Extract compiler and build information.

Compiler Info
bash
readelf -p .comment <binary>
strings <binary> | grep -i -E 'gcc|clang|build|version'

Look for:

  • GCC/Clang version
  • Target triplet (e.g., arm-linux-gnueabihf-gcc)
  • Optimization level hints
  • Build date/time
Build Metadata
bash
readelf -n <binary>  # Build ID and ABI info

Step 7: Disassembly (with symbols)

If symbols are present, disassemble key functions.

Verify Symbol Availability
bash
readelf -Ws <binary> | grep ' main$'
readelf -Ws <binary> | grep -E '<function_name>'
Disassemble Functions
bash
objdump -d --disassemble=main <binary>
objdump -d --disassemble=<function_name> <binary>

Analysis tips:

  • Look for calls to imported functions (e.g., printf@plt, strcmp@plt)
  • Identify control flow (branches, loops)
  • Note register usage patterns
  • Track function call arguments

Step 8: Handling Stripped Binaries

When symbols are removed, adapt the analysis approach.

Strip and Compare
bash
cp <binary> <binary>_stripped
strip <binary>_stripped

# Compare before/after
readelf -Ws <binary>
readelf -Ws <binary>_stripped
Disassemble Without Symbols
bash
# Name-based disassembly will fail:
objdump -d --disassemble=main <binary>_stripped  # FAILS

# Instead, dump entire .text section:
objdump -d -j .text <binary>_stripped | less

Function identification strategies:

  • Look for common prologues (e.g., ARM: push {r11, lr}, x86: push rbp)
  • Find calls to known PLT functions (e.g., atoi@plt, printf@plt)
  • Use entry point address from readelf -h as starting point
  • Look for string references (xrefs to .rodata)

Report Generation

Create a structured markdown report with all findings. Use this template:

markdown
# Firmware Static Analysis Report

**Binary:** <filename>
**Analysis Date:** <date>

## Executive Summary

[2-3 sentence overview of the binary: purpose, architecture, and key findings]

## Binary Characteristics

- **File Type:** [ELF type]
- **Architecture:** [CPU architecture, bitness, endianness]
- **Entry Point:** [address]
- **Link Type:** [static/dynamic]
- **PIE:** [Yes/No/Unknown; evidence]
- **ASLR:** [Runtime tested / Not tested; evidence]
- **Stripped:** [Yes/No]

## Architecture Details

- **CPU:** [ARM/MIPS/x86/RISC-V/etc.]
- **Bitness:** [32-bit / 64-bit]
- **Endianness:** [Little-endian / Big-endian]
- **Calling Convention:** [ABI details]

## Symbol Analysis

### Imported Functions
[List key imported functions and what they suggest about behavior]
- `printf` - Formatting and output
- `socket` - Network communication
- `strcmp` - String comparison
- etc.

### Exported Functions
[List exported functions if any]

### Key Functions Identified
[List main and other important functions found]

## String Analysis

### Interesting Strings
[List notable strings found, categorized by type]

**Configuration/Paths:**
- `/etc/config.conf`
- etc.

**Credentials/Keys:**
- `admin:default_password` [⚠️ SECURITY CONCERN]
- etc.

**Error Messages:**
- "Invalid input"
- etc.

**Network/URLs:**
- `http://update.example.com`
- etc.

## Structure Analysis

### Segments
[List key program segments with addresses and permissions]

### Sections
[List important sections with sizes]
- `.text`: [size] - Code
- `.rodata`: [size] - Read-only data
- etc.

### Dynamic Dependencies
[List required shared libraries]
- `libc.so.6`
- `libssl.so.1.1`
- etc.

## Security Analysis

### Mitigations Detected
- PIE: [Yes/No/Unknown; evidence]
- ASLR: [Runtime result/Not tested]
- RELRO: [Full/Partial/None/Unknown; evidence]
- Stack canary evidence: [Observed/Not observed/Unknown; coverage unverified]
- Stack execute request: [Non-executable/Executable/Missing; runtime unverified]
- Fortify evidence: [Observed/Not observed/Unknown]

### Security Concerns
[List any security issues found]
- Hardcoded credentials
- Weak/no ASLR
- Missing stack protection
- etc.

## Metadata

### Compiler Information
- **Compiler:** [GCC/Clang version]
- **Target:** [Toolchain target triplet]
- **Build Date:** [if available]

### Build ID
[Build ID from notes section]

## Disassembly Highlights

### main() Function
[Brief description of what main does based on disassembly]

### Other Key Functions
[Brief description of other important functions]

## Recommendations for Further Analysis

1. [Specific next steps based on findings]
2. [Tools to use next: Ghidra, IDA, Binary Ninja, etc.]
3. [Specific functions or areas to focus on]
4. [Dynamic analysis recommendations]

## Appendix

### Full Symbol Table
[Attach or reference full symbol list if relevant]

### Complete String Dump
[Reference to strings.txt file]

Additional References

  • Architecture details: See references/architectures.md for architecture-specific calling conventions and characteristics
  • Toolchain commands: See references/toolchain.md for detailed command syntax and options

Tips

  • Always work on a copy - Never modify the original firmware binary
  • Save intermediate outputs - Redirect command outputs to files for reference (e.g., strings -a binary > strings.txt)
  • Cross-reference findings - Strings/imports are candidates; verify authentication use, attacker control and reachability before reporting a vulnerability
  • Architecture matters - Load the architecture reference early if unfamiliar with the target
  • Document as you go - Build the report incrementally during analysis
  • Look for the unusual - Hardcoded credentials, unusual network addresses, and debug paths are common in firmware
  • Check toolchain - Version strings are clues; verify component identity, backports and vulnerable code before assigning a CVE
  • PIE vs non-PIE - ET_EXEC binaries have fixed addresses, making analysis easier
  • Stripped binaries - Don't despair, entry point and PLT calls still provide context

© OrbitCurve, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 2 other files (references) in plugins/firmware-reverse-engineering/skills/firmware-static-analysis of OrbitCurve/firmware-reverse-engineering.

  • SKILL.md
  • references/architectures.md
  • references/toolchain.md

Open the folder on GitHubat commit a047a60

Compare with similar skills

Firmware Static Analysis next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Firmware Static Analysis compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Firmware Static Analysis this skillOrbitCurve/firmware-reverse-engineering214—~3.2kAutomated safety check: PassApache-2.0
Analyzing Packed Malware With Upx Unpackermukul975/Anthropic-Cybersecurity-Skills34k—~3kAutomated safety check: PassApache-2.0
Performing Dynamic Analysis With Any Runmukul975/Anthropic-Cybersecurity-Skills34k—~2.8kAutomated safety check: PassApache-2.0
Performing iOS App Security Assessmentmukul975/Anthropic-Cybersecurity-Skills34k—~3kAutomated safety check: PassApache-2.0
Performing Static Malware Analysis With Pe Studiomukul975/Anthropic-Cybersecurity-Skills34k—~3.3kAutomated safety check: PassApache-2.0
Analyzing Linux Elf Malwaremukul975/Anthropic-Cybersecurity-Skills34k—~3.1kAutomated safety check: WarnApache-2.0

Similar skills

  • Analyzing Packed Malware With Upx Unpacker

    mukul975/Anthropic-Cybersecurity-Skills

    Identifies and unpacks UPX-packed malware samples, including binaries with modified UPX magic bytes or headers that block automated decompression, to recover the original executable for static…

    34k GitHub stars~3k tokensUpdated 1 mo ago
    SecurityAuto-check passed

  • Performing Dynamic Analysis With Any Run

    mukul975/Anthropic-Cybersecurity-Skills

    Perform interactive dynamic malware analysis using the ANY.RUN cloud sandbox to detonate samples, observe real-time execution behavior, interact with malware prompts such as dialogs and CAPTCHAs…

    34k GitHub stars~2.8k tokensUpdated 1 mo ago
    SecurityAuto-check passed

  • Performing iOS App Security Assessment

    mukul975/Anthropic-Cybersecurity-Skills

    Performs comprehensive iOS application security assessments using Frida for dynamic instrumentation, Objection for runtime exploration, SSL pinning bypass for traffic interception, keychain…

    34k GitHub stars~3k tokensUpdated 1 mo ago
    SecurityAuto-check passed

  • Performing Static Malware Analysis With Pe Studio

    mukul975/Anthropic-Cybersecurity-Skills

    Performs static analysis of Windows PE malware samples using PEStudio to examine file headers, imports, strings, and resources without executing the binary, identifying packing, anti-analysis…

    34k GitHub stars~3.3k tokensUpdated 1 mo ago
    SecurityAuto-check passed

  • Analyzing Linux Elf Malware

    mukul975/Anthropic-Cybersecurity-Skills

    Analyze malicious Linux ELF binaries — botnets, cryptominers, ransomware, and rootkits targeting Linux servers, containers, and cloud infrastructure — through static analysis, dynamic tracing, and…

    34k GitHub stars~3.1k tokensUpdated 1 mo ago
    SecurityAuto-check: warnings

  • Binary Re

    aiskillstore/marketplace

    This skill should be used when analyzing binaries, executables, or bytecode to understand what they do or how they work.

    430 GitHub starsUsed in 1 repo~2.6k tokens
    SecurityAuto-check passed

More from OrbitCurve/firmware-reverse-engineering

  • Ghidra Re

    OrbitCurve/firmware-reverse-engineering

    Expert-level Ghidra reverse engineering for firmware binaries with emphasis on stripped binary analysis, automated function discovery, cryptographic routine identification, authentication logic…

    214 GitHub stars~4.2k tokensUpdated 1 mo ago
    Auto-check passed

  • Firmware Security Reports

    OrbitCurve/firmware-reverse-engineering

    Evidence-based security report generation for firmware assessments.

    214 GitHub stars~4.1k tokensUpdated 1 mo ago
    Auto-check passed

Categories

Questions about Firmware Static Analysis

What does Firmware Static Analysis do?

Systematic static analysis of ELF firmware binaries using command-line tools (file, strings, readelf, objdump, xxd). Firmware Static Analysis is an agent skill from OrbitCurve/firmware-reverse-engineering. Systematic static analysis of ELF firmware binaries using command-line tools (file, strings, readelf, objdump, xxd).

When should I use Firmware Static Analysis?

Firmware Static Analysis fits situations like: the agent needs to perform initial reconnaissance on firmware/embedded binaries before reverse engineering; specifically for; identifying architecture and binary characteristics; extracting metadata.

How do I install Firmware Static Analysis in Claude Code?

Run `npx skills add OrbitCurve/firmware-reverse-engineering --skill firmware-static-analysis -a claude-code`. Or copy the skill folder (plugins/firmware-reverse-engineering/skills/firmware-static-analysis in OrbitCurve/firmware-reverse-engineering) into .claude/skills/firmware-static-analysis in your project. Claude Code loads it when a task matches its description.

How do I install Firmware Static Analysis in Codex?

Run `npx skills add OrbitCurve/firmware-reverse-engineering --skill firmware-static-analysis -a codex`. Or copy the skill folder (plugins/firmware-reverse-engineering/skills/firmware-static-analysis in OrbitCurve/firmware-reverse-engineering) into .agents/skills/firmware-static-analysis in your project. Codex loads it when a task matches its description.

Can I use Firmware Static Analysis in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add OrbitCurve/firmware-reverse-engineering --skill firmware-static-analysis -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/firmware-static-analysis, .gemini/skills/firmware-static-analysis, .github/skills/firmware-static-analysis and .opencode/skills/firmware-static-analysis in your project.

What does Firmware Static Analysis need to run?

SKILL.md names no scripts, command-line tools or credentials: Firmware Static Analysis is instructions for the agent only.

Does Firmware Static Analysis access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Firmware Static Analysis safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Firmware Static Analysis use?

Firmware Static Analysis is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Firmware Static Analysis use?

About 3.2k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2.3k tokens, read only when the agent opens those files.

What are the alternatives to Firmware Static Analysis?

Skills that share tags, products or a category with Firmware Static Analysis: Analyzing Packed Malware With Upx Unpacker (mukul975/Anthropic-Cybersecurity-Skills, 34k stars), Performing Dynamic Analysis With Any Run (mukul975/Anthropic-Cybersecurity-Skills, 34k stars), Performing iOS App Security Assessment (mukul975/Anthropic-Cybersecurity-Skills, 34k stars) and Performing Static Malware Analysis With Pe Studio (mukul975/Anthropic-Cybersecurity-Skills, 34k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Firmware Static Analysis?

OrbitCurve (a GitHub organization) maintains it in OrbitCurve/firmware-reverse-engineering, which has 214 GitHub stars. The repository holds 3 skills in this directory. The repository was last updated on September 7, 2026.

Source: OrbitCurve/firmware-reverse-engineering on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.