# Vault 7: Projects

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

### Cherry Blossom

# CherryBomb_CherryBlossom_Internal_TestProcedures_CDRL-14c

- 1
- 2
…
- 43
- 44
- 45
- 46
- 47
…
- 70
- 71

UNCLASSIFIED
Cherry Bomb Program Cherry Blossom Internal Test Procedures
a series of “Options”, with one of them being the “Router” option, which
contains a list of router IP addresses (in many cases just one, however). The
Flytrap filters DHCP packets, searching for the “Router” Option flag. When
one is discovered, the Flytrap sets its default gateway to this value and
caches it for future power-cycles in NVRAM.
To test this, first configure the AP without a default gateway using the web
interface. Then, telnet to the AP, killall mm, and unset any default gateways
cached in NVRAM (this is done with “flash set
DEF_WLAN1_ACCOUNT_RS_IP 0.0.0.0”). You may also need to manually
remove the default gateway from the routing table (with “route del default”).
Be sure that the router that the Flytrap is connected to will server DHCP
addresses. Configure the wireless Client Computer to get its IP address
automatically using DHCP, and disconnect it from the network. Next, start
mm. Then connect the wireless client to the Flytrap. If the test is successful,
mm debug output should indicate “Found DCHP gw=a.b.c.d” or something
similar, and the Flytrap should beacon successfully.
Cached Gateway Test – DGD will cache a discovered gateway in NVRAM
(typically in an unused key, as most devices have a number of these) so that
discovery is quicker after a power-cycle. Because the cached value could be
invalidated at some point, an internet connection test is done after setting this
cached gateway. If it fails, the gateway is unset, removed from the cache, and
the ARP/DHCP discovery techniques resume.
First, perform a successful ARP or DHCP test. Then telnet to the device, and
“killall mm”. Then start “mm”. mm debug should report “Adding route for
stored gw=a.b.c.d”, and the Flytrap should successfully beacon.
Next test that an incorrect cached value does indeed get uncached after an
unsuccessful internet connectivity test. To do so, set the cached gateway to a
nonsense IP (this is done with “flash set DEF_WLAN1_ACCOUNT_RS_IP
1.2.3.4”). Then telnet to the device, and “killall mm”. Then start “mm”. mm
debug should indicate an internet connection failure, and remove the cached
gateway (you can check on the device with “flash get
DEF_WLAN1_ACCOUNT_RS_IP” which should report 0.0.0.0). Then run a
DHCP or ARP Test, verify a successful beacon, and check the cached
gateway (use “flash get DEF_WLAN1_ACCOUNT_RS_IP”, which should
report the proper gateway IP.
User Reconfigured Gateway Test – test that if a gateway is reconfigured on
the device through the web page, that beacons still go through. While mm is
running, open the web configurator, set a correct gateway, and save the
changes. Verify that mm is still beaconing successfully.
Pass/Fail: the test passes if the above 4 subtests pass.
UNCLASSIFIED
45

- 1
- 2
…
- 43
- 44
- 45
- 46
- 47
…
- 70
- 71