CYB3RMX/Qu1cksc0pe

All-in-One malware analysis tool.

9
Hotness score
17
Reliability score
2,028
Stars
almost 7 years
Age
0
Published reviews
0
Questions

Scores

Hotness and reliability

The two headline scores, measured daily, with 30, 90, and 180 day views.

Hotness score

Jul 19, 2026

Current9

Previous14

Weekly average

100500
Full metrics details

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

180 observed daily rows. Missing days are not fabricated.

Hotness formula

40% Hot today + 40% Hot this week + 20% Breakout.

  • 40% Hot today: 1
  • 40% Hot this week: 14
  • 20% Breakout: 8
  • Stars gained: 1d: 0
  • Stars gained: 7d: 4
  • Stars gained: 14d: 11
  • Stars gained: 30d: 17
  • Stars gained: 90d: 48

Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.

  • Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
  • Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
  • Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
  • Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
  • Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
  • Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score

Reliability score

Jul 19, 2026

Current17

Previous17

Weekly average

100500
Full metrics details

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

180 observed daily rows. Missing days are not fabricated.

Reliability formula

30% Continuity + 30% Closure + 20% Shipping + 10% Liveness + 10% Support burden.

  • 30% Continuity: 8
  • 30% Closure: 0
  • 20% Shipping: 0
  • 10% Liveness: 42
  • 10% Support burden: 99

Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
  • Support burden = 100 − 2 × open issues per 1,000 stars
  • Liveness = 100 × exp(−pushed days ago ÷ 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score

Reliability breakdown

What drives the reliability score

Component scores measured daily from GitHub activity (2026-04-29).

Continuity30% of headline8

Activity on 0 of 90 tracked days in the last 90 and 0 of 30 in the last 30.

Closure30% of headline0

Merged 0 of 0 PRs opened and closed 0 of 0 issues opened over the last 90 tracked days — PR flow carries 55% of this component, issue flow 45%.

Shipping20% of headline0

0 releases in the last 180 days, 0 in the last 90 and 0 in the last 30 — a steady cadence scores highest.

Liveness10% of headline42

Last push 139 days ago — freshness decays as pushes age (roughly halves every 83 days without a push).

Support burden10% of headline99

Open-issue load isn't tracked for this repo yet.

Adoption confidence8

Modeled — how confidently teams are adopting this repo. Stargazers

Maintenance quality28

Modeled from PR/issue responsiveness and upkeep signals. Activity pulse

Risk score55

Modeled — lower is better; adoption and continuity risk. Repository

Stays active (30d)21%

Modeled chance the repo stays active over 30 days. Activity pulse

Stays active (90d)13%

Modeled chance the repo stays active over 90 days. Activity pulse

Release rhythm (180d)0

Regularity of releases over the last 180 days. Releases

Maintainer bus risk (90d)85%

Modeled — lower is better; concentration of commits in few maintainers. Contributors graph

Topics

Explore related topics

Jump into the topic listings this repository belongs to.

Measured history

Project metrics

Weekly GitHub totals with 30, 90, and 180 day views.

Weekly star gains

Jul 19, 2026

Current3

Previous8

Weekly star gains

113-5
Full metrics details

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

180 observed daily rows. Missing days are not fabricated.

DateValue

Cumulative stars

Jul 19, 2026

Current2,028

Previous2,025

Cumulative total

2,0281,0140
Full metrics details

Running total of the GitHub GraphQL stargazer count over time (not weekly deltas), reconstructed from starredAt events and totalCount in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

180 observed daily rows. Missing days are not fabricated.

DateValue

Issues opened

Jun 14, 2026

Current0

Previous0

Weekly total

110
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

144 observed daily rows. Missing days are not fabricated.

DateValue

Issues closed

Jun 14, 2026

Current0

Previous0

Weekly total

210
Full metrics details

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

144 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests opened

Jun 14, 2026

Current0

Previous0

Weekly total

110
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

144 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests closed

Jun 14, 2026

Current0

Previous0

Weekly total

110
Full metrics details

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

144 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests merged

Jun 14, 2026

Current0

Previous0

Weekly total

110
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

144 observed daily rows. Missing days are not fabricated.

DateValue

Issue close ratio (daily)

Feb 11, 2026

Current0.00

Previous1.00

Daily ratio — a gap means nothing was opened that day

How this works: each day's value is issues closed that day ÷ issues opened that day. Days when nothing was opened render as gaps — never a rolling average or a made-up zero. Values above 1 mean the project closed more issues than arrived that day.

1.000.500.00
Full metrics details

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

2 observed daily rows. Missing days are not fabricated.

Per-day formula: issues closed that day ÷ issues opened that day; blank when nothing was opened (a gap, not a zero).

DateIssues openedIssues closedStored score

Project Overview

Qu1cksc0pe is an all-in-one malware analysis tool built for fast static triage. You point it at a suspicious file and it tears the file apart in one pass: sections, imports, strings, embedded indicators, packer signatures, and matches against a bundled YARA rule set. It handles the formats you actually meet in investigations — Windows PE executables, Linux ELF binaries, macOS Mach-O files, Android APK and DEX packages, and malicious documents.

Don't let the GitHub language stats confuse you. The repo reports YARA as the primary language because a large share of the codebase is detection rules; the tool itself is Python and runs as a command-line program.

Be clear about what you are getting. Qu1cksc0pe is a triage tool, not a sandbox. It tells you what a file looks like and what it is probably capable of — it does not detonate samples and record behavior. Use it to decide in minutes whether a file deserves deeper reverse engineering, and escalate the ones that do.

Key Challenges Addressed

The slow part of malware triage is rarely any single check. It is stitching together a string extractor, a PE parser, a packer detector, a YARA scanner, a document inspector, and a VirusTotal lookup by hand for every sample. Qu1cksc0pe targets exactly that pain:

  • Tool sprawl: one command runs the checks you would otherwise chain across half a dozen single-purpose utilities.
  • Capability assessment: import and section analysis plus pattern matching surface what a binary can do — network access, persistence, injection-style API usage — before you open a disassembler.
  • Packed samples: packer detection tells you when static results are lying to you, so you do not waste an hour reading strings from a packed shell.
  • Malicious documents: Office and PDF inspection surfaces macros and embedded objects, which is where most phishing payloads live.
  • IOC extraction: domains, URLs, IP addresses, and email addresses come out of the sample ready to feed your blocklists and threat intel notes.

Getting Started

Clone the repository and install the Python dependencies:

git clone https://github.com/CYB3RMX/Qu1cksc0pe.git
cd Qu1cksc0pe
pip3 install -r requirements.txt

Then run a static scan against a sample:

python3 qu1cksc0pe.py --file suspicious.exe --analyze

Document files get their own lane:

python3 qu1cksc0pe.py --file invoice.docm --docs

There is also an interactive console mode via --console, and an --install flag that sets the tool up as a system-wide command. For reputation checks, store a VirusTotal API key with --key_init, after which --vtFile queries VirusTotal for the sample.

Sharp edges you will hit immediately:

  • If pip3 install fails while building yara-python, your system is missing libyara headers. Install your distro's libyara-dev package (or use a prebuilt wheel) before retrying.
  • If you run --vtFile without first storing a key via --key_init, the lookup fails on authentication and you get nothing back. Run --key_init once per machine before any VirusTotal work.
  • Linux is the first-class platform. Before standardizing on Windows or macOS, check the compatibility notes in the README — some analyzer modules are partial outside Linux.
  • You are handling live malware. Keep samples in an isolated VM with no shared folders; one accidental execution on your workstation turns a triage task into an incident.

Features and Use Cases

The feature set maps cleanly onto the static triage workflow:

  • Multi-format binary triage: sections, imports, strings, and suspicious API patterns for PE, ELF, Mach-O, and APK/DEX targets.
  • YARA scanning: a bundled rule set runs against every sample, and you can drop in your own rules for org-specific detections.
  • Document analysis: macro and embedded-object inspection for Office and PDF files via --docs.
  • VirusTotal integration: hash and file reputation checks through --vtFile once a key is configured.
  • IOC extraction: network indicators pulled straight out of samples for blocklists and reporting.
  • MITRE ATT&CK context: capability findings are framed in ATT&CK terms, so your triage notes speak the same language as your detection team.

Where it earns its keep: you are a SOC analyst triaging email attachments and EDR quarantine hits, an incident responder making a fast first read of binaries pulled off a compromised host, or an instructor who wants one tool that demonstrates the entire static workflow end to end. In all three cases the win is the same — you get a defensible first verdict in minutes without juggling five tools.

Ecosystem and Dependencies

Qu1cksc0pe stands on well-known analysis libraries rather than reinventing parsers. Androguard handles Android package parsing, oletools powers the Office document analysis, and rule matching runs through YARA bindings. Terminal output is rendered with Rich, which is why the reports are actually readable at 2 a.m.

The practical consequence of leaning on that stack: when upstream libraries pin or break versions, a fresh dependency install can get brittle. If pip3 install -r requirements.txt fails on a clean machine, check the failing package against your Python version before assuming the tool itself is broken.

Architectural Overview

The design is a dispatcher plus per-format analyzers. The main qu1cksc0pe.py script parses your flags, identifies the target file type, and routes to a dedicated analyzer for that family — Windows binaries, Linux binaries, Android packages, documents. Detection content (YARA rules and pattern definitions) lives separately from analyzer code.

That separation matters for two reasons. First, extending detection means adding rules, not modifying Python logic — you can harden coverage for your environment without forking the tool. Second, the analyzers are independent, so a parsing failure in one format does not take down triage for the others. The trade-off is that this is a terminal-first tool: if you want it inside an automated pipeline, you are wiring up CLI invocations and parsing output yourself rather than calling a documented API.

Pros and Cons

Pros:

  • One command covers PE, ELF, Mach-O, APK, and document formats — the fewest moving parts you will find for broad static triage.
  • Static-by-default is safe: it inspects samples without executing them.
  • Bundled YARA rules and ATT&CK framing give you useful signal before you have written a single custom rule.
  • Setup is a clone and a pip install — dramatically lighter than standing up a sandbox.
  • Output is built for a human on call, not for log parsers.

Cons:

  • No behavioral data. A well-packed or heavily obfuscated sample reveals little statically, and Qu1cksc0pe cannot detonate it to learn more.
  • The Python dependency stack (yara-python, Androguard) is a recurring source of install friction on fresh machines.
  • No first-class automation interface — pipeline integration is do-it-yourself CLI wiring.
  • The bundled rule set is general-purpose; serious detection coverage still requires your own YARA rules.
  • It is a community project without vendor backing, so weigh maintenance risk before making it load-bearing in production incident response.

Comparison and Alternatives

Measured 90-day trends for this project and its alternatives.

GitHub stars

Weekly star gains

11,04542-10,961
Full metrics details

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

Qu1cksc0pe

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
capa

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
Detect It Easy

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
CAPEv2

GitHub GraphQL current stargazer cohort, reconstructed from starredAt events and totalCount retrieved in one stable pagination walk. GitHub does not expose historical unstar events, so this is not an exact ledger of past star counts.

179 observed daily rows. Missing days are not fabricated.

DateValue

Issues opened

Weekly total

23120
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

Qu1cksc0pe

GitHub API observation. Historical values render only when the source provides a real observation for that day.

144 observed daily rows. Missing days are not fabricated.

DateValue
capa

GitHub API observation. Historical values render only when the source provides a real observation for that day.

142 observed daily rows. Missing days are not fabricated.

DateValue
Detect It Easy

GitHub API observation. Historical values render only when the source provides a real observation for that day.

36 observed daily rows. Missing days are not fabricated.

DateValue
CAPEv2

GitHub API observation. Historical values render only when the source provides a real observation for that day.

142 observed daily rows. Missing days are not fabricated.

DateValue

Issues closed

Weekly total

20100
Full metrics details

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

Qu1cksc0pe

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

144 observed daily rows. Missing days are not fabricated.

DateValue
capa

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

142 observed daily rows. Missing days are not fabricated.

DateValue
Detect It Easy

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

36 observed daily rows. Missing days are not fabricated.

DateValue
CAPEv2

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

142 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests opened

Weekly total

23120
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

Qu1cksc0pe

GitHub API observation. Historical values render only when the source provides a real observation for that day.

144 observed daily rows. Missing days are not fabricated.

DateValue
capa

GitHub API observation. Historical values render only when the source provides a real observation for that day.

142 observed daily rows. Missing days are not fabricated.

DateValue
Detect It Easy

GitHub API observation. Historical values render only when the source provides a real observation for that day.

36 observed daily rows. Missing days are not fabricated.

DateValue
CAPEv2

GitHub API observation. Historical values render only when the source provides a real observation for that day.

142 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests closed

Weekly total

36180
Full metrics details

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

Qu1cksc0pe

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

144 observed daily rows. Missing days are not fabricated.

DateValue
capa

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

142 observed daily rows. Missing days are not fabricated.

DateValue
Detect It Easy

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

36 observed daily rows. Missing days are not fabricated.

DateValue
CAPEv2

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

142 observed daily rows. Missing days are not fabricated.

DateValue

Pull requests merged

Weekly total

31160
Full metrics details

GitHub API observation. Historical values render only when the source provides a real observation for that day.

Qu1cksc0pe

GitHub API observation. Historical values render only when the source provides a real observation for that day.

144 observed daily rows. Missing days are not fabricated.

DateValue
capa

GitHub API observation. Historical values render only when the source provides a real observation for that day.

142 observed daily rows. Missing days are not fabricated.

DateValue
Detect It Easy

GitHub API observation. Historical values render only when the source provides a real observation for that day.

36 observed daily rows. Missing days are not fabricated.

DateValue
CAPEv2

GitHub API observation. Historical values render only when the source provides a real observation for that day.

142 observed daily rows. Missing days are not fabricated.

DateValue

Open/closed pull request ratio

Weekly average

100500
Full metrics details

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

Qu1cksc0pe

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
capa

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
Detect It Easy

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
CAPEv2

GitHub Search pull-request totals queried for exact UTC days; rolling values are sums of proven daily counts.

179 observed daily rows. Missing days are not fabricated.

DateValue

Open/closed issues ratio

Weekly average

100500
Full metrics details

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

Qu1cksc0pe

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
capa

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
Detect It Easy

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

180 observed daily rows. Missing days are not fabricated.

DateValue
CAPEv2

GitHub Search issue totals queried for exact UTC days; rolling values are sums of proven daily counts.

179 observed daily rows. Missing days are not fabricated.

DateValue

Releases

Weekly total

110
Full metrics details

GitHub release published_at events bucketed by UTC day; drafts are excluded.

Qu1cksc0pe

GitHub release published_at events bucketed by UTC day; drafts are excluded.

180 observed daily rows. Missing days are not fabricated.

DateValue
capa

GitHub release published_at events bucketed by UTC day; drafts are excluded.

180 observed daily rows. Missing days are not fabricated.

DateValue
Detect It Easy

GitHub release published_at events bucketed by UTC day; drafts are excluded.

180 observed daily rows. Missing days are not fabricated.

DateValue
CAPEv2

GitHub release published_at events bucketed by UTC day; drafts are excluded.

179 observed daily rows. Missing days are not fabricated.

DateValue

Hotness score

Weekly average

100500
Full metrics details

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

Qu1cksc0pe

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.

  • Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
  • Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
  • Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
  • Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
  • Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
  • Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score
capa

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.

  • Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
  • Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
  • Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
  • Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
  • Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
  • Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score
Detect It Easy

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.

  • Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
  • Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
  • Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
  • Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
  • Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
  • Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score
CAPEv2

Derived only from GitHub GraphQL starredAt events after daily star totals are reconciled.

179 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.40 × Hot today + 0.40 × Hot week + 0.20 × Breakout.

  • Same-day multiplier = stars 1d ÷ max(1, stars 7d ÷ 7)
  • Weekly multiplier = stars 7d ÷ max(1, stars 30d ÷ 30 × 7)
  • Fortnight multiplier = stars 14d ÷ max(1, stars 90d ÷ 90 × 14)
  • Hot today = clamp(70 × log-scale(stars 1d, 1000) + 30 × breakout-scale(same-day, 4))
  • Hot week = clamp(75 × log-scale(stars 7d, 5000) + 25 × breakout-scale(weekly, 3))
  • Breakout = clamp(35 × breakout-scale(same-day, 4) + 40 × breakout-scale(weekly, 3) + 25 × breakout-scale(fortnight, 2.5))
DateStarsStars 1dStars 7dStars 14dStars 30dStars 90dSame-day multiplierWeekly multiplierFortnight multiplierHot todayHot weekBreakoutStored score

Reliability score

Weekly average

100500
Full metrics details

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

Qu1cksc0pe

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
  • Support burden = 100 − 2 × open issues per 1,000 stars
  • Liveness = 100 × exp(−pushed days ago ÷ 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score
capa

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
  • Support burden = 100 − 2 × open issues per 1,000 stars
  • Liveness = 100 × exp(−pushed days ago ÷ 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score
Detect It Easy

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

180 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
  • Support burden = 100 − 2 × open issues per 1,000 stars
  • Liveness = 100 × exp(−pushed days ago ÷ 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score
CAPEv2

Derived from the displayed continuity, closure, shipping, liveness, and support-burden components.

179 observed daily rows. Missing days are not fabricated.

Per-day formula: 0.30 × Continuity + 0.30 × Closure + 0.20 × Shipping + 0.10 × Liveness + 0.10 × Support burden.

  • Continuity = 35% active ratio 90d + 20% active ratio 30d + 15% PR efficiency 90d + 10% PR efficiency 30d + 10% liveness + 10% observed-history coverage
  • Closure = 55% PR merge efficiency 90d + 45% issue close efficiency 90d
  • Shipping = 100 × (20% × release ratio 30d + 30% × release ratio 90d + 50% × release ratio 180d); ratios are releases ÷ 2, 6, and 12, capped at 1
  • Support burden = 100 − 2 × open issues per 1,000 stars
  • Liveness = 100 × exp(−pushed days ago ÷ 120)

Stars, issues, pull requests, and releases are daily observations. Pushed-days and license are repository snapshot-derived inputs and are not independent historical GitHub events.

DateIssues openedIssues closedPRs openedPRs mergedReleasesStarsOpen issuesPushed days agoContinuityClosureShippingLivenessSupport burdenLicenseObserved daysMissing daysNeeds healingStored score

No single tool owns this space. The real question is whether you need broad static triage, deep capability analysis, or full dynamic detonation — and each alternative picks a different point on that line.

capa is the strongest static capability analyzer for PE, ELF, .NET, and shellcode: it tells you what a binary can do and maps findings to MITRE ATT&CK with a large, actively maintained rule corpus. It does not cover documents or Android, which is exactly the gap Qu1cksc0pe fills. Detect It Easy is the reference tool for packer and compiler identification — far narrower than Qu1cksc0pe, but best-in-class at that one job. CAPEv2 is a full dynamic sandbox with payload and config extraction; it answers questions no static tool can, at the cost of real infrastructure you have to deploy and babysit. Viper treats the problem as binary management — a better fit when your actual pain is organizing and enriching a growing sample collection rather than triaging one file fast. Cuckoo Sandbox is archived and unmaintained; do not start a new deployment on it — use CAPEv2 instead.

Project Repo Hotness (~6mo) PRs merged (~6mo) Star growth (~6mo)
Qu1cksc0pe https://github.com/CYB3RMX/Qu1cksc0pe 45.37 0 413
capa https://github.com/mandiant/capa metrics pending 0 36
Detect It Easy https://github.com/horsicq/Detect-It-Easy 4.52 0 6383
CAPEv2 https://github.com/kevoreilly/CAPEv2 metrics pending 0 74
Viper https://github.com/viper-framework/viper metrics pending 0 metrics pending
Cuckoo Sandbox https://github.com/cuckoosandbox/cuckoo metrics pending 0 metrics pending

If you only adopt one alternative, make it capa: Mandiant maintains it actively, the documentation and rule corpus are excellent, and its capability-to-ATT&CK output is the most actionable static signal in this group.

Conclusion

If you triage suspicious files in a SOC or incident response role, install Qu1cksc0pe and make it your default first pass — one command covers PE, ELF, Mach-O, APK, and document samples instead of five single-purpose tools. The official repository and README document every flag with examples. I recommend it specifically for the minutes-not-hours first verdict; keep your disassembler for the samples that earn it.

Do not call --vtFile before you store a VirusTotal API key with --key_init — the lookup fails on authentication and you get no reputation data. Keep every sample inside an isolated VM with no shared folders, because one accidental execution on your workstation is an incident, not a near miss. Do this first: git clone https://github.com/CYB3RMX/Qu1cksc0pe.git && cd Qu1cksc0pe && pip3 install -r requirements.txt.

Join the conversation

Reviews · Questions · Posts

Share what you know about Qu1cksc0pe — write a review from your real experience, ask an implementation question, or publish a post about how you use it.

Share your experience

Write or update your review

Explain what worked, what broke down, and what another team should know before adopting Qu1cksc0pe.

Write your review now — it saves locally and publishes automatically after you sign in.

Rating
Positive attributes
Negative attributes

Project Q&A

Questions and answers

Browse implementation threads tied directly to CYB3RMX/Qu1cksc0pe. Each question links through to the full answer page.

Q&A No threads yet

Be the first to ask how teams run Qu1cksc0pe in production. Every question you post becomes a durable, searchable answer page other developers can find.

Ask the first question

Related posts

Posts tagged with the same topics

These posts come from the same topic surface as this repo, so readers can move from project evaluation into practical writeups and migration notes without leaving context.

Posts No topic-linked posts yet

Share how your team uses Qu1cksc0pe — a migration note, an architecture writeup, or a comparison. Your post reaches everyone browsing these same topics.

Write the first post
Get a weekly email with the hottest new projects in the Malware Detection & Analysis and Antivirus world.
No Spam. Unsubscribe easily at any time.

Copyright 2018-2026 Awesome Open Source.  All rights reserved.