# 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
…
- 137
- 138
- 139
- 140
- 141
…
- 174
- 175

SECRET//20350112
15.6 (U) Manual Operation of Flytrap Software
(S) This section discusses the manual operation of Flytrap software, which can be
beneficial for development, testing, and diagnostics. In order to operate the Flytrap
software manually, you need to have a shell, which is most easily achieved by forming an
image with “Include Telnet Daemon” = “yes” (see 15.5.2). For Flytrap diagnostics, it is
typically desirable to form an image with the “Enable Debug Printing” = “yes” (see
15.5.2).
(S) The controlling Mission Manager process is typically named “mm”, and is typically
located in “/usr/sbin”, although these can be specified differently in the image formation
process (see 15.5.2). “mm” has the following useful command line options:
mm [-i serverAddress] [-p serverPort] [-b initialBeaconPeriodSec]
[-t initialBeaconTrafficRequirement] [-l logLevel] [-x]
-> serverAddress is PoP address to beacon through
-> serverPort is PoP port to beacon through
-> pollPeriodSec is the number of seconds between polling the nfhook
-> initialBeaconPeriodSec is the time to wait before sending the
Initial Beacon (only relevant if Initial Beacon has not been sent)
-> initialBeaconTrafficRequirement is the traffic requirement to use
for the Initial Beacon (only relevant if Initial Beacon has not
been sent). 0 implies NONE, 1 implies LOW, 2 implies MEDIUM, 3
implies HIGH
-> logLevel is the verbosity of logging. The higher this number, the
more logging (both mm and kernel) is done
-> -x permanently erases all Flytrap-specific nvram data, essentially
resetting the device to the same state as just after initial
Flytrap firmware upgrade. mm exits after erasing nvram data.
(S) The most common situation in which manual operation is desired is to have a Flytrap
immediately beacon to a particular PoP (which forwards the Beacon to the CherryTree
and retrieves a Mission). To do so:
• connect and telnet to the device
• kill the mm processing with “killall mm”
• reset the Flytrap-specific nvram data with “mm –x”
• start mm with:
mm –i serverAddress –p serverPort –b 0 –t 0
• to diagnose Flytrap behavior, you may want to instead start mm with:
mm –i serverAddress –p serverPort –b 0 –t 0 –l 3
which will produce very verbose logging if the image has been formed with
“Enable Debug Printing” = “yes”
(S) It should be noted that the “-b” and “-t” options are not relevant if an Initial Beacon
has been successfully sent – in this case the Flytrap will use the “Power-Cycle Wait” and
“Traffic Requirement” parameters (see 9.11.8) from the last Mission it retrieved to
determine how long to wait and what traffic requirement to use for the Beacon,
respectively. The mm “–x” option can be executed to erase all Flytrap-specific nvram
139
SECRET//20350112

- 1
- 2
…
- 137
- 138
- 139
- 140
- 141
…
- 174
- 175