# Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.

### Cherry Blossom

# SRI-SLO-FF-2012-177-CherryBlossom_UsersManual_CDRL-12_SLO-FF-2012-171

- 1
- 2
…
- 17
- 18
- 19
- 20
- 21
…
- 174
- 175

SECRET//20350112
executing in), then remove the implant components from this decompressed section, then
recompress the section (without the implant components) into a bootable firmware
image, and finally rewrite the new firmware image to flash. Flytrap devices typically do
not have the resources (RAM) necessary to perform such an operation, and the operation
itself would be time-consuming and if interrupted or done incorrectly could render the
device inoperable.
5.2.3.16 (U) Kill
(S) Flytraps can be assigned a Kill Mission. At the next successful Beacon, the Flytrap
will receive the Kill Mission and immediately abort. Note that the device will still
function properly, but the Flytrap implant will no longer run. The kill persists through
power-cycle events. A Kill Mission 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: see the note of 5.2.3.15.
5.2.3.17 (U) Default Gateway Discovery (DGD)
(S) DGD is a series of passive techniques to discover the default gateway on a LAN if
one has not been configured on the Flytrap device. Certain Flytrap make/models support
Default Gateway Discovery – in particular the Senao/Engenius 3220 devices support
DGD. If a device does not have a default gateway route in its routing table, the Flytrap
will not be able to open a connection to the internet, and hence not be able to send
Beacons/Alerts. Typically, DGD is only needed on true AP devices (i.e., not wireless
router devices) because true AP’s do not typically need a default gateway in order to
operate – they merely bridge same subnet clients and do not route traffic to other subnets.
Section 15.7 discusses DGD techniques in more detail.
5.2.3.18 (S) Firmware Upgrade Inhibit and Upgrade Alert
(S) The Flytrap implant will not survive a firmware upgrade (exception: Roundhouse
devices). As such, a few Flytrap device types support a “Firmware Upgrade Inhibit”
feature that does not allow the user to upgrade firmware (see 6.2 for device types that
support this feature). This feature is an option specified at firmware build time. See
section 12.7 for more detailed info.
(S) As of svn revision 8222 (CB v4.0), a few Flytrap device types also support the
Upgrade Alert feature (see 6.2 for device types that support this feature). If a device
owner visits the device’s firmware upgrade page, the Flytrap sends a “page visit”
Upgrade Alert to the CT. If the owner attempts a firmware upgrade, the Flytrap sends an
“upgrade attempt” Upgrade Alert. In the case of a Flytrap configured with the Firmware
Upgrade Inhibit option, the Flytrap will only send an “upgrade attempt” Upgrade Alert in
the case where the owner has somehow subverted the Upgrade Inhibit (i.e., the Upgrade
Inhibit option prohibits the owner from performing a detectable upgrade attempt action).
19
SECRET//20350112

- 1
- 2
…
- 17
- 18
- 19
- 20
- 21
…
- 174
- 175