# Vault 7: Projects

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

### Cherry Blossom

# CherryBomb -- CherryBlossom FAT Procedures (CDRL-14a)

8 August, 2012

- 1
- 2
…
- 68
- 69
- 70
- 71
- 72
…
- 79
- 80

UNCLASSIFIED
Cherry Bomb Program Cherry Blossom FAT Procedures
5. After about 50 seconds, assuming a constant connection, the cygwin shell
from step 2 should report:
Update succeeded
Waiting for client connection
At this point, the <SQSH_FILE> has been written to flash, and the device
is going to reboot.
If the operator loses connection at some point, the cygwin shell will report:
Failed to receive status
Waiting for client connection
and the device will not be able to report the "Update succeeded" status.
As long as the cygwin shell has reported Connection Accepted as in step 4,
and the device is not power-cycled during the 50 seconds of flash writing,
the upgrade should succeed. See the "TROUBLESHOOTING AND DEVICE RECOVERY"
section if any problems arise.
6. The device takes 30-60 seconds to reboot -- the operator should see the
wireless network go down for this period of time.
TROUBLESHOOTING AND DEVICE RECOVERY:
The manufacturer's original 2.00.08 firmware has shown to be flaky,
particularly in regards to the (Atheros) wireless driver. That said,
the upgrade procedure has been tested with high likelihood (> 98%) of success.
Testing showed that in > 98% of test runs, the upgrade was successful. In some
cases, the device would reboot, but an error or kernel panic (usually related
to the wireless driver) would occur. In all cases where an error occurred
during the reboot process, an additional power-cycle would resolve the
problem.
During testing, the most common action leading to a failure was not setting
the device back to the manufacturer's original firmware AND performing an
additional power-cycle after the device fully rebooted (steps 1 and 2 of the
TEST PROCEDURE section).
If the cisc0wn-2.00.08.pl script returns "Failed", the most common cause is
running against a CB firmware (instead of original manufacturer's
firmware). This puts the device in a state whereby even if the original
manufacturer's firmware is restored, upon reboot the device's web page will
always report "500 Internal Error". To recover the unit, do the following:
1. Hold the reset button while powering the router on. Continue holding it
until the power LED begins alternating between green and orange.
2. Connect a laptop to one of the four LAN ports of the device.
3. Statically assign an IP address such as 192.168.0.7 to the laptop. Note
that the router will have the address 192.168.0.10, which should be
pingable.
4. telnet to 192.168.0.10, port 9000:
telnet 192.168.0.10 9000
When the telnet program connects, hit CTRL-C twice very quickly.
A "RedBoot>" prompt should appear.
5. From the Redboot prompt, execute (exactly and carefully):
UNCLASSIFIED
70

- 1
- 2
…
- 68
- 69
- 70
- 71
- 72
…
- 79
- 80