1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
//! Boot-sector / MBR malware plaintext markers.
//!
//! Single source of truth for documented boot-sector-malware byte markers, for
//! forensic tools that scan an MBR/VBR boot-code area (e.g. `mbr-forensic`).
//! Markers are matched as substrings anywhere in the boot code, so each needs
//! only the literal bytes — no fragile fixed offsets.
//!
//! The seed set is deliberately limited to **publicly-documented historical
//! markers** so that no pattern here is fabricated. Operators extend
//! [`BOOTKIT_MARKERS`] with vetted markers from their own threat intel.
//!
//! Sources:
//! - "Stoned" boot-sector virus (1987) — taunt strings `"Your PC is now Stoned!"`
//! and `"LEGALISE MARIJUANA"`: F-Secure / virus encyclopedia descriptions;
//! <https://en.wikipedia.org/wiki/Stoned_(computer_virus)>
/// One boot-sector-malware marker: a family `name` and the literal `needle`
/// bytes that, if present anywhere in the boot code, identify it.
/// Seed table of documented boot-sector-malware markers (see module docs).
pub const BOOTKIT_MARKERS: & = &;
/// Scan `boot_code` for every known marker, returning the distinct family names
/// that matched, in table order (each family reported at most once).
/// `true` when `needle` occurs anywhere in `haystack`. Empty needles never match.
// ── Signature-free heuristic knowledge ───────────────────────────────────────
//
// The authoritative open reference (ANSSI `bootcode_parser`) detects MBR/VBR
// bootkits by hash-whitelisting known-good boot code and falling back to
// HEURISTICS, not per-family byte signatures — the significant families (TDL4,
// Rovnix) are polymorphic by design, so robust detection is signature-free. The
// constants below are the cited knowledge those heuristics consume; the
// detection logic itself lives in the consuming crate (e.g. `mbr-forensic`).
//
// Sources:
// - ANSSI `bootcode_parser` (hash-whitelist + heuristics; the expected-interrupt
// set): <https://github.com/ANSSI-FR/bootcode_parser>
// - Mebroot/Sinowal — original MBR at sector 62, payload sectors 60/61; INT 13h
// read-spoofing: Florio & Kasslin, Virus Bulletin 2008, "Your computer is now
// stoned (…again!)":
// <https://www.virusbulletin.com/virusbulletin/2008/04/your-computer-now-stoned-again>
// - Petya (Red) — original MBR (XOR 0x37) at sector 56, repeating-0x37
// verification sector 55: Kaspersky Securelist, "Petya: the two-in-one trojan"
// <https://securelist.com/petya-the-two-in-one-trojan/74609/>
// - NotPetya — sector-0 backup at sector 34: Fortinet, "Petya's Master Boot
// Record Infection"
// <https://www.fortinet.com/blog/threat-research/petya-s-master-boot-record-infection>
// - TDL4 — original MBR in an end-of-disk RC4 container (no fixed LBA): Kaspersky
// Securelist, "TDL4 – Top Bot" <https://securelist.com/tdl4-top-bot/36152/>
// - Boot-code entropy 7.0 (suspect) / 7.5 (strong): general packer-detection
// figures borrowed by analogy (no MBR-specific authority) — Lyda & Hamrock,
// IEEE S&P 2007, "Using Entropy Analysis to Find Encrypted and Packed Malware".
// Self-decrypting stubs can sit below these, so treat as triage, not proof.
/// A sector where a documented MBR bootkit stashes the original MBR or a payload.
/// LBAs where documented MBR bootkits stash the original MBR or payload sectors.
///
/// A structurally-MBR-like sector (ending in `0x55AA`) found at one of these — or
/// anywhere in [`TRACK0_GAP`] or the disk's final sectors — that is NOT the live
/// MBR at LBA 0 is the strongest signature-free bootkit indicator. (TDL4 and
/// Guntior instead stash at the disk's end, which has no fixed LBA and must be
/// scanned by offset from the last sector.)
pub const ORIGINAL_MBR_STASH_SECTORS: & = &;
/// The legacy 'track-0 gap' — LBAs 1..=62, between the MBR (LBA 0) and the first
/// conventionally-aligned partition at LBA 63. A classic stash region; any hidden
/// MBR-shaped sector here is suspicious.
pub const TRACK0_GAP: RangeInclusive = 1..=62;
/// Boot-code Shannon entropy (bits/byte) above which the 446-byte code area is
/// *suspected* packed/encrypted (triage only — borrowed from general packer
/// literature; self-decrypting stubs can sit below it).
pub const PACKED_BOOT_CODE_ENTROPY_SUSPECT: f64 = 7.0;
/// Entropy above which packing/encryption is *strongly* indicated.
pub const PACKED_BOOT_CODE_ENTROPY_STRONG: f64 = 7.5;
/// BIOS real-mode interrupt vectors a legitimate MBR/VBR boot stub is expected to
/// invoke: video `0x10`, disk `0x13`, blocking `0x18`, time `0x1a`. An `int` to
/// any other vector in disassembled boot code is a suspicious indicator (ANSSI).
pub const EXPECTED_BOOT_INTERRUPT_VECTORS: & = &;
/// Documented stash entries whose `lba` equals `lba` (a sector may be used by
/// more than one family / for more than one purpose). The returned iterator is
/// lazy — collect or inspect it.