5.10 The exploit kits

The last family is the one this manual refuses to expand: three modules that catalogue several hundred CVEs between them. A CVE is not a technique. It is one message shape with one vulnerable parser behind it, and whether it works depends on the baseband, the firmware revision, and the testbed. So each kit gets one page, and the pages are about how to use the kit — how to find out what it covers, how to run one entry honestly, and how to tell a corpus entry from a demonstrated capability.

Nothing in this family needs a radio to read. Everything in it needs a lab device to run.

5.10.1 The GSM/GPRS kit

Need: nothing to enumerate; a lab handset and SIM to run.

modules/20_gsm_cve.sh --coverage          # what the corpus covers and its horizon
modules/20_gsm_cve.sh --list-cves        # id, kind, class, needs, label
modules/20_gsm_cve.sh --probe            # what this bench can actually reach
modules/20_gsm_cve.sh --plan             # the run plan for the entries that are reachable
modules/20_gsm_cve.sh --run-cve CVE-2019-16256
modules/20_gsm_cve.sh --runs-tsv         # every run, with its verdict
modules/20_gsm_cve.sh --reachability     # per entry: reachable here, or why not

--coverage is the page that keeps the kit honest:

corpus         GSM/GPRS CVE corpus
entries        29
years_covered  2010 2015 2017 2018 2019 2020 2021 2022 2024 2025
corpus_horizon 2025-12-31
checked_on     2025-06-01

Read the horizon, not the count. A corpus has a date because the world keeps producing vulnerabilities, and a kit that claimed completeness would be claiming to have stopped time. --reachability then says, per entry, whether this bench can reach it at all: Simjacker needs a SIM-Toolkit harness, not a radio, and the kit says so rather than offering a button that would fail.

The needs column in --list-cves is the single most useful thing here. An entry marked programmable-sim cannot be run against a stock SIM; an entry marked sim-toolkit-harness needs the harness on the bench. --probe turns that into a checklist for the machine you are sitting at.

What you read: the run verdict per entry, and the difference between "not vulnerable", "could not deliver", and "not reachable from this bench". Only the first is a statement about the device.

When it refuses: --run-cve with an id not in the corpus is refused with the nearest match; a run whose prerequisites are missing records the missing prerequisite rather than a failed exploit.

Read next: §5.5.2 for the SIM-Toolkit surface most of this corpus targets.

5.10.2 The LTE kit

Need: nothing to enumerate; a lab eNB/EPC path to run.

modules/21_lte_cve.sh --coverage
modules/21_lte_cve.sh --list-cves
modules/21_lte_cve.sh --corpus            # the message corpus the kit carries
modules/21_lte_cve.sh --corpus-entry <id>
modules/21_lte_cve.sh --corpus-stats
modules/21_lte_cve.sh --gen --plmn 310-260 --teid 0x0001
modules/21_lte_cve.sh --run-cve <id>
modules/21_lte_cve.sh --runs-tsv

The LTE kit carries a corpus of real message bytes alongside the CVE list, which is what makes it useful without a vulnerable phone: --corpus-entry prints one, --gen materialises the corpus against your own PLMN and TEID, and --corpus-stats says what is in it (message types, generations, plaintext vs protected). A corpus entry is a test vector, not an exploit — running it against a healthy stack should produce a clean rejection, and that is the expected result.

What you read: from --corpus-stats, whether the corpus has the message you care about; from --runs-tsv, what happened when a vector met a device.

When it refuses: --corpus-entry with an unknown id; --gen without a PLMN, because a corpus generated against an unstated network is not reproducible.

Read next: §5.4.1 for the core-side messages this kit's corpus exercises.

5.10.3 The 5G kit

Need: nothing to enumerate; a lab gNB/core path to run.

modules/22_nr_cve.sh --coverage
modules/22_nr_cve.sh --list-cves
modules/22_nr_cve.sh --list-findings      # the write-ups behind the entries
modules/22_nr_cve.sh --run-cve <id>
modules/22_nr_cve.sh --probe
modules/22_nr_cve.sh --reachability
modules/22_nr_cve.sh --snssai <hex>       # scope a run to a slice
modules/22_nr_cve.sh --plan

5G's corpus is younger and mostly not in the baseband: a large share of the entries are service-based-architecture findings — a network function that trusts a token it should not, an NRF that enumerates more than it should — which is why --snssai exists to scope a run to one slice and why §5.4.3 is the reading before this page.

--list-findings prints the write-up each entry came from, so an entry can be traced to a published disclosure rather than to a name in a list.

What you read: --reachability, the same discipline as the GSM kit: which entries this bench can even attempt.

When it refuses: a slice identifier that is not an S-NSSAI; a --run-cve for an entry whose prerequisite network function is absent from --probe.

Read next: §5.4.3 for NRF discovery, §5.4.5 for slice selection.

5.10.4 A baseband research kit

Need: a lab device, and a lot of patience. This is the only family member that operates below the message layer: it is about reaching a baseband's own code, and it is explicit that the useful part is the harness, not the payload.

modules/54_baseband_exploit.sh --list-cves
modules/54_baseband_exploit.sh --cve <id>
modules/54_baseband_exploit.sh --states          # baseband state machine
modules/54_baseband_exploit.sh --fw-manifest     # what firmware this bench holds
modules/54_baseband_exploit.sh --fw-verify
modules/54_baseband_exploit.sh --qemu-harness    # can a stripped image run here
modules/54_baseband_exploit.sh --emulate
modules/54_baseband_exploit.sh --l2-build --l2-case <name>
modules/54_baseband_exploit.sh --l2-corpus
modules/54_baseband_exploit.sh --plan

--qemu-harness and --emulate are the honest centre of the module: most baseband research is spent getting an image to run at all, and the kit reports what it can and cannot emulate rather than pretending a CVE is a button. The L2 case builder (--l2-build, --l2-corpus, --l2-case) is how a specific parser gets exercised in that harness.

--fw-manifest plus --fw-verify is a chain-of-custody tool: which firmware images are on this bench, and do they still hash to what they did when they were acquired. A research result you cannot tie to an image is not reproducible.

When it refuses: --emulate without a verified image; --cve with an id the kit does not carry.

Read next: §5.10.5, which is the diagnostic half of the same work.

5.10.5 Baseband diagnostics

Need: a lab device. Where §5.10.4 tries to reach code, this page is about seeing what the modem is doing at all — which is the prerequisite for every baseband result anyone has ever published.

modules/56_baseband_diag.sh --ports              # diag ports this device exposes
modules/56_baseband_diag.sh --cmd-name 0x0b      # what a diag command id means
modules/56_baseband_diag.sh --frame / --unframe  # the diag framing layer
modules/56_baseband_diag.sh --demux              # split a diag stream by subsystem
modules/56_baseband_diag.sh --log-classify       # sort a log by what it is about
modules/56_baseband_diag.sh --nv-scan --nv-parse # non-volatile item read
modules/56_baseband_diag.sh --state --state-info # modem state machine, decoded
modules/56_baseband_diag.sh --efs-walk --efs-read
modules/56_baseband_diag.sh --at --at-parse
modules/56_baseband_diag.sh --audit

The EFS/NV verbs matter beyond diagnostics: a device's non-volatile store is where identities, calibration and provisioning live, so --nv-scan, --efs-walk and --audit are how you establish that a lab device is what you think it is before you trust a result from it.

What you read: --audit's summary of what the store exposes; --log-classify per line of a log; --state-info for where the modem thinks it is.

When it refuses: an unframed stream given to --demux; an EFS path outside the store's own root.

Read next: §5.5.1, which reads an identity from the SIM side rather than the modem side, and the store table in §3.1 for the directories these verbs write into.