Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.
SECRET//20350112
detected. For example, the Copy of too many concurrent calls will impact user
performance to a point where call quality is spotty.
5.2.3.12 (U) Harvest Mode
(S) Flytraps support a Mission-configurable “Harvest Mode”, which harvests email
addresses and chat users (and VoIP numbers for Roundhouse version 2 devices (svn >
7500)) found using the Flytrap implant search algorithms (see 15.4) and reports them
back to the CT in a subsequent Beacon. Harvest mode will send up to 3 kilobytes of
harvest data per Beacon (2 kilobytes are reserved for webmail and chat filter [i.e., “Strict”
harvests], and 1 kilobyte is reserved for RFC 822 email filter harvests, as described in
15.4). At each beacon, the harvest buffer fill percentage (both RFC 822 and webmail [or
“Strict”]) is computed. See 9.11.9 for enabling Harvest in a Mission and 9.24 for viewing
Harvest data with CherryWeb.
5.2.3.13 (U) Minimal Resource Usage
(S) The Flytrap implant uses minimal device CPU and RAM. Performance tests indicate
that for a device with a T1 WAN connection, wireless client throughput is degraded by <
1%. Total RAM usage for Flytrap software modules is on the order of 500 kilobytes
(executing processes use around 250 kilobytes, but devices typically use a RAM-mounted
file system (cramfs or squashfs) and so the size of the uncompressed binary executable
file uses another 250 kilobytes of RAM).
5.2.3.14 (U) Minimal Interference with Normal Device Operation or Look and Feel
(S) The Flytrap implant has minimal interference with normal device operation or look
and feel. The Image Formation process (see Section 15.5) inserts the CB implant directly
into the manufacturer’s original firmware, so that the behavior of the original
manufacturer’s firmware is maintained. For example, the web pages used to configure the
device remain unchanged.
5.2.3.15 (U) Suicide
(S) Flytraps have both an Initial Beacon and Mission-configurable “suicide” interval. If a
Beacon cannot be sent successfully within this suicide interval, the Flytrap will self-abort.
Note that the device will still function properly, but the implant software will no longer
run. The suicide persists through power-cycle events. The Flytrap suicide feature is fully-
supported on devices that retain Flytrap NVRAM values (see 15.3) even after a hard-
reset/restore factory defaults event (see “Wifi Devices.xls”) – devices not supporting this
will be “killed” until the next hard-reset event, at which time the device would enter an
initial state (i.e., it would return back to the Initial Beacon state).
Note: For most devices, the implant cannot actually be removed, but simply does not
execute once a suicide or kill event has occurred. Generally, most Flytrap devices
persistently store the firmware image in flash memory as a compressed file. When the
device is powered-on, the firmware image is decompressed into (volatile) RAM, and then
executed. The Flytrap implant is packaged directly into this compressed firmware image.
In order to remove itself permanently, the implant would need to decompress the
firmware image into another section of RAM (different than the section it is currently
18
SECRET//20350112